Strange problem with markers...

[Gypsy Baron]

First off, here's my version info:

Versions:
Application 01.02.2898
Engine 03.02.2898
CommonLib 01.04.2729

Here is what is happening. I load an airport that
contains "marker" records, either fron an XML file
or a BGL file, do an edit then compile.

I can compile the file the first time and save
it under a new name.

I then reload that new BGL file and attempt to
compile it again, whether edited or not, and the
compilation fails. Note that this is the very same file
that ADE created.
Here's the error data:

ScruffyDuck Scenery Design Engine Compiling
Using FSX BglComp....


Parsing document: K:\FSX Tools\Airport Design Editor\Bgl\KADW_ADE_PDS_yy.xml

INTERNAL COMPILER ERROR: #C2362: Marker keyword MUST have all the following: TYPE, LAT, LON, ALT, and HEADING!
INTERNAL COMPILER ERROR: #C2031: Failed element parse <Marker>
INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:

ERROR: <FSData
ERROR: version = 9.0
ERROR: >
ERROR: <Marker
ERROR: lat = 38.7888002023101
ERROR: lon = -76.8705470860004
ERROR: alt = 280.0F
ERROR: type = MIDDLE
ERROR: >
ERROR:
INTERNAL COMPILER ERROR: #C2362: Marker keyword MUST have all the following: TYPE, LAT, LON, ALT, and HEADING!
INTERNAL COMPILER ERROR: #C2031: Failed element parse <Marker>
INTERNAL COMPILER ERROR: #C2032: XML Parse Error! Element tree follows:

ERROR: <FSData
ERROR: version = 9.0
ERROR: >
ERROR: <Marker
ERROR: lat = 38.7944777682424
ERROR: lon = -76.8705748021603
ERROR: alt = 280.0F
ERROR: type = INNER
ERROR: >
ERROR:
INTERNAL COMPILER ERROR: #C2607: Compilation errors detected, compilation failed!

Parse complete!

I've checked the marker data in the input XML file
created by FSX Planner and compared it to the
marker data in the FSX stock airport and the
entries are identical.

Here is the marker data produced by the first, successful
compilation:

<Marker
lat="38.79447776824236"
lon="-76.87057480216026"
alt="85.344M"
type="INNER"
heading="0.0"/>
<Marker
lat="38.83272774517536"
lon="-76.87071964144707"
alt="85.344M"
type="MIDDLE"
heading="178.59375"/>
<Marker
lat="38.8264138251543"
lon="-76.87072232365608"
alt="85.344M"
type="INNER"
heading="178.59375"/>
<Marker
lat="38.78880020231008"
lon="-76.87054708600044"
alt="85.344M"
type="MIDDLE"
heading="0.0"/>

Here is the marker data of the original XML input file:

<Marker
lat="38.83272774517536"
lon="-76.87071964144707"
alt="85.344M"
type="MIDDLE"
heading="178.59375"/>
<Marker
lat="38.79447776824236"
lon="-76.87057480216026"
alt="85.344M"
type="INNER"
heading="358.59375"/>
<Marker
lat="38.78880020231008"
lon="-76.87054708600044"
alt="85.344M"
type="MIDDLE"
heading="358.59375"/>
<Marker
lat="38.8264138251543"
lon="-76.87072232365608"
alt="85.344M"
type="INNER"
heading="178.59375"/>

It would appear there is a conflict with the schema
somewhere along the line.
FSX Planner will compile or re-compile the airport
that was created from the original XML file AND the
BGL file created by ADE after the first successful compilation.

After that, I'm in a catch 22 situation.
I can't re-compile the airport in ADE when I read
it back in and I can only save it in "ADE format", thus I can't edit the file in XML format
to attempt to "fix" the marker entries.

I've gor a saved heavily edited version of
this airport ( KADW ) but I can't compile it
nor can I eliminate the marker records.
In the Navaids list, the "Delete" doesn't.

OK....just did a bunch of tests. The culprit
APPEARS to be the entries of:

heading="0.0"/>

If I load the first ADE output BGL into FSX Planner, save a XML,
and then compile it again ADE will load it but will
not compile without the error. That is with either the
BGL or XML as input.
If I cut & paste the original marker heading
data into the two "0.0" entries, ADE will
compile the file without error.

Bottom line is that ADE is introducing a condition
in the BGL output that it can't handle as an
input condition.

Hope all this makes sense and is helpful.

Paul

 

[jvile]

Here is what is happening. I load an airport that
contains "marker" records, either fron an XML file
or a BGL file, do an edit then compile.

Paul

I will try to explain this in just a few words.

No utility works correctly other then ADE when it comes to any type landing or navigational NAVAID for FSX.

