Mr Nobody

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 Awesome, thanks for following this up both of you!

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

Yep, you get a patch release that doesn't have a showstopping issue

I'll take the extra time to actually finish the half a dozen mission ideas I started and didn't have ready for the launch day

I haven't tested this so it's a shot in the dark, but could you set their landing waypoint to the "Rearm/Refuel/Repair" type and then make the timer extremely long so that they feasibly won't leave for a very long time, well past the point where you'd expect the mission to be over?

Thanks for the quick reply, that's got me on the right path. Appreciate it! I should add as an aside for anyone from the future with the same problem as me: I used NewGroupName = mist.cloneInZone('Test Group', {'Spawn Zone'}).name to get the group name in this example, rather than "NewGroupName.name". Not sure if that makes a difference in terms of syntax or causing anything to fall apart in certain situations but it's been working flawlessly so far.

As the title suggests, I'm having a bit of confusing time in regards to this. I'm trying to spawn units via MIST's cloneInZone function, but I'd like to be able to grab the name of the freshly spawned group since I want to add it to a table for tracking various things. The wiki suggests that the function returns the name of the newly generated group, though I'm not entirely sure how to go about accessing this. I tried doing something along the lines of: NewGroupName = mist.cloneInZone('Test Group', {'Spawn Zone'}) to see if the variable "NewGroupName" would be the string of the group's name to no avail. I'm pretty sure I'm barking up the wrong tree trying this (my only experience in lua is throwing myself at DCS stuff until it works) so any help would be greatly appreciated - am I trying to do this the wrong way, is it not possible, alternatives etc? Thanks in advance.

Unfortunately that hasn't done it for me. I cleared out fxo/metashaders folders, did the slow repair, and it was still crashing. Decided to leave it for the evening and try something again tomorrow. Tried again this morning, placed down a F-15 on Caucasus and tried it in both ST and MT, everything worked fine. Went back to the mission I was originally crashing on, which is on Persian Gulf, and it immediately started crashing as before (works the first time, if I reslot or restart the mission, it crashes on the first sweep). Update @Timghetta: I'm pretty sure I found a cause for this. I tested on an empty map with 2 different Client F-15Es for both Caucasus and Persian Gulf, everything worked fine. As soon as I forced Civ Traffic on in the PG version, I got the crash. PG, Civ Traffic on High: Crash PG, Civ Traffic on Low: Crash CCS, Civ Traffic on High: Crash CCS, Civ Traffic on Low: OK

I'm having this issue as well, been able to replicate it multiple times; Air started in F-15E, went to AG radar, RBM and HRM work fine. Go back to Mission Editor or hit LShift + R to reload the mission, get back in the same slot, go to AG radar, immediately crashes on the first sweep. Adjusting the amount of threads in Special Options doesn't correct this issue. CPU is an Intel i7-8700K @ 3.7.

I, for one, am finally breaking my forum silence to announce that I proudly welcome our new J-8II overlords, just because I'm about to sell all my stocks in salt and I need to feel good about my investment.