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

Next Sde Build.............

Jon

Pulling the non_terminal NDB and VOR's into SDE outside the Airport record could be an enhancement down the road. It has its advantages because some NDB's and VOR's that are not Terminal are still used for approach data including certain type outer markers without NDB's. These are listed in other bgl's

I think we discussed that earlier using the other method which is based on a radius distance from the ARP of the Airport when reading the other Navaid bgl's.

Did I say that right?
 
Hi Jim

I agree and have plans to do that. A scanner would search all bgl records as for Airports, looking for NVX records in the default folders and non terminal navaids in the addon scenery folder. A suitable algorithm would then search based on the ARP of an airport.
 
That was it the scanner feature.

I failed to mention the WAYPOINTS. As you know any waypoint in the Airport record is a TERMINAL_WAYPOINT that is assigned to that airport. The GPS receiver show these as a blue triangle.

If you look through approach data you will also see WAYPOINT (not VOR or NDB) which is used but is also listed as part of a route record. The GPS receiver show these as a pink triangle and they are also in some cases part of the Approach code in both the Transitions and IAF of a runway.

Some NAVAIDS in FS9/FSX are a little buggy at times when nested outside a Airport record in other bgl's. Waypoints associated with Routes seem to work fine because they are nested together but when pulled into the approach data of a Airport record they tend not to work.

FS9/FSX has a work around where they plant a TERMINAL_WAYPOINT in the airport record and set the LAT/LON the same as the WAYPOINT, VOR or NDB.

Zooming in real close (GPS Receiver) to a NDB used as a outer marker or VOR as a Navaid for approach records will reveal a TERMINAL_WAYPOINT (small blue triangle overlayed) used for the Approach code.

If a new WAYPOINT is written and placed into the compiled <FSdata bgl which must set outside the <Airport Record then FS9/FSX does not honor it in most cases when writting new approach code. It appears that FS9/FSX only reads those type waypoints correctly from the other bgl's and you would have to edit a default MS bgl to get approach data to work.

If I have to add a new VOR or NDB to my bgl I always associate a TERMINAL_WAYPOINT to the same LAT/LON and use it in the approach data. When the lines are drawn for a LOAD and ACTIVATE GPS Receiver approach, it appears the VOR or NDB is connecting the lines but it is actually the TERMINAL_WAYPOINTS overlaying those NAVAIDS, Somewhat of an elusion which FS9/FSX is good at.
 
Hi Jim

Thanks for the explanation. There is more to this FS stuff every time I look :)
 
Decode FSX MDLs

Hi, Jon

SDE can decode an OBXxxxx.bgl file and save its XML code. But in many OBXxxxx.bgl there are objects with coded MDLs which SDE doesn't extract, by now. I can say this because I tested with other decompiler.

Are you planning to do this in a future SDE build?

I think it's interesting to access those objects in order to create a user's library, so one can see those objects and decide if it's interesting to put them in his sceneries, manually or using OPT.

Best regards,

José
 
Last edited:
Jose

You are correct. SDE does not expose the mdl data although it does have it. I am of the opinion that we should not be decompiling other peoples' libraries and recompiling the objects into new libraries and that is the main reason why SDE behaves the way it does. It would, of course be very easy to change that and I guess I am being hypocrical in that I have a tool which can open up any scenery bgl file and allow users to see inside it and change it :o :o
 
\

Hi, Jon

scruffyduck said:
Jose

You are correct. SDE does not expose the mdl data although it does have it. I am of the opinion that we should not be decompiling other peoples' libraries and recompiling the objects into new libraries and that is the main reason why SDE behaves the way it does. It would, of course be very easy to change that and I guess I am being hypocrical in that I have a tool which can open up any scenery bgl file and allow users to see inside it and change it :o :o
Click to expand...

Of course, I should respect your opinion, but I think this is not the general point of view. As you know, any decompiler open the code from another people, once that code is not opened by the author. Perhaps there are protected objects in FSX. They are not showed even in OPT. I'm not refering to those.
To the others, in my opinion:

First, once the file could be decompiled, the user should be the jugde of his action;

Second, others respectful and traditional decompilers do that since a long time ago, and there is no bad judgement on that;

Thirdly, People buy the game, not its right. That's correct. But we are making scenery just to play, not doing a business.

I beg your perdon to ask you to review your point of view, since your tool is becoming a very useful one and people don't want to use other decompiler only to create a library.

Best regards,

José
 
Last edited:
For FS9 mdls but not yet for FSX you can use my LOV tool to display the objects in a library in 3D (using DirectX). These can be turned and scaled so you can see what they will look like in the Sim. I will make an FSX version when I get the time :)
 
I only can say thank yo

Hi, Jon

I very thankful for your attention.

scruffyduck said:
Guys
So I think to make the mdl data accessible in SDE.
Click to expand...

I needed to gather all my courage to put that question under you. But I hoped you would understand, as you did.

Again, my deepest respect for you.

Best regards,

José
 
No problem Jose. I need to look at how SDE handles mdl objects. They are handled differently than others as I do read out some of the data in the mdl file itself. I have that data held in the objects. It could be put out into the XML when in SDE format. Give me a little while to think how to handle it.
 
I'm gonna jump into this discussion but first I want to thank you scruffyduck for the great tool SDE really is!
However I found that the program does not like to read the xml created just moments before by the same program. Some deep details: I read a APX file and saved an airport to xml. Than I opended the same xml I just saved and an error comes up. (Se attached file)

