WilliamLink

Well, I figured out what was causing the issue, and it's ridiculously simpler than I thought: It has to do with the NAMING of the textures. For instance, In my case, I had 3 textures for the Flight Stick of the F-15C I was working on: One for the Diffuse/Albedo/Color called "Stick_Diff"; One for the Normals called "Stick_Normal"; One for the RoughMet called "Stick_RoughMet". Normal Map was working fine, but in order to get the RoughMet texture to work, IT MUST HAVE THE SAME EXACT NAME of the Diffuse texture + the suffix "_RoughMet". So in that case, the correct name for the roughmet should be "Stick_Diff_RoughMet". OR What I did instead: I decided to remove the suffix "_Diff" from the Diffuse texture, and just call it "Stick". This fixed the issue, because now that the RoughMet does have the same exact name of the Diffuse texture + the suffix. And the names look more organised this way.

Wow, roughly 4 years later, and I'm facing these SAME EXACT issues. The only difference being: I'm using Blender and the EDM Exporter Plugin instead of 3DS Max. But, despite the different 3D modeling software, we're pretty much in the same case. I'm working on a Cockpit Mod for the F-15C because I can't stand looking at that 8+ years old cockpit model anymore (poor F-15C, forsaken by ED), and have just finished remodeling of the Flight Stick (the original FC3 model is insufferable to look at. The stick is DISGUSTINGLY incomplete - only half of the 3D mesh visible, the side facing the player, while the backside of the stick is just a massive hole in the mesh). And even though I've set the material of the Stick to use the Stick_RoughMet texture, the ModelViewer does not read the texture correctly. It completely ignores the R channel, leaving the mesh with an all-white Ambient Occlusion channel, and inverts the G channel, which inverts the behaviour of the Roughness channel. Only the B channel is read correctly, making the metallic parts look like metal. Have you found a solution for the issue, after all those years? [edit] All of the roughmet textures previously setup on the original mesh of the cockpit are correctly read by the ModelViewer. The problem is only in the new mesh parts (in my case, the new Flight Stick). Diffuse/Albedo Maps and Normal Maps are working just fine, the problem is only on the RoughMets.

Today I was trying an Air-to-Ground mission with the SU-25T and I noticed something wrong with the compass readout of my Heading whenever I get out of any NAV mode. The problem is: When I'm in any of the Navigation Modes, the HUD reads my heading correctly, but the analog HSI compass seems to be flipped/misaligned, pointing me to a completely different heading. And when I switch to any other mode (A-G or A-A), both readings get wrong. For instance, I picked up a slot on Rota Island, where the Frogfoot spawns on ground, facing north. While still on ground, when I switch into A-G mode, the HUD changes my HDG tape reading something around 165~175-ish. The problem persists while I'm flying. The analog HSI ALWAYS reads incorrectly, regardless of what Mode I'm in. As far as I've tested, this bug doesn't happen in Single Player, only in Multiplayer and only in the Marianas map. I've attached a trk file for the mission, so you guys can check the issue. I even commented on the Text Chat about it. 4YA_Mar_PVE2_V2.17[03_JUN_BKN]-20230205-125801.trk

