GeoS72

Addendum: What is the best course of action? The hacks that some presented are user workarounds to a problem. That easily has negative consequences when attempting to taxi a Corsair ashore or afloat. Taxiing under high engine RPM to lift the tail wheel is NOT recommended. It can spell disaster when completing a single-player campaign, multi-player mission, or other evolution.

@JupiterJoe, @Doughguy, & @-Rudel- Here are my tests in an F4U and P-47 with diff braking. See relevant track & MIZ files. These conditions are confirmed: 1. Damage to Corsair at initial spawn. 2. Corsair "slams" on deck after repair - potentially damaging tail wheel; no notice for sustained damage. 3. Poor turn radius with tail wheel unlocked (before and after repair). 4. Sharp turns in Corsair under 0 wind conditions by increasing engine to takeoff speed. Tail lifts off deck and diff braking is achieved. 5. Demonstrated the dangers of diff braking with high engine power & tail off deck in the Corsair. 6. Corsair track file with repair has accelerated time after initiating the repair cycle. 7. P-47 repair cycle NOT triggered at spawn point. 8. P-47 can perform sharp turns when engine near takeoff power. Tail lifts off deck & diff braking achieved with tail wheel locked. 9. External views yielded a visual difference between Corsair & P-47 tail wheel caster effects. Corsair shows limited, approx (+/-) 20 deg caster; P-47 tail wheel showed 90 deg caster. Conclusion: F4U-1D Corsair tail wheel model appears to be damaged at spawn and/or aircraft has too much weight on the tail wheel to prevent full caster. @JupiterJoe, I never put a lot of thought behind the repair cycle for aircraft. Thanks for sharing that pearl of wisdom! 2025-08-16 F4U Turn Rate-No Wind.trk 2025-08-16 F4U Turn Rate-No Wind-Repair.trk 2025-08-16 P47 Turn Rate-No Wind-Repair.trk Corsair-Turn Test-No Wind.miz

@-Rudel-, have you independently confirmed this bug exists, besides reading this thread? Making sharp turns in the Corsair is not possible in its current state. Do you require more information or data? Are you suggesting that the users are SOL ("Still" Out of Luck) for differential braking?

Gents, Raising the tail does not require additional wind on deck. Increasing throttle above 30 PSI of manifold pressure raises the tail off the ground. This is covered in one of the Training Missions for the Corsair. When the tail comes off the ground, you can release 1 brake pedal and the plane will pivot on the held brake. It is VERY precarious because you can easily nose over. I wish to reiterate: If you have to go full throttle, stand on 1 brake, and add rudder (rudder yields no result, btw) just to make a sharp turn in the Corsair, then something is flat-out wrong!

@Skyspin, Confirmed. I just tested the diff braking effect. It's still broken. There was no mention of it in the change log. I wanted to see if the problem was secretly solved. That is a resounding "NO." Can we get a few more Corsair flyers to chime in, please? We need to squeak more loudly to get some grease.

@Cgjunk2, Thanks for the confirmation. I agree with your remarks! I attempted to put things into perspective when it comes to fixing bugs. I would bet dimes to donuts that other game-braking things would be a higher priority to resolve. For example, crash to desktop, incurring damage/landing gear collapse just by spawning into the unit, or engine explodes when applying throttle past 50%.

@flanker0ne, Thanks for the suggestion. However, my test resulted in no action being taken. For example, after moving the switch to PTT (Push to Talk) in multiplayer, I would hear a distinct audio pop to indicate the mode changed from VOX to PTT. There was no audio pop to indicate the ICS mode change. This is a problem that should be investigated further.

GTFreeFlyer, Good for you to put a lot of faith into a dev to rack & stack their priorities. I ask about the priority to resolve this issue because it can be easily overridden for a seemingly nice-to-have feature. How many times have we seen DCS World (in general) or a module break after introducing a new feature? More importantly, how long does it take for that broken feature to get repaired? Do you remember how long it took for ED to fix the Multiplayer Scoreboard? The answer is ~ 9 months. I suspect it would have been longer had it not been for users to complain often about it. Fixing discrepancies in DCS is a topic for another time. Getting back on-topic of differential braking: If you have to go full throttle, stand on 1 brake, and add rudder (rudder yields no result, btw) just to make a sharp turn in the Corsair, then something is flat-out wrong! There is a problem with the flight model regarding tail wheel castering/differential braking physics. The Corsair should be no different than any other tail-drager when taxiing with it's tail wheel unlocked. If I can't easily taxi this bird on the deck then it will collect dust. It would be a shame if this problem does not get addressed. To sum things up, diff braking is broken for the Corsair. It affects basic ground/flight deck handling. Many users, like myself, have issues with it. I would like to see this problem get addressed sooner rather than later. This shouldn't be the top priority but should be grouped with higher-priority items.

