moggel

We ended up figuring it out. I was guiding a bunch of guys who had recently started playing DCS and set up a server for it. As such, the M92 mod was installed incorrectly into the "mods/tech" folder in the server's install folder structure (where only 'official' mods are allowed). I told him to move he mod to the community mods/tech folder instead (under the "Saved Games" structure) and he confirmed he'd done it. I double checked and they were there, but the units still didn't show up in game. I checked the logs and saw a few lines that indicated something still wasn't right: I then asked the guys to check whether the mods where now in two locations, and it turned out they were. So, instead of moving the mods they had just copied them, so those community mods where still in the 'official' mods folder, which is why DCS blocked them as "not authorized". Once they had removed the duplicates from the official mods folder structure, it worked fine.

I see exactly the same problem, and this is in the server log. Did you sort it?

I eventually figured it out. Turns out I had just made a mistake, and in part hadn't adjusted the NVG properly to see the strobe at a longer distance. Works fine now. Thanks for taking the time.

Does this still work? I tried the script and I get no errors but I also don't see any strobe effect in my NVG when I test it.

Yes, I have tested setting the task instead and I don't see any difference. Also, the AIs I'm testing with are super simple, with a "Nothing" main task, and no Advanced Waypoint Actions"; just a simple route with a few waypoints. I have tested with just one or two waypoints and with a bit longer routes that end with a landing. Sometimes it works, sometimes not. Oftentimes it does works fine but when I test it later, having made other - unrelated - changes to the miz, it stops working and I'm unable to figure out a pattern. It's like it's just cursed or something. Voodoo I guess my questions are: Are more people seeing this (Follow task unreliable from scripting)? Might there be some dependency that can cause it to not have an effect, that I just haven't thought about?

I'm writing an "interceptor" Lua script, for air policing and such, and it works very inconsistently. What it does is it allows a pilot to fly up to an AI aircraft and perform an intercept signal (rock wings and/or flash external lights). This causes events that can be interacted with by the mission maker, but the default behavior is for the AI aircraft to "follow" the player aircraft. The script simply pushes a "Follow" task to the AI task stack. This has turned out to work very inconsistently. I have had several situations where I've been testing it and it works. Then, suddenly, it just stops working. Pushing the task to the AI does nothing. There is o following at all. Nothing in the dcs.log. I have not found any pattern to why this can suddenly stop working. Does anyone have any ideas?

It seems the latest DCS update (February 22, 2024) caused an IC issue: /textures/su-27_detail @ c:/users/xyz/saved games/dcs.openbeta/mods/tech/vpc airfield equipment/textures/vpctextures.zip

Confirming this

I dug into the keybinding hypothesis and, yes, that's the problem. But what's weird is, it wasn't the Cougars. It was the Thrustmaster TQS, BTN60 default binding (QUIET). I guess QUIET activating FZ makes sense, in so far it prevents AGR from emitting, but I would've expected the OVRD to get triggered in that case, not FZ? Either way, mystery solved. Digital Combat Simulator Black Shark 2024.01.19 - 13.03.48.01.mp4

I thought about that too, and the only binding is for my Cougar MFDs. I checked the "joystick properties" app and it does not indicate any of the buttons are active, unless I press them. I'll try disconnecting the Cougars just to be sure.

When in A-G mode, the AGR is in "FZ" mode and I cannot get out. Repro: Caucasus Slot into first F-16C (air started, see miz for A-G loadout) Enabled A-G mode Result: AGR is in FZ mode. Clicking "FZ" OSB does nothing. Still in FZ mode. Have tried repairing. Also tried several different loadouts CAC_F-16_AGR_FZ_forced_ON.trk mission_small.miz

Mystery has been solved. Turns out I had activated V-sync in the Varjo Base software and (apparently) not noticed the performance degradation at first so I didn't connect the dots. Duh!

Please advice. Last week I started getting crappy performance from my hardware and setting. In VR I'm used to seeing between 45-80 FPS. Suddenly, without any apparent reason (I hadn't changed any settings) I was looking at ~20-25 FPS, sometimes even sub 20. As I started to troubleshoot I reset all DCS settings to "VR" (which acronym for "crappy settings to maximize performance; goodbye graphics - hello frame rates") and I was still looking at sub-30 FPS! I don't see anything obvious in the Nvidia control panel. Hardware: i9 11900K, 64Gb DDR4, RTX 4090, Varjo Aero Windows 11 Home Edition. Latest Nvidia drivers. I do not have MSI Afterburner installed Tested so far: Reset Nvidia control panel settings to default, then changed "Power management mode" to "Prefer maximum performance" Reset DCS settings to "VR" (really bad graphics quality) Tested Multi Thread and Single Thread (equally bad performance) DCS is currently not playable I'm stumped graphics.lua options.lua

Ok, unless I misunderstand something... Heli pads does not allow rearm/refuel without adding an iFARP iFARPS cannot be added to elevated platforms, such as those heli pads ... this means elevated heli pads cannot really be used as helicopter bases during operations (other than just nice looking places to start/land from), right? I can accept that, and work around it. Just looking for clarity.

I don't know if this is specific to the Syria map (and I couldn't find a forum to submit bug report for that particular map) but when I try placing invisible FARPs on several of the helicopter pads the ME pops a dialog informing me the terrain is too steep. I don't have any insight into the map tech but should it even be necessary to put down invisible FARPs on heli pads? (this particular heli pad is in YB16)