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

Ordering of Elements in the Scenery Tree

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,857
Country
unitedkingdom
Well at the moment you can't drag and drop and I do not think it is practicable - the chaos possible in moving elements all over the place doesn't bear thinking about.

I am currently working on setting SDE up to allow direct tweaking of the BGL raw data file. As part of that SDE now has a raw data display which returns information about the offset of an element from the start of the BGL file and the length of the record. To facilitate looking for errors I am moving the order of display in complex objects like airports to be in the sequence of the file.

This may be a valid order and it may affect the compiler - I need to test that.

When it is done I will post the order. In the meantime please let me know what order works best from the designers perspective

Thanks
 
Messages
8,893
Jon

Keep in mind that this is my personal order and is based on what normally is worked on within a decompiled default bgl making it easier to scroll and find certain data more quickly.

I have another list besides this one if I am writting a XML from scratch. It does not change this list order but adds additional element tags nested properly so FS loads data at runtime correctly.

The following is Facility Data (only) List for a FSX default bgl that must nest inside the Airport Record

<Airport Header
<Services
<DeleteAirport ("TRUE" "FALSE" list)
<Tower
<Runway
i.e. all runway data as shown in SDE down to and including
<Ils end
<GlideSlope
<DME
<Start type
"RUNWAY"
"WATER"
"HELIPAD"
<Helipad <-- denotes the default visual ground markings and not a Object. LAT/LON should agree with the Starttype so they overlay
<RunwayAlias (optional if listed)
<RunwayStart (optional if listed)
<Com
<TaxiwayPoint
<TaxiwayParking
<TaxiName <--- SDK says should be listed last out of these 4 Taxi's but works here
<TaxiwayPath
<Aprons
<ApronEdgeLights
<BlastFence
<BoundaryFence
<Jetway
<TaxiwaySign
<Approach
<Waypoint
<Ndb (TERMINAL_NDB) only

Note

The approach data record is normally the largest record. It does not have to be close to the runway info. Only the first line in the approach record references the type approach for the runway. All legtypes and Transistions are from the approach plates and not from the Runway Record listed at the top.

The Airport Record can only contain Tower, Services, Com, Runway, RunwayAlias, Aprons, ApronEdgeLights, TaxiwaySign, Waypoint, Approach, Ndb, Helipad, Start, Jetway, BlastFence, BoundaryFence, DeleteAirport data.

The SDK is not very clear in this area in the way it is written when you get down toward the bottom part of the document. It leads you into thinking that VOR's, Markers, Geopols, Routes, etc. are nested inside the Airport record and they are not.

I don't see a problem in the way you list all the Library objects last. It would be hard to nest them inside the associated ICAO code.

I am emailing you a bgl with the master xml for my next post. This will allow SDE to see how a single bgl is used to incorporate an entire XML build from start to finish.

Decompiling multiple airports in a single default bgl is one thing but when decompiling a single airport bgl that is hand written must also be a consideration which you have already come across with AFCAD issues.


EDIT

After reading this I need to explain some additional information.

The ILS record that nest with the Runway is owned by the Runway and only serves one purpose. The purpose is so the User Planes radio can receive the ILS freq. and lock onto the Localizer (GS/DME if listed). Many think that by adding a ILS to a runway (using AFCAD) also causes ATC to recognize the ILS and this is not so. ATC sees the runway as a Visual runway and closes it if weather falls below minimums.

The only way to get ATC to understand a ILS exsits is to write a XML companion ILS Approach in the Approach data record using <Approach type="ILS" for that runway number. The ILS which is owned by the Runway only extends into the surrounding scenery by about 28NM and this is hard coded. When the Approach data owns the ILS companion record then ATC uses the invisible scenery of a airport which in most cases is a 108NM radius from the ARP.

This is one of the reasons the runway ILS is broken by AFCAD if a user/scenery designer renumbers a runway that has associated instrument Approach data. ATC no longer understands the ILS when it is no longer tied to the runway number that has been changed. Of course on the surface the User Plane stills sees the ILS on the CDI and thinks everything is ok.
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,857
Country
unitedkingdom
Thanks Jim I will look at that -actually it would be possible to allow users to set their own display order (which does not have to be the same order as needed to compile correctly) I will think about a practical way to do this - it should not be that difficult in the engine, designing a user friendly interface to allow the settings is another thing entirely :)
 
