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

SDE Build 2598

scruffyduck

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,951
Country
unitedkingdom
Available from here

www.scruffyduck.co.uk/files/sde_current_build.zip

SDE Build 2598 includes fixes for apron light decoding which was handled wrongly and the ability to read all the airport in an FS setup (either FS9 or FSX) and then decode an individual airport selected from the airport list. Both default and add on airports are identified as in AFCAD2. Incoming FS XML is now validated against the FSX bglcomp.xsd and compiler problems caused by bad decoding of regions have been fixed.
 
Hi Jon,

One thing I have noticed when opening an XML file it does not show the runway designator. If the XML is compiled and the resulting bgl is loaded then it show the designator.

David
CanUK Scenery
 

Attachments

  • FromXML.jpg
    FromXML.jpg
    30.9 KB · Views: 612
  • FromBGL.jpg
    FromBGL.jpg
    32 KB · Views: 612
Thanks David, It is the way the name is constructed when loading the XML and that is different than when loading a BGL file. I will make it consistent in the next build.
 
Are you ready to dig back into your code and revisit some issues?

Lets talk taxiway signs. I know you don't want to hear that but it is taking to decompilers to get one good set of signs.

Used Build 2591. Build 2598 was not available yet when I did all this work.

I am going to recheck with the new 2598 all of the following issues.


My question is, do you source the First taxiway sign in the list (rightside window) of the decompiled bgl to XML the same way for each airport?

We know that at most airports there is at least one sign that all the rest can reference from. Every airport that I am working with has been very easy to find that reference sign using SDE. It is the very first one in the list on the rightside window pain.

When I find that sign on the airport and make a small exclude around that single sign then all the signs are excluded. Thats the good news if you do every airports first sign on a decompile the same way.



Now on to another issue pertaining to signs.

It would take too many pictures so I am asking that you use SDE and decompile 0302/26200. Go down and open KSAV.

The very first sign is the reference sign in the right side window of SDE so I exclude (XML rectangle) to remove all signs

<TaxiwaySign
lat="32.127745"
lon="-81.194956"
heading="50"
label="l[C2]d`C\"
size="SIZE3"
justification="RIGHT"/>

BUT!!!, you decompile so well that you also (with SDE) find unique things that MS has left behind. Inside that sign is another sign (like a small suitcase in a large suitcase) that is smaller in size (SIZE2) so it is not visible on the airport taxiways but SDE finds it.

Down toward the bottom of the sign list is this sign

<TaxiwaySign
lat="32.127745"
lon="-81.194956"
heading="5"
label="d&lt;E&gt;"
size="SIZE2"
justification="RIGHT"/>

Identical LAT/LON but smaller sign (SIZE2) and the XML will not compile once decompiled because the compiler thinks this is in error as per the following

Invalid format for Taxiway Sign label: d<E>

The compiler is not seeing the l (location letter) in front of the so it does not understand the &lt; or &gt; and ends up with an error using the carrot symbols. The problem is not with SDE but I think MS with their tool embedded the unseen sign by accident (unless it is the true reference sign embedded). That also shows they may not use the same tools we have to use for compiling.

If you put the l (location) in front of the and then do a search in the XML list there is a sign with the correct label code and with a different LAT/LON (see next example).

<TaxiwaySign
lat="32.128365"
lon="-81.195736"
heading="89"
label="ld&lt;E&gt;"
size="SIZE3"
justification="RIGHT"/>


The end result is 2 signs with the same LAT/LON (one inside the other like suitcases) but smaller in size. Then we also have that same SIZE2 (visually unseen) sign and a SIZE3 with what should have the same sign information on it but one is missing the l (location) so the XML won't compile.

Now this may be unique to this airport so I will move on to the next problem.

The above was easy to fix because I just took the SIZE2 and deleted because a SIZE3 exsist and is used in its place.

Now that I have the reference sign excluded and no signs are visible at the airport I am going to copy all of the signs from SDE into MY FSX XML so I can pick and choose which signs I need to move or change the Label letter/numbering.

Sounds simple enough except the LAT/LON decimal values of all the decompiled signs are all out of place. If you look close at the decompiled sign decimal LAT/LON they group all the signs toward one end of the airport. Many signs have the same Lat or Lon causing them to group together.

This is not a problem as long as the reference sign is used for the sourcing code to place the rest of the signs but I excluded the reference and added all signs back into my XML.

The fix I had to use for this is to decompile the signs with Winfrieds decompiler and copy his format into my XML. He used a different LAT/LON decimal format even though the signs in his utility are listed the same way in SDE. That placed all the signs back to their correct position so now I have full control to move/change/delete multiple or single signs as needed.

