• 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.

XML code for Geo-Locked Objects?

tgibson

tgibson

Resource contributor
Messages
11,767
Country
us-california
Hi,

Using BGL2XML 1.50 I can find no differences in the XML code between geo-locked BGL files and regular library BGLs available world wide. Am I missing something?

As an example, here is the header and first Scenery Object entry of one of my decompiled library BGL files (available world wide):

Code: 
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Created by Scenery Design Engine (SDE) on 6/3/2016 -->
<FSData
   version="9.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="bglcomp.xsd">
   <ModelData
      name="dfebe03c44177488133cb6bae8370b03"
      sourceFile="dfebe03c44177488133cb6bae8370b03.mdl"
      fileOffset="0"/>

and here is the XML code from the decompiled Orlando.BGL file (from FS9), found in the Scenery/NAME/scenery folder. This file is marked as geo-locked by Instant Scenery and will not let me place objects from this file in (for example) Alaska:

Code: 
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- Created by Scenery Design Engine (SDE) on 6/3/2016 -->
<FSData
   version="9.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="bglcomp.xsd">
   <ModelData
      name="7eaf1c0242da61735195f8abf1d27553"
      sourceFile="7eaf1c0242da61735195f8abf1d27553.mdl"
      fileOffset="0"/>

There is no other code in both of the files except further ModelData sections and the final </FSData> line.

So is BGL2XML not decoding some information?

Thanks,
 
Last edited:
Tom

Lets keep this post open since my post you referenced pertains to FSX.

This picture is a portion of the FS9 Orlando.bgl and the 1st entry is your fantasy tower mdl. My source file says Orlando_00.mdl but it can also be the GUID based on how I read the bgl. There is nothing in the orlando bgl except Model data.

r02.jpg


We now need to go find the placement code for the fantasy tower mdl. It is going to be in 1 of the 4 OB9NAME bgl's. I search each bgl and find the fantasy tower in OB9NAME0.bgl. Since the Scenery Object placement code and the LibraryObject model GUID from the Orlando bgl are combined and compiled into the same bgl this scenery is treated as scoped to the vicinity of Orlando

cr3.jpg


If I want to use it world wide I create a library. The XML will look like this. Notice I do not code it as a LibraryObject but use ModelData for the compiler.

<SceneryObject
lat="N28 9.93795"
lon="W081 48.46119"
alt="0.0000M"
altitudeIsAgl="TRUE"
pitch="0.00"
bank="0.00"
heading="46.05"
imageComplexity="SPARSE">
</SceneryObject>

<ModelData
name="7eaf1c0242da61735195f8abf1d27553"
sourceFile="7eaf1c0242da61735195f8abf1d27553.mdl"
fileOffset="0"/>

The source file MUST BE pathed so the compiler can find it or just place the source file in the same folder the compiler is in.

Now copy the 2 fantasy bmp files from the NAME\Texture folder to the texture folder you are using with your active scenery folder.
 
Last edited:
Hi,

But that's the same code that is used for normal library objects - a ModelData section in one BGL file and a SceneryObject section in a different BGL file, referencing the GUID in the other file's ModelData section. These are available world wide - why is your example above geo-locked? Is it the OB9xxx file name?
 
If you look at my OB9NAME0 picture the LibraryObject Guid is nesting inside the Scenery Object

Example

<Scenery Object
Placement code
and
LibraryObject guid
</SceneryObject>

which in effect is locking it to the placement code.

Separate the LibraryObject and call it ModelData from the sceneryObject per my above example and it will now be world wide
 
Last edited:
Hi again,

My code for a world wide object (created by Instant Scenery, Rwy12, EZ-Scenery, etc.) has the LibraryObject section placed inside the SceneryObject section and this does not geo-lock this object - I can use it anywhere else. Here is an example:

Code: 
   <SceneryObject
      lat="37.8927519544959"
      lon="-121.242592781782"
      alt="0.0M"
      altitudeIsAgl="TRUE"
      pitch="0"
      bank="0"
      heading="118.998413085938"
      imageComplexity="NORMAL">
      <LibraryObject
         name="00fc1632d3d6417f8626f29a1048d971"
         scale="1.00"
         />
   </SceneryObject>
 
Ok, let me keep digging.

Is that name="00fc1632d3d6417f8626f29a1048d971" in another bgl that has all model data like a city bgl has?

If 00fc1632d3d6417f8626f29a1048d971 is a stock object I would like to replicate your findings.
 
I am looking at your code.

Code: 
<SceneryObject
  lat="37.8927519544959"
  lon="-121.242592781782"
  alt="0.0M"
  altitudeIsAgl="TRUE"
  pitch="0"
  bank="0"
  heading="118.998413085938"
  imageComplexity="NORMAL">
  <LibraryObject
  name="00fc1632d3d6417f8626f29a1048d971"
  scale="1.00"
  />
  </SceneryObject>

and that will work anywhere in the world if the Model data was also compiled.

Somewhere in that same bgl should be the following

<ModelData
name="00fc1632d3d6417f8626f29a1048d971"
sourceFile="00fc1632d3d6417f8626f29a1048d971.mdl"
fileOffset="0"/>

The LibraryObject name="00fc1632d3d6417f8626f29a1048d971" has to point to a source file .mdl for the scenery to display. It is normally in the same compiled bgl as the placement code and Library Object.

If the compiler cannot find the source mdl it will give an error and not compile
 
Last edited:
Hi,

No, that is an object I created in GMAX, and placed using Rwy12 or Instant Scenery.

