Game Killer/Game_Killer.bin/1027.DESGN2.TXT

Text File | 1991-06-11 | 71KB | 1,368 lines

DESGN2.TXT is a collective effort of many Microsoft Aircraft & Scenery
Designer fans.  Some of the tips were written specifically for this file
while others were culled from messages in the CompuServe FSFORUM message
forums.

We hope that you'll find the following tips and design techniques useful in
your own scenery design.

Contributors:
  Mike Barrs
  David Bartholomew
  Jeff Bingham
  Gary E. Evoniuk
  Jeff Feinsmith
  Hugo Fuegen
  Lee Fortner
  Ken Fugate
  Jeff Horrocks
  Peter James
  Rick Lee
  Chris Manrique
  E.J. Pieker
  Jim Ross
  Don Simmons
  Stamatis Vellis

Edited by:
  Nels Anderson

          =======================================================

SECTIONS:

  1) ASD File Management
  2) Airport Design
  3) Special Effects using SEE
  4) Other Special Effects
  5) Coloring Techniques
  6) Connecting Scenery Files
  7) Design Aids
  8) ASD Usage Tips
  9) Object Placement
  10) Scenery Documentation
  11) Techniques for Individual Scenery Objects
    a) Mountains
    b) Navaids
    c) Lakes
    d) Buildings
  12) Frame Rate Effects

          =======================================================

1) ASD FILE MANAGEMENT

One of the "problems" with ASD scenery is that you can quite quickly collect
too much of it!  There are some tricks that can be used to help and to be
sure that you get the scenery you want loaded.

ASD autoloading is confusing and can also be too slow in some cases.  Here's
how it works:  If you already have an .sc1 file loaded and you're within its
boundaries (as set from the menu) you're fine.  Once you go outside the
boundary, ASD is going to start looking for a new .sc1 to load.  Note the
the boundary is a circle where the center and radius are both controllable.

When ASD starts searching you can run into a couple of problems.  One is a
noticeable pause every 15 seconds or so.  This is caused by the actual
search through your disk for a new .sc1 file.  ASD checks each .sc1 present,
trying to find one who's boundary you're now within.  If you have a slow
disk or lots of .sc1 files the pause can be quite objectionable.  There are
a couple of possible solutions.  One is to keep only the .sc1 files you need
now in your FS4 directory and keep the others elsewhere.  This way, ASD has
to look at many fewer files and the pause is shorter.  Another option is to
use a disk cache, which speeds up all disk accesses.  Disk caches are a
bigger subject than can be discussed in detail here, but might be something
worth looking into.

Another problem you may run into is ASD loading the wrong scenery.  The
usual cause for this is a boundary and/or center point that's set wrong.
In most cases you can fix the problem by making the boundary smaller.  The
default is a 100 mile radius which is much too large for virtually all
scenery.  In many cases you can cut the radius down to 10 miles or less
and still have the file autoload earlier enough.  Center point placement
is more critical the smaller the boundary is, so when you cut down the
boundary radius check the center point and move it if necessary.

                                                       --Nels Anderson

          =======================================================

2) AIRPORT DESIGN

For airport design, you should visit a local pilots shop (FSS, or FBO, at
many airports) and pick up a copy of the "Airport/Facility Directory" and
your area edition of "U.S. Terminal Procedures." These books cost about $2.00
apiece and are definitely a must. They give precise specs for runways (width,
length, types of lighting, field elevations, bearings from various VOR's
etc).

                                                       --David Bartholomew

A. ILS Systems

You will have to have a NOAA (National Oceanic and Atmospheric Admin-
istration) Instrument Approach Plate for the proposed system: these come in
very cheap books for large areas of the country.  Jeppesen-Sanderson also
publishes these, but they're more expensive and harder to get.  For some
samples see the approach plates in the FS manual, and with several of the
scenery disks. Reason for this: you have to know the localizer frequency and
distances for the markers.

1. The usual procedure is to put the ILS at the touchdown marks on the
runway. Of course it should go right between them, and the runway should be
oriented as straight up-and-down as you can manage.

2. You have a choice on glideslope when putting in an ILS. Leave it at 3.0
unless you have information (from an approach plate or otherwise) to the
contrary.

3. Normally we don't use inner markers; these are quite rare in real life.
But we usually have middle markers, at least, and in most cases outer
markers. Again the existence or non-existence of an outer marker can be
determined from approach plates: for example, Martha's Vineyard has an ILS
approach but no outer marker (FS 4.0 manual, p. 157).

4. Placing the middle and outer markers: You have already put in your ILS at
the touchdown marks. Count .1 nm for the distance between said marks and the
threshold of the runway. Now look at the profile in the approach plate, and
back up (slew) until the DME to your ILS (tuned on nav1) is the proper
distance from the threshold, according to the approach plate. Put in the
marker with the ASD editor; same procedure for both middle and outer markers.
Van Nuys has an outer marker, but no LOM (next paragraph here): see approach
plate, FS Manual p. 163 ("KADIE OM").

5. In some airports there is a NDB coinciding with the outer marker: this is
called a LOM. In such instances put in a NDB with the proper frequency at the
same coordinates as the outer marker.  See the approach plate for Champaign,
FS manual p. 152, where the "LOM" (= Veals NDB) is marked; also p. 155.

6. You will see from some IAP's that the frequencies for the ILS systems at
both ends of a runway are the same. Don't worry; stick 'em in. FS can
distinguish them. SD-12 has several of these pairs: Bedford and Boston, for
example.

B. Runway and taxiway lighting

Using Laemming Wheeler's SEE03 (and the EZC module which comes with it), it
is quite easy to give runways and taxiways the proper day/dusk/nite lighting.

With the standard (as supplied) EZC.DAT file, all you do is to draw a "royal
blue" (half way between real dark blue and "Cessna" blue!) line around your
taxiways. Try to draw them as continuous lines, that is, hit "P" for point
and pivot, rather than drawing separate lines: this will improve your file
size and frame rate.  These lines will be invisible in the daytime, and royal
blue dots (lights) at dusk and night, after you run EZC with SEE03.

For runways, I often draw two yellow lines at the edges of the runway. These
become again invisible in the day, and yellow lights at dusk and dark.

Careful: this will affect *all* royal blue and yellow lines, whether they're
at runways and taxiways or not!

If you want to be very precise on exact FAA standards for runway and taxiway
lighting, this is not the whole story. But this is fairly complicated and
will require some further research.
                                                       --Jim Ross

There are two ways to cover up the old runways, both of which use polygons.
One is to lay down the new, presumably more accurate runways and then move
around placing polygons to cover up places where the old ones are not quite
fully covered by the new. This can take quite a few polygons; thus, quite a
bit of your memory, and it's a bit tricky to get the polygons neatly butted
up against the new runway lines. Rick Lee suggested slightly overlapping
polygons onto the runway, saying that when you enter the polygon, it'll "slip
under" the runway.

