GeoS72

@Flappie, Confirmed. The problem is fixed. Thank you very much for addressing the problem!

@BIGNEWY & @Flappie, I'd like to piggy back on @Derbroomaster's remarks. George AI will lase a target every 5 seconds (approx) when outside of 8 km to obtain range information. Inside 8km, the lase logic is delayed to some ambiguous time. This process is very persistent when using the AGM-114L (Radar Hellfire) missile. Furthermore, George AI will not fire even when there is a clear line-of-sight to the target and the helo is within launch parameters. Press "Consent to Fire" all you want; George AI will not comply. I'd also like to point out that after lasing a target outside 10km will also allow the range to falsely count down and then stop. This fake countdown process will continue until the helo is within 9km from a target. What is the link between number of instances George AI lases a target beyond 8km, laser range data countdown beyond 10km, infrequent lasing within 8km, and failing to fire AGM-114Ls after consent was given? One more parting shot: George AI will frequently fail to lase a target. I have to manually cycle between Missile and No WAS modes just to get the George AI to lase a target in a "timely" fashion. Derbroomaster and I flew in the same mission today. So here is a link to my track file (much larger than his) and my DCS log. Persian Gulf 006 Track File link I'd certainly like to see some resolution to this persistent and annoying problem. Would moving this thread into the Bugs section may be more appropriate? dcs.log

@OnReTech, When will the issue with Tacan (TCN) channels be addressed in the Sinai map? I've seen several threads that discuss broken TCN channels. Specifically Cairo West has incorrect or nullified TCN and VOR info. In the screenshot, one can clearly see the Airfield info screen shows SPX Tacan Channel 0X and SPX VOR Frequency 0.00 MHz. There is an additional TCN icon that shows 114X with Station ID BLA. DCS Log file submitted. My track file is too large to attach. Here is one of many threads that also address this specific error at Cairo West. https://forum.dcs.world/topic/328094-cairo-west-vortac-is-broken/#comment-5239541 dcs 2024-07-13 Cairo West TCN.log

Here are the DCS log & track files. The track was from a Combined Arms training mission. Anytime you see the Vulcan being steered left or right it was from the use of rudder pedals. dcs.log tempMission.miz.trk

Yes, I had the same experience!

After this new update, I cannot steer any vehicles using the A & D keys. I can use axes to turn left & right but not the keyboard. Additionally, the key binds are default W for gas, S for brake, A for left, and D for right. There are no conflicts with these key binds. Track file & DCS log soon to follow.

The score window fails to record any kills. The points work for score but no breakdown on Air, Ground, Ship, Loss. All my settings remained the same. The only thing different was the update to the latest DCS update. dcs.log CaucasusFox2_003-20240711-182117.trk

Flappie, I saw that! Thanks for your help in getting this problem resolved. I will try it out soon enough!

Yes, I too am affected by this bug. I own FC3 and did not upgrade to FC2024. It tried to reinstall itself but after a restart, I get the same message. I hope that a hotfix would be available soon?

When setting Mi-8/Mi-24 to "Take off from Ground Hot" in those locations, I see no discernible difference to the size of the landing pad. I would argue that half of the helicopter slots cannot be used for either airframe. I measured out the width of the pads in the ME. Slots 11 - 16, 18 - 19, and 21 - 28 measure ~68 ft (21 m) wide. The width of slots 41 - 44, 46, and 48 measure ~60 ft (18 m) wide. While I appreciate the realism factor, the larger "locked" parking slots cannot handle the Mi-8/Mi-24 while the smaller "unlocked" slots can handle them. Does that make sense to anyone? Once again, I petition to open the slots to accommodate the larger helicopters.

There are some issues with parking slots at King Abdullah II airport. The size of the helicopter parking slots are too small for the Mi-8MTV2 Hip & Mi-24P Hind. There are about 10 slots available but it looks like more should be available. The only available slots are 03 - 06, 41 - 44, 46, and 48. The remaining slots that should be able to park them are: 11-16, 18 - 19, 21 - 28, 45, 47, and 49. That is 19 slots that cannot accommodate these larger helicopters. I'd also like to point out that slots 03 - 06 are for larger fixed wing slots. Refer to the image that indicates the slots in red that do not allow Mi-8/Mi-24 parking. The green area will allow Mi-8/Mi-24 parking.

