SkateZilla

That's not to say, Some Font's and Controls / text may get a small enlargement, as I made them small in the UI originally to fit everything, I've since divided or moved many controls around, so there is space, to not have Microscopic 8 pt fonts on many of the controls.

1. Scalable Window isn't an option at the moment, as many elements are hard coded to their size/dock/location, I could add a pop out console w/ a larger font size, but I wouldn't say that it would be a priority, as I have other major functions that need to be finished and debugged. the UI Window is already substantially bigger than what most users wanted (apparently people still use 1280x720p displays?). when I have time to re-configure the docking and linked edges of the controls, I may have the right side extendable and as the app window size extends past specific values, increase the font size of the console. 2. and 3. are being worked on, Like I said, I have to be careful how it's integrated to remember, and when the value is loaded as there are dozens of sub functions tied to preset switches, and if the app switches from default to another before all the functions are complete it will cause a mess in exceptions and desync. Same for when a User chooses a Preset and switches builds. It would likely be a complex system that manages the selected preset the same way it manages the preset names per builds. Same for MT Switch, If it's enabled on a build that has MT then switches to a non MT build and it remains enabled, then it would cause argument manifest and binary exceptions. It'd also be a complex system that remembers MT Button state for each build but still run the MT check and disable if the MT Binaries are not preset. They'll both be integrated, but it's not going to be a rush job, and I have a significant list of little bugs in the core functions that need to have

That would be an Assumption.

All updates are attached to the first post: https://forum.dcs.world/topic/134493-the-dcs-updater-launcher-gui-utility-version-20-2023/

I'd honestly rem the code entirely, Users got the idea that popping the breaker was equivalent to pressing the NOS or TCS Off button on a race car. (More power at the expense of stability etc). the issue here is, the over the top story in a book or video interview was over hyped to get the viewer/reader excited, I know pilots that literally laugh at this, Why would you risk compressor stall and losing your aircraft for a measly 2000lbs of thrust (out of a total of 41,800)(aka ~5%), when you can better manage AoA and maintain speed without any risk. If you desperately 5% more total thrust to win all your engagements, your doing something wrong.

3rd Parties use EFM: External Flight Model, and the Fidelity can range anywhere the developer wants it to w/ the data they have.

For the record, my question regarding separation was Rhetorical. As for Rendering, 1 Model can easily take years w/ complex animations, damage models, texture research, PBR Layer Generation, etc etc etc. Outside of that, for DCS at least, it's not even about the new EDMs, you can clearly see they are in the sim in the 2023 Beyond and any ED Content published thus after, The models even if done, it's still not ready to fly, the AI Flight Models, AI Systems etc. likely aren't done. In Closing, The B-1B, B-52H, S-3 are more than "Model Swaps", And I'd rather wait for them to be properly done, vs ED Dropping the new Models in now, and continue to use any old and broken AI Scripts for said aircraft.

What would be the point of separating them if they are going to connect to the same servers, if that were the case it would simply be a new module.

IMHO, If you not gonna raise the bar on the model remasters, then there's no point in doing them... The New B-52, B-1B and S-3 Models are going to be amazing milestones, leading the way for more AI Assets hopefully. Honestly anyone who thinks even a 200K Poly model is built and animated in less than a few years, not to even mention damage modelling, hasn't done 3D Rendering long enough.

Millimoles per liter. Basically saying Online Simulation is a Fraction of a fraction of a fraction of online games.,

FC Planes? I Love FC3 Planes: That being said, FC3 Planes still have PFMs and weapons.

it does nothing, it's an old value.

i will populate monitor config files for any monitor luas that are detected in the /DCS World/Config/MonitorSetup and Saved Games/DCS/Config/MonitorSetup folder. The list will populate the Profiles in the game's folder first, then add profiles from the saved games folder.

