There are six different ways to accomplish the same goal. The simplest is to have your thumbnail its respective
texture.variation folder named as thumbnail.jpg
As for this entry in the texture.cfg file, it is a leftover mistake from ACES. This entry points to a set of folders that only existed on ACES'
network server! It is completely useless for any simmer...
Code:
fallback.3=..\..\..\..\..\..\Scenery\Global\texture
The correct entry should have been, so any required default files from the sim's
..\Texture folder would be found:
Code:
fallback.3=..\..\..\..\Texture
Thanks for clarifying that, Fr. Bill !
I find there are so many oddities one might discover when dealing with FS, that is both refreshing and helpful when someone with your in-depth first-hand experience (and as someone well-connected with ACES), takes the time to post info which might explain things that one either has ...or potentially could encounter in the future.
Please forgive the following impromptu comments, which I feel are not only related to this topic, but to FS forum discussions in general.
I believe threads opened in FS forums should be allowed to serve the needs of the FS Community
in addition to the party who initiated the opening post.
I also believe those who may have a preference for dealing with only certain types ...or quantities... of information, should not seek to limit the information which may be posted by others, if that information addresses the main topic of the OP
and incidentally may additionally answer the questions of others related to that topic.
Some of us who roll up our sleeves and get "under the hood" in FS have found out how important it is to be aware of the internal search path that FS follows to look for files when it comes time to render the world in 3D on a single loop graphics engine that has a lot of data it has to integrate and process before it appears on screen.
In the early months after release of FSX RTM, with performance concerns being a major issue on then available hardware, investigations with utilities such as "File Monitor" and "Process Monitor" revealed that optimized placement of files into locations left over from the "development phase" at ACES (rather than the actual "installed" locations on end user folder chains !) that were actually at that time, "first" in the internal search path of the FS data loading engine...
increased performance significantly !
Many of these old "development phase" search paths were corrected in SP1, with improvement in performance from that as well as other optimizations implemented by ACES.
One might wonder based on Bill's statement here how many more of these undocumented residual "development phase" search paths are still present in the FSX code.
Personally, I appreciate knowing about them, and wish to thank Bill for taking the time to share his insight with use here, as I also believe there is still potential benefits to other FS Developers in knowing about such things.
For example, one may still be able to optimize FSX performance by putting files in "initial query" locations characterized by a shorter FS internal search path, since
it has been acknowledged by ACES that -THE- killer of performance in the FS rendering process is file I/O (and the longer the search for files, more file I/O occurs in FSX).
It can be helpful too, in preventing challenges to users troubleshooting what is going on with their FS installations when files are placed in "down-line" fallback locations that are not usual and customary folders for files; this is of course complicated when add-on sceneries are released without un-installers, or a master list of what files are placed where when installed with an installer in case that uninstaller fails.
For example, one might be aware of the potential benefit of keeping ones add-on files in "local" folder chains rather than placing them in deeply nested FS system folder chains:
GaryGB said:
http://forums.simflight.com/viewtopic.php?f=19&t=78100&start=15
Regarding the "Airport_Buildings_AP.bgl" referenced in Ed's ReadMe file:
FYI: The mapped default textures for the objects in Ed's "Airport_Buildings_AP.bgl" will be found by FSX as needed in its own "always active" internal folder chain search path, so IMHO, no need to put that BGL into the [FSX install path]\Scenery\Global\Scenery folder (it's too easy to forget it was put there if one ever needs to un-install this particular KEWL package in the future!)
So, I'd like to suggest that we put "Airport_Buildings_AP.bgl" into Ed's Emma_Field\Scenery folder instead.
Ed, I mean no disrespect to you as person, as this comes from one who wishes you well (and one who freely acknowledges having authored posts here and elsewhere containing on-topic yet voluminous "horizon-expanding" material which some might prefer to either ignore ...or at best to "save for future consideration").
But IMHO, I must say that I see risks for restricting the flow of information that may otherwise be for the good of the FS Community, if you endeavor to exercise editorial control over threads in a public forum in which you are not only the OP, but a moderator.
I have seen some of the threads here at SOH in which you were the OP "locked", IMHO unnecessarily, in what one might reasonably infer to be an attempt to limit the further flow of information into the thread.
I find that inexplicably out of keeping with the intent of public forums for the FS community frequented by both end-users and FS developers, and I am personally unfamiliar with threads being locked in FS forums except when there is seriously acrimonious posting and/or inappropriate content or conduct being manifested by a thread's participants.
Certainly one can appreciate the value of threads with concise, focused discussion that are efficient to use as a quick way to get answers, and which may serve as a valued reference for future queries by others seeking answers to their issues with FS.
But I believe that as one pursues one's own personal agenda in FS Community threads via what one might anticipate and prefer to be concise, focused discussion, we would also want to NOT limit the contribution of information from others which might otherwise prove valuable in the future, even if we may not ourselves see the immediate utility of that information for our own agenda... in the present moment.
And I do think we should express courtesy, and perhaps even consider offering a "Thank You", to folks for their well-intended contributions to a thread, especially when the person has a potential wealth of knowledge to share from their years of in depth involvement with FS as an "FS-Insider"... whether or not they may have been a full-time member of the ACES team. :salute:
With kind regards, and good wishes for SOH... as a valuable forum system of open discussion for both casual and serious end-users and FS developers alike. :mixedsmi:
GaryGB