For some reason BGLanalyzex does not group the signs towards one end of the airport but places them as per the LAT/LON back where they should be.

I can't help out with what you do on your end, only what I can do on this end. Its easy to see that in some cases SDE is so powerful that it uncovers records that should not even be there in the first place.

I am assuming on this end that SDE is placing all the signs correctly based on the first reference sign. The LAT/LON of each sign is then disregarded at that point until we need that LAT/LON value for something else.

If there are unclear areas in my post we may need to discuss deeper in depth. This could be another one of those localizer threads. Been at this all night so time for some rest here on my end (early morning)
 
jvile said:
Are you ready to dig back into your code and revisit some issues?
Click to expand...

sure :)

Lets talk taxiway signs. I know you don't want to hear that but it is taking to decompilers to get one good set of signs.
Click to expand...

No that is fine I know that taxisigns are wrong

Used Build 2591. Build 2598 was not available yet when I did all this work.

I am going to recheck with the new 2598 all of the following issues.
Click to expand...


No need 2598 does not address any issues on Taxi signs.

My question is, do you source the First taxiway sign in the list (rightside window) of the decompiled bgl to XML the same way for each airport?

We know that at most airports there is at least one sign that all the rest can reference from. Every airport that I am working with has been very easy to find that reference sign using SDE. It is the very first one in the list on the rightside window pain.

When I find that sign on the airport and make a small exclude around that single sign then all the signs are excluded. Thats the good news if you do every airports first sign on a decompile the same way.
Click to expand...

Yes. The first sign in a taxi sign record always has zero offset to the reference point and I guess that makes it the reference sign




Now on to another issue pertaining to signs.

It would take too many pictures so I am asking that you use SDE and decompile 0302/26200. Go down and open KSAV.

The very first sign is the reference sign in the right side window of SDE so I exclude (XML rectangle) to remove all signs

<TaxiwaySign
lat="32.127745"
lon="-81.194956"
heading="50"
label="l[C2]d`C\"
size="SIZE3"
justification="RIGHT"/>

BUT!!!, you decompile so well that you also (with SDE) find unique things that MS has left behind. Inside that sign is another sign (like a small suitcase in a large suitcase) that is smaller in size (SIZE2) so it is not visible on the airport taxiways but SDE finds it.Down toward the bottom of the sign list is this sign

<TaxiwaySign
lat="32.127745"
lon="-81.194956"
heading="5"
label="d&lt;E&gt;"
size="SIZE2"
justification="RIGHT"/>

Identical LAT/LON but smaller sign (SIZE2) and the XML will not compile once decompiled because the compiler thinks this is in error as per the following

Invalid format for Taxiway Sign label: d<E>

The compiler is not seeing the l (location letter) in front of the so it does not understand the &lt; or &gt; and ends up with an error using the carrot symbols. The problem is not with SDE but I think MS with their tool embedded the unseen sign by accident (unless it is the true reference sign embedded). That also shows they may not use the same tools we have to use for compiling.

If you put the l (location) in front of the and then do a search in the XML list there is a sign with the correct label code and with a different LAT/LON (see next example).

<TaxiwaySign
lat="32.128365"
lon="-81.195736"
heading="89"
label="ld&lt;E&gt;"
size="SIZE3"
justification="RIGHT"/>


The end result is 2 signs with the same LAT/LON (one inside the other like suitcases) but smaller in size. Then we also have that same SIZE2 (visually unseen) sign and a SIZE3 with what should have the same sign information on it but one is missing the l (location) so the XML won't compile.

Now this may be unique to this airport so I will move on to the next problem.
Click to expand...


This might actually be some sort of error in the SDE de-compiler.

Sounds simple enough except the LAT/LON decimal values of all the decompiled signs are all out of place. If you look close at the decompiled sign decimal LAT/LON they group all the signs toward one end of the airport. Many signs have the same Lat or Lon causing them to group together.

This is not a problem as long as the reference sign is used for the sourcing code to place the rest of the signs but I excluded the reference and added all signs back into my XML.

The fix I had to use for this is to decompile the signs with Winfrieds decompiler and copy his format into my XML. He used a different LAT/LON decimal format even though the signs in his utility are listed the same way in SDE. That placed all the signs back to their correct position so now I have full control to move/change/delete multiple or single signs as needed.

For some reason BGLanalyzex does not group the signs towards one end of the airport but places them as per the LAT/LON back where they should be.
Click to expand...

