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)

I'm curious, though. I assumed the radio traffic was simply audio files being played from triggers, but you're saying the audio actually gets channeled through the simulated radios then? I forgot to mention: I also did not get a reply from the tanker (I think it was Texaco), and its TACAN was not picked up by my receiver either. Maybe also due to battle damage. However, as I reported inbound I did get arrival's audio again, and later tower.

Really like the campaign so far. Just wanted to report that during msn 2 I lost incoming radio calls. could operate the F10 radios and initiate calls to my wingman, and awacs, but I never heard their reply - just "Dan's" responses to whatever they said. I had taken a AAA hit by then, that made me loose all my pods, so maybe radio wasn't working or something? If the radio logic does check for loss of radio then I guess Dan's outgoing messages should also reflect this?

Me and @Moonshine did some testing and found that: Airborne TACANs now seem limited to about 40nm (might be realistic) Fixed TACANs are now very weak. We picked up the the DAN tacan (Syria, 21X) at abour 12-13nm and Kuboleti (Caucaus, 67X) at about 22-23nm. We flew high so LOS shouldn't have been a thing TEST_TACAN_Caucasus_for_2.9-20231022-120815.trk TEST_TACAN_Caucasus_for_2.9-20231022-120932.trk

I got my TQS today and was able to mount it to the Monstertech clamp without any problems. I could only fit two screws at the back, which seems to be sufficient, but if I want it even more firmly attached I would need to either drill two more holes in the Monstertech plate, or come up with some other solution. Doesn't seem to be necessary though.

So, I've done quite a lot of scripting to allow control of tankers (can be used to set up AAR tracks, and tankers can be assigned to them, and then reassigned to different tracks, RTB and so on). When my script sets up tankers, with different callsigns, it also automatically assigns the TACAN channel, mode and its identifier. For example, SHELL 1 ident is "SHA", SHELL 2 is "SHB", and so on. This works just fine, and has been working fine for a year now. But today I noticed if I load and run a mission on a MP server, the ident isn't showing in the aircraft. Instead it's just some dots. In SP mode I do see the ident as expected though. Single Player: Multiplayer: Could this be some new MP bug?

I used this post some weeks ago to understand how to allow running Sinai-based missions on one of our servers. Worked fine. I tried it again today and now, when I add Sinai-missions to server's list, they are grayed out again. Map is installed under server's Mods/terrain folder. I even went ahead and remove/reinstalled the Sinai map, but the miz is still grayed out. Has anyone seen this/have suggestions for troubleshooting?

I later restarted the PC, for other reasons, and now I can't reproduce it. Apparently, the DCS server was just suffering from some temporary flu. Thanks!

Can someone help me understand what's wrong with this one? I'm working on a mission and I'm testing it both in single player mode and also on a dedicated DCS server I just installed. When the same mission runs on that server all SA-2 launchers gets replaced by Leopard 2 MBTs, for some weird reason. I have seen this happening when a mod is missing, but this is just the vanilla SA-2 template so I don't get why this can happen.

Answering my own question, in case more people have a need to substitute AI-controlled objects with simple statics, damaged or not. This can be achieved with MOOSE's SPAWNSTATIC code api. No need to even drop the intended static model on the map, just check the controlled object's type name and use it with the SPAWNSTATIC:NewFromType function to get a SPAWNSTATIC wrapper. Then use that wrapper's :Spawn-functions. If anyone's interested I can paste the code for a "substitute with static" script

Thanks, but I need to be able to do it from script. Can I create a static object from any (non-static) unit?