plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

In the upcoming flighting, we've changed the behaviour of the content.xml file. If your addon uses this file, please read this article!

Please take a moment to read the platform’s guidelines before you get started!


question

RomanDesign avatar image
RomanDesign asked FlyingRaccoon commented

Missing textures reported in my airport, but I can't reproduce.

One of the first customers for my fresh CYOO release has reported missing textures on some aprons and provided screenshots. I can't reproduce it. The aprons use mostly Asobo textures that are present in default Material libraries that are in the Scenery Editor. "Asobo Asphalt" etc. I used them for aprons, together with coloration, as I did on previous releases. Looks normal on my PC, but see attached screenshots for what a customer sees.

Some aprons are using custom textures I created, often with colorizing attribute, some are base-fs library Asobo default materials. For custom materials that show up fine on my PC, is there a way to diagnose/test my materials? I've never had this problem before. For ASOBO default libraries, are there any that somebody can possibly be missing, because of optional Asobo add-ons? I have removed everything from my Community folder just in case, but I do have Asobo contents from the World Updates etc. Is there a list of materials that are safe to use (meaning everybody with a base MSFS install will have them)?

Any advice or tips on how to debug/fix that?1b.jpg

2b.jpg


If it helps, here's an example of how my material is set up:


1656371887304.png

Update: the bug is now reported by 4 separate customers, so that's not a one-off. 2 of them have confirmed the workaround that fixes it: renaming the folder from "romandesign-airport-cyoo” ro "z_romandesign-airport-cyoo". This fixed the issue. There bug must be related to the order textures are loaded. But it won't help once the scenery is available on the Marketplace, as you can't rename folders then. So a better workaround or fix is needed, or I will have hundreds of customers reporting this and will drown in support emails through no fault of mine.

scenerymaterialstexturing
1b.jpg (44.9 KiB)
2b.jpg (24.7 KiB)
1656371887304.png (3.4 MiB)
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Boris_ avatar image
Boris_ answered FlyingRaccoon commented

Hello @RomanDesign @DrzewieckiDesign ,

Can you make sure that no mods or tweaks are used when you encounter this problem and check in the console if there is a specific line about this event ?
Can you also move the camera to another airport to see if the problem also occurs elsewhere?

Regards,
Boris

21 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

The problem is that it's not me that encounter the problem, and I can't reproduce it. Askin ga customer to enable dev mode and peak at the console etc. is problematic.
1 Like 1 ·

We have had feedback from the engine team and there is no known cause for this behavior.
I understand the difficulty of getting your customers to run diagnostics so I suggest you tell your user to open a ticket on our zendesk.

Thanks,

Regards,
Boris

0 Likes 0 ·
Added a screenshot of my material.
0 Likes 0 ·
Show more comments

The bug is now reported by 4 separate customers, so that's not a one-off. 2 of them have confirmed the workaround that fixes it: renaming the folder from "romandesign-airport-cyoo” ro "z_romandesign-airport-cyoo". This fixed the issue. There bug must be related to the order textures are loaded. But it won't help once the scenery is available on the Marketplace, as you can't rename folders then. So a better workaround or fix is needed, or I will have hundreds of customers reporting this and will drown in support emails through no fault of mine.

1 Like 1 ·
Can you send us your package ?

See 3) Provide Private Content

Regards,
Boris

0 Likes 0 ·
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...
0 Likes 0 ·
Hello @RomanDesign

How is your material library named?

0 Likes 0 ·
RomanDesign avatar image RomanDesign FlyingRaccoon ♦♦ ·
As you see on the screenshot it shows up as "romandesign-airport-cyoo"
0 Likes 0 ·
Show more comments

@Boris_ - Another customer has reported the same, here is his screenshot:

1656365903106.jpeg

0 Likes 0 ·
1656365903106.jpeg (458.6 KiB)
@Boris_ I just had another report. So that makes 4 customers with the same issue. I still can't reproduce it. I just submitted my CYOO scenery for the Marketplace through Marketplace Content Portal, in case you want to check the files.
0 Likes 0 ·

Another customer, same issue: 1656438804369.png

