SkateZilla

Anyone can compile systems, the Visual Studio files are there, only some parts outside of the SDK are missing.

A-4E-C is a 100% Original module, not a mod of an existing module, they didnt circumvent anything. The team developed all of their systems from scratch, they have their source code for the DLLs to make changes and re-compile them. If anyone wants an F-5E Export Version, with systems not already part of the F-5E-II they'd have to code all the systems from scratch and compile the DLL.

ED cant just throw mods into the core for multiple reasons: A. Licensing, most mods use models that acquired thru 3rd Party Sites that have strict License agreements. B. Support, the Mod would need to be supported and the mod owner would have to have an agreement with ED to submit their work to ED to be included in each patch. C. Trademark Licensing, ED would have to pay for any TMs included in the Mod as it would be part of a commercial product, as a free distributed mod, it does not. There are a dozen or so more reasons, but those are the main 3.

Multi-Threaded Binaries are Located in: \DCS World\Bin-mt\ Also there's really no reason to put the --Force_enable_vr, Argument in there, Just use "Launch VR On" button. (make sure you select the proper VR API first)

Are you using the default path \Program Files (x86)\Tacview\? or another location, it might be a user path issue, like I said, I'll likely re-write it w/ a select folder dialog that way a user can choose 64/32 bit if they so choose. in the log, during the startup checks, ~ line 135, you'll see: 09/09/2023 | 09:29:43 PM | CHECK | Checking for Tacview Software 09/09/2023 | 09:29:43 PM | CHECK | Checking Default Path it should say whether or not it was detected, As stated above, I think there might be something hinky with user paths / check and trying to pull the icon, if you are using a custom user path instead of the default install path.

Less memory usage in 32-Bit Mode? Either way, a quick rewrite of the Check function may be needed, as Loading the Icon is part of that function, but if Logs say it's detected and installed, it's simply not able to access the file to pull the icon from it, however, if logs show its not detected as installed, then it's a "Check" function path issue. and the Launch Function is able to launch despite the Check Function not able to verify the file / directory exists.

IIRC, the function is coded for the 64.exe, so the "Check" looks for that exe, and if its there, it pulls the icon from it, since your pointing to the non 64.exe it's not pulling an icon, as the check is looking for a different file. I'll have to double check it, but I'm confident that's the case, in which all I have to do is augment the "check" function for both the 32bit and the 64bit exe depending on which one the user selects.

I'll double check when I finish other parts, But work this week is minimal as I am busy with job this week + other events.

why would you launch the 32-bit version? once the parser is re-written and cleaned up I'll check and add the 32-bit executable to the check, but IIRC, the 32-bit executable is meant for older 32-bit sims that still use tacview, DCS has long since been 64-Bit

Assign them in Mission Editor as "00" instead of "200", and paint the "2" on the nose section.

There should be a Tacview Icon: The app pulls the Icons directly from the file. As for a dedicated Forum Section, that's unlikely to happen.

bleed off the hydraulic pressure.

for the record, if ED decided to pursue a solution, I wouldnt expect it to be a quick turn-around, as it would require a lot of re-writing viewport codes.

You Saw Flyby Shots w/ Minimal Animations, no Weapons Deployment, No Countermeasures, etc etc etc.

The app doesn't touch the Input folder due to unique USB Names and Paths per machine. If you backup the /Saved Games/ Folder or Saved Games/Config/ Folder entirely then it will contain the /Input/ folder.

Check the Preset Files, Make sure there is not a options.lua in \Presets\Default\ Folder. Its stating it cannot move the file because it's already there.

Graphics Rendering is never ending, in the time it takes you to build the model and animated it, the technology has changed, and you have to go back and revise it, If the community had any idea how many times I had to go back and re-do the Super Hornet Model to confirm to new standards, they'd lose their minds. But that's me, my Level Of Detail / Standards are very high, to the point where, the source model I licensed is likely going to be augmented by laser scanned datapoints to correct the shape, and re-doing the UVW Maps and moving to higher resolutions etc.

IMHO, Coming from someone that does Cinematic Rendering as well as Models for Games: Mesh Creation and UVW Unwrapping and Texture Template Creation is 90% of the work. So, not to sound like I'm belittling anyone's work, Licensing a Prebuilt/textured model is basically jumping to the finish line sort to speak, The standard 200 Arg Animations for DCS, I can do in a day, if the connectors and pivot points are already rigged in the model. if not it will likely be around a week, to properly align and rig all the controllers, connectors, and pivot points for each item that will be animated. now if I want to do damage and expanded animations (likely 500+) it would take even longer.

Proper Integration, AI and Systems, etc. Use the Current B-1B and B-52 and tell me they are used properly by the AI.

Small Correction, The Community Modder's License Models and roughly convert them to DCS every week. (Mainly from TurboSquid), In Which case, most of those Models have a non-commercial license agreement which prevents it from being integrated into the sim commercially. and most of the time, when I say "rough" conversion, I mean textures adjusted, and main things (Gear, Canopy) animated, w/ zero to no damage modelling, or work put into a proper integration. That's not to say there are teams that build their own models, but at the Level of Detail needed for DCS< I highly doubt they build, separate, animate, and have it 100% in game in less than a few months.

I'll look into it and likely add some more logging to the "Settings.Upgrade()" function to log if it was successful or had an exception. it's literally the first command executed, But you can access the settings folder and choose the previous versions folder and copy/paste the settings file to the new version's folder. Eventually I am going to separate it to it's own XML file outside of the /AppData/ folder.

FC3 Aircraft aren't clickable and will not be expanded to such as FC3 is Feature complete and pretty much in long term support status.

Apologies, It's a busy time of year for me, plus I had a hardware failure that disabled my main rig. How are you updating? As settings are programmed to upgrade the files from one version to another.

Because the fuel system in the DLL does not allow fuel transfer, as there is no code for it. Same for Wingtip Tanks, they can hold fuel, but the aircraft wont use it as there is no code to allow it to transfer fuel from those pylons.

The only time it would require a reset is if you change the path or I tell it to reset at start, It's supposed to update with every version.