The other method is the easiest, which is to just build a single large
polygon that covers the entire old airport runways, and then start your new
"construction". I guess the trick there is to make sure of the placement for
your initial "reference" runway, by determining where you're going to put it,
noting the exact coordinates, and then returning to that point after covering
the old scenery. When I did DCA, two of the runways were pretty close to the
"original", so I just used separate smaller polygons to clean up around the
edges. But it DID cost me in frame rate, since I ended up using "dozens" of
polygons to make the taxiways; not to mention a fairly complex set of
terminal and hanger structures. It's borderline--too slow for my 286/12, but
I'm going to try it out on a 386/33 before I start deleting anything to make
it more flyable.

On your point about the night view, I think clearly the "trimming" polygons
are going to be less intrusive on the night view than the larger, all-
inclusive polygon. BTW, I noticed while testing my DCA file at night that
there were several polygons around the general area that also showed up at
night. These were not polygons I had laid down, so it occurred to me that they
might have been "clean-up" additions made by SubLOGIC in the final stages of
SD development, so the problem may not be unique to ASD.

                                                       --Jeff Bingham

I think it is better to create the new runways using the old SD's because all
of the elevations are already correct.  Except for in the featured scenery,
the default FS scenery does not have proper elevations.  For example, the
place where ABQ would be is only 600 ft MSL where in reality it is 5300 ft
MSL.

Replacing the runways in the early scenery disks requires you currently to
place a dark green polygon over the old airport because they are 2X too big.
You must then put the new airport on the polygon.  I say currently because
there is help on the way in this area from third party utilities.

On the newer SD's, you can just place a new runway on top of an old one as it
is already properly sized.
                                                       --E.J. Pieker

          =======================================================

3) SPECIAL EFFECTS USING SEE

Laemming Wheeler's SEE (Special Effects Editor) allows you to add a wide
variety of different effects to ASD scenery that is not normally available.
Included effects are:

       Add dusk/night effects
       Add taxiway and other ground lights (instead of lines)
       Import new scenery objects from optional scenery libraries
       Add ATC messages (including std ATIS with WX)
       Add off-region navaids for electronic navigation continuity
       Patch crossing runways for visual realism
       Recolor polygons and rivers

With the release of SEE03 (version 3) SEE includes and EZC mode (easy SEE)
that allows anyone to get SEE special effects without writing custom
scripts for their scenery.  SEE03 also includes many tutorials on its
available features for those who do want custom effects.

SEE also includes the ability to import custom scenery objects, including
buildings and other objects not including in ASD's normal abilities.
Several libraries of SEE objects are available.

SEE is too big a subject to cover in detail here.  If you want to really
enhance your scenery, just get a copy of it and go to work!

If you're not comfortable writing scripts, you should also look into
SEEPLUS by Joe Lincoln.  This is a menu driven front end for SEE that
allows you to access most SEE features using point and shoot menus.

                                                       --Nels Anderson

Range:

SEE03 can change the range (visibility distance) of any or all objects,
although I understand there are certain limits.

I usually change the range of all of my buildings (Class 9 objects in SEE
terminology) to 60, which is about 7.5 nm. This means that they all come "on"
at the same time, no matter how big they are, and appear about the same time
as the runways, if they are terminal buildings.

To do this you have to write a SEE03 script (range.dat) which reads:

Usual directory/file/library information

report

setrange,9,1,60
setrange,9,2,60
.....
setrange,9,100,60

save
end

Now merely do: SEE03 range.dat

In the above, "9" means object type 9, that is, buildings, and the increasing
numbers are the particular building -- this includes anything you put in with
"ADD BUILDING" in ASD (towers, automobiles, fuel dumps, too).

Or whatever: this would take care of 100 buildings. You can have the number
higher than the actual number of buildings you have in a given file, and
SEE03 will just ignore the irrelevant ones.

Just write that script and merely change the directory/file information for
each use.

Of course you can do this with anything else: if you want to change the range
of roads, use "4" instead of "9"; runways, "6" instead of "9", etc. The docs
for SEE03 have a list of the designations for object types.

You can, of course, just change *some* buildings, not all. But you have to
figure out which buildings are which, and to do this you ordinarily have to
do some fancy calculation with the .rpt file which SEE03 turns out. It is
entirely possible that if you have a lot of densely-packed buildings visible
from a long way away, your frame rate will suffer. Be judicious. Maybe you
will want to put in some buildings, run SEE03/range.dat, and then put in some
more buildings, which will not be affected.

By the way, the range of navigational aids such as VORs can be increased
beyond the default, and you may want to do that if you happen to know that a
given VOR is a HVTAC, which I think means "high" = can tune it from a long
distance, as over against a LVTAC (low = short). But here I tread on thin
ice. SD-12 certainly has some VORs that are thus distinguished: TMU (Groton,
CT) is a TVOR, whatever that means, and is tunable only from quite a short
distance. Others can be tuned from almost 100 nm.

On range distances: one unit = 256 meters, so 80 = about 10 nm, as Laemming
says.
                                                       --Jim Ross

          =======================================================

4) OTHER SPECIAL EFFECTS

In addition to SEE there are a number of other 3rd party software packages
that will enhance your scenery designing.  These include:

  ASDMOVE   (by Steve Wigginton): Moves, exports/imports groups of ASD scenery
            objects.
  FSMOVE    (by Jan Visser & Hans van Whye): Another utility to move scenery
            objects.
  LEVITILT  (by Jim Ross): Levitate and tilt ASD objects that otherwise
            are forced to remain on the ground.
  BOUNDS    (by Jim Ross): Calculates scenery boundaries.
  FSPASD    (by Joe Lincoln): Sets memory sizes.


ASDMOVE - Bulk Scenery Mover:

One drawback when editing ASD scenery is that you can only work with one
scenery object at a time.  This can get real frustrating if you need to move
a bunch of objects, especially when you have things that are made up of
several objects that need to remain aligned properly.

ASDMOVE solves this problem by allowing you to select a group of objects and
move them all at the same time.  It's fairly easy to use, as you do much of
the work in FS4/ASD itself.  You mark the objects you want to move by setting
two corners using radio towers; the radio towers work as opposite corners of
a square.  Then, you use windsocks as "key points".  All the scenery marked
by the radio towers can then be moved, with the key points being used for
placement; the object at the original key point will move to the new key
point and all other objects will remain in their relative positions.

ASDMOVE can also be used to delete groups of objects, save a group of objects
to a file (a .CUT file) than can be imported into other .SC1 files, and
reorder objects in a .SC1 file for easier editing with FS4/ASD.

FSMOVE:

This utility has the same basic purpose as ASDMOVE, namely moving scenery
elements created with ASD.  It does not, however, have some of the extra
features of ASDMOVE.

Moving objects is a three step process: generate a report, tag elements
you want moved, and then move the elements.  The amount of movement is
specified using the standard FS coordinate system.

LEVITILT:

This utility allows you to add some extra special effects to most ASD
objects.  With a few exceptions, you can raise objects above the ground
and also tilt them.  This allows some spectacular effects like roads
that run over mountains, building on mountains, multi-part buildings, etc.

Levitilt will prompt you through the changes you want to make.  The only
previous knowledge you'll need is the object type number and the object
number within its type.  Other available utilities will allow you to
obtain this information.

BOUNDS:

