streakeagle

Ther real deal: Clear as day to me, even more so with a color filter. The "l" has glare or a paint chip that breaks up the line. the "d" is fairly clear. The color filter appears to show a hint of the "s".

Until ED fixes all of the modules that have the old horrible reflections, it isn't moot. With the continuously changing nature of the DCS World core game engine, it shouldn't be a problem to expect that modules that are still for sale and theoretically fully supported be compliant with the graphics standards for the current patch level. Otherwise, they are communicating that it is unwise to buy/fly anything but the latest modules that are fully compatible.

Check out the laser scan of an RF-4: McDonnell Douglas F-4 Phantom II - 3D model by Raiz (@RaizVR) [65e172a] (sketchfab.com)

I used to be able to go to the Naval Aviation Museum in Pensacola and take real measurements in a simulator cockpit, but they closed access to the base after a shooting so I can't go there anymore. But the USAF Museum in Dayton has a real F-4 cockpit you can sit in and I took measurements there, too. If you have any aviation museums nearby with an F-4, you might be able to arrange a visit where you can sit inside and take measurements. Someone made a 3d laser scan of an F-4 including the cockpit and they have it available for sale. If you have access to the software needed to open the file, that would be perfect for getting measurements.

I had another flight simmer who was putting together real F-4 panels post pics with dimensions. I took the photos and scaled them to print out 1:1 to match the dimensions given. I printed them out on white card stock 8 1/2 x 11 and taped them together. Here is the forum post where you can find my source images: F-4 Phantom B-8 Stick Phase 3 - Game Controllers - CombatACE I originally used upscaled black and white images from the F-4E manual, then pasted over them with the above upgraded panels photos. Note: The Tracer posting above is the same person that posted the photos at the link

Whatever it is that makes 90 fps out of 45 fps (motion reprojection?). With that turned on, the frame rate is unsteady, there are artifacts (blurry spots), and generally lower performance. If I force it off, my frame rates can vary between 45 and 85 when left unrestricted while having fairly high quality settings. It isn't 4K desktop quality, but it is getting pretty close. I would kill for a 90 fps lock, but the best I can manage if 45 steady, and even then some situations briefly drop the fps below 45.

I haven't done any of the core affinity stuff. For me, the big difference was realizing the 6900 XT hated motion smoothing. Once I disabled the motion smoothing, the performance and stability skyrocketed. I can generally maintain 45 fps, even in an F-14 on a Super Carrier with fairly quality settings including mirrors, shadows, and heat blur at MSAAx2, AFx16. The G2 looked great before, it looks fantastic now. Clarity in the cockpit is outstanding.

That would have saved me a lot of time over the years of playing DCS when the Warthog was my throttle and quite a few aircraft needed a mod to make the flap switch work as well as anything I wanted to map to the other toggle switches. There is one benefit to doing file compares after patches: sometimes changes show up eliminating the need for the mod. But I would much rather have had "automatic injection", especially in some time frames where the patches and subsequent hot fixes were happening very frequently.

The only major changes to USAF F-4s that would affect carrier compatibility was the landing gear. The USAF F-4's have bigger tires, which required bumps in the wings to accommodate them compared to the F-4B/N. The tailhook remained fully functional. The automatic wing fold mechanisms were removed to reduce weight, but could still be folded manually if desired. I don't know about the ability to rig the harness to cat launch, but there was nothing that would prevent a USAF F-4 from landing safely on a CV compared to the Navy F-4, other than having different avionic fits potentially requiring a 100% manual/visual landing approach.

If you check every time there is a patch like I do, you would be surprised by how often changes are made, even to long existing modules. DCS patches change core items several times a year, resulting in changes in almost every single module. The latest change is the new built-in radio/voice-chat functionality, which affected nearly every module that has lua edits. I use Notepad++. Fixing one aircraft is painless. But when I used the Warthog throttle, I had custom scripts for a large number of aircraft. Sometimes, I would just finish getting everything caught up, when a hotfix or surprise patch would reset everything back to default. Mod manager programs don't really help me: I can paste all of the lua files over the updates in a couple of mouse clicks. Assuming there are no changes and blindly pasting over the new files can cause problems whether you use a mod manager or not. The only advantage the mod manager offers is automating the ability to swap between edited files and the latest versions provided by an update. I don't need software to do that. I could simply write a couple of batch files to backup/swap lua files. What would help me is if only the files that had changed were updated by DCS, then I would know which ones need to be compared and patched back up. I don't expect anyone to buy hardware to avoid a minor scripting hassle, but I will say that having switches that trigger a maintained DX button for every single position makes mapping controls much easier in most modules. It is only when modules have very poor scripts for mapping certain controls that I need to edit any lua files to get the desired results. As for Target: I used the Warthog for many years. Target wasn't too bad aside from having to update the software every now and then, but the inherent limitations of using the graphical interface got in the way with many games. Using the advanced scripting option was no advantage over other means to get the same results. In DCS, the lua scripting was a simpler and better option for me rather than having to tie up my system with one more program running in the background while playing DCS. MSFS has such a horrible interface for mapping controls, that I always used the latest version of FSUIPC negating the need for Target. The only sim I played that Target was the best path forward was Steel Beasts Pro PE. So, I always had Target installed and up to date, but rarely used it.

The problem with using scripting is that it gets wiped out after every patch. While it is easy to copy/paste the removed/replaced files back, ED and 3rd parties frequently update these control map files, so the only safe way to do it is to perform a file compare and paste in the changes you made from the old file to the new file. I had a lot of aircraft customized to make the Warthog throttle work well. It was a ton of work after every patch. The WinWing throttle and control panels are far more compatible with most aircraft. I only have a few aircraft that still need some scripts to map correctly to physical switches.

