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

Ideas for a new scenery design tool

Thanks from me also Jim

I agree with Arno and would add that you suggestion on sub tools mirrors our thinking on task based division of the program. I believe that is what we have in mind. You have clarified for me what those sub tools could be and how they might inter-relate.
 
Unfortunately the same XML code is now also used for the visual aspect of the scenery, so that means the AI and scenery demands sometimes collide.

Arno

What visual aspects of the scenery. Are you refering to FS2004 or something new in FSX. I don't see anything in FSX that is different except the Jetways and the visual model for the ILS, NDB and VOR which are now nested under the airport header instead of above the airport header.
 
Hi Jim,

I am refering to the fact that the Fs2002 AFCAD only had effect on non-visual things, so it was only used by "AI people", while in Fs2004 (and FsX) it also determines the visual part of the airport. So besides the AI people, scenery designers are now also using the tool.
 
Arno

But Scenery designers should not be using the AFCAD tool as we know it today and we should not promote its use for adding any type Object Scenery into a decompiled AFCAD bgl. That is how the exclusions and buildings added by designers got into a af2_.bgl to begin with.

I agree and understand how AFCAD and FS2002 worked. I also know what some scenery designers try and do with a AFCAD type bgl (adding XML exclusions and buildings) and all the troubles it presents to the user if they want to change a simple parking space.

The key element in any scenery bgl is the Airport Header (if needed) and what is listed above and below it. AFCAD type scenery design programs must work with the data that nest under the Airport Header in the correct AP*.bgl. The Taxiway signs and all Approach data is also under the Airport Header and belongs to the Airport and not the Region Code. FSX has added some additional modeldata under the Airport Header which I listed above.

All visual airport scenery which is listed in the SDK must nest above the Airport Header because it is not owned by the airport but is owned by the Region code and then the Lat/Lon value.

This allows the combining of airport Scenery Objects and the visuals of what AFCAD adds to be in one scenery bgl. However, in the past it was a limitation of Lee's AFCAD program and not the FS program.

Tools that are properly coded can combine all the airport Scenery Objects with the now current AFCAD type scenery as long as the correct airport information can still be edited by the user.

I feel confident we are in unison on this but my original post may not have been clear in that area.

For almost 3 years I have been combining all the airport visual scenery with my Approach data into the same bgl. At that point I still give everyone a AFCAD bgl so they can tweak the airport to their specifications.

If you look at any of my ILS bgl's uploaded to AVSIM I combine all exclusions, modeldata, Guids, Generic buildings, Jetways, taxiway signs, Terminal_Waypoints, correct Approach data needed, etc. into one single scenery bgl.

I make a AFCAD bgl with the airport visuals to coorespond with the scenery bgl so all users can edit the AFCAD as needed.

A tool can put all of these into a single compiled bgl but in my original post I was listing some issues that need to be addressed with such a tool.
 
Hi Jim,

For stuff like 3D objects I agree. But I think it is wrong to say that scenery designers should not use AFCAD as it is. Things like startup positions, runways, etc are things that designers need to place in their scenery. These are aspects that are inside the Airport tag in the XML code. So the designer has either the option to use AFCAD or another tool that can create this code (for example SceneGenX). But using SceneGenX can create conflicts later on again, as having the same airport defined twice can also result in trouble.

A lot of the problems we are talking about here occur because people are not aware of the fact that AFCAD BGL files are not special BGL files, they are using the same code as BGLComp generated ones. But AFCAD only reads and writes a subset of the total format.
 
Hi Jim

OK I am certainly over simplifying a complex situation but as I understand it you are saying that those things which are nested under the Aircraft Header should be placed in their own bgl file and not mixed with scenery objects which can go in another. So does it make sense for a tool such as we are discussing to generate separate bgl files for each type of information. That is, of course, easy to arrange. Forgive me if I have gotten the wrong end of the stick :)
 
Arno

I agree that current scenery designers should use AFCAD as it is. That even includes FS2002 because a AFCAD airport must align with any 3rd party scenery even if they use their own runway and taxiway textures. AI Planes do not follow a taxiway like a User Airplane which uses visual cues. AI Planes must follow the link lines that must also embed/overlay the visual 3rd party textures.

My point is some designers decompile a AFCAD bgl with NewBglanalyze and add additional excludes and buildings that AFCAD in its current state will delete. These additional scenery elements can't be under the airport header and AFCAD removes them if the User opens the AFCAD, changes something then saves.

