Fabri91

In some trials using the same MP mission where the issue occurred, but in single-player, I was able to reproduce it once: track attached (Caucasus map). 01 ah64 xfer fail.trk

I also had this issue occur, when flying on a self-created MP mission with cool weather (single-digits C temperature).

Even if they do not have such agreements, it's not our problem to solve.

It's probably the author of the Syria map, Ugra Media - it's the only possible overlap. The lack of communication is concerning - there are other map pairs where there is overlap, which of course are now completely out of consideration since part of them can be removed without any notice whatsoever.

I can confirm that especially in the external view while panning around performance seems to be very inconsistent and stuttery.

Tangentially linked to this point: if there's a name assigned to a waypoint it should be shown in Jester's menu.

I had the same error when not including the Skynet script (I missed the file named skynet-iads-compiled.lua, specifically) correctly in the startup trigger - ensure that you've done that.

I seem to have the same issue - here's a video recording of it occurring:

As described in the title, today I noticed this issue while flying the F-14A for the first time after a long while: in short, the GBU-12s loaded on board appear ablative grey, as IIRC is used on naval aircraft, but upon dropping thebomb became "standard green": The DCS version used is the latest Open Beta - Multithreaded version 2.9.0.47168.

I've flown it yesterday and managed to complete it on my second try - turns out, I will likely try it again later this week! Well done!

Sometimes, even when starting hot on the runway or in flight, when setting up for an ILS approach the ILSN and ILST buttons on the HSI will not be present and appear/disappear seemingly at random. In this case, for example, they disappeared after I selected ILST mode and started tracking the localizer. At a later stage they re-appeared, as did the glideslope, far below my nose. Pressing the corresponding PBs didn't seem to have an effect on the system in this apparent "stuck" state.

So far with a buddy in MP we're able to reliably reproduce the crash: in both cases me as the WSO activated the A/G radar page, then my pilot selected the same page and only after that the radar knob was moved to OPER from STBY. At that very instant I, as the session host and the WSO, experienced the crash. A full, slow repair was run after the first test and *prior* to the second test.

Same issue still present on Caucasus.

Thanks for the amazingly quick reply! I'll test it out some and report back any issues. EDIT: I tried your example and it seemed to work, but upon changing the units (Tigr on red side with an Abrams on the blue side) the wreckage still appears to stick around - have attached some screenshots in addition to the modified mission file. Especially in the first one you can clearly see both the old and new vehicle. viper w uu mod.miz

If the change is here to stay, would it be possible to have a module that wipes a trigger zone of all objects? This way it could work like this: spawn clones -> when all are dead run this "wipe all" module -> when it's done run the delayTimer -> when it's done trigger a new spawn event. I'm thinking of having it be separate because if static objects are not tracked then it's "dangerous" to wipe them as part of the cloneZone everytime, so it might make sense to have it have to be invoked intentionally.