SETBOUND.EXE is a simple utility that allows you to determine the center
point of a series of FS coordinates as well as the radius from that center
point to the most distant of the coordinates.  This is handy for setting
the center bound and radius for ASD scenery correctly.

FSPASD:

One problem many newcomers to ASD have is getting other people's scenery to
load.  Usually the problem is that the memory allocations for the .SC1 and/or
.DY1 files are set too small.  You can change them manually using the FS4/ASD
menus, but FSPASD will automate this for you.

                                                       --Nels Anderson

          =======================================================

5) COLORING TECHNIQUES

Shallow water effect: In coastal and island areas with clear water, you can
add some visual depth to your coastlines by placing a narrow, medium blue
polygon between the dark blue default water color and your land color. Draw
the polygon side that touches the shoreline so that it slightly overlaps the
shoreline, and when drawing the "outside" of the polygon (where it meets the
water), use several different points at slightly different distances from the
shore so it looks natural and isn't a straight line. Use a white polygon
between the two for a white sand beach. This technique has a few
disadvantages; a) you can forget seaplane landings since the water color
isn't the "legal" dark blue (solution - leave a dark blue "deepwater channel"
to the seaplane dock), b) you'll have to use SEE to edit the color for a
realistic nighttime look, and c) your ASD scenery will look weird if it's
based on a scenery disk and that disk isn't loaded first. I think the
realistic look outweighs the disadvantages. When flying over shallow sunlit
water the color is never a uniform blue except for very early and late in the
day. This is especially true in the Caribbean and other tropical areas.

                                                       --Mike Barrs

Thin, meandering rivers can be useful to give a feeling of ground texture.
This is especially handy near airports to give a feeling of movement when
taking off or landing.  In this part of the country (New England) such rivers
are also fairly common in real life.

                                                       --Peter James

The real world as viewed from the air is actually fairly dull looking; many
of the available FS colors are much too bright!  If you're really trying for
realism this is something to consider when choosing colors.  Save the bright
colors for objects you really want to draw attention to.

                                                       --Nels Anderson

          =======================================================

6) CONNECTING SCENERY FILES

One thing that I have done when starting my West Virginia project is to take
a compass (circle drawing type) and draw circles around all the major points
that I want to cover on a state map.  I can adjust the size of the circles to
make them mesh together nicely for just a little bit of overlap.  You need to
do something like this to get a feel for where the centers and boundaries
need to be for your files.  I'm using approximately 20-25 mile radii for most
of the files.
                                                       --Rick Lee

On boundaries: the trouble, of course, is that bounded areas are circular,
and this causes a good many coverage problems. I have found that in some
areas where there is densely-packed scenery, I have to duplicate some
airports on two adjoining files, or perhaps just one object (for example, a
mountain or a section of road). SEE03 has ways of doing this, and much the
same thing can be accomplished with ASDMOVE.
                                                       --Jim Ross

I was drawing 4 and 5nm. circles on my TAC chart looking for the best places
to center scenery areas when it OCCURRED to me that the ILS approaches in FS
extend out for _34 miles_ from the runway. So much for small boundaries and
separate files.  It's all gonna have to be merged into one big file for those
(ILS) airports to work right.
                                                       --Mike Barrs

          =======================================================

7) DESIGN AIDS

I use USGS topographical maps and NOAA Aircraft Sectional Charts for adding
all the details and navaids.

It's great if you can find aerial views of what you are designing.  Postcards
are great for this.  Cheap and readily available.  Many airports sell aerial
view postcards of the airport.  Aerial views of cities are commonly found
wherever postcards are sold.
                                                       --Rick Lee

You can obtain U.S. Geological Survey maps direct from the USGS.  Write to

Distribution Branch
U.S. Geological Survey
Box 25286, Denver Federal Center
Denver, CO 80225

Ask them for the index for the state or states you're interested in.  Once
you have the index you can order the actual maps.  For most ASD design,
you'll want the 7.5 or 15 minute series of maps.

You can also obtain USGS maps at local stores such as sporting goods
stores and stores that deal in civil engineering supplies.  Check your
telephone yellow pages.
                                                       --Nels Anderson

Sectional charts cost about $5.50 (I forget just how much), and those two
books will run you $4.00 total. If there's a TCA chart for your area, get that
too, as it shows more detail. They run $2.75. That's $12.00 or so, but your
scenery will be worth it.
                                                       --David Bartholomew

          =======================================================

8) ASD USAGE TIPS

When placing scenery sometimes the view just doesn't cover enough territory.
Use the slew upwards key and your view gets wider! Voila!

                                                       --Jeff Horrocks

This weirdness concerning the editing of runways also applies to the editing
of ILSs. When you edit an ILS, only the frequency is correct. All the other
values, and in particular Glideslope angle, have been retained from your
*last* ILS edit! There is a trick to find out what glideslope angle has been
specified for the particular ILS you wish to edit: hit the <9> and <8> keys
in succession: the new value is the valid glideslope angle entered for the
runway! I've tried it and it works, don't ask me why.

The same problem applies re ILS "heading": the heading which is displayed is
the heading you had prior to entering the editor, *not* the specified ILS
heading!

Finally, as you've already pointed out, whenever you edit the runway
lighting system you *always* get a "Type: none" indication, regardless.
Also, after you've done any changes to the lights or whatever, but *before*
you save the new entries, re-examine the runway headings and designators!
Especially the designators do not necessarily retain their R/L markings, but
show the settings for the previous runway edited!

                                                       --Stamatis Vellis

          =======================================================

9) OBJECT PLACEMENT

What I've learned in designing Van Nuys and Phoenix, among other scenery, is
to try to lay out the major navaids first. If the subLogic scenery disk is
available and you want to make your scenery compatible with that, or to use
it as the template, great. Find where your VOR's should go. The subLogic
manuals give exact coordinates for theirs. If you don't have any SD's,
either locate yourself in the designer with latitude/longitude turned on, or
triangulate to it from already-made established VOR's. A sectional chart is
essential for this. When you've found the exact spot, plant a building
there, 200'x200'x1500' tall, with bright red and white sides. It'll show up
for miles! Of course, you place your VOR there too.

Now go out (in regular slew mode) along the radial(s) and set your other
checkpoints, again with the supertall buildings. Do this for all the navaids
you need, usually 4 or so for the area. I generally try to design in a radius
of 25 miles or less, but many navaids will be outside this area of course.

Next step is to lay out major roads. Check the sectional chart, as well as
regular road maps. Note where major bends occur. Get bearings to at least 2
VOR's for each of those spots. Then go out and plant more supertall buildings
there. Now begin laying your road. Don't lay down more than 5 miles between
points or the road will twist like a ribbon! I always save each segment
separately, this way they'll appear in a smooth progression as you fly along
the road. Your supertall buildings serve as route markers when laying out the
major roads. They can be removed afterward.

After you have the major roads and VOR's laid out, you should put down
runways. They define the elevation for the area and should be done before
putting in mountains.

After your airports are in place, put in mountains. Limit them to 5 mile
lengths or less, because if you make them too large they're invisible. Lay out
groups of them to make a range of mountains. Keep the different colors to a
minimum, it seems to help the frame rate.

