Oh, the Things You Can Do!

[allardjd 1,853]

John’s Corner

 

Oh, the Things You Can Do!

 

by John Allard

 

Dave Jones and I have a shared expression that I’ve used in this column before to describe certain things – quicksand. This article is about a certain kind of quicksand, that of editing FS airports. The first few steps are great – as all of it is, really. At some point, however, you realize that it’s bottomless – there’s no depth at which you can say, “I’ve found the end of this one.” Don’t say I didn’t warn you.

 

Once you get your feet wet with this kind of thing, it brings to mind the exclamatory Dr. Seuss line I’ve borrowed as a sub-title. Airport editing can make you feel like that once you realize what’s possible – and much is possible. Certainly all of us at OFSC have become aware of the kind of thing that’s feasible with the release of Dree’s KOCF scenery for FS9 and FSX – what a difference! If we’d never seen the real KOCF, that airport scenery would still stand out in FS, visibly better than the stock version of almost any other airport. If you’re fortunate enough to have seen the real thing, as we have, then you can’t help but appreciate how well done and accurate he’s made it. That’s our first inkling of what’s possible by way of editing airports.

 

This article is intended neither as a review nor a how-to. After you’ve finished reading this you won’t be any more capable at editing FS airports than now, but you may have more interest and a better idea what can be done and what sort of tools are required and available if you wish to take that first step into the swamp.

 

There are something on the far side of 20,000 airports in FS9 and at least 10,000 more in FSX. Some few are photo-realistic creations of pretty high quality; at the other end of the spectrum are all those bare grass strips with no facilities at all. Those latter are just a faint brown stripe in that nicely mowed rectangle of grass. You know the ones I mean, impossible to find in the dark and nearly impossible to land on satisfactorily in any kind of a crosswind, often with a tall tree at the approach end. They’re all there – the extremes and everything you can imagine in between.

 

Why would you want to edit an airport? There are any number of reasons, but they boil down to appearance or utility. For me the first reason encountered, and to this day the most powerful of motives is to give deserted airports the ability to accommodate traffic – so usually utility in my case. Whether you only have native FS traffic, a freeware package or a high-end payware traffic application, no airport is going to have any traffic unless there are parking spots defined. If a traffic program sends AI aircraft to a barren airport with no parking spots, and if you’re at the destination watching, you’ll see him land and abruptly disappear as he stops on the runway. If the traffic package attempts to originate a flight there, it will never materialize. Parking spots are the key to all of it and it may come as a shock to know that most stock FS airports have none.

 

Airport editors are not only the quick and easy way to add parking at FS airports, as far as I know they are the only way, short of writing XML code. An interesting thing about parking spots is that after you’ve added one with an airport editor, you don’t even see it directly in FS, though you might see the optional paint lines on the apron that lead to it. An FS parking spot is an invisible entity that is part and parcel of an airport. Its primary function is to confer the ability for FS AI traffic to use that airport and for them to behave somewhat realistically while there.

 

Taking a half-step back, it’s important here to identify the different tools used to edit airports. They fall roughly into three categories…

 

• Airport Editor

• Object Placer

• Scenery Designer

 

It is the first of these, the airport editor that is the focus of this article. The airport editor is intended to add, edit or delete the airport components, entities, properties and features, i.e. those things that are an intrinsic part of the airport.

 

 

Placing buildings (with certain exceptions), vehicles, trees, roadways, tank farms, signs (except runway and taxiway signs), light poles, cargo containers lying about and other such things that are often used to dress up airports are outside the purview of the airport editor. For those you need an object placer, though some of the current airport editors do blur that line a little. To create from scratch such objects, i.e. buildings, vehicles, etc, requires a Scenery Designer. We won’t be discussing those.

 

The airport editor’s stock in trade is the visible and invisible elements of what it takes to make the airport functional. Airport editors deal in runways; ramps; taxiways; start positions; hold short positions; parking spots; runway and taxiway edge stripes, lights and signs; navaids; radio frequencies and other such related things. They are not so much geared toward the non-functional, eye candy features.

 

Unless creating a new airport from scratch, which the editors will handily do if you wish to, the runways themselves are not something often worked with in the editor. More typical if you’re tweaking an existing airport is working with parking spots, ramps and aprons and with the taxiway and parking links that tie them all together. During and after placement, those entities have certain properties that must be defined and set. Such things as surface type, width, striping, edge and center-line lights and other properties must be specified for taxiway links. Parking links are similar but often lie atop ramps. Ramps share some of the same properties, but their shapes are not constrained to be linear – their outlines are laid out by clicking points connected by rubber-band lines, permitting irregular shapes of virtually any size and orientation with straight-line edges. Taxiways or parking links, most often the latter, may overlie ramps and define taxi paths and parking lanes upon them.

 

 