I think I need to go back and look at the code which calculates the sign co-ordinates based on the given offsets. If that is not calculating correctly (and I suspect it isn't) then that would put the signs in the wrong place

I am assuming on this end that SDE is placing all the signs correctly based on the first reference sign. The LAT/LON of each sign is then disregarded at that point until we need that LAT/LON value for something else.
Click to expand...

May not be a good assumption at the moment :)

If there are unclear areas in my post we may need to discuss deeper in depth. This could be another one of those localizer threads. Been at this all night so time for some rest here on my end (early morning)
Click to expand...

No you are confirming what I suspected. I hope you have a good night's sleep. When you have a moment I would appreciate your looking at the apron lights issue again - I hope I have fiexed that now in 2598.
 
OK I know that the method I used to calculate co-ordinates of a sign based on the reference point and offsets is wrong. I am using another method which seems to be more accurate but I am getting errors in the 5th decimal place on the co-ords when I re-compile the decoded airport.

If anyone has a formula for calculating the terminal co-ordinates based on latitude and longitude offsets then I would appreciate some information. I have three methods!! All giving different answers :confused:
 
Working with 2598 now on the other issues.

Wished I had a answer for the coords but don't have a clue.

Maybe in that one set of records the best way to decompile is with the following format


lat="N32 7.75359"
lon="W081 13.10554"
 
Hi Jim

I am now using code that I used for oobject placement in Scenery Maker. This is accurate down to a inch or so. I am doing some more test but in the meantime the new code stands and signs stay where they should be (at least close enough). I have a couple of other ideas that I might test but in the end I think we are dealing with the well-known creep issue of using a compile-decompile-compile chain rather than using a master XML file :)
 
Just found a problem reading ILS and placing them on runways. This is in an AFCAD file. I checked it in AFCAD and it compiles fine. It won't compile in SDE because it will not allow an ILS outside the airport record. It also looks like the Ident of the ILS is not the same as the one given in the airport record and this is stopping it being put insige the airport record. Also this would not compile since it has a glideslope. The interlocks in SDE won't allow this to be fixed in program at the moment so I am working on a way around it


EDIT

OK I have found a way around and corrected the problems. As mentioned above the Primary and secondary ILSIdent values given in the runway record did not match either of the ILS Idents, I have no idea why. Recompiling with SDE corrects this and the ILS are attached to the runway,
 
Last edited:
Jon, are you planning a graphical interface for SDE similar to Lee's Afcad program? What I'm asking is are you planning graphical reprensentation of the data in program?
 
Phantoms said:
Jon, are you planning a graphical interface for SDE similar to Lee's Afcad program? What I'm asking is are you planning graphical reprensentation of the data in program?
Click to expand...

Yes :) Also I plan to make the engine available to other developers who might want to use it in their own application
 
Getting out of memory error in SDE on certain dir's

Try 0302/25160 and see if it happens to you. Occurs with both the lastest versions.


I tried BGLAnaylzex and received 4 unknowns for KDTW. That was the airport I was trying to get at to begin with in SDE.

<Airport ident="KDTW"
region=""
country="United States"
state="Michigan"
city="Detroit"
name="Detroit Metro Wayne Co"
lat="N42 12.74583"
lon="W083 21.20350"
alt="196.90M"
trafficScalar="0.70"
airportTestRadius="4000M"
magvar="6.30">

<Tower
lat="N42 13.29775"
lon="W083 20.93802"
alt="0.00M">
<SceneryObject
lat="N42 13.32396"
lon="W083 20.72218"
alt="0.0000M"
altitudeIsAgl="TRUE"
pitch="0.00"
bank="0.00"
heading="0.20"
imageComplexity="VERY_DENSE">
<LibraryObject
name="{37A4EA40-AE2C-4B8A-98A8-9A1B00B7FFDB}"
scale="1.00"/>
</SceneryObject>
</Tower>
<!-- unknown type of subrecord in airport, Id = 66, Offset = BD1B0, size = 4C -->
<!-- unknown type of subrecord in airport, Id = 66, Offset = BD1FC, size = 4C -->
<!-- unknown type of subrecord in airport, Id = 66, Offset = BD248, size = 4C -->
<!-- unknown type of subrecord in airport, Id = 66, Offset = BD294, size = 4C -->
<Runway number="4" designator="LEFT"
lat="N42 12.85267"
lon="W083 22.50859"


This could be a rotating beacon on top the Control Tower.

There is also a problem with 0302/2621 and appears to be a ILS issue but I am still checking that to see if it is SDE or another issue with the FSX Airport records.

I sure hope SP1 is working toward fixing all the Airport records that are incorrect.

