[Nuke]

ive added some new features to armor.tbl. features include new calculation types, storage locations, and the ability to set where difficulty is applied in relation to calculations (fixes 2493 and possibly 2494).

ive added the following calculation types to the system
+calculation:     does this
cap                   if damage is greater than +value:, damage = +value:
instant cap        if damage is greater than +value:, damage = +value: and calculations stop
set                    damage = +value:
load                  damage = number in storage location +Value: (may be between 0 and 7 right now, anything more or less will cause a warning), storage locations default to 0 if no values are stored there;
store                 current damage is stored in storage location +Value: (0-7), does not change damage. storage locations are only persistent for the duration of an armor calculation
random             random number between damage and +value:

you can use these instead of +value: (you have to use one of the 3, but you cant use more than one) on most calculation types
+stored value: # of storage location (0-7). this lets you use a stored value in place of an explicit value for a calculation
+constant: lets you choose one of several internally defined values in place of +value:

   base damage       -damage before calculations are done (this happens after difficulty scaling if set to happen first)
   current damage   -the current damage value
   difficulty factor    -the current difficulty factor, by default 0.2 (easy) to 1(insane)
   random              -random number between 0 and 1
   pi                       -3.14159... not sure what you'd use it for though

you can set where difficulty is computed on a per damage type basis with (this goes after +Weapon Piercing Type:)
+Difficulty Scale Type: first, last, manual (default is first)

things to look for:
make sure computations work
thoroughly test load and store operations
test invalid indices (should throw an appropriate warning)
make sure you cant use +stored value: with load/store calculation types (i debated whether or not to make this a feature, and decided it was better if it wasnt)
check status of mantis issue 2494 (shield armor no work for player) with this build
make sure i didnt break the game's damage mechanics

note that i haven't had a chance to test this yet.

*edit*
i fixed some bugs and uploaded a new patch, but due to an unrelated issue i cannot make any new builds at the moment

*edit again*
latest builds here

[attachment deleted by ninja]

[Nuke]

i decided i didnt like the way the "apply difficulty" calculation worked so i removed it. in its place you have another alternative to +value:, which is +constant: of which you may choose any of these:

base damage       -damage before calculations are done (this happens after difficulty scaling if set to happen first)
current damage   -the current damage value
difficulty factor    -the current difficulty factor, by default 0.2 (easy) to 1(insane)
random              -random number between 0 and 1
pi               -3.14159... not sure what youd use it for though

builds and patch above updated

[Droid803]

ran it and everything looks to be working properly that i've tested.
though that's just playing through and paying attention, and not an actual test mission so...that probably wasn't a very good test.

[Nuke]

nother major bug smashed, forgot to init +Difficulty Scale Type:, so if no difficulty scaling mode was selected, none would be applied (default should have been first)

[Droid803]

That explains why I have been exploding easier on my non-experimental armor types XD
Right uh, I'd love to make a test mission...but no FRED build known to peoplekind knows how to parse my armor.tbl :/

[Nuke]

build/patch updated

i dont think a test mission will do. i think what we need is a couple modular tables to add damage and armor to some retail ships and weapons. we only really need one of each. try each calculation with an obvious value to make sure calculations work. constants and memory locations wouldn't be that hard to test. difficulty scaling could be tested by creating a known situation where cutoff would result in no damage being applied if the difficulty factor was low, then just sit in front of a turret and see how long it takes to die, then change where the factor is applied and see if it makes a difference. i think tomorrow i may add some code to print out the input and output parameters of a damage computation, and see if it behaves in a predictable manor.

[Droid803]

After messing around with this a lot, I'm pretty sure the game's damage mechanics aren't broken by this
And all of the calculation types I've tested so far appear to work as they should...not 100% on that though.

[AndrewofDoom]

I've verified that Droid's statement is correct. I works just fine for me.

[Nuke]

seems this is ready for review and commit.

[Nuke]

did this ever get reviewed/committed?

[chief1983]

It appears not, and in fact even if it had, it probably would have been just after we had picked a revision to split off for RC1.  Is it something anyone was really needing in 3.6.14?  It's probably good enough for trunk now.

[Nuke]

no hurry. it was meant to fix a couple mantis issues though. but these are somewhat trivial.

[Droid803]

Hi hi, I need it.
I have a mod that doesn't run without this due to using new armor.tbl stuff, and swapping around armor.tbls (or requiring a custom build) is less than ideal.

[Droid803]

Right, er, I'm having some trouble merging with the more current revisions in trunk. I think something might be conflicting here now, and I'm not good enough at coding to figure out what.

[Nuke]

yea some more things were setup to use the armor system. i had to add an extra argument to getarmor function, just find the offending entries and put a 1.0f as the second argument.

[Droid803]

Uh so, I don't think I quite know where.
Its just that whenever I try to merge the two the build process ends up failing at one point or another.
A patch file would help

[Nuke]

k, this should be up to date as of this post. ive only added the 1.0f to the new calls to the getarmor function so that it would build. i havent looked at them to see if they need to be difficulty scaled or not. il need to work on this some more.

*edit*
wouldnt let me attatch, had to use my ftp account
get it here

[Droid803]

http://pastebin.com/03Ez0EH2

getting a CTD under very special circumstances, tracing call stack, looks like this may be related.

[The E]

Cause of this is probably a null pointer dereference.

Code: [Select]

float ArmorType::GetDamage(float damage_applied, int in_damage_type_idx, float diff_dmg_scale)
{
...
ArmorDamageType *adtp = NULL;

//Find the entry in the weapon that corresponds to the given weapon damage type
num = DamageTypes.size();
for(i = 0; i < num; i++)
{
if(DamageTypes[i].DamageTypeIndex == in_damage_type_idx)
{
adtp = &DamageTypes[i];
break;
}
}
...
//Make sure that we _have_ an armor entry for this damage type
if(adtp != NULL)
{
...
}
//check to see if we need to difficulty scale damage last
if(adtp->difficulty_scale_type == ADT_DIFF_SCALE_LAST)
damage_applied *= diff_dmg_scale;
If no valid damage type can be found, adtp will not be valid when that last line of code will be executed.

[Nuke]

i see what i did

i did this here

Code: [Select]

...
//Make sure that we _have_ an armor entry for this damage type
if(adtp != NULL)
{
...

but then at the end of the if statemend, i didnt check to see if the pointer was good:

Code: [Select]

...
//check to see if we need to difficulty scale damage last
if(adtp->difficulty_scale_type == ADT_DIFF_SCALE_LAST)
damage_applied *= diff_dmg_scale;

return damage_applied;
...

that should be inside the if statement, then there should have been a fail mode return with damage * difficulty_scale. since the function is expected to return damage with difficulty scale applied. will fix.

patch

*edit* patch brought up to 8214