Flappie, Thanks for reviewing the track file. I certainly was looking at each Mi-24 when attempting to fire a stinger at it. Did the Linebacker have similar desync issues? When I play in the server solo, the Stinger growl works as advertised. However, when multiple people are in the server using MANPADs or Linebackers (anything with Stingers), the tone is constantly on. It's like a bleed over tone; similar to the RWR bleed over.

@Flappie, I would like to add my $0.02 to this topic. Attached is my track file that happened today. I was testing out a Combined Arms area and about 70% through the mission, I encountered the constant tone of the MANPAD (Stinger) and Bradley Linebacker. There were only 2 players: me in the Game Master slot and another player in the Tactical Commander slot. I controlled a MANPAD while my buddy controlled the Linebacker. This was at Amman airfield in the Syria map. The only way for my buddy to get rid of the tone was to exit the server and get back in to it. I was not lucky since my computer was the host server. So the sound was ever present even when I switched to another vehicle. I switched to a standard M2A2 Bradley afterwards and played with the sound muted. When I tested this in single player (thru Mission Editor), the persistent growl was not present. However, that tone is evermore present in multiplayer. Would this help your troubleshooting efforts? server-20240615-134015.trk

Yurgon, I've seen the issue where it only affects one radio but 3 out of 4 radios. Additionally, if it's an ancient problem then could it be addressed?

Would love to see the option to add/remove the Mast Mounted Sight (MMS) from the Re-arm/refuel menu.

While in the Mission Editor, I noted a bug when changing radio frequencies under the Radio tab. The default radio frequency (above the Callsign options) is linked to Channel 1 on 3 radios: UHF AM, VHF AM, and VHF FM1. A change to Channel 1 in any of these radios will override settings for the other 2. It will either use the minimum frequency or maximum frequency depending on which Channel is first altered. For example: 1. VHF FM1 Channel 1 change to 30 MHz yields a change to VHF AM Chan 1 to 116 MHz, UHF AM Chan 1 to 225 MHz, and Radio Frequency (above Callsign) to 30 MHz. 2. VHF AM Channel 1 change to 120 MHz yields a change to VHF FM1 Chan 1 to 87.975 MHz, UHF Chan 1 to 225 MHz, and Radio Frequency (above Callsign) to 120 MHz. 3. UHF AM Channel 1 change to 230 MHz yields a change to VHF AM Chan 1 to 151.975 MHz, VHF FM1 Chan 1 to 87.975 MHz, and Radio Frequency (above Callsign) to 230 MHz. 4. Change the Radio Frequency (above Callsign) to 310 MHz yields a change to UHF AM Chan 1 to 310 MHz, VHF AM Chan 1 to 151.975 MHz, and VHF FM1 Chan 1 to 87.975 MHz. VHF FM2 radio is unaffected by this bug.

@silverdevil, Thanks for the suggestions. This issue academic since the problem only occurred over those 3 days. Please keep in mind that in the evening of May 22, the download speed and installation process took 45 minutes. From Sunday and most of the day on Wednesday, the update process took over 5 hours before Curl Error (6) would appear. I didn't play with any network settings. The problem appeared to resolve without my intervention. If the problem was on my end, then issues accessing the Internet would be more problematic and widespread to other sites. Since this issue was happening while I accessed the DCS servers, then I speculated the problem rested on the ED server side. Since then, I updated the Win11 QoS levels and also flushed my DNS settings. Moments ago, I pinged the DCS website and the results are as follows: Pinging digitalcombatsimulator.com [93.115.211.146] with 32 bytes of data: Reply from 93.115.211.146: bytes=32 time=120ms TTL=48 Reply from 93.115.211.146: bytes=32 time=122ms TTL=48 Reply from 93.115.211.146: bytes=32 time=120ms TTL=48 Reply from 93.115.211.146: bytes=32 time=120ms TTL=48 Ping statistics for 93.115.211.146: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 120ms, Maximum = 122ms, Average = 120ms In the end, I'd like to think the issue could be a combination of issues. First, a fresh install of Windows 11. It may have some settings that could cause the networking issues. Changing the QoS settings may have helped but that was changed after the fact (and problem resolution). Second, timing could also play a hand at the problem. Maybe there were server issues on ED's side of the fence days before the Phantom release? I find it unusual that on the evening of a big DCS update/new module release that my connection issues with the DCS server suddenly fixed itself. The big mystery is: What fixed the problem?