FSX stock Markers, Waypoints, Non_Terminal NDB's VOR's DO NOT belong in any Airport Facility Data xml (other then new ones created) but yet in order for some current designed Utilities out there they must copy these from the NVX bgl and place them on the GRID. Why? Because those same utilities no not understand how FS9/FSX reads and layers Navaids on a loadup of invisible scenery.

What this does in some cases is duplicates the NAVAID with one on top the other but you can't see it. You now have the stock Marker etc from the NVX bgl on the grid and the one that is nesting in your XML.

Only one Utility in the past read all Stock NAVAIDS correctly by scanning the proper bgl's files in the current bgls's and the associated surrounding bgl's that placed airports on the cusp of a boundary and that was AFCAD2.

ADE is in essence working the same way as Lee designed AFCAD2 and all our NAVAIDS on the GRID are there becaused we scanned a radius from the ARP and did not copy them into the XML. There are some things Lee did in AFCAD2 that no Utility yet has the ability to do including ADE in the area of NAVAIDS.

You can add a new MARKER, NDB, VOR, ILS using ADE but we don't copy in any exsisting NAVAIDS other then the allowed which are the ILS, GS, DME, TERMINAL_NDB's amd TERMINAL_WAYPOINTS as we move to the future.

If you load a bgl or XML into ADE that was first saved with another program then you will get compiler errors in these areas of stock NAVAIDS that are non-compliant to how FSX works and what the SDK says.

This is probably what you don't want to hear but no Current Utility available comes close to AFCAD2 except ADE. If you start a airport with ADE you must stay with ADE. If you start a airport from any other type non-compliant SDK Utility that does not understand how FS9/FSX works and reads in Navaids, exclusions, library objects, Waypoints, NDB's, Markers, etc. you must stay with that Utility.

Our inspiration and design of ADE comes from Lee's Swordy's AFCAD2 program and no one regardless of what they sell you or give you complies properly with AFCAD2 or the SDK.

We could have gone down the path like Lee did that if a non-compliant SDK code gets placed in AFCAD Lee flushed it out on a compile. We use the BGLCompiler unlike other Utilities available and do not flush out these improperly nesting Navids but cannot assure you that if they exsist the BGLComp compiler can deal with them.

We built ADE from the ground up using the APX bgl allowed elements and attributes and did not give the program tricks to display certain things on the GRID. In time we can also add many more compliant Utilities and Data into our airport as per the standard schemes of SDK's because we work with the proper FSX fundamentals in the Home Verson.

I do not want to sound bias here but without these basic fundamentals there could not be a Pro Edition Version in our future. Each Utility available has strenghts and weaknesses so we decided to apply the correct compliant standards that the core FSX program is coded for.

I am purposely being a little vague in this area so I may not give you a concrete answer (Jon may have a better answer) but in due time you will start to see things come from ADE that no other Utility can match unless they use some sort of trickery that is being applied today within those same Utilities.

We did give ADE the ability to load in a XML or a bgl from other Utilities but that is not saying you have the ability to work with that format airport and compile it with the BGLComp compiler based on what the Utility is nesting both inside and outside the airport element tags.

The PRO Version may have the ability to read, write and repair these non-compliant attributes nesting in both the airport data tages and the FSData tags but we will cross that bridge when we get to it.

Bottom line is that ADE is introducing a condition
in the BGL output that it can't handle as an
input condition.

That is because the input condition was not suppose to be there to begin with

In summary

If you start a project with FSXP then stay with that utility.
If you start a project with AFX then stay with that Utility.
If you start a project with ADE then stay with that Utility.

 

[scruffyduck]

Paul

Can I just confirm that the markers you refer to are stock markers and they have come from another utility as Jim describes? He is correct that you cannot edit, move or delete stock markers and ADE does not allow that or bring them into the actual XML from a stock file. However if you load them from another bgl file or xml then it will treat them as user defined and that will cetainly cause duplication of markers at the very least. You should not need to do anything with stock markers as they are going to come from the stock bgl files whatever you do.

I have not seen any problems with user defined markers when created by ADE itself. However you do raise a point that needs investigating. If ADE is treating these as user defined markers then it should not cause a compiler failure with them. Would it be possible to see either the xml or bgl file so that I can check it out here? you can email it to me at jon @ scruffyduck.co.uk leaving ou the spaces of course
I can then confirm if ADE is introducing the problem you describe and if so deal with it.

 

[scruffyduck]

Paul

I have done some checking. The schema information in bglcomp.xsd is not clear on whether heading is arequired attribute or not. Generally required attributes has 'required' associated with them and this does not. ADE is therefore treating a heading of 0.0 as not necessary and not generating that attribute in the XML. I will change this as soon as possible. The option available is to change the heading in the XML you have so that it is off 0.0. That should work I think

 

[Gypsy Baron]

Paul

