GeoS72

Thank you, Flappie!

Moderators, Have you seen this problem?

After today's patch (09/30/2024), the detailed scoreboard is still not fixed.

This problem still persists. I attempted to create a "dummy" MIZ file and then copy most of the relevant lines of code from the suspect file into the dummy file. The problem carried over to the dummy file. Any suggestions?

I encountered a strange error last night while playing a closed mission with my squadron. The problem: Multiplayer slot is locked or denied to a client after the unit is dead or the client despawns. This happened in the Sinai map. See attached DCS log but I didn't find any errors that would cause this type of problem. This problem affected any client who crashed/despawned. I checked the airfield assets. All aircraft set to unlimited. No dynamic slots were used. I also compared the mission settings to another multiplayer map. The settings are identical. Has anyone else experienced this problem? I didn't see any threads that would compare to this problem. dcs-2024-09-05 Pharoahs Fate.log

@Flappie, thank you for the post. I will test it shortly.

Confirmed, the detailed score is still broken in Multi-Player. I am puzzled why there was a fix for the Single Player detailed score. Perhaps that is used as a baseline for Multi Player?

@74DELTA, Good to hear that your problem was solved. Thank you for sharing the solution to your problem. Even though it was a self-inflicted wound, you recognized the problem and fixed it. Well done! Just to clarify the file location for SimpleSlotBlockGameGui.lua: It should be in the Saved Games folder: C:\Users\UserName\Saved Games\DCS\Scripts\Hooks

All, While reporting that a problem was fixed is good for you, providing the solution to your problem would help the next guy a lot more. For example, downloaded the current lua file (if possible, cite location) then pasted file into the correct folder (state which folder). Or say, "modified line x in lua file from value A to value B." Thank you!

I confirmed the problem is still present. Multiplayer scoreboard has not been addressed.

In this multiplayer server, I flew into Al Dhafra. First target was T-90 MBT. George lased & fired. Target destroyed. The 2nd target was a Shilka. I had to cycle George AI twice in order to get him to lase & fire. Range at time of fire was ~6,800 m. I'd also like to point out that I was well inside the 8,000 m range and George refused to lase. I was flying right towards the Shilka at a 12 o'clock position, so my path was stable. DCS Log attached & link to download the track file is on my Google Drive: Link to PersianGulf_007-George AI No Lase.trk So now this bug is marked as W.I.P., what exactly does that mean? Are there any timelines established to address this problem? dcs.log

So, will the TACAN channel bug be addressed in this next update? Or would it get worse with new airfields to be added?

@Hootman9104, @LittleNose, et al: When you encounter such problems, please help out the effort in resolving this issue. Post your dcs log and track file along with a description of the incident. The more documentation we provide, then it should help refine the AI logic.

@Lord Vader, Please review my last track file (PersianGulf_007...). While attacking targets at Liwa, I was well inside 6,000 m, had a good line of sight, slowly advancing on targets, and was stable. I'd also like to point out that the number of times the AI would lase between 9999 m and 8,000 m is anywhere between 4 - 5 times, depending on aircraft speed. That's about 9-second intervals from "Laser Off" to "Laser On". Once inside the 8,000 m range, the periodicity of AI lasing is erratic, sporadic, or unpredictable. I can't speak for others, but using workarounds can only go so far. I find it odd that not a whole lot of people have complained about this lack of performance; or at least made a bug report. There aren't a lot of threads that cover this specific discrepancy, and if there is a thread about it, then there are a lot of conjecture and no results. It is very bothersome that the AI would fail to lase or even refuse to fire a missile when it appears that all constraints to designate & launch a missile have been met. If you pardon the pun, I spend a lot of time "force choking" the AI to do it's job. When seconds count for the AI to lase & fire, that's when it will fail you. That becomes VERY frustrating when you have to fly 15+ minutes to a target then get shot down because the AI failed. That sucks the fun right out of playing DCS. Would you agree? Will any of these track files be used to further dissect this problem?

On tonight's track file in a Persian Gulf multiplayer server: 1. Take off from FARP Rome to capture Liwa. 2. ~20 flight from FARP. 3. George AI lased the first 3 targets: 3.a. SA-11 Command Center, began lasing ~8,700 m. Consent given at 7,800 m. Missile fired ~ 7,700 m. Target destroyed. 3.b. EWR, began lasing ~ 5,000 m. No consent given. Target destroyed by pilot (me) with Gun ~ 800 m. 3.c. SA-11 Launcher, began lasing ~ 6,000 m. Target destroyed by pilot (me) with Gun ~ 900 m. 4. All remaining targets (~6 total) at Liwa were designated by George AI but NO laser ranging info obtained. George AI set to "Yellow": Consent to Fire required and Hellfire Lima WAS'ed. Pilot did not intentionally cycle WAS for George AI. 5. All remaining targets destroyed by pilot (me) with Gun ~ 900 m or less. 6. Base captured with only 1 missile launched, all remaining targets destroyed via Gun. PersianGulf_007-20240727-205351.trk dcs 2024-07-27 Liwa 6 targets no lase.log

