Scenery Design Engine New Build

[scruffyduck]

I have released a new test build - www.scruffyduck.co.uk/files/sde_test2.zip

This has more complete de-compilation of FS9 and FSX scenery files (those compiled by bglcomp). There is now an XML pane in the test app which shows the XML for the de-compiled object. Changing properties of the object should be reflected in the XML. You can't edit the XML by hand but through the properties. Most parts of the airport record are now available (excluding approaches).

All feedback much appreciated.

 

[jvile]

Thanks Jon

I will work with it but I also need approach code because the airports I update in FSX are ones with new runways missing in FSX and approach code that I have to write for AI behavior.

So far those FSX type AFCAD programs being uploaded to web sites have to many issues and don't work correctly.

 

[lc0277]

Great job, Jon! I'm impatient to see some kind of map view component in your tool

I have a remark concerning the XML output; the library objects XML declaration are not shown in the XML pane when I select one of them. Only the SceneryObject (the parent object) is shown.

Another idea is to force the locale/culture to be US/English. In a French environnement, all numbers are printed with a comma as decimal separator and this is probably not a good idea if the XML is to be recompiled or shared.

Thank you

 

[scruffyduck]

Thanks Guys

I am working on Approach code now so maybe by next weekend (I am trying to produce weekly builds) I will have it working. Also missing is taxiways etc and they are on my 'this week' list also.

Yes the library object code is missing from the scenery object - I just haven't added it in - will be in the next version for sure.

As for culture that is a very good point and something that I had to deal with for LOM. I think the issue for that is likely to be in the user interface rather than the engine since numbers stored internally in DotNET are culture independent. Having said that the XML certainly has to use a point decimal separator. I will make sure that the XML generator forces the decimal separator to a point.

Well a map interface is where I want to get but right now I want the engine to be independent of the interface and I am just beginning to understand how complex a scenery file can be!!!

 

[Javier]

As for culture that is a very good point and something that I had to deal with for LOM. I think the issue for that is likely to be in the user interface rather than the engine since numbers stored internally in DotNET are culture independent. Having said that the XML certainly has to use a point decimal separator. I will make sure that the XML generator forces the decimal separator to a point.

Hi Jon,

If you are using c# you can try ToString(..., NumberFormatInfo.InvariantInfo).
and you will be printing a point as decimal separator even here at Spain where we also use a comma (or maybe you are already doing it and the problem is another one... ).

Well a map interface is where I want to get but right now I want the engine to be independent of the interface and I am just beginning to understand how complex a scenery file can be!!!

I'm eager too to see the map interface (don't worry, just wanted to make a little pushing...

Best Regards,
Javier.

 

[scruffyduck]

Hi Javier

Yes I am using C# but not using that in the code at the moment. I thought to add it into the method that generates lines of XML. I will get that into the next build. Since all XML is generated by the one method it should handle this issue

 

[scruffyduck]

What's in the next Build (Hopefully!)

Well I am getting more stuff de-compiled although it is still not all there especially around the airport with taxiways, aprons and approaches still as work in progress.

What is there now is compiling. It is possible to decompile a file and then make some changes and re-compile it. Because of the design of the Engine it is possible just to compile part - so for example a single airport. So there is now a simple way to make changes and save them using the BGL format itself. For example, decompile a default BGL, extract a single airport and compile it then load that back in so that you are working with that alone.

This week has also involved a lot of tidying up and finding out the things that I had missed or gotten wrong.

Hope to release the next build Sunday night

 

[scruffyduck]

There is now a new build : www.scruffyduck.co.uk/files/sde_test3.zip

This has a number of changes including those mentioned in the post above. There is also a button to delete parts of the scenery file tree. This works and will remove the tree node and anything it contains.

Anything you compile is saved in both XML and BGL form in the work sub-folder of the application. You can obviously play around with the raw XML if you wish The version of bglcomp included is from SP1. Also you can load back in the bgl created and see if the changes you made in properties etc worked OK.

Be aware that the compile will only generate that stuff for which there is valid XML available. There is now some basic information on Approaches but this is not complete (no legs yet). A number of other bits have been sorted out and I would like to thank Winfried Orthman (Osman) for his special and invaluable help to me in understanding the format of FS9/FSX scenery files.

Hopefully there will be more progress next week. I will focus on Approaches as my next key bit of the jigsaw.

All feedback and comments gratefully received

Just a final warning not to use this for anything important!!!!

 

[Javier]

Hi Jon,

It seems I'm the comma-buster

There are still some commas as decimal points (in non english systems) when you export or view xml in Helipad, VOR, Start or Vasi. Maybe others also as I haven't looked in detail.

Not important in this moment, just for your info.

Best Regards,
Javier.

 

[scruffyduck]

Hi Javier

Thanks for letting me know - I changed the xml code generator and maybe I did not include the culture invariant code in all the places.

OK some of the objects are still using an older XML code generation method - I need to change them to the new one - includes the objects you mention.

 

[scott967]

Jon -- the tool is looking good. Couple suggestions:

Altitude. In FS9 this was stored as 1/1000 meters, but you are only providing .1. Can this be changed? In FS9 the JABbgl tool was the only one to give the full accuracy.

Vor_ILS. Can this section be decoded separately from the airport data? There are examples where MS have ILS elements in there which aren't connected to the airport/runway element.

Lat/long Can there be an option to display decimal degrees, like in the XML?

