5 hours ago, Mace said:

To me that's simpler yet than the "KSP" method mentioned previously (what is "ksp"?)

KSP stands for Kerbal Space Program. It's a game where you can explore space by building Rockets using parts. Very fun game with great physics simulation!

KSP on Steam Store

Edited October 10, 20196 yr by UltimateAntic

4 hours ago, C2615 said:

BUT HELL, why 3rd  add-on makers (and many other non-FS app) so love to push everything they have(even aircraft) into "My document" or "ProgamnData" or "AppData" under my C:\ drive(although I have moved my document out of C), without even asking?! MY C DRIVE IS NOT FOR THESE S***T!

Microsoft recommendations:

Use %ProgramFiles% to install the application, so it will get extra security protection from UAC. Nothing should try to write anything in this folder.

Use %APPDATA% for smaller configuration files that contain preferences that might change by user account (es. .INI files)

Use %PROGRAMDATA% for binary files that will be rewritten by the application and don't change by user (es. program databases)

LM recommendations:

Install the add-on.xml file under %USERPROFILE%\Documents, so it will get Auto-discovery, that is the ability to uninstall the whole sim and have the add-on being recognized again on the next installation without having to do anything. It's NOT required the add-on itself to be located *here* in the Documents folder, just the add-on.xml, but some developers puts all files under here so they can spare themselves from writing the actual installation path in the add-on.xml <Path> lines.

I purposely used VARIABLES ( those % signs ) to make it clear that, these locations are NOT set in stone, while they are *usually* on C:\ they can be moved, even if not all of them can be moved very easily but, if an installer will use the proper Windows API functions to read this VARIABLES, the files will end up and will work even in their moved location.

There are so many reasons that are simply too long to explain here why those are very sensible choices, and I doubt Microsoft will go against their own standard rules which has been there since 2006 when UAC came out.

4 hours ago, C2615 said:

BUT HELL, why 3rd  add-on makers (and many other non-FS app) so love to push everything they have(even aircraft) into "My document" or "ProgamnData" or "AppData" under my C:\ drive(although I have moved my document out of C), without even asking?! MY C DRIVE IS NOT FOR THESE S***T!

 

There is an excellent guide https://www.prepar3d.com/forum/viewtopic.php?f=6322&t=120676

that explains why you need to do none of the things that you have apparently done.

Isn't it too late? Just wondering...

37 minutes ago, virtuali said:

 

I appreciate your post, factual and didactic. But there is an obvious tension between the well thought but complicated construction of software engineers and what the user wants. It is time that the former listen to the latter. 

1 hour ago, domkle said:

I appreciate your post, factual and didactic. But there is an obvious tension between the well thought but complicated construction of software engineers and what the user wants. It is time that the former listen to the latter. 

The OS folder layout design is not up for review or modification by the FS2020 crew.  So... best practice will remain unchanged until there is a completely new version of Windows that no longer dictates the current design elements.

The actual error is in purchasing a small drive for the single most important drive of one's system.

Just now, WarpD said:

The OS folder layout design is not up for review or modification by the FS2020 crew.  So... best practice will remain unchanged until there is a completely new version of Windows that no longer dictates the current design elements.

The actual error is in purchasing a small drive for the single most important drive of one's system.

I agree that FS20 will probably not change the Windows structure ! That was a general statement.

On the second point, I genuinely don't really understand where the problem is. My P3D3 main folder is on G: SSD drive with  a "program files (x86)", not on C:. The issue for me is more the scattering  of "utility" files on the C : and an E: (I split in two my Users/xxx directory) drives.

Rather than try to relocate FSX, almost anything for FSX can be re-located elsewhere than C: with pathing set in the configs.

1 hour ago, WarpD said:

The actual error is in purchasing a small drive for the single most important drive of one's system.

The bigger error, IMHO, is in not learning about and effectively using symbolic links to alleviate some of the pain.

Just one example article, chosen mostly at random: The Complete Guide to Creating Symbolic Links (aka Symlinks) on Windows

 

K.I.S.S.

I like the X-Plane approach to files.

On the new MSFS, I'd like to see a comprehensive, yet friendly User Interface.

The new MSFS sure has drummed up a lot of excitement in the flight simulator community. Make it great.

Windows has "rules".  The rules are expected to be followed.  Many protection products now help enforce said rules by blocking file writing and sometimes even reading to areas outside the proscribed locations.

Compliance isn't really that difficult nor is it painful or messy or anything else.  It's a well defined, structured system that when followed reduces support issues dramatically.  The only error I've ever seen is the design of computer systems with small C drives.  Not a wise choice.  My C drive is 1/2 a terabyte.  That's the smallest drive on my system.

The FSX file structure is very simple:

 

User files:

C:\Users\you\AppData\Roaming\Microsoft\FSX

C:\Users\you\AppData\Local\Microsoft\FSX

C:\Users\you\Documents\Flight Simulator X Files

C:\Users\you\Pictures\Flight Simulator X Files

 

All User files:

C:\Users\All Users\Microsoft\FSX

(C:\ProgramData\Microsoft\FSX)

 

Program files:

C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X

 

Those locations are entirely necessary for networking and security in Windows. Programs designed to run on other systems, as well as windows, will be a lot simpler.

 

The biggest bane to Flight Simulator based systems is to install out of the common system, that's where 90% of all errors creep into the simulator, the other 10% is from addon planes, AI traffic and scenery. An individual may not see it this way, but from a support perspective it's glaring and obvious, and unnecessary.

Most errors creep into the simulator through relocating out of the common system in order to avoid permission problems. It's easier to check the one box they didn't know about when they recommended installing into a private folder.

If we have to install add-ons that write out to their own files inside of the program files we can set the Modify Allow permission on that folder for the Users group. Then install the add-ons.

 

By using the configs files can be relocated to save space on the C drive. Also mentioned are symbolic links which is another way to deal with space and move files to another drive, but is an approach that can befuddle the inexperienced users.

The so-called location problems that are spoken of regarding FSX and P3D are non-existent.

On 10/9/2019 at 8:57 PM, Mace said:

To me that's simpler yet than the "KSP" method mentioned previously (what is "ksp"?)

You should've quoted me!

 

So KSP is Kerbal Space Program, it's a very popular simulator in which you build your own planes and rockets and stuff. It's actually really fun; and it certainly isn't a kid's game due to the really sharp learning curve.

Just kill off the DLL.xml system.

That's all I care about.

 

On 10/9/2019 at 8:12 PM, Flybynumbers said:

Since most simmers use a dedicated PC these days anyway...

What makes you think this? Some may do but i'd be very surprised if most did - I certainly don't.