Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Nuke on September 15, 2011, 11:47:28 am
-
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 (http://nukedspace.fsmods.net/armor builds.7z)
[attachment deleted by ninja]
-
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
-
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.
-
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)
-
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 :/
-
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.
-
After messing around with this a lot, I'm pretty sure the game's damage mechanics aren't broken by this :D
And all of the calculation types I've tested so far appear to work as they should...not 100% on that though.
-
I've verified that Droid's statement is correct. I works just fine for me.
-
seems this is ready for review and commit.
-
did this ever get reviewed/committed?
-
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.
-
no hurry. it was meant to fix a couple mantis issues though. but these are somewhat trivial.
-
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.
-
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.
-
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.
-
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 :P
-
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 (http://nukedspace.fsmods.net/armorpatch2.patch)
-
http://pastebin.com/03Ez0EH2
getting a CTD under very special circumstances, tracing call stack, looks like this may be related.
-
Cause of this is probably a null pointer dereference.
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.
-
i see what i did
i did this here
...
//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:
...
//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 (http://nukedspace.fsmods.net/armor stuff 8214.patch)
*edit* patch brought up to 8214
-
Tested compile on Mac, it at least builds against latest trunk (r8627). Haven't given it any more fulsome testing.
Patch that will apply cleanly against that revision attached -- no operative changes.
[attachment deleted by a ninja]
-
Using the last posted patch, I was able to get confirmation of compile on OS X, and confirmed compile on Windows. Still need to test compiling under Linux.
Nothing jumps out at me as needing correction, and my tests with the MediaVPs and Blue Planet did not produce any odd behaviours.
Assuming that Linux has no issues, I'll have this committed by Tuesday afternoon (It's now Monday for me right now) unless anybody else can come up with anything that needs correction.
I attached a mildly altered version that I'll be committing, baring any issues.
[attachment deleted by a ninja]
-
Committed r8629
Would still like more feedback regarding this, but honestly it's been long enough that anything potentially still outstanding on it is probably minor enough or fringe enough that it can be dealt with while live.
-
it did make me get an understanding for how ridiculously complicated the engines damage computations are. it gave me headaches. so glad its finally in.
-
YES. YES. YES.
/M. Bison.
-
hurr durr
How many people tested this patch with this in mind? :p
make sure i didnt break the game's damage mechanics
This revision is apparently the cause of the recently discovered difficulty bug.
-
i figured with the big red letters it would have been at the top of everyone's list.
the main feature/bugfix of the patch was the ability to tell the game when to do the damage calculations for difficulty scaling. the difficulty scaling was done before the armor-damage calculations originally. so i added +Difficulty Scale Type:, which can be set to one of 3 things "first" (default), "last" or "manual". if set to manual, then no difficulty scaling would be done (new features gave you access to the scaling factor and you could use explicitly it in your calculations). if this mode was somehow defaulting to manual it would explain why this is happening. but thats just a theory. il take a look at this tomorrow when my brain isnt tired and the contents of my freespace2 folder is brought up to date.
-
hurr durr
How many people tested this patch with this in mind? :p
make sure i didnt break the game's damage mechanics
This revision is apparently the cause of the recently discovered difficulty bug.
Actually, I believe this problem was commented on several times but was commented on as a change in the AI response. Which was generally blown off with the comment that there had been no change to the AI and no further investigation was performed.
-
Sounds like groupthink. Can you point to specific posts or quotes so that we can learn to avoid falling into those traps in the future?
-
hurr durr
How many people tested this patch with this in mind? :p
make sure i didnt break the game's damage mechanics
This revision is apparently the cause of the recently discovered difficulty bug.
Actually, I believe this problem was commented on several times but was commented on as a change in the AI response. Which was generally blown off with the comment that there had been no change to the AI and no further investigation was performed.
Sounds like groupthink. Can you point to specific posts or quotes so that we can learn to avoid falling into those traps in the future?
No, actually, last time Macfie brought this up, I told him the AI shouldn't have been changed and if he was observing change it was a serious issue that needed to be investigated.
Let me go get the specific quotes.
e: actually apparently i just trailed off like a slackjawed moron http://www.hard-light.net/forums/index.php?topic=83485.msg1669976#msg1669976
-
Hey, if I had a nickel for every time I did that, I'd...
So when this bug gets sorted out, would it be grounds for a re-release of 3.6.16 final? Because I feel like the last thing we want to be doing is pointing newbies at an official version that's liable to slaughter them on a regular basis.
(Meanwhile, like a masochistic idiot, Mongoose keeps using this build...)
-
Higher difficulty levels probably aren't having as big a difference, so our veteran players probably didn't notice anything with it. But we'll be version bumping, not trying to release a second 3.6.16. Probably expect a 3.6.16.1 as soon as this is fixed.