Messages
8,893
Setting the display order would be the ultimate way of doing it if possible.

Maybe in the settings window where we tick the boxes of what to display or just hand edit your settings xml into a list order.

Any one working with SDE should have some knowledge on how to edit a xml. FS requires people to edit the SDK xml settings for certain menus to show up in the Sim.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,857
Country
unitedkingdom
I'll have a look at it Jim. I think we could set one order for display items and another for compile order. The compile order would be fixed to ensure the most compliant way for BglComp and the display order would be for working with the tree. I would think an order for the top level objects and an order for the Airport record.

Thinking about it that could be done using and XML file linked to a treeview with drag and drop. That would be all outside the Engine of course - that would just want the XML file. So to get going that could be edited by hand.
 
Messages
8,893
This is my list of a hand written XML

After the compiler header is always the Excludes. This tells FSX to exclude anything first then place the scenery objects both Generic and Library Object Guid/model.mdl's next. There is a pecking order inside the XML that must be followed which you have already seen some of that with taxiways, Blastpads, ILS data, etc.

In that way you do not have to use a alpha/number file name (seperate exclude bgl's) in order for FSX to exclude something then allow a reinsert of something else.

Many scenery designers make multiple exclude files with just one exclude rectangle per bgl. What a waste of space and time. Even if I made a seperate exclude bgl, all the excludes can be in that one file rather then having a single exclude per bgl.

There is one FSX exclude issue that may be by design or a mistake.

If you exclude a Library Object you cannot place a Library Object Guid back into that exclude box. It will not show up!!! You can put anything else into the rectangle box but not a Library Object Guid.

There are many complaints on other web sites that Users are saying the Utility shipped with FSX SDK does not work correctly. In most cases this is what the designer is trying to do and it is not the Utility but what was excluded first.

If you look at the SAV xml I sent you I excluded at the top the Main Terminal Building which is a Library Object. At first I made the exclude rectangle to large when I moved the Terminal NORTH and WEST. When I added the animated Library Object JETWAY for Gate 9 it would not show up because its reference LAT/ LON was inside the exclude rectangle.

I went back and made the exclude rectangle 1/4 inch in size (see the decimal values of the exclude) so I had more room to play with for the LAT/LON of the JETWAY and then it showed up.

I also excluded only the reference Taxiway sign which unlocked all the signs from the Bias. I then copied all signs back into the XML which are now treated as stand alone scenery items and allows me to edit, change Lat/lon, labels, etc.

I then excluded all the antennas and associated checkerboard shacks that are part of the visuals for the ILS runways. I moved them to their proper LAT/LON and reset the imageComplexity= to a low slider value. For some reason FS has these visuals at a very high setting which has no effect on FPS.


The list then looks like this

<FSData compiler header
<ExclusionRectangle (many as needed)
<SceneryObject (both <Generic and <LibraryObject)
< Modeldata (if needed for type scenery design)
<Effects
<Triggers (for weather and fuel)
<Windsocks
<Attached Objects (such as beacons if visual Tower is placed above the Airport Record)
<Time Zone
<ExtrusionBridge
<VOR (plus DME and Visual model)
<NDB (non_TERMINAL because it nest outside the Airport Record +DME and Visual Model)
<Markers

and now the list for

<Airport Header (and all required data as listed in above post)

and then after the closing element which is <Airport/>

<Boundary (and all associated types, Arc's Lines, circles, etc.)
<Waypoint ( these are non_TERMINAL and used primary for Routes but also in Approach Records listed above)
<Route (both previous and next)
<Geopol (type and associated data)

and then the closing statement of

<FSData />
 
Last edited:
Messages
490
Country
brazil
Order in the ordering...

Hi Jon and Jim,

Since the beggining of SDE developing, I ever downloaded its more recent version and tried using.

To myself, the ordering of ICAO codes, the same as the bgl presented, was somehow difficult to search visually for a certain ICAO code. I don't know, but it seems that in the original bgl, those codes are ordered firstly by longitude and secondly by latitude (or viceversa). But, one could allways search for a word in the text file.

In my opinion, besides this kind of ordering, there's no other to worry about in SDE tree. Perhaps, one textbox to search for words helped better than ordering things.

Best regards,

Jose
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,857
Country
unitedkingdom
Thanks Guys

Jose I will add a box to allow the searching of the tree for a word. The next build will have objects sorted alphabetically in any case so it should be easier to find an airport by it's ICAO.
 

rhumbaflappy

Administrator
Staff member
Resource contributor
Messages
5,948
Country
us-wisconsin
Hi all.

I may be wrong, but I believe if you have the exact Lat-Long of an object, you can use that pair for both the minimum and maximum of an exclude. This was true for FS9. The only question would be if SDE obtains that exact number set on decompilation ( I think it does ). That almost eliminates another object using the exact same reference point... a very good reason to use a decompiler!

Dick
 
Messages
490
Country
brazil
Exclude area

Hi, Jon

I´m changing some parameters of an default airport (SBCB) where there is one beacon that I shall delete.

With an exclude program (designed for FS9, but it doesn´t make difference) I draw a retangle around the object location. I try to get the exclusion of that beacon with the minimum retangle dimensions I could, but it didn´t work until I tried with a bigger one. It seems that FSim´s exclusion works within an area and not with the object´s coordinates.

So, I think a point isn´t enough, except if you could create a square exclusion, whose center would be that point (the same way the Fuel Repair trigger works).

Best regards,

José
 
Last edited:
Messages
8,893
I may be wrong, but I believe if you have the exact Lat-Long of an object, you can use that pair for both the minimum and maximum of an exclude. This was true for FS9.

You cannot use a pair for the LAT/LON in the exclude rectangle. This is true for both FS9 and FSX. The BGLComp compiler for both versions always produce errors if the LAT or LON in the rectangle are identical numbers.

The following is the exact reference point of a default Object Libarary extracted from a OBX bgl

<SceneryObject
lat="N32 8.10835"
lon="W081 12.38567"
alt="0.0000M"
altitudeIsAgl="TRUE"
pitch="0.00"
bank="0.00"
heading="0.00"
imageComplexity="NORMAL">
<LibraryObject
name="{46FC74B0-4731-4914-BDBB-EA96028F7D4F}"
scale="1.00"/>
</SceneryObject>

If you use that pair of LAT/LON in an exclude rectangle the first error is

INTERNAL COMPILER ERROR: #C2343: LatitudeMinimum MUST be less than LatitudeMaximum!
INTERNAL COMPILER ERROR: #C2031: Failed element parse <ExclusionRectangle>
INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:

If you lower the LatitudeMinimum (by one digit) from N32 8.10835 to N32 8.10834 then the BGLComp compiler will erorr the LON value

INTERNAL COMPILER ERROR: #C2344: LongitudeMinimum MUST be less than LongitudeMaximum!
INTERNAL COMPILER ERROR: #C2031: Failed element parse <ExclusionRectangle>
INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:

All 4 LAT/LON in the exclude rectangle must be a different number as long as it is a rectangle. A single pair of numbers cannot produce a bounding box rectangle around the reference point.

This is the same for both FS9 and FSX

You only need to box (rectangle) the reference point of what is being excluded and not the entire visual model.

I would be interested in how you made a exclude with XML in FS9 by only using a pair of numbers so I could further my studies in FSX.
 
Messages
8,893
Jose

The reference point does not always agree with the very center of the Object being excluded.

If you don't know where the LAT/LON of the Object is located then it is trial and error or build a large rectangle which might encompass the reference Lat/Lon.

Sometimes I decompile the associated scenery bgl of the airport and find the exact reference point of what I need to exclude if it is a Library Object. other type scenery like Generic buildings are normally about center position. There are utilities that do this but I found that the AFCAD program is as easy as any other utility.

The crosshair using AFCAD can be positioned on the exact Reference point once you read the scenery bgl and then using the crosshair you can keep the rectangle to a very very small value.
 

rhumbaflappy

Administrator
Staff member
Resource contributor
Messages
5,948
Country
us-wisconsin
I may have used a hex editor to test the repeated single pair of lat-long.... and now that I think on it, I did make a small utility to make a "box" for XML. It spit out a pair of lat-long in XML format, much as you coded by hand, when given a single lat-long.

Jon--

An addition such as that would be good for SDE if we cannot use the same lat-long pair for XML input.

Dick
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,857
Country
unitedkingdom
Hi Dick

Sounds like a good idea. I am going to change the tree display for an Exclusion Rectangle to allow for two vertices to be specified. I'll look at adding some kind of offset function from a single point at well
 
Top