
FS4/ASD .SC1 FILE RECORD TYPES

Well, I should have started this a long time ago, I hope I don't forget
anything

These are the collected FS4 notes and rambling by Dan Samuel as brought
about by many long nights of staring at FS4 ASD SC1 files.

This file is ordered by hex record types, not by objects.  Objects are
collections of records.  This is an attempt to generate a description
of 'all' record types.  The complete contents of most records will not
be dealt with here, only those parts which were of immediate concern to
me in my research.


NUMBERS

Most of the numbers shown here are hexadecimal, without the 'h' suffix
always being shown.  the main exception is in the case of offsets within
a record which are shown in decimal.  For example

     25h  record type

     1,2: the two bytes at offsets 1 and 2 in the record form a 16 bit number
	  where the first byte is the least significant byte.
     3,4: the bytes at offset 3 and 4 form another 16 bit number.

	  offset 0 is the record ID itself (25h in this case)

     For example, the record:  25 AA BB CC DD

       0: = 8 bit record ID, 25h
     1,2: = 16 bit number, BBAAh
     3,4: = 16 bit number, DDCCh


COORDINATE SYSTEM

Just to recap, there are 3 forms of coordinates used in records:

     4 byte absolute   AA BB CC DD

     Pick up all four bytes and do an unsigned addition of 0xC0 to the
     most significant byte (offset 3).	The result 32 bit number is in
     the units 1/256th of a meter. Use (unsigned long) as data type

	       i.e.  FS world coord   DDCCBBAA
				   +  C0000000	   (unsigned addition)
				   -----------
				   =  positive number of 1/256ths of a meter
				      from the origin of the universe.

     2 byte absolute   CC DD

     Pick up both bytes and do an unsigned addition of 0xC0 to the most
     signficant byte (offset 1).  The result 16 bit number is in the
     units 256 meters (identical to the MSB two bytes of the 4 byte abs.)
     use (unsigned int) as data type, or convert to (unsigned long) and
     pad LSB bytes with 0.

	       i.e.  FS World coord    DDCC0000
				    +  C0000000
				    -----------
				    =  1/256ths of a meter

	       or, if you REALLY need low res values:

				       DDCC
				    +  C000
				    -------
				    =  positive # of 256-meter units from
				       origin of universe

     2 byte relative   BB CC

     pick up 2 bytes (no 0xC0 crap) and treat as 16 bit 2s complement
     signed number of meters.  To compute absolute coord of a relative
     point, be sure to align on the proper units boundary

	  internal unsigned long center coord:	DD CC BB AA  (1/256th meters)
	+ signed int relative coord		xx CC BB 00  (meters)
					      -------------
     where xx is the sign extension of the CC byte of the relative coord.

Be sure to only worry about the 0xC0 high byte correction when initially
picking up a 2 or 4 byte coord value.  Convert it immediately and do all your
math in the clean number space.  You can then reconvert just before saving the
value.	For example:

unsigned long GetCoord4(int off)
     {
     unsigned long temp;
     int i;

     temp = 0;
     for ( i=0; i<4; i++ )
	  {
	  temp <<= 8;
	  temp |= GetByte(off+i);
	  }
     return (temp + (unsigned long) 0xC0000000);
     }

void PutCoord4(int off, unsigned long val)
     {
     int i;

     val -= (unsigned long) 0xC0000000;
     for ( i=0; i<4; i++ )
	  {
	  PutByte(off+i, (unsigned char) (val & 0xFF));
	  val >>= 8;
	  }
     }

For ASDROT, I pick up all numbers at their maximum resolution and immediately
convert them to double floating point numbers in 1/256th meter resolution.


PARSING OBJECTS

I think everyone has seen the header region of an SC1 file and the pointers
to the nine object classes.  (roads, runways, rivers, etc.)  Objects of the
same type are stored sequentially and the AREA record of each object contains
the distance to the next object in the class.  The final object in a class
points to a 79h record, which ends the list.