Simplicity works best, I've found. The sectional charts show elevations, and
it may take practice, but you CAN make eerily realistic mountains using them.
Remember, where the lines are close together is a steep slope, so some of your
"peak points" should reference them so you end up with an accurate profile of
the mountain.

This about covers all I can think of for major design. After that, depending
on memory available etc, you can go in and place large buildings (often just a
few will do nicely), lakes, etc. You can also lay out rivers too, as rivers
automatically go under existing roads. Experiment with the width before you
get too far along, or your canal will look like the Mississippi.

                                                       --David Bartholomew

The locked grid feature can be quite useful for laying things down accurately.
The trick is to get the grid locked into the right place.  What I like to do
is get one object placed accurately (the local airport is a good choice) and
then pick virtually any map, whether a USGS map, local street map, or
whatever, just as long as that map has a grid on it.  Determine the grid
spacing on your printed map, use the ASD grid in the unlocked mode to get
it aligned with your printed map and then switch it to locked.  Now, you
can lay down buildings, roads, etc. exactly as they appear on your printed
map.
                                                       --Nels Anderson

To accurately add new objects, start with a known anchor point such as a VOR
already on the default scenery or scenery disk scenery.  I get the distance/
bearing of all the VORs from the anchor point using my Jeppesen ProStar
calculator (what a gem!). I calculate the "True FS North" variation, i.e.
the heading at which the East coordinates remain constant (you can easily
find this heading by experimenting with slewing). I then go to a LOTUS
spreadsheet I've prepared and based on the coordinates of the anchor point,
the "True FS North" variation and the distance/bearing of the missing/
misplaced VOR the spreadsheet calculates the missing/correct VOR's
coordinates in FS format.

I prefer this method to triangulation based on two known VORs, because with
my method you only have to "accept" one point in FS as being correctly
placed, and almost *all* the rest have very accurate placements in relation
to that anchor point. With triangulation, you have to accept that *all* the
VORs used in your triangles are accurately placed. I don't like this
"acceptance" at all, from my experience with the FS world.

Naturally, if an airport is not correctly placed vis-a vis the "anchor"
point, then I usually misplace the VORs very near to that airport and place
them correctly in relation to *that* airport, so that I can exercise the
approach and landing phase with accuracy. Thus, in the end I may end up with
a handful of misplaced VORs but I still feel that the majority of the USA
VORs will have been placed very accurately in relation to the common "anchor"
location.
                                                       --Stamatis Vellis

To find the magnetic deviation on a sectional chart, look for the closest
DASHED purple (ok, so the FAA calls it MAGENTA) line.  There should be
several spaced out on the chart.  Then follow the line until you find the
deviation.  This amount must be added or subtracted to the TRUE heading to
find the magnetic heading.  If the deviation is stated as EAST with an E you
must subtract this amount.  If it is WEST (or W) you must add this amount
(just remember, EAST is "LEAST" and WEST is "BEST").

Just in case you are wondering, there are places in the US which need no
correction (Roughly a line from eastern Wisconsin to the pan handle of
Florida, and this line is called the AGONIC LINE).
                                                       --Lee Fortner

Most of the smaller detail seems to fit in better using the eyeball method
rather than the lat. & long. or grid reference method. At this point in the
design having it look right is perhaps more important than precise and
totally accurate renderings. Of course as with all of the above, these are
methods that I have found successful so far and are by no means the only ways
or best ways of doing the job. After all this is all supposed to be **FUN**
and I can only say that this A&SD utility is about the most enjoyable bit of
software I have run across for a long while.

Keep an eye out for as many maps and references as you can. City maps and
postcards are excellent ways to add to your reference material. Of course
nothing can replace good aviation and nautical publications for accurate
coordinates.
                                                       --Don Simmons

How do you adhere to PROPER Lat/Long? Have you worked out a conversion
formula from FS coords to Lat/Long? If you are using VOR radials for placing
airports and other navaids, how can you be sure that the VORs are properly
placed to begin with?

The reason I'm asking is cause I am trying to achieve accuracy myself...

ANALYSIS:

After spending many hours experimenting I've come to the conclusion that the
best way is to decide upon an "anchor point" in every FS sectional, e.g. the
San Francisco VOR for the San Francisco sectional, take it for granted that
the anchor point is correctly placed (or even "move" it to the correct spot)
and then start placing ALL other VORs etc. in that sectional by calculating
the direct bearing and distance from the anchor point.

I am using Jeppesen's PROSTAR calculator for the bearings/distances, and the
RNAV flight planning program to easily get the correct Lat/Long coords for
every navaid. From the PROSTAR I take the bearing angle with an accuracy of
one thousand of a degree and the distance to one thousand of a mile!

Caution: IN bearing/distance measurement from the anchor point, the exact
cant angle at this anchor point must be included, otherwise you may find
yourself way off!

PROBLEM:

The problem that I face is the known one: what happens when a navaid ends up
positioned in the wrong place relative say to an airport?  Do you change the
navaid's position, or that of the airport? I favor the second option cause at
least for the navaid I'm 100% sure it is correctly placed in relation to the
anchor point, which in turn seems to be correctly placed to begin with.  But
if you change the airport's location to match the VOR's location, what do you
do with the nearby city, roads, lake etc?

SOLUTION:

Make a small SC1 file with the airport you are going to land or take off
from, and place the required navaids correctly IN RELATION TO THAT AIRPORT.

The required navaids for the takeoff/approach won't be many, so you can do
these files within minutes.  Then you use the small files which use the
airport as the anchor point for your take off and approach/landing and the
accurate SECTIONAL.SC1 for the remaining part of your trip. Naturally, when
you switch from an AIRPORT.SC1 to a SECTIONAL.SC1 and vice versa, or even
from a SECTIONAL.SC1 to another SECTIONAL.SC1 file, some corrections
(hopefully slight) will be required to set you back on your previous course.

Another advantage of this method is that since you pick a new anchor point
for *every* sectional, the chances of ending up with a VOR at sea(!) are
minimized: discrepancies don't get so much out of hand within such a
relatively small area.

The triangulation from two VORs procedure sounds perfectly right to me, and
it was the first thing that came to my mind when I was first thinking about
"placements" with ASD.  However it makes a BIG assumption: That the two VORs
you work with have been accurately placed by SubLogic to begin with. As I
have personally come to find, this is not always true.  This problem is
further increased when you use ANOTHER set of VORs for your next object
placement: you assume again that *this pair* too is accurately placed to
begin with, and so on, and so on. In the end, for your method to be accurate
we must assume that almost ALL the Sublogic navaids are correctly placed,
and I'm afraid this is not the case.  Quite a few are unfortunately
mislocated. Some FS Sectionals are better than others in accuracy, but you
must thoroughly check a sample of a few navaids before you proceed with your
method.

That's why I stick to *one* point for the whole sectional. I try to make as
certain as humanly possible that this point is more or less accurately
placed, and if it's not, I place it to what I consider to be the correct
location. Then I base all the placements for the sectional on this ONE point.
This way all items placed will be correct at least in relation to each other,
if not in relation to the underlying FS map. I naturally relocate ALL
navaids, including the existing ones. I don't even bother to check any more
whether they have been correctly placed by Sublogic: most times than not they
are off target.

