Using HitByWeapon to emulate armor zones?
Moderator: Moderators
Using HitByWeapon to emulate armor zones?
Experiments with the counter have shown that most (almost all) of the damage is dealt after HitByWeapon was called, I presume this could be used to set ARMORED depending on the angle of impact so we can have tanks with stronger front armor in mods that want them. Or did everyone but me already know this?
It won't work properly with explosions caused by weapons that didn't hit the unit directly as they don't call HitByWeapon (could be minimized by resetting ARMORED a set amount of time after the impact) and it might break down if a unit takes fire from multiple directions at the same time but it should work well enough I think.
And we really need a dedicated scripting forum, this one seems to be aimed more at mods as a whole.
It won't work properly with explosions caused by weapons that didn't hit the unit directly as they don't call HitByWeapon (could be minimized by resetting ARMORED a set amount of time after the impact) and it might break down if a unit takes fire from multiple directions at the same time but it should work well enough I think.
And we really need a dedicated scripting forum, this one seems to be aimed more at mods as a whole.
- unpossible
- Posts: 871
- Joined: 10 May 2005, 19:24
sounds like something that shouldn't be hitbyweaponangle but hitbyweaponsector...where sectors are front/back/side/side/top/bottom. or just a very inaccurate calculation, assuming you can perform a simplified version without using the exact one...noone would ever want to use angles beyond very simple implementations i'd have thought.
Well, yes, but we're still stuck with hitspheres, with those you can't really test for hit areas.
I think the shield idea might work. You mean adding a shield that only extends past the hit sphere slightly in front of the unit, right? I hope projectile collision handling is accurate enough, that wouldn't work if the projectile can only detonate every n pixels (such behaviour happens with fast shots hitting the ground) and would often end up inside the hit sphere before exploding.
I think the shield idea might work. You mean adding a shield that only extends past the hit sphere slightly in front of the unit, right? I hope projectile collision handling is accurate enough, that wouldn't work if the projectile can only detonate every n pixels (such behaviour happens with fast shots hitting the ground) and would often end up inside the hit sphere before exploding.
Actually... here's how you can do it...sounds like something that shouldn't be hitbyweaponangle but hitbyweaponsector...where sectors are front/back/side/side/top/bottom. or just a very inaccurate calculation, assuming you can perform a simplified version without using the exact one...noone would ever want to use angles beyond very simple implementations i'd have thought.
Use rockunit.h's calculation of the hit... the inverse of the angle generated during rockunit's calculation is your hit angle.
However... there are two problems with all this:
1. You can only do this RETROACTIVELY. Scripts do NOT take precedence of sim-time events such as damage application.
2. Because most hits are actually area-effects being applied, I doubt if this solution would be at all accurate.
Argh: Yes but it gets called on the first frame of damage and the expanding explosions mean that the bulk of the damage is dealt on a later frame. Letting the counter display its HEALTH value when HitByWeapon is called makes it show the health it had before it got hit.
RockUnit simply reads the values given to HitByWeapon, the counter displays 0 for them when getting hit.
Sniper: Impossible, there's no way to tell what just hit you.
RockUnit simply reads the values given to HitByWeapon, the counter displays 0 for them when getting hit.
Sniper: Impossible, there's no way to tell what just hit you.
Turret speed/aiming speed. If the unit can't effectively engage things behind it, it'll take more damage from them because it'll take longer to kill them. For some units, making them simply unable to engage targets behind them might work, especially if they have a slow turn rate. For others, if you can reduce the turret aiming speed against a target in the rear arc, it would have a similar effect.
I hope I can avoid doing that. The point is to have e.g. infantry kill the tank in one shot when approaching from the side but not from the front. Now the question is if I should assume front or side armor for all hits.
Using beam lasers makes the shields stop the damage, unfortunately they'll stop all of it instead of merely reducing it. I think I'll use those with limited capacity shields for now.
Using beam lasers makes the shields stop the damage, unfortunately they'll stop all of it instead of merely reducing it. I think I'll use those with limited capacity shields for now.