Some interesting and practical issues are under consideration here !
I have experienced some of what Greg mentions, and have wondered if I could solve the problems with such an additional utility that at least identifies duplicate object GUIDs.
[
DIGRESSION ]
Please forgive this "
marginally-related topical digression", but I am wondering if it may not prove relevant to one of Greg's questions, and the issue of whether GUIDs cannot be somehow better controlled in FSX.
As to the "Colossally Huge
EZ-Scenery Object Library From Hell" scenery area (ex: "
FL390 EZ-Object Library" etc. with
all BGLs in the \Scenery folder, and
all textures in the \Texture folder), when activated in Scenery.Cfg on my FS system during a flight, it promptly brings FSX to a crawl.
http://library.avsim.net/esearch.php?CatID=fs2004sd&DLID=122705
http://74.125.47.132/search?q=cache...90+EZ-Object+Library&cd=3&hl=en&ct=clnk&gl=us
Some objects and their textures are then not being written for minutes or
many minutes.
I don't know if this is simply a recurrent breakage of FSX indexes that has occurred on my system while attempting to inspect scenery areas under development with scenery density slider settings far beyond what my older system can handle and then crashing repeatedly, but
it is a real pain.
FYI: When originally adding library BGLs and textures to this single "twin folder" for EZ-Scenery object libraries, I once accidentally placed 3,000
duplicate textures in the \Texture folder along with the originals while making sure I had the newest updated files for libraries released by various authors.
Until deleted, having those duplicate textures in the \Texture folder alongside the originals caused FSX to crash when that library was active in Scenery.Cfg.
In an attempt to try and see what is going on that brought the system to its knees, Sysinternals Process Explorer (with FSX selected) shows that all object libraries in the just-activated "EZ-Scenery Object Library From Hell" scenery area (including those that have
nothing to do with objects known to be placed in the scenery for the active loaded flight)... apparently are being
indexed at runtime, mid-flight.
Funny thing is, for performance I turn
off the Windows Indexing Service related to the "Windows File/Folder Search" function (and BGLs are not supposed to be a "Document Type" indexed by that MSIE Index.Dat engine anyway); so I assume this is some 3rd party application function such as FSX itself doing the "indexing"... to then be written into the IDX files in the following Windows XP Pro 32-bit folder at:
C:\Documents and Settings\All Users.WINDOWS\Application Data\Microsoft\FSX\SceneryIndexes\
I have also found via Sysinternals Process Monitor that all objects called by BGLs (and textures, effects etc. associated with instructions in MDL files) apparently are "inventoried" by FS during startup.
This is true even if scenery areas are "un-checked" in the FSX Scenery Library UI (and thereby set as "Active=FALSE" in Scenery.Cfg); scenery areas must be deleted (or "Cut and Exported" using SCM2004) to halt this process which contributes to longer FS initial application loadup.
http://library.avsim.net/search.php?SearchTerm=SCM2004&CatID=root&Go=Search
In light of the profound change in FSX behavior that happens on my system in relation to having such a large number of objects all in one scenery "Area" and/or "Layer" of the Scenery.Cfg, I wondered if there is an internal limit in FSX (perhaps related to how much memory is installed/available at runtime) that determines how many GUIDs can be dealt with at a time without function slowing to a crawl or even causing a crash.
NOTE: I do only have 2 GB RAM on that FS development/testing system, but I keep LOD display radius no higher than 1/2 way up, and I use NO AI Traffic or Weather, and have seen this repeatedly even when FSX scenery density slider is set at
minimum !
I am also compelled to wonder if there is not a finite limit as to just how many GUIDs that FSX can deal with
globally in a configuration that has vast numbers of add-on Aircraft, Sceneries etc. ?
BTW: This same "inventorying" is done with Aircraft, and contributes to longer loading of the FSX aircraft picklist unless the infrequently used Aircraft.Cfg files are renamed to no longer have a *.CFG extension.
Aircraft not being used frequently must be "hidden" from FS to halt this process (which otherwise, IIRC, also contributes to longer FS initial application loadup).
[
END_DIGRESSION ]
I'm not very familiar with GMAX or FSDS development, but IIRC, doesn't the GUID of an object get embedded in the MDL when it is created by it's author, and isn't that "internal" GUID always the same (meaning it also cannot be changed by the end-user even when decompiled from a library and re-packaged into another library) ?
Regardless of the FS scenery library of 3D objects to be placed by XML that an object ends up inside, isn't there some unique ID and non-editable GUID in each MDL file that could be read and used by a special utility to compare with other MDL files and identify duplicates ?
That way the end user would be at least informed of which library BGLs the duplicates are in, and could perhaps in some way help mitigate the duplication problem from spreading further throughout the FS community.
Developers publicly distributing placement BGLs with their sceneries could then avoid (or at least minimize) placement of objects that call upon libraries known to have duplicate scenery object GUIDs in them.
It would be great if we could use "GUID Excludes" to "
block" or filter use of duplicate GUIDs in the FSX subsystem, so FS would allow only (1) instance of an original MDL GUID to be loaded/rendered instead of duplicates at runtime depending on what FSX knows to be actively available in Scenery.CFG.
I suppose it might be a challenge to identify which object is the "proper" original, and I don't think that with these duplicate libraries already being out in the FS Community one should attempt to "disable" an
entire library if somehow it were possible to determine that it contained 1 or more known duplicates, as this would likely just add more chaos to the add-on scenery world.
[
EDITED]
Wouldn't it be nice though, to have a utility that identified duplicate GUID objects and then had the ability to allow the user to pick the library BGL file (copy) from which they wanted to disable a particular object or list of objects to unburden FS from having to deal with the duplicates... on just that end-user's system without altering the (original) scenery object library itself (the original being zipped up for safe-keeping). ?
Hope this helps sort out some issues and contributes some beneficial ideas.
GaryGB