A bug with armour that is revealed through use of the LTC_Power XG type.
If the players armour is 0% and you use LTC_Power XG to give the player armour, the armour counter will not go down when you get shot.
If the players armour is 1%+ when the LTC_Power XG is used or the player picks up an armour pickup after the LTC_Power XG is used, the armour counter will go down as normal when you get shot.
#1 Updated by danij over 13 years ago
This is due to the rather bizarre handling of armour in DOOM. In P_DamageMobj it can be seen that a player is only considered to have armor if player_t::armorType is non-zero, regardless to the actual value of player_t::armorPoints.
As XL_DoPower does not currently set player_t::armorType this explains why the correct behaviour is exhibited only if the player has previously been given/collected armor.
The best solution to this problem would be for XL_DoPower to call P_GiveArmor, specifying both the type and the number of points to be given. However, how to do this in a backward-compatible fashion? Given that XL_DoPower can give an arbitrary number of armor points how to determine which type of armor is being given when (currently) ltc_power does not provide that information?
1) Enhance ltc_power so that the type of armor being given can be specified as an iparm.
2) If an armor type is not specified (type == 0) use the following logic to determine type:
If rand(minDelta, maxDelta) < armorPoints0
type = Green armor
type = Blue armor
Or should we instead default to Green armor always, if the armor type is not specified?
#2 Updated by vermil over 13 years ago
I agree that expanding ltc_power to include optional field(s) a mod maker can use to set a certain armour type would be a very useful expansion of the line for Doom and Heretic Doomsday modding.
There isn't really anything to tip the balance in favour of either armour type when it comes to deciding which should be given if the player has 0 armour when they cross an ltc_power line that doesn't have a field(s) manually setting the type. (I'm assuming implementation of the additional field(s) mentioned).
But personally, I would probably go with type1 in the above circumstance.