reported Scripting API - Event.dead not called if an object isn't immediately dead

[Apple]

Since the last BETA update, the event.dead isn't called, if a unit isn't immediately dead, see attached demo. The death is registered in the ME event log, but the API isn't called. Reported by dcs-online.de and [WP] Stingray in the Moose Discord.

event dead test.miz

[ataribaby]

Yeah just came across of this as well right now

In case of T-55 DCS dead event event.initiator:getCategory() is 1 and in case of T-72 it is 3
3 is static, looks like cooked up T-72 is static

Seems that some units have now that "cooking off" delayed death and they cause this problem.

here is my report in moose thread with video and test mission.

 

[Special K]

With the BDA event, the unit type magically changes from UNIT to STATIC. That seems to be the issue here.

[cfrag]

2 hours ago, Special K said:

the unit type magically changes from UNIT to STATIC.

... so take note if you are processing kill events. Static objects don't respond well to getGroup(). That can wreak havoc on your score-keeping code. 

 

[Grimes]

This was discovered and reported on Saturday. 

[Apple]

Ok awaiting patch ….

[Apple]

On 3/21/2022 at 10:48 PM, Grimes said:

This was discovered and reported on Saturday. 

Is this fixed with today’s path, @Grimes? Thanks

[Pikey]

sorry to interupt, but I get dead events for the instant kills and slow burners. Is there a more concrete type testing to perform to accept this as officially fixed?

 

[funkyfranky]

@Pikey, I have a little test mission, where I trigger an explosion of 2 kg TNT at the position of a TPz Fuchs. I didn't and still don't get a dead event when it's cooking even though it is clearly dead and not shown anymore on the F10 map and its lifepoints are 0.

When I increase the explosion power to 5 kg, it is instantly dead and the dead event is triggered.

 

TL;DR not fixed from what I can see

[Apple]

@Grimes @BIGNEWY Any updates on this? Appreciated, thanks!

[Jakko]

@Grimes@BIGNEWY@Apple@Flappie

why are there open beta versions when such a critical bug is patched into the stable version today?
the error is likely to affect every mission out there.

or how do the other mission designers ask if their units have died if not using "event.dead" for any ground vehicle?

tips are welcome.
i had to change large parts of my script for the open beta so that the mission can continue at least rudimentarily.

[Dzsekeb]

1 hour ago, Jakko said:

@Grimes@BIGNEWY@Apple@Flappie

why are there open beta versions when such a critical bug is patched into the stable version today?
the error is likely to affect every mission out there.

or how do the other mission designers ask if their units have died if not using "event.dead" for any ground vehicle?

tips are welcome.
i had to change large parts of my script for the open beta so that the mission can continue at least rudimentarily.

I was previously checking for the Object and Unit categories to score the dead units. I've switched to just checking if whatever died has specific attributes, regardless of category. Seems to work ok so far. Still pretty disappointing that ED pushed this to stable.

[Astronaut]

I no longer look at initiator object category, just initiator category. it'll return whether it's a static or unit but that's the best I got. and you have to use an active filter, not filter once. I agree it's very frustrating. I don't want to update all my missions because I don't like doing it this way and if they fix it i'd go back to the old way. but the fix is probably measured in months to years, not days to weeks so best to find workarounds. it shouldn't have made it into stable, but really, what's the point of stable anymore? it's no more or less stable than Open Beta (mostly a compliment for not crashing open beta with the new closed testing procedures, ) just delayed. This seems like such a small bug but it's such a huge PITA and really hampers some of the missions i build.

[Apple]

Yes this urgently needs fixing. Still nothing official on this from @BIGNEWY or @Grimes

[Grimes]

29 minutes ago, Apple said:

Yes this urgently needs fixing. Still nothing official on this from @BIGNEWY or @Grimes

I said it was reported and I've tried to give it some attention, but other than that I can't do much at all about it unfortunately. 

[Apple]

8 hours ago, Grimes said:

I said it was reported and I've tried to give it some attention, but other than that I can't do much at all about it unfortunately. 

