Condition of "at war" or "at peace"

[otyugh]

Hey, still another naive question that might be trivial.

I try to raise an alert when any unit of the player (me) is dealing damage ton another unit that is not the player's property (friendly fire or ctrl+d on my own units, shouldn't be taken into account).

I don't find out, widget:UnitDamaged seem to only report damages on the player and not anybody else -unitTeam is everytime == Spring.GetMyTeamID()-.

[Jools]

Hmmm, I'm not sure I understood correctly: you want to have a report when any of your own units is shooting at a not-allied unit. Correct?

Widgets only have information of what happens within your line of sight. That means you can have a report when your peewee shoots at enemy peewee, but not when your bertha hits enemy base.

Yes, when you have LoS on enemy it goes like this:

Code: Select all

widget:UnitDamaged(unitID, unitDefID, unitTeam, damage, paralyzer, weaponDefID, projectileID, attackerID, attackerDefID, attackerTeam)

check when attackerTeam equals your own team, and attackerID will be your UnitID that deals damage.

[otyugh]

That my actual whole problem.
Consider the following :

Code: Select all

function widget:UnitDamaged(unitID, unitDefID, unitTeam, damage, paralyzer, weaponDefID, projectileID, attackerID, attackerDefID, attackerTeam)
	if(attackerTeam==nil) then
		attackerTeam='?'
	end
	Spring.Echo("attacker :"..attackerTeam.." victim:"..unitTeam)
end

What I get in a melee pewee fight early on is a bunch of

"attacker ? victim 0"

, 0 being my teamID. Oddly I was getting better results using "UnitLastAttacker" on unitID.


Basically damage are only perceived from my point of view, so a pewee can fire on foreign ressources building directly without any chance to trigger UnitDamaged.


I was wondering if there was a way to work around this. But the functions around projectiles does not seem not to cover this, althought I'm not 100% sure.

[Silentwings]

LuaUI is only able to see things from your own point of view, to work around that you need help from a gadget.

[Jools]

That my actual whole problem.
Consider the following :

Code: Select all

function widget:UnitDamaged(unitID, unitDefID, unitTeam, damage, paralyzer, weaponDefID, projectileID, attackerID, attackerDefID, attackerTeam)
	if(attackerTeam==nil) then
		attackerTeam='?'
	end
	Spring.Echo("attacker :"..attackerTeam.." victim:"..unitTeam)
end

What I get in a melee pewee fight early on is a bunch of

"attacker ? victim 0"

, 0 being my teamID. Oddly I was getting better results using "UnitLastAttacker" on unitID.


Basically damage are only perceived from my point of view, so a pewee can fire on foreign ressources building directly without any chance to trigger UnitDamaged.


I was wondering if there was a way to work around this. But the functions around projectiles does not seem not to cover this, althought I'm not 100% sure.

Try with this code:

Code: Select all

function widget:UnitDamaged(unitID, unitDefID, unitTeam, damage, paralyzer, weaponDefID, projectileID, attackerID, attackerDefID, attackerTeam)
	if attackerTeam and  weaponDefID > 0 then
		Spring.Echo("attacker :"..attackerTeam.." victim:"..unitTeam)
	end	
end

That will filter out a bunch of cases with indirect damage, such as unit damaged by debris, collateral damage, fire, water, fall damage, etc etc.

But the point is as silentwings says, it cannot catch all cases when your unit damages enemy, because in the game, this information is not present. Even with a gadget you cannot catch the case when a kamikaze unit blows itself up and kills enemy stuff.

But it will work as a way of telling when your units are in peace or in a firefight. But those 'empty' values you get are when the the enemy is damaged by other means than a direct hit by the peewees gun.

[FLOZi]

But the point is as silentwings says, it cannot catch all cases when your unit damages enemy, because in the game, this information is not present. Even with a gadget you cannot catch the case when a kamikaze unit blows itself up and kills enemy stuff.

Depends if you are using engine kamikaze... in MCL I identify mechs that meltdown in a catastrophic over heating which result in damaging enemy units as the "attacker".

[Jools]

But the point is as silentwings says, it cannot catch all cases when your unit damages enemy, because in the game, this information is not present. Even with a gadget you cannot catch the case when a kamikaze unit blows itself up and kills enemy stuff.

Depends if you are using engine kamikaze... in MCL I identify mechs that meltdown in a catastrophic over heating which result in damaging enemy units as the "attacker".

Yes, you can do it 'manually' but the information is not present in that callin.

[FLOZi]

It is if you set the kamikaze unit as the owner of the explosion

[Google_Frog]

I am fairly sure that widget:UnitDamaged is only called for units which you own (technically, ones with your allyTeamID). You are going to need some ingenious method of collecting the information you want (periodically check seen unit health?) or help from a gadget.

In ZK we're opening up some information which would make sense for a team to see. Here is a gadget that sends enemy deaths that occur within LOS https://github.com/ZeroK-RTS/Zero-K/blo ... events.lua

[Jools]

I am fairly sure that widget:UnitDamaged is only called for units which you own (technically, ones with your allyTeamID). You are going to need some ingenious method of collecting the information you want (periodically check seen unit health?) or help from a gadget.

I'm not sure but I think it's called for every unit that you can see, i.e also enemy units. But it should be tested, I'm too tired now to test.

At least the widget that plays self destruction sounds: everybody visible can hear that sound. I guess I assumed it works the same way.

[gajop]

If not, it definitely should be like that. Polling which GF mentioned might cause performance issues if you're worried about that. It's also rather ugly.

[Google_Frog]

Is there anything wrong with the gadget I linked? I was not involved in its implementation and would like to know whether it is a good method for giving widgets more information.

If the ZK gadget is a good implementation then I disagree with this:

If not, it definitely should be like that. Polling which GF mentioned might cause performance issues if you're worried about that. It's also rather ugly.

A game might need to hide whether a unit was destroyed or just left LOS. For example a unit could have an ability which makes it look like it self-destructed but actually it teleported or went invisible. If the game implemented widget:UnitDestroyed for enemy units then it would be able to decide when to send the event. Spring is already quite bad at information warfare games so I would not want to make it worse.

[gajop]

A game might need to hide whether a unit was destroyed or just left LOS

Maybe there can be a single callin for those cases if not already? I'm against polling to mimic events (I've written some and they can be slow and non-trivial to write).

[otyugh]

I am fairly sure that widget:UnitDamaged is only called for units which you own (technically, ones with your allyTeamID). You are going to need some ingenious method of collecting the information you want (periodically check seen unit health?) or help from a gadget.

I'm not sure but I think it's called for every unit that you can see, i.e also enemy units. But it should be tested, I'm too tired now to test.

At least in BA, I wasn't able to get any teamID from UnitDamaged that wasn't mine of wholes games.

And is true in fact, we can always guess someone is dead by the sounds. So it's not that much of a hidden stuff. :p

[Google_Frog]

A game might need to hide whether a unit was destroyed or just left LOS

Maybe there can be a single callin for those cases if not already? I'm against polling to mimic events (I've written some and they can be slow and non-trivial to write).

I am not advocating polling. I am saying that if a game wants widgets to see events such as these it should send those events from a gadget. It is easier to add a callin to a particular game than to block one if the callin gives away too much information.