Naturally, when you "cross" sectional there will be a discrepancy involved,
because it is unlikely that the two anchor points, one for each sectional,
have absolutely accurate positions relative to each other. But the
discrepancy will last just for the crossing: then, all navaids in the next
sectional will again be very accurately placed to one another, and so on.

Regarding the "triangulation" issue, I've always thought of it as "solving"
a triangle, and my method does exactly that. If you consider:

a) the VOR which is my anchor point as the 0,0 spot of the X and Y axis
(point A)

b) the X axis as the North FS coordinates and the Y axis as the East FS
coords, and then

c) draw a line from 0,0 at an angle to the X axis equal to the bearing TO
the item we wish to locate, (important: corrected for cant *and* magnetic
variation) and at a length equal to the distance of that point from the
anchor VOR, the end of that line is where the location of the item in
question should be.

To find the FS coords of that point, you basically solve the formed triangle
ABC
                               X   B
                               |  /|
                               | / |
                               |/  |
             ------------------A---C-------------------Y
                               |
                               |

Where A is your starting VOR (anchor point), B is where your required item
should be placed, AB=distance of required item from anchor VOR, and the angle
XAB is equal to the magnetic heading TO the required item FROM the anchor
VOR, CORRECTED for canting and magvar. When you solve this triangle (very
easy since in effect you know ALL three angles AND one side) AC=required
change in East coords from the East coords of the anchor point, and BC=change
in North coords. QED(?)

To solve the triangle I use a LOTUS Symphony template where I just input only
once the coords of the anchor VOR (only once for each sectional), and the
"correction" angle at that anchor point VOR (i.e. the heading at which the
East coords remain constant at the anchor point location), and then input one
by one the bearing/distances of the items to be placed.  Each time my
spreadsheet comes up with the exact coordinates.

To find the correct bearing/distance for each object, I use a "real life"
flight planning program to get the Lat/Long coords and a Jeppesen PROSTAR
calculator to get the exact bearing/distance, with an accuracy of one
thousand of a degree, and one hundredth of a mile.
                                                       --Stamatis Vellis

My feeling is that, since the LAT/LONG location consistency has some
question, it makes more sense to use VORs to maintain the "integrity" of
your navigation within a given region. You may want to use LAT/LONG to put
in an initial location, if you're creating some location that doesn't
already exist in current scenery files, as I did with Anchorage, Alaska, in
a file I'm working on. But once that was done, I switched to VOR-measured
references, since I can read those radials and calculate those distances
from a sectional chart, and then slew around dropping VORS in their
"appropriate" places.  From there, I plot and triangulate for starting
points for polygons, or locations for roads, bridges, buildings, towers,
etc.

Since I like to use instrument approaches, my experience has been that this
method gives me confidence in the placement of navaids for those approaches.
I cross-check the bearings, radials and distances on the IAP plates for those
areas I'm working on, as I go, and make sure that intersections are where
they're supposed to be, and so on. Maybe I just haven't given the LAT/LONG
method enough of a break in this regard, as you have, but it's working out
for me, using the VOR method, in spite of the VOR placement error. You're
right, that if the error is "consistent", you can use the system and be OK.
Another reason I use the VORs, though, is because of their value in
determining a wide variety of locations for which LAT/LONG coordinates are
simply not available. That way, my consistency factor affects the scenery
placement as well as the airport/navaid placement.
                                                       --Jeff Bingham

I am not sure if this is exactly how it works. I experiment at every
location to find this heading at which the East coords remain constant,
without looking at the cant and MagVar tables. Bear in mind that I'm only
interested in this angle for the anchor point of each sectional, not for
*every* point cause I base all my bearing/distance calculations exclusively
from that point. (That's another advantage of having only one anchor point
in each sectional)

Here comes a sample of my findings:

FS Sectional     Coordinates  Variation/disk

Klamath Falls:    19120.00   -39 sd4
                   5968.00
Houston:          12125.00   -11 sd1
                  13781.45
San Francisco:    17340.00   -37 dflt & sd-sfs, -39 sd3
                   5060.00
Los Angeles:      15371.00   -30 dflt -29 sd3
                   5796.00
Van Nuys          15505.00   -30 dflt
                   5812.96
Phoenix:          14538.00   -27 sd2, -29 dflt
                   7962.51
El Paso:          13427.00   -22 sd2
                   9840.98
Seattle:          21337.00   -44 dflt, -43 sd4
                   6579.00

I have not checked if these figures equal to cant+magvar cause it is a
pointless exercise: scenery disks 1-6 don't quote cant angle.

                                                       --Stamatis Vellis

I don't have to bother *at all* with FS in order to translate the bearing
and distance findings to FS North and East coords! I input them to my LOTUS
template and come up with the exact FS coords where I must put the object.
Then, I switch back to FS and simply use ASD to enter the object at the
known coords. No need to bother with ILSs etc. Everything is done *outside*
FS. So, all your comments regarding your points (1) and (2), although
absolutely correct, do not affect my method. Incidentally, re your point
(2), in my triangle solving formulaes I have calculated that 7.234375 points
in FS = 1nm, which ties perfectly with your estimate of 256m to 1 point!

Now, re your question about cant and magvar: No I don't assume that the cant
of a given point is exactly that printed on the chart, nor do I bother with
magvar either: I simply find the heading at which when slewing forward the
EAST coords remain absolutely constant. That's what we are after. If this
happens to be the sum of cant + magvar, so much the better. Remember that I
only need this angle for *one* point in each sectional (my "anchor" point),
cause I'm basing all bearing/distances for locating all the rest of the
navaids on that point only. Do I do it by trial and error? Thank God, no:

I am using DESQview when doing all this stuff, so that I can switch from one
program to another constantly. Now here comes the nice part: when you are in
SLEW mode in FS and you switch away from the window where FS is loaded, when
you return to it the plane is automatically heading towards the *crucial*
heading we are looking for!!! Why? Don't ask me, but I'm grateful!! No cant
angles involved, no magvar, no trial and error, pure automation!

Now for your final question: how do I apply it? I think I've explained that
in my message where I drew the little diagram. The angle XAB is not just
equal to the magnetic heading FROM the anchor point TO the navaid in
question, it is corrected for this famous angle we just talked about. For
example if I'm solving for a VOR in Houston Sectional, where this angle (how
shall we call it?) equals to -11 deg (349 deg heading), and supposing that
in the real world the magnetic heading FROM the anchor TO the VOR in
question is 90 deg, in my triangle solving template angle XAB is taken as
90+11=101 deg.  This way, when you fly from the anchor point to the VOR you
will be flying along a magnetic heading exactly equal to that depicted in a
Low Altitude or WAC map. Also, the distance of these two points will be
accurate to within half a mile or so.  Now to your final point, re QED: I
never had any Latin in school, but our English math teacher had told us to
write QED at the end when we thought we had proved that a theorem was true.
Thanks for correcting me Jim, but let me pass this exam just once, and I
promise to do better next time -:) -:)
                                                       --Stamatis Vellis