Given a pointer to the start of an object, the following state machine will
step through all the various records in the object:

The following assumes the scenery is maintained in memory in the array sc[]
and the variable 'off' is the current offset within that array.

void ParseRecords(unsigned int off)
     {
     unsigned int end;
     end = off + GetInt(off+1);      ; pick up 2 byte # at sc[off+1], sc[off+2]
     while ( (off < end) && (sc[0ff] != 0x79) )
	  {
	  switch ( sc[off] )	     ; first byte is record ID
	       {
	       case 0x25:     // 25h record
		    <handle 25h record>
		    off += sizeOf25Record;
		    break;
	       case ... :
		    <handle ...>
		    off += sizeof...
		    break;
	       default:
		    <report new record type encountered>
		    break;
	       }
	  }
     }

Which records need to be dealt with and which can be ignored is left up
to your utility to decide.  Do not depend on records occuring in a fixed
order or at fixed offsets within an object.


----------------------
RECORD TYPES, IN ORDER
----------------------

It seems likely that the most significant bit of a record type is completely
unimportant and no perceived differences seem to exist between two record
types which vary only in that bit.  However, this remains a mystery, so
records are listed here only in the forms I have encountered.


---- 00h record ---------------------

     00 00 00 24 00 00 00

     7 bytes
     seems to be SEE extension

---- 01h ----------------------------

     01 00 00 00 00 00 00

     7 bytes
     seems to be SEE extension

---- 02h ----------------------------

     02 00 00 23 00 00 00

     7 bytes
     seems to be SEE extension

---- 03h ----------------------------

     2 bytes

---- 05h ----------------------------

     05 AA BB ee ee ee ee nn nn nn nn

     11 bytes
     NDB record
     1,2:      Radio Frequency = BBAA KHz  (BBAA is BCD)
     3,4,5,6:  East Coord
     7,8,9,10: North Coord

---- 0Bh/8Bh ------------------------

     0B LL HH xx yy

     3, 5 or HHLL bytes
     Skip marker, used by SEE to force ASD to not process display commands
     held 'inside' the skip region.

     This is an UNCONDITIONAL skip command and ASD ALWAYS skips forward
     HHLL bytes while processing the display list.  However, utilities
     should only skip the record size itself (3 bytes) so as to be sure
     to parse all possible records which might need to be analyzed.

     If HHLL = 5, then xx yy are some form of object marker (SEE library
     objects, for example).

  SEE-modified #4352 : 0B 05 00 52 43 23     ; polygon, river
  SEE-modified #4C52 : 0B 05 00 52 4C 23     ; road
  SEE-modified #434C : 0B 05 00 4C 43 23     ; line
      Variable Record: 0B 0C 00 4E 49 54 45 0B 05 00 42 43 0E ; building
      Variable Record: 0B 0C 00 4E 49 54 45 0B 05 00 42 43 8E ; building
  SEE hides  23 bytes: 0B 17 00 23 0F 00
      Variable Record: 0B 0C 00 4E 49 54 45 0B 05 00 42 43 8E
      Variable Struct: 0E 08 00 0B 2C 00 1D 00

  SEE hides  50 bytes: 0B 32 00 8E 08 00
      Variable Struct: 8E 08 00 0B 2C 00 1B 00

  SEE hides  54 bytes: 0B 36 00 8E 08 00
      Variable Struct: 8E 08 00 0B 30 00 03 00

  SEE-modified #4350 : 0B 05 00 50 43 23

---- 0Eh/8Eh ------------------------

     0E LL HH

     HHLL bytes long  0006 or 0008
     Skip marker used by SEE to hide subsequent records
     This is an UNCONDITIONAL skip which is used to skip OVER 0Bh skip
     records. (skipping the skip, as it were).

     Utilities can safely skip forward HHLL bytes without worrying
     about missing important records.

     If HHLL = 0006, then it only skips the following 0Bh record
     If HHLL = 0008, it also skips a 2 byte signature.

