Jean-Luc, Although I agree that log files can be useful, my experience shows
that they are definitely not the ultimate solution to identify & fix CTDs (at
least not “most of them” as you seem to imply). As a side note, I am not too
sure what the link you provided is supposed to illustrate. I’ll make sure I
get back to you to see if/how a log file could have helped when then OP’s
issue is identified and fixed. Best regards, Eric / Asobo
Ask your customers if they have installed the scenery on an external drive
formatted in Fat32 or ExFat. Those two filesystems don’t support filenames
longer than 256 chars, only NTFS does so, considering how long complete
pathnames might end up in a package, it’s not difficult to surpass that limit,
which would prevent some files from loading. Got a similar report from a
customer, who also said he had missing texture, in addition to stuttering,
which started when he bought a new external drive where he moved the whole
Community folder to, which nowadays usually ships pre-formatted in ExFat, so
they can be used on PC/Mac/Linux with no formatting required. Following my
suggestion, he reformatted in NTFS, and all problems were gone.
you’ll find my reply in another tree of messages, unfortunately I pressed the
wrong “reply” link so it seems?!
Just had another one. I highly doubt people are using external drives a lot
for MSFS. However the path length could be an issue. Those textures filenames
are long and the path is long too. Maybe I could rename them to something
short in the update. I wish I know hot to test it, but I can’t
Ah, then renaming to “z_…” wouldn’t have fixed the issue…
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:
[need help understanding log.txt files - Technical Support - Cubby's Corner - X-Plane.Org Forum
understanding-logtxt-
files/&do;=findComment&comment;=980142](need help understanding log.txt files - Technical Support - Cubby's Corner - X-Plane.Org Forum
help-understanding-logtxt-files/&do=findComment&comment=980142)
like: (which are just simple file missing/referencing errors)
1. 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:
1. 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:
1. 0:42:42.150 E/SCN: WARNING: got error on DSF load for scenery file 40, -75, Custom Scenery/KTEB_TETERBORO/
2. ...
3. 0:42:43.800 E/SYS: +-------------------------------------------------------------------------------
4. 0:42:43.800 E/SYS: | There was a problem loading the scenery package:
5. 0:42:43.800 E/SYS: | Custom Scenery/KTEB_TETERBORO/
6. 0:42:43.800 E/SYS: | The scenery may not look correct.
7. 0:42:43.800 E/SYS: | Please see the log.txt file for detailed error information.
8. 0:42:43.800 E/SYS: | (io_dsf.cpp:686)
9. 0:42:43.800 E/SYS: +-------------------------------------------------------------------------------
10. 0:42:44.563 E/SYS: +-------------------------------------------------------------------------------
11. 0:42:44.563 E/SYS: | The following scenery package has a problem and will therefore not be loaded:
12. 0:42:44.563 E/SYS: | Custom Scenery/KTEB_TETERBORO/
13. 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.
14. 0:42:44.563 E/SYS: | http://lookup.x-plane.com/_lookup_10_/missing_custom_scenery.html
15. 0:42:44.563 E/SYS: | (io_dsf.cpp:759)
16. 0:42:44.563 E/SYS: +-------------------------------------------------------------------------------
Also this one:
1. 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:
FYI Another user has confirmed that renaming the scenery folder to
“z_romandesign-airport-cyoo” solves the issue (adding “z_” so scenery loads
last). It may help you to figure out why it happens. This is not a solution
though, because with Marketplace packages users can’t rename scenery folders.
This has to be sold, because I got 6 people at least who reported this
problem. It’s definitely widespread
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.
I’m not sure a customer would be comfortable editing that. I also don’t want
to be responsible for ruining his MSFS if he attempts and fails…
I see you got the package. Let me know what you can find. I got a couple more
people having this issue, this is widespread. Two people confirmed they had it
on NTFS-formatted drive, I was checking if they had a file system that maybe
was limiting access to a file path this long or something…
I did ask 5 customers with the problem about that, provided instructions on
how to check file system. 2 of them have reported back, both are running NTFS
SSDs. So that’s not the issue. But it was worth checking, thanks. It still may
have something to do with the filename/path length inside MSFS strings
somewhere though. Not likely though, because adding “z_” to the path cures it,
so far in every case.
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
Seems to be longer on my system!?!?! See here:
https://devsupport.flightsimulator.com/t/4303
VFS Root too long
The standard path to the community folder is something like this:
F:\WpSystem\S-1-5-21-7555345473-1456586222-3848173965-1001\AppData\Local\Packages\Microsoft.FlightSimulator_97675b3d8b558\LocalCache\Packages\Community
This is already taking 151 characters out of the 260 available (MAX_PATH) and
this doesn’t leave much remaining characters for any sub-folder.
Is this real about MAX_PATH? So not related to NTFS file system, but it’s an
MSFS limit? This could explain why only some users get it - some may have a
slightly longer path than others. Mine is short as MSFS packages are installed
into I:\MSFS2001\ and Community folder is in i:\MSFS Community\ (with addon
manager handling linked dirs). So it would be logical that I can’t reproduce
it. However it’s not clear then why adding Z_ to the folder name solves it.
Any ideas? If the path length is feasible explanation I can rename the very
long texture filenames in my material library to something very short in the
next update. So RD_WHITE_ASPHALT_CRACKED_01_ALBEDO.PNG.DDS would become
CRK.DDS if that could solve the issue.
I don’t know if this is the root cause in your case, but this is a
possibility, although like you I doubt this in particular here because when
adding even more characters it seems to be working. Anyways it is an
information to keep in mind just in case, and if there would have been a log
file like in X-Plane saying something like:
00:44.231 Failed to find resource 'RD_WHITE_ASPHALT_CRACKED_01_ALBEDO.PNG.DDS', referenced from file 'F:\WpSystem\S-1-5-21-7555345473-1456586222-3848173965-1001\AppData\Local\Packages\Microsoft.FlightSimulator_97675b3d8b558\LocalCache\Packages\Community\romandesign-airport-cXXX-theairportname\scenery\global\scenery\texture\RD_WHITE_ASPHALT_CRACKED_01_ALBEDO.PNG.DDS'. Reason: filepath too long.
Or if no such entry would be found in the log file, then you’d be 100% sure.
You’d also be 100% sure of the root cause if the log file would say this
instead for example:
00:44.231 Resource override: 'F:\WpSystem\S-1-5-21-7555345473-1456586222-3848173965-1001\AppData\Local\Packages\Microsoft.FlightSimulator_97675b3d8b558\LocalCache\Packages\Community\romandesign-airport-cXXX-theairportname\scenery\global\scenery\texture\RD_WHITE_ASPHALT_CRACKED_01_ALBEDO.PNG.DDS' was replaced with: 'F:\WpSystem\S-1-5-21-7555345473-1456586222-3848173965-1001\AppData\Local\Packages\Microsoft.FlightSimulator_97675b3d8b558\LocalCache\Packages\Community\anothervendor-airport-YYYY-theairportname\scenery\global\scenery\texture\RD_WHITE_ASPHALT_CRACKED_01_ALBEDO.PNG.DDS'.
In which case you’d know what to look for and change:
https://devsupport.flightsimulator.com/t/4278
Just saw this comment - the comment system here is very inconvenient, easy to
miss things. Yes, that’s likely. I didn’t know or read anywhere that material
library has to have a unique name. So my CYOW has the same name in its
material library, though this material is new. Can it still conflict? It would
explain why only some people have this problem, as only those who already have
my CYOW would have this problem.
I think that’s likely the problem. The material library name is used as an
identifier so if multiple packages are using the same, it can lead to
unexpected behaviour. I’ll try to repro the issue on our side.
This was it! Thank you. Knowing what you said I could both reproduce the
issue, and fix it by renaming the material library.
I’m glad you’ve found a solution to this issue. What would be great in the
future is to have some user facing tooling to automatically detect and inform
users and devs alike, when a file overrides another one.