Alighierian

What is the fix in question? Both the CJS discord links I found were dead. Edit: Found this post via a different topic It didn't appear to do much, however, and still got stuck during load. I disabled the 130 and OH-6 for now (dunno if it's affected, but I'm not using it anyway), and ran a deep repair. Appears to be working for now. Edit 2: Found the actual issue on my end; bandit's weather mod was still on v10. Loading went as normal after updating to the latest version (v15 atm). It was rather inconsistent at failing, so it took me a few tries to find it.

I initially had some empty folders pop up after running the script. However, after I grabbed the correct Powershell version (x64 in my case), it properly handled all files it found (no empty folders from what I can see). Results are quite promising: The actual FPS in this MP mission hasn't changed much, but the microstutters are significantly reduced. I guess it was previously asking just a bit too much VRAM from my RX6800.

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.

Comms being annoying is a known issue. Current procedure for using the comms can be found in the guide, and includes binding a dedicated 'game comms' found in the options, and correctly setting the intercom knob. https://docs.google.com/presentation/d/1kCJf5Nk-fU_21eO7W1ozYfb9FKt488ax65IbeuIGVtA/edit#slide=id.g10c2e0f079a_0_755 Communication section starts at page 62

@Nealius I don't know why it's behaving differently for the individual maps either. I'm using OvGME to apply DOF2 to the main install folder. Nowadays I use OvGME for basically all DCS modding, for both main and Saved Games folder. OvGME is nice in that regard: you can make multiple profiles to switch between and selectively apply stuff to whichever directory.

I just tested it with a new install using the version from this reply, and it appears to be working for me on Caucasus, Syria, and now the Marianas as well. Caucasus no zoom Caucasus zoom Syria no zoom Syria zoom Marianas no zoom Marianas zoom Update: I kinda forgot it didn't work on Marianas, and apparently so did the game. That was on the Pagan airfield, on one of the northern-most islands.

I encountered a small issue on the Aleppo version: The FARP ammo storage for CTLD spawns still has the default name instead of 'logistic1', and as a result you can't spawn in crates, as the script claims 'you're not close enough to friendly logistics'. After I renamed it to 'logistic1' it worked again, so it's just the renaming that slipped through, not the script itself.

When mods are in play, it's always a good idea to check if it's a recent addition that causes something to not show up. If the game/affected item works without (recent) mods, you can narrow it down to see which mod and/or what parts cause issues. Sometimes issues stem from unexpected items causing chain reactions, by having malfunctioning parts, or not having certain things. It can be as simple as a skin file having a different layout, or a more recent update adding new items to a skin file. However, because the custom skin in question predated that update, that addition isn't included, resulting in missing textures and such, or, in the most annoying case, game crashes.

Just started using this awesome skin, but ran into a bit of a snag: it appears some of the files associated with this skin interfere with the recently added HARM targeting pod. When using this skin, the HAD-page doesn't show any radar contacts. When using a vanilla skin, in the same session, the HAD-page works as intended, displaying radar contacts. Edit: After disabling the visor (helmet glass) section in the description.lua, the markings showed up again on the HAD-page.