I am using a VOR as a reference in order to arrive by trigonometry, as
opposed to slewing, to the exact FS coords where the navaid in question must
be located. I am not interested in the magvar in particular: only in the
heading at which the EAST coords remain unchanged as you slew forward. I
think I've explained why in my other message to Jim. Why don't I just slew?
Two reasons basically:

   a) because I want accuracy. I calculate bearings to a thousand of a degree
      and distances to a hundredth of a nm while the FS VOR adjusts every TWO
      DEGREES! and DME reads to within a tenth of a nm. If you are solving for
      a point at the other end of the Sectional you can't imagine how wrong
      you can be if you are just half a degree off.

  b)  how would I place navaids which are more than 70 nm away from the
      reference VOR? the VOR/DME will stop reading.
                                                       --Stamatis Vellis

I gradually replace all the sectional VORs, and thus scenery done this way
will be differently placed with ASD scenery done by triangulation. However,

a) I don't do *any* scenery. I'm totally incapable of designing a single
   airport, never mind about more complex structures! I only do the IFR
   part of the SC1 files.

b) I use one anchor point for EVERY SECTIONAL, not one for the whole USA. To
   be honest, I've tried the latter approach, using the IAH VOR in Houston as
   the "center", and the Seattle SEA VOR ended up some 18 nm southwest of it's
   true location! Not terrible considering the distance involved, but totally
   unacceptable for IFR flying. I thus switched to one anchor point for every
   Sectional instead (even better than one per Scenery Disk). This way the
   "scale" is much reduced and hopefully the risk of ending up in the water is
   minimized.

But you are right about the compatibility issue: it may be a problem. One
way to alleviate this is to place the VOR which is closest to the major
airport of your scenery file VERY accurately, use this VOR as the anchor
point and place all the remaining navaids/airports in relation to that
point. Then your scenery file will be both "scenic" AND IFR compatible.
Basically that's what I'm doing with other's scenery files: relocate one
major VOR to its proper location in relation to the main airport of the SC1
file, and then I redo ALL the navaids of that file, which subsequently
becomes my proper Sectional because I keep adding navaids of that Sectional
to that SC1 file.  Examples: Albuquerque, EL Paso, Phoenix, San Antonio and
Houston Sectionals are "based" on the relevant SC1 files that have been
uploaded, by relocating where necessary the VORs closest to these airports
and using them as anchor points.  Then, when you want to add VORs of these
sectionals you add them in these files, always using the same anchor VOR.

Problem: What if you have TWO or more airports done by different people
which airports belong to the same sectional but are not properly located
relative to each other? (e.g. Van Nuys SC1 and the default LAX) Then I guess
you choose the most accurately placed of the airports and base your anchor
VOR for the whole sectional re that airport. As to the other airport(s), you
make a small file, containing just that airport and all the required navaids
for IAPs. So if you want to fly to that airport, you use your main Sectional
SC1 to fly up to say 50 nm from the airport, and then manually switch over
to that airport's SC1, and continue with your approach and landing.

Example: When I just "transit" the Los Angeles area, I use my LAX Sectional
SC1, which is based on the LAX VOR. If I want to land in Van Nuys, I use the
LAX Sectional up to a certain point, and then manually switch to the Van
Nuys SC1, which I've edited extensively re navaids placement, and carry out
my approach and landing. The way I edit the Van Nuys SC1, is just like a
miniature of my Sectionals: one anchor point, all the rest placed in
relation to that. Naturally, there are many things which require attention
in some SC1: delete ILS which don't exist in reality, add others which are
not included by the designers, alter runway headings (up to the point of
messing up the airport scenery), relocate/add navaids required for IAPs,
etc.
                                                       --Stamatis Vellis

          =======================================================

10) SCENERY DOCUMENTATION

This really doesn't come under design, but if you can, encourage people to
write fairly full docs for their files. Not just a description of the scenery
part, but info on airport, *particularly* if they are new to the FS/SubL
world. Coordinates, runway headings, navaids, fixes from nearby VORs, etc.

                                                       --Jim Ross

Scenery documentation should also include system requirements for using the
file, especially things like the background scenery (a scenery disk or the
default scenery) and memory requirements.
                                                       --Nels Anderson

          =======================================================

11) TECHNIQUES FOR INDIVIDUAL SCENERY OBJECTS

A) MOUNTAINS

After some more experimentation it appears that MSL is correct rather than
AGL.  I am putting in the hillside that is next to the runway at Mallory
Airport.  Now that I have a little better control over the mountain maker
the airport looks much more like it does in reality.

By the way.... MSL=Mean Sea Level... AGL=Above Ground Level.

                                                       --Rick Lee

The AGL thing isn't correct because in the ABQ scenery GL is about 5300 ft
so if I wanted Sandia Peak, which is 10,600, I would have to enter 5300 but
that gives you a mountain that is about 600 ft high.  Or if you assume that
it is AGL, then it would have come out over 15,000 ft high.

I think this is how it works.  The peak height is the elevation at that
point in the FS DEFAULT scenery plus the peak height you have selected.  So
if you enter FS without scenery loaded and at the point where you want to
put the mountain, your altimeter reads 500 ft and you want a 5000ft ASL
peak, you would enter 4500 for the Peak height.  In the case of ABQ, if I go
there without loading SD-2, my altimeter reads 600 so 600+5300=5900 and
ground level is 5300 thus I get a 600 ft mountain!

So, I believe that it is AGL to the DEFAULT scenery elevation and SD's are
throwing in the confusion.

I am not 100% certain that this is accurate but it worked perfectly on my ABQ
scenery.
                                                       -E.J. Pieker

Wow! That's pretty confusing.... let me see... to get the proper height of
the mountains, I go to the spot, turn on DEFAULT scenery, check elevation,
place mountains according to AGL.  Turn SD back on and all should be well.

Is that about it?

I had been trying to do this using topographical maps and neither AGL or MSL
seemed exactly right.  MSL was getting closer though.

                                                       -Rick Lee

OK... I did some experimentation last night and it's more complicated than
we thought apparently.  I checked the default altitude and it was exactly
the same as the SD-9 altitude... this is apparently due to the fact that
there is an airport right smack there where I am putting the mountains and
the airport altitude determines the height of the ground level.  The ground
level would change I suppose if I turned off the ASD stuff... it's an ASD
airport there that I put in with an altitude of 800 feet.  I put in the
mountains using MSL and then measured the results by slewing and the results
seem to be perfect.
                                                       --Rick Lee

You know all those weird altitude jumps you get when flying around? The
ground altitude is determined by the altitude of the nearest airport. When
you fly out of one airport area and into another, the altitude jumps. The
altitude of the ground you are sitting on is determined by the nearest
airport.

The altitude of CRW is something like 980... Mallory is 800... you get a
little jump when you fly near Mallory.... I think the ISLAND airport is 600.

                                                       --Rick Lee

The runway altitude that you specify is what the altimeter will read while
the plane is on the ground.  There are problems when there is a ground level
altitude already specified.  In scenery design, we are VERY careful not to
let ground level areas overlap. One of the side effects could be a "jumping"
altimeter.  The needle moves up, and down quickly, as the scenery first sets
one ground level, then another.
                                                       --Chris Manrique

