Spring RTS Engine

Boolean so that this explosion or weapon impact does either no damage, or damage to friendly units

Another Boolean that specifies whether this explosion does damage to enemy units or not.


THIS INCLUDES AOE!

Suggested tag names:

noFriendlyFire
noEnemyFire

Atm most of us are trying to achieve this via gadgets and the like but said gadgets are unreliable. Besides, there should be a switch in the engine for it.

Edit: This also goes for unit death explosions as well as weapons assigned to units.

how are gadgets unreliable?

UnitPreDamaged should handle this fine

http://pastebin.com/Tw5Cy8Ya

Works for units weapons, not for unit death explosions.

http://pastebin.com/vdhbT2RH

Doesn't work at all.


Plus, these are tags that should be in the engine weapondefs anyway.

Death explosion
=> Attacker is dead
=> Attacker parameters are nil (attackerID, attackerDefID, attackerTeam)
=> Your gadgets function doesn't fire

WeaponID works just fine however, so your gadget would turn into something like...

noFriendlyFireWeapons = {WeaponDefNames[...].weaponDef = true, ...}

Which is a bit more hassle than just putting a tag on the weapon (Unless weapons have customparams?)

You want deaths to damage enemies and features, but not friendlies? Why have death explosions do any damage at all then? I guess it is important for damaging nearby enemies when your units die?

Kamikaze units that don't chain.

Also, why doesn't the noenemy fire one work? That one is a massive pain in the cock.

Thanks for explaining that niobium. Makes a lot mroe sense now.

Niobium wrote:Death explosion
=> Attacker is dead
=> Attacker parameters are nil (attackerID, attackerDefID, attackerTeam)
=> Your gadgets function doesn't fire

This is bad. Spring should be fixed so attackerDefID and attackerTeam are still there even if the unit is dead.

You can set the kamikaze weapon to be a watchweapon, and then:
...I think that will give you a valid UnitID on death. The alternative is to manually cause an explosion in COB via emit-sfx during the death sequence before returning.

This wouldn't solve the scenario where a regular unit fires a weapon, dies before it reaches its target and again unitpredamaged would fail to give the parameters.

CarRepairer wrote:Spring should be fixed so attackerDefID and attackerTeam are still there even if the unit is dead.

...would solve it. Would it be difficult to fix?

This wouldn't solve the scenario where a regular unit fires a weapon, dies before it reaches its target and again unitpredamaged would fail to give the parameters.

True, but it should fix Forb's immediate problem.

As for the fix, maybe just store the team ID? I can see all sorts of problems cropping up if dead unit IDs are still considered to be valid.

CarRepairer wrote:This wouldn't solve the scenario where a regular unit fires a weapon, dies before it reaches its target and again unitpredamaged would fail to give the parameters.

CarRepairer wrote:Spring should be fixed so attackerDefID and attackerTeam are still there even if the unit is dead.

...would solve it. Would it be difficult to fix?

Units dying before shots hit is common enough that it makes it impossible to implement team-based or unitdef-based special damages consistently. While unitdef-based things could be handled by unique weapondefs through a troublesome process, even simple team-based damages like 'Team X has +10% damage' are impossible, especially so when the damage modifications are large.

Imo this is bug (in that it causes buggy inconsistent behavior), but looking at the spring code it doesn't appear to be a super easy fix of tacking on some parameters in one place. It seems like it would require all projectiles to get ownerTeam/ownerDef on creation , and then passing those values onto created explosions/damage, which would then pass them into the damage functions. Basic changes, but quite a few of them.

Argh wrote:

I can see all sorts of problems cropping up if dead unit IDs are still considered to be valid.

Not unitID, I just said unitDefID (attackerDefID + attackerTeamID).

Niobium wrote:Imo this is bug (in that it causes buggy inconsistent behavior), but looking at the spring code it doesn't appear to be a super easy fix of tacking on some parameters in one place. It seems like it would require all projectiles to get ownerTeam/ownerDef on creation , and then passing those values onto created explosions/damage, which would then pass them into the damage functions. Basic changes, but quite a few of them.

Thanks for the explanation. I hope this could be resolved. Even if it's just teamID that is maintained, it would suffice (teamID + weaponID).

Perhaps a better method would be to have dead units leave behind a data-tombstone that contains some simple information, and add a method GetDeadUnitInfo(unitID) that returns as subset of the live unit's info. In this case, that would happen transparently in the background and the DeadUnitINfo's DefID and TeamID would be passed into the predamaged handler?

edit: too bad we don't just get an invalid AttackerID instead of a "nil" one. Then you could simply cache all the Unit IDs on unit creation, storing their team and unitdefID there. That collection would logically outlive the units, so you could use that to check the info of dead units.

There are tombstones, they just get cleared after each frame.

It would be nice for a projectile to give at least some of the information even after a unit's long gone.

Hmm. So, does Explosion() return nil for the ownerID, or a number, if the firing Unit is dead?

If the second case, and you want a tombstone keeper, that's a fairly routine Gadget- we could put Units in an array, with dead/alive states, and sync that with weapons instead of querying Spring. I don't think there's a need for an engine fix on this, frankly:

Pxtl: Don't forget unitIds get reused!

True. What's the rationale behind that, btw? Seems unlikely we'd ever hit the limit on that number...

@zwzsg - well, that depends on teh unitID reuse algorithm. If it keeps going upwards until wraparound and then grabs the next available one, the UnitID should last long enough for any death explosion. Plus, if you're using an "on unit create" approach I mentioned, you would at least *know* when a UnitID was reused, and could keep track of all uses of the unitID.

But either way, you still need AttackerID to be passed in UnitPreDamaged instead of Nil to take that approach.

unitIds for new units are chosen randomly out of the currently unused IDs. this is to make some forms of cheating harder.