Airport editors use a network of nodes and links to define aircraft pathways, whether for runways, taxiways or parking links. A node is simply a defined geographical location on the airport, shown in the editor as a largish round spot of a specific color to denote its type and function. Links are straight lines that connect the nodes. Though they show in the editor, in FS the nodes and links themselves are unseen. They are, however, there in FS and are important, defining the paths, limits and intersections of the various airport highways and byways. The nodes not only serve as connectors for the straight-line links, they constrain or trigger certain actions by the AI aircraft that use them. The taxiways and runways associated with the system of nodes and links do appear in FS, of course, and the details of their appearance are controlled by the properties assigned to the individual links.

 

For example, an east/west runway 9/27 may be 3,500 feet long, with an asphalt surface 125 feet wide, having medium intensity edge lights, threshold lights, Runway End Identifier Lights (REIL), runway numbers, a dashed centerline stripe, solid edge stripes and touchdown zone markings. A certain taxiway connecting to that runway may be designated as taxiway Juliet and be of concrete, 80 feet wide, with solid lines right, left and center and blue taxiway lights on the right edge only. Some distance away that taxiway may branch to a grass-surface parking link that is 60 feet wide with dashed lines right and left. The parking link may terminate at a GA Medium parking spot designated as Parking 7 with a radius of 45 feet and oriented at 315 degrees true. The foregoing is not an exhaustive listing of the properties of each kind of entity, but should serve to give an idea of the kind of things that are accomplished by setting properties of the various airport elements.

 

 

Parking spots take on special importance, as they are one of the principle objects of the node and link system. Most of the network end-points tied together with nodes and links are the various parking spots. Parking spot types recognized by FS are…

 

• Dock GA

• Gate Heavy

• Gate Medium

• Gate Small

• Ramp Cargo

• Ramp GA

• Ramp GA Large

• Ramp GA Medium

• Ramp GA Small

• Ramp Mil Cargo

• Ramp Mil Combat

 

The various types of parking are pretty much self-explanatory. The important thing is that they exist in sufficient numbers to accommodate the traffic that will use the airport and that they are properly connected to the runway(s) by the node and link system. A continuous path defined by taxiway and parking links must exist from a runway to a parking spot or that spot will not be used properly by AI traffic. If disconnected, arriving traffic will not move there. Originating traffic may appear, but will be unable to move and will eventually just disappear. The various editors contain a helpful utility called a Fault Finder. When invoked it will scan the loaded airport and will report such problems as isolated segments, disconnected links, etc.

 

The inherent traffic management system in FS normally operates a few notches above stupid and can usually be depended upon to route AI aircraft to the appropriate kind of parking spot, subject to a set of built-in hierarchical rules. Those rules allow the program to determine how ties are to be broken or what to do if the most appropriate kind of spot does not exist or is not empty.

 

The editors have many other capabilities I haven’t mentioned. Other airport features such as runway and taxiway signs are easily defined and placed. Apron edge lighting is a matter of clicking down strings of rubber band lines where needed, with properties controlling light spacing and intensity. Exclusion rectangles can be defined to suppress autogen or other objects. Helipads are easily placed and need not be connected to the nodes and links network. Temporary points and guidelines may be laid on the diagram as an aid in getting things oriented just so – those are deleted at the end with a single mouse click, having served their purpose.

 

For those attempting a more ambitious airport project, the editors provide the capability to place an image below the editor image while working with the airport. Something like a Google Earth screenshot or an FAA airport diagram of the airport you’re working with can be laid beneath the editor work area. Transparency controls are adjusted so the underlying image can be seen through the editor working image and pinning and scaling controls allow the image to be indexed to and stretched to the same scale as the editing screen. What results is a template that can be used to easily get the physical layout of runways, taxiways ramps and aprons just right. Our FS world is static, but the real world is not. If a favorite airport has undergone renovation or new construction in the real world, the editors make it quite easy to make its FS alter ego look the same. It’s not exactly child’s play, but isn’t terribly difficult either. There’s much more capability in the editors – many things not mentioned here, but this should be sufficient to give the reader some idea of what can be done and a glimmering of how it’s achieved.

 

During and after editing, the updated airport file must be saved, of course. It’s best not to save to the original file name, which will over-write the stock FS airport. A better way is to “Save As” a different file name in a new folder under the Addon Scenery folder in FS. Airport files have bgl extensions and must be saved in a sub-folder named “scenery”, thusly…

 

 

By visiting the Settings menu in FS and adding that location to the Scenery list at a higher level than the default FS scenery, the new airport will be displayed by FS but the file defining the old one will still be available if ever needed again.

 

The two premier Airport Editors that I know of are the freeware ADE9X by Scruffy Duck Software and the payware AFX by Flight1. Both are capable of working directly with either FS9 or FSX airports. Both work well and are reasonably full-featured. Each has some capabilities the other does not have but overlap in all the vital areas. As a for instance, ADE9X shows building locations, AFX does not. On the other hand, AFX has a better way of displaying taxiway designators. It’s mainly a matter of preference.

 

Welcome to my bog!

 

[mutley 4,488]

:smile:

Super article John, I often wish I had time to explore this to the full.

Cheers

Joe