GeoS72

I did a bunch of stuff back in March & April. The problem was on their end, not mine. The problem eventually resolved itself without much fanfare or even them contacting me to verify the problem was fixed. Their customer service reps said the "fix" would take several months. And they weren't kidding. I can now use my VPN while playing DCS. It took about 5-6 months to fix but it works now.

@-Rudel-, et al, My 'tism is kicking in when reading the problem with Differential BRAKING. I'm sure we all know the definition of brake however, there are some posts (including the M3 list of bugs) that conflate the spelling of it. Brake/braking/braked = application of a force to slow down an object. For example: My foot applies pressure on the car's BRAKE pedal to reduce vehicle speed. Break/breaking/broke = to separate an object into many pieces or to damage an object. For example: A car's camshaft can BREAK just by dropping it on the floor. Another example: A car's hydraulic rubber BRAKE line can BREAK when it is very old and too much pressure is applied. Again, I'm sure we are all thinking of the same thing. However, reading it causes all sorts of trouble in my head. And one could easily say: I'm taking a break from flying the Corsair because of its Differential Braking problem.

Gents, to be fair: please refer back to the post Rudel made about Acknowledging Bugs/Request List. This problem is cited on their Bug List and he did acknowledge it is a problem. He also stated that this would be addressed after they sorted the engine management problem. With that being said, it's been approx 2 months since the engine management issues were addressed. I've rarely seen a dev be pro-active with updated bug reports. For the most part, they (not just M3) follow a long period of silence until they are ready to release "good" news. If a dev provides some form of update then they believe it forms a deadline and they are held accountable for it. So they keep quiet and let the users stew in their proverbial juices. Am I happy about this silent treatment? NOPE! Does my level of frustration increase when there no updates after each patch? YUP! Does the level of frustration continue to grow when there's no mention in the forum (this thread)? A resounding YES! After reviewing M3's bug report, I can honestly say, this problem is the most commented. One would assume this issue has greater visibility, which would equate to a higher priority to resolve. All I can say is: I've recommended to my fellow squadron mates to avoid this module until key issues are fixed. Like the differential braking/feathering into the wind, and the damage model (potential tail wheel damage) at spawn-in. I refuse to fly this module until these issues are addressed. No training missions, no Corsair School (campaign), not even air starts! I'm pretty upset because being an early adopter, I expect the plane to perform adequately. I know that several of my squadron mates are disappointed but they were shocked to hear my say, "Don't waste your money now. Wait until it's fixed."

Wow! Thanks for the update, @BIGNEWY! I thought this discrepancy fell off the radar. Good to see it is being addressed.

Are there plans to organize all of the untitled/un-named helicopter bases that are marked as "H"? It's very challenging to sort/list/find all of these H airbases, especially when applying dynamic warehouse features.

@shadowborn, The problem is complicated to say the least. I've been reporting issues with GeorgeAI for a while. Despite my best efforts to provide the requisite information it never seems be be "enough". The problems with GeorgeAI really start to manifest after flying for a while. I'd say after 30min of flying. That defeats the purpose of providing a short track file for review. I'm not sure if this may help you but after all the recent updates to GeorgeAI, I follow these steps: 1. Maintain a loadout of 1-Kilo and 3-Lima Hellfire per rack. 2. Keep him de-WAS'ed until within range. 3. GeorgeAI can lase to obtain range data while de-WAS'ed (short right). 4. Once in-range, switch GeorgeAI to RF MSL or SAL MSL (short left, then long left to cycle between MSL types). 5. He should activate the laser for range data (so the data can be automatically transferred to the Hellfire) 6. If he has a hard time lasing the target, switch between RF MSL and SAL MSL. This is why I keep at least 1 Kilo Hellfire per rack. 7. You should be no closer than 1,100 meters to fire the MSL. Otherwise, GeorgeAI will not comply after consent is given. 8. Frequently have George AI de-WAS'ed when you are not actively shooting at a target. My rule of thumb is de WAS him after 1 minute from the last target hit. Note: I've had many times where I had to cycle GeorgeAI 3+ times to get compliance and fire a missile. I also had to slow down my button movements to be more deliberate. This can be very challenging especially when you get caught up in some intense battle sequences. GeorgeAI is still far from perfect. As you noted after crashing, I too get the repeating "Aircraft armed" callout. That is normally caused when the helo is wobbling/tilted/fallen on its side, or there is damage to the weight on wheel switch (however the game calculates that logic). Lately, I will see and hear GeorgeAI stuck in a target lasing loop. I'll hear him call out "lasing" to infinity and also see a notification window that says "lasing" scroll down the right side of my screen to infinity. I have to undesignate the target and reacquire it for the problem to go away. I know this may sound silly to ask: Have you verified there are no keybinding conflicts when you experience GeorgeAI safing the helo? @BIGNEWY, I ask for consideration to short track file requirement. Based on my experience in multiplayer environments, which is were many of us experience these bugs, it takes at least 30 minutes of flight time to encounter an issue with GeorgeAI. Furthermore, it is a huge PITA to stop my entertainment and exit the server just so I can immediately preserve my DCS log and multiplayer track file. Then get criticism for it being too long/large and not be reviewed; or suggest to provide more data. Trust me when I say that I have better things to do than to complain about a DCS module (or modules). If I'm complaining about a problem, then I'm pretty fed up about it. You are welcome to come into my server and experience the issues hurting my head. You may collect all the data you wish at that point.

