PDA

View Full Version : PR Damage Calculator


Senshi
January 30th, 2016, 03:35 PM
Just for those curiously inclined, I'm currently working on another small tool:
Super-early alpha damage calculator (http://tournament.realitymod.com/damagecalc)

Currently it only shows info about materials, so it's not really a damage calculator yet.

A short summary about how PR actually calculates damage (it's logical, but not trivial):
A firearm emits a projectile.
That projectile has the following important parameters:
- raw damage
- material
Said material defines how the projectile reacts when hitting another material.
All soldiers, vehicles, statics, even terrain also have materials assigned (objects can have them assigned per-polygon, meaning it is important where you hit the target). The relation of "offensive" material vs "defensive" material is assigned a damage modifier (among other properties), which is a multiplier applied to the raw damage value of the projectile.

Example:
The Russian AK74M (rurif_ak74m) fires a 545_39_g projectile. This projectile has a raw damage value of 36 hitpoints and has material 3556 assigned.
In the damage calculator, I can now set this material as source material ("3556 pr_bullet_556").
I can then see what target relations are defined for this one (many), and select my target. Usually, you target soldiers, so I filter for "human" in the target list.
This shows me that the following multipliers apply:
23 Bodyarmour: 36 * 1.0 = 36HP
3703 Poor Bodyarmour: 36 * 1.3 = 45.5HP
24 Body: 36 * 1.7 = 61.2HP
25 Head: 36 * 5 = 180HP
77 Limbs: 36 * 1.1 = 39.6HP

All PR soldiers have 100 HP, and will start bleeding 0.2HP/sec at 75HP or less.

Projectiles also can cause splash damage. This follows the same principle: There's a raw "explosionDamage" and "explosionMaterial" assigned. However, for explosions it is NOT relevant where you hit a target: Instead, each object has a "default material" assigned. Explosive damage is always matched against this default material, no matter where the explosion "ball" will hit. For soldiers, this is material 24 (= human_body) in most (all?) cases.
Projectiles also have a "explosionradius" defined. The closer to the limit of the radius the target is, the less damage it takes (this is a linear relation: 25% radius = 75% damage).
The AK does not deal explosive damage. Some big calibers (12+mm, as found in heavy static MGs (e.g. DShK) or autocannons) can.
On a direct hit with an explosive round, BOTH the impact damage and explosive damage is received by the target. Random fact: Hand grenades deal zero damage on impact.

We're not done yet: Projectiles can have an additional modifier that depends on travel distance. This is used in PR for all ballistic projectiles.
The AK74M will start losing damage at 350m, and reach a minimum damage of 40% at 1000m distance. The decrease in damage between those points is also linear. This multiplier can be a severe reduction: a headshot at 1000m deals merely 72HP damage.




Currently, you have to look up the firearm name and projectile information yourself in the game files.

So the logical next step for this tool is to add projectile and gun information, and allow selecting guns/projectiles and target objects. I have all that information present, but sadly it's ~20MB of data. Don't want to force clients to load that via JScript everytime they open the webpage.
So I have to delve into PHP coding, another new topic for me. The expected benefit is that users will not have to download the entire dataset, but will only request the tiny snippet of information they actually need (the server will select and send it).

As I just restrict it to materials right now, Jscript is fine, though it's still ~2MB of data (which explains why it takes a couple of secs to fill the list).

Also, no styling yet. Barebone HTML ftw.

It'll probably take a while until I have this PHP stuff sorted out, hence a barebone release now.

SgtTetgmeyer
January 30th, 2016, 06:36 PM
Senshi, the maker of random useful tools we didn't know we needed until he made them.

Norby
January 30th, 2016, 06:39 PM
That is an interesting project. I will be following your progress.

Banana_Joe
January 30th, 2016, 06:49 PM
Looks very interesting.


The expected benefit is that users will not have to download the entire dataset, but will only request the tiny snippet of information they actually need (the server will select and send it).

To me this sounds like you should think about using a back-end database to store your data.
If that, for some reason, shouldn't be an option for you the next best thing I can think of right now would be to compress the data before sending it. Although a DB would still be the better solution imo.

Senshi
January 30th, 2016, 09:26 PM
Don't think a full-scale SQLDB is necessary, the parsing is pretty simple and still lightning-fast. "Just" have to figure out how to do all that on the server and send back the generated HTML table :) .

EDIT: To clarify, the "select the correct data" requires a one-time loop over the objects with a simple if object.id == searchid
return object, which takes less than ~0.1sec on my local machine. There is some more steps, but those are trivial.
The longest delay is caused by currently having to transfer 20MB of JSON data before that.

I still believe I merely am lacking some fundamentals in Ajax to get on the right track. But I also just started this project a couple hours ago, so I'm not worried too much ;) .

Aleksis
January 30th, 2016, 10:52 PM
You could use the file system as your database. Split the 'materials' array into files for each object and rename it to material id. Then request only those who you need.

Senshi
January 31st, 2016, 09:29 AM
That would work, but it'd lead to ~12.000 tiny files, because that's how many objects PR consists of. I'd rather not do that, simply because it'd take a lot of HDD space and more importantly: I only have FTP access, so I cannot zip-upload&extract. Uploading/overwriting all files individually via FTP would take days.

Banana_Joe
January 31st, 2016, 05:29 PM
Alright.
I'd just use a simple html get request, process the request in the back-end (e.g. with php) and then return the output to the client. This means you don't have to send your json file over the network.

Senshi
January 31st, 2016, 09:02 PM
That's exactly what I said I am planning to do in all previous posts :) .
The materials.json is just one tiny file, there's still a couple other, larger files. Which is why it's a little bit more complicated, but I'm making progress already.

Banana_Joe
January 31st, 2016, 10:02 PM
Yeah I know ;)
Like I said I'd still go with a small database like sqlite or similar that doesn't need much setup really. That would reduce the server load and access time quite a bit imo :) Or at least use a divide and conquer style of search algorithm to reduce the lookup time (although from taking a quick look at your json file it's not order in any way, so that wouldn't work then...)