Thank you, @Flappie for reporting the detailed score!

Here is a 2nd set of files that should show when George AI wouldn't lase or fire. dcs fail2Lase-Fail2Fire-2nd time.log DH Fail2Lase-Fail2Fire-2nd time.trk

I used this map for the most recent testing. Test Range.miz

Here is another set of files. George had several failures to lase & fire in a generic Caucasus map MIZ file. dcs Fail2Lase-Fail2Fire.log DH Fail2Lase-Fail2Fire.trk

Here is tonight's issue on my Syria base capture map (played in single player): George AI lased the first target 4 times outside of 8km. George did not lase again but I got a "within range" message. The target data went from ~8400 m to ~7,800 m without the need to lase again. I gave the consent to fire and George AI fired a Lima. I also want to point out that there should have been a 5th time George AI would lase the target based on his earlier cadence. After the target was destroyed, George AI acquired the 2nd target but took a while to lase it. It was well inside 8km and no issue with George firing a Lima. dcs 2024-07-24 Syria.log DH Messeh-4x Lase.trk

Also posted on 7/13/2024: Here is another DCS log and link to a Fast Mission from the Sinai map. I also do not understand why this thread is heavily restricted with file sizes. The link is about 18.5 MB and showcases the problem of firing on the VERY last target, a T-72 MBT. Fast Mission-Sinai-Last Tank No Fire dcs 2024-07-13 FastMis-LastTankNoFire.log Posted on 7/19/2024: Ok, here are 2 sets of log/track files for a test mission in the Caucasus map. I wasn't able to duplicate the problem as we described above. However, I did experience 1 laser ranging event at a range of ~9,900 meters then got no other lase events. After flying towards the target range, George AI gave me an "in-range" at ~7,800 meters. There were no other laser ranging events. This happened when targeting the 1st vehicle on both runs. dcs Test Pilot 1st Target Long Wait-2.log dcs Test Pilot 1st Target Long Wait.log DH Test Pilot-Long Wait 1st Target.trk DH Test Pilot-Long Wait 1st Target-2.trk One more post on 7/19/2024: This track should better show the ranging issue with the first target. George lased target at ~9.6km and then nothing. I cycled his status from MSL to No WAS and then back to MSL. He said target was within range but did not lase at first. The range was at 6.8km until he lased the target again. This problem appears to happen when there is more action occurring in the battle space. So more data is needed. Additionally, this issue is problematic to capture for me. There are days when this bug happens frequently while other days, it's not a big deal. dcs DH Test Pilot-1st Target Range Issue.log DH Test Pilot-1st Target Range Issue.trk

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 on Jul 13. So here is a link to my track file (much larger than his) and my DCS log. PersianGulf_006 Track File I'd certainly like to see some resolution to this persistent and annoying problem. This issue was originally addressed in this thread: George Wont Fire Any Hellfires More track & log files to follow. dcs 2024-07-13.log Original posted on 7/13/2024: Here are DCS log & Track files from a Fast Mission (creation) that was in the Sinai map. This track should show the number of times that I had to manually cycle George AI from WAS'ing MSL to De-WAS then back to MSL in order to get ranging info. A lot of the time, this range was under 5km. There were also several instances of George AI not firing after consecutive consent to fire orders were given. Fast Mission Tracj 2024-07-13.trk dcs 2024-07-13 Fast Mission.log

First, I'd like to point out that the OP never got any resolution to his problem. Second, others (myself included) believe that it was unnecessary to start a new thread in a different section because the problem was similar. There was no need to start a duplicate thread. Third, if there was a solution then it was not obvious. Standby for a new bug report to document my findings. Cross-referenced bug thread to post problems with George not lasing/firing Lima missiles: George AI and AGM-114L Lasing-Fail to Fire

Well, I'd like to use an electronics term to best describe the resolution to this problem: PFM...Pure eFfing Magic! It looks like the problem resolved itself. Don't know how or why. I mapped the following HOTAS for Left/Right movement and tested in the Caucuses map: WinWing Throttle Ry Axis: Pass WinWing F-16 X Axis: Pass Virpil Rudder Z Axis: Pass* * - this was the original axis that failed; even after several axis tunes. Suddenly, it now works. Maybe mapping to the other axes helped? With each of these axes bound, I was able to use the keyboard commands (A & D) to steer left/right.

Draconus, thanks for the feedback. Which axis did you have bound for steering? I wonder if there is a specific issue with binding rudder pedals for steering. I will have to test it further. All I know and experienced is this: Before this patch, I could use either joy axis (rudder) or key binds A & D to steer a Combined Arms vehicle left or right. Currently, the key bind for accelerate and brake (W & S) work in conjunction with the axis bind for right toe brake. If the key binds were fighting with the axis bind then some unusual movement should be observed. However, there is no unusual movement. The vehicle tracks straight; if A or D is pressed, then no movement occurs. The only time the vehicle turns left or right is when the rudder axis provides the input.