NZFF

Please use this topic to post any points you feel should become standards for the development of AFCADs

Here are a few of mine. There's a longer doc to explain some of these at the end of the post.

Runways
=======
Co-ordinates of thresholds match real life.
Runway Width is correct, including edge pavement if present
Runway Markings are correct
Runway Lighting is correct
No taxiway lights on runway
Green light end row on runway - only present if present in real life
Runway designation (no "Left" or "Right" for seal runways unless this is how they are referred to
Placement of PAPIs is accurate

Taxiways
========
Widths accurate
Edge Markings absent unless present in real life
Centreline Markings absent unless present in real life
Lighting only provided where it is in real life
Designation - Name the taxiway after the taxiway and not the holding point

Aprons
======
Surfaces made of correct materials
Apron edge lighting present as per real life
Parking Locations placed correctly
Parking Codes set according to VOZ AI traffic identifiers

Aerodrome
=========
Reference point matches that on AIP chart and co-ordinates
Com frequencies - only one per frequency type per airport


-------------------------------------------------------
The release of Lee Swordy's 'AFCAD' program has probably been responsible for the highest number of airports that developers have released beyond the default FS scenery. FS9 and FSX both use XML-based scenery for airports, and like writing a webpage without a WYSIWYG editor, working purely in code is far from the most expiditious way to produce something usable. With AFCAD, developers were able to see 'their' airport being created right under their eyes. All of a sudden, what was once a reasonably complex task became simple. Almost too simple, in fact.

An 'AFCAD' (as airport-only add-ons have since become known) is essentially the airport itself as it is printed in the AIP. Runways, taxiways, aprons, lights, and radio frequencies. Nothing in more than two dimensions. It's the flat bit that you land on, and has nothing to do with buildings, windsocks, towers, antennas, signs, boundary fences, terminals, baggage trolleys, light towers and everything that makes an airport look and feel like an airport. Because of this, AFCADs tend to receive poor attention from developers compared to the rest of their scenery creations. After all, why would anyone bother spending time working on a flat piece of land for a flight simulator?

Because we're trying to model the real aviation world as accurately as possible, both in terms of behaviour and appearance.

An AFCAD is about appearance, first and foremost, but should also behave as realistically as the sim allows. As AFCAD developers, we want to try and satisfy both these conditions (appearance and behaviour) where possible. There will be times when a choice we make about one condition will not affect the other. However, every choice we make should be done to try and satisfy at least one of these conditions.

Here are the three rules:
If a choice you have will not affect the behaviour of the airport, choose the option that looks as realistic as possible.
If a choice you have will not affect the appearance of the airport, choose the option that behaves the most like it would in real life.
If a decision you need to make will favour either the appearance or the behaviour of the airport, decide how important the behaviour is and choose the option with this in mind.

Data sources
==========
Images:
AFCAD developers tend to live off Google Earth/Google maps. While I admit I've used it many times myself in the past, it does have it's limits. First, there are parts of the country not covered by the images that are of a high enough resolution to build an accurate AFCAD airport from. Secondly, the images may not be recent enough to show the correct airport layout. Thirdly, even the higher resolution images aren't high enough for identifying things like runway and taxiway lighting.

Many city or regional councils in New Zealand have websites with hi-res maps on them. This can give alternative images that are sometimes of a quality far superior to that of Google Earth.

www.airliners.net and www.jetphotos.net are aviation-specific photo sites. Both have categories for 'airport overviews' which depict airports. Often these are aerial photos and can give another perspective on things.

Failing all of the above, Land Information New Zealand www.linz.govt.nz has an almost nationwide database of reasonable aerial images. They are black and white, but they cover everywhere. The image quality falls somewhere between poorer NZ images and better NZ images from Google earth.

Data:
Again, the 'bread and butter' for developers is undoubtedly the New Zealand AIP site www.aip.net.nz which is hosted by the Airways Corporation of New Zealand. This is certainly a 'must-have' site, but users should be familiar with the chart symbols before attempting to build an airport based on one. For instance, grass and seal taxiways are a very similar shade of grey "“ this is something the Microsoft developers missed when modelling scenery for FS9.

Also on the AIP site are a collection of documents about all the International airports in New Zealand. Go to the main page, then AD1 Aerodromes [airport name]. You will be taken to a PDF containing some very useful information about the airport. Again, use this information only after becoming familiar with it's quirks.

The CAA site holds another useful document in the form of runway end co-ordinates. http://www.caa.govt.nz/airspace/AirNavReg/...o-ordinates.pdf . Before building any taxiways you should always ensure your runway is located in the right place. There are a number of airports in the FS9 default scenery which were wrongly placed. The navaids are all perfectly positioned, so it can make for some interesting instrument approaches if you leave the airport in the wrong place!

Last of all, there are ways of calculating dimensions yourself provided you have a decent quality image. Just because you don't have the information on hand, does not mean you should just make assumptions.


CHECKLIST:

Runways
=======
Co-ordinates of thresholds match real life.
AFCAD will tell you the longitude and latitude of the pointer wherever it is on the screen. Load the CAA runway co-ordinates PDF and if they have included the airport you are modelling, you can compare your co-ordinates with the actual ones. For displaced thresholds, the 'runway end' is still the runway end.

Runway Width
But it says 45m, right? Sure it does, but how do you know if there is any edge pavement? The usable portion of the runway may be 45m, but there may also be some extra pavement either side of the runway. Here's how to find the runway width:
Get an image that shows the entire length of the runway and measure it using the measure tool in photoshop or some equivalent program.
Take the 'actual' length reported on the AIP chart, and divide it by this number.
Measure the width of the runway on the same scale and multiply it by the number you got from the last calculation.
It should be close to 45m, but it may be more. If it's more, it's likely they have used 'edge pavement'. In which case you now know to check that box in AFCAD.

If you are having trouble getting a decent measurement of the width because the runway is so long that the width becomes narrow, try zooming in to a higher scale then measure the length of one entire centreline stripe. ICAO Annex 14 dictates that a runway centreline stripe should be 30m long and have a gap of 20m between each stripe. Cool huh?
So again, measure a stripe, then calculate 30/your measured length.
Measure the width (again, in the same scale) and multiply by the number you got in the previous calculation.

Runway Markings
In particular, I'm referring to edge lines. A default AFCAD runway always has these, but they're actually not all that common in New Zealand. Just look closely at the aerial images. You may find that what looks like edge lines is actually lichens growing on the parts of the runway where no aircraft goes!

Runway Lighting
In particular, touchdown zone lighting. This isn't very common at all in New Zealand. Beyond the 3 major internationals, I can't think of anywhere else using these systems out there. Check the AIP for this info and look for "TDZ" in the section under Runway Lighting.

Taxiway lights on runway
This is where a hi-res image is useful. These lights are semi-flush units and you can usually see dots in the pavement where they have been installed. Generally speaking, a runway has no taxiway lights on it. Failure to remove them is something even the default FS9 developers managed, but it's not difficult. Just remove them from the section of taxiway in question. The runway should be a nice clean surface.

Green light end row on runway
Are they actually there? The only way to be certain is to visit the airport at night and see for yourself! Again, they are part of any default AFCAD runway so people tend to leave them in, but that doesn't mean they are there in real life. They're not too common in New Zealand.

Displaced threshold 'paint' on grass runways (no)
Grass runways aren't painted on, yet if you specify a displaced threshold on a grass runway they paint markings on! Personally, I would be inclined to make the runway it's full length and use static objects (not with AFCAD) to mark the displaced thresholds. You'd have to weigh up how big a deal it is that AI traffic won't use the displaced threshold. I'd hazard a guess that if the airport in question has a grass runway, there won't be much AI traffic. This is a good example of the tradeoff between airport appearance and behaviour.

Runway designation
Always make sure the seal runway is numbered without a left or right. It's very common in NZ to have parallel grass and seal runways, but Auckland is the only airport I know of where a seal runway is referred to as 'left' or 'right'. In FS, two runways on the same heading will automatically be assigned the names "left" and "right". Change it so the seal runway is just called the number.

Don't be scared to close a runway
FS isn't smart enough to distinguish between seal and grass runways. I've been told to make a visual approach for a grass runway in a 737 before and it just wrecks the flight. It would also look pretty silly seeing AI traffic landing on a grass runway when there is a perfectly good seal runway there. I always close those runways I don't want AI to use. By the same token, don't be afraid to open a runway (eg Christchurch runway 11/29).

Placement of PAPIs is accurate
Again, the default AFCAD location of PAPIs may not match where they are in real life. Most hi-res photos are clear enough to display the actual location, so don't be afraid to try and tweak the AFCAD settings on this

RLLS
RLLS, LDIN, or 'Runway Lead-in Lighting System' is a crude version of an approach lighting system used to guide aircraft to a runway. Unfortunately, FS has no easy way to model these at present. I'm sure we could use static objects that glow in the right colour at night and position them in the right places.


Taxiways
========
Widths accurate
Use the AIP docs or the measurement technique mentioned above to discover the actual width. Remember to vary them as required too

Edge Markings
While it's common in NZ to see centreline markings on taxiways, it's relatively uncommon to see edge markings (yellow lines). Check the aerial photo before you make a whole lot of taxiways that will otherwise need to be changed later. AFCAD default taxiways have edge markings. That doesn't mean you shouldn't change them.

Centreline Markings
There are plenty of taxiways with no centreline markings either. Some taxiways have lines, others do not. There's no reason you can't do this with your AFCAD. They don't all have to be the same.

Lighting
This should be the way it is in real life. The AIP documents give most the info you need here. Under 'Lighting Taxiway" they will say "edge" or "CL". CL means Centreline. In cases where it says CL and doesn't say edge, there is no edge lighting. Centreline doesn't imply edge lighting as well. Go to Wellington airport if you don't believe me! Also, not all the taxiways at one airport are lit. Sadly, nothing apart from an airport visit at night will give you this kind of information. Even the AD1 document doesn't go into enough detail.

Designation
Name the taxiway after the taxiway and not the holding point. This one affects the behaviour and not the appearance. It might be taxiway 1 with holding point Whiskey. In real life and in FS, the clearance is "Taxi via taxiway one" not "Taxi via taxiway whiskey". Forget naming the holding points, FS doesn't refer to holding points by name. It's just "Taxi to and hold short of runway"¦."Â￾ Also, if the taxiway designation in real life is anything other than short alphanumeric, don't name them. If you write word (eg parallel) fs will read it phoentically "Taxi via papa alpha romeo alpha lima etc"

Be brave
Don't hesitate to close a taxiway if you don't want it used by AI traffic. You can still use it yourself if you want. (behaviour)
Don't be afraid of separate taxiway links from different aprons to try and give a wider range of taxi movements (behaviour)
Don't be afraid to use an apron polygon if you just can't get the right shape out of a taxiway (appearance)
Don't be afraid to add small remnants of old taxiways to add realism. Just be cautious of link lines. If in doubt, use an apron polygon (appearance)


Aprons
======
Surfaces
Try to vary the surfaces where they change in real life. The building materials do nothing apart from 'look' a certain way, so use them. Concrete, Bitumus, Asphalt, gravel. They will all take Boeings happily so we might as well vary the surface where it changes in real life.

Lighting
Use lighting strips and don't be afraid to shorten the distance between lights. The default is quite wide and can make it difficult to tell when you are approaching a break in the apron for a taxiway at night if they are too wide. If you're really picky, you can measure these in critical places too.

Parking Locations
Set accurately. In the AD1 document, they have the co-ordinates of all stands. This can be a useful 'ruler' to see how accurately you have placed everything else.

Parking Codes
Set according to VNZ/VOZ AI traffic identifiers



Aerodrome
=========
Reference point matches that on CAA chart and co-ordinates
Just use this as a guide. If you are modelling an airport that is featured in the runway end co-ordinates PDF you will most likely not need to worry about this step, but if not then it's vital.

Elevation matches real thing
This is fairly obvious but it always pays to check.

Com frequencies
This is a biggie in the default scenery. Many airports have multiple ground, tower, approach and departure frequencies. What this eventuates to is a behaviour within FS that is nothing like in real life. Stock FS9 Wellington is a classic. If runway 34 is in use, the tower frequency is 118.8 as it should be and ground is on 121.9. However, if runway 16 is in use, more likely than anything ground will be on 118.8 and tower will be on 120.8. This is never the case in real life. FS9 also lists a stack of frequencies for Christchurch airport, simply because the centre is located there. Depart from Christchurch in stock fs9 and you'll be handed off to 119.5. The thing being, that's the Bay Sector in the north island. You have no control over which frequency FS will use. Don't try and copy every frequency. This is a 'simulation', not a frequency directory. We want to simulate how it works on a typical day. For each airport, you want to aim for no more than one of each frequency type. At least in this configuration you will be mimicking a config that is SOMETIMES used in real life.

Very comprehensive guide Richard. If anyone gets stuck, chuck up a post, likelihood is there'll be a member who lives near the airport in question who might know the info you're looking for, or is happy to pop down and check it out.

Alex

Good guide Richard.
You also have to decide what mesh you are designing for, and whether to include flatten/excludes for it.
I hate flatten lines in the scenery.cfg file because you often modify scenery and then are left with a legacy flatten.
Best put in a bgl with the scenery if possible.
Additional parking codes have been used for GNZLAP (i.e. sub-5 tonne MTOW) and are listed here

Thanks for putting this together Richard.

I was thinking that we should create flattens for all AFCADs so we're not mesh dependent, and I mean real vector poly flattens (none of the cfg business). This can be done easily with SBuilder. In fact, SBuilder is a great tool to also import background imagery from Google Earth. With SBuilder we can have a real ground texture from GE and put a flatten for the airport down. This works best with FSX as you can blend the ground texture with the 'ordinary scenery'.

Anyway, let's get a first build together first. I've been mucking around with the free Auckland 2005 scenery (airports only as I have the RealNZ scenery). Has anyone been able to sort out the black polygons that float everywhere? Looks like porting FS2004 scenery to FSX is going to be a bit of work...

Christian wrote:

QUOTE (Christian @ Jan 20 2008, 04:57 PM) <{POST_SNAPBACK}>

I was thinking that we should create flattens for all AFCADs so we're not mesh dependent, and I mean real vector poly flattens (none of the cfg business). This can be done easily with SBuilder. In fact, SBuilder is a great tool to also import background imagery from Google Earth. With SBuilder we can have a real ground texture from GE and put a flatten for the airport down. This works best with FSX as you can blend the ground texture with the 'ordinary scenery'.

I only found out about scenery.cfg flattens recently. Up until then, I had been using vector flattens. The way FS9 default scenery does it is to coincide the flatten poly with the exclude poly, which I think is a good standard for us to follow.

I'm a fan of SBuilder too. Not so big on SceneGenX for anything apart from object placement. I found it tended to wreck taxiway shapes if they were curved.

An interesting situation we'll have to decide how to cope with is overriding defaults. For instance, NZPM in FS9 is in completely the wrong place. If we just add to it then we'll have only one AFCAD, but we'll end up with two flatten and exclude areas, as well as the incorrectly placed airport buildings from the default airport. When I've built scenery like this in the past, I've modified the default BGLs, but this isn't an option for distribution as it means distributing copyrighted data. The other time we'll meet this problem is with LWM polygons, such as the enourmous lake north of Ohakea instead of the Rangitikei river. You can't exclude them. Surely there is a way to get rid of them?

Do you think it would be useful to assign some AFCAD/ FSX Planner gurus to create/check these files?

Personally I dont (yet) have a heap of knowledge on setting up the non visual parts of the airport facitlities (taxiway paths, ILS, non precision approach data etc) so it would be good to have someone check it.

Also, does AFCAD use Fs9/FSX XML based formatting?.....to ensure forwards capability we need to use it.

Timmo wrote:

QUOTE (Timmo @ Jan 22 2008, 02:26 PM) <{POST_SNAPBACK}>

Do you think it would be useful to assign some AFCAD/ FSX Planner gurus to create/check these files?

Personally I dont (yet) have a heap of knowledge on setting up the non visual parts of the airport facitlities (taxiway paths, ILS, non precision approach data etc) so it would be good to have someone check it.

Also, does AFCAD use Fs9/FSX XML based formatting?.....to ensure forwards capability we need to use it.

I think that's a really good idea - having some people as AFCAD peer reviewers. The reason I wrote my guide above was to hopefully eliminate some of the things that the peer reviewers would otherwise have to edit out later. It's much easier to make a change early on than it is to go back to a completed AFCAD and fix it. For instance, if you make a taxiway with modified markings, every taxiway you add after that will inherit those properties. Much faster than going back after the fact and changing them all.

NPAs aren't actually handled by the AFCAD, they're in the nav BGL, but there is still a fair amount of non visual work to creating an AFCAD so this would be good.

AFCAD does use XML formatting. Anything AFCAD creates can be de-compiled with BGL2XML and recompiled back again. I've had terrible luck doing the latter, but it is XML so it will be possible. There are a few subtle differences in the AFCAD format between FS9 and FSX - things like boundary fences are added in for FSX.

At airports where there is more than one runway (eg one seal and one or more grass runways) do people think we should close the grass runways?

My reasons for doing this myself in my own personal add-ons are:

1. Because if the wind favours it, the grass runway will become the duty runway. Terrible realism if you're flying anything larger than a light twin.
2. Because you can't actually select a different runway to land on. Even if the wind favours it, the runway ATC give you WILL BE the runway you're expected to land on. Sure, you can request a different approach, but all that does is give you either a circling approach or sidestep approach. In either case, tower will expect you to land on the original runway.
3. Would we want AI traffic using the grass, given we can't really spell out which runways we want different traffic types to use?

The grass runways will still exist, and those who don't use FS ATC can use them as they wish to. At the moment, those who use FS ATC receive a poorer example of realism with the grass runways open than they could if they were closed.

Thoughts?

I have to admit Idon't know enough to comment. I fly small aircraft so I'd like to use grass runways. Maybe we can offer 2 sets? It's not really much effort to produce 2 sets, there aren't many airports affected.

Christian wrote:

QUOTE (Christian @ Jan 26 2008, 08:18 PM) <{POST_SNAPBACK}>

I have to admit Idon't know enough to comment. I fly small aircraft so I'd like to use grass runways. Maybe we can offer 2 sets? It's not really much effort to produce 2 sets, there aren't many airports affected.

This is probably the best compromise, all things considered.

Something else I think needs to become a standard for AFCADs is that there must be a flatten and an exclude made for the entire airport boundary (assuming the plans of photoreal airport textures will allow this). I'm having some nasty CTD issues at the moment, and I seem to have pinned it down to the contents of the 'Addon Scenery' folder, which contains a lot of third-party AFCADs that don't have flattens anywhere. Consequently, the runway is sometimes buried into the ground in patches.

greaneyr wrote:

QUOTE (greaneyr @ Jan 26 2008, 09:01 PM) <{POST_SNAPBACK}>

I'm having some nasty CTD issues at the moment, and I seem to have pinned it down to the contents of the 'Addon Scenery' folder...

CTD is more likely conflicting AFCAD versions - I make a point of searching the FS folder every now and then for "AF2*.*" and flushing them.
Passing thought for grass runways is to make a second airport for the GA (Taking care not to clash names with the airport list posted earlier). That way the heavies won't try to mow the lawns.

AF2 is correct for FS9 isn't it? (FS9 is what I'm running)

