GeoS72

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.

The only thing altered were both DCS updates (MiG-29 release & 1st week hotfix). As you may recall, there was a bug that effed up the re-arm menu. Loadouts for the wrong aircraft would be displayed. It was quietly fixed in the hotfix. There is still a glitch with the re-arm menu but appears to resolve on its own. I seriously doubt a mod or livery that has been installed for a long time will cause such havoc. Yes, I'm aware how easy it is to change a load out for the same type of aircraft. However, I did not play with any Apache settings. The the last big change I made to the affected MIZ file was the addition of the MiG-29A Fulcrum.

The default load out changed in general. It was highly unlikely that 1 load out was copied to EVERY blue Apache. I also have a bug for the active livery showing "default" when there is obviously a different livery being displayed.

I lost count of the hours spent changing the livery on several spawn points. This reminds me of the bug that kept resetting sound files. Can we please address spawn points resetting the livery from X to "DEFAULT"? As you can clearly see, this is not the default livery. Yet the ME seems to randomly (or universally) reset any livery for any aircraft to "default". Is it possible to use the same method of saving sound file in the trigger system to have the same effect on liveries?

Has anyone else noticed their AH-64 default load outs changed? I don't know how this happened, but I'm effin pissed! Every AH-64 spawn point in my MIZ file for the PG map has a "default" load out of Rocket Pods x2 and Hellfire x8.

If the base was still under construction, then why include it? There are other airfields in the PG map that are imaged as terrain. For example, there is an airfield south of Fujairah that can be seen as an image. IMHO, this is evident of a larger problem: the arbitrary & capricious method of updating a module (terrain, aircraft, etc) and allowing things to "drop off". Case in point: I once reported a bug about ground units unable to follow certain roads in Kerman and Jiroft in 2022. In 2025, the problem was partially fixed. Kerman was kind of fixed but Jiroft was not. No additional explanation given, just Kerman was fixed to some extend while Jiroft was not fixed. Here's the link to that old thread. File attachments were removed because of age and the need to make room for more file space. Ground Unit Bugs As we can see in this instance of Qusahwire Air Base, it was modeled with parking slots assigned. One can "click" on it in the F10 map to pull generic data. However, in the ME, one cannot set a coalition or warehouse assets to this airfield. One could drop invisible FARP points along the airfield to add life but will be limited to the use of the Dynamic Slot system (for Helos & VSTOL aircraft). Perhaps someone could prove me wrong that you can spawn a fixed-wing aircraft at an invisible FARP? I must admit that I have not tested dynamic slots on FARPs with fixed-wing aircraft. As time marches on, I grow more tired and frustrated of tolerating the arbitrary & capricious nature of bug reporting/fixing bugs/module support. IMHO, this is one of many thousands of cuts that is either intentionally or unintentionally left to grow.

I'm curios to learn of their intentions with partially adding Qusahwira Air Base. That's like starting a sentence and

I believe you can see Global Hawk UAS adjacent to one of the sun shades if you zoom in on the 2nd photo. You may have to go to the source from which the image was pulled to see it though.

+1 for making this an active airfield in the PG map! Based on my research, this airbase has 2 names: Qusahwira Air Base and UM Elzumol 1. If this airfield in the Abu Dhabi Emirate doesn't exist in the game, then why does it have parking slots? Since it is modeled, it would make more sense to just add it to the list of airfields and warehouses. I'm unaware of how much work goes into making all the logistics for a base work but it looks like most of the hard work was done! As an interim, laying down invisible FARP pads in several locations can replicate the refuel/rearm functions. The "invisible" airfield that represents Qusahwira Air Base has at least 16 parking spots. Here are 2 satellite images with ID labels. 1st label is Um Elzumol 1. The 2nd satellite image has the ID label of Qusahwira Air Base.

It would be such a benefit to add a ControlsIndicator overlay that could be modified for all FC3 aircraft. Especially since the FC2024 modules have independent files that could be modified to accommodate multi-monitor support. Currently, the FC3 controls indicator does me no good when it falls outside of the viewable area of my monitor configuration.

I made a macro for Notepad++ to edit all the declare_kneeboard_device files so that after each DCS Update, it will reduce your workload. Two things to note: 1. Edit the folder location for your main DCS installation folder on Line 19. 2. Copy & paste Lines 14 - 23 into the existing shortcuts.xml file for Notepad++. It can be found here: C:\Users\UserName\AppData\Roaming\Notepad++ 3. These basic instructions are also found inside the XML file. shortcuts.xml

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