Author Topic: Nassau issue from Key West install  (Read 244 times)

Dillon

  • Full Member
  • ***
  • Posts: 156
Nassau issue from Key West install
« on: September 23, 2021, 12:38:07 am »
I'm getting a large 11 sign on the side of Runway 14 with Key West installed.  I tested and it looks like Key West is causing the problem.  I removed everything from my community folder and the problem is only there with Key West installed.  I have the latest version of Key West as downloaded using the Add-on Manager utility.

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 41738
    • VIRTUALI Sagl
Re: Nassau issue from Key West install
« Reply #1 on: September 23, 2021, 10:41:32 am »
Tried it now, and I can't see anything wrong there, see the attached screenshot (KEYW is of course installed). Could you please post a screenshot, so I know where and what you are referring to ?

Dillon

  • Full Member
  • ***
  • Posts: 156
Re: Nassau issue from Key West install
« Reply #2 on: September 26, 2021, 04:18:18 pm »
After further investigation me and others have conflicting results as to what's causing this.  I'll post a screenshot later so you can see what's going on.  If you can't reproduce it on your end then there's nothing you can do.  Thanks for looking.

virtuali

  • Administrator
  • Hero Member
  • *****
  • Posts: 41738
    • VIRTUALI Sagl
Re: Nassau issue from Key West install
« Reply #3 on: September 27, 2021, 02:51:11 pm »
I don't know if there might be more than one cause for this problem but, according to the post on Avsim ( in which you also posted ), the only thing sure it's NOT caused by FSDT KEYW, as confirmed by multiple users who have that problem even with NO FSDT KEYW installed.

Instead, someone hinted in his case it was caused by the AYDY - Sindeni Airstrip freeware found on flightsim.to. So, I downloaded it and yes, I can confirm this scenery WILL surely cause a conflict at MYNN, for several reasons:

- according to its layout.JSON file, it places some of its BGLs at the "root" level of the main Scenery folder in the sim.

While the ones named "aydyscn.bgl" and "aydyshp.bgl" are named specifically enough to not likely to cause a conflict, the one named "objects.bgl" most likely will, because it's very generic and it's the same name used in the SDK sample so, it's very likely another freeware author doing the same mistake of placing things in the main "Scenery" folder of the simulator AND naming the file objects.bgl, would results in these two conflicting with each other.

A proper practice should be placing your files in a SUB-folder of the main "Scenery" folder, a practice this freeware followed ONLY for the "modelLib.bgl" file, likely because this other bad practice of having a file modelLib.bgl file in the ROOT Scenery folder has been frowned upon by everybody, including yours truly, on a Avsim post made A YEAR ago:

https://www.avsim.com/forums/topic/585422-fsdt-releases-key-west/page/3/?tab=comments#comment-4356053

Even in this case, users were mislead assuming "FSDT KEYW has a problem", when it was caused by two freeware BOTH making the same mistake of using the modelib.bgl file in the root "Scenery" of the sim. But it was a year ago, the SDK wasn't very clear about that, so we could cut some slack.

Later, the SDK HAS been updated and, in the same sample, it has ALL the .BGL files placed in a sub-folder named "mycompany". Asobo likely realized their sample mislead too many people assuming they could just place files in the root Scenery folder, resulting in lots of conflict-causing freeware because the explanation of how the Virtual File System in MSFS works wasn't very clear.

So, this freeware developer followed the advice, and placed the modelLib.bgl in a sub-folder named scenery/aydy/modelLib.BGL, but he should have done the same for the others, especially considering he decided to name one of them with a very generic name.

- The other issue is that, by decompiling the objects.bgl file, the one placed in the Scenery global root, it results with the following source code:


<?xml version="1.0" encoding="utf-8"?>

<FSData version="9.0" timestamp="1/1/1601 12:00:00 AM">
  <SceneryObject lat="25.050604082643986" lon="-77.47305750846863" alt="0.0F" altitudeIsAgl="TRUE" snapToGround="FALSE" snapToNormal="FALSE" pitch="0" bank="0" heading="-180" imageComplexity="VERY_SPARSE">
    <LibraryObject name="{8396d176-1549-4772-a6e0-a54e5a0ee216}" scale="1" />
  </SceneryObject>

  <SceneryObject lat="25.05112711340189" lon="-77.4737361073494" alt="0.0F" altitudeIsAgl="TRUE" snapToGround="FALSE" snapToNormal="FALSE" pitch="0" bank="-0.005493164" heading="132.61597" imageComplexity="VERY_SPARSE">
    <LibraryObject name="{b5a61705-97ef-4cc3-a058-4eb7743564cf}" scale="50" />
  </SceneryObject>
</FSData>


There are two issues here, which I have highlighted:

- The 2nd object defined has the SAME GUID as the SAMPLE "Box" from the SDK, which is a Box with a checkered texture, AKA "the Rubik Cube"

- BOTH Objects are placed at...you guessed it...on the left side of Rwy 14 at MYNN. The 2nd one has a scale factor of 50 so, whatever it is, it will likely big. Clearly, something located in Papua New Guinea has no business placing an object at Nassau.

Why some people see the "Rubik Cube" ( which is the object with GUID b5a61705-97ef-4cc3-a058-4eb7743564cf in the SAMPLE from the SDK ) and others see the "Huge 11" ?

Because ANOTHER scenery must have re-used the same GUID from the SDK SAMPLE, and assign it to an "11" sign it needed for ITS scenery. Another common mistake: reusing the GUID from the SDK SAMPLE, which won't be a problem until *another* scenery tries to place it.

Now, the following will be even more interesting because, searching for this GUID in my Community folder ( which only has KEYW and this AYDY scenery doing test ), I could only find it in AYDY so, normally, UNLESS you installed the SDK sample at MYNN, you shouldn't see anything at MYNN, since this GUID is "supposed" to be used only by the MYNN sample and even if you had that installed, you were supposed to see the "Rubik Cube", which is what the sample assigned to that GUID.

So, I searched in the "Official" folder too and, guess what...the b5a61705-97ef-4cc3-a058-4eb7743564cf GUID is defined in this scenery:

Official\OneStore\microsoft-airport-egpr-barra\scenery\microsoft\Barra-Airport\modelLib.BGL

And it's used by this object:

<ModelInfo guid="{b5a61705-97ef-4cc3-a058-4eb7743564cf}" version="1.1" name="EGPR_11 Sign">

And THAT'S the real cause of the problem: the EGPR - Barra Airport, which I guess comes with the UK World Update has used the same GUID as in the SDK Sample to create a custom sign with an "11". This won't always be a problem but, it will result in a BIG "11" sign if something place it, even the SDK sample itself.

So, basically:

- Those having installed both the SDK sample and the AYDY scenery (or another scenery that placed that object at MYNN ) both NOT the UK World Update, would see a "Rubik Cube" at MYNN, because that's what the sample assigned to that guid.

- Those having installed the AYDY scenery (or another scenery that placed that object at MYNN ) AND the UK World Update, would instead see a big "11" sign at MYNN, because the EGPR Barra from the UK World defined that guid to be an "11" sign, and the AYDY scenery PLACED IT at MYNN, because the file OBJECTS.BGL is basically a copy of the same file in the SDK MYNN Sample.

« Last Edit: September 27, 2021, 03:24:02 pm by virtuali »