I have done some checking. The schema information in bglcomp.xsd is not clear on whether heading is arequired attribute or not. Generally required attributes has 'required' associated with them and this does not. ADE is therefore treating a heading of 0.0 as not necessary and not generating that attribute in the XML. I will change this as soon as possible. The option available is to change the heading in the XML you have so that it is off 0.0. That should work I think

Yes, I did confirm that pasting in a heading
of other than 0.0 did compile without errors.
There is, however, no way to change that 0.0
heading from within ADE, thus the airport that
I originally compiled with ADE, read back in
from the BGL, modified, and attempted re-compile.
It's sitting there in the saved file folder as
and ".ade" but attempts to change to marker heading
don't "take".

Do you still need the xml\bgl that I was working with?

Paul

 

[scruffyduck]

Hi Paul

No need. I think we have the solution tagged

 

[Gypsy Baron]

Paul

I will try to explain this in just a few words.
-SNIP_
You can add a new MARKER, NDB, VOR, ILS using ADE but we don't copy in any exsisting NAVAIDS other then the allowed which are the ILS, GS, DME, TERMINAL_NDB's amd TERMINAL_WAYPOINTS as we move to the future.

If you load a bgl or XML into ADE that was first saved with another program then you will get compiler errors in these areas of stock NAVAIDS that are non-compliant to how FSX works and what the SDK says.
-SNIP-
In summary

If you start a project with FSXP then stay with that utility.
If you start a project with AFX then stay with that Utility.
If you start a project with ADE then stay with that Utility.

Thanks Jim.

So, if I understand this, for FSX airports I do NOT need
to include any stock Navaids when modifying an
airport ( mainly parking, vehicle routes, etc ).

What I have observed is that several of the FS9
AFCADS that came with AI packages thatn I used
for a starting point may have had markers, etc,
included.
Also, I often found that the ILS and approach
data didn't show after doing a mod. Thus I developed
a procedure whereby I loaded the stock airport first
in FSX Planner and saved the xml. I then loaded the AFCAD
and saved the xml. From there I did a cut & paste
of things like the boundry fences ( I have found it to be
really, REALlY tedious to attempt to add them with
either FSX Planner or ADE ), approach data and
the navaid and comms.
Essentially what I was attempting to accomplish was
to use all of the stock airport and add the parking
from the AFCAD. The only way to merge this is
through an xml cut & paste effort.

I think I understand some of the pitfalls a bit
better now. Thanks for the explanation.

Paul

 

[jvile]

So, if I understand this, for FSX airports I do NOT need to include any stock Navaids when modifying an
airport ( mainly parking, vehicle routes, etc ).

Paul

You are hitting the nail on the head now


FS9/FSX does not need any type marker, waypoint, NDB or VOR in the copied up XML. It is smart enough on a load to read Navaids at the root bgl's and combine those behind the scence to your modified airport.

There is no reason to even show them on the GRID. Jon I discussed this months ago but decided to show a symbol for markers and other navaid symbols because AFCAD did show but uses a scanner for display because they are not there in the compiled bgl.

The 2 schools of thought is if a scanner is not used then some utilities add them to the XML so they show on the GRID.

To see this technique mostly in AFX they call a Navaid "USER MODIFIED" if you mouse over it. You can delete some of the NDB's on the AFX GRID 3 times before you are down to the stock. That is telling you how many NDB's have been duplicated in your copied up XML.

We do copy and display the ILS/GS/DME symbol for a runway because user will want to edit these that FS allows. FS does not allow a Localizer to be removed. So even if we did not show the ILS, FS still adds it in the mix of reading and combinning Navaids to the copied up XML to bgl.

What I have observed is that several of the FS9
AFCADS that came with AI packages thatn I used
for a starting point may have had markers, etc,
included.

TRUE if they are new ones that were not in the stock bgl (NV. bgl). We can add new Markers which is allowed but the stock are always there also. My concern is when some are duplicating in 2 locations a marker when it is not needed.

I then loaded the AFCAD
and saved the xml. From there I did a cut & paste
of things like the boundry fences ( I have found it to be
really, REALlY tedious to attempt to add them with
either FSX Planner or ADE ), approach data and
the navaid and comms.

I do the same thing also to combine into a compliant FSX XML what AFCAD does not know about. I have some very complex FS9 AFCAD's I don't want to spend time redesigning for FSX so I copy paste same as you.

Nothing wrong with this, The only caution is Freq's in FS9 may have changed in FSX. If you bring in the AFCAD freq's that came from FS9 then FSX uses those and they might be wrong. When I make my deleteALL list I drop the