I've been in DCS since A-10C Beta, that's about 15 years now. (edited version #, as 1.1.1.1 was the last build prior to DCSW and not "beta") those number's arent even accurate, as I few in multiple builds in parallel.

I'll do ya one better, if you want them off off, I've attached the adjusted roughmet for you. Just place in /Mods/aircraft/F-15E/textures/F-15E-CPT/ I recommend backing up original first, as I don't know if this will trip the Integrity Check. Default On/Off: Modded On/Off: F-15E_T15_RoughMet.dds

Easiest fix for the guys that want no reflection (whether they are mirrors or just general environment color): Open the Cockpit roughmet texture and make it so the Mirror is not polished / metal. the "Low Resolution" Mirror Effect your seeing is the Roughness/Metallic Material settings in the texture, that's it, this effect maybe better/worse depending on SSLR enabled or not. But it's not the normal Mirror viewport rendering, it's the same general lighting/reflection you'd see on the externals of some metallic aircraft. General Environment reflection based on texture roughness/metallic setting doesnt effect Fr/PS, but still provide a visual representation that a mirror is there, instead of a black or dark plate of metal, which IMHO is preferred vs having mirrors that have no environment interaction, since there is no way to stow them. So if you want it to be a simple "grey" texture, remove the metallic properties and make the material rough in the cockpit roughmet texture. it would likely break IC though.

Also, Provide the coordinates.

This ^ VR ON is the only Launch Button that Sends the Arguments, VR OFF sends force_disable_VR and LAUNCH by itself is default setting launch, no VR arguments either. If youre selecting "Oculus VR API" from the Drop Down it will not Run Any OpenXR Commands, You Need to Select OpenXR for OpenXR Libraries. It will default to OpenXR if the only Argument is "--force_oculus_VR", the Specific API Arguments Require "--force_enable_VR". I literally switch back and forth between ST/MT and Oculus/OpenXR a 100+ times a week testing w/ DCS Testers. The command functions are correct. Launch VR ON: The Arguments are Automatically added to the Process.String when launching, no need to add Arguments to the Launch Arguments Box. These Arguments are Automatic when Choosing VR On, ST or MT. If Selection is Default Windows API: --force_enable_VR if Selection is Oculus API --force_enable_VR --force_oculus_VR If selection is OpenXR API --force_enable_VR --force_OpenXR If Selection is SteamVR API --force_enable_VR --force_steam_VR

I was looking at the code, as I said above, it's all sorts of honky due to null value error, so I'm re-writing it to clear it up.

I actually just found a null bug in those functions. Originally, Copy would to Copy from Source to Destination Backup would backup in the same SG Folder so it would create a /Config_MMDDYYYY_HHMMSS/ Folder. Delete would make a backup w/ Same format then Delete the /Config Folder. But there's a null value so it's not copying folders correctly, if at all, I will have to fix that. Force Oculus Launches using Oculus Runtimes (no OpenXR). Force OpenXR Launches using OpenXR Runtimes (OpenXR Menu should be visible) The reason that command is launching w/ OpenXR for you is the Argument for Oculus is wrong, should be: --force_oculus_VR

In the future, but Its a bit trickier this time around so I have to be careful how I implement it.

Files are Attached to first post.

07.03.2023.32 - Fixed VR Selection Box Staying Blank on First Run (Should Default to "Windows Default") - Adjusted Build Scan Functions Order (Moved Module Version Check and Module Scan to the End.) - Adjusted Startup Functions Order, Removed depreciated Function. - Revised Sim Scan Engine / Saved Games Scan, Fixed Error that Resulted in Folders Being Detected even though it was not set or existing. - Adjusted Startup Logging for Better Information. - Adjusted Startup Order for User Profile Options (will Load Custom UserP Folder prior to App's Folder Creation) - Re-enabled Hidden "ULTRA" Shadows Selection. - Increased Scripts Textbox to 5,000 Characters. - Increased Autoexec Textbox to 1,000 Characters. - Fixed CrossLink resulting in Command for "Install" being sent for Uninstall functions on 75% of the Module IDs. - Splash Screen Revision G. - Added "Classic USNF" Theme - Fixed Stuck Filter/Parameters on Open File Dialog and Open Directory Dialog. - Added More Exception Catches around Build Scan (trying to determine where the thread hangs). - Added Exception Catch around UI Command / Memory Address (Attempt to Fix Hanging Build Scan Thread).

Okay, worth a shot, Scan / Calculate is an entirely different thread, which is odd that it would force another thread to finish. I've been re-ordering some startup calls, hopefully it was just a errant call stopping it, As the logs indicate: -The Interposer Build Scan Function was Executed, -The Thread was Created/Started, -The Multithreaded function never got past the 1st line of the Function after the thread was created and started. The 1st Line was to Change UI to Show Build Scan Active, So I'm Assuming it's hanging on waiting for memory address for the command on the 2nd line. Which helps narrow down some, and the specific command is also used in Scan/Calculate Build Thread along with a few others as it's a General UI Command, but since it's being run on another thread, it has to access the UI / Main App Thread's Memory Space to Execute. So it's likely that the Build Scan Thread is not able to Access the Memory address to run the command sometimes at startup (either because it's locked/in use by another thread, or simply not created yet) Clicking the Scan Calculate Button Runs the same command 4 lines down it's multithreaded function, While the Build Scan tried and got stuck trying to access the memory address and was waiting for the command to run before proceeding, The Scan Build Details Thread was able to access the command/memory address successfully, which releases the wait on the Build Scanner Function to complete it's function/routine. The Joy's of Multi-Threading :-). It's likely the Build Scan Thread is started and launched before the UI Generates the Memory Address for the function. Depending on how fast the app UI is generated vs how fast the system processes the other threads is likely what's causing the Successful / Unsuccessful Launches. I've put exception catches around that function, hopefully if the memory address isn't accessible, it catches as an exception, logs it and proceeds. if that doesn't work, I will have to look into it further. it could be something else entirely, But the fact that it stops on that line, and that line is executed by the other function/thread as well, leads me to believe it's that command.

Prolly Could Click the "Refresh" button Immediately Next to "Builds" on the home screen, should do the same function.