Hi all,I don't have the airports all you guys are referring to but I have seen this kind of problem before at other FS9 airports and have managed to solve most of them, .......well sort of.[snip]Hans

Hans, thanks for that - it fits with my original theory and is much better put. But using my exclude file idea actually solves the problem without deleting any bgl files for add-on airports (and thus not losing any scenery objects within them) which is what made me come up with the second idea as to the cause in this specific instance.Best wishes,John

This has been an interesting thread to follow as I love to solve puzzles.And some great info has been passed along.I decided to look at VIDP myself and think I have stumbled upon something.I think this developer tests his custom objects at KSEA and leaves these test files in his upload.I looked at a few files...2d igi blue.bgl2d igi blue4.bglddome.bglface wall.bg...all contain the 3D model for a single object, and place it at the exact same coordinates. at KSEA. They do not add anything to VIDP.I suspect he has some type of template that he uses to look at his models that places them at the default startup location for FS9.John's exclude seems to be the easiest fix, short of going through each .bgl file in the addon. There may be a/some files in there that add items to both airports, I don't know. I don't intend on spending any more time on this addon, it's headed to the recycle bin for me. This issue, and too many others, for my liking.regards,Joe

Joe and John,If I've understood you correctly, the following:If the VIDP author has left some .bgl files in his VIDP airport scenery folder but which position and even duplicate certain objects in the totally different KSEA scenery, then this would amount to committing a kind of virtual mortal sin !! O.K. the author wouldn't have done this purposely but I must now admit that in my rather long initial reaction concerning the FS9 scenery cache buildup, I didn't take this kind of sin into account.The most logical thing would now be to de-activate any new Exclude statements and all four of your singled out VIDP .bgl files and see what happens, both at KSEA and VIDP. Depending on the results, these .bgls could then be selectively re-activated to observe their effects at both airports. After terminating this action with good results it could become necessary to CUT/paste one or more of these .bgls from the VIDP scenery folder to the KSEA scenery folder where they in fact belong and if any untextured objects appear at KSEA, then their related texture .bmp files should be COPY/pasted ("COPY" = for safety reasons) as well.However, If your named four .bgl files are in fact only "left over test files" within the KSEA scenery folder itself and are not stored in the VIDP scenery folder, then the end solution is easier still. Just de-activate them and see what happens in the KSEA scenery, etc.Whatever you do, make backups to a safe place of both original airports before messing around with any of them as above.Good luck.Hans

Good day all.I too experienced the trees and a very odd looking tower across RW 34R at KSEA. The only change I have made to the default KSEA is to add an afcad file. I recently download the VABB scenery from this website and suddenly found that KSEA had some tree's across RW 34R. I then downloaded VIDP and VOMM and found that I now had the VIDP terminal buildings running across RW 34R as well.I then deleted VABB / VIDP and VOMM from my scenery and thankfully RW 34R is back to normal.All 3 sceneries were designed by the same person. I will be sending a mail to the the creator explaining the scenery clashes.I hope this helps all those who were experiencing the same problems as my self.Regards

Good day all.I too experienced the trees and a very odd looking tower across RW 34R at KSEA. The only change I have made to the default KSEA is to add an afcad file. I recently download the VABB scenery from this website and suddenly found that KSEA had some tree's across RW 34R. I then downloaded VIDP and VOMM and found that I now had the VIDP terminal buildings running across RW 34R as well.I then deleted VABB / VIDP and VOMM from my scenery and thankfully RW 34R is back to normal.All 3 sceneries were designed by the same person. I will be sending a mail to the the creator explaining the scenery clashes.I hope this helps all those who were experiencing the same problems as my self.Regards

Just to say I am already in touch with the author (Ashish) and he has responded that he is going to look into the issues so I am hoping for a solution soon.I must say I wasn't aware VOMM also caused similar problems! I guess my exclude file is doing a grand clean-up! And there is the matter of the two Swedish sceneries (which I don't have) too! Poor old Seattle has had more than its share.John

