Dup

Same issue here. We have pretty big missions with lots of BB antennas, could be cool to have this fix as soon as possible...

Any news about this request ?

We're regularly organising night time or bad weather events on our server, and it's always a painful point to make airfield switch lights on and make the simulation more realistic and immersive... Having an API method to manage this would be a great new feature for sure ! Please do it !

Hi there, On our server, we have been 4 players (2xF-16, 2xF/A-18) not having missile alert for R33 shot by AI controlled MiG-31s. For this one, I think trk file won't help since it's a really heavy mission with lots of players and AI units during a 1h30 flight. I also experimented same issue on a PvP BVR server, plus a case where I get a fox 3 missile alert with sound and visual indicator but lost sound after a few seconds. If this can help in any case...

Hi there ! Since a few days (maybe since 2.8, note sure), we're not able to ban a player from our dedicated server using the remote console anymore. In summary: - Kick from local web GUI : OK - Ban from local web GUI : OK - Kick from remote GUI : OK - Ban from remote GUI : KO I'll be pleased to provide you with any log/trace/ID you may need to investigate.

I would love to have a look to these documents as well, if you can share in PM. Because what Harker says sounds perfectly logic. The fact that the radar provides raw data that are processed, filtered, merged with other sensors and shared data, all of this to give a trackfile that can't be interacted with doesn't make any sense. Engineeringly speaking. If at least the symbology was different, that would be a hint that we have the beginning of what could be a solid contact that will be soon correlated, this would be understandable. Think of the focus loss of the pilot, fighting with its commands to select the trackfiles that cannot be selected... It can't be acceptable... Is there a reason for this design ?

Issue solved. Juste in case someone is having this issue, I ticked "Allow More Controller Inputs" option by accident. Unticked it and everything is working fine now.

Hi there ! The topic title almost says it all. I recently rebuilt a brand new computer that can run DCS with almost all settings max, and I'm experiencing weird behavior on SRS. When I try using SRS (even without running DCS), it can take from quarter of a second to almost a whole second time between the moment I press PTT and the moment the "pop" sound plays and green light appears on overlay. Sometimes, it simply doesn't catch PTT press, sometimes it get stuck like PTT is pressed down. The issue happens whether I'm using my X-52 HOTAS or keyboard, game controller display windows doesn't show any input lag. I'm using Windows 10 up to date. I'm wondering if someone is having or had the same issue. Maybe a library to update somewhere...

Nice !

Same issue here, goes away with medium quality instead of low for water. Is it planned to be fixed ? This is making carrier operations pretty hard and I clearly can't afford above medium setting due to FPS loss.

Tricky.

Do you mean that SRS is reading the UFC display as we do ? The radio frequencies aren't part of the exports ?

I noticed 2 things yesterday : The first one may be correct as is, but once the hornet has an engine running and radios are powered, both of them aren't listing guard frequency by default. We can then tick "GRCV" mode so the guard frequency is monitored, but it is also ticked automatically whenever you go on "G" channel by rotating the radio knob. I don't know if it means the radio isn't set correctly at startup or if it is correct behavior. The second one is more problematic. I noticed it using SRS mod but it seems to be related to the F/A-18 module, see the associated screenshots with the SRS overlay info : - set the GRCV mode on COMM 1 and select chan 1 on it, which is 251.000, then COMM 1 is monitoring 243.000 ("G" symbol in SRS overlay) - select a channel on COMM 2 and start typing the same frequency that is selected on COMM 1, then even before you press ENT on the UFC, the guard frequency doesn't look like to be monitored anymore according to the SRS overlay, even if it is still on different frequencies since we didn't entered the 251 in COMM 2 channel - when pressing ENT on UFC, COMM 2 then take the entered frequency and if simply pull the channel selection knob on COMM 1, guard monitoring seems to be back. From there, whenever the selected channels of COMM 1 and COMM 2 set the same frequency, the guard monitoring quit as well I noticed that this won't happen if you set both COMM 1 and COMM 2 in GRCV mode, so I think it is a bug related to the displayed frequency and state of GRCV mode for the active radio in UFC display. Note that the GRCV mode isn't changed at all when this frequency equality happens. Here's a track you can also use if it helps in any way.

Looked familiar at reading... https://forums.eagle.ru/topic/254558-second-gbu-12-sticks-on-pylon-after-first-successful-release/ It just happens sometimes, I didn't find a reliable way to reproduce.

Understood, so basically, the simpler the mission is, the less objects it has, the better it is to replay the track with minimum gap between original situation. The track I sent contains the mission from our server (Bullseye Francophone). Did you try to play it or did you try in your own missions ? Maybe some specific mission stuffs can be responsible of this ? Yes, I can confirm that I'm holding weapon release from the moment I see the release cue to something like 0,5sec-1sec after it crosses the FPM. The only thing I see that may create noise in procedure is the fact that I use a Saitek X-52 HOTAS and bind the "weapon release" command on second trigger and "gun trigger" on first trigger. This causes gun trigger to be pressed at the same time when I push the trigger all the way to weapon release. I can try to change this and see if it stops happening.