@Saxman, thanks for your research into the gun convergence problem. What was the historical preference for these range settings? What was the yardage recommendations for outer, middle, inner guns?

Keybind problem solved. Moderators, please close this thread.

The differential braking bug still persists. I uninstalled the module then reinstalled it. No difference after the re-installation. The diff brake and tail wheel performance remains unchanged - difficult to make the appropriate turns while on deck (CV or land-based). @-Rudel-, how does this stack up in the priority list of bugs to address? @_Hoss, you are very fortunate to not have any issues with steering on deck! I made some small adjustments to my brake & rudder curves but nothing as substantial as yours. Additionally, applying rudder + brake in the direction of the turn has 0 effect on the turn radius.

@BIGNEWY, your recommendation requires many of us to change some in-grained procedures. The additional commands to lase/de-lase the target while GeorgeAI is de-WAS'ed will help. However, there are many instances where George AI would not lase/fire given constraints being met. It will also be helpful to add the laser on/off command while RF missile is selected. Since there are times when maneuvers must be performed and the range to target or target orientation has changed. I have a wish list thread here for it: GeorgeAI Additional Function to RF Missile. Let's keep this thread going for more input, please.

@BIGNEWY, et al: Here is an example of GeorgeAI lasing a target beyond 8km then not lasing afterwards. He designated the target approx 2 times from 9999+ meters. The range decreased down to ~8,400m then no more lasing. I flew up close until landing next to the target. All the while, he would not lase. I purposely did not change any settings because I wanted to see if he would lase the target. This is EXACTLY what I talked about in my previous thread here: George AI and AGM-114L Lasing and Fail to Fire Problems. See my track and MIZ file. 2025-07-31 GeorgeAI-No Lase.trk AH-64 GeorgeAI Test.miz

The keybinds are missing for the Intercommunication System (ICS). Specifically, the ICS Mode Switch - HOT MIC, ICS Mode Switch - PTT, and ICS Mode Switch - VOX keybinds do not work. My controller can bind to them however, nothing happens when placing the switch to those positions. The ICE Mode Switch - Down and ICS Mode Switch - Up keybinds work without issue. For the record, I bound the Up and Down keybinds.

I'm surprised no one has mentioned adding this beauty! Devs, can we get the AGM-114R9X, also known as the "Flying Ginsu"? Pretty please with sugar on top! I believe every MANPAD should be taken out with the Flying Ginsu. Let me head off the excuse generator. Here's a brief video overview of it working. If you can develop the F-35 from white papers, then this should be viable!

I have a recommendation with all of the new GeorgeAI features incorporated in the Jul 23 update: I noticed the ability of GeorgeAI to lase a target when de-WASed by short press right on the GeorgeAI panel. Again, that is while the CPG has nothing WASed. Would it be possible to add the same "lase" command while the RF missile is selected? See my screenshot as an example. In this example, the "DESIG AGAIN (Designate Again)" function would be similar to the "Laser On" function when the AI is de-WASed. This would force the CPG to lase the target and send target data to the RF Hellfire before a launch. A short press to the right would allow the CPG to momentarily lase the target again for a firing solution. For those who need a graphical reference, this is the option that I mentioned above. When flying in a multi-crew cockpit, I would often ask my human CPG to redesignate a target to ensure the AGM-114L Hellfire has accurate data. This is very helpful after evading incoming missiles or negotiating terrain to a different location. Cross-referenced from this thread: GeorgeAI and AGM-114L Lasing and Fail to Fire Problems

Merci, Flappie! I know you are the messenger in this instance. I am sorry to hear the devs will NOT consider this request. I think they are dead wrong. It is a shame! Besides, who needs the ControlsIndicator overlay? So what if it's out of my monitor's viewable area. Embrace the charm that is part of the FC3 experience! Perhaps more FC3 clients would chime in to create the demand?

