GeoS72

@-Rudel-, what is the possibility of the Corsair being "slammed" on the deck during spawn-in to cause the tail to shear off? Hmm...what if the damaged landing gear (potentially tail wheel) causes the Corsair to spawn farther back? Maybe the carrier can't "see" the tail wheel and positions the main mounts closer to the deck edge. This would in turn cause the tail to hang over the water and shear off during spawn-in. As noted in this track file on an ashore parking spot, the plane is violently dropped after the repair cycle is completed. Imagine the plane being dropped during a spawn that is ~60ft above ground. Does my hypothesis have merit? 2025-09-18 Corsair Repair x2.trk

@-Rudel-, Attached is my track file. This was part of the Cold Start training mission. Upon spawn-in, I performed a repair. Afterwards, the plane was "slammed" onto the deck. Then I performed a 2nd repair and the process repeated itself. If the plane had 0 damage, the repair cycle would not be initiated. However, the ground crew repaired the plane twice and it was still broken. 2025-09-18 Corsair Repair x2.trk

"Gentlemen, please rest your sphincters." Let's stay on the topic of differential braking. Any argument over the damage model can be discussed in the appropriate thread. The cross-reference to the damage model was made. Additionally, check out Rudel's thread for squashing bugs. There are a couple of links to it in this thread already. Are we disappointed about several issues with the Corsair? Yes! Is the damage model still broken, despite the note of it being fixed? Yes. How often do we read about a fixed bug that was contrary to the report? Lately, it happens pretty frequently. Are we frustrated? Yes! How can we help solve the problem? Report the bug and provide follow-up in the right thread. Do you know what would be great? Seeing how quickly M3 fixes the differential braking problem. Maybe we can get some resolution in the next update? Until then, the Corsair's wings are clipped. She's grounded until further notice. Moving forward: The differential braking problem is reported and M3 has it on their list of bugs to squash. If there are new users who just got the Corsair and wish to complain about the same error, then please do so. There is no need to further speculate potential causes. State your observation: Can't turn on deck in X training mission, need full power to turn in Y instant action scenario, or can't turn on deck in Z multiplayer mission with wind.

As you may or may not recall, Rudel stated the devs were addressing engine management issues. Then they would look into the diff braking issue. Aside from the damage model verification, the Corsair remains grounded.

@JupiterJoe, did you try the repair method to test your claim?

@-Rudel-, Would you be able to broach that subject with ED as well? You may have more clout than just little old player(s) like myself.

When spawning a Corsair on a Nimitz class carrier, the plane immediately takes damage. The client plane is "cut in half" upon spawn. The ME setting for this group was Take Off from Parking Hot. Could the spawn point for the Corsair be moved further up to avoid this bug? See image for spawn location being too close to the edge. As a side note, Take off from Runway puts the Corsair on the Catapult. Without any external stores, you could take off without crashing. There was no need to salute to start the sequence.

It's been a while since I last played with the DTC. However, the DTC only works with limited aircraft. The following method is pretty solid. Edit the frequencies from the radio tab on each aircraft type. For example, list out all the radio freqs for the 50 channels in the F-14B. Once you are done, click on the "copy settings" icon from the Airplane Group dialog. It is located next to the field labeled TAIL #. Another window will open to the left. Check the Radio Settings box, select "All Allied units of this type (BLUE)" radio button. Then press OK. All of your F-14B aircraft will now have the same radio frequencies. Does that help? The location of the Copy Settings Button: Check Radio Settings, select the radio button: All Allied units of this type (BLUE). Then press OK.

I would recommend following jonsky7's advice. My observation to your monitor config lua - verify these entries are accurate, including UPPER case: UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center