I turned off motion smoothing, now my 6900 XT runs butter smooth with a first generation G2 with the new usb cable. I can fly in an F-14A from the supercarrier and sustain 45 fps with graphics settings very high, with mirrors, shadows, and heat blur. In many situations, the frame rate rises up to 60 fps or more. At this point I am very happy with the 6900XT. If the price had not been ridiculously high, I would have liked a 3090.

I never knew they had hangar deck catapults. Like Vipers launching from Battlestar Galactica. That should have been the normal way they launched to leave the deck free for landing/parking.

I have numerous ways to deal with switch guards depending on how the mapping options available. In the later modules, there is usually a way to move the switch guard and the switch at the same time, reducing the need for a separate input for the guard. I have the WinWing throttle and control panels, which have lots of 3-position switches. These allow me to open the switch guard, operate the switches, and close the switch guard in most cases without any additional scripting. So, one option you might consider is using a 3-position switch in place of a guarded 2-position switch, then coming up with a mapping that allows you to operate the switch and toggle the guard position.

The AFCS binding options are great, but the 3-position Heading Hold toggle switch is missing the "Heading Hold On/GT Toggle" option and there is an extra "Autopilot Heading Toggle On" binding that doesn't follow the naming convention that performs the same function as "Heading Hold ON". I believe that this was a typo. The name "Autopilot Heading Toggle ON" should be changed to follow the format of the other AFCS toggle binds: "Heading Hold Toggle On/GT". The functionality of "Heading Hold Toggle On/GT" should be scripted to toggle between "On", "Off", and "GT". The "UHF ARC-159 Function Dec" does not work at all. The "UHF ARC-159 Function Inc" toggles between "Off" and "Both". They should work similar to other Dec/Inc bindings. "UHF ARC-159 Function Inc" should progress clockwise from Off->Main->Both->ADF. "UHF ARC-159 Function Dec" should regress counterclockwise from ADF->Both->Main->Off.

I have figured out the fix for this based on a post in "multiplayer bugs": You have to add the skin you want to see (even default skins!) to the saved games folder of the server. It can't be zipped up either, you need to extract it. Since this eats up hard drive space, I just install only the skins the server mission(s) are using. The file path looks something like this, but according the server being used: C:\Users\<username>\Saved Games\DCS.openbetaserver\liveries\MiG-21Bis

Dedicated server installs don't include the skins to save space. But why do the servers need the skins installed for the AI? The client skins work perfectly without being installed. I don't know if this is on purpose or a bug, but I don't understand the purpose unless it is part of the file checking process to ensure no cheating?

Resolved: this is a known DCS "feature": AI on multiplayer servers will only show skins that are installed in the server's saved games\liveries folder... and they need to be extracted. So as soon as I placed all of the selected MiG-21 skins into the liveries folder AND extracted them, I could see the skins. This is a horrible feature. I can understand restricting addon skins, but stock skins have to be duplicated and extracted to be visible in multiplayer? This explains why the A-4E-C worked: the entire A-4E-C mod is in the saved games folder on the server, so it works. I am irritated that I lost so much time trouble shooting this and that I even bothered to bring it up with Magnitude 3 LLC. I apologize for not having searched the multiplayer bug list for a general ED bug before coming here.

Two screenshots. The first one is in single player on a flat panel monitor and shows all of the selected skins. The second one shows a what a multiplayer client sees running the same exact mission. Second client screenshot.

With 4 x AI F-14As in different skins, 4x AI MiG-21s in different skins, 1 x client MiG-21 in a different skin, and 4 AI A-4E-Cs in different skins, only the A-4E-Cs and client MiG-21 have the correct skins, all other aircraft have default skins.

I stand corrected: the problem occurs with F-14s as well. Perhaps all third party modules? I don't have time to test that right now. Maybe this is an ED problem that was introduced with a patch. I remember seeing default MiG-21s on the Vietnam server for quite some time but didn't realize that they weren't the skins specified by the server until I started helping out with mission editing/server maintenance.

If I use the mission editor on the client to open the track file as a mission and fly it as a single player, the skins work perfectly. So, the client has the skins, but can only see them on the client's aircraft, not on any other AI. But if I run the mission locally in single player, all the skins work correctly.

I just narrowed the scope of the problem: I created a simple mission 5 MiG-21s on the ramp, 4 x AI and 1 x client, all with different skins/nationalities. Running in single player, all 5 MiGs have the correct skin. Running on a server with no restrictions, the client aircraft has the correct skin, but all AI aircraft have the default skin. What is different about how AI skins are pathed/selected in multiplayer vs single player for the few modules that are exhibiting this problem? Keep in mind, these are not addon skins, these are all stock skins that are available upon installing the aircraft.

If they locked out liveries, which they don't (I have tested using my own local host as well), why is it that only a few third party have this problem. Notably the C-101, MiG-21, and Christen Eagle. I have verified that other people experience the exact same anomaly, so it isn't my install. What is different about the skin packaging/paths of these few aircraft compared to all the others? I couldn't find a difference. Yet the skins worked fine for the other aircraft. It is not any one livery. No matter what skin is specified by the server, the MiG-21 is in the two-tone gray with white crosses on red/blue roundels and the C-101 is light blue with orange high visibility panels. Whereas, I can use any skin I want from any nationality on all of the aircraft I have tested: F-14, AJS-37, AI F-4, A-4E-C, etc.

Host server shows skins for most aircraft. A handful of third party aircraft do not show selected skins: particularly the C-101 and the Magnitude 3 LLC modules. This is with stock installs and skins on both ends: the DCS server host and client. I don't see how an "official WinZip archiver" has anything to do with the problem, as everything works on both ends except for particular third party aircraft, which leads me to believe it is related to how those third parties have their skins organized and/or compressed. If it is an ED problem, why aren't all third party aircraft affected?