Nealius

I've only researched the ablative coating but I imagine the guidance kits followed the same process: At some point in time the colors were changed, as they were introduced to the fleet they were intermixed with the older kits until the older kits were all used up and only the new kits remained. Why certain color kits were mixed with certain color bombs could be anything. Looking at pics I see the guidance kits themselves mixed: gray kit with green fins, green kit with gray fins, etc. Just comes down to what's not broken and available for the mission that day, I suppose.

Still unacknowledged and unfixed in 2.9.3.51704

Obviously. I was thinking more of programming more variables into the AI so that bailout it delayed longer than it currently is. Similar to the variables we got in the WW2 AI for what targets to engage or when to disengage from a fight.

In the Tomcat on multiplayer only the first pass is accurately graded. All subsequent passes are cut or no-grade. Those same passes are graded very differently with 3rd party plugins like MOOSE/AIRBOSS.

Should be gray coating (specifically FS 36375 IIRC), with dirt and grime, not a clean white as reflected in the current texture files. When this bomb customization feature is released I hope the textures are updated to better reflect reality. Inclusion of the already existing ablative green coating (two yellow bands) as an option would be great as well, for historical accuracy if doing 1980s~1990s missions, before the gray color was standard.

Works fine here for me as well. I do often find in the Viper my inputs (mouse, keyboard, HOTAS buttons) sometimes get registered as double-presses. Most frequently with the parking break, FLCS BIT, and CMDS program/mode switches. Could just be me and my system but if the switch isn't "sticking" then there's a possibility you may be experiencing the same thing.

I may be putting maybe too much faith in the source material and visual adaptation, but in Masters of the Air they consistently do everything they can to AVOID bailing out until it's the last possible option.

Ah, the wake. Now I see what you mean. Re: pic. That's pretty shallow for a carrier.

We've already established that the 3D model has four screws. Where is the "two scews" claim coming from? At pier/in harbor is not equivalent to off the coast or in deep water. The shallower waters and constant, large boat traffic will disturb the silt and make the water cloudy. Not to mention all the garbage from all the people and industrial work there.

Depends on the map, which I can only assume is trying to replicate the visibility of their respective oceans. Of the maps we have I've only personally been to the Marianas and the water is pretty damn clear. Maybe not as clear as what's pictured, and particularly at that angle, but at certain angles you could see at least a chunk of the screws in theory--solid 20~30m visibility last time I went diving there, and that includes looking straight down from the boat, not just while under water. Pretty sure there's a YouTube video somewhere as well with carrier crew swimming in the deep blue and you can catch a sight of the screws. PG, Sinai, Syria, in comparison you can't see them at all. That said, I think it's less of a water transparency issue and more of a total lack of "churn" in the water.

