Directional damage.

[Das Bruce]

How feasible is this? I mean no need to go overboard, just four directional. Just a damage modifiyer/sheild repuslor thing.

[Sean Mirrsen]

If the ARMORED sysvar will take decimal values to set the damagemodifier, it can be possible via the HitByWeapon script.

[Drone_Fragger]

...You mean hax? And dirty script tricks?

[yuritch]

4 directions can be too few. Considering that most units are likely to have equal armor on the left and right sides, we need:
1. Frontal armor
2. Side armor
3. Rear armor
4. Top armor (usually WAY lower than frontal)
5. Bottom armor (mostly useful for planes, but also for units likely to step on mines).
That gives 5 directions.

[Guessmyname]

Alternatively, if we can modify the current and max health of a unit, and HitByWeapon could detect the type of weapon the unit was hit by and calculate the piece closest to the impact (or piece of the weapon collision mesh when we get around to that)...

[Optimus Prime]

all these features are good and necessary for a game like battletech where you have got a hand full of units, but i think it gives to (atm all) spring mods really a very small improvement. Who cares when a peewee is attacked from the back, or let it be a goliath.
If all other important problems with spring are done and bugfree, the devs can have a look at damage directions, but putting work in this right now is much too early i think.
(Not that this idea is bad at all, but i see more important things to do right now)

[Warlord Zsinj]

IIRC you could do basic directional damage in OTA, so therefore it should be possible in Spring.

[Dragon45]

OTA directional damage was script-based, hacky, and expensive (in terms of CPU) meaning you couldnt have too many at once.

I could imagine this owuld be a godsend for TA:FF and GEM and SWTA:WIS etc; but all these mods need other things <hitboxes and collision detection> implemented properly first.

[Nemo]

It would also be a godsend for any mod with tanks.

It would make our lives at A&A:S a LOT easier, since right now we have all sorts of nasty calculations and armor averages to try to make up for the fact that a hit in front is the same as a hit in the back, which is the same as a shell landing on top.

[Sean Mirrsen]

It's not script-heavy, all TA units used HitByWeapon to determine the direction the unit should rock in when hit by a shell. If the ARMORED variable could set the armor of a unit according to each hit's direction (it's only a few more conditions per script call), you could modify the percentage of damage it receives according to the spot where the weapon hit. As far as I can remember, the HitByWeapon uses two angles, x and y, to determine the exact point of impact, so you can script like (-45<x<45),(45<x<135),(135<x<-135),(-135<x<-45),OR(y>100) for different damage zones. If there was some variable that would pass on the ID of the weapon that hit, it could be another way to limit effectiveness of certain weapons.

[Eaglebird]

Just as a comment, I think it'd be pretty neat (no real plus in functionality, I think, to mods), but pretty neat to have things on units that can be blown off/damaged. I just think it'd be cool to see a plane flying through the air, get slapped with falk, lose its tail, and fall to the ground in a fireball.

[Guessmyname]

doable with scripting

[Nemo]

Zwzsg's reply from TAU after I posted what Sean M wrote.

1) The argument received by HitByWeapon are normalised, that means you can get the angle, but not the radius, of the point where the shot hit. You can know which direction the impact is, but not how far from center.

2) Damage is dealt before HitByWeapon is called. So the "set ARMORED" happens too late, and will affect the next shot. Which could very well comes from another direction.

3) Some shots travel great length between each tick so the position of the point they hit isn't always closely related to the direction they come. Put a stumpy in front of you commander, and try to hit different part of the stumpy with the commander laser to see what I mean. You'll notice the point of impact "jumps" position, instead of smootly moving, when you move a little bit the attack cursor and click.

[Sean Mirrsen]

Hmm... okay, why can't we change it so the damage is dealt AFTER HitByWeapon executes? That would solve one of the problems. The problem of range is irrelevant, since what we need is direction, not range. The problem of "jumping" is something we'll have to live with, last time I tried to solve it in a project of mine, it induced lag with even one rapid-firing weapon. Although that project was done with DarkBasic...

Also, zwzsg is probably speaking of TA (I know he's the scripting guru and such), it's likely that some processes are done differently in Spring.

[Argh]

I'm sorry, but interupting the thread that executes things that need to execute super-fast in the stack in order to be accurate, such as damage done, just to call the BOS handler and have it check for a script called HitByWeapon() ... seems like a terrible idea.

I dunno whether folks have really noticed yet, but with area-effect weapons, there's a quite-noticable pause between actual shot impact, the flash, and finally, the damage dealt... and that's in the current code for this, which is reasonably fast. This is a non-trivial slowdown.

To get angular damage, we'd not only need hitboxes, but we'd have to be able to name them, and have them be able to be called by name somewhere in our mods... and then there would be the problem of area-effect weapons overlapping multiple hitboxes... gawds... that'd be a big mess. Not an insolvable one, but complicated and difficult to balance.

[Pxtl]

I'm sorry, but interupting the thread that executes things that need to execute super-fast in the stack in order to be accurate, such as damage done, just to call the BOS handler and have it check for a script called HitByWeapon() ... seems like a terrible idea.

I dunno whether folks have really noticed yet, but with area-effect weapons, there's a quite-noticable pause between actual shot impact, the flash, and finally, the damage dealt... and that's in the current code for this, which is reasonably fast. This is a non-trivial slowdown.

To get angular damage, we'd not only need hitboxes, but we'd have to be able to name them, and have them be able to be called by name somewhere in our mods... and then there would be the problem of area-effect weapons overlapping multiple hitboxes... gawds... that'd be a big mess. Not an insolvable one, but complicated and difficult to balance.

Well, I'd focus on just being able to determine the damage based on the unit vector of the damage. That vector is already used for impact handling, so just use the vector relative to the unit to calculate the damage. But yes, the only robust way to do this would be through BOS, which creates your speed issues. No mucking with hitboxes

[Sean Mirrsen]

Ghm, k. Call another script exclusively before dealing damage, something like WeaponImpact(x,y). Any wait commands in the script should have no effect. Basically it should only contain the IF clauses and "set ARMORED to X" lines, meaning it executes a maximum of 6 commands for 5-directional damage (5 IF checks, one set line), which shouldn't slow the process much. Any other weapon hit effects will be processed by the slower HitByWeapon script.

[Snipawolf]

This reminds me of that game I played a long time ago, it had hovertanks armor and its gfx were like a tank/fps fused with OTA, it was called Thunder Brigade, if this approves I might very well release a mod about that game, just cuz it was awesome

Anyways, sounds like pieces falling off could take some scripting, almost nothing you can't do with it in games like this eh?