Pizzicato

I'm using a Reverb G2.

@Flappie Great news! Thanks so much for getting this addressed.

Good to hear. Thanks Flappie.

@Flappie Did you have them check the first stress test that I uploaded (not the on/off test or the one from last year)? It doesn't appear to have any downloads, but I'd be surprised if they were able to get all 50 Hornets started without experiencing the crash.

Well that's bizarre. Replicating bugs is a weird and unpredictable endeavour. Thanks for following up anyway, Flappie. I hope someone eventually manages to get to the bottom of this.

You should probably be specific about which Christmas...

No arguments here. In the meantime, though, you can at least cycle through them with successive mouse clicks (if you didn't already know that).

@Flappie In case it's valuable, it seems that the uncontrolled setting isn't a factor. Because I'm a curious soul, I set up another quick test mission - this time with a single hornet that's already in flight. I then created a simple alternating that toggles EPLRS on and off every 2 seconds. There obviously isn't a real world use case for this, but I just wanted to stress-test EPLRS on a single aircraft without the uncontrolled flag set. The triggers maintain a count of the ON/OFF iterations in the log. Test run 1 crashed silently to the desktop after 59 cycles. Test run 2 crashed on the FIRST cycle! Test run 3 crashed after 3 cycles (This time while on the "EPLRS to OFF" part of the cycle) Hope that's helpful. EPLRS Test - No Uncontrolled.miz

Thanks Flappie. Much appreciated.

PS - Do you have the admin rights to give this thread a more relevant name? It's not really about MOOSE and IDEs now, really.

Hey @Flappie Unfortunately, it appears that the EPLRS bug is very much still alive and kicking unless the engineer you mentioned meant "Never apply EPLRS to an uncontrolled aircraft even if it was STARTED several seconds earlier." I put together a simple stress test which demonstrates that the crash is reproducible: 50 uncontrolled Hornets on the Caucasus map. One Hornet receives the Start command 3 seconds later, the same Hornet receives the EPLRS command This sequence repeats every 6 seconds. There is onscreen and debug log feedback to mark the progression of the test. I ran this test three times: On the first run it crashed after 4 aircraft had been processed. On the second run it crashed after 3 aircraft had been processed. On the third run it crashed after 14 aircraft had been processed. This really needs fixing as it makes setCommand() EPLRS a really nasty and unpredictable scripting-landmine. EPLRS Stress Test.miz

@Flappie I checked my scripts last night and it turns out that the issue was that I was calling the EPLRS setCommand() immediately after the Start setCommand. I used timer.scheduleFunction() to introduce a 2 second delay and everything started working fine. Thanks for pointing me in the right direction. On the flip side, I was easily able to replicate the silent-crash-back-to-desktop by calling the EPLRS setCommand on Uncontrolled groups. It's not a major issue given that I now have a workaround, but it still seems that the engine should be able to cope with this issue a little more gracefully (and ideally with some feedback to the scripter). Regardless, thanks again for the quick reply and helping me figure out what was going on.

Hmm... yeah, that's possible. I'm not at my home PC right now, but I'll check my scripts tonight and see if that's what's going on. I'll report back and let you know if that's what was going on. Thanks for the clarification and the quick response, @Flappie. Much appreciated.

@Flappie So... I just spent four hours trying to figure out the cause of DCS silently crashing to desktop during a mission I'm building, and it turns out that it's this exact same issue from nearly a year ago (i.e. too many EPLRS setCommand calls in too short a space of time). Very frustrating waste of an evening. Can you check the bug database and see if the issue is still there, please? 11 months to address a 100% reproducible Class A crash bug (albeit something of an edge-case) is a little disappointing.

Surely that would be the ultimate waypoint (assuming that it isn't set to "landing"), no?