Oh, man. I believe this is one of the oldest - if not THE oldest - issue that HAUNTS the Frogfoot (and yes, it's ONLY the Frogfoots - both the A and the T variants). I've been complaining about this for literally YEARS now. It's too much for me. It's gotten to a point that this is infuriating now. And we're talking about the ENTRY LEVEL DCS aircraft. EVERY SINGLE NEW DCS PLAYER will have their first impressions on the simulator with this aircraft. Eagle Dynamics MUST do something about this issue.

Oh, my god! I can't believe this problem is STILL present in the Frogfoot, after like what... 8 years now? Even more than that! This is absurdly infuriating at this point! ED NEEDS TO DO SOMETHING ABOUT IT! We're talking about the ENTRY LEVEL aircraft that comes with DCS. It's the aircraft in which absolutely EVERY SINGLE NEW PLAYER will have their first impressions on DCS! And it has ALWAYS had this ANNOYING ISSUE never addressed and fixed! Just to clarify, the "saking" we're talking about here, as far as I understood the topic, IS NOT the shake caused on the whole airframe by overspeeding at 600+ km/h, or due to excessive AoA. IT'S NOT the normal buffeting on the flight control surfaces. We're NOT talking about THAT kind of shake, guys. As Reslox mentioned above, it's the ridiculous shake of THE CAMERA - NOT THE PLANE - that happens as soon as you start TAXIING on the ground. It's like the pilot view camera is being held by someone with parkinson's. We're not talking about crazy hyperspace warping speeds, we're talking about NORMAL TAXI SPEED. Hell, even WALKING SPEED, like 2 m/s makes the camera shake like it's going through an earthquake. PLEASE, PLEASE, dev team, take a look at this issue!

There is now a new option where you can change that, but you have to press Esc, go to the Options, and on the System tab, you'll find a new slider on the right side of the panel called "External Field of View". If your external camera is all zoomed out, giving you the Fish Eye effect, it means this Field of View slider is tuned all the way up to 140°. Change that to something around 60~70 and you'll get the old default angle. I also hated this change. It's simply unecessary, since we've always had the NumPad hotkey combos to control that.

Well, at least in the F-15 and the A-10, you can select the steerpoint you've pre-planned as your Bullseye, and when you go into A-A/A-G modes, your analog HSI (as well as the HUD) will still keep the references to that steerpoint, pointing you to the bearing and range for it - unless you fly over it, then it'll cycle to the next waypoint and you'll have to re-select it. For the Flankers and the Frogfoots I'm not sure the analog will keep the references - I think it does, but have to double check that - but as far as I know, the Flanker's Head Down Display will show you only the Data Link screen as soon as you enter the BVR/Close Combat modes, and will clear out all of the Navigation informations.

This bug IS STILL occurring as of today (january 3rd, 2023). Testing it on multiplayer, in a 162nd Viper Squad Training Server. The SU-33 DOES have a parking brake (check the Controls Settings for the command called "Wheel Brakes Start", this functions as the parking brakes). Also on top of that, the SU-33 is a Flaming Cliffs 3 aircraft, and as such, you CANNOT refuel/reload if your engines are running. It means you are not able to move whatsoever during the refueling/rearming process. There is no reason for this to be happening at all.

This has been my #1 wish ever since I started playing Lock On - Modern Air Combat, back in 2013~2014. Even before I got into DCS and bought the Flaming Cliffs 3. If a high fidelity module isn't in the realm of possibilities, I think at least the FC3 F-15 deserves and desperately needs an update. Switches, dials and knobs in the consoles lack the animation of flipping and turning, like the Flankers have for some of them. Interior lighting looks awful at night, honestly. Super unbalanced cockpit displays, instument panels and flood lights. Exterior model and textures would also greatly benefit from a rework.

Having my previous message being said, I TOTALLY agree on the AWACS calls issue. It makes NO FUCKING SENSE having the AWACS annoying the player with frequent BRA calls for bandits that are HUNDREDS OF MILES AWAY, especially when there are much closer bandits which pose a much more significant and imminent threat to us. There should be a "Range Filter" on the AWACS AI for when they start calling bogeys for us. In my experience with DCS, anything past beyond 80 miles is pretty much IRRELEVANT to the player, unless it's a hostile F-14 that can shoot Phoenixes from farther than that range.

I can add to this issue. There is a hotkey to cycle through the message feedback modes, that used to change the filters of which messages the player receives from the built-in Radio Comms. This hotkey is labeled "Receive Mode" in the Controls window of the Options Menu. Hotkey is RShift+\ or RShift+M. When you first spawn in an FC3 aircraft or any "low fidelity" module, the default Receive Mode is set to "Player's Communications + Reports to Player + Other Aircraft Communications". If you press the hotkey once, it shows that message on the top-right corner of your screen. Pressing the hotkey again while the message is being displayed will cycle through de 3 different Receive Modes from this default one to the second mode, which filters out the "Other Player's Communications". With this second mode, you should not receive radio calls from other flights calling waypoint passes, requests for takeoff/landings from other aircraft, or anything in general that has nothing to do with you and your flight. Means you'll only receive messages that are relevant for your mission, such as the regular AWACS vectors and ATC calls that are directly for you. Pressing it once more cycles to only "Player's Communications". This last mode used to only return to you the radio calls that are immediate direct responses to the Radio Calls YOU select on the Comms menu (this one even filtered the continuous AWACS feedback), meaning you only get an AWACS feedback WHEN YOU REQUEST IT. Same for ATC comms, Wingman, JTAC, etc... The only issue I'm having with this feature (I'm testing this with the F-15 right as I type in here) is that this last mode, the Players's Communications, it still gives me radio feedback for communications I did not request, like waypoint calls from AI flights (which should only be received on the default mode). This issue began quite a while ago (I started noticing it after the Apache became available) and it was even worse than it is right now. It got KIND OF fixed a couple of updates ago, but still remains this minor issue.

For the F-15 in particular, this function requires you to HOLD the key binding. For every other aircraft, it's a toggle function, but for the F-15, it only works while you hold the key. And by the way, if you start holding it AFTER you move your rudder, it will hold the wheel steering in that direction even after you neutralize rudder, so make sure you have it neutral when you press and hold the key.

I thought I could add my 2 cents on this issue. I've noticed this issue with the speedbrake for quite some time, and I don't know whether this is actually a bug or it's how it is designed in the real jet (my guess is this is actually how it's supposed to work), but your speedbrake won't come out when you have a high Angle of Attack. Anywhere above 25 units of AoA makes the speedbrake not operate. I'm not sure what causes the AoA sensor in the Eagle to go nuts when you're stationary on ground (maybe wind incidence angle?), but you can watch, in a fully stopped and engines off condition, that your AoA Gauge keeps jumping from 0 all the way up to 45+ units, and whenever the needle passes the 25 mark, it prevents the speedbrake from operating. This strange AoA sensor behavior also happens on other jets (I've experienced that with the SU-25 - when its AoA passes a certain limit, the annoying warning sound goes off - and in the Flankers as well), so maybe it is caused by wind. For the Eagle, the side effect of this high AoA is the speedbrake won't move. Also, when you're in the air, get your speedbrake out and pull a high alpha maneuver, and watch your speedbrake retract automatically when you have the high angle of attack, and it'll come back out when the AoA goes down. This behavior is what leads me to believe this issue is actually a design choice, not a bug. But I may be wrong on that, it needs investigation.