scruffyduck
those things which are nested under the (correction) Airport Header should be placed in their own bgl file and not mixed with scenery objects which can go in another.

There must always be a AFCAD type airport for any and all 3rd party scenery (FS2002 FS2004) so the User can edit the AFCAD data and make parking spots apply to his model mdl aircraft radius. AI Aircraft designers do not use a standard radius. FSX now uses the wing span divided by 2 and a different code for parking.

If it is time to make a new tool that resembles AFCAD then it should not be limited to what is listed under the Airport Header (only) in the current version of Lee's AFCAD tool.

A new tool for FSX can allow all the scenery for the airport and what AFCAD adds (runway textures, taxiways, aprons, freq. start locations, etc.) to be in one bgl.

This is not possible at the present moment in FS2004 regardless of what some scenery designers are trying to do.

So does it make sense for a tool such as we are discussing to generate separate bgl files for each type of information.

No

That is the problem we have now with AFCAD and Scenery Objects because it is AFCAD that will not accept the additional scenery not FS. FS is just the opposite and will allow all airport Object Scenery and airport scenery (which AFCAD works with) to be in one bgl.

AFCAD only allows what is listed under the Airport Header in its bgl and some VOR navdata above the Airport Header.

Also, FSX and the previous FS9 allows a mixing of both into one bgl as long as the exsisting AFCAD XML data is below the Airport header. This becomes a problem because the user cannot edit any part of what would be the AFCAD data if it is in one bgl with all the scenery data that FS allows.

Example of a compiled bgl

<?xml version="1.0" encoding="ISO-8859-1"?>
<FSData version = "9.0" xmlns:xsi='http://xxxx xsi:noNamespaceSchemaLocation="bglcomp.xsd" >

multiple xml exclusions
any type scenery such as generic buildings, model mdl, etc.
Guids such as Tower with attachments
windsocks
Jetways (Fs2004 only)
ground support eqiupment
any additional VOR's, NDB's etc that are not attached to a Airport

Now list the Airport Header here

All the AFCAD data if you decompile a AF2_*.bgl

add taxiway signs
All Approach data and Transistions based on ARINC
Terminal Waypoints
Terminal NDB's

close with FSdata

FS allows all the AFCAD airport data scenery if it is added under the Airport Header and BGLcomp will compile with no errors.

However, the AFCAD program is just the opposite and will not allow any of the scenery above the airport header unless it is a VOR only. AFCAD was not entended to be a scenery program except for what is listed as per the SDK under a Airport Header excluding Taxi signs and approach data.
 
Last edited:
Thanks Jim for clarifying this agian, I think we do agree here.

But this is indeed something we need to be aware of. For example, what happens if people continue to use the current AFCAD version with FsX (not sure if that is possible though), that could have implications on how we generate the BGL files from our tool, as we don't want a user editing an airport with AFCAD to destroy part of the information in there. So that is something we surely need to think about.
 
Thanks Jim for the explanation. That makes it clear.

Arno
I guess it is entirely possible that AF2 bgls will be used in FSX. If not directly (since it does not read FSX bgl files properly as far as I can see) then via FS9. There must be thousands of AF2 files out there and peope will surely import them into FSX.
 
This past weekend - I used FSUIPC and AFCAD to copy an FSX airport into AFCAD. Had to trace the aprons, taxiways and runways, etc. I then modified the parking, taxi paths, etc. Saved the FS2004 file - moved it to the FSX.

People will start using AFCAD to work with airports for FSX as soon as the program hits the street and they realize that FSUIPC will feed location data to AFCAD.

The only difference is that they will not be able to pull the base airport information from the FSX APXnnnnn.bgl files. But it will not take much work to figure out how to get around that.

The problem with AFCAD used as a visual scenery tool is limiting the data in the AF2_file (Please a new name and not AFX_ICAO - personally I prefer the ICAO first by default.)

The data which impacts AI and user aircraft parking, taxi paths, aprons, runways, taxiway signs, etc - needs to be in a user editable file. Everybody wants to tweak their hometown airport. If they cannot do it with a simple tool - they will decompile and modify files and mess them up. There are also a lot of options which had no impact in FS2004 which need to be tested in FSX - taxiway weights, pushback direction, etc - plus new options in FSX.

Other data - especially objects like buildings, scenery objects, navaids and such needs to be stored in a separate file - which cannot be easily decompiled and modified.

