Alighierian

Just to also chime in on this, as I never properly followed up on the same stuttery mess issue: Updated to 2.9.3.51704 (unification update), and applied the 'settimeout(0)' fix. Along with an export interval of .5s / 1s (lowtick), and my Apache is finally flyable with CMWS on in a heavy mission. Testing point - Pretense, Beirut airport Previous OB (pre-update, r5 5600): ~15-25 FPS with CMWS on, ~40-60 with CMWS off Previous OB, and current patch (r7 5800X3D): ~20-30 FPS, though I didn't test these for long Current + fix (r7 5800X3D): ~65 FPS stable, with and without CMWS on So far it seems to have launched the FPS into properly usable territory.

Had the same issue earlier today, likewise with items bought via Steam. Reimported the licences, and the auth error was resolved.

Nothing's stopping you from having a custom background, and using an image of choice instead. You can even modify the loading screen images, should you wish to do so.

It also has some graphical glitches:

Are you installing it in the DCS root folder (not saves games)? Did a bunch of flying yesterday/last night, and this mod works in the latest OB version.

Officially removed, yet apparently not worth mentioning the changelog.

The issue is inconsistent with how quickly it happens, and almost never occurs on the first havoc. Given the time since I tested it, I don't directly recall which havoc failed to be shot down in that track. I previously replicated it by doing the test mission (also attached), and letting it run. Speeding the time up didn't affect the frequency of error. I would have to run the test mission again to see if it's still present in 2.8.

Same here, category is gone after the recent patch where some bindings changed. Currently trying to reapply it, but so far no dice. It would help if I use the 'AH-64D' folder, instead of creating an 'AH_64D' one. The bindings showed up again after properly re-applying it, though I did have to re-do them.

This issue was first observed multiple times in a multiplayer mission on Syria, Lebanon locale, after which I replicated it in a single player situation, as similar to the multiplayer situation as viable. Version: Latest Open Beta at this time - 2.7.14.23966 The gist of it: HAWK site sees a target (in this case a Havoc) and, if a firing solution is available, fires. Target evades by means of terrain masking HAWK loses target, and goes back to idle search Target unmasks and is reacquired by the SR TR starts tracking target, but the Launchers don't react Target sees no need to further evade, and proceeds to do Havoc stuff, like murdering the HAWK site and everything nearby (Unsure what the conditions for this are, maybe a few cycles of lost targets) - HAWK fails to engage any target until packed and redeployed, or ROE are cycled. In my replication I set the Havocs to do a weapon hold course, to try and achieve point 7, though I suspect it may need multiple cycles over the course of a few hours to rear its ugly head in this situation. Reloading of launchers might be related, though I couldn't conclusively confirm or rule it out with this relatively brief testing. In the multiplayer server, the HAWK sites are built up with CTLD, but are otherwise completely vanilla units. In my single player test I tested it with both my normal mod complement, as well as without any mods active, and it occurred in both situations. Additionally, I highly doubt it was altitude related, as the AI Havocs in their unchallenged attack state want to be above the targets, which is in this case the HAWK site. This is an image taken from the 'SP - without mods' track file, where the launchers did not engage the Havoc (top left of image, 6.3nm, flying at 5k ASL), despite having fully loaded launchers. I confirmed in a different run with 8 or 9 launchers that the HAWK can engage for the entire stretch, up until it's masked by the ridge-line it's positioned on, off-screen to the left of this image, so this situation is well within its capabilities to engage and hit. And this was for the next Havoc that showed up. The previously inactive launchers engaged as normal. Launcher layout in the MP server: HAWK 1 HAWK 2 Area situation in the Multiplayer server, Syria map, Lebanon - HAWK 1 is Northern red circle, HAWK 2 is Southern red circle. The Havocs spawn at Beirut and head South/East, towards the combat area. Orange indicates another HAWK site which I've observed exhibited the same issue: it detected a Havoc entering the valley, opened fire, and lost track. When it next re-acquired the same Havoc, it failed to actually re-engage, and it took a while until the Havoc was shot down by other air defences. The HAWK itself never fired another missile after picking that Havoc up again, despite it being well in range the entire time. I've attached multiple tracks, two of which were shot with mods active, though none directly affect the units and they can be viewed with an unmodded client. The third one is shot without mods. Additionally, I've attached the basic mission I made to test the situation. It's not consistent with how quickly it happens, so I ran it a few times to confirm. It's also possible to increase the amount of havoc spawns (along with the scripting), in order to increase the odds of it occurring in one mission. It probably comes as no surprise that this bug is very annoying here: A SAM site that works for a while, and then casually watches as an attack helo butchers it, isn't much of a use in a dynamic persistent scenario, where the SAM engaging something isn't a 'one wave and it's done'-deal, but an hour upon hour upon hour upon hour endurance thing. SP - With mods - HAWK fail 2.trk SP - Without mods - HAWK fail 1.trk SP - With mods - HAWK fail 1.trk HAWK-Havoc test Beirut.miz

If the mission itself doesn't work in part/fully because of ground mods, that is probably unrelated to the Apache, and instead caused by general DCS changes/updates. The most common fix for that, however, lies on the mod creators' side, not with ED or other official 3rd party developers. Mods are great, and I'm a modder myself, which is also why I fully realise, and accept, that problems with mods have to be solved client-side 99% of the time. So, ye, disable the mods that cause the mission, or your game, to not work, and update them when possible, or stop using the mod(s) in question if they're abandoned. It's infeasible for game devs to account and accommodate all the stuff modders come up with, beyond basic modding capacity, and perhaps modding tools if they're feeling generous.

Known issue (can't use radio in 1.2 with latest OB version when not using SRS to select and use the radio).

The latest patch of DCS broke the 1.2's radio when not using it through SRS. I have the same issue currently, and am unable to contact anybody with it. The devs are aware of the issue, though, so hopefully we'll have a fix soon-ish.

Thanks for the quick update. I've come to really like how realistically visible the smoke is, even at long range.

It looks like an update is needed. I got an error about a TONEMAP, and DCS plainly didn't boot until I disabled this mod.