moggel

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)

Done

[EDIT] Can a moderator move this report to AI Ground Bugs instead? Before I take this any further, would just like to know if more mission designers are seeing the same thing. I scripted a ground battle, which sees an armored column move along a route, triggering events and logic as it reaches each waypoint. I have tested this multiple times and it works reliably in single player. When run by a server, in MP, I see this: 1. AI takes some very weird route. Instead of navigating along a road, as programmed, they start by heading off into the terrain 2. Waypoint logic gets triggered way way before the armored column is even close to them Map is Syria, DCS is 2.9. Same miz behave extremely different in MP vs SP mode and I'm currently clueless as how to troubleshoot it. Attached .trk and .miz SYR_A_few_good_men_M04_103_119_20-20231217-140932.trk SYR_A_few_good_men_M04_103_119_20.miz

Great post. I was attracted by the design of the training system and was pleased to find a group that was less about virtual 'rank' and command, and more about making use of every individual's ability and ambition. If you like a challenge and want to push yourself in the digital skies regardless of airframe or role, don't hesitate to apply!

After 2.9 release I very often find it's very difficult to designate an emitter on the HAD page. What happens is usually (with TGP active on other MFD): I move HAD cursor over emitter and go TMS UP The emitter gets momentarily highlighted (inverse block) but immediately undesignates. The TGP momentarily slaves to corresponding location It usually takes > 10 attempts before I get a solid designation Is this as intended? One assumption was that maybe the triangulation constantly updated and that made it loose the lock, but I don't really see the emitter number move at all when this happens (and it's PGM2, not getting any lower unless I also use TDOA - which I didn't)