@silverdevil, Thanks for the reply. While this problem may be atypical, it was very unusual to experience this issue. Especially since I was installing a fresh copy of DCS and having to install 47 modules. While your screenshot looks good, timing is everything. When did you run an update - within the past 2 days? I would argue that last week, there may have been some other factors at play that we aren't privy to? I recall connection/download issues when the Apache & Strike Eagle came out. Perhaps there was some strange Windows 11 setting that needed to be changed? Maybe I needed to sacrifice a chicken, or ask God to change Pepsi to Coke. All I know is there was a problem and hopefully the log file would help. I just want to play DCS and not have to play log file detective. It still grinds my gears thinking about the DAYS of delays and several failures to download/install DCS. It will be interesting to see feedback from ED.

Last week, I encountered the Curl Error (6) when attempting to reinstall DCS from scratch. I am VERY upset because over 3 days, the updater would fail to download and install properly. This also included the Repair process! Refer to the screenshot that shows the data usage (more about that shortly). Additionally, the download process exceeded 5 hours and then fail. I would get the Curl Error (6) message anywhere between the 3 - 5 hour mark. I was unable to run DCS because the initial install produced the same Curl Error (6) message just as it completed. Therefore, Windows would report the program was not installed properly. On Wednesday (the day of Phantom release), the download failed once during the day after 6 hours. The download rate the updater would report was 10-11 Mbps. Later that (Wednesday) evening, the DCS update utility FINALLY downloaded and installed the update. Despite it reporting 11 Mbps, the download/install process took 45 minutes! As another consequence of this failed download process, my computer had a difficult time accessing the internet. Web pages would fail to load and would take 8-10 tries to reload the page. It was PAINFUL to try to update DCS in the background and work from home at the same time. This has NEVER been a problem in the past. Lastly, I want to address the data usage. As a result of these failed attempts to download and install DCS through the update process, it caused a HUGE spike in data usage. My ISP has an upper data usage limit of about 1.2 TB per month. As a result of this update, it rapidly pushed me beyond 950 GB in 3 days! This also coincided with a new billing cycle so I now have to actively manage my data use for the rest of this billing cycle (ends 18 Jun)! This Curl Error (6) problem has to originate with ED servers. I tested my data transfer rates with other products (e.g. Steam) and the transfer rates matched my network settings. I was getting transfer rates that exceeded 95 Mbps. Again, I'd like to point out that on Wednesday evening (22 May 2024), the update process only took 45 minutes instead of the 5+ hours of failed downloads from 20 May - 22 May. Here are the screenshot of data usage that shows the DCS download spike and one of the autoupdate logs. Moreover, this was installed on a FRESH copy of Windows 11. Fresh as in it was installed on 19 May! No 3rd party anti-virus software used, just Windows Defender. autoupdate_log-2024-05-21.txt

I'd like to reiterate the problem and solution here. Problem: An error message will appear stating, "Can not open debriefing file" when exiting a multiplayer map in single player or Mission Editor. The cause: 1. Group Name contains an apostrophe. 2. Slot blocking script references the Group Name containing an apostrophe. Solution: 1. Avoid using an apostrophe in Group Names. i.e. O'Malley, O'Higgins, O'Man, etc. 2. Use dash (-), underscore (_), or no special character. i.e. OMalley, O-Higgins, O_Man, etc. Reference the above posts for examples of a MIZ file that contains a slot blocker with the apostrophe and a MIZ file that does not use slot blocker. Thank you, @Flappie for digesting this thread and providing the space to find the root cause of this problem.

I am resurrecting this thread from the dead because there are some additional overlays that are discussed in this thread on the Mi-8. There are some screenshots that show the results. These overlay files can be edited for anyone who uses multi-monitor displays. The overlays that can be moved around are: Controls Indicator AI Gunner Crew Status Indicator The AI Gunner & Crew Status Indicator overlays can be edited for the Mi-8, Mi-24, and UH-1. Feel free to check it out! Cross-referenced link here: Mi-8 Crew Status Indicator Position