Thanks @Grimes appreciated

[stolle217]

interested and watching

[Jakko]

still does not work for me with today's patch.

[streakeagle]

In the server missions I maintain, this breaks the scheduled spawning. Once a given group of targets are killed, they don't respawn. I can use trigger zones to work around this, but it would be much better if ED addressed this problem rather than having to do extensive editing to all of our missions!

[Apple]

Agree. @Grimes @BIGNEWY @Wags -sorry for being buggy, but any news on fixing this? This is a major PITA for all scripters. Thanks!

[Pikey]

Just to help out the explanation because the problem wasn't immediately fully understood.

Ground units at least, possibly more kinds are substituted for a "static type unit" when they recieve terminal damage, i.e. when they are on flames, no health and 30 seconds later explode.

A lot of scripts rely on knowing when something has died so it can be respawned or an activity takes place as a result. This is a fundamental scripting trigger and one of the most obviously used. It has been used for over a decade, and over these years many scripts are created to leverage the fact that something 'died' in the mission.

Due to the change of the type of unit that explodes, DCS creates a dead event but its not the same unit type and is missed because it is a static. Depending on the coding, a script can hit or miss this, but at least as far as I know any script created with Moose prior to today (5/6 years worth) will fail to recognise something died in game. We implemented a workaround where we have to examine a static dying and check it wasn't a unit and all sorts of messy and un hygenic workarounds to get it going, but the impact post today remains the years of work people have created using Moose will fail to recognise a dead unit as a result. I dont have an assement for the AGME or Mist or custom SSE scripting related scripts.

What the ask is, is to have things as they were before, that when a unit dies, it doesn't change its type, in order to preserve the thousands of published player scripts that are downloadable on the forums and web site.

Thanks.

Edited May 5, 2022 by Pikey
tpyo

[cfrag]

On 5/5/2022 at 10:08 AM, Pikey said:

What the ask is, is to have things as they were before, that when a unit dies, it doesn't change its type, in order to preserve the thousands of published player scripts that are downloadable on the forums and web site.

I believe the ask is slightly simpler - nobody is opposed to the change of type per se, it's something that could potentially be used later. What we simply ask is that the dead event is invoked for the unit - what happens after (e.g. turn into static) is not important (to me, and I wager for most scripts). If that static unit later also receives a dead event, so much the better, no skin off anyone's nose. Just invoke the dead event just prior to switching it to static.

Edited May 6, 2022 by cfrag

[Astronaut]

26 minutes ago, cfrag said:

If that static unit later also receives a dead event, so much the better, no skin off anyone's nose. Just invoke the dead event just prior to switching it to static.

 

That also will create issues, if a dead unit is dead twice, once as a unit and once as a static. I have scripts that monitor statics and scripts that monitor units, so that would create just as much of a headache as the current issue. I just want it to report a dead UNIT only. That's what was placed in ME or spawned in scripts, that's what I expect to see the event for.

[cfrag]

53 minutes ago, Astronaut said:

That also will create issues, if a dead unit is dead twice, once as a unit and once as a static.

Actually, that's true - even with some of my own code under the current system where the statics 'inherit' the mob's name. I misspoke. So if new static objects replace the dead mob, they should be named differently, and ideally have a separate category tat identifies them as 'wreck' or similar when their death event is invoked.

  

Edited May 6, 2022 by cfrag

[Gizmata]

I have a custom designed script that kept "drones" (S3-B) flying around, that began crashing the server recently due to reading a "nil" value for a destroyed unit/group health.  I tracked them every few seconds and queried the health of each aircraft and this worked fine for the past few years.  I added some dumps to my log to see what the aircraft table looked like, and it was full of data before the plane got hit and was missing afterwards, as though the plane never had existed.

To work around it, the order of testing would need to change, to assume that if the unit/group doesn't exist, then it has been destroyed.  I just don't know all the places I have script snips that can't be used without rework/retest.

I only tested the single unit S3-B groups, so I don't know how if other vehicle types are removed from tracking the same way, or if this is due to it being a single unit group.