---- 12h ----------------------------

     12 cc

     2 bytes
     Sets color of subsequent lines drawn

	 0  BLACK	  8  BROWN
	 1  DK. GREEN	  9  YELLOW
	 2  DK. BLUE	  A  DK. GREY
	 3  DK. CYAN	  B  LT. GREEN
	 4  ORANGE	  C  RED
	 5  LT. GREY	  D  GOLD
	 6  LT. BLUE	  E  XPARENT?
	 7  CYAN	  F  WHITE

     the 25h record, with appropriate argument, controls the colors used
     for area filling polygons.

---- 15h ----------------------------

     15  09 00	09 00  09 00  00 00 00 00 00 00 10 00 19
     15  09 00	09 00  HH HH  ee ee  zz zz  nn nn  10 00  19

     16 bytes long
     seems to be SEE extension
     contains heading/pitch/bank info and a delta point

     5,6: heading, 10000h = 360 degrees
     7,8: delta east
     9,10: altitude
     11,12: delta north

     delta point is used in 58h text records.

---- 16h ----------------------------

     16  00 00	00 00  40 0C  0A 00
     16  00 00	00 00  8D 38  0A 00

     9 bytes long
     orientation record

     1,2:
     3,4:
     5,6: heading, 10000h = 360 degrees
     7,8:

---- 17h -----------------------------

     1 byte long

---- 19h -----------------------------

     1 byte long
     Often used to mark end of record

---- 1Dh -----------------------------

     1D 10 11 00 00 49 12 00 00 8B 02

     11 bytes long
     VOR record

     3,4,5,6: East coord
     7,8,9,10: North coord

---- 1Fh -----------------------------

     1F LL HH .. .. ..

     3 bytes
     HHLL contains a branch offset.  A group of 1F records is generally
     preceded by a 20h record.

---- 20h -----------------------------

     20  LL HH	AA BB  CC DD  EE FF
     20  16 00	9E 02  AA 00  FF 7F

     9 bytes
     Conditional Branch
     Skips HHLL bytes if variable at BBAA tests some way in relation
     to DDCC and FFEE.

     FFEE is often 7FFFh

	SEE Extension: 20 16 00 9E 02 AA 00 FF 7F 1F
	SEE Skip Mark: 1F 1A 00 1F DE 00 1F EB 00 1F C3 01 17 1F BF 01
		       1F E1 00 1F CE 00 1F 04 00 17 20
	SEE Extension: 20 35 00 9C 02 00 00 FF 7F 20
	SEE Extension: 20 1C 00 A0 02 00 00 FF 7F 1F
	SEE Skip Mark: 1F 99 00 1F A4 00 1F 49 00 1F 82 00 1F 71 00 1F
		       B9 01 17 1F 94 00 1F 67 00 1F 36 00 1F 6F 00 1F
		       7A 00 17 20 1C 00 A0 02 00 00 FF 7F 1F 6D 00 1F
		       5C 00 1F 1D 00 1F 72 00 1F 45 00 1F 8D 01 17 1F
		       4C 00 1F 3B 00 1F 0A 00 1F 5F 00 1F 4E 00 17 25
		       E2 02 0E 00 2F 32 02 33 03 33 0B 33 0A 29 2F 32
		       04 33 05 33 0C 33 0B 29 2F 32 06 33 07 33 09 33
		       0C 29 2F 32 08 33 01 33 0A 33 09 29 17 25 E2 02
		       03 00 2F 32 01 33 02 33 0A 29 17 25 E2 02 03 00
		       2F 32 03 33 04 33 0B 29 17 25

	SEE Extension: 20 32 00 9C 02 00 00 FF 7F 20
	SEE Extension: 20 19 00 A0 02 00 00 FF 7F 1F
	SEE Skip Mark: 1F 67 00 1F 52 00 1F 6A 00 1F 43 00 1F 52 00 17
		       1F 45 00 1F 4B 00 1F 5A 00 1F 33 00 1F 4B 00 17
		       20 1C 00 A0 02 00 00 FF 7F 1F 3E 00 1F 20 00 1F
		       41 00 1F 23 00 1F 29 00 1F B9 00 17 1F 10 00 1F
		       1F 00 1F 2E 00 1F 10 00 1F 1F 00 17 12 0A 32 2B
		       33 0B 33 2C 17 12 0A 32 2F 33 09 33 30 17 12 0A
		       32 29 33 0A 33 2A 17 12

	5 byte Record: COLOR = DK. GREY  25 E2 02 0A 00
  SEE hides  10 bytes: 23 0A 00 8C 02 01 00 0B
  SEE hides  36 bytes: 0B 24 00 25 E2 02
	5 byte Record: COLOR = RED	 25 E2 02 0C 00
	SEE Extension: 20 0E 00 9C 02 00 00 FF 7F 25
	5 byte Record: COLOR = LT. GREEN 25 E2 02 0B 00
	SEE Extension: 20 0E 00 9C 02 D8 FF 28 00 25
	5 byte Record: COLOR = YELLOW	 25 E2 02 09 00
	1 byte marker: 2F

	SEE Extension: 20 0B 00 9C 02 00 00 FF 7F 12
	   line color: COLOR = LT. GREEN 12 0B
    ??	7 byte marker: 00 00 00 24 00 00 00
	1 byte marker: 19
	1 byte marker: 17