@Usagi, Glad to help! I made a change to the image above and added a post script. Hope that all helps explain things further!

@Flappie, Here is another example of the slot blocker breaking the debrief log in the basic map. DCS log and debrief log included for your review. DCS log calls out the failure on Line 1129: 2024-04-27 04:09:53.782 ERROR LuaGUI (Main): ERROR loading debrief.log: [string "C:\Users\GeoS\Saved Games\DCS.openbeta\Logs\debrief.log"]:41: ']' expected near 'Malley' Debrief log Lines 39 - 51 have the following info: triggers_state = { ['TF-51 O'Malley'] = (this is Line 41) { time = 10.001, value = 100, }, -- end of ['TF-51 O'Malley'] SSB = { time = 1.001, value = 100, }, -- end of SSB } -- end of triggers_state single-quote-SlotBlocker.miz debrief.log dcs.log

@Flappie, I downloaded your miz file and didn't experience the problem. I also made 2 new miz files in an effort to reproduce the results. I was able to reproduce the error! The problem is caused by a slot blocking script. In the original post, the value of 100 is a clue. I use that value in my slot blocking script. I've included 2 versions of the South Atlantic map miz file, one with slot blocker and one without. I also attached my DCS log and debrief log. Line 1411 in the DCS log calls out the error in Line 35 of the debrief log. The debrief log at Line 35 displays: ['Su-25T O'Sheehans-1'] = { time = 0.801, value = 0, }, -- end of ['Su-25T O'Sheehans-1'] Because the debrief log uses single quotes for the string, it generates the error after Su-25T O. Therefore anything after the second single-quote breaks the debrief log. So it doesn't know what to do with Sheehans-1. single-quote-DH_edit.miz debrief.log dcs.log single-quote-SA_Map.miz single-quote-SA_Map-SlotBlocker.miz

@Usagi, The reason why you can't see those overlays on your additional monitors is because they are "below" the resolution of those 1920x1080 monitors. The DCS environment sees your primary monitor as 2560 pixels (wide) by 1440 pixels (high). That primary monitor resolution is extended into those secondary 1920x1080 monitors. Think of those extra monitors as they were your feet. If your feet are a size 7 then they can physically fit inside a size 9 shoe. Your feet have a lot of room in those size 9 shoes! The same applies to those additional monitors. They can only display a 1920x1080 picture but DCS thinks they are the same height (1440 pixels) as your primary 2560x1440 monitor. Basically, your DCS screen resolution should be around 6400x1440 because it adds up the total width of all those monitors while maintaining the height of your primary monitor (1440 pixels). All of those 1080 pixel "feet" fit inside the 1440 pixel "shoes" with a lot of room to spare. For single monitor use, the default overlay locations work well. However, when adding multiple monitors of different sizes, then their locations become hidden. This is because those smaller monitors cannot "see" the location of those overlays despite DCS "telling" the overlays to show up at the bottom right corner of the screen. As an example, this is a basic graphical representation of my monitor configuration. I use 3 small 800x600 monitors plus my primary monitor in DCS. This works well for the F/A-18C Hornet. When I'm not flying the Hornet, these extra displays are normally blank. When they are not displaying MFD information, I use them to display various overlays in other modules, like the Mi-8, UH-1H, and a wide array of others. Does that make sense? P.S. I replaced the image with this one. The yellow box shows the resolution of the monitors that DCS will see. According to DCS, my monitor resolution is 4960 x 1440. So anything below the visible range of these 800 x 600 monitors will be hidden from view. However, it will be visible when taking screenshots or when pressing Alt + Tab to cycle between windows. HINT: When making adjustments to the overlays, use Alt + Tab to cycle between windows to quickly identify their position. You can also keep the LUA file open in Notepad++ to change values. Be sure to save the LUA file before resetting the scenario. Additionally, use the "Fly Again" button to reload the scenario. The LUA file will be reloaded with the new changes and saves a lot of time reloading a mission.