question

I can't see where the problem could be, but it can be there somewhere. Renaming the folder by adding "z_" solves it, so somehow the loading order makes a difference...

With a log file, it probably would have been solved a long time ago without bothering Asobo. These are time savers for everyone in practice, and hands-on experience dealing with this every day shows that most of the time users can figure out themselves the issues thanks to a log file.

Eric,

I appreciate you're investigating the feasibility, so I wanted to help in answering your question: "how can you assume that a log file would help?", and I've provided a link to a Qwant powered search over the entire X-Plane.org forums for the keyword "log.txt" (which is the filename X-Plane is saving its log file to).

The only assumption I have is that I don't know whether you're accustomed to X-Plane log file, and/or the discussions revolving around its log file. So this link should give you a lot of practical use case where you can find many examples of end users and 3rd parties using it to solve problems, or users helping each other to solve issues they have with X-Plane thanks to the X-Plane log file information.

PS: I agree with you 100%: log files are not the ULTIMATE solution to identify & fix CTDs. I believe it is also important to distinguish your point of view (code wise) as a developer of the host app, and our point of view (code wise) as developers of add-ons, with limited to no knowledge about the steps the host application is going through. And my experience in this case, is that the log file is an ADDITIONAL tool in the arsenal that can help finding the reasons faster (thanks to the information about the context of execution it provides), either directly (this is the bug) or indirectly (this can't be the reason so let's try from another angle approach), this can often reveal very simple problems perfectly solvable at the user side only (hey, FS2020 can't deal with MAX_PATH - prepending all paths with "\\?\" maybe?, so we can't load this file and this is why your add-on is not working), etc...

PS: to save from searching all the links, I've clicked on a few one reported by Qwant on the first page, and here is a concrete example:

https://forums.x-plane.org/index.php?/forums/topic/92100-need-help-understanding-logtxt-files/&do=findComment&comment=980142

You then got a number of errors like: (which are just simple file missing/referencing errors)

0:00:44.231 E/SCN: Failed to find resource 'Panel.png', referenced from file 'Aircraft/Heavy Metal/B747-100 NASA/'.

And in another post in the same topic:

SkyMaxx Pro: WARNING! GPU free memory at -84800 KB. X-Plane may crash due to lack of memory. Reset your settings or remove memory-intensive add-ons such as photo-scenery.

Or this one:

0:42:42.150 E/SCN: WARNING: got error on DSF load for scenery file 40, -75, Custom Scenery/KTEB_TETERBORO/
...
0:42:43.800 E/SYS: +-------------------------------------------------------------------------------
0:42:43.800 E/SYS: | There was a problem loading the scenery package:
0:42:43.800 E/SYS: | Custom Scenery/KTEB_TETERBORO/
0:42:43.800 E/SYS: | The scenery may not look correct.
0:42:43.800 E/SYS: | Please see the log.txt file for detailed error information.
0:42:43.800 E/SYS: | (io_dsf.cpp:686)
0:42:43.800 E/SYS: +-------------------------------------------------------------------------------
0:42:44.563 E/SYS: +-------------------------------------------------------------------------------
0:42:44.563 E/SYS: | The following scenery package has a problem and will therefore not be loaded:
0:42:44.563 E/SYS: | Custom Scenery/KTEB_TETERBORO/
0:42:44.563 E/SYS: | It requires an additional library scenery package that is not installed, or it is missing some of its files.
0:42:44.563 E/SYS: | http://lookup.x-plane.com/_lookup_10_/missing_custom_scenery.html
0:42:44.563 E/SYS: | (io_dsf.cpp:759)
0:42:44.563 E/SYS: +-------------------------------------------------------------------------------

Also this one:

0:51:32.920 W/ATC: Could not find an appropriate flow at KTEB...attempting to autogen one on the fly

etc...

All of these are valuable info both when developing an add-on (post-morten a CTD, because otherwise the console content is not useful when it dies with the process and you can't read it), but they are also valuable information for end-users trying to figure out and trying to solve their own local problems on their systems.

----------------------

PS: There is also this wishlist topic I've linked you to in the past:

How to troubleshoot user CTDs? - MSFS DevSupport (flightsimulator.com)

I gave you a real world example of something that HAS happened, a customer who DID move the Community folder to an external drive, because he exhausted space on the main drive so no, it's more common that you think. You don't have to use my suggestion, of course.

And no, the solution is not rename your textures, because in a way or the other, you will hit the 256 max chars due to things outside your control, like the user account name for example: a default install folder for the MSFS Community is already quite long as it is, on my system the Community root starts at 110 chars, and that even before you add your package root name and the complete path down the actual texture name, it's quite common to reach or possibly exceed 256 chars.

I think this caused problems on early MSFS releases, which required a change in a registry key or a policy change to fix it, and I guess later installers must have added this fix automatically (it become default after a certain Windows 10 release) but, it sill requires NTFS.

The main problem is, not many users are even aware of this problem, so maybe MSFS could use a small check that, if the Content is moved on a non-NTFS drive, it could issue at least a warning about it.

Have you tried to keep the original name, and just change the loading order in the CONTENT.XML file ?

That would at least confirm it is a loading order issue, since by editing the content.xml you are effectively changing it.