fixed CTD when exploding a single-unit group

[Mr Nobody]

Had an issue pop up while working on some VBIED stuff.  The general gist is that I'm using the "Perform Command > Run Script" at a vehicle's final waypoint to have it explode.  The code I'm using to grab the vehicle's position and destroy it is:

 

local thisGroup = ...
local firstUnit = thisGroup:getUnit(1)
local firstUnitCoords = firstUnit:getPoint()
trigger.action.explosion(firstUnitCoords, 200)

This works fine if there's more than 1 vehicle in the group, but if the vehicle is alone in the group, then DCS crashes as the explosion triggers (you can see the initial effect of the explosion in the right spot as the crash happens, so the explosion part of it is still "working").  No scripting errors pop up and dcs.log doesn't show anything out of the ordinary for me.

Am I misunderstanding something about getUnit or using it incorrectly, or is there some kind of quirk with how it works when there's a single unit in a group?  I also tried making a function that checks that the group size is >= 1 before grabbing the unit and exploding it, and then calling that from the vehicle waypoint, but it still results in the same crash.

Test mission is attached with 2x Urals that will drive forward a little bit and the lead unit explodes, as intended.  If you reduce the group size to 1, it will crash the game instead.

VBIED Test.miz

[cfrag]

A couple of things:

First, that vararg '...' accessor is cool, something I forgot and a great reminder of what is possible with Lua. It makes the waypoint code portable; in my mind, though, its a bit unsafe. It is not the reason why DCS full-crashes here, though. And yes, this is a DCS-crashing bug that can be 100% re-produced, simply make the group consist of only one vehicle (just as you narrate)

The reason that DCS full-crashes when you only have a single unit in your group is that the group is destroyed by the explosion while the script is running and (my guess) the backend deallocates the group's context in which the Lua script runs while it is running, full-crashing the environment. I'm sure that @Flappie would love to take a look at that - a full DCS crash should not be possible when a group's waypoint script is running and the entire group is destroyed. If left in DCS like that, any script that runs during waypoint executions is at risk.

[Flappie]

Thank you both. This crash issue is already fixed internally.

[Mr Nobody]

18 hours ago, cfrag said:

A couple of things:

First, that vararg '...' accessor is cool, something I forgot and a great reminder of what is possible with Lua. It makes the waypoint code portable; in my mind, though, its a bit unsafe. It is not the reason why DCS full-crashes here, though. And yes, this is a DCS-crashing bug that can be 100% re-produced, simply make the group consist of only one vehicle (just as you narrate)

The reason that DCS full-crashes when you only have a single unit in your group is that the group is destroyed by the explosion while the script is running and (my guess) the backend deallocates the group's context in which the Lua script runs while it is running, full-crashing the environment. I'm sure that @Flappie would love to take a look at that - a full DCS crash should not be possible when a group's waypoint script is running and the entire group is destroyed. If left in DCS like that, any script that runs during waypoint executions is at risk.

Agreed, It's not often I think of using it, but it seemed like a neat way to do some simple waypoint-based things like using Group.destroy() to remove something that's leaving the play field or the VBIEDs in this case, all while not needing to track names of dynamically spawned groups.

I had a hunch that it might have been because the script was trying to run on the group which was somewhere in between existing and not (Schrodingers Ural?).  I'm still very inexperienced with lua so I wasn't sure if there was a way to maybe "trap" the script so that the explosion didn't occur until after it had done what it needed to do.  I didn't check to see if scheduling the explosion with a second or two delay was a workaround for this

13 hours ago, Flappie said:

Thank you both. This crash issue is already fixed internally.

Awesome, thanks for following this up both of you!

[Flappie]

Fixed in today's update.