greaneyr wrote:

QUOTE (greaneyr @ Jan 26 2008, 09:41 AM) <{POST_SNAPBACK}>

At airports where there is more than one runway (eg one seal and one or more grass runways) do people think we should close the grass runways?

My reasons for doing this myself in my own personal add-ons are:

1. Because if the wind favours it, the grass runway will become the duty runway. Terrible realism if you're flying anything larger than a light twin.
2. Because you can't actually select a different runway to land on. Even if the wind favours it, the runway ATC give you WILL BE the runway you're expected to land on. Sure, you can request a different approach, but all that does is give you either a circling approach or sidestep approach. In either case, tower will expect you to land on the original runway.
3. Would we want AI traffic using the grass, given we can't really spell out which runways we want different traffic types to use?

The grass runways will still exist, and those who don't use FS ATC can use them as they wish to. At the moment, those who use FS ATC receive a poorer example of realism with the grass runways open than they could if they were closed.

Thoughts?

It may be possible to just shorten the grass runway so that bigger aircraft can't use it. I think this is how Tauranga works.

greaneyr wrote:

QUOTE (greaneyr @ Jan 27 2008, 11:53 AM) <{POST_SNAPBACK}>

AF2 is correct for FS9 isn't it? (FS9 is what I'm running)

What I was getting at, is you may have an AFCAD sitting in Flight Simulator 9\Scenery\World\scenery, which may have a different version in Flight Simulator 9\Addon Scenery\scenery, and yet another perhaps in the scenery folder of some installed addon. They would conflict and cause CTD. I've moved away from having AFCADs in Addon Scenery\scenery, and tend to leave them in the addon's scenery folder now.

