Is there a "smart" way of generating destroyed units and objects?

[Pizzicato]

I'm looking to write a script that pre-destroys specific objects at the start of a mission. My current assumption is:

• Search for the unit and get its pos vec3.
• Use trigger.action.explosion to create a blast at that location that destroys the unit or object.
• Randomly assign effectSmokeBig (and its variations) or nothing to that location to add a little flavour. 

My only concern about this approach is that I assume it'll create a bunch of Dead/Kill events that will pollute the Debrief screen. That being the case, I'm wondering if there's a smarter way to approach this?

Edited May 5, 2024 by Pizzicato

[TEMPEST.114]

AFAIK, that's pretty much all we have.

As for 'polluting the debrief screen', have you tried it? If it happens before players have jumped in, does it show up? And if so, is that a problem?

As for your solution, seems perfectly reasonable to me. Though from a mission creator's point of view, I'd think about making a public API function call from the Mission Editor on MISSION START that you can use with DO SCRIPT and pass in a table of object names or ids or whatever, and then let your script destroy them or randomly choose from the list and destroy them, that way you have unexpected stuff each playthrough and you only need to pass in a table from within the mission editor and it keeps it clean. 

Just my 2p.

[Grimes]

The problem with explosions is it isn't confined to the object you want to destroy. There are more options for units than you do scenery objects. You can use Unit.getbyName():destroy() to remove specific units. If you want you can spawn in dead statics at the same time. You can also go about it backwards where the group is set to probability 0% and then use a script to spawn in the group as needed. You check the saveState, see which units are alive, populate the group with those units while ignoring the ones that are dead, and spawn in the group via scripting. 

[Pizzicato]

Hey Tempest. I did a super-quick test and it turns out that you're correct that destroying the objects or units at mission start doesn't trigger the associated death events. All nice and clean.

Edited May 5, 2024 by Pizzicato

[Pizzicato]

2 minutes ago, Grimes said:

The problem with explosions is it isn't confined to the object you want to destroy. There are more options for units than you do scenery objects. You can use Unit.getbyName():destroy() to remove specific units. If you want you can spawn in dead statics at the same time. You can also go about it backwards where the group is set to probability 0% and then use a script to spawn in the group as needed. You check the saveState, see which units are alive, populate the group with those units while ignoring the ones that are dead, and spawn in the group via scripting. 

Thanks for the pointers, Grimes. I hadn't considered the "probability 0%" solution. I really appreciate the new ways of thinking about these problems.

[cfrag]

Wait… if you want to deploy dead units, cant you simply place static objects with the dead flag set? It’s certainly doable with script. The objects aren’t always good-looking, but my godson says the same about me, so…  

[Pizzicato]

10 hours ago, cfrag said:

Wait… if you want to deploy dead units, cant you simply place static objects with the dead flag set? It’s certainly doable with script. The objects aren’t always good-looking, but my godson says the same about me, so…  

I'm trying to create persistence between missions, so I'm saving out a table of dead units at the end of the mission and then reloading it at the start of the next one and adjusting the world state accordingly. That being the case, I'd need to get the types, positions and orientations of the "should be dead" units, destroy them, and them find the equivalent statics and spawn them in their dead state. Definitely doable, but I've always been a bit intimidated by dynamic spawning. It always seems super complicated, but maybe now's the time to learn.

[cfrag]

11 hours ago, Pizzicato said:

Definitely doable, but I've always been a bit intimidated by dynamic spawning. It always seems super complicated, but maybe now's the time to learn.

It is an unpleasant experience the first time, and it probably won't ever be a good experience until we get a better API for spawning. My impression is, though, that you'll quickly write your own spawning method, and then it becomes much easier. When you read the units that are dead, simply read their descriptions (via Unit.getDesc() and save it. You can feed that desc with very little changes to coalition.addStaticObject() and have the object spawn. "very little change" because you may probably want to change the isDead flag if it's not already set.

[Pizzicato]

Thanks for the explanation, cfrag. That sounds simple enough.

I think the only challenge is that there appears to be a bug (feature?) at the moment where units are removed at the moment of destruction. That means that any calls to the unit from the event.initiator property of S_EVENT_DEAD generate an error which isn't super helpful.

[cfrag]

17 hours ago, Pizzicato said:

That means that any calls to the unit from the event.initiator property of S_EVENT_DEAD generate an error which isn't super helpful.

There is a "feature" in DCS where a unit can change in-game from being a Unit (an instance of the Unit class) to a static object before it dies (when the unit cooks off), but retains the name (remember that names must be unique - except for map objects, but we'll cross that bridge when we get to it). This means that if you try to access a (former) Unit that now has become a scenery object (for example if you want to access the group that that unit belonged to, but scenery objects have no groups), you will run into an error. Is that documented? Heck, no. DCS is supposed to be fun! So never trust that you know the initiator even if it pretends to have a unique name, always verify that it is indeed of that class.

 

Edited May 10, 2024 by cfrag

[Pizzicato]

Thanks cfrag. Your explanations are super-useful, so thanks for taking the time to respond.