ADE and <SceneryObject>

[Mace]

Jon, et al: You can save me some experimenting, by answering this question:

If I have an xml file with <SceneryObject> data and <ModelData> info in it, will ADE erase these entries when I save in ADE? Or will it keep them intact?

 

[dcmiller58]

Mace,

Except for the tower object which you can add to the tower view in the dialogue box I believe any scenery objects will be removed if you open in ADE and compile.

I have had to create a separate scenery file for my scenery objects, including a tower because I attached a beacon to it.

edit: Jon might likely be along in a moment to correct or clarify this understanding.

Derrick

 

[scruffyduck]

It depends on the circumstances. I am doing some work on this at the moment and it seems that if you load an Xml File into ADE that contains scenery objects those objects are persisted in the file and would thus be passed to the compiler. This would also be true for a Bgl file containing this type of object. You can't display or edit them at this time though

ModelData should not get passed through.

As Derrick says - you can't create or place scenery Objects with ADE at this time

 

[dcmiller58]

Would this mean that, for example, a fuel trigger would get passed through and compiled?

Derrick

 

[GHD]

ADE passes the AFX dummy scenery object through to the compiler which causes an error.

George

 

[scruffyduck]

ADE passes the AFX dummy scenery object through to the compiler which causes an error.

George

Yes - the only sensible answer I can see at the moment is to strip any scenery objects coming in to ADE.

 

[Mace]

Yes - the only sensible answer I can see at the moment is to strip any scenery objects coming in to ADE.

This is what I will do then. Thank you.

Actually I must split into 3 files:
1) MPBO_apx_rb.bgl all ADE stuff
2) MPBbx1_rb.bgl all whisplacer stuff
3) MPBbx2_rb.bgl all of my custom gmax objects

Whisplacer does the same thing. It will STRIP OUT any custom <ModelData> you have. At least the version I have will.

Good thread, thanks for the info.

 

[jvile]

Mace

You can combine ADE and Whisplacer once all is finished.

Just place all models and sceneryLibrary above or below <Airport.

Scenery and exclusions are NOT Airport Header sensitive and belong to the world database in theory same as non_Terminal NAVAIDS .

Once combined you can open with ADE and still see all the airport just don't save as a .ade yet until we get further down the road with Pro Version.

My EHAM, VHHX and others that I build have everything the SDK FSX that is compliant allows in the ADE airport bgl.

The downside is if someone wants to open your airport and make changes. But there is a work around to that if they have SDE. Make a XML with SDE. Extract out the Whisplacer, Compile the XML and make changes. Use SDE to reopen bgl/make XML then add back and run the XML across the compiler.

Some are doing that with my the multi airport EHAM package without having to have my 7 master XML's. (6 airports, 1 GUID)

I give them fair warning to be careful because a airport bgl can be very complex and can be designed to follow the rules of a default APXnnnnn.bgl the way MS entended a airport enhancement to be.

The more files made, the less efficient in reading the files on startup. The read on startup should be in the bgl (same with your cvx's you showed me) and not multiple bgl's to keep performance high. MS has one short sentence on this in the SDK's when designing with all those multiple files that actually belong together as one.

Can we all say ADE Pro Version for the advance designer.

 

[Lupo]

files vs performance

Jim

I'm very close now to posting KMSP and the discussion on the number of files in an airport release caught my eye. I currently have four files: a cvx file for the new flatten and edits to the background (land class and such), a facilities file which is in the style of AFCAD. My additional scenery is in a separate file and finally, I have the approach data in its own file.

To further organize I kept any approach related scenery (localizer antennas and shacks) in the ILS file and the more general scenery in the "scenery" file.

I could get this down to the cvx file and one afx_bgl. I've been wondering what the best configuration to be on this and wonder if there really is a noticeable difference as far as performance goes between two vs. four files for this.

Thanks for any input on this.

EDIT: OK, I did some experimenting and after about ten minutes of up time I see no difference between the separate files and when I combine the additional scenery file and approach data into the main facilities file.

John

 

[Mace]

You can combine ADE and Whisplacer once all is finished.

I have thought about this. You bring up an interesting point.

The downside is if someone wants to open your airport and make changes.

And there is the problem. How can you trust that a user will know to save and cut out certain sections BEFORE saving in ADE/FSXPlanner,etc.?

Chances are, they might destroy the functioning/visuals of the airport.

That's the whole modus operandi behind me splitting out the files like that. Actually when you did it for KMIA that's where it first caught my eye.

I can either:
1) release one xml bgl and recommend users not mess with it, or
2) split out the objects as a separate bgl, possibly approaches separate too

I think all of this will be moot with ADE Pro. Yet even then we will still have the problem of users modding our airports with ADE Home Field. Or design tools that don't follow the rules.

 

[Mace]

EDIT: OK, I did some experimenting and after about ten minutes of up time I see no difference between the separate files and when I combine the additional scenery file and approach data into the main facilities file.

