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?

In the two hours between the original post and your reply? Unfortunately not. ED's addressing of bugs and issues (when they even acknowledge them)* is measured in months and years**, not hours. I'll see you all back here when this gets fixed in 2030 for a celebratory pint. *A recent bug report about a broken F/A-18 training mission was moved out of the Bugs and Problems forum into the general Missions and Campaigns section. **Not an exaggeration since I recently got a response to a bug report I'd made in 2022 stating that the bug had now been addressed. (I do appreciate the issue actually being addressed, though, and the follow up was also very welcome, so it's not all bad.)

Oh god! Thank you so much for this. It's been driving me mad (and really hurting my eyes), but I thought it was just me. I really hope this gets addressed, and soon.

@BIGNEWY@NineLine Why did this get moved from the Bugs and Problems forum? This is a bug and problem, right?

Yeah, I know. I don't really expect this training mission to get fixed for that exact reason. I'm not sure that it can be fixed given that constraint. That said, it's obviously not ideal that an official training mission is fundamentally broken and unfixable.

Hey all, The second part of the Multi-shot AIM-120 Employment training mission appears to be broken. After loading into the second part of the mission, you start out in Active Pause while being briefed on how to employ your wingman in an engagement. Unfortunately, your wingman isn't actually paused during this period. While you're being briefed, you wingman desperately tries to maintain formation around your static aircraft, getting lower and slower as he circles down into the ocean. By the time the mission briefing has completed, the wingman that you're supposed to directing as part of the training smear is just an oily smear on the surface of the water.

You really need to explain why something is needed if you want people to understand the issue you're trying to solve and act on your suggestion. What is it that you're trying to do that you can't accomplish with the current implementation of the ruler and compass?

I am using 2FA. I haven't initiated any trials, though. Any ideas why 2FA might be causing an issue? I'm not technical enough to know what problems that might cause.

@NineLine I've done some (by no means exhaustive) testing, and the behaviours are generally much improved from when I first reported this. There are still some weird anomalies in there, though. In terms of testing, I kept things very simple: Two aircraft flying head-to-head towards each other on the Caucasus map from 250 nm apart. The fighters were just given the default CAP task. No tweaks. The map was empty, so there were no distractions and no AWACS or EWR support. I gauged the detection ranges as the points at which the fighters lit their afterburners and started manoeuvring for position. My initial findings were: Western Fighter versus Transport F-14B v IL-76 - 176nm F-15C v IL-76 - 95nm F-16CM v IL-76 - 73nm F/A-18C v IL-76 - 82nm Western Fighter versus Small Fighter F-14B v Mig-29 - 91nm F-15C v Mig-29 - 70nm F-16CM v Mig-29 - 73nm F/A-18C v Mig-29 - 73nm Russian Fighter versus Transport Mig-29A v C-130 - 75nm Su-27 v C-130 - 75nm Mig-31 v C-130 - 110nm Russian Fighters versus Transports Mig-29A v F-16 - 75nm Su-27 v F-16 - 70nm Mig-31 v F-16 - 72nm I'm not an expert by any means, but these numbers seem much more sane and plausible versus the omniscient AI radars and suicidal charge-across-the-entire-map-on-full-afterburners-and-run-out-of-fuel-before-reaching-their-target behaviours of a couple of years back. As I mentioned, though, there are still some comparatively minor weirdnesses remaining. As an example, Mig-31 appears to have the radar cross-section of a small skyscraper as both the F-16 and F/A-18 begin engaging it at over 150nm. That seems a little odd to me given that they only "see" an Il-76 at 70-80nm. There are probably other such issues hidden away waiting to be found, but all in all it seems generally much better. Thanks for the heads up.

I'm having the same issue with a lot of micropauses and stutters, all of which sync up with ModelTimeQuantizer:ANTIFREEZE ENABLED or ModelTimeQuantizer:SAME MODEL TIME messages in the log. As as example (attached), that's 15 such messages in 7 seconds. I don't have any WinWIng peripherals, and I'm not running as administrator.

Another bump. It's all very well saying that DCS is a sandbox, but that only works if you've got the right toys to play with in it. I really like the Iraq map, but it's pretty pointless without pretty much any properly liveried Iraqi assets.