---- 21h -----------------------------

     21 LL HH ....

     HHLL bytes long

---- 22h -----------------------------

     3 bytes
     marks end of mountain point list

---- 23h -----------------------------

     23 LL HH aa bb cc dd

     HHLL bytes (7 minimum)
     SEE skip marker to hide subsequent information.
     based on time of day, does skip

	    23	0F 00  8C 02  04 00   ; if night, step, else skip
	      25  night color
	      0B  go L:
	    23	0F 00  8C 02  02 00   ; if day, step, else skip
	      25  day color
	      0b  go L:
	    25	dusk color
	L:  continue

     I'll bet this REALLY means: If FS4 parameter 028C == 0004 then step
     i.e. SKIP IF NOT EQUAL.

     this record is also used by divided hiways to change line colors
     when 28c = 6

  SEE hides   8 bytes: 23 08 00 4E 03 FF FF 19
	1 byte marker: 19

---- 24h -----------------------------

     24 04  00 AE CF 11  00 00 00 00  00 29 8D 02

     14 bytes
     specifies local center point of object (for subsequent rel. pts)
     2,3,4,5: East Coord
     10,11,12,13: North Coord

---- 25h -----------------------------

     25 LL HH bb aa

     5 bytes
     sets parameter HHLL to value aabb

     Parameters:

     HHLL      Meaning
     02E2      - surface color (usually repeated in all 4 nybbles)
     02EF      - altitude in meters above sea level
     02F6      - set to one for inner marker
     02F8      - set to one for outer marker
     02FA      - set to one for middle marker
     031E      - set to zero before defining mountain range info
		 set to one before defining mountain side info

     Other maybe parms:

     028C      - 4=night, 2=day, 6=time to make lines lt gray on div. hiway
     0312      - SEE sets to 1 before 20h, 1Fh record list

---- 28h -----------------------------

     ??? 8 bytes

---- 29h -----------------------------

     1 bytes
     Marks end of polygon point list.  DRAW back to start and close poly

---- 2Ah -----------------------------

     2A  B6 E3 00 00 58 B5  23 F9 00 00 D2 D6  12

     14 bytes
     2 relative DELTA points, in a single record.  Used a lot by SEE
     1,2  : East 1
     3,4  :
     5,6  : North 1
     7,8  : East 2
     9,10 :
     11,12: North 2
     13   :

---- 2Fh -----------------------------

     1 byte
     Marks start of Path list for polygon