Here is a link to download the track file for this livery bug. I'd like to repeat this is more of a Mission Editor problem. The track file will only show the effect of the problem, where as ME screenshots point to the cause. PG Map Livery Issue Track File

Here are 2 screenshots that has 1 minor livery discrepancy and 1 major discrepancy. The Apache rearm screen shows "Item 1" in the drop-down menu for liveries. It should read "Apache Desert". I also confirmed the livery ID from the MIZ file. The Tomcat livery should be the "default", 01 - VF-102 Diamondbacks 1996 livery. Instead, I get the VF-103 Jolly Rogers. Now, this is where the problem gets strange. In the MIZ file, the livery id shows up as VF-103 Last Ride. However, in the Mission Editor, the livery should be 01 - VF-102 Diamondbacks 1996. The livery IDs are messed up bigger than a soup sandwich. Here is the Item 1 choice on the rearm menu. Here is the VF-103 livery, when it should be VF-102 livery.

Here is the DCS Log, the track file is too large to attach right now. There was a bug when I opened the rearm menu in the Apache. It showed the F/A-18 livery in the pull-down list. I wasn't able to recreate my initial discrepancy because the base from which this was observed was not captured yet. However, refer to the screenshots from the Mission Editor. That is more of the tell than any track file or log could show. dcs - PG Livery Issue.log

These edited screenshots show the radio frequencies of my template aircraft depicted in the track file.

Here is my track & log file to document the radio freq not matching the Dynamic Spawn template. DCS Log-Track Files.zip

I have an issue concerning the Dynamic Spawn templates: Unique radio frequencies are saved for each aircraft in the Mission Editor. However, when a user spawns into a Dynamic slot, my list of unique frequencies are overwritten with the default radio frequencies. Therefore, a custom list of radio frequencies are not retained in the Dynamic Spawn system. Does anyone else experience this? A track file will soon follow. For example, F/A-18 Comm 1 channel 1 is set to 230 MHz. After spawn-in, channel 1 is set to 225 MHz.

@Nealius, thank you for reminding us of your thread back in 2021! I was surprised to see one of my posts in this thread. Yes, it still happens. @BIGNEWY, should these 2 threads merge? Additionally, this link discusses the problem & fix for the ME Removing Sound Files from Action Trigger Section. Perhaps a similar method could be applied to the method of saving liveries?

@BIGNEWY, I worked exclusively in the Mission Editor today for 6+hrs converting static slots into dynamic slots. Here are plenty of screenshots to review. The Red Boxes/Arrows show the wrong livery upon first access. The Green Boxes/Arrows show the proper livery after selecting it. There were more instances but I am exhausted from staring into the ME & using Paint.net to highlight. My DCS log is also attached. Not sure if that will confirm the problem. What do you see? dcs - 2025-10-04.log

@BIGNEWY, this is an issue more associated with the Mission Editor. How would a track file & log help in this regard? I'll work on it but the results may appear disjointed.