That's not a conclusive list - but as Jim noted - stuff not associated with the airport - needs to not be in the airport file - like buildings.

Though, it would be useful if the position of default buildings and objects were displayed in an AFCAD like tool.

I certainly cannot keep up with the programming discussion - but urge you to look at how two different groups will use the tool(s).

Scenery designers and average users

Average users are going to ask for a lot of extra features - which they are often not willing to learn how to use.

Lee Swordy held a long discussion in the AFCAD2 beta about adding code to modify and create an ILS - localizer and GP. He felt strongly that it would be misused by people who did not understand how they were used in the real world and the impact, or lack of impact, upon the approach system.

He was very reluctant to include that capability - only doing so because people were using older programming to add ILS to their airports which totally fouled up the approach system.

But scenery designers need to learn early that a one file method will not work.

A design tool which creates such discipline by default would be very beneficial.
 
Last edited:
Thank you

this is certainly increasing my understanding of how AFCAD came about as is used by different groups.
 
Thanks for this post, yes we clearly need to think about how we can make a tool that both scenery designers and "average users" can use without trouble. This seems to be a very hard requirement on such a tool.

I must say that I am a bit worried about using AFCAD with FsX. As discussed above AFCAD only reads parts of the BGL files, so I think we could loose vital FsX information if we try to use AFCAD on the new BGL files.
 
Is the soution 2 tools? a restrict one that allows the "home town" airport change and a power tool?


José

I do not think so. Worst case it is two GUI's of the same tool (so different views) but I do not think this is needed either if we design the GUI correctly.

If for example approaches are not consistent with ILS etc, we should clearly indicate what the problem is, and quite simply refuse to generate the scenery until it is fixed.
 
Lars,

I agree there. But we need to be very aware of the problems that can occur when people try to edit our generated BGL files later with AFCAD. As AFCAD is very popular, they will do that. And we need to make sure that will not destroy the scenery.
 
Despite the range of views it does seem to me that generating two (or more) bgls might be worth further thought. I suppose there might be some performance hit in having multiple bgl files but I'm not sure that is proven???

AS with SBuilder which generates bgls for each type of scenery structure if our tool worked on a similar model then perhaps we can minimize the risk of someone changing a bgl in such a way that they get unexpected results.

Also I think we can only legislate for how our tool works and we control how things get compiled or decompiled.
 
Despite the range of views it does seem to me that generating two (or more) bgls might be worth further thought. I suppose there might be some performance hit in having multiple bgl files but I'm not sure that is proven???

AS with SBuilder which generates bgls for each type of scenery structure if our tool worked on a similar model then perhaps we can minimize the risk of someone changing a bgl in such a way that they get unexpected results.

Also I think we can only legislate for how our tool works and we control how things get compiled or decompiled.

It is definitely an option, and luckily something we can easily manipulate later - as it is only the final BGL writer generating the scenery from our data model that needs to deal with this.

I guess we can't be so lucky that the AFCAD loader is broken - meaning it is not able to load everything Flight Simulator X is. If we could inject a valid BGL structure in the file throwing AFCAD off the track, we could prevent people using it. :D
 
Lars,

I agree there. But we need to be very aware of the problems that can occur when people try to edit our generated BGL files later with AFCAD. As AFCAD is very popular, they will do that. And we need to make sure that will not destroy the scenery.

Hi Arno.

I've tried to load the default FSX files into AFCAD. It can detect them, but it cannot decompile them.. so AFCAD cannot display them or edit them.

Dick
 
Is the soution 2 tools? a restrict one that allows the "home town" airport change and a power tool?

That is a better way of saying it rather then my previous post that refers to a base tool then adding in more powerful sub-tools.

I suppose there might be some performance hit in having multiple bgl files but I'm not sure that is proven???

That is exactly what does work in FS9/FSX and is promoted by MS if the bgl's are located into the proper folders.

The problem with Airport scenery (what AFCAD works with) cannot be overlayed at a higher scenery priority like other forms of mesh, land class, adding generic buildings etc., etc. When I use a program like Sbuilder all I need to do is select, draw and lay down a new LC which also appears to be layer priority sensitive.

The XML data in the AP*.bgl works differently. FS is always going to load the default AP*.bgl data and then look for instructions written at a higher scenery priority to substitute new XML data. If you write XML data that is in the default AP*.bgl and place it higher it is now duplicated in FS not over written.

