Please add a weapondef tag for friendly fire
Moderator: Moderators
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Please add a weapondef tag for friendly fire
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.
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.
- bobthedinosaur
- Blood & Steel Developer
- Posts: 2700
- Joined: 25 Aug 2004, 13:31
Re: Please add a weapondef tag for friendly fire
how are gadgets unreliable?
Re: Please add a weapondef tag for friendly fire
UnitPreDamaged should handle this fine
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Please add a weapondef tag for friendly fire
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.
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.
Re: Please add a weapondef tag for friendly fire
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?)
=> 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?)
- bobthedinosaur
- Blood & Steel Developer
- Posts: 2700
- Joined: 25 Aug 2004, 13:31
Re: Please add a weapondef tag for friendly fire
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?
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Please add a weapondef tag for friendly fire
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.
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.
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Please add a weapondef tag for friendly fire
This is bad. Spring should be fixed so attackerDefID and attackerTeam are still there even if the unit is dead.Niobium wrote:Death explosion
=> Attacker is dead
=> Attacker parameters are nil (attackerID, attackerDefID, attackerTeam)
=> Your gadgets function doesn't fire
Re: Please add a weapondef tag for friendly fire
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.
Code: Select all
function gadget:Explosion(weaponID, px, py, pz, ownerID)
if(weaponID == myNiftyWeapon) then
teamID = Spring.GetUnitTeam(ownerID)
return false end
end
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Please add a weapondef tag for friendly fire
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.
...would solve it. Would it be difficult to fix?CarRepairer wrote:Spring should be fixed so attackerDefID and attackerTeam are still there even if the unit is dead.
Re: Please add a weapondef tag for friendly fire
True, but it should fix Forb's immediate problem.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.
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.
Re: Please add a weapondef tag for friendly fire
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.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.
...would solve it. Would it be difficult to fix?CarRepairer wrote:Spring should be fixed so attackerDefID and attackerTeam are still there even if the unit is dead.
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.
- CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Please add a weapondef tag for friendly fire
Not unitID, I just said unitDefID (attackerDefID + attackerTeamID).Argh wrote:I can see all sorts of problems cropping up if dead unit IDs are still considered to be valid.
Thanks for the explanation. I hope this could be resolved. Even if it's just teamID that is maintained, it would suffice (teamID + weaponID).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.
Re: Please add a weapondef tag for friendly fire
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.
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.
Re: Please add a weapondef tag for friendly fire
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.
It would be nice for a projectile to give at least some of the information even after a unit's long gone.
Re: Please add a weapondef tag for friendly fire
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:
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:
Code: Select all
local unitList = {}
function gadget:UnitCreated(unitID, unitDefID, teamID, builderID)
unitList[unitID] = {dead = false, deadTimes = 0}
end
function gadget:UnitDestroyed(unitID, unitDefID, teamID, attackerID)
unitList[unitID].dead = true
end
function gadget:GameFrame(f)
if f % 33 < 0.1 then
for i,k in ipairs(unitList) do
if k.dead = true then
if k.deadTimes > 2 then
unitList[i] = nil --clear this location
else
k.deadTimes = k.deadTimes + 1
end
end
end
end
end
function gadget:Explosion()
--check for match with dead / living here, if yes then set something up for UnitPreDamaged()...
end
Re: Please add a weapondef tag for friendly fire
Pxtl: Don't forget unitIds get reused!
Re: Please add a weapondef tag for friendly fire
True. What's the rationale behind that, btw? Seems unlikely we'd ever hit the limit on that number...
Re: Please add a weapondef tag for friendly fire
@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.
But either way, you still need AttackerID to be passed in UnitPreDamaged instead of Nil to take that approach.
Re: Please add a weapondef tag for friendly fire
unitIds for new units are chosen randomly out of the currently unused IDs. this is to make some forms of cheating harder.