Hi All,I think we can now all agree that strange scenery objects unexpectedly appearing at previously correctly displayed addon FS9 airports, are caused by duplicate Guids used in MDL library .bgl files. At FS9 startup these duplicates are ignored during the scenery cache buildup process, which causes unpredictable objects to be displayed in unpredictable airport sceneries. It's in fact a structural FS9 bug, the effects of which will only get worse in the future due to more and more MDL library .bgl files (containing Guids) being used by scenery developers, mostly because of their positive frame rate effects.This brings me to a logical request and I admit readily that I may be chasing a pink elephant here, but here goes anyway:Would it be possible for one or more of you technical gurus out there to at least begin thinking about making some kind of a utility tool program which runs through all FS9 addon sceneries, targeting only MDL library .bgl files and which builds up a cache with all found duplicate Guids ? The tool should then (somehow) change only those duplicate Guids with the single object in mind of making them UNIQUE within any FS9 setup, while at the same time, preserving their integrities and dedicated texture displaying functionalities. Maybe you guys can think of other technical solutions but duplicate Guids seem to be the root cause of the "strange objects/textures" being positioned in unexpected FS9 sceneries by their correct and dedicated scenery object placement .bgl files.I'm posting this request because I'm absolutely convinced that it would be impossible to expect scenery developers to take already present Guids into account within many thousands of personal FS9 setups all over the world.Comments are welcome.Hans

I think we can now all agree that strange scenery objects unexpectedly appearing at previously correctly displayed addon FS9 airports, are caused by duplicate Guids used in MDL library .bgl files.

I don't agree with that statement at all. I know for a fact the issue of having many objects displaying at the same spot at KSEA has nothing to do with duplicate GUID numbers, if it did you would see many copies of the same 3D model in the same spot. FS9 will only recognize one instance of a GUID. If several 3D objects have the same GUID, then any time a scenery object placement .bgl calls for any of those objects, FS would only display the one that it recognizes.Say you have a tree, a hangar, and a pink elephant that all have the same GUID. If the pink elephant is the one item that FS9 associates with that GUID, then any time a designer has placed the tree or the hangar at any scenery, anywhere in the world, you will see a pink elephant, not a tree and a hangar and a pink elephant.This is not the case at KSEA. All of those items piled up at the same spot have unique GUID's, they have to. And I know the 4 files I listed earlier all use distinct GUID's because I de-compiled the files to XML and read them.Each GUID is a 32 digit number with each digit being 0-9 or a-f. That gives us a total possible number of available GUID's of 16³². That's a big number. Is it possible to have duplicate GUID's? yesIs it likely? noHas it happened? probably, though I have never seen itYour idea for a utility is valid, though I see a couple issues with it. One being that if you change the GUID for an object, you then have to change the GUID in every scenery placement file that uses that object. How is this utility going to know if the scenery placement file is wanting to use the tree or the pink elephant?The best way to handle the issue is for the developer to re-compile the object library, which in FS9 will give all the objects a new GUID. The developer then has to edit all their scenery placement files using the new GUID's and then distribute the patch files to the public.But this is really a non-issue, or at least a tiny one.The problem with KSEA is poor file management by the developer, or possibly a glitch in some software that he is using.Remember, there is nothing wrong with KSEA. The issue is with these other addons and it manifests itself at KSEA, but the problem is not with KSEA itself.Hope this clears thing up a bit.regards,Joe

I don't agree with that statement at all. I know for a fact the issue of having many objects displaying at the same spot at KSEA has nothing to do with duplicate GUID numbers, if it did you would see many copies of the same 3D model in the same spot. FS9 will only recognize one instance of a GUID. If several 3D objects have the same GUID, then any time a scenery object placement .bgl calls for any of those objects, FS would only display the one that it recognizes.

I agree with you, Joe. Initially I thought it was duplicate GUIDs (yes, I have experienced this, just twice) but behaviour according to the relative position in the Scenery Library of my exclude file brought me round to thinking along your lines. If it had anything to do with GUIDs on objects at KSEA the exclude would also work below the level of the Indian airport sceneries. I tried that and it didn't.John

Hi,He probably uses GMAX for creating his objects (or at least MakeMDL) and it gives you KSEA coordinates by default when it creates the XML placement file. You are supposed to change those to the coordinates you want. Many people just "take a look" at the objects by leaving the coordinates alone and going to KSEA. But then you need to remove that information before releasing your scenery. :)Hope this helps,