0 Likes 0 ·
1656438804369.png (3.3 MiB)
Show more comments
RXP avatar image
RXP answered RXP edited

[ START OF EDIT -

I'm sorry for the screen grabs but I find this forum board is the most hostile to following up discussions:

- it breaks the formatting or add non-sense HTML junk when copy pasting

- it hides the discussion trees which makes it harder to find answers to posts, or to find new posts.

- there is no "copy link" unless a few top level posts, which makes it harder to share the direct link to a post in a thread.

Or is there a user-facing configuration setting to solve all of the above that I missed to find?!?

- END OF EDIT ]


@RomanDesign

When reading that renaming the folder corrects the issue, I can't help thinking your scenery could be affected with this issue:

Is scenery file structure and duplicates still a thing? - MSFS DevSupport (flightsimulator.com)

1656432093256.png



Maybe having a log file of some sort would help identifying this kind of problems more easily at the user level, and the 3rd party level (a log telling "file XXXX is overridden by file YYYYY"), but it doesn't seem a log file is any good idea or at least not "planned anytime soon":

@SonantAlpaca

1656431599782.png

Add a way to view CTD (crash) logs to identify the cause - MSFS DevSupport (flightsimulator.com)


@EPellissier is giving some hope though:

1656431970189.png

Event ENGINE_AUTO_SHUTDOWN causes CDT...! - MSFS DevSupport (flightsimulator.com)


Or could it be you're modifying an Asobo texture is blocked by the engine? I wish I had a definitive answer to this question because I'm having an issue where a modified material doesn't seem to be displaying the modification but instead is displaying as if it isn't (actually the engine can even be displaying 2 instances of the same object but only one of the 2 respects the modified material ?!).

SU9 overriding some glTF materials: is this a regression or intentional? - MSFS DevSupport (flightsimulator.com)





1656431599782.png (22.4 KiB)
1656431970189.png (109.3 KiB)
1656432093256.png (185.0 KiB)
4 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

This could be related. At least part, if not all textures that are reported missing are my custom material, derived from Asobo material. The reason for creating it is that the "cracked ashpalt" Asobo material is ignoring the "colorize" setting and is not changing color at all. So I took the 2 DDS files from that material, converted them to PNG, then renamed them (RD_+old filename), so the filenames are different, then created my material using both files (Albedo + Comp) and this way colorize works now and I can change the tone of different areas. The material is now, and the images have different filenames, although are using Asobo-derived images. 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...

0 Likes 0 ·
RXP avatar image RXP RomanDesign ·

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.

1 Like 1 ·
I think we got your point regarding log files - there's no need to put links (or snapshots) to the original discussion in every thread.

On top of this: without knowing the exact cause of the issue reported by the OP, how can you assume that a log file would help?

Best regards,

Eric / Asobo

0 Likes 0 ·
Show more comments
RXP avatar image
RXP answered RXP edited

@EPellissier

Hi Eric,

Experience shows that the log file, provided it includes meaningful content for what it's used for (which could be different information than what is in the console, but not necessarily), is a valuable tool to help debunking these kind of bugs and most CTDs: https://www.qwant.com/?q=site%3Aforums.x-plane.org+log.txt&t=web

It is also an invaluable tool for 3rd parties when you also have the API in the SDK which gives you access to outputting your own log message interleaving with the host messages, because this gives a timeline of events you can relate one to the other.

Best regards,

Jean-Luc

4 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

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

0 Likes 0 ·
RXP avatar image RXP EPellissier ♦♦ ·

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

1656522577936.png


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)

1656536977999.png


0 Likes 0 ·
1656522577936.png (70.3 KiB)
1656536977999.png (46.4 KiB)

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.

0 Likes 0 ·
Show more comments
virtuali avatar image
virtuali answered Cygnific commented

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.

7 comments
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

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
0 Likes 0 ·

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.

0 Likes 0 ·
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.
0 Likes 0 ·
Show more comments
Ah, then renaming to "z_..." wouldn't have fixed the issue...
0 Likes 0 ·
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.

0 Likes 0 ·
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...
0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.