Would be nice if the names were settled to begin with instead of suddenly changing mid-development and ruining 98% of all user-made liveries which make up for the total lack of coherent CVW liveries--particularly those matching our carrier assets--that come with the module by default. (Just sayin')

May have found a fix. 1. Delete all lines referencing a "BORT_NUMBER" 2. Add the following lines of code, and edit the bolded parts to match the dds files in the liveries folder (if no particular name, delete those) {"f18c1_number_nose_right", 0 ,"F18C_1_DIFF_VFA195_CAG",false}; {"f18c1_number_nose_right", ROUGHNESS_METALLIC ,"F18C_1_DIF_RoughMet",true}; {"f18c1_number_nose_right", DECAL ,"empty",true}; {"f18c1_number_nose_left", 0 ,"F18C_1_DIFF_VFA195_CAG",false}; {"f18c1_number_nose_left", ROUGHNESS_METALLIC ,"F18C_1_DIF_RoughMet",true}; {"f18c1_number_nose_left", DECAL ,"empty",true}; {"f18c2_kil_right", 0 ,"F18C_1_DIFF_2_VFA195_CAG",false}; {"f18c2_kil_right", ROUGHNESS_METALLIC ,"F18C_2_DIF_RoughMet",true}; {"f18c2_kil_right", DECAL ,"empty",true}; {"f18c2_kil_left", 0 ,"F18C_1_DIFF_2_VFA195_CAG",false}; {"f18c2_kil_left", ROUGHNESS_METALLIC ,"F18C_2_DIF_RoughMet",true}; {"f18c2_kil_left", DECAL ,"empty",true}; {"f18c1_number_F", 0 ,"F18C_1_DIFF_VFA195_CAG",false}; {"f18c1_number_F", ROUGHNESS_METALLIC ,"F18C_1_DIF_RoughMet",true}; {"f18c1_number_F", DECAL ,"empty",true}; {"f18c2_number_X", 0 ,"F18C_1_DIFF_2_VFA195_CAG",false}; {"f18c2_number_X", ROUGHNESS_METALLIC ,"F18C_2_DIF_RoughMet",true}; {"f18c2_number_X", DECAL ,"empty",true};

Changing them all to true, e.g.: {"F18C_BORT_NUMBER_NOSE_L_100", 0 ,"F18C_1_DIFF",true}; {"F18C_BORT_NUMBER_NOSE_L_100", ROUGHNESS_METALLIC ,"F18C_1_DIF_RoughMet",true}; {"F18C_BORT_NUMBER_NOSE_L_100", DECAL ,"empty",true}; Does not remove them.

The skin is. The carrier itself is the standard CVN-71. Check the infobar at the bottom of the pic. The skins only change the hull number and name, not the 3D model.

Mine have four: (CVN-71)

Because DCS maps have elevation. Crosswind limits, weapons employment. Let's say the Med is a balmy 12kts, perfect for carrier ops. Well now everything on the east side of the Syria map is going to have 24kt winds because it's around 2,000+ ft in elevation.

No mods and it still happens to me, but a specific Marianas mission is the biggest offender. Even if I start over from scratch and remake it, it will still get stuck. Other missions, including paid campaigns, are hit-and-miss. Sometimes they work, sometimes they get stuck. Flappie and I have been going through all sorts of troubleshooting and track files with no end in sight and no one other than myself is able to reproduce the issue with that specific Marianas mission, which is leading me to believe there's an issue with my computer itself.

My only issue with the current system is that parachutes are the exact same size and shape as aircraft in VR, until you get within 1nm and then it suddenly disappears, then reappears as a parachute. I'm getting tired of trying to BFM with parachutes while the actual bandit throws a heater up my tail.

I've been having trouble with compass navigation in the German warbirds due to the compass freezing up during turns. I discovered this is realistic and that pilots would turn x-seconds at a known rate before rolling level and checking the compass. In this video (timestamped) it's mentioned that the artificial horizon contains a rate-of-turn indicator in order to accomplish this. However, this isn't mentioned in the ED manuals or Chuck's guides for the German warbirds. Does anyone know how to read/use this rate-of-turn indicator in order to properly navigate with the compass? The video author also did not know how the instrument itself is calibrated.

Cat shot issues appear to be fixed with the FM update. Even from cold starts and idling about on the deck, I no longer experience downward vectors into the ocean.

Previously the AoA bug--causing 3PTIW cut passes--was present regardless of wake turbulence setting.

CASE III has it the worst. Player A calls inbound, but CATCC sends the respons (comms menu tree) to Player B, using Player B's modex and state. After established CATCC/Tower get Player A and Player B properly separated, but Player B gets "no proper communications) because he/she literally isn't allowed to call inbound.

Going gear/flaps down at 230kts I noticed pitch down moment with very minimal ballooning, which feels normal to me comparing to other aircrafts' behavior.

On the current build I get no pitch up over the deck, and the sudden decrease in AoA bug also appears to be gone. However this is with the wake turbulence setting off.

@StolenPen Yes, same behavior now that I reproduced in the Hornet as well. It works the first time but refuses to work after, and yes I do use a modifier. With limited HOTAS functions and the complexity of all our modules it's impossible to NOT use a modifier for such tertiary functions. At the same time, modifier works fine for other commands like VR zoom, ball call, tanker pre-contact, etc. Not sure why the modifier would cause a problem with the comms menu only.