GeoS72

@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!