toprob wrote:

QUOTE (toprob @ Jan 27 2008, 01:53 PM) <{POST_SNAPBACK}>

It may be possible to just shorten the grass runway so that bigger aircraft can't use it. I think this is how Tauranga works.

Often though the AFCAD is all you have, and that might look odd.
It makes the case for texturing the entire airport area though, rwy's included.
That way the AFCAD isn't visible, and you can fiddle with it.

Charl wrote:

QUOTE (Charl @ Jan 27 2008, 07:05 PM) <{POST_SNAPBACK}>

What I was getting at, is you may have an AFCAD sitting in Flight Simulator 9\Scenery\World\scenery, which may have a different version in Flight Simulator 9\Addon Scenery\scenery, and yet another perhaps in the scenery folder of some installed addon. They would conflict and cause CTD. I've moved away from having AFCADs in Addon Scenery\scenery, and tend to leave them in the addon's scenery folder now.

Ahh I get you. Still, at some point you're going to have overlaps aren't you? Unless you have enough new AFCADs to effectively replace an entire default AP*****.BGL tile, you're going to have at least two versions of one AFCAD. I know that's certainly the case with my FS install.

Robin:
FS certainly does something funky with runways. Airports such as Ohakea and Christchurch never advertise the secondary seal runways as being in use, regardless of the wind. I've always found it odd that this is the case, and yet at New Plymouth I'll frequently hear runway 14/32 in use.