It's almost a full year since this topic was started, and the problem is still present. And there are a few other issues I found with the TF. The 'Close Canopy' default key binding (LCtrl+C) doesn't work as intended. It actually opens the canopy, even though the 'Open Canopy' keybind is LShift+C. So both key bindings are opening the canopy, leaving only the mouse wheel option for this function. Binding another key does not fix the issue either. Another MINOR issue: Left Clicking on the Flight Stick Locking Pin (located in front of the base of the stick) should put the flight stick fully forward and lock it in place with the pin; Right Clicking the pin locks the stick in Neutral Position. The Right Clicking function works properly but Left Clicking is not. They have key bindings, though (LShift+X for Fowrard Lock and LAlt+X for Neutral Lock), and the keys are working properly.

I've been able to toggle the labels yesterday without crashing... MAYBE it's related to what aircraft I choose (yesterday I picked up an F-16C and had no crash, now for this crash I've attached, I was in the F-15C)... No idea. I'll try to cause the crash on Single Player missions, try it with different aircraft and see how it goes.

I've just reproduced the crash, but I couldn't attach the original zip folder because it exceeds the 5 MB maximum attachment size (it's a 9.9 MB file). Most of it is because of the mission track (.trk) file inside the .zip. It was a pretty busy Capture Bases mission from a 4YA server, with 30+ active players at the moment. So I took the freedom of extracting the zip folder, and re-zipping it without the .trk file. dcs.log-20211223-012540(1).zip

Well, I can't remember if this hotkey Shift+F2 is reserved by any other conflicting software running on background. I gotta check this, but I think there's nothing using it. But what happens in-game is that as soon as I press the Left Alt Shift + F2 it freezes for a couple of seconds, then the pop up Crash Report window appears, giving me the option to send crash report (I have NO IDEA what that actually does). I've just checked if the crash happens on the Menu Screens, and nope. It doesn't. Only when I'm actually on a mission/server. Edit: Just correcting the Hotkey. It's actually Left SHIFT + F2, not Left Alt + F2. There are also other keys for other types of Labels toggling. I'll check these as well next time.

I've been having this issue for quite some time. I can't remember the last time it worked for me, but I guess it was before the 2.7 release. My "Labels" option is set to "No Labels" on the Gameplay Options Menu, but there is a hotkey to toggle them on and off (Left Shift + F2). It's a useful tool in multiplayer servers that I'd like to use for when I want to quickly identify a player that's right next to me on the ground or in the air, without having to look at the F10 map, find myself in it and the player next to me to see their callsign. The problem is, as soon as I press the hotkey, the game crashes. This happens on both the Stable Release branch and the Open Beta branch (fresh install on my PC, as I've just decided to play on the OB this week). Tested on multiplayer servers only. I haven't checked in Single Player yet but it's likely to do the same. DCS Log attached. dcs.log

I downloaded the Monitor version, but when I tried to open the .RAR, i got a "Broken/Corrupt File" warning.

Well, they've fixed MOST of these issues - some of them still persist - since the latest update (Version 2.7.6 Stable Release). The cockpit interior lighting has been tuned up quite a notch (only during daytime you can barely notice any difference, but for night time it's ok); Exterior Navigation Lights have been fixed and are fairly visible now; Leading edge wing base Red Strobe Lights have been tuned down to a reasonable level; HUD brightness is adjustable as always, doesn't need fixing; The Displays are still too bright and overexposed; The mysterious red light on the head of the Ejection Seat is still present; Now the Landing/Taxi Lights, however, are presenting a new issue: They are missing the "halo" effect texture completely. Or rather, what I believe it's actually happening is there's some sort of Alpha Clipping issue between the "Halo" texture and the glass cap of the lamps, where the glass is displaying opaque on top of the halo texture. The Landing and Taxi lights are lighting up the ground and objects correctly though. I still think the taxi light is a little dim and doesn't reach very far on the ground. I feel like the F-15 taxi lights still remain the weakest among all the american aircraft in DCS (but MAYBE this is an F-15 related problem? Maybe the F-15 in real life has a weak taxi/landing light? Who knows?).