AFCAD copies out certain XML data from the default bgl. But the very first instruction written just after the Airport Header is the
<DeleteAirport
deleteAllApproaches = "FALSE"
deleteAllAprons = "TRUE"
deleteAllFrequencies = "TRUE"
deleteAllHelipads = "TRUE"
deleteAllRunways = "TRUE"
deleteAllStarts = "TRUE"
deleteAllTaxiways = "TRUE" />

Six out of many many areas of the default AP.bgl are now copied into AFCAD and can be edited and saved at a higher priority level. End result is that most of the XML in the default AP*.bgl is still used and only the AFCAD XML is used that was copied out at a higher priortity level. If the delete statements are not used and I change something about a runway in AFCAd then FS uses both the original and the AFCAD runway data. That is a sure CTD.

There is no automation when working with certain bgl's. You must first tell FS not to use what is default, then write what will be used.

Notice there is no ILS = False. All the ILS data that is seen in AFCAD gets attached to the Ruway properties because AFCAD also reads the companion NV*.bgl. AFCAD can not or will not edited the default ILS data because it would destroy and no longer agree with the Approach data which ='s FALSE which is also used from the default AP.bgl (see Reggie's post above).

I would go one step further and say that no exsisting Runway number can be changed. There is no Payware scenery that has ever done it right to date. Look at all the high power Payware for EHAM, KMCO, KDEN, LEBL, KIAH, KMIA, just to name a few and when their scenery changed the runway numbers they did not rewrite the approach data. On the visual surface (airport VMC) everything appears ok but then change the weather to less then 3 miles and all the approach data becomes corrupt. When someone makes a AFCAD, that also corrupts the Navaids listed by AFCAD and are distorted severly.

I have had conversations with the designers and the sad part is they continue to blame MS by saying FS has limitation that they can't overcome.

The 2 bgl process mentioned above does work and says all AFCAD airport XML data is in one bgl. I continue to promote removing the ILS data from the runway properties based on the way AFCAD does it. This is so no one can add a new ILS, try to change a ILS or renumber a runway without further knowledge of how to rewite or edit the default Approach data.

The second bgl would have to be a more powerful tool which would add additional 3rd party airport XML building scenery, objects, mdl model data, Navdata, approach data, boundry's, etc.

This is what I have been doing for several years now but I also follow the MS recommendation on where these 2 bgl's should be installed. My KMSP v1.1 on AVSIM is an example of the 2 bgl process but also reqiured me to have a single bgl for the flatten and a single bgl for the LC. All total I made 4 bgl's which included the AF2_KMSP.bgl (AFCAD).

The single most powerful bgl that I hand wrote has all the XML exclusions first then new building scenery, Objects, Guid's, mdl modeldata, new taxiway signs, waypoints and all new Approach data for the new runway which I added with AFCAD. Embedded in this single bgl is also the exclusion for Mall Of America which the default FS scenery put it in the wrong location. I then reinstalled the buildings that make up MOA and placed them in their correct Lat/Lon. The LC bgl is needed to increase the size of the airport ground texture and adding 2 new LC for where MOA was and where it was relocated.

I can only imagine a powerful tool that would let me do all this from one source. I said earlier I am not a tool designer but have been very successful in writting/combining all types of FS XML data into a single bgl and using the requirements that FS understands.

A side note is that AFCAD can read the airport header in FSX (see post above) but needs a code tweaking to decompile the bgl and be able to read the additional bgl's it works with based on there new naming scheme.
 
Last edited:
I could be wrong but what the "Home town changers" are looking for is usually a quick way of changing taxyways, aprons and parking spots. Runway changes come in second and it's important especially when you need to relocate everything. So this need resumes to:

Rearrange parking spots: add new, delete old

Rearrange aprons: Delete Old, make new, change old shapes;

Rearrange taxyways: Delete Old, make new, change old shapes;

Automated vertical signing with new aprons and taxiways;

Rearrange buildings: Delete old, relocate old

In a second level
Change runway characteristics;

In a third level
Change navaids

In a fourth:
Change procedures;

I don’t know what happens in other countries but I believe that the main source for accurate information is the AIP however this implies an effort. So the google earth is the best candidate. I believe that afcad success came from the simple and intuitive GUI.

I too believe that a merge powerful tool is needed but I’m still wondering if the expert/basic views of a powerful tool is the solution. For the above problem.


José
 
Back
Top