I wouldn't call Spud's video recommendation a bug fix. That's more like masking the symptom. Not to mention, will you spend the time to edit all the training mission and scenario files after each DCS update? It may be viable for mission creators in a multiplayer environment. However, even with a small amount of wind, steering is hard to control. I would also argue that having a small amount of wind at 33ft helps to dissipate any smoke over the airfield. Otherwise, the smoke will bellow and completely mask the landing area. I do hope that Magnitude 3 remedies this problem sooner than later. As previously stated, I will not fly the Corsair until this bug is resolved.

hreich, This may sound simple but would like to confirm: Have you verified the position of each monitor in Windows prior to running DCS World? I have to manipulate 2 of my monitors from the Windows Display Settings before I start DCS. In my instance, two of my MFD display swap (e.g. Left MFD becomes Center MFD, Center MFD becomes Left MFD). Additionally, the arrangement & alignment of your monitors are unusual. Are you using an iPad to export 2 MFDs and another iPad to export the AMPCD (Center MFD)? Is the resolution of Monitor 3 2048x1536? The alignment of Monitor 3 is not aligned to the left margin of monitors 1 & 4. Could you share a screenshot of your monitor setup from Windows Display Settings? Is it possible to change the resolution on Monitor 3 to match the others (1920x1080)? Then it could be placed below Monitor 2 and provide good alignment. What is the resolution that DCS sees? How is your monitor configuration file setup? Here is my example: Monitor 1 is the main viewport (2560x1440). Monitors 2 - 4 are small 800x600 monitors that are used for Left MFD (#2), Right, MFD (#3), and Center MFD (#4). I have to swap monitor 2 & 4 to correspond the displays to the Cougar MFD panels. In my example, DCS sees a resolution of 4960 x 1440. DCS will generate objects in the invisible portion (below monitors 2 - 4) but I will never see it. I have specific coordinates in my monitor config file to prevent DCS from showing objects below monitors 2 - 4.

@sirrah, I found a similar solution. I made my own animated image by using several PNG frames from a video. I used about 100 frames. Set each frame to start 0.1 sec (60 frames/sec) and presto. This facility is crude but adequate... It works but it bloats the MIZ file. I believe an animated GIF or PNG file would be a more civilized approach.

I'd find it very entertaining to see the phrase "One Ping". Just one of many quotable quotes from Hunt for Red October.

@Floyd1212, Thank you for those supportive words and sharing a sentiment that has been brewing inside for some time. Please read along! @BIGNEWY, I digress from the main topic for a moment to address these sentiments stirring from within and as Floyd1212 kindly shared. Allow me to share my passion and support with the following: 1. I own just about EVERY module, terrain, asset pack. The few that I don't own are the Christen Eagle, MiG-19, and Hawk. I currently have 2 modules on pre-order. 2. I am one of those passionate players who support Eagle Dynamics and other third party developers. Not a day goes by without friends & family hearing me preaching from the gospel of DCS World. 3. I created a virtual squadron and rent a Fox3 server to host unit events. We play on a weekly basis and enjoy the camaraderie that often comes from military veterans. I am a proud veteran and many of my squadron-mates are also vets. This is where we go to "unplug" or decompress after a stressful week at work. 4. The modules that I fly the most are the F/A-18C Hornet and the AH-64D Apache. I would say that the hours spent in the Apache has surpassed the hours of time spent in the Hornet. Fun fact: I worked on the F-14A/B/D Tomcat and F/A-18C Hornet for many years. So you could say that I know a thing or two about these aircraft. 5. I own a few pieces of kit to help support my DCS "habit" such as WinWing F/A-18 Throttle, Stick (plus the F-16EX grip), Virpil rudder pedals, TrackIR, Cubesim monitors, and Cougar MFDs. All of these devices yield a benefit that I take full advantage of, chiefly to aid my aging eyes. 6. I have the pleasure of fixing several issues with the core and module-specific bugs. Three that come to mind: Constant heat seeker tone when playing as a MANPAD unit in Combined Arms, base coordinate error in the South Atlantic map, and the F/A-18C Pilot survival rate(*). Many of these bugs were left untouched for 9 months or past 1 year after being "fixed". As I recall, the IR tone for the MANPAD was supposedly fixed 1 year before I re-addressed the topic. Here's a 4th change: I was also responsible for pushing for a change in how sound files are stored in the mission files. Before, certain sound files would arbitrarily reset. That's like playing a game of whack-a-mole in a large multi-player mission! * - You fought me and other clients tooth and nail - claiming the pilot survival rate was perfect. It was FINALLY changed after an outcry from several Hornet players and supplying data to back it up. 7. While I don't play DCS every day, a large part of my weekends - Thurs through Sun revolve around playing in one of my squadron multi-player missions. It's not uncommon for me to fly for 6+ hours per day. 8. There feels like there is an "Us vs Them" mentality when it comes to reporting bugs. It appears the stance from any ED team member is denial of a problem or at least deflecting the problem to a user-induced problem. I'm sure there's data that may prove casual users induce many problems. For many years (and still ongoing), ED counts on a core of passionate players to submit bug reports or suggestions to make each module better. Which was the reason to have an Open Beta branch. However, constantly saying "there's no problem here" or to dismiss a bug/suggestion because I represent a small percentage of players is flatly a slap in the face. Your model for improvement was centered on player feedback. 9. I believe that a module dies from a thousand "paper cuts". I mean to say that while a module may provide a lot of features, there are fine cracks that can be easily seen when looking beyond the casual player's mentality. Here is where attention to detail will spell success or failure for a module. Hey, I want to do X...too bad. Not supported. Why is feature Y broken? You represent a minority so don't hold your breath for us to fix it. Oh, an update just broke my helicopter. Each time I start the aircraft, the CPG windshield wiper turns on and will not shut off (where have I seen that problem manifest?). 10. ED needs players like myself and Floyd1212 to identify bugs and provide invaluable feedback to improve each module. I have ranted long enough. There are a few more points that I wish to address but this is long in the tooth already. Please do not misconstrue my talking points as a personal attack or making ED appear to be the bad guy. That is far from the case. I wish to point out some examples as a learning process. I am always available to talk via DM, Discord, email, and/or experience my squadron. Send a DM if you would like to set something up. Getting back to the AH-64, I really believe ED hit one out of the park when this module was initially released. If it supplanted my time in the F/A-18C Hornet (and knowing my background) then that's one HUGE compliment! There are many small improvements that need to be made to make it a superior module. Dare I say it should be a flagship module! Making adjustments to the TEDAC display is one and wrangling GeorgeAI is another avenue for improvement. But dealing with GeorgeAI is a topic for another thread! How's that for passion and support? Now, for a little humor and to paraphrase Pulp Fiction: can we, pretty please with sugar on top, fix the effin' Apache?

@BIGNEWY, ED Staff, @jonsky7, and fellow users, We need to garner more attention to this bug. We are 1 month away from it's 2yr anniversary and little to no action was taken to resolve this problem. If you are passionate about this module then please speak up! We need to upgrade this bug from "Reported" to "Fixed". The TEDAC remains ON after leaving the CPG seat and will remain ON until the client leaves the server or restarts DCS. During 1 multiplayer server session, it doesn't matter if the client changes to a different aircraft, such as F/A-18C, F-16C, CH-47F, etc. After the client picks another Apache pilot slot, the TEDAC will be ON and the image will be frozen from the initial CPG instance. Furthermore, the Autopilot ControlsIndicator overlay is masked by the TEDAC display or blank out screen when in the Pilot seat. That is another problem because modifying the ControlsIndicator.lua file will fail Integrity Check (IC). I have a separate thread about that problem. Speak up and let your voice be heard. The more people complain about this problem should help to resolve this issue. I'd like to play more as the CPG but this bug prevents me from jumping between seats since the frozen screen presents too much of a distraction. I need your help to bring resolution to this problem. If you have time to press the "Like" or "Thanks" button, then please take a moment to comment. It's time to fix this TEDAC bug!