There are default keybindings for controlling HUD brightness. I've changed mine but I believe RCtrl + RShift + H = Brightness Up, and RAlt + RShift + H = Brightness Down. Or something like that. Also, you can change the color of the HUD Symbology, with RCtrl + H (or is it RAlt + H, anyway, just try these combinations out and you'll figure out). I wish there was a control for the cockpit lights brightness as well.

I am trying to play again the FC3 Campaign for the F-15C after a couple of years having finished it, and I'm also facing issues with AI wingmen behaviour in some missions. My wingman #2 sometimes just EXPLODE out of nowhere, for no reason at all. He's not getting engaged by anything, or even crashing into nothing. Just simply exploding suddenly, and sometimes even causing damage to my aircraft, when we're flying in Close Group Formation. It's a well known fact for MANY years that the AI traffic and ATC logic is plagued with A LOT of bugs and issues, or simply weird behavior and lacking many features that could add for a more immersive single player experience. Formation Takeoffs and Landings almost ALWAYS result in tragedy. Yesterday I've tried a formation landing with my 3 AI wingmen, after successfully completing one of the early missions in this campaign, they all crashed on each other behind me, causing a MAJOR explosion, killing all three pilots instantly, and damaging my aircraft. There are SO MANY things to be fixed in the AI logic (especially in regards to ATC interaction) that Eagle Dynamics have always postponed the work and focused on developing new stuff.

Test 2.miz Here you go. In the previous version (Test 1) I had the Civil Aircraft Mod installed so there were some stuff from this mod in the mission. I removed them all to make sure you are able to load the mission without having to install the mod.

Thanks for the response. I did a few other tests with this mission, and even got to the point of completely removing all of the Advanced Waypoint Options for the 2-ship of Black Sharks. Instead of telling them to Escort the tanks, I've actually set up a series of steerpoints nearby the path of the thanks. Result: No difference at all. The Black Sharks are still hovering still in the air, carried by the wind. But I also found out that the Frogfoots were actually engaging the black sharks, which was the reason they we're flying directly into the threat envelope of the SAMs in my home base. In one of the tests, the Froggies indeed engaged the choppers in a couple of passes, while evading the SAM shots. The Black Sharks also managed to avoid the Froggies attacks, but they NEVER followed their pre-planned route, neither with or without Advanced Waypoint Options. Then I decided to remove the Advanced Waypoint Options for the Frogfoots completely. Result: Now they follow half of their flight plan, but a couple of minutes before reaching the steerpoint where they would initiate their attack on the tanks and choppers, they just go "NOPE" and return to base.

I'm facing a similar problem. I'm trying to set up a mission where there is a group of tanks driving from a FARP towards some small town with a 2-ship of Ka-50s escorting them, while in the opposing team, there would be a flight of 3 SU-25s coming to attack the whole group. The player's role is to prevent the Frogfoots from reaching the tanks and choppers. Simple mission, right? However, the only group that's behaving as expected is the tank group. Neither the Sharks or the Froggies are following the Advanced Waypoint Options. The Frogfoots are completely ignoring the tanks and flying straight towards the player's home base and getting themselves engaged by the player's base SAMs. The Black Sharks take off from the FARP, and simply keep hovering in the air at 1000 ft, being dragged away by the wind and not caring at all about the tanks they're supposed to escort.