Use AFCAD 2.21 to edit FS2004 airport layouts, configure WOAI parking, update KORD and resolve duplicate BGL conflicts safely.
AFCAD 2.21 edits FS2004 airport-facility data—runways, taxi links, aprons, parking, communications and supported navaids—not terminal objects or AI schedules. Identify the active airport BGL, save one replacement BGL in an active scenery layer, then restart Flight Simulator 2004 and test ATC and AI behaviour before making further changes.
What can AFCAD 2.21 edit in FS2004?
AFCAD changes the facility data that FS2004 uses to operate an airport, rather than every visible part of its scenery.
| Airport element | What AFCAD changes | Main check |
|---|---|---|
| Parking | Position, heading, radius, parking type, number and airline codes | Connect each stand to the taxi network |
| Taxi network | Nodes, links, names, widths and surface types | Links must share real nodes, not merely cross visually |
| Runways | Position, dimensions, surface, starts and operating properties | Preserve runway links, exits and hold-short connections |
| Aprons and pavement | Facility-generated apron polygons and taxiway surfaces | Custom ground textures may still cover the result |
| Airport services | Communications and supported navaid data | Avoid conflicting frequencies or duplicate facilities |
AFCAD cannot move a separately placed terminal, hangar, jetway, windsock or static aircraft. It also cannot redraw a custom photo texture or alter an AI timetable. If the terminal itself must move, use the separate workflow for creating and placing custom FS2004 airport buildings.
How do I edit an FS2004 airport with AFCAD?
The safe method is to edit the facility source actually used by FS2004, retain a backup and load one intentional replacement above the stock airport.
- Install the correct editor. Use the FS2004-compatible AFCAD 2.21 download. This article concerns FS2004, also known as FS9; AFCAD 2.21 is not an airport editor for newer simulators.
- Close FS2004 and make backups. Copy the add-on airport facility BGL you intend to replace to a folder outside every active scenery area. Never overwrite or remove a stock BGL because one stock file can contain several airports.
- Find the active airport source. Open the airport by its ICAO identifier and inspect the source information shown by AFCAD. Compare it with the FS2004 Scenery Library. If an add-on airport supplies its own facility layout, use that as the starting point rather than editing the lower-priority stock layout.
- Separate facility files from visual scenery. An airport package may have one BGL for runways and parking, other BGLs for terminal objects, and a texture folder. Replace only the facility definition. Do not disable an entire scenery package merely because its terminal remains visible.
- Save one replacement BGL. A dedicated location such as
<FS2004>\Addon Scenery\My AFCAD\scenerymakes the file easy to identify and remove. Its parent scenery area must be active and have suitable priority. Our BGL installation and scenery-priority instructions cover the activation process in detail. - Edit exact properties. Change parking radii, codes, headings, taxi links, runway details or frequencies through each element's properties. Zoom in closely when joining links; two lines that appear to meet can still end on different nodes.
- Complete the operational network. Every usable stand needs a continuous route to the runway system. Check taxi-link types, runway links, runway starts and correctly positioned hold-short nodes.
- Run AFCAD's fault checks. Correct disconnected links and other reported faults, then save. A descriptive name such as
AF2_KORD.bglis helpful, but the filename alone does not determine which airport the BGL contains. - Restart and test. Exit FS2004 completely after replacing the BGL. Restart it, load the airport and test ATC routes and AI movement rather than judging the result only by visible pavement.
WOAI, airline codes and AI parking in FS2004
AFCAD does not install, create or schedule World of AI traffic; it provides the parking and taxi network that installed WOAI aircraft can use.
A WOAI package normally depends on a traffic BGL for its timetable and an installed AI aircraft whose aircraft.cfg entries identify the model and parking preferences. In the relevant [fltsim.x] entry, these fields commonly include:
atc_parking_types=GATE— the broad parking type the aircraft prefers.atc_parking_codes=ACA— one or more airline codes used when matching coded stands.
The AFCAD stand must be large enough, connected to the taxi network and compatible with those type and code values. Airline codes guide parking selection; they do not reserve a particular gate absolutely, and they do not create a flight. Uncoded stands are useful where several operators need shared or overflow parking.
If no WOAI aircraft appears, check the traffic schedule, simulator time and day, AI traffic-density setting, installed aircraft title and active traffic BGL. Changing an AFCAD cannot repair a schedule that does not reference the installed aircraft correctly.
Air Canada A220 parking example
An Air Canada A220 needs a compatible parking type and code, a connected stand and a parking radius large enough for its roughly 35.1 m wingspan.
- Inspect the installed A220. Open its actual
aircraft.cfgand find the Air Canada[fltsim.x]entry. Do not assume every package uses identical parking values. - Match the airline code. If that entry uses
atc_parking_codes=ACA, add the ICAO codeACAto suitable AFCAD stands. A different or missing value in the installed package must be handled accordingly. - Match the parking type. A gate is normally appropriate for a scheduled passenger A220. Use a ramp type only when the aircraft configuration and the intended airport operation call for it.
- Set an adequate radius. Half of a 35.1 m wingspan is about 17.55 m, so use at least an 18 m parking radius. Add some margin where the apron permits, especially if the AI model's geometry requires it, and check that adjacent aircraft do not overlap.
- Test the route. Confirm that the stand link reaches a continuous taxi route and that the aircraft can push back without crossing a building or another parking circle.
This setup makes the stand suitable for a correctly configured Air Canada A220; it cannot force that aircraft to appear. A valid traffic schedule must still place the flight at that airport, day and time.
How to edit KORD with AFCAD
To edit Chicago O'Hare in AFCAD, first identify which KORD facility BGL FS2004 is loading and keep its airport layout separate from any KORD terminal models and textures.
- Inventory the KORD scenery layers. Close FS2004, note every active Chicago O'Hare package and back up its files. An airport BGL need not contain
KORDin its filename. - Locate the active source. Search for
KORDin AFCAD and inspect the reported source. If a KORD scenery package is installed, start from its facility layout so the gates and taxiways remain aligned with that package. - Identify the facility BGL. Do not confuse it with separate terminal, ground-object or texture files. Disabling an object BGL may remove buildings without changing ATC or AI routing.
- Create one intentional replacement. Back up and deactivate the package's separate facility BGL before loading your edited replacement from a higher-priority active layer. Leave the stock airport untouched and retain the KORD package's visual files.
- Edit in small groups. At an airport as complex as KORD, change a gate group or taxiway section, validate it, and then continue. Large batches make a single disconnected node difficult to find.
- Check every critical connection. Validate gate links, taxiway intersections, hold-short nodes, runway links, runway starts and exits. Pay particular attention where several taxi routes cross or run close together; visual overlap is not a connection.
- Restart and observe traffic. Test departures from several terminal areas, arrivals leaving different runways and ATC taxi instructions in both directions. Preserve the previous working BGL outside active scenery until the revised KORD layout passes these checks.
If the KORD package stores facility and object data together in a way that cannot be separated safely, do not disable the combined file blindly. Keep a backup, use a higher-priority replacement only after checking for duplicate facilities, and confirm that both the terminal visuals and operational layout survive the change.
Why are my AFCAD changes not showing in FS2004?
Changes usually appear missing because another airport BGL is active, the replacement is in the wrong folder, or the user is looking at unchanged custom objects rather than facility behaviour.
| What you observe | Likely cause | What to test |
|---|---|---|
| Duplicate or offset parking, unexpected taxi routes or strange ATC instructions | Competing airport-facility BGLs | AI parking, taxi clearance and runway access |
| Terminal remains in its old position | Separate object-placement BGL | Whether parking and ATC changed underneath it |
| Old markings or apron artwork remain | Custom ground texture covering facility pavement | Taxi routing and parking positions rather than texture appearance |
| No change of any kind | Inactive folder, wrong source or failed save | File location, modified timestamp and scenery priority |
A mistake we see constantly is treating an unchanged terminal as proof that AFCAD failed. Terminals, textures and airport-facility data can all come from different files.
How do I isolate a duplicate AFCAD or airport BGL?
Isolate a conflict by changing one active airport layer at a time and restarting FS2004 after every change.
- Exit FS2004 fully. Do not rely on the simulator to reload a replaced airport definition during the same session.
- List the suspected layers. Include dedicated AFCAD areas and complete airport packages. Do not search only for filenames containing the ICAO code.
- Disable one suspect at a time. Use the Scenery Library or temporarily move a backed-up add-on facility BGL outside every active
sceneryfolder. Never remove shared stock scenery files. - Verify the edited BGL. Confirm its exact location and modified timestamp. If the timestamp did not change, AFCAD may have saved elsewhere or Windows permissions may have blocked the write.
- Restart FS2004. Load the same airport, aircraft, parking position and traffic conditions for each comparison.
- Test operational evidence. Request taxi clearance, inspect the assigned route and observe AI parking and runway use. Visual objects alone cannot identify which facility BGL is active.
- Keep the confirmed combination. Re-enable required terminal and texture files, but retain only one intentional add-on facility definition above the stock airport.
Why do AI aircraft get stuck after an AFCAD edit?
AI aircraft usually get stuck because the parking stand has no continuous valid route to the runway, not because the visible taxi line looks wrong.
- Disconnected nodes: links that cross or overlap without sharing a node do not form a usable junction.
- Wrong link type: taxi, apron and runway links have different purposes. An incorrectly typed segment can stop ATC finding a route.
- Missing hold-short point: runway entrances need a correctly connected hold-short node positioned near the runway boundary.
- Stand too small: an AI aircraft will not select parking that cannot accommodate its required radius.
- Incompatible parking data: type and airline codes should correspond with the aircraft's
aircraft.cfg, while shared stands may be better left uncoded. - Poor stand geometry: heading, link direction and nearby parking circles can produce bad pushbacks or overlapping aircraft.
After correcting the fault, start from several edited stands, request taxi clearance and observe both departures and arrivals at normal simulation speed. Keep the previous BGL outside all active scenery folders until the airport works with more than one aircraft size and parking area.