Senshi
January 31st, 2016, 11:59 PM
Well, if I had anything more than FTP access to the PR/PRT page, I'd do just that :) .
Search algorithm doesn't really need to be optimized, considering the lookup merely takes milliseconds. Users can wait that long...

But I'm currently working on a new hosting solution with more control and possibilities (and less outdated PHP etc. ;) ). I'm expecting only good things will come from this (buzzword Laravel), though it probably will take a while to learn and adjust my antiquated workflows. Luckily I managed to convince/coerce my brother (who is much more experienced in webdev stuff) to support me in setting this all up and teaching me the basics.

adrenalinetooth
February 20th, 2016, 08:32 AM
test

Senshi
March 23rd, 2016, 01:41 AM
New stuff on the horizon:

http://i.imgur.com/QKHPaRY.gif (http://i.imgur.com/QKHPaRY.gifv)



The data is already in place (http://i.imgur.com/qv48HtS.png) (who'd have guessed PR has over 2500 weapon definitions? And 1700+ kits?), but presentation is still extremely rough & ugly, hence it's not online yet.

Sibren
March 23rd, 2016, 10:49 AM
Starts to look nice :)

Do you think you will be able to let the tool interpret GB as Great Britain, tnk as tank and such so you can get a nice tree selection? (For example, Click tank --> Great Britain --> Challenger 2 or APC --> US --> LAV25 or AAVP or Bradley )

Senshi
March 23rd, 2016, 11:57 AM
Partially. The PR game files simply have very little localization (because ingame, very little is actually localized and presented to the player as well!). So it would require some manual "dictionary" to be written for all those non-localized parts. Basically, only vehicle names and vehicle weapons are localized in PR. Not even hand weapons.

EDIT: Also, the tree building would be tricky, because how would you sort it? One user would prefer to have vehicle types as the top branch (Tank->GB->Challenger), another would look for nations (GB->Tanks->Challenger). Making an intuitive UI is a serious challenge :( . And building the necessary smart SQL queries for data-requests as well...