Charl wrote:

QUOTE (Charl @ Jan 27 2008, 07:05 PM) <{POST_SNAPBACK}>

It makes the case for texturing the entire airport area though, rwy's included.
That way the AFCAD isn't visible, and you can fiddle with it.

Are you talking about texturing using the FS2002 SDK + GMAX, or just using photo textures? I thought that the AFCAD elements were still visible above the photo texture if you did that? What about things like lights? Will these show through?

While we're on the subject of lights, what about those airports with RLLS/LDIN systems installed? There's no way to model these in an AFCAD but they're not high tech and would be quite easy to add in using custom objects I'd imagine. We would just need information on the location of each light so we can accurately place them.

Robin does this in RealNZ - I went looking at NZTG after his earlier comment and that's an example. (GNZLAP has a custom AFCAD for that airport which operates fine but doesn't show all visual elements)

Just thinking about this after the development of some airports in FSX Planner recently.

I think it would be good to separate out the different aspects of the airports into different BGLs so that if some aspect is causing problems/conflicts it can be disabled. It also means if one aspect of the airport is changed (i.e. taxiway names/locations) then only one aspect has to be updated and released.

For example:
(ICAO Code_Type_Suffix_FSVersion.Bgl)
AA_Facilities_FSX.Bgl- Contains all the AFCAD/FSXPlanner information- Runways, taxiways, parking for Auckland etc etc
AA_Buildings_FSX.Bgl- Contains models (either custom or library) of buildings
AA_Buildings_2_FSX.Bgl- " " " (Suffix needed for multiple building Bgls)
AA_Flatten.Bgl- Contains the flatten
AA_Vegetation_FSX.Bgl- Contains 'placed (i.e. not autogen) trees
AA_Misc_Cars_FSX.Bgl- Contains other items, in this case cars.
AA_Misc_Objects_FSX.Bgl- Contains other misc items.



I think priority should be placed on creating accurate Facilities information for all the airports/airfields in the Vol 4...these can then be updated with custom buildings etc as time goes on.

Thoughts?