Joe,Thanks for your reaction and I now agree with you that the problem at KSEA could be specific to that scenery only, especially in this case because an exclude seems to have been able to correct the problem but I do have some other examples on which I have based my opinions. Here are some of them:At my addon Cairo (Egypt) airport the author had used 40 foot shipping containers stacked on top of one another for creating some of his his airport buildings. The specific container textures were repainted with walls, windows, doors, etc. so as to show them as airport buildings. A rather unique method I agree but so far so good and everything was displayed without any technical problems......although rather "heavy" on my frame rates.However, after installing many other airport sceneries during quite some months, those shipping containers at Cairo had suddenly lost their original textures and were now being displayed as actual green coloured containers with the shipping company's logo (Evergreen) on them. After a lot of trial and error work I eventually found the .bgl file which was causing the problem in the Tegucigalpa airport scenery. It placed a few of these static containers somewhere near it's cargo area. This began a rather extensive testing process and by temporarily changing the priorities in the FS9 scenery library layers, the Cairo problem was solved but now the containers at Tegucigalpa were displayed with Cairo airport building textures. In the end I deleted the offending .bgl in the Tegucigalpa scenery and apart from a few containers disappearing there, the Cairo "buildings" were now being displayed correctly again. This whole issue turned out to be a definite case of duplicate Guids of which the display priority could be influenced by messing around with the FS9 scenery library layers. Based on this it remains my opinion that the only process where such a problem can be initiated is during FS9 startup, where the first Guid found has priority over subsequent duplicates, including their dedicated textures. If these two Guids had been unique the Cairo/Tegucigalpa problem would never have occured.I've also had comparable problems at Hong Kong's Kai Tak and Turkey's Istanbul Ata Turk airports where trees had suddenly become untextured, most probably because the Guids concerned were duplicates. They were therefore ignored and the called for textures connected to the remaining active Guid, could not be found where expected. These problems were solved, not by searching for the responsible .bgl file(s) but by copy/pasting the textures concerned to the folder where they COULD now be found. However, I still regard this method as a "cover up" over the underlying duplicate Guid problem.Approaching the scenery developer for a solution is obviously the road of the least resistance but under the above circumstances, which developer do you approach ? The one who made the scenery where the problem occurs or the "other" one who made the scenery, which unknown to any "normal" simmer, actually causes the problem ? This could especially be an issue when the simmer stumbles onto the problem by chance like I did, at a (far) later date.Concerning the possible utility, I agree with you fully that it would be extremely difficult if not impossible, to automatically make duplicate Guids unique while at the same time keeping them synchronised with their related object placement .bgls. However, a utility which would only list any found duplicate Guids with their original folder and .bgl names, would be a great help for manually undertaking the effort of making them unique, etc. I also agree with you that there should not be too many of them .......yet but only a single one can cause quite some specular problems in totally unexpected places and moments.But I remain thankful for your comments or those from others, because I'm never too old to learn more about our fantastic hobby.Hans

Each GUID is a 32 digit number with each digit being 0-9 or a-f. That gives us a total possible number of available GUID's of 16³². That's a big number. Is it possible to have duplicate GUID's? yesIs it likely? no

Just to add a bit of real-world perspective on the number of unique GUID's......there are more unique GUID's than stars in the visible universe!For another perspective on this, see here: The Quick Guide to GUIDs

Just a follow-up note to say that I have heard from Ashish Singh, the developer of these sceneries, and he is working on a new version of his sceneries to eliminate the faulty objects. He anticipates uploading the new versions in a week or so.I'm not sure if that includes VOMM as when I first wrote I wasn't aware that also caused problems. Then there is the matter of two Swedish sceneries (which I don't have) that do the same - perhaps somebody else would like to follow these up?It is caused by EZ Scenery - apparently if the co-ordinates are unassigned they will default to that exact spot at Seattle. I was about to say that when in the past I developed simple sceneries using that software I never had that problem but perhaps I should check KSEA before I open my cakehole and put my foot in it!Best wishes,John

I have done some research and it is possible to eliminate these objects without abandoning add-on sceneries of VABB Mumbai and VIDP Delhi which both place unwanted objects at KSEA.If you create an exclude file for "library objects" with the following co-ordinates:N47* 25.9844'N47* 26.0818'W122* 18.5169'W122* 18.3386'and place it in the Scenery Library at a level higher (i.e. loading afterwards) than VABB and VIDP then the unwanted objects will not be seen.Note also that another discussion identifies similar problems with ESNS and ESPA add-ons too ( http://forums1.avsim...howtopic=291516 ) but I'm not in a position to check whether this fix will solve that issue as I don't have them installed.John

Amen for forums, they are a treasure. Just found that large purple LED at the end of the runway with those awful trees! Now to get rid of them!!!!![edit] I have VABB installed. Going to check now. [edit]Daniel