deleteAllFrequencies="TRUE" so it does not show. (same as saying "FALSE if it is listed)

This forces FSX to use all Freq's at the root and combine to both bgl's for a complete airport. (see list below)


<DeleteAirport
deleteAllRunways="TRUE"
deleteAllHelipads="TRUE"
deleteAllStarts="TRUE"
deleteAllTaxiways="TRUE"
deleteAllAprons="TRUE"
deleteAllApronLights="TRUE"
deleteAllJetways="TRUE"
deleteAllApproaches="TRUE"
deleteAllBlastFences="TRUE" />


If you copy part of a airport into your XML then it is mandadory to tell FSX not to use what is in the root bgl but use what is in your xml. This allows you to edit what you copy without a duplication. It is similar to a unlocking key.

If the deleteALl= is missing from the list then FSX knows that is FALSE by default and will always use what is in the root. SO I don't copy in what I want FSX to use at the default. Why have it in 2 places if is identical to begin with. Just causes a more work load on FSX when starting up to read it something in the root and then read it again in the new airport BGL twice if nothing changed.

Blast and Boudary fences fall into this also. Most don't tamper with those so drop the deleteALL=, don't copy to the new XML and let FSX use the defaults at the root. Keeps your XML a lot cleaner.

Notice I have deleteAllApproaches="TRUE".

That is because for this airport (EHAM) I rewote all the approach code and added it to my XML. I now have to tell FSX not do use what is at the root but use all my code. If I DO NOT rewrite approach code I let FSX combine the root approach code to the Runway ILS's that are in my airport bgl. Just remove the deleteAllApproaches="TRUE" or if it is listed say "FALSE".

Many FSX airports uploaded have the approach code listed twice in the default GPS Receiver which is a mess.

The reason is the Utility copied all approach code into the XML and then set the deleteAllApproaches="FALSE" which is now duplicated and being read from 2 sources. There is no reason to have all that approach code in the User XML if they are not rewritting it and then blocking it from showing in the GPS receiver.

In AFCAD Lee did something very unique. If someone placed approach code in his XML, on a compile of AFCAD he sets deleteAllApproaches="FALSE" and flushes out all the added approach code so it can't be read twice at the GPS receiver. Smart thinking on his part and others are trying to duplicate AFCAD but they can't duplicate Lee's thinking process.

Glad Jon is working on the marker issue for display and compiling if it exsit as a add in but like I said a stock always is processed even if it is not showing on the GRID. It is one of those nice to see symbols so we don't think FSX left it out by mistake.

We still have a long way to go with the PRO version that some are going to marvel over. I just have to be careful and not let the cat out of the bag yet so I sometimes maybe illusive. However, don't stop those issues you see from coming. Some of the designers knowledge here on this forum like yourself and others are very valuable information to the teams thought process and we thrive on that.

The nice thing is everyone gets to interact with the entire team rather then just Jon. Sometimes you get answers from us and Jon has to write the code and understand what it is we all want. He keeps us in line.

 

[scott967]

On the subject of the markers, in FS9 I have had situations where the stock marker is misplaced a bit, or maybe even quite a bit. In that instance I have simply added another marker of the right type. AFAICT, this doesn't cause any problem, though I haven't really tested to see if it really makes a discernible difference. Also with the heading: does FS9/X actually do anything with this, from a quick test it seems like the antenna pattern is circular?

scott s.
.

 

[jvile]

from a quick test it seems like the antenna pattern is circular?

Scott

In testing the markers it is purely a nice to have and gives the audible we listen for at the OM/MM ILS type runway in most cases and the OM/MM/IM for the CAT II and III runways in most cases (OM can be the exception). But you know all that so I just said it for others that read this.

If you do a precise slew around of the marker it is more in the shape for activating audible as a fan (diamond) rather then round. This is the reason it has to have a runway alignment heading.

Some airports with Parallels like KATL use one Outer Marker for both runways and when I changed the heading of a marker so it was 90 degrees from runway alignment it lost is side to side audible diminsion fan value.

I assumed from that, the marker must be properly aligned. I have noticed that the heading data for a marker at some airports is Mag and some are True. This causes a slight turning of the fan (diamond) symbol but has not been a big problem yet so I did not report it to Jon.

I thought months ago we found a way to show a correct marker by reading runway heading and then backtracking into the markers which are not part of the airport runway data and grabbing the correct Marker for the correct runway. They are very hard to match up on a GRID to what runway they belong to.

Jon has more details on the final code used to get a marker set correct to the runway it belongs to.

 

[scott967]

Thanks Jim. My quickie test was looking at a middle marker using the lights on the default 172sp in slew mode. I was at 200 ft to try to see what it would do realistically. What I found is the light turns on when approaching pretty close to the marker position, and the light remains on for a bit after crossing over. All my tests were flying over the marker, no tangential runs, which might be interesting. Also the impact of elevation over the marker. I will probably do some more testing just out of curiosity. I haven't looked at what variable causes the marker lights to come on at all. I assume it is pretty simple boolean.

scott s.
.