Yes, that object's ModelData section is in a separate file containing nothing but ModelData sections. That is how all of my library objects are handled. I checked inside that BGL placing
00fc1632d3d6417f8626f29a1048d971 and there are no ModelData sections at all.

That's a bad example because the library BGL file is huge. I have chosen a different file set, for the airport KTVL.

Note that this is a file set that allows the objects to be placed world wide. If you need an example of one that is geo-locked, use the Orlando.BGL and OB9NAME0.bgl files found in the FS9/Scenery/NAME/scenery folder, as you have already examined. I can't find a difference.

Included is:

KTVL_1962_library.BGL - the library BGL file
KTVL_1962_library.txt - the Rwy12 text file of the library
KTVL_1962_library.BGL.xml - the XML file decompiled by the latest BGL2XML
KTVL62EZ.BGL - the placement BGL file for most of these objects in the library above
KTVL62EZ.BGL.xml - the decompiled XML file

You can download the relevant files here:

http://www.calclassic.com/Temp/KTVL_Test.BGL.zip

You should be able to place any of the objects in this library world wide, even with the EZ file installed as well. Instant Scenery says I can as well.

Thanks,
 
Tom

My initial findings are the same as yours. If the scenery object model is from the stock Area of FS (ie Orlando.bgl) then it will be locked within a certain vicinity.

In the early development of ADE we found many instances where the compiler MSN gave us in the SDK and the compiler ACES Studio used for compiling scenery were not the same. In the header of many stock bgl's there is a reference to the geographical area covered by the contents of the bgl file. This limits how far a scenery object can be moved and based on MSN is done for scenery optimization purposes.

When MSN compiled certain bgl's they added in the header a geo area which we have no way of doing. When we make a library of scenery objects and compile, regardless of how we place the scenery and the model.mdl those same scenery objects become available world wide as you have pointed out.

The end result is if I want to use a FS9/FSX scenery object that is considered scoped within a vicinity of its placement I have to compile the Placement /Libraryobject with the Model.mdl in the same bgl.

If I create scenery with a 3rd party tool (GMAX) then regardless of how I code it in the XML it is scoped to the entire world since there is no geo restriction in the compiled bgl header.

I am not sure but you could ask Konstantin if his IS utility reads the bgl header and determines if it has a geo reference.
 
Hi,

Thanks for your findings. Don also mentioned a geo area in the header, which none of our decompilers appear to be able to decode. I guess for now we'll just have to use the SceneryObject and ModelData in the same file method to geo-lock objects.

Thanks for your efforts,
 
Detecting and decoding the lat/lon bands (which governs the visibility/availability of geo-locked models) is straightforward. If ADE can make use of the geo-reference data, I'm happy to advise Jon as to its location/format.) Since there are no filesize implications, those bands could be adjusted/reset simply by overwriting the lat/lon band data in the binary file and resaving the file. Or, if not useful inside ADE, I could generate a little standalone utility to do this

As noted by others, there is no way to do this from XML with the available compilers. It can, however, be controlled/adjusted using .asm. In fact, this is how ADE-GP limits the GP data to the vicinity of the airport to which it applies.

Don

EDIT: It took me about two hours to create a utility to handle lat/lon bands. Then, I realized the lat/lon bands only apply to FS8 objects(e.g., GPs). Nonetheless, based on Jim's analysis (i.e., that models defined in the same file as their placement are geo-locked to that area), it should be relatively easy to identify whether objects in a .bgl are so geo-locked and to extract them into a separate file and compile them independently of the placement data, thus unlocking them.
 
Last edited:
That's too bad, since I found those files above in FS9 that do not have placement and definitions in the same file and are geo-locked. So we still don't know what causes these files to be geo-locked in FS...
 
Tom, please send me the library file with the geo-locked object(s) that does not contain any placement data (don at stuff4fs dot com). Perhaps it contains the essential "clue".

Don
 
Hi,

I've sent them. It turns out that the only ModelData sections for the Orlando objects appear to be in the Orlando.bgl file and these are somehow geo-locked, even though the decompiled file contains no placement data. When I decompile the Orlando.bgl file (reported to be geo-locked by Instant Scenery) and then recompile it using BglComp, it is exactly the same size as the original file. And when used in FS9, Instant Scenery reports that the objects in this recompiled file are now available worldwide. Since the files are exactly the same size, it suggests to me that some sort of coding order may be the signal to FS9 to geo-lock these objects, rather than an added header section? And perhaps the decompilers are ignoring this difference and producing only XML code which does not geo-lock objects? Perhaps this is necessary because BGLComp may not accept the code that produces geo-locked objects? All speculation of course.

For all I know there may just be a byte in the file (or for each object) that needs to have a specific value to geo-lock the objects...
 
PS. I examined the original and recompiled files in a hex editor and the headers do appear different, while the code below the header appears identical (at least for the first page of data).

And if I change the header of the recompiled BGL to that of the original BGL file using the hex editor, the objects become geo-locked to the Orlando area in FS9.

So I think we have figured it out that there is indeed a difference in the header information, but that the number of bytes in that header is unchanged (most but not all of them in the recompiled file are 00). I have no idea if any XML code could trigger BGLComp to produce that modified header, though.
 
Last edited:
Winfried reported in his bgl file structure documents that headers had references to the geopraphical area covered by the contents of what was compiled in the stock files.

We still know the compiler the SDK gives us and the compiler MSN used were different in many ways.
 
PPS. The orlando.bgl file in FSX has the same header information for the most part. When I recompile it with the FSX BGLComp the header looks like the recompiled FS9 version (again for the most part). So it appears to be working much the same in FSX as in FS9.
 
You must log in or register to reply here.
Back
Top