Another problem when compiling is that it does not like the boundaryFence vertex. Se below.

Is there a workaround this or will it be "fixed" (if possible)?

Best regards,
Mikael


INTERNAL COMPILER ERROR: #C2031: Failed element parse <BoundaryFence>
INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:

ERROR: <FSData
ERROR: version = 9.0
ERROR: >
ERROR: <Airport
ERROR: country = Sweden
ERROR: city = Borlange
ERROR: name = Borlange AB
ERROR: lat = 60.4222223907709
ERROR: lon = 15.5149997770786
ERROR: alt = 153.31M
ERROR: magvar = -3
ERROR: trafficScalar = 0.7
ERROR: airportTestRadius = 5000.0M
ERROR: ident = ESSD
ERROR: >
ERROR: <BoundaryFence
ERROR: profile = {5acb60e6-992b-41c7-929b-e31d5343cd29}
ERROR: >
ERROR:
INTERNAL COMPILER ERROR: #C2031: Failed element parse <Vertex>
INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:

ERROR: <FSData
ERROR: version = 9.0
ERROR: >
ERROR: <Airport
ERROR: country = Sweden
ERROR: city = Borlange
ERROR: name = Borlange AB
ERROR: lat = 60.4222223907709
ERROR: lon = 15.5149997770786
ERROR: alt = 153.31M
ERROR: magvar = -3
ERROR: trafficScalar = 0.7
ERROR: airportTestRadius = 5000.0M
ERROR: ident = ESSD
ERROR: >
ERROR: <BoundaryFence
ERROR: profile = {5acb60e6-992b-41c7-929b-e31d5343cd29}
ERROR: >
ERROR: <Vertex
ERROR: lat = 60.409391708672
ERROR: lon = 15.5399179458618
ERROR: >
ERROR:
INTERNAL COMPILER ERROR: #C2031: Failed element parse <Vertex>
INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:
INTERNAL COMPILER ERROR: #C2607: Compilation errors detected, compilation failed!


Parse complete!
 

Attachments

  • error.JPG
    error.JPG
    88.9 KB · Views: 534
OK let me look at it - I assume the problem is with ESSD? Or is it a different Bgl File,
 
Last edited:
OK here is what I did.

Imported APX52100.bgl which contains ESSD.

Selected ESSD from the Tree and clicked Compile > FSX. This compiles fine.

I then selected File > Save XML and saved it to ESSD - Borlange AB.xml in the work folder.

I then opened this XML file in SDE and compiled it again. I got no errors.

Finally I loaded ESSD- Borlange AB.Bgl into SDE from the work folder and compiled it again. I got no errors.

Can you confirm what you did to raise the errors please?
 
scruffyduck said:
OK here is what I did.

Imported APX52100.bgl which contains ESSD.

Selected ESSD from the Tree and clicked Compile > FSX. This compiles fine.

I then selected File > Save XML and saved it to ESSD - Borlange AB.xml in the work folder.

I then opened this XML file in SDE and compiled it again. I got no errors.

Finally I loaded ESSD- Borlange AB.Bgl into SDE from the work folder and compiled it again. I got no errors.

Can you confirm what you did to raise the errors please?
Click to expand...

I did exactly what you have done.
1) Imported APX .bgl file
2) Selected ESSD from the Tree and clicked Compile>FSK (did NOT edit anything).
3) Saved as xml and then opened it again, and the problem was a fact.

Maybe I have to redownload the program again and test if this problem still haunts me.

The other problem (BoundareyFence) is also ESSD and compiled with SDE, which gave me the long error message.

Maybe the fault is on my computer, and not the program itself?
Odd that you don't get the Fence problem..
 
I am using a later build than the last released one last one released is 2604 for a stable build and 2613. 2613 is an interim build which may have unexpected problems) so that may have something to do with it. Can you confirm which build you are using?

Could you also send me the xml created when you decoded ESSD?

SDE is a very complex program and is still undergoing many internal changes - it may be that you have found one that is fixed but I would like to be certain :)
 
scruffyduck said:
I am using a later build than the last released one last one released is 2604 for a stable build and 2613. 2613 is an interim build which may have unexpected problems) so that may have something to do with it. Can you confirm which build you are using?

Could you also send me the xml created when you decoded ESSD?

SDE is a very complex program and is still undergoing many internal changes - it may be that you have found one that is fixed but I would like to be certain :)
Click to expand...

I am using Build 2604. I attach the xml working file that SDE generated from the APX bgl.

Thanks for helping me!
 

Attachments

OK I am getting a bunch of compiler errors with that xml code in the latest build here so I guess that 2604 has a bug. You could try 2613 which is in a post here as an interim build. If that does not handle the problem then I should make a build available in the next few days that contains the fixes and upgrades that mean things are working here.
 
scruffyduck said:
OK I am getting a bunch of compiler errors with that xml code in the latest build here so I guess that 2604 has a bug. You could try 2613 which is in a post here as an interim build. If that does not handle the problem then I should make a build available in the next few days that contains the fixes and upgrades that mean things are working here.
Click to expand...

I can't find the link in this topic, could you please post a link again? :)
Thank you for all help!
 
You must log in or register to reply here.
Back
Top