• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSXA Need for Jetway extensions

Hi Jim,

I do understand that Geo-Locked really means that the Orlando objects are locked outside of a 60 nm radius of the original location - IS *will* let you place these objects in the Orlando area. That is what I've always thought Geo-Locked meant.

I understand your example in FSX - the OBX28170.BGL file contains both SceneryObject placement code and ModelData sections. This is what I have always thought created geo-locked objects.

I also understand the geo-locking of FS9 objects specified in some OB files - there are both SceneryObject and ModelData sections for those in the same file. These would then be Geo-Locked.

But my question is about a file like Orlando.BGL in the FS9/Scenery/NAME/scenery folder. There appears to be no difference in the XML code as decompiled by BGL2XML (and by BglXML.exe as well) between a BGL file available world wide and the Orlando.BGL file that is locked into a 60 nm radius. The code for an example object in the Orlando.bgl file:

Code:
   <ModelData
      name="060545a54d80527bbd03ffb4e3d0f9ad"
      sourceFile="060545a54d80527bbd03ffb4e3d0f9ad.mdl"
      fileOffset="0"/>

There is no other mention of this GUID in this Orlando.BGL file.

The placement code appears to be in the file OB9NAME0.BGL:

Code:
   <SceneryObject
      lat="28.1642273068428"
      lon="-81.8072211742401"
      alt="0.0M"
      altitudeIsAgl="TRUE"
      pitch="0"
      bank="0"
      heading="136.049194335938"
      imageComplexity="SPARSE">
      <LibraryObject
         name="060545a54d80527bbd03ffb4e3d0f9ad"
         scale="1.00"
         />
   </SceneryObject>

This is the only time this GUID is mentioned in this file, and it is not mentioned in any of the other 4 OB files in the NAME/scenery folder. Instant Scenery cannot find this object in any other OB file available while sitting at KORL (oddly enough that includes 4 OB9NAMC files (6 through 9) and the OB9NAMW1 file!). I can confirm that an object from the OB9NAMW1 file does appear just fine in FS9 at Orlando. I can also report that geo-locked objects in OB9OCEN1.BGL (placed in Hawaii and the South Pacific, I checked) are also available at KSFO but not at KORL (!).

So the Orlando.BGL file contains the ModelData lines but no SceneryObject placement code (as decompiled by BGL2XML), and the OB9NAME0.BGL file contains only SceneryObject placement code and no ModelData lines (again, as decompiled by BGL2XML), yet the Orlando.BGL file appears to be geo-locked. So is the required code either incorrectly missing from the decompiled XMl file or is FS9 using some other method of defining geo-locked objects in this case?

Very interesting...
 
Tom, as I mentioned in an earlier post, geo-locking is accomplished by some data in the .bgl file header and is totally independent of the placement position (except, of course, one would expect the placement to be within the geo-locked area). But, the object is not locked, per se; the whole file is ignored by FS when the user aircraft is outside the lat and lon bands defined in the file header and, hence, the object simply isn't available to FS at that time.

BGL2XML does not report these position bands.

Don
 
Tom

We are cross posting. See what I wrote in your other post since we are dealing with FS9
 
So the Orlando.BGL file contains the ModelData lines but no SceneryObject placement code (as decompiled by BGL2XML), and the OB9NAME0.BGL file contains only SceneryObject placement code and no ModelData lines (again, as decompiled by BGL2XML), yet the Orlando.BGL file appears to be geo-locked. So is the required code either incorrectly missing from the decompiled XMl file or is FS9 using some other method of defining geo-locked objects in this case?

Tom

You are using an old decompiler that is not showing everything
 
I just downloaded the BGL2XML 1.50 file from the ScruffyDuck Download Center earlier today? Is there a later source for this utility? Or are you using a different decompiler?

The text file does mention version 1.3.6, but I downloaded 1.50. And the GUI program reports:

Versions:
Application 01.05.1
Engine 05.09.0
 
Don

Glad you covered the bands

I did not mention the bands in the header of the bgl which is a references to the geographical area covered by the contents of the
file, I used a NM distance to show how large the vicinity can be. For the USA 60NM radius is about the size of the vicinity the object will still appear in.
 
Back
Top