Waypoints/ndbs. There is the concept of "terminal" waypoints and ndbs. Is there some way to determine which are which?

thanks

scott s.
.

 

[Javier]

OK some of the objects are still using an older XML code generation method - I need to change them to the new one - includes the objects you mention.

Hi Jon,

Many thanks. Your program is actually very useful for the moving map I'm trying to finish. Do you have any plans to decode the dem*.bgl files? I haven't been able to find any info about their format and I would like to put some mountains on the map so planning VFR become easier (and less dangerous )

Best Regards,
Javier.

 

[scruffyduck]

Jon -- the tool is looking good. Couple suggestions:

Altitude. In FS9 this was stored as 1/1000 meters, but you are only providing .1. Can this be changed? In FS9 the JABbgl tool was the only one to give the full accuracy.

Yes I am throttling it back. The value in bgl, as you say, is to 1000th meter

Vor_ILS. Can this section be decoded separately from the airport data? There are examples where MS have ILS elements in there which aren't connected to the airport/runway element.

Not sure - Vor/Ils are in a separate section but those related to a runway are moved into the runway section. I tried to compile one using SDE and selection an ILS - the compile failed. Does not seem to make much sense to be able to compile one outside it's runway. You can certainly compile Vors on their own.

Lat/long Can there be an option to display decimal degrees, like in the XML?

the engine keeps data in all the formats - at the moment the test app which displays the properties is using the String format to display the property and the engine defaults to the decimal format for the XML. I have been thinking about allowing users to select units but that is really a GUI issue.

Waypoints/ndbs. There is the concept of "terminal" waypoints and ndbs. Is there some way to determine which are which?

I am sure there is - I just haven't gotten to it yet

 

[scruffyduck]

Hi Jon,

Many thanks. Your program is actually very useful for the moving map I'm trying to finish. Do you have any plans to decode the dem*.bgl files? I haven't been able to find any info about their format and I would like to put some mountains on the map so planning VFR become easier (and less dangerous )

Javier.

I have some information about it thanks to Winfried, but I have not gotten that far into the files yet. My ultimate aim is that the engine can handle any type of scenery file including dem and cvs.

 

[phpdk]

Hi Jon,

Looking forward to the final version. I tried the latest with an APX-file I created for the Faroe Islands on the basis of the default APX46090. There is one airport but I added many helipads as separate airports with ICAO codes assigned. It works in the sim. But I noticed that your tool assigns tower positions to my helipads - all of them at 0* lat/0* lon and at the same altitude as the helipad. When recompiling you get a warning that the tower is very far from the runway!

Decompiling with BglAnalyzeX does not give me these spook towers.

Peter

 

[scruffyduck]

Hi Peter

Thanks for letting me know - I need to look at towers since sometimes they are generated with 0 lat/lon which I think means that they are not there. The SDE XML generator automatically creates a tower in any case at the moment which might explain the problem. I plan to make the tower a separate node so it can be deleted from the object tree if not required.

 

[scott967]

Not sure - Vor/Ils are in a separate section but those related to a runway are moved into the runway section. I tried to compile one using SDE and selection an ILS - the compile failed. Does not seem to make much sense to be able to compile one outside it's runway. You can certainly compile Vors on their own.

I didn't try, but I'm not surprised that bglcomp won't allow this. Somehow MS was able to do this -- they must be using a different compiler. I'm mainly interested in getting it decoded at least. My test case is KSTL in APX23180.bgl.

When you look at this, you see that RWY 12R has a secondary "ILS" of IFXD and named LOC/DME 30L. But if you look in the Vor_ils section of the file, you will find another ILS in addiion to this one, IBKY named ILS 30L. There is an ILS approach for 30L using this ILS and it shows up in the GPS. IFXD is used in an LDA approach to 30L.

scott s.
.

 

[scruffyduck]

Hi Scott - I will take a look at that airport and include it in my test set.

I suppose one could change the xsd to allow separate compilation but I do not think that would be a very good idea

 

[jvile]

Quote:
Waypoints/ndbs. There is the concept of "terminal" waypoints and ndbs. Is there some way to determine which are which?

[/QUOTE]I am sure there is - I just haven't gotten to it yet [/QUOTE]



If the NDB is nested under the airport header it is a TERMINAL_NDB.

if the NDB is outside the Airport header or listed in another bgl it is a navigation NDB.

Lee Swordy listed the NDB in the properties section as a TERMINAL_NDB if his decompiler read it nested under the airport header.

He used a checkmark and what airport it is assigned to in the NDB property screen.

The same applies to certain VOR's that can also be TERMINAL_VOR's but Lee did not list those seperate. All VOR's that were added to a airport in Lee's program were always placed outside the airport header so they were never TERMINAL_VOR's even though some airports do have them.

The issue with KSTL like other airports in the database is the runway property owns the ILS so the user airplane panel will read the Loc/GP. A runway will not compile if it has 2 or more ILS assigned to it. That requires FS9/FSX to list one ILS in the runway properties and one in the Approach data. KSTL situation has both a ILS and a LDA which is also considered a ILS without GP in some cases. Another problem with KSTL is they accidently reversed the LDA with the ILS so if you use as a test bed be careful of the accidental reversal of IDENTS.

MAP mode in FSX for KSTL chooses the LDA with no GP over the ILS with GP so it appears the ILS idents are wrong based on MAP mode.


@ scott

I think we had a dicussion about this somewhere else or am I mistaken.