---- 31h -----------------------------

     31  pp  ee ee  zz zz  nn nn

     8 bytes
     Defines numbered vertex for subsequent 32, 33, and triangle records.
     1	: vertex pp (#00-1F for mountain peaks, #20-?? for base points)
     2,3: East offset from current CENTER (signed meters)
     4,5: Altitude from current CENTER (meters???)
     6,7: North offset

---- 32h -----------------------------

     32 pp

     2 bytes
     MOVE PEN (w/o drawing) to vertex pp (from vertices created by 31 records)
     Used in SEE library objects

---- 33h -----------------------------

     33 pp

     2 bytes
     DRAW TO VERTEX pp command (using numbered 31h record vertices)

---- 35h -----------------------------

     2 bytes

---- 3Eh -----------------------------

     3E  LL HH	17 02  D9 11  7D 00

     9 bytes (HHLL indicates size of object description)
     AREA Record.  Gives low precision (256 meter) center of object and
     max visible distance.  ASD presumably doesn't bother drawing object
     if it fails this test.  All records begin with an area record, but
     may include additional area records.

     1,2: size of object desciption (all records)
     3,4: north coord (256Meter resolution) of object center
     5,6: east coord
     7,8: max visible distance (256 meter)

---- 40h/C0h -------------------------

     40  ee ee	nn nn

     5 bytes
     MOVE PEN (no ink) command for drawing 2D polygons.  nnnn and eeee are
     signed relative offsets (in meters) from current CENTER (24h) record.
     polygon may be tilted in space via previous 16h record.
     1,2: East offset (signed meters)
     3,4: North offset

---- 41h -----------------------------

     41  ee ee	nn nn

     5 bytes
     DRAW TO NEXT POINT command (see 40h)
     1,2: East offset (signed meters)
     3,4: North offset

---- 43h -----------------------------

     1 byte
     ???

---- 4Ch -----------------------------

     2 bytes

---- 4Dh -----------------------------

     4D LL HH ...

     HHLL bytes long

---- 4Eh -----------------------------

     4 bytes

---- 4Fh -----------------------------

     15 bytes
     ILS description record
     3,4,5,6: East Coord
     7,8,9,10: North Coord
     11,12:   Heading 10000h = 360 degrees

---- 50h/D0h -------------------------

     35 bytes
     Runway description

---- 51h -----------------------------

     1 byte
     Marks end of mountain triangle list

---- 52h -----------------------------

     2 bytes

---- 53h -----------------------------

     ??? bytes
     Building/wall list
     extremely variable length

---- 58h -----------------------------

     58  00 00 00 02 00 03 00  SS SS  <text> 00 17

     43 bytes
     SEE uses this to make TEXT appear in 3 space.
     8,9: SS SS  Size of characters
     10- : ASCII text, padded with spaces, ends with 00

--------- known 58h fields

       SEE Text Block: 58 00 00 00 02 00 03 00 14 18  x  x  x  x  x  x
			x  x  x  x  x  x  x  x	x  x  x  x  x  x  x  x
			x  x  x  x  x  x  x  x	x  x  x 17
	     SEE Text: 'versions are included.          '

------- text on sign -----------------

       SEE Text Block: 58 00 00 00 02 00 03 00 10 0F 6F 72 64 65 72 20
		       79 6F 75 72 73 20 66 72 6F 6D 20 20 20 20 20 20
		       20 20 20 20 20 20 20 20 20 20 00 17 3E 6A 00 D9
	     SEE Text: 'order yours from                '

       SEE Text Block: 58 00 00 00 02 00 03 00 0C 0C  t  e  k  m  a  t
			e    00 17 -- -- -- -- -- -- -- -- -- -- -- --
		       -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	     SEE Text: 'tekmate '

       SEE Text Block: 58 00 00 00 02 00 03 00 0A 0A  1  5  3  0  7
			P  a  r  k  v  i  l  l	e
						     00 17 -- -- -- --
	     SEE Text: '15307 Parkville                 '

       SEE Text Block: 58 00 00 00 02 00 03 00 0A 0A 68 6F 75 73 74 6F
		       6E 2C 20 54 58 20 20 37 37 30 36 38 20 20 20 20
		       20 20 20 20 20 20 20 20 20 20 00 17 -- -- -- --
	     SEE Text: 'houston, TX  77068              '

       SEE Text Block: 58 00 00 00 02 00 03 00 07 07 6F 72 20 63 61 6C
		       6C 20 00 17 3E 82 00 D9 D4 D8 01 0E 00 0B 05 00
		       00 30 8E 06 00 0B 71 00 24 02 2E 6E D8 01 00 00
	     SEE Text: 'or call '

       SEE Text Block: 58 00 00 00 02 00 03 00 0C 0C 37 31 33 2D 34 34
		       30 2D 35 35 34 32 20 20 20 20 20 20 20 20 20 20
		       20 20 20 20 20 20 20 20 20 20 00 17 3E 82 00 D9
	     SEE Text: '713-440-5542                    '

       SEE Text Block: 58 00 00 00 02 00 03 00 07 07 66 6F 72 20 76 69
		       73 61 2D 6D 63 20 6F 72 64 65 72 73 20 61 6E 64
		       20 20 20 20 20 20 20 20 20 20 00 17 3E 82 00 D9
	     SEE Text: 'for visa-mc orders and          '

       SEE Text Block: 58 00 00 00 02 00 03 00 0A 0A 6E 65 78 74 20 64
		       61 79 20 73 68 69 70 70 69 6E 67 20 20 20 20 20
		       20 20 20 20 20 20 20 20 20 20 00 17 3E 42 01 D9
	     SEE Text: 'next day shipping               '

---- 5Ah -----------------------------

     10 bytes
     Triangle record used in mountains, depends on previously recorded
     vertex coords (see 31h)

     1,2: x    cross product vector of two triangle edge vectors
     3,4: z    (scaled so largest component has absval <16384)
     5,6: y
     7: vertex #A (v1)
     8: vertex #B (v2)
     9: vertex #C (v3)

     The cross product is used (I assume) for determing which 'side' of
     the triangle you are on (for hidden surface elimination).	I compute
     the cross products of vectors (A-B) and (A-C) as in:

void ComputeCrossProduct(int v1,int v2,int v3)
     {
     double x1, y1, z1;
     double x2, y2, z2;

     x1 = VertE[v3] - VertE[v1];
     y1 = VertN[v3] - VertN[v1];
     z1 = VertZ[v3] - VertZ[v1];
     x2 = VertE[v2] - VertE[v1];
     y2 = VertN[v2] - VertN[v1];
     z2 = VertZ[v2] - VertZ[v1];

     dotE = y1*z2 - z1*y2;
     dotN = z1*x2 - x1*z2;
     dotZ = x1*y2 - y1*x2;

     while ( Dot2Big() )
	  {
	  dotE /= 2.0;
	  dotN /= 2.0;
	  dotZ /= 2.0;
	  }
     }

---- 6Fh --------------------------------

     11 bytes

---- 79h --------------------------------

     1 byte
     Marks end of linked list.

---- 9Ch --------------------------------

     6 bytes
     East 'range' data for mountain (keeps track of min and max E values
     of vertices defined in 31h records)
     2,3: Minimum
     4,5: Maximum

---- 9Eh --------------------------------

     6 bytes
     Altitude 'range' data for mountain (keeps track of min and max Z values
     of vertices defined in 31h records)
     2,3: Minimum
     4,5: Maximum

---- A0h --------------------------------

     6 bytes
     North 'range' data for mountain (keeps track of min and max N values
     of vertices defined in 31h records)
     2,3: Minimum
     4,5: Maximum

------------------------------------------

25h record thoughts

This record is probably really a generic command to set a 16 bit variable
maintained in memory by FS4  such that

25 ll hh mm nn

will set the variable at offset hhll to the value nnmm.  It looks like
SEE goes ahead and allocates itself some more vairables from this range,
or perhaps they just know all the allowed variables already.  If my
assumption is true, then the following variabel offsets are defined:

     2E2       - surface color (usually repeated in all 4 nybbles)
     2EF       - altitude in meters above sea level
     2F6       - set to one for inner marker
     2F8       - set to one for outer marker
     2FA       - set to one for middle marker
     31E       - set to zero before defining mountain range info
	       - set to one before defining mountain side info

--------------------------

Mysterious JUMP/SKIP codes

     0E
     8E
     1F
     0B
     8B

This codes are used to skip over regions of scenery.  At run time, the skips
are recomputed to cause animation and color changes.  However, occasionally
a skip has an ambiguous value.	I.e. normally it is safe to step ahead 3 from
a skip and find a new record, but sometimes you have to step 5 or 7 or more
to be safe.  SEE often puts a record designator just after the skip.  The
problem is that utility programs like ASDROT and ASDMOV have to update
records within the skipped regions.

--------------------------

Building Walls Record  53h

It is very difficult to determine exactly how many bytes are included after
this record.  It is always terminated by a 19h, however.  Perhaps it is
impossible for a 19h to occur within the data itself.

--------------------------

SEE Colorization

SEE color changes are achieved via use of multiple 25h color change commands
surrounded by 23h and 0Bh and 0Eh skip commands such that only one of the
color commands is executed for a particular time of day and the others are
branched around.

--------------------------

SEE Library objects

SEE library objects hide inside of FS4 timing gates and use the AREA and
CENTER records of those gates.	The gates themselves are made invisible
by being given a 0 width and placed at a high altitude.  A library object
then uses additional drawing commands inside of the gate definition.

Some library objects consist of multiple gates, where each gate describes
a single 'panel' of the object.  Panels are 2D polygon pictures all in
a common plane which is then oriented in 3 space via a type 15h
orientation record.  For example, one gate/panel might be the left side of
a car, another might be the wheels on the left side of the car.

Other library objects include more complicated 3D drawing commands within a
single timing gate object.  For example, the light house consists of a series
of 31h vertex records followed by 30h and 31h drawing commands to define
polygons using those vertices.


--------------------------
DISCLAIMER
--------------------------

The above information was derived from hours of analysis of manually
generated scenery files.  The FS4/ASD community as a whole has spent
way too much time decoding this information in order to generate useful
utilities.  It would be nice if the original authors chose to publish
this information (and profitable for them as well, I am sure).	However,
the above information is not distributed with an eye towards enabling anyone
to rob the original authors of any rightful profits.  This information
should be used only for the common good of the FS4 community and to
encourage sales of FS4 and related products.

Dan Samuel  [70110,434]



-----------------------------
lib3demo
Record Types seen:
  0Bh  seen 1132 times
  0Eh  seen 97 times
  12h  seen 106 times
  15h  seen 283 times
  17h  seen 305 times
  20h  seen 24 times
  23h  seen 566 times
  24h  seen 287 times
  25h  seen 696 times
  29h  seen 352 times
  2Fh  seen 352 times
  3Eh  seen 287 times
  40h  seen 428 times
  41h  seen 2540 times
  58h  seen 24 times
  8Eh  seen 186 times
  ---------------------------
nycity.sc1
Record Types seen:

Record Types seen:
  0Bh  seen 399 times
  0Eh  seen 136 times
  12h  seen 131 times
  16h  seen 149 times
  19h  seen 159 times
  1Dh  seen 1 times
  22h  seen 7 times
  23h  seen 211 times
  24h  seen 284 times
  25h  seen 175 times
  28h  seen 6 times
  29h  seen 34 times
  2Ah  seen 222 times
  2Fh  seen 34 times
  31h  seen 74 times
  3Eh  seen 255 times
  40h  seen 67 times
  41h  seen 801 times
  51h  seen 7 times
  53h  seen 226 times
  5Ah  seen 83 times
  8Eh  seen 97 times
  9Ch  seen 7 times
  9Eh  seen 7 times
  A0h  seen 7 times
  C0h  seen 27 times

Total unexpected records: 0
  ---------------------

