[Droid803]

I've mentioned it once on IRC, but I guess I'll mention it again.

As it stands right now, difficulty-based damage scaling is applied before armor.tbl calculations.
While this is fine for things like multiplicative, it has some...unfortunate implications for Cutoff/Instant Cutoff/Reverse Cutoff/Instant Reverse Cutoff.

It means that they're useless on the player ship.

Since they operate on a fixed value, if you have a cutoff of say 20, and the player with that armor type is getting hit by a weapon that does 25 damage, it should do the full 25. This is the case on Insane, where there is no damage reduction.

However, on say very easy, the player is only actually receiving 5 damage (due to the 0.2x damage multiplier for the difficulty), and thus the player is invulnerable to the projectile that should be dealing damage to them.

Would it be possible to alter the damage calculation algorithm so that difficulty-base damage reduction is applied last?
That would make the most sense, even for "additive" and "subtractive", and would make the cutoff type calculations not fail on the player ship. Unless there is a reason why difficulty based damage modifications must be applied first. This change should make difficulty based damage scaling equivalent to a base HP increase for the player, and shouldn't have any effect on retail that I know of.

(P.S. can I have a reverse cutoff variant that reduces damage above +value to +value rather than 0, that would be lovely )

[Aardwolf]

I think this issue ought to be addressed! Someone please address this issue.

[MatthTheGeek]

you most fix it

[Nuke]

this is definately something to consider. being able to flag in each armor type with something like this:
+scale difficulty: first/last/never/custom
would help a lot. all are self explanatory except custom. using custom you can plug the difficulty factor into your custom equation in any way you see fit.

[Goober5000]

This is a good request.  I'd fix it if I knew anything about armor.tbl...

I suggest Mantising it, since it qualifies as a bug fix.  Bug fixes do not belong in the forum.

[Droid803]

Alright, I'll put it onto Mantis.

[ShivanSpS]

Since they operate on a fixed value, if you have a cutoff of say 20, and the player with that armor type is getting hit by a weapon that does 25 damage, it should do the full 25. This is the case on Insane, where there is no damage reduction.

Wait, what? that means in Insane i get the same damage from the same weapon in a Ursa than in a Perseus?

[Droid803]

I mean the following:
Ship A1 has armor with calculation type +cutoff: 20, with the old calculation chain.
Ship A2 has armor with calculation type +cutoff: 20, with the new calculation chain. (Here)
Ship B1 has no armor

Weapon X does 25 damage

On Insane,
Damage taken by Ship A1 = 25*1 = 25 (>20) = 25
Damage taken by Ship A2 = 25 (>20) = 25*1 = 25
Damage taken by Ship B1 = 25*1 = 25

On (very?)Easy,
Damage taken by Ship A1 = 25*0.2 = 5 (<20) = 0
Damage taken by Ship A2 = 25 (>20) = 25*0.2 = 5
Damage taken by Ship B1 = 25*0.2 = 5

The Ursa and Perseus both have no armor by default, so they would both behave like Ship B2...

this is regarding armor.tbl.


I'd appreciate if someone would give me some feedback about my patch http://www.hard-light.net/forums/index.php?topic=78211.0, even if its to yell at me and to tell me to never mess with FSO again, because on my end, this has definitely changed behavior from A1 to A2.

[ShivanSpS]

But its fine that on Insane EVERY ship behaves like it has no armor? thats whould explain why the AI dies so easily on heavy ships too.

It just dont seems to be fine to just NULL the armor on all ships, increasing damage and armor reduction is one thing, but 0 armor on all ships? :/

[Aardwolf]

@ShivanSPS: Maybe you're confusing armor with hitpoints?

Edit: in retail, there was no "armor"-based damage reduction

[Nuke]

I mean the following:
Ship A1 has armor with calculation type +cutoff: 20, with the old calculation chain.
Ship A2 has armor with calculation type +cutoff: 20, with the new calculation chain. (Here)
Ship B1 has no armor

