try the new version I just uploaded for me - if it fails then I will make this change - I just want to verify if the cmp command had anything to do with it

Click to expand...

The new version still fails during the compilation, with the error message:

Code:

1>AmmoMod.cpp(35): error C2415: improper operand type

I don't have any knowledge of assembly language, but judging from YAAM's code it seems jle can't work with DamageFunctionReturn. gvx's modification works fine.

I like the new calculation logic, much better than the previous one as now you can modify both DR/DT separately with ammo multiplier and divisor. Just curious about two things:
1. When or where is the additional 30% DR from Finetrait applied in the new calculation?
2. Don't know if I miss something, but in the middle of the calculation:

if amDRM is greater than 0 then amDRM=0-armDRM
if CD is greater than 100 then CD is set to 25
if CD is less than 100 then CD is set to -25
armDR=armDR+amDRM+CD
if armDR>=100 and amX is greater than 1 then armDR is divided by amX

Click to expand...

With unmodified ammo protos, since all JHPs have amDRM greater than 0, it seems "armDR=armDR+amDRM+CD" (should be "armDRM+amDRM"?) will be reduced to a simple "armDR=CD".
With modified ammo protos, since there's no amDRM greater than 0, unless CD > 0 and with extremely high armDRM (like power armors' Laser DR), armDR >= 100 will be very unlikely.
Is there any other occasion that armDR >= 100 for amX coming into play? Or I should ask what exactly amX does except dividing armDR when armDR >= 100 in the new calculation?

EDIT: Uh, from your HTML it seems as long as amX is greater than 1, it will divide armDR no matter armDR is greater than 100 or not. That's why that if I change the modified ammoX of 5mm JHP from 2 to 1, the result with ADT 2 & ADR 30 will be different by 1. Because with ammoX=2, final armDR will be lower to 7 during the process.

try the new version I just uploaded for me - if it fails then I will make this change - I just want to verify if the cmp command had anything to do with it

Click to expand...

The new version still fails during the compilation, with the error message:

Code:

1>AmmoMod.cpp(35): error C2415: improper operand type

I don't have any knowledge of assembly language, but judging from YAAM's code it seems jle can't work with DamageFunctionReturn. gvx's modification works fine.

I like the new calculation logic, much better than the previous one as now you can modify both DR/DT separately with ammo multiplier and divisor. Just curious about two things:
1. When or where is the additional 30% DR from Finetrait applied in the new calculation?
2. Don't know if I miss something, but in the middle of the calculation:

if amDRM is greater than 0 then amDRM=0-armDRM
if CD is greater than 100 then CD is set to 25
if CD is less than 100 then CD is set to -25
armDR=armDR+amDRM+CD
if armDR>=100 and amX is greater than 1 then armDR is divided by amX

Click to expand...

With unmodified ammo protos, since all JHPs have amDRM greater than 0, it seems "armDR=armDR+amDRM+CD" (should be "armDRM+amDRM"?) will be reduced to a simple "armDR=CD".
With modified ammo protos, since there's no amDRM greater than 0, unless CD > 0 and with extremely high armDRM (like power armors' Laser DR), armDR >= 100 will be very unlikely.
Is there any other occasion that armDR >= 100 for amX coming into play? Or I should ask what exactly amX does except dividing armDR when armDR >= 100 in the new calculation?

EDIT: Uh, from your HTML it seems as long as amX is greater than 1, it will divide armDR no matter armDR is greater than 100 or not. That's why that if I change the modified ammoX of 5mm JHP from 2 to 1, the result with ADT 2 & ADR 30 will be different by 1. Because with ammoX=2, final armDR will be lower to 7 during the process.

Click to expand...

new version has been uploaded to the same link - modified code for that one line to be like Haen's YAAM

answers
1. "Finetrait"? As far as I am aware all trait's benefits and penalties that apply to combat are added before the section of code I have modified. So when a value is called in to the damage calculation it will already have been adjusted for any impact from a chosen trait
2. Yes I made the decision to not allow for ammoDRM to be a positive number, and instead of converting an existing positive ammoDRM to 0 I choose to convert it to a negative. I did this because I wanted my fix to be able to stand alone with unmodified proto files and bring some correction to the game. In the original, weapons using JHP ammo are overpowered; but if I had not done this, then weapons using JHP ammo would have been too weak.

After a lot of thought, it made no sense that ammo would ever add DR. I think the original devs realized the damage calculation was messed up, but instead of correcting the calculation they tried using the values fed into it to correct the output. Its any old trick, don't blame the math, blame the data.

I also had to account for high armor DR values given EMP DR for all armor is 500, but I think that's a bug to be corrected as well, by some other mod though.

Remember, my mod does nothing to affect ammo, weapons, or armor, I just changed how the values they pass into the damage calculation are used.

The modified ammo values I used in my html/javascript are just examples of what I think the ammo values should be to bring a bit more balance to the game inconjunction with my mod.

And don't know if I misunderstand the HTML code. There are two lines in the description in new calculation don't seem right for me:

Code:

if armDR>=100 and amX is greater than 1 then armDR is divided by amX

Actually as long as amX>1, armDR will be divided by amX.
Both IF statements for checking armDR ("temp" in HTML) greater or less than 100 have amX subtraction loops.

Code:

if armDR is less than or equal to 0 and amX and/or is greater than 1 then temp=(ND*small bonus percent)/100, ND=ND+temp

It seems the bonus part "if (amX>1 && amY<=1)" section doesn't check for armDR. Or did I miss something? The sentence itself also seems a bit weird.

Click to expand...

You are correct that my description does not exactly match what's going on in the javascript, that's because I was lazy and I should correct it for those who do not know how to read javascript - sorry.

The point at which the bonus is added, it's already determined in the code that the armorDR is 0 or less.

I didn't formally test the new formula in game yet, just try killing a few critters using AP ammo with vanilla value and see if the damage is better.
I'll go for vacation for next 8 days, so I can only start testing/verifying after that.

Nope, not yet. But the output will not change greatly from the current version.

Click to expand...

I think in theory the output shouldn't change at all, given if you only simplify the code for readability by removing redundant/unnecessary checks. Or are you planning to tweak the formula further?

Click to expand...

No tweaking - but it seems with what I have so far, I may have corrected inadvertently a rounding error. So when you compare the output of the current version with that of the next, you'll see a few numbers change. I've walked through it and where I was "dividing" but 100 I had missed a condition when checking what was being "divided" was either greater than or less than, I missed equal to.

So really the next version; while being simplified, also has a bug fix.

A bit off topic (sorry), but am I right that armor bypassing doesn't factor into this part of the damage formula? I suppose it then gets factored in during the total calculation afterwards (along with Living Anatomy etc.), but how do they do that then? Do they simply multiply the damage by five, or what?

A bit off topic (sorry), but am I right that armor bypassing doesn't factor into this part of the damage formula? I suppose it then gets factored in during the total calculation afterwards (along with Living Anatomy etc.), but how do they do that then? Do they simply multiply the damage by five, or what?

Click to expand...

To the best of my understanding, any adjustments that are made to any of the values used in the portion of code I've modified, are made before hand. So when those values are used in this portion of code they are final/adjusted.