John

Were you testing load times? Or were you testing sim performance?

 

[jvile]

Lupo

No you won't see any difference with a single airport. When you get deeper into many multiple bgl scenery's that could be combine or a User starts building a storehouse full of 3rd party enhanced airports like we would do at PAI then FS can start to slow down.

My thought is we should do our part as best as possible for the User that loads our files. If I made 2000 airports and they all had 30-50 different bgls per airport that starts to take a toll and yet some designers don't combine. How many times do we see 10 bgl's that have a single exclude in each. I wonder how many designers actually know that excludes are owned by the World Scenery database and not the airport they have been nested in or with.

So I could have

5 Exclude bgl's
6 CVX bgl's thanks to Mace I don't anymore so I need to fix KATL like EHAM
1 Approach bgl (need another Airport Header)
1 Taxiway sign bgl and how many times do we see that (need another airport header)
8 different scenery bgls that seperate model objects from generic or GUID's
1 AFD bgl with a mandatory Airport Header
1 APXnnnn.bgl with a mandatory Airport Header
etc

How many Airport Headers do we see out there for one set of scenery files and then ask, why does this simple airport I load cause a CTD a 100 miles away from it. To lower the risk in FS9 the Scenery\Generic\scenery folder plays a big part in helping with mutilple airport header bgl's. At least that way FS is in control of sorting the data and not a designer or user. To my knowledge Reggie and I (maybe a few more) used the Generic\scenery folder the way FS entended. It is one of the most powerful active folders in FS and the yet least known about.

Then the User runs some kind of a utility that says, "we will find duplicate AFCAD's for you" and sure enough it finds all those duplicate headers that are needed based on bad techniques and those bgls get deleted. Now designers are getting e-mails from users saying your airport don't work.

My EHAM package could have very easily been 55 bgl's the User would have to copy into a Addon scenery folder then activate it at the library (Scenery.cfg)

Instead, the EHAM download is only 2 files which one has to be all the shp2vec new airport boundary's and a single bgl with multiple everything you can throw at it with 6 enhanced airports nesting. That also included a total rewrite of all the STAR arrivals/Transitions into EHAM and Crosswinded the runways with weight restrictions added by unlocking the default overlays.

We need to study standards now as the Pro Version goes into beta so we do combine as much as possible as per the SDK's. There is a reason MS wants all the enhanced airport Elements nesting both above and within the <Airport Header and read on startup is just one example.

You could throw my KMSP FS9 approach data into the ADE bgl and it won't get flushed out by the ADE Home Version. FS9 and FSX does not know the difference between FS9 written approach Elements vs FSX element/attribute structure. The only difference there is did you compile with BGLComp FS9 or FSX.

However, check to see if FSX added any of the TERMINAL_WAYPOINTS I had to use in FS9 3 years ago. Don't need to confuse the GPS receiver line draw engine with Duplicate NAVAIDS.

Jon is moving his ADE Utility into a direction never seen before. The possibilities have been there in FS9 but when the AFCAD utility Beta came to a stop no one picked up where it left off or at least not until Jon went to work on ADE Home/Pro.

I am just trying to put some pieces in place and give some food for thought as we move toward the next Generation of multiple utilities in a single designed GUI for airport enhancement.

 

[jvile]

Yet even then we will still have the problem of users modding our airports with ADE Home Field.

Mace

I think we already thought of that if I check my notes. We had the same thought as you so lets for example say if ADE Pro designed the airport then ADE Pro must edit the airport and not ADE Home Edition.

I don't know if we ever defined any objectives and goals in a post here to what ADE Home Version is for other then release a beta Version to the public and say try this.

 

[Lupo]

Jim

Yes, I guess every bit helps as far as multiple headers go so I plan to release just two files for KMSP. As far as the NAVAIDS go I had to do some changes there as one that was used for the missed approach on rwy 35 was not present in FSX. I also added a few to update some of the RNAV approaches to current fixes.

Something I've noticed when decompiling with SDE is that it seems to add turnDirection="L" to elements and in the missed approach section that will upon recompile put in an extra turn which is drawn in the GPS as an extra circle. I have been compiling from xml straight to the current BGLComp so as to not introduce this erroneous code.

John

 

[jvile]

Something I've noticed when decompiling with SDE is that it seems to add turnDirection="L" to elements and in the missed approach section that will upon recompile put in an extra turn which is drawn in the GPS as an extra circle.

I saw the extra circle but assumed it was added at the front side of MS approach coding. There were many in FS9 that I did fix but those could have been caused by the other decompilers also. I did not think to look at a before and after line draw when working with all the decompilers available.

I am going to work on that right now to identify where the problem is nesting.

I will give Jon what I find to go with a few other similar issues reported in SDE Client TestApp by other Team Members.


Thank you for the find

 

[Lupo]

Jim

No problem -- glad to help. This tool-set that Jon has been working on has been a great help!