I think I've gotten the hang of designing mountains accurately, to the point
where they seem to resemble the real item being done.

The main point is that you need to use as many base points and peak points as
you can, and cut back on the number of different colors for best effect. You
should also use a USGS topo map, or the FAA sectionals, or TCA maps, which
show contour lines and actual elevations.

The mountain base elevation seems to be dependent on the local elevation of
the nearest airport. So it looks like you should plant some runways and
specify actual elevation on them. Then it appears that local mountains and
hills bases will be at nearly the right level.

The actual layout of the mountain is similar to doing a line. If you like, try
this: think of doing a line that bends around, using only three points (the
two endpoints and one somewhere in the middle). Notice that you can only get a
crude approximation of the profile of something that way, but if you increase
it to 5 or more, your profile looks more accurate. When setting peaks, set the
altitude carefully, and place the peak where you need it. Also put in as a
peak a dip in the range, like a pass or saddle. If there's a steep escarpment
on the side of a mountain, put peaks of appropriate elevations closer together
there so you get an accurate profile.

As for coloring, there's some internal logic that determines the coloring
scheme and pattern which I don't know how to decipher. I generally cut it
back to one or two colors, and then toggle others on and off until I get the
effect I want. This is done after I've set the peaks and base points. By the
way, you can set more base points after setting peaks, and jump back and
forth. There's some upper limit of points per mountain but I'd have to look
that up.
                                                       --David Bartholomew

                ** Seminar in the Theory of Mountain Design **

Here's the "theory" behind mountain design.  I'm not sure I could give a
very good tutorial on mountain design without explaining the theory, so if
you can understand this stuff, you'll have a big jump on understanding
mountain design.

First of all, other than the control you have of selecting your color
palette for the mountain, you have no control over which surface gets which
color.  We really wanted to provide more control, but it would have been a
pretty big system to write.  The way it works is, based on your ground and
peak points, a number of triangular surfaces are created to model the
mountain.  These surfaces are colored in the order they are generated, by
selecting colors in order from the selected color palette.  It would have
been nice to select the color based on the orientation of the surface,
essentially light-source shading, but with only 16 colors, what that would
have meant was a fairly large collection of adjacent surfaces would have the
same color, and you would have little depth cue, or even shape cue to the
mountain.  With 256 colors, we could have done a good job of this type of
rendering, but nobody seems to use this driver (for good reasons; too slow
and chunky).

Now, about how the mountain is triangulated.  It's been awhile since I wrote
it, but I believe it works like this:

   (1)  Connect all ground points in order of generation, from first to last,
        then connecting the last one back to the first to get a closed loop.
        Store those edges in a list.

   (2)  Connect peak points as specified by user.  Connect in order as for
        ground points.

   Now, we have two lists of connections, a closed polygon for ground points
   and a line, possibly with a couple small loops, for peak points.  Now we
   must begin connecting ground points to peak points.

   (3)  Now, for all pairs of ground points which have an edge connection
        between them, find the nearest peak point to which they both can be
        connected without intersecting an existing edge.  Note that such a
        point WILL NOT ALWAYS EXIST.  In such extreme cases, you won't get a
        fully generated mountain range.  Form these two new edges, and note
        that you have created at least one triangle, consisting of two ground
        points and one peak point.

   (4)  Now, for all peak points see if there is a ground point to which it
        may be connected without intersecting an existing edge.  If so, form
        the edge.

   (5)  For all peak points, see if there is a peak point to which it may be
        connected without intersecting an existing edge.  If so, form the
        edge.

   (6)  Now you have a bunch of edges.  Scan this list of edges and form the
        triangles they define.  Color them and generate database info.

   (7)  You are done.  Take a nap.

Now, there are some problems with this algorithm:

If you generate a set of ground points or peak points which, when connected
in the order of generation intersects itself, some necessary surfaces will
not get generated.  I hope this is clearly indicated in the manual.
Remember:

        * Do not generate peak or ground lines which intersect themselves *

If you have several points which nearly fall on a line, the algorithm can
get confused due to mathematical overflow or underflow.  Some necessary
edges might not get generated (causing a hole in the mountain), or some
redundant, intersecting edges might get generated (causing overlapping
surfaces).

There seems to be another bug which sometimes creates a mountain with a
missing face, which I haven't been able to figure out.

If you really want to understand what is going on, I suggest you get a sheet
of paper, draw a ground outline, draw a peak line and try to figure out how
the program will "connect the dots."  For the simple cases, you should be
able to get it right.  For the harder ones, it's possible you or the program
will make a mistake.  Remember, in step (3), the program connects to the
nearest point, so if your drawing isn't precise, you will perhaps come up
with a different mountain.
                                                       --Hugo Fuegen

I have often noticed the bug where a surface of a mountain doesn't get
generated.  My solution to this, is to place another peak very close to the
peak point that generated the non-surface and to place it in the non-surface
region (if that makes sense).  This usually overcomes the transparent
mountain surface problem.
                                                       --E.J. Peiker

B) NAVAIDS

It's my understanding that VOR's will not remain where you put them because
they place themselves at some sort of FS internal grid boundary.  If I recall
correctly, that means 30 meter accuracy.  However, if you use ILS's instead,
they will remain where you put them.

In order to get as much accuracy as possible on my scenery design for the
Alexandria, VA area, I use ILS's as temporary markers exclusively.

You may note that if you _move_ a VOR, it will remain at its new location;
however, from my experience it starts acting like an ILS.

                                                       --Jeff Feinsmith

If you'd like another technical explanation... The command in logol for
VOR's and ILS's are identical.  Internally, FS decides that the navaid is a
VOR if the low words of it's location are zero.  If the low words are
non-zero, then FS will assume it is an ILS.  (For example, a vor placed at
16384N,20000E is a VOR; a vor placed at 16384.3904N,20000.2312E is an ILS.)
There is additional code involved, as both the Glideslope, and the Direction
must be specified.  FS4.0 introduced a new logol command that is ALWAYS an
ILS, and includes GS, and DIR.  3.0 and earlier have glideslope, and
direction picked up from a set of variables.

If you are really interested, in FS3.0 and earlier, VORs took 7 bytes, ILS's
would take 13 bytes (extra 6 for GS, and DIR). In FS4 VOR's take 7 bytes
still, and ILS's take 11 bytes.
                                                       --Chris Manrique

What you say in your message re localizer placement must obviously be 100%
correct. However, in the FS world we cannot place the Localizer antenna at a
different location than the Glideslope antenna. Thus if you place your ILS
1,000 feet beyond the far end of the runway in question, the glideslope will
guide you to land 1,000 feet *beyond* the end of your runway! I think we are
better off placing the ILSs at the near end touchdown markers of the runway.
This way, following the ILS needles will (hopefully) get us down right were
we hoped to land.