Weapon X does 25 damage

On Insane,
Damage taken by Ship A1 = 25*1 = 25 (>20) = 25
Damage taken by Ship A2 = 25 (>20) = 25*1 = 25
Damage taken by Ship B1 = 25*1 = 25

On (very?)Easy,
Damage taken by Ship A1 = 25*0.2 = 5 (<20) = 0
Damage taken by Ship A2 = 25 (>20) = 25*0.2 = 5
Damage taken by Ship B1 = 25*0.2 = 5

The Ursa and Perseus both have no armor by default, so they would both behave like Ship B2...

this is regarding armor.tbl.


I'd appreciate if someone would give me some feedback about my patch http://www.hard-light.net/forums/index.php?topic=78211.0, even if its to yell at me and to tell me to never mess with FSO again, because on my end, this has definitely changed behavior from A1 to A2.

does your patch allow a modder to explicitly place the difficulty damage scaler in their equation chain? applying a single stage computation is one thing but if you have several, it may be neccisary to place the damage scaler at a specific spot for the equation (or a few spots) to work right. i do think a post scale would be a good default though.

aside from that i kinda wish there were additional computations. all 4 cutoff operations cut to zero. the low cuttoffs are fine, but the reverse cuttoffs make less sense. i can see them being used in something like feedback armor that becomes stronger while being damaged. but what if i want to plug in a different equation if the damage is over a certain level then you kind of loose the damage information, you can add some damage post cutoff to somewhere in the neighborhood of the cutoff and do extra maths. but then you loose proportionality. it would be cool if you could substitute +value: with flags that represent internal values. like +difficulty scale or +damage which substitute that value for the explicit value. i kinda wish you could also store the current damage, and then be able to call it up with +stored value. to break it down i want this:

new calculations
$store:       ;sticks current value into a memory location for later use, say after a cutoff operation
+value:      ;location (cant really imagine needing more than a few possible locations)
$set:          ;simply means damage = value
+value:
$cap:         ;if damage is more than value, damage = value
+value:
$instant cap: ;cap is applied and computations cease
+value:

constants that may be used in place of +value:
+input damage              ;the value you get before computations are applied
+difficulty scale             ;difficulty scale factor
+percent hitpoints         ;percentage of hull/shield segmeny/subsystem hitpoints remaining (can be used to make damaged armor more or less effective, such as reactive armor)
+random                      ;random number between 0 and 1, for chaos insertion
stored locations
+stored location: #        ;use value from memory location index (if no value was stored yet, use 0)

adding these features would greatly expand the system and allow more complex damage modelling. another option would be $default difficulty scaling: pre/post/none (use none to define it explicitly with +difficulty scale), which ive brought up before. simply moving the scaling with no other option may cause other issues with other damage setups.

[Droid803]

I'd love to implement those but i'm way too n00b at coding for FSO to know where actual armor calculations are held. XD

[Nuke]

i might take a look at it one day when i feel like coding. seems a couple of those features (like constants and storage locations) would make the system exponentially more useful.

[Nuke]

seems wmc was nice to me and left step by step instructions to adding damage types in the code, looks like i may be able to add some of that stuff. i still dont know how easily i will be able to substitute +value: tags with constants. but i can at least make the system a bit more versatile.

*edit*
looks like load and store operations are trivial

*edit again*

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 an assert), 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
add_random        ;creates a random number between 0 and +value: and adds it to the damage. (negative numbers result in subtraction)
multiply_random  ;if +value: is positive, creates a random number between 0 and +value: and multiplies it with damage. if +value is negative, creates a random number between +value: * -1 and 1.
random                   ;random number between damage and +value: (not available in this patch/build)
apply difficulty         ;applies difficulty in one of two ways. if value is 0 or less, it will multiply damage by difficulty scaling factor, otherwise it will replace damage with the scaling factor (useful if youve stored damage)

you can use this instead of value (you have to use one or the other but not both)
+stored value: ;# of storage location. this lets you use a stored value in place of an explicit value

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)

