OnDamageShields

[george moromisato]

<OnDamageShields> for weapons can return two possible result types:

If it returns Nil, then full damage is passed to the shield and processed normally.

If it returns an integer, shields are skipped completely and the integer is the amount of damage passed to armor.

In RC5 I would like to make the following additions. First, the event will get three new arguments:

aShieldHP: This is the current number of HPs that the shields have.

aShieldDamageHP: This is the number of HPs that the shields will decrease by under normal circumstances (after damage adj, etc.)

aArmorDamageHP: This is the number of HPs that will pass through to armor.

Secondly, the code in <OnDamageShields> can return a list with two integers: the first is a new value for aShieldDamageHP; the second is a new value for aArmorDamageHP.

Question 1 for Betelgeuse and Atarlost (and anyone else who might use this event): Is this a reasonable design? I.e., does this give you the proper control to create the weapons you're interested in?

Question 2: How should I handle reflection? My proposal is this: if the damage will be deflected by the shields, then aArmorDamageHP will be set to the string "reflect". (And you'll be able to return "reflect" as the second value in the return list).

NOTE: I want to keep this change as simple as possible--I can imagine 100 different ways to improve this, but all add more complexity and more code. And if it takes me too long to code, then I'd rather defer it until 1.1.

[Atarlost]

Um. Looks good mostly. I think reflection may need to be a seperate flag. The way I read it now if the shield would reflect because of its own traits there will be nothing that gives you the damage because aShieldDamageHP will be "reflect" and aArmorDamageHP will be 0. This means that while you can make a shot that wouldn't normally be reflected be reflected you can't make a shot that would be reflected not be reflected. Using a "reflect" string in place of damage is fine for a return, but not so great for an argument.

Apart from that problem I don't see anything I particularly want to do that it won't.

[Betelgeuse]

looks good,

Will the first argument need to be passed aDamageHP or aShieldDamageHP in the standard damage case? (ie is the event before or after adjustment)

other than that it looks perfect for my purposes. (mainly controlling damage done by the weapon with data on the shot)

just to be clear are these the globals that will be in RC5's onDamageShields

aShieldHP, aShieldDamageHP, aArmorDamageHP, aDeviceItem, aDamageHP, aCause

Will gSource be in?

[Atarlost]

gSource is in in RC4. I've already used it for a mod.

[george moromisato]

Um. Looks good mostly. I think reflection may need to be a seperate flag. The way I read it now if the shield would reflect because of its own traits there will be nothing that gives you the damage because aShieldDamageHP will be "reflect" and aArmorDamageHP will be 0. This means that while you can make a shot that wouldn't normally be reflected be reflected you can't make a shot that would be reflected not be reflected. Using a "reflect" string in place of damage is fine for a return, but not so great for an argument.

Apart from that problem I don't see anything I particularly want to do that it won't.

I hate to say this, because it adds more variables, but I think we'll need the following:

aShieldHP
aShieldDamageHP
aArmorDamageHP

aShieldReflect
aOriginalShieldDamageHP
aOriginalArmorDamageHP

If the shield didn't reflect the shot, then aShieldReflect is Nil and aOriginal* are undefined.

If the shield reflected the shot, then:

aShieldReflect = "reflect"
aShieldDamageHP = 0
aArmorDamageHP = 0
aOriginalShieldDamageHP = shield damage if not reflecting
aOriginalArmorDamageHP = armor damage if not reflecting

This is important because I can imagine future cases where some shields take damage to reflect (or leak damage to armor, even if they reflect). In those cases, aShieldDamageHP and/or aArmorDamageHP would be non-zero (but still different from aOriginal*).

[alterecco]

That looks very good...

My only comment would be that I can not see why the aOriginal* would not be set... It would make more sense to me if they were just equal to their end values if there was no reflection in the equation.

If you do want to keep them without a value, then at least set them to Nil, so that we don't get errors if we use them.

That a shield would take damage or only reflect partial damage makes a lot of sense to me.

[george moromisato]

looks good,

Will the first argument need to be passed aDamageHP or aShieldDamageHP in the standard damage case? (ie is the event before or after adjustment)

other than that it looks perfect for my purposes. (mainly controlling damage done by the weapon with data on the shot)

just to be clear are these the globals that will be in RC5's onDamageShields

aShieldHP, aShieldDamageHP, aArmorDamageHP, aDeviceItem, aDamageHP, aCause

Will gSource be in?

If you don't want to change the damage to shields or armor (and ignoring reflection for now) you should return:

(list aShieldDamageHP aArmorDamageHP)

In other words, both have already been adjusted for damage type, etc. and will not be adjusted further.

gSource is in RC4 and it is the object that got hit.

If you are looking for the missile object, then you can generally find it in aCause.

The event also gets: aAttacker (the obj that fired the shot); aOrderGiver (the player, if aAttacker was an auton or a wingman); aHitPos; aHitDir; aDamageType; aWeaponType.

[Betelgeuse]

This is important because I can imagine future cases where some shields take damage to reflect (or leak damage to armor, even if they reflect). In those cases, aShieldDamageHP and/or aArmorDamageHP would be non-zero (but still different from aOriginal*).

If you wanted to do that wouldn't you need to return three things not two?

(shieldDamage armorDamage reflectString)

Otherwise you can't make reflecting weapon that leaks some to the armor.

I am fine with the restriction myself just want to point it out.

[george moromisato]

If you wanted to do that wouldn't you need to return three things not two?

You're totally right and that's what I ended up having to do. OnDamageShields can now return the following different values:

Nil = Process damage normally

{integer} = Skip shields and pass damage to armor

'reflect = Reflect damage (shield takes no damage, none leaks to armor)

(list {shieldDamage} {armorDamage}) = Shields drop by shieldDamage hp; armorDamage is passed through to armor; does not reflect.

(list {reflect} {shieldDamage} {armorDamage}) = Same as above, but reflect shot if {reflect} = 'reflect.

I think this gives you a lot of control. For example:

If you just want to let shields process things normally, you can return Nil or you can return:

(list aShieldReflect aShieldDamageHP aArmorDamageHP)

If you want shields to take double damage from your shots, you can returns:

(list aShieldReflect (multiply aShieldDamageHP 2) aArmorDamageHP)

If you want your shots to never reflect, you can return (following alterecco's advice):

(list Nil aOriginalShieldDamageHP aOriginalArmorDamageHP)

Etc.

[Betelgeuse]

so we will be able to make a weapon that is always reflected off of shields 8)

sounds cool. Would be useful in enemy swarms.

Does reflected shots keep the data that was on the original shot?

Then we can make a shot that does less damage on each reflection.

[george moromisato]

Does reflected shots keep the data that was on the original shot?

Then we can make a shot that does less damage on each reflection.

Unfortunately, no. The reflection generated by the shield code is a new object.

But if you want, you can do your own reflection from inside <OnDamageShields>. Just repoint the aCause object (or create a new one with sysCreateWeaponFire).

[Betelgeuse]

But if you want, you can do your own reflection from inside <OnDamageShields>. Just repoint the aCause object (or create a new one with sysCreateWeaponFire).

Will repointing the aCause make it so it doesn't get destroyed?

[george moromisato]

Will repointing the aCause make it so it doesn't get destroyed?

No, good point. That won't work.

[Betelgeuse]

Will repointing the aCause make it so it doesn't get destroyed?

No, good point. That won't work.

ok will just use sysCreateWeaponFire. Does that trigger onFireWeapon? and if so does onFireWeapon run and return before the sysCreateWeaponFire returns?

emulating lifetime is easy enough I just need to know what data to set when. (data on the shot I mean)