The glideslope angle is usually 3.00 deg, but not *always*.  It is better to
look it up at the appropriate IAP book.  If you place the ILS at the
touchdown markers, it is fairly easy to follow the IAP distances for placing
the various markers using the ILS DME readout: you usually add 0.1 nm to the
IAP distances, because the touchdown markers are approx. 1,000' from the
edge of the runway and 1,000 feet = 0.16 nm.
                                                       --Stamatis Vellis

The first thing to remember is that LDAs sometimes are called "handrails",
meaning they usually take you down one side of the approach. They are like a
localizer without a glide slope, but the transmitter is offset from the end
of the runway.  Usually, it is short and to one side and it may be at a
significant angle to the final approach path.

You can get detailed information from both the Terminal Procedures and the
Airport/Facilities Directory, and you may need both.  The IAP plate for the
LDA approach should show the location of the transmitter in its plan view.
You will see a turn to final heading indicated, and there may be special
instructions. The A/FD usually shows the Lat/Long coordinates of the navaid,
but this is good only if all other details, like runway, OM, MM, NDB, etc.,
are precisely located.

I have used the following procedure:

1) Locate the navaid (ILS) visually using the IAP plan view and measuring
distances from the end of runway.  Set the glideslope to 0 degrees and the
heading as shown in the IAP.

2) "Fly" the approach in reverse using slew with the ILS/LDA set up on OBI1,
setting MM, OM, LOM, NDB as you come to them.  I also put in little buildings
where these are to be set before I set the navaid. This seems to get things
lined up.
                                                       --Ken Fugate

C) LAKES

One method of working around the placement of polygons is to do the outline
with "lines" first. Do the first draft in one color and subsequent revisions
of the total shape or portion of the shape in other colors. When the shape is
eventually as required simply place your polygon references by slewing around
the appropriate revision lines. Once you are well and truly satisfied with
the results, erase the "lines".

I always orient the grid facing due north (000) before I start slewing from
one reference point to the next. This certainly makes the transition from one
spot to the next much easier. I get my reference points from WAC, SEC, and
Terminal charts.

Of course there must be better ways of doing this, but, this is what works
for me.
                                                       --Don Simmons

It's probably faster to drop a tower at each triangulation point than to
hassle with writing down and punching in coordinates. The towers will still
be visible when you slew upwards to see the whole thing, and then you can go
back and erase them after you've drawn the polygon.

There is a faster way - it's less accurate than triangulating each point but
much easier.  Place a tower at some central reference point you've located
by triangulation, with a heading of 0.00. Go to the Design Preferences menu
and set the grid size to something that's scaled to the map you're using for
reference. I use 528 feet (1/10 mile) for small stuff and 2640 feet (1/2
mile) for larger areas. For geographic features your grid would need to be
really large.  Set the grid to Move with Object, which will center the grid
on your tower, and then set it to Locked.

Now you can draw "freehand" while checking your map. For example your next
point might be 3 miles east and 2 miles north of the reference point on the
map, so you just count grid blocks - one and a half to right, and up one
(using the 2640 feet grid), then place your point. The mouse works really
well for this.
                                                       --Mike Barrs

More tricks I use to get a look at things that don't show well in the design
window:

Set spot plane view to 2000 feet or more. Use <ScrollLock><keypad 5> to look
down on the plane/scenery.

When placing/coloring a short tree or small bridge, slew downwards to see
closer to the ground. (F10 on left function keyboards, and F1 on top.)

                                                       --Jeff Horrocks

To place the grid where I want it, I go into edit mode (1,J,1,J), tab to a
reference object, hit 6 so the view is oriented the same as the object, then
Esc back to the (1,J,1) menu.  Then I go to Design Preferences where I set
the grid to "Move with Object" or "Move with View" so it snaps in place,
then I lock it.

It would be real handy to have a keyboard macro to do stuff like this but I
don't know if any ProKey type programs are compatible with FS.

                                                       --Mike Barrs

D) BUILDINGS

[Re: combining buildings to form a stadium]: I tried a few other things
first looking for wedge shapes, but ended up using an optical illusion. The
stadium ring is 7 rectangular flat roof buildings butted end to end to form
the ring shape with an open end. The ends where the buildings join together
and overlap are the same color as the outside vertical surface (light gray)
so you don't get bleed-through from the outside.  There's a little bleed
through from the top, but those lines could be explained away as aisles
through the bleachers.

The main trick is coloring the "inside" edge of the ring of buildings the
same as the top surface.  You don't see the edge where the two surfaces join
so your eye is fooled into believing that you're seeing a single plane that
slopes from the high outside edge to the ground near the field.  It works
'cause your brain "knows" what a stadium is supposed to look like.

                                                       --Mike Barrs

A little thing on combining buildings: Doors. Make a rectangular flat roofed
building the proper width and height for your door but *very* short (just
hit 0 for length). Make the side which will show outside as the door the
color you want; all other sides the color of the sides of the building they
will face. Roof a bright contrasting color to that of your building (for
placement). Jockey the door around so that the colored side just peeps out
from the building; get it properly oriented, *then* change the roof color to
that of your building, and stick 'er in.

Windows. Start with a door as above, but this time color it blue. Now do
another door, but shorter so that it occupies the space between the ground
and the bottom of the window. This one the color of the side of the
building.

You can use similar techniques to get the effect of columns on a building.
You have to be fairly judicious here. Each of these is a separate object and
will affect your frame rate.
                                                       --Jim Ross

          =======================================================

12) FRAME RATE EFFECTS

I think the frame rate is dependent on the number of static objects on the
screen and the total number of dynamic objects in the entire DY1 file since
FS needs to keep track of their whereabouts.
                                                       --E.J. Peiker

The frame rate *is* affected by all the objects in the file to some extent.
What is currently *visible* has even more effect on top of that.  How large
the objects visible are has an effect too.  If you put in some new objects
the frame rate will slow somewhat even though those objects may not be
visible currently.  Flying up close to a bunch of polygons has a very
noticable effect.
                                                       --Rick Lee

When we are designing scenery within scenery disks, we will optimize the 2d
and 3d objects for speed.  (By doing things like giving a rougher view of an
object from a distance, and in some cases giving a 2d view of a 3d object
to decrease the amount of processor work for a far off object.).

In many cases, it's best to just work with the existing scenery, and put in
your new stuff around it.  Painting out ground scenery does lead to problems
however, as what you are actually doing within the simulation, is drawing
the old scenery, painting over it with green, then drawing new scenery, so
in effect you are painting that portion of the screen 3 times to see it
once.  The closer you are to an object, the greater the time it will take
for a screen fill, so the greater the frame rate hit you will take.

The worst effect of this is a dramatically slower frame rate at an airport
on final approach.  It's something you, as a designer, will have to look at
and determine what is and is not acceptable to you.
                                                       --Chris Manrique

An elementary observation perhaps, but lots of buildings in the field of
view really drags the frame rate down.  Two good examples, the excellent
Hanscom file and some of the Boston-Logan files.  In designing, it's
important to keep in mind the tradeoffs: super accurate building placements
are fun to create and can do an amazingly good job of recreating a
"snapshot" aerial view of your favorite area.  Once you get down to flying
however, these types of files really slow down the frame rate when the
buildings are in view, and may detract from the overall flying experience.

                                                       --Gary E. Evoniuk