I am finding many Localizers throughout North America (ie Canada, Mexico) that did not get centered to the runway and are not offset Localizers or LDA's. Some I have fixed and uploaded to AVSIM but it appears that the round world kept the runway LAT/LON the same but when the airport scenery moved a small amount it took the Localizers with it.
 
OK I can confirm that I am getting the same out of memory problem. From the initial error message seems to implicate something in a runway record. I need to dig in and see what is happening.


It is in a runway. There is a trash record in a runway somewhere. I don't think it is KDTW. BglAnalyzeX also reports an unexpected element in a runway record and presumably passes over it. SDE isn't getting the chance to ignore it. I want to see what it is, and where if I can before I put code in to stop this problem. Basically the recordType ID is gibberish and the length of the record is massive and that causes the problem.
 
Last edited:
OK the problem is with KDET Runway 07 and 80 bytes into a 124 byte record there is a typeID of 17421 with a length of 1106499338 and that is causing the exception. I am going to fix the bug in the program now but it seems that this runway has nothing but markings and lights - at least that is the problem occurs after they are decoded.

I have fixed SDE to bypass this particular error but clearly there is something related to that runway which is giving trouble. I suspect it might be some type or overrun or other runway extension but I can't lnow. Maybe we can check the airport and find out what should be there
 
Last edited:
In the picture you can see the taxiway was not locked to runway 7.

All I did was grab the taxiway with the mouse and pulled it away from the runway. FS cannot have a taxiway that is disconnected on both ends to keep ATC from using the runway. Only one end must be disconnected or the Taxiway to Runway paths can be corrupt.

SDE may not like either one or two ends disconnected and a lot of taxiways in FS are designed with one end disconnected to keep ATC from using it. Visually the disconnect is not seen because the break in the blue nodes are very close together. AFCAD reports this break as a error.

FSX now has a better way of closing a taxiway but they did not use it. That is to connect both ends to a runway and then code the taxiway with a VEHICLE statement. Vehicle is for Ground support taxiway routes and ATC does not send airplanes onto a Vehicle coded taxiway. I have closed some taxiways with this method and SDE accepts it and so does FSX.
 
Last edited:
Hmmm as far as I know there is no code in a runway record which relates to taxiways.
 
I took KDET a part and it appears that RW07 was not closed after the displaced threshold with

</Runway>

possibly causing the Runway records to be corrupt.

I also found in the Taxiway points a no_draw

<TaxiwayPoint index="75"
type="HOLD_SHORT_NO_DRAW"
orientation="FORWARD"
lat="N42 24.45309"
lon="W083 0.13920"/>

That will not compile and I have never seen a type="HOLD_SHORT_NO_DRAW"
before.

I had to remove _NO_DRAW so the compiler would match index 75 to 90


FSX did connect the taxiway to rwy07 which FS9 did not attach as per my picture

Another stab in the dark to see if this could be the problem.
 
Last edited:
I have confirmed that the

</Runway>

missing after RWY 07 is the problem.

Once I added it and put the displaced thresholds plus the PAPI4 that also was missing back into the runway records SDE opened the new compiled APX25160 bgl with no problem

EDIT

Of course that don't solve the problem with the MS default APX.bgl and my new APX25160 cannot be distributed. It will allow you to get SDE to open airport records that have these missing pieces of element tags but I wonder out of thousands of APX files how many have problems.
 
Last edited:
What is interesting is that the Scenery Engine in FSX must be ignoring those problems unless it is still related to our incomplete understanding of the format and some things that are in the BGL file are acceptable which we think are wrong. There are still a bunch of data which we do not understand.
 
Last edited:
Over the years I have often written code in XML just to find that when the dll processes the bgl in run mode things are either ignored or changed from my original data.

It appears that the dll's have the final say on how the XML/bgl is translated and run in the sim.

I have had to learn that certain data in the approach code once processed by the dll makes changes so I alter the writting of my XML on the frontend side knowing (based on experience) that the dll is making a change.

In this way I am somewhat forcing the dll to expect what I have written rather then change it when processed. The end result is that my XML compiled bgl is more compliant with what the dll wants see to begin with.

Most of this is in the area of Translating the XML code in order to duplicate the approach chart Waypoints/Fixes that draw the lines on the face of the GPS receiver.

The objective is to take the approach chart and make it look exactly the same way in the GPS receiver. In that way the User Plane can "lock" on to the chart showing in the GPS receiver and the autopilot will actually fly the approach chart with ATC instructions.
 
You must log in or register to reply here.
Back
Top