PR Damage Calculator

[Senshi]

Just for those curiously inclined, I'm currently working on another small tool:
Super-early alpha damage calculator

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]

Senshi, the maker of random useful tools we didn't know we needed until he made them.

[[R-COM]​Norby]

That is an interesting project. I will be following your progress.

[Banana_Joe]

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]

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]

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]

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]

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]

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]

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...)