Airport Objects Tutorial
Jump to
Tutorial Overview
RealFlight G4.5 introduced the ability to import custom-made objects for use in user-created airports. There are several different available object types with specific behaviors. This guide will describe some of the details necessary to get an object to behave as desired.
Among the available object types are:
- Dynamic Scenery Object -- an object that responds to physics.
- Static Scenery Object -- an object that does not respond to physics.
- Projected Scenery Object -- a decal texture on the ground.
- Windmill Object
- Windsock Object
- Roller Coaster Object -- an object that moves along a predefined route.
- Ferris Wheel Object -- an object that rotates about an axis.
Dynamic Scenery Objects
Dynamic Scenery Objects are objects that will respond dynamically to physics. They will fall in response to gravity, blow away in response to wind, and can be moved or knocked over if you fly into them.
There are no special steps required for a Dynamic Scenery Object to function. However, the position of the optional "~CS_CG" frame will be treated as the object's center of gravity. Specifying the center of gravity can be useful when creating objects like buoys, which may need CG information in order to float properly on water.
Static Scenery Objects
Static Scenery Objects are objects that do not respond to physics. They will not fall in response to gravity, cannot be blown away by RealFlight's wind, and will stay firmly put if collided with.
There are no special steps required for a Static Scenery Object to function.
Projected Scenery Objects
Projected Scenery Objects are two-dimensional objects that follow the contour of the terrain. They are essentially decal textures on the ground. You might use a Projected Scenery Object for a runway, a patch of dirt, or a logo displayed on the ground.
The geometry of the model should be a single two-dimensional plane. Make sure it has a texture.
Windmill Objects
Windmill Objects behave like real-life windmills, rotating in response to RealFlight's wind.
A Windmill Object should have three separate frames, each with its own purpose. The first of these components is the base of the windmill, which is stationary. The windmill's base should have its own frame, but does not require a particular name.
The second component is the "pod" or "hub" of the windmill. This component will rotate about the Z axis to face the same direction the wind is blowing. It is also the point at which the blades of the windmill are attached. This frame must be named "~CS_Pod" and should be a child frame of the windmill's base.
The third component of a Windmill Object is the frame representing all of the windmill blades. This frame will rotate about the axis corresponding with the direction in which the pod is facing. This frame should be named "~CS_Blade" and should be a child frame of the windmill's pod.
The overall hierarchy of the windmill should be: WindmillBase --> ~CS_Pod --> ~CS_Blade
Pivots must be set up correctly on both the ~CS_Pod and ~CS_Blade frames in order for them to rotate properly. The ~CS_Blade frame will pivot about its Y axis. The pivot for ~CS_Pod should be set up such that the Y axis is pointed opposite the direction the wind is blowing (i.e. it points into the wind).
Windsock Objects
Windsock Objects behave like real-life windsocks, flapping and flailing about in the direction of the wind.
There are three main components to a Windsock Object model. The first component is the base or pole of the windsock, which is stationary. The windsock's base should have its own frame, but does not require a particular name.
The second component is the rotating ring generally found at the top of the pole, to which the windsock is attached. This component has a purpose and behavior similar to that of the "pod" or "hub" of a Windmill Object, rotating about the Z-axis to face the direction the wind is blowing. This component's frame should be named "~CS_RotatingRing" and should be a child of the base component's frame.
The third component -- actually a set of components -- defines the individual segments of the windsock's fabric mesh. The first segment's frame must be named "~CS_SEG1" and should be a child of "~CS_RotatingRing". All additional segments do not require specific naming conventions aside from starting with "~CS_" (to avoid being merged with the root frame on export). However, each segment must be parented to the previous segment. That is, the second segment of the windsock mesh should be a child of ~CS_SEG1, the third segment should be a child of whatever you name your second segment, and so on.
Roller Coaster Objects
Roller Coaster Objects are objects that continually move around a pre-defined circuit. Some example uses of the Roller Coaster Object type here at Knife Edge Software have included an actual roller coaster as seen at the "Carnival" airport, the bats swarming about the House Of Horrors also at the "Carnival" airport, and the moving train found at the "City Park" airport.
Any stationary parts of the object, such as the track, do not need any specially-named frames.
There should be at least one frame whose name starts with "~CS_CART". You can have more carts by naming additional frames "~CS_CART01", "~CS_CART02", and so on. Each of these frames will contain a moving object that will loop through a circuit as defined by the waypoint frames, which we'll cover in a bit. Each cart frame must also have the following user-defined properties:
- NUP_LapTimeSEC --- This determines how long, in seconds, that it takes for the cart to make one full lap around the waypoints.
- NUP_DelaySEC --- This determines how long, in seconds, that it takes for the cart to begin moving once it has been initialized in RealFlight. This is necessary to get a "chained together" effect with multiple carts, rather than having them all overlapping one another.
There should also be at least four helper frames whose names start with "~CS_WAYPOINT". These determine the course that the carts will follow, in ascending alphabetical/numerical order. You may want to name your frames something like "~CS_WAYPOINT01", "~CS_WAYPOINT02", etc. The "~CS_CART" frames will sequentially move / rotate to each of these waypoint nodes.
Ferris Wheel Objects
Ferris Wheel Objects are objects that constantly rotate on their own. Some example uses of this object type might include an actual ferris wheel, a rotating ring in an obstacle course, or a radar dish.
For a component frame of a Ferris Wheel Object to rotate, it must be given a name starting with "~CS_PIVOT". You can have multiple rotating frames by naming them something like "~CS_PIVOTwheel", "~CS_PIVOTlamp", etc. Every pivoting frame must also have the following user-defined properties:
- NUP_RotationRateXDEGpSEC -- defines the number of degrees about the X axis that this object will rotate every second.
- NUP_RotationRateYDEGpSEC -- defines the number of degrees about the Y axis that this object will rotate every second.
- NUP_RotationRateZDEGpSEC -- defines the number of degrees about the Z axis that this object will rotate every second.