patch added, builds uploading. so far i havent tested it.

*edit yet again*
*builds updated*
builds available

things to look for:
make sure computations work
thoroughly test load and store operations
 test invalid indices (should throw assert 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)
make sure i didnt break the game's damage mechanics

lol, my patch is pi kb
*patch removed, see below for a newer one*

[Nuke]

i decided to drop both randoms for some other features

now a simple +random: returns a random number between the current damage and the value. while this seems like a downgrade, its not, because of a new feature.

you can now substitute +value: tags with +stored value: tags. what you do is you use the +store: calculation to put the current damage into a memory location (number defines which), set damage to 0 with +set: and then use +random:. and if you wanted to multiply that by damage you would just do a +multiply: with +stored value: (location number). you can get the result of either of the old random calculations in this way.

anyway i haven't upped any new builds yet, im gonna give the code another once over to kill any bugs i may have introduced. ive also working on making it possible to define where difficulty scaling is done. ive added enough code to parse a +Difficulty Scale Type: tag, which accepts "first", "last", or "manual" (default is first, the original behavior of the system) and most of the time you will probably want "last", but the 3rd option will allow you to define it manually. gonna have to write more code though. keep an eye on this post for build updates.

features implemented, see previous post. patch/builds available over here.
builds for lazy people

[Alan Bolte]

+percent hitpoints         ;percentage of hull/shield segmeny/subsystem hitpoints remaining (can be used to make damaged armor more or less effective, such as reactive armor)

If this were implemented, could it be used to emulate the damage portion of the "big damage" ship flag, i.e. prevent a ship from being reduced to less than x% of its total hitpoints? If so, it would be an excellent way to solve the common FREDing question of how to make something reliably unkillable without making it invulnerable. Sure, you can switch invulnerable on if it gets below x hitpoints, but AFAIK that won't prevent a sufficiently large damage value from bypassing the limit.

[Nuke]

+percent hitpoints         ;percentage of hull/shield segmeny/subsystem hitpoints remaining (can be used to make damaged armor more or less effective, such as reactive armor)

If this were implemented, could it be used to emulate the damage portion of the "big damage" ship flag, i.e. prevent a ship from being reduced to less than x% of its total hitpoints? If so, it would be an excellent way to solve the common FREDing question of how to make something reliably unkillable without making it invulnerable. Sure, you can switch invulnerable on if it gets below x hitpoints, but AFAIK that won't prevent a sufficiently large damage value from bypassing the limit.

thats the only one of the suggested features i haven't implemented yet. im not really sure how to pull this off yet. i was thinking of using it to simulate reactive armor, which becomes less effective as it is damaged. but yea you could just as easily make armor which is harder to damage as it gets low. id love to expose more bits of data to the armor system, more information about the ship and the damage, but you could quickly turn the code to mush by doing this kinda thing without restraint.

[Tomo]

If this were implemented, could it be used to emulate the damage portion of the "big damage" ship flag, i.e. prevent a ship from being reduced to less than x% of its total hitpoints? If so, it would be an excellent way to solve the common FREDing question of how to make something reliably unkillable without making it invulnerable.

You are aware that this is what Ship-Guardian and Ship-Guardian-Threshold are for?
Ship-Guardian was Retail behaviour!

The first prevents a ship from being damaged below 1%, the second allows a defined value if you prefer.

There is also the same thing for specific subsystems.

http://www.hard-light.net/wiki/index.php/Ship-guardian

[MatthTheGeek]

No, that's not what Ship-Guardian and Ship-Guardian-Threshold are for. They are supposed to turn invulnerable a ship after a certain threshold. What Alan Bolte was suggesting was something that progressively makes a ship more and more resistant as they take damage, instead of making them magically invulnerable. That way they still are impossible to destroy, but the effect is much less obvious than guardianing.

[chief1983]

Isn't that what happens with capital ships against most fighters weapons?