@jonsky7, @MadKreator, & @Deezle, Thanks for researching this display export for the Hook! I noticed the contents of the MFD_device_IDs.lua file identifies the MFDs as follows: "CO" - co-pilot outboard "CI" - co-pilot inboard "C" - center "PI" - pilot inboard "PO" - pilot outboard MFD_SELF_IDS = CO = 0, CI = 1, C = 2, PI = 3, PO = 4 My multi-monitor config includes the use of 3 CubeSim 600x800 monitors plus the primary 2160x1440 display. I played with the MFD_init_copilot_in/out.lua and MFD_init_pilot_in/out.lua files to see if they would alternate between positions. Foreshadow: it didn't work. Both pilot & copilot displays were overlaying on top of the other. I'm not a coder so break stuff but not confident to fix it. Here is what I modified for the copilot files: MFD_init_copilot_out.lua (lines 17 - 18): 17: update_screenspace_diplacement(0, true, 0) 18: try_find_assigned_viewport("CH47_Copilot_LEFT_MFCD") MFD_init_copilot_in.lua (lines 17 - 18): 17: update_screenspace_diplacement(1, true, 1) 18: try_find_assigned_viewport("CH47_Copilot_RIGHT_MFCD") I made a separate entry on my monitor config file to add the correct viewport for CH47_Copilot_LEFT/RIGHT_MFCD. I also used the "0, true, 0" and "1, true, 1" displacement values to aid in monitor identification. It did not help. I also changed the displacement values in the pilot position to "3, true, 3" and "4, true, 4" respectively. Again, this was no help in blanking the copilot displays while in the pilot seat and vise versa. The blanking of the displays when the player is not in the corresponding position is very similar to the AH-64 TEDAC blanking issue when switching from CPG to Pilot seats. @jonsky7, you initiated that TEDAC thread almost 2yrs ago too. The solution you guys provided is a good start! For now, the pilot displays are presented on my CubeSim monitors while in any other crew position. At lease they respond to input from the Copilot seat. Ultimately, I believe this problem should be resolved by ED. What do you guys think?

For those who need a graphical reference, this is the option that I mentioned above. When flying in a multi-crew cockpit, I would often ask my human CPG to redesignate a target to ensure the AGM-114L Hellfire has accurate data. This is very helpful after evading incoming missiles!

@Flappie, Merci beaucoup!

@BIGNEWY, Thank you for breaking the silence on this thread. I also noticed the tag was changed from "investigating" to "reported". Given your reply, it appears the tag is a downgrade. From the perspective of a guy with multi-monitors, this annoyance discourages multi-crew flights. Additionally, the frozen TEDAC screen will be on during the same session, regardless of other aircraft used in between. So if I were to fly as CPG then switch to flying an F/A-18, F-14, CH-47, etc, and then return to Pilot an AH-64, the image that remained in the TEDAC display will once again reappear and not go away. The only way to remove it would be to start a brand new mission, leave the server & rejoin, or restart DCS. That is a "less than optimal" solution to this problem. While this bug is a low-priority, it will quickly come up on a 2yr anniversary; 1st reported by @jonsky7 on 25 Oct 2023. What is needed to elevate this task to a higher priority? How much more time will pass before this problem would be resolved?

@_Hoss, I don't understand why some people don't have an issue while others, like myself, have the issue with diff braking in the Corsair. I confirmed the problem still persists after the Jul 23 update. @-Rudel-, do you have visibility on this issue?

@BIGNEWY, this is becoming more and more frustrating. Can this problem be addressed, please? Can we get some further traction other than "Investigating"? I could avail myself for a Discord chat or other means to dialog about this long-standing issue. Here are more items to point out about the TEDAC display. 1. Spawned in first AH-64 in Pilot seat. 2. Autopilot Controls Indicator display blocked by black overlay. 3. Switched to CPG seat, didn't play with TEDAC. 4. Jumped back to Pilot seat, TEDAC display still on; Auotpilot Controls Indicator display blocked by TEDAC display. 5. Spawned in to new aircraft, CH-47F. Nothing unusual about the displays. 6. Spawned in to a second (different) AH-64 in Pilot seat. 7. TEDAC display still on from the first spawn! It was immediately present because the rest of the cockpit was still being rendered. Notice the blurry segments? First screenshot represents first spawn. This was taken after I moved from Pilot to CPG then back to Pilot seats. Note the Yellow Box showing the TEDAC overlay and the purple arrow shows the Autopilot Controls Indicator being blocked. Afterwards, I spawned into a CH-47, nothing unusual with the displays. Unless you count the Left MFD not being displayed. Lastly, I spawned into a different AH-64 slot, in the Pilot seat. While the cockpit was being rendered (see blurry segments), the TEDAC display remained on. That was 2 aircraft spawns ago! Why does the TEDAC display remain on after switching between 3 different aircraft slots?

@BIGNEWY, The GeorgeAI is getting better. It still has issues lasing a target. Hearing him say, "Constraints" is a good reminder to line up the shot prior to missile launch. I can't imagine the struggles the ED team had to work the kinks out of this new system. Well done! I have a recommendation with all of the new GeorgeAI features incorporated in the Jul 23 update: I noticed the ability of GeorgeAI to lase a target when de-WASed by short press right on the GeorgeAI panel. Again, that is while the CPG has nothing WASed. Would it be possible to add the same "lase" command while the RF missile is selected? See my screenshot as an example. In this example, the "DESIG AGAIN (Designate Again)" function would be similar to the "Laser On" function when the AI is de-WASed. This would force the CPG to lase the target and send target data to the RF Hellfire before a launch. A short press to the right would allow the CPG to momentarily lase the target again for a firing solution. I can create a wish list thread for this idea, if you'd think it would help.

@Saxman, thanks for the clarification! I'm not sure why I didn't understand it at first.