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?
Update:thebug 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.
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
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.
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
This may actually be a single material that is problematic, and it’s my custom
material. I still can’t reproduce the issue, but I may have a possible
workaround, another customer who had the same issue reported that he figured
it out: rename my scenery folder so that it starts with a letter “z”, so my
scenery loads last. So, the folder would be named “zromandesign-airport-cyoo”.
This cured it for him. However that’s not a solution for obvious reasons.
Naming convention is there for a reason and should be observed, and also this
would not work with the Marketplace release as you can’t rename things the way
you can with Community folder. So what can it be that the order of loading
fixes this behavior? My material uses textures based on 2 png files - albedo
and comp, both are copied from Asobo texture, the only reason for this
material is that colorizing works, as it doesn’t with that particular Asobo
material but does with custom material. Otherwise there’s nothing special
about it.
@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.
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.
[ 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: https://devsupport.flightsimulator.com/t/4278
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
https://devsupport.flightsimulator.com/t/4305 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 ?!). https://devsupport.flightsimulator.com/t/4292
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…
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.
In case it’s useful, the folder structure for it in the package is
\romandesign-airport-cyoo\MaterialLibs\RD_Materials\Textures\ And the
filenames are RD_WHITE_ASPHALT_CRACKED_01_COMP.PNG.DDS
RD_WHITE_ASPHALT_CRACKED_01_ALBEDO.PNG.DDS
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
@RomanDesign Any chance you have other products with a material library named
RD_Materials that could be conflicting? If not, can you also try to clear the
SceneryIndexes cache directory in your AppData MFS folder?
@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
