summaryrefslogtreecommitdiffhomepage
path: root/Doc
diff options
context:
space:
mode:
Diffstat (limited to 'Doc')
-rw-r--r--Doc/3DS File Format.txt3111
-rw-r--r--Doc/AI.txt (renamed from Doc/AI.TXT)2496
-rw-r--r--Doc/Backstory.doc (renamed from Doc/backstory.doc)bin22528 -> 22528 bytes
-rw-r--r--Doc/Designer.txt (renamed from Doc/DESIGNER.TXT)344
-rw-r--r--Doc/Dynamic Campaigns.txt (renamed from Doc/dynamic campaigns.txt)1402
-rw-r--r--Doc/Engine.txt212
-rw-r--r--Doc/Eschaton-Atmosphere.txt16
-rw-r--r--Doc/ExceptionHandler.cpp.txt446
-rw-r--r--Doc/Gameplay.txt (renamed from Doc/GAMEPLAY.TXT)248
-rw-r--r--Doc/Landscape.txt (renamed from Doc/landscape.txt)174
-rw-r--r--Doc/Nearmap.txt (renamed from Doc/NEARMAP.TXT)234
-rw-r--r--Doc/Old Manual.doc (renamed from Doc/old manual.doc)bin1250053 -> 1250053 bytes
-rw-r--r--Doc/Outline.txt (renamed from Doc/OUTLINE.TXT)94
-rw-r--r--Doc/Pavlov.txt (renamed from Doc/PAVLOV.TXT)118
-rw-r--r--Doc/Player.doc (renamed from Doc/PLAYER.DOC)bin2856960 -> 2856960 bytes
-rw-r--r--Doc/Player2.doc (renamed from Doc/PLAYER2.DOC)bin648704 -> 648704 bytes
-rw-r--r--Doc/SpaceSim Market Crash.txt (renamed from Doc/space sim market crash.txt)64
-rw-r--r--Doc/Squadron Info.txt (renamed from Doc/squadron (wc) info.txt)192
-rw-r--r--Doc/Starshatter Campaign.txt1996
-rw-r--r--Doc/Task.txt (renamed from Doc/TASK.TXT)760
-rw-r--r--Doc/starshatter.Doxyfile3438
21 files changed, 5729 insertions, 9616 deletions
diff --git a/Doc/3DS File Format.txt b/Doc/3DS File Format.txt
index 64cd23a..5304879 100644
--- a/Doc/3DS File Format.txt
+++ b/Doc/3DS File Format.txt
@@ -1,1557 +1,1554 @@
-
-
---------------------------------------------------------------------------------
-
-
-The Unofficial 3DStudio 3DS File Format v1.0
-
-By Jeff Lewis (werewolf@worldgate.com)
-
-Notice
-
-This document is an attempt to document the AutoDesk 3DS file format. This was
-made difficult in that I don't own or have access to a copy of the program, only
-to sample files. Fortunately, someone used AutoDesk's own 3DS file development
-kit to create a program which dumps the contents of a 3DS file into a human
-readable form - albeit somewhat inaccurately. The codes listed and their names
-come from that program and have been confirmed by testing.
-
-It should be known that the 3DS format is, as far as I know, a proprietary
-format of AutoDesk and that the format details are not widely known or are
-protected by AutoDesk.
-
-It is not my intent to infringe on AutoDesk's rights, but simply to make a
-large collection of 3D image files accessable to people who do not use 3D
-Studio - or cannot use it because AutoDesk has not chosen to provide a version
-of 3D Studio for the computer they use (ie: The Macintosh in my case).
-
-Warning
-
-This document is not intended to be a definitive definition of the 3DS format
-and is not authorised by AutoDesk. While every effort has been made to ensure
-its accuracy, or at least warn you when there's doubt about its accuracy, no
-guarantee of accuracy in any of it can be given. Use this document at your own
-risk.
-
-
-Document layout and format information
-
-In the following document, chunk names which are in bold mean the chunk format
-has been determined with certainty. Chunk names which are not bold but have
-a struct following means that this is a guess but is not substantiated. All
-others are unknown.
-
-A short is always a two byte integer.
-A long is always a four byte integer.
-A float is always a four byte IEEE floating point number.
-A cstr is a zero byte terminated ASCII string without a length.
-A char is a single byte integer.
-
-
-3DS File Format
-
-A 3DS file consists of blocks of data called chunks. Every chunk starts the
-same way:
-
- short chunk_id;
- long chunk_len;
-
-The chunk_id is a unique code which identifies the type of data in this chunk
-and also may indicate the existence of subordinate chunks. The chunk_len
-indicates the length of following data to be associated with this chunk. Note,
-this may contain more data than just this chunk. If the length of data is
-greater than that needed to fill in the information for the chunk, additional
-subordinate chunks are attached to this chunk immediately following any data
-needed for this chunk, and should be parsed out. These subordinate chunks may
-themselves contain subordinate chunks.
-
-Unfortunately, there is no indication of the length of data which is owned by
-the current chunk, only the total length of data attached to the chunk, which
-means that the only way to parse out subordinate chunks is to know the exact
-format of the owning chunk. On the other hand, if a chunk is unknown, the
-parsing program canskip the entire chunk and subordinate chunks in one jump.
-
-In the following list, I try when possible to indicate that a chunk is likely to
-have subordinate chunks and what kinds of subordinate chunks I've seen attached
-to it.
-
-Another problem lies in cstr names. I've seen cases where the space used by a
-name is riddled with fragments of old names. It seems that the space reserved
-for a name is not cleared if a smaller name replaces it. If the name is removed,
-you'll get a zero byte indicating an immediate end of string, followed by an
-undetermined number of characters and nulls. This seems to happen only when the
-cstr is at the end of a block of data and so you can assume that the length of
-the chunk contains no other subchunks. See viewport_data for an example of this.
-
-
-0xxxH Group
-
- 0000H
- NULL_CHUNK
- 0001H
- Unknown chunk
- float ???
- 0002H
- M3D_VERSION
- short version;
- 0005H
- M3D_KFVERSION
- 0010H
- COLOR_F
- float red, grn, blu;
- 0011H
- COLOR_24
- char red, grn, blu;
- 0012H
- LIN_COLOR_24
- char red, grn, blu;
- 0013H
- LIN_COLOR_F
- float red, grn, blu;
- 0030H
- INT_PERCENTAGE
- short percentage;
- 0031H
- FLOAT_PERCENTAGE
- float percentage;
- 0100H
- MASTER_SCALE
- float scale;
- 0995H
- ChunkType
- 0996H
- ChunkUnique
- 0997H
- NotChunk
- 0998H
- Container
- 0999H
- IsChunk
- 0c3cH
- C_SXP_SELFI_MASKDATA
-
-
-
-1xxxH Group
-
- 1100H
- BIT_MAP
- cstr filename;
- 1101H
- USE_BIT_MAP
- 1200H
- SOLID_BGND; followed by color_f
- 1201H
- USE_SOLID_BGND
- 1300H
- V_GRADIENT; followed by three color_f: start, mid, end
- float midpoint;
- 1301H
- USE_V_GRADIENT
- 1400H
- LO_SHADOW_BIAS
- float bias;
- 1410H
- HI_SHADOW_BIAS
- 1420H
- SHADOW_MAP_SIZE
- short size;
- 1430H
- SHADOW_SAMPLES
- 1440H
- SHADOW_RANGE
- 1450H
- SHADOW_FILTER
- float filter;
- 1460H
- RAY_BIAS
- float bias;
- 1500H
- O_CONSTS
- float plane_x, plane_y, plane_z;
-
-
-
-2xxxH Group
-
- 2100H
- AMBIENT_LIGHT
- 2200H
- FOG; followed by color_f, fog_bgnd
- float near_plane, near_density;
- float far_plane, far_density;
- 2201H
- USE_FOG
- 2210H
- FOG_BGND
- 2300H
- DISTANCE_CUE followed by dcue_bgnd
- float near_plane, near_density;
- float far_plane, far_density;
- 2301H
- USE_DISTANCE_CUE
- 2302H
- LAYER_FOG
- float fog_z_from, fog_z_to;
- float fog_density;
- short fog_type;
- 2303H
- USE_LAYER_FOG
- 2310H
- DCUE_BGND
- 2d2dH
- SMAGIC
- 2d3dH
- LMAGIC
-
-
-
-3xxxH Group
-
- 3000H
- DEFAULT_VIEW
- 3010H
- VIEW_TOP
- float targe_x, target_y, target_z;
- float view_width;
- 3020H
- VIEW_BOTTOM
- float targe_x, target_y, target_z;
- float view_width;
- 3030H
- VIEW_LEFT
- float targe_x, target_y, target_z;
- float view_width;
- 3040H
- VIEW_RIGHT
- float targe_x, target_y, target_z;
- float view_width;
- 3050H
- VIEW_FRONT
- float targe_x, target_y, target_z;
- float view_width;
- 3060H
- VIEW_BACK
- float targe_x, target_y, target_z;
- float view_width;
- 3070H
- VIEW_USER
- float targe_x, target_y, target_z;
- float view_width;
- 3080H
- VIEW_CAMERA
- cstr camera_name;
- 3090H
- VIEW_WINDOW
- 3d3dH
- MDATA; Mesh Data Magic Number (.3DS files sub of 4d4d)
- 3d3eH
- MESH_VERSION
- 3daaH
- MLIBMAGIC; Material Library Magic Number (.MLI files)
- 3dc2H
- PRJMAGIC; 3dS Project Magic Number (.PRJ files)
- 3dffH
- MATMAGIC; Material File Magic Number (.MAT files)
-
-
-
-4xxxH Group
-
- 4000H
- NAMED_OBJECT
- cstr name;
- 4010H
- OBJ_HIDDEN
- 4011H
- OBJ_VIS_LOFTER
- 4012H
- OBJ_DOESNT_CAST
- 4013H
- OBJ_MATTE
- 4014H
- OBJ_FAST
- 4015H
- OBJ_PROCEDURAL
- 4016H
- OBJ_FROZEN
- 4017H
- OBJ_DONT_RCVSHADOW
- 4100H
- N_TRI_OBJECT
- named triangle object
- followed by point_array, point_flag_array, mesh_matrix,
- face_array
- 4110H
- POINT_ARRAY
- short npoints;
- struct {
- float x, y, z;
- } points[npoints];
- 4111H
- POINT_FLAG_ARRAY
- short nflags;
- short flags[nflags];
- 4120H
- FACE_ARRAY may be followed by smooth_group
- short nfaces;
- struct {
- short vertex1, vertex2, vertex3;
- short flags;
- } facearray[nfaces];
- 4130H
- MSH_MAT_GROUP mesh_material_group
- cstr material_name;
- short nfaces;
- short facenum[nfaces];
- 4131H
- OLD_MAT_GROUP
- 4140H
- TEX_VERTS
- short nverts;
- struct {
- float x, y;
- } vertices[nverts];
- 4150H
- SMOOTH_GROUP
- short grouplist[n]; determined by length, seems to be 4 per face
- 4160H
- MESH_MATRIX
- float matrix[4][3];
- 4165H
- MESH_COLOR
- short color_index;
- 4170H
- MESH_TEXTURE_INFO
- short map_type;
- float x_tiling, y_tiling;
- float icon_x, icon_y, icon_z;
- float matrix[4][3];
- float scaling, plan_icon_w, plan_icon_h, cyl_icon_h;
- 4181H
- PROC_NAME
- 4182H
- PROC_DATA
- 4190H
- MSH_BOXMAP
- 4400H
- N_D_L_OLD
- 4500H
- N_CAM_OLD
- 4600H
- N_DIRECT_LIGHT; followed by color_f
- float x, y, z;
- 4610H
- DL_SPOTLIGHT
- float target_x, target_y, target_z;
- float hotspot_ang;
- float falloff_ang;
- 4620H
- DL_OFF
- 4625H
- DL_ATTENUATE
- 4627H
- DL_RAYSHAD
- 4630H
- DL_SHADOWED
- 4640H
- DL_LOCAL_SHADOW
- 4641H
- DL_LOCAL_SHADOW2
- 4650H
- DL_SEE_CONE
- 4651H
- DL_SPOT_RECTANGULAR
- 4652H
- DL_SPOT_OVERSHOOT
- 4653H
- DL_SPOT_PROJECTOR
- 4654H
- DL_EXCLUDE
- 4655H
- DL_RANGE
- 4656H
- DL_SPOT_ROLL
- float roll_ang;
- 4657H
- DL_SPOT_ASPECT
- 4658H
- DL_RAY_BIAS
- float bias;
- 4659H
- DL_INNER_RANGE
- float range;
- 465aH
- DL_OUTER_RANGE
- float range;
- 465bH
- DL_MULTIPLIER
- float multiple;
- 4680H
- N_AMBIENT_LIGHT
- 4700H
- N_CAMERA
- float camera_x, camera_y, camera_z;
- float target_x, target_y, target_z;
- float bank_angle;
- float focus;
- 4710H
- CAM_SEE_CONE
- 4720H
- CAM_RANGES
- float near_range, far_range;
- 4d4dH
- M3DMAGIC; 3DS Magic Number (.3DS file)
- 4f00H
- HIERARCHY
- 4f10H
- PARENT_OBJECT
- 4f20H
- PIVOT_OBJECT
- 4f30H
- PIVOT_LIMITS
- 4f40H
- PIVOT_ORDER
- 4f50H
- XLATE_RANGE
-
-
-
-5xxxH Group
-
- 5000H
- POLY_2D
- 5010H
- SHAPE_OK
- 5011H
- SHAPE_NOT_OK
- 5020H
- SHAPE_HOOK
-
-
-
-6xxxH Group
-
- 6000H
- PATH_3D
- 6005H
- PATH_MATRIX
- 6010H
- SHAPE_2D
- 6020H
- M_SCALE
- 6030H
- M_TWIST
- 6040H
- M_TEETER
- 6050H
- M_FIT
- 6060H
- M_BEVEL
- 6070H
- XZ_CURVE
- 6080H
- YZ_CURVE
- 6090H
- INTERPCT
- 60a0H
- DEFORM_LIMIT
- 6100H
- USE_CONTOUR
- 6110H
- USE_TWEEN
- 6120H
- USE_SCALE
- 6130H
- USE_TWIST
- 6140H
- USE_TEETER
- 6150H
- USE_FIT
- 6160H
- USE_BEVEL
-
-
-
-7xxxH Group
-
- 7000H
- VIEWPORT_LAYOUT_OLD
- 7001H
- VIEWPORT_LAYOUT; followed by viewport_size, viewport_data
- short form, top, ready, wstate, swapws, swapport, swapcur;
- 7010H
- VIEWPORT_DATA_OLD
- 7011H
- VIEWPORT_DATA
- short flags, axis_lockout;
- short win_x, win_y, win_w, winh_, win_view;
- float zoom;
- float worldcenter_x, worldcenter_y, worldcenter_z;
- float horiz_ang, vert_ang;
- cstr camera_name;
- 7012H
- VIEWPORT_DATA_3
- short flags, axis_lockout;
- short win_x, win_y, win_w, winh_, win_view;
- float zoom;
- float worldcenter_x, worldcenter_y, worldcenter_z;
- float horiz_ang, vert_ang;
- cstr camera_name;
- 7020H
- VIEWPORT_SIZE
- short x, y, w, h;
- 7030H
- NETWORK_VIEW
-
-
-
-8xxxH Group
-
- 8000H
- XDATA_SECTION
- 8001H
- XDATA_ENTRY
- 8002H
- XDATA_APPNAME
- 8003H
- XDATA_STRING
- 8004H
- XDATA_FLOAT
- 8005H
- XDATA_DOUBLE
- 8006H
- XDATA_SHORT
- 8007H
- XDATA_LONG
- 8008H
- XDATA_VOID
- 8009H
- XDATA_GROUP
- 800aH
- XDATA_RFU6
- 800bH
- XDATA_RFU5
- 800cH
- XDATA_RFU4
- 800dH
- XDATA_RFU3
- 800eH
- XDATA_RFU2
- 800fH
- XDATA_RFU1
- 80f0H
- PARENT_NAME
-
-
-
-AxxxH Group
-
- a000H
- MAT_NAME
- cstr material_name;
- a010H
- MAT_AMBIENT; followed by color chunk
- a020H
- MAT_DIFFUSE; followed by color chunk
- a030H
- MAT_SPECULAR; followed by color chunk
- a040H
- MAT_SHININESS; followed by percentage chunk
- a041H
- MAT_SHIN2PCT; followed by percentage chunk
- a042H
- MAT_SHIN3PCT; followed by percentage chunk
- a050H
- MAT_TRANSPARENCY; followed by percentage chunk
- a052H
- MAT_XPFALL; followed by percentage chunk
- a053H
- MAT_REFBLUR; followed by percentage chunk
- a080H
- MAT_SELF_ILLUM
- a081H
- MAT_TWO_SIDE
- a082H
- MAT_DECAL
- a083H
- MAT_ADDITIVE
- a084H
- MAT_SELF_ILPCT; followed by percentage chunk
- a085H
- MAT_WIRE
- a086H
- MAT_SUPERSMP
- a087H
- MAT_WIRESIZE
- float wire_size;
- a088H
- MAT_FACEMAP
- a08aH
- MAT_XPFALLIN
- a08cH
- MAT_PHONGSOFT
- a08eH
- MAT_WIREABS
- a100H
- MAT_SHADING
- short shading_value;
- a200H
- MAT_TEXMAP; followed by percentage chunk, mat_mapname,
- mat_map_tiling, mat_map_texblur...
- a204H
- MAT_SPECMAP; followed by percentage_chunk, mat_mapname
- a210H
- MAT_OPACMAP; followed by percentage_chunk, mat_mapname
- a220H
- MAT_REFLMAP; followed by percentage_chunk, mat_mapname
- a230H
- MAT_BUMPMAP; followed by percentage_chunk, mat_mapname
- a240H
- MAT_USE_XPFALL
- a250H
- MAT_USE_REFBLUR
- a252H
- MAT_BUMP_PERCENT
- a300H
- MAT_MAPNAME
- cstr filename;
- a310H
- MAT_ACUBIC
- a320H
- MAT_SXP_TEXT_DATA
- a321H
- MAT_SXP_TEXT2_DATA
- a322H
- MAT_SXP_OPAC_DATA
- a324H
- MAT_SXP_BUMP_DATA
- a325H
- MAT_SXP_SPEC_DATA
- a326H
- MAT_SXP_SHIN_DATA
- a328H
- MAT_SXP_SELFI_DATA
- a32aH
- MAT_SXP_TEXT_MASKDATA
- a32cH
- MAT_SXP_TEXT2_MASKDATA
- a32eH
- MAT_SXP_OPAC_MASKDATA
- a330H
- MAT_SXP_BUMP_MASKDATA
- a332H
- MAT_SXP_SPEC_MASKDATA
- a334H
- MAT_SXP_SHIN_MASKDATA
- a336H
- MAT_SXP_SELFI_MASKDATA
- a338H
- MAT_SXP_REFL_MASKDATA
- a33aH
- MAT_TEX2MAP
- a33cH
- MAT_SHINMAP
- a33dH
- MAT_SELFIMAP
- a33eH
- MAT_TEXMASK
- a340H
- MAT_TEX2MASK
- a342H
- MAT_OPACMASK
- a344H
- MAT_BUMPMASK
- a346H
- MAT_SHINMASK
- a348H
- MAT_SPECMASK
- a34aH
- MAT_SELFIMASK
- a34cH
- MAT_REFLMASK
- a350H
- MAT_MAP_TILINGOLD
- a351H
- MAT_MAP_TILING
- short flags;
- a352H
- MAT_MAP_TEXBLUR_OLD
- a353H
- MAT_MAP_TEXBLUR
- float blurring;
- a354H
- MAT_MAP_USCALE
- a356H
- MAT_MAP_VSCALE
- a358H
- MAT_MAP_UOFFSET
- a35aH
- MAT_MAP_VOFFSET
- a35cH
- MAT_MAP_ANG
- a360H
- MAT_MAP_COL1
- a362H
- MAT_MAP_COL2
- a364H
- MAT_MAP_RCOL
- a366H
- MAT_MAP_GCOL
- a368H
- MAT_MAP_BCOL
- afffH
- MAT_ENTRY
-
-
-
-BxxxH Group
-
- b000H
- KFDATA; followed by kfhdr
- b001H
- AMBIENT_NODE_TAG
- b002H
- OBJECT_NODE_TAG; followed by node_hdr, pivot, pos_track_tag,
- rot_track_tag, scl_track_tag, morph_smooth...
- b003H
- CAMERA_NODE_TAG; followed by node_hdr, pos_track_tag, fov_track_tag,
- roll_track_tag...
- b004H
- TARGET_NODE_TAG; followed by node_hdr, pos_track_tag...
- b005H
- LIGHT_NODE_TAG; followed by node_hdr, pos_track_tag, col_track_tag...
- b006H
- L_TARGET_NODE_TAG; followed by node_id, node_hdr, pos_track_tag
- b007H
- SPOTLIGHT_NODE_TAG; followed by node_id, node_hdr, pos_track_tag,
- hot_track_tag, fall_track_tag, roll_track_tag, col_track_tag...
- b008H
- KFSEG
- short start, end;
- b009H
- KFCURTIME
- short curframe;
- b00aH
- KFHDR followed by viewport_layout, kfseg, kfcurtime, object_node_tag,
- light_node_tag, target_node_tag, camera_node_tag, l_target_node_tag,
- spotlight_node_tag, ambient_node_tag...
- short revision;
- cstr filename;
- short animlen;
- b010H
- NODE_HDR
- cstr objname;
- short flags1;
- short flags2;
- short heirarchy; ?
- b011H
- INSTANCE_NAME
- b012H
- PRESCALE
- b013H
- PIVOT
- float pivot_x, pivot_y, pivot_z;
- b014H
- BOUNDBOX
- b015H
- MORPH_SMOOTH
- float morph_smoothing_angle_rad;
- b020H
- POS_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float pos_x, pos_y, pos_z;
- } pos[keys];
- b021H
- ROT_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float rotation_rad;
- float axis_x, axis_y, axis_z;
- } rot[keys];
- b022H
- SCL_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float scale_x, scale_y, scale_z;
- } scale[keys];
- b023H
- FOV_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float camera_field_of_view;
- } fov[keys]
- b024H
- ROLL_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float camera_roll;
- } roll[keys];
- b025H
- COL_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float red, rgn, blu;
- } color[keys];
- b026H
- MORPH_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- cstr obj_name;
- } morph[keys];
- b027H
- HOT_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float hotspot_ang;
- } hotspot[keys];
- b028H
- FALL_TRACK_TAG
- short flags;
- short unknown[4];
- short keys;
- short unknown;
- struct {
- short framenum;
- long unknown;
- float falloff_ang;
- } falloff[keys];
- b029H
- HIDE_TRACK_TAG
- b030H
- NODE_ID
- short id;
-
-
-
-CxxxH Group
-
- c010H
- C_MDRAWER
- c020H
- C_TDRAWER
- c030H
- C_SHPDRAWER
- c040H
- C_MODDRAWER
- c050H
- C_RIPDRAWER
- c060H
- C_TXDRAWER
- c062H
- C_PDRAWER
- c064H
- C_MTLDRAWER
- c066H
- C_FLIDRAWER
- c067H
- C_CUBDRAWER
- c070H
- C_MFILE
- c080H
- C_SHPFILE
- c090H
- C_MODFILE
- c0a0H
- C_RIPFILE
- c0b0H
- C_TXFILE
- c0b2H
- C_PFILE
- c0b4H
- C_MTLFILE
- c0b6H
- C_FLIFILE
- c0b8H
- C_PALFILE
- c0c0H
- C_TX_STRING
- c0d0H
- C_CONSTS
- c0e0H
- C_SNAPS
- c0f0H
- C_GRIDS
- c100H
- C_ASNAPS
- c110H
- C_GRID_RANGE
- c120H
- C_RENDTYPE
- c130H
- C_PROGMODE
- c140H
- C_PREVMODE
- c150H
- C_MODWMODE
- c160H
- C_MODMODEL
- c170H
- C_ALL_LINES
- c180H
- C_BACK_TYPE
- c190H
- C_MD_CS
- c1a0H
- C_MD_CE
- c1b0H
- C_MD_SML
- c1c0H
- C_MD_SMW
- c1c3H
- C_LOFT_WITH_TEXTURE
- c1c4H
- C_LOFT_L_REPEAT
- c1c5H
- C_LOFT_W_REPEAT
- c1c6H
- C_LOFT_UV_NORMALIZE
- c1c7H
- C_WELD_LOFT
- c1d0H
- C_MD_PDET
- c1e0H
- C_MD_SDET
- c1f0H
- C_RGB_RMODE
- c200H
- C_RGB_HIDE
- c202H
- C_RGB_MAPSW
- c204H
- C_RGB_TWOSIDE
- c208H
- C_RGB_SHADOW
- c210H
- C_RGB_AA
- c220H
- C_RGB_OVW
- c230H
- C_RGB_OVH
- c23dH
- CMAGIC
- c240H
- C_RGB_PICTYPE
- c250H
- C_RGB_OUTPUT
- c253H
- C_RGB_TODISK
- c254H
- C_RGB_COMPRESS
- c255H
- C_JPEG_COMPRESSION
- c256H
- C_RGB_DISPDEV
- c259H
- C_RGB_HARDDEV
- c25aH
- C_RGB_PATH
- c25bH
- C_BITMAP_DRAWER
- c260H
- C_RGB_FILE
- c270H
- C_RGB_OVASPECT
- c271H
- C_RGB_ANIMTYPE
- c272H
- C_RENDER_ALL
- c273H
- C_REND_FROM
- c274H
- C_REND_TO
- c275H
- C_REND_NTH
- c276H
- C_PAL_TYPE
- c277H
- C_RND_TURBO
- c278H
- C_RND_MIP
- c279H
- C_BGND_METHOD
- c27aH
- C_AUTO_REFLECT
- c27bH
- C_VP_FROM
- c27cH
- C_VP_TO
- c27dH
- C_VP_NTH
- c27eH
- C_REND_TSTEP
- c27fH
- C_VP_TSTEP
- c280H
- C_SRDIAM
- c290H
- C_SRDEG
- c2a0H
- C_SRSEG
- c2b0H
- C_SRDIR
- c2c0H
- C_HETOP
- c2d0H
- C_HEBOT
- c2e0H
- C_HEHT
- c2f0H
- C_HETURNS
- c300H
- C_HEDEG
- c310H
- C_HESEG
- c320H
- C_HEDIR
- c330H
- C_QUIKSTUFF
- c340H
- C_SEE_LIGHTS
- c350H
- C_SEE_CAMERAS
- c360H
- C_SEE_3D
- c370H
- C_MESHSEL
- c380H
- C_MESHUNSEL
- c390H
- C_POLYSEL
- c3a0H
- C_POLYUNSEL
- c3a2H
- C_SHPLOCAL
- c3a4H
- C_MSHLOCAL
- c3b0H
- C_NUM_FORMAT
- c3c0H
- C_ARCH_DENOM
- c3d0H
- C_IN_DEVICE
- c3e0H
- C_MSCALE
- c3f0H
- C_COMM_PORT
- c400H
- C_TAB_BASES
- c410H
- C_TAB_DIVS
- c420H
- C_MASTER_SCALES
- c430H
- C_SHOW_1STVERT
- c440H
- C_SHAPER_OK
- c450H
- C_LOFTER_OK
- c460H
- C_EDITOR_OK
- c470H
- C_KEYFRAMER_OK
- c480H
- C_PICKSIZE
- c490H
- C_MAPTYPE
- c4a0H
- C_MAP_DISPLAY
- c4b0H
- C_TILE_XY
- c4c0H
- C_MAP_XYZ
- c4d0H
- C_MAP_SCALE
- c4e0H
- C_MAP_MATRIX_OLD
- c4e1H
- C_MAP_MATRIX
- c4f0H
- C_MAP_WID_HT
- c500H
- C_OBNAME
- c510H
- C_CAMNAME
- c520H
- C_LTNAME
- c525H
- C_CUR_MNAME
- c526H
- C_CURMTL_FROM_MESH
- c527H
- C_GET_SHAPE_MAKE_FACES
- c530H
- C_DETAIL
- c540H
- C_VERTMARK
- c550H
- C_MSHAX
- c560H
- C_MSHCP
- c570H
- C_USERAX
- c580H
- C_SHOOK
- c590H
- C_RAX
- c5a0H
- C_STAPE
- c5b0H
- C_LTAPE
- c5c0H
- C_ETAPE
- c5c8H
- C_KTAPE
- c5d0H
- C_SPHSEGS
- c5e0H
- C_GEOSMOOTH
- c5f0H
- C_HEMISEGS
- c600H
- C_PRISMSEGS
- c610H
- C_PRISMSIDES
- c620H
- C_TUBESEGS
- c630H
- C_TUBESIDES
- c640H
- C_TORSEGS
- c650H
- C_TORSIDES
- c660H
- C_CONESIDES
- c661H
- C_CONESEGS
- c670H
- C_NGPARMS
- c680H
- C_PTHLEVEL
- c690H
- C_MSCSYM
- c6a0H
- C_MFTSYM
- c6b0H
- C_MTTSYM
- c6c0H
- C_SMOOTHING
- c6d0H
- C_MODICOUNT
- c6e0H
- C_FONTSEL
- c6f0H
- C_TESS_TYPE
- c6f1H
- C_TESS_TENSION
- c700H
- C_SEG_START
- c705H
- C_SEG_END
- c710H
- C_CURTIME
- c715H
- C_ANIMLENGTH
- c720H
- C_PV_FROM
- c725H
- C_PV_TO
- c730H
- C_PV_DOFNUM
- c735H
- C_PV_RNG
- c740H
- C_PV_NTH
- c745H
- C_PV_TYPE
- c750H
- C_PV_METHOD
- c755H
- C_PV_FPS
- c765H
- C_VTR_FRAMES
- c770H
- C_VTR_HDTL
- c771H
- C_VTR_HD
- c772H
- C_VTR_TL
- c775H
- C_VTR_IN
- c780H
- C_VTR_PK
- c785H
- C_VTR_SH
- c790H
- C_WORK_MTLS
- c792H
- C_WORK_MTLS_2
- c793H
- C_WORK_MTLS_3
- c794H
- C_WORK_MTLS_4
- c7a1H
- C_BGTYPE
- c7b0H
- C_MEDTILE
- c7d0H
- C_LO_CONTRAST
- c7d1H
- C_HI_CONTRAST
- c7e0H
- C_FROZ_DISPLAY
- c7f0H
- C_BOOLWELD
- c7f1H
- C_BOOLTYPE
- c900H
- C_ANG_THRESH
- c901H
- C_SS_THRESH
- c903H
- C_TEXTURE_BLUR_DEFAULT
- ca00H
- C_MAPDRAWER
- ca01H
- C_MAPDRAWER1
- ca02H
- C_MAPDRAWER2
- ca03H
- C_MAPDRAWER3
- ca04H
- C_MAPDRAWER4
- ca05H
- C_MAPDRAWER5
- ca06H
- C_MAPDRAWER6
- ca07H
- C_MAPDRAWER7
- ca08H
- C_MAPDRAWER8
- ca09H
- C_MAPDRAWER9
- ca10H
- C_MAPDRAWER_ENTRY
- ca20H
- C_BACKUP_FILE
- ca21H
- C_DITHER_256
- ca22H
- C_SAVE_LAST
- ca23H
- C_USE_ALPHA
- ca24H
- C_TGA_DEPTH
- ca25H
- C_REND_FIELDS
- ca26H
- C_REFLIP
- ca27H
- C_SEL_ITEMTOG
- ca28H
- C_SEL_RESET
- ca29H
- C_STICKY_KEYINF
- ca2aH
- C_WELD_THRESHOLD
- ca2bH
- C_ZCLIP_POINT
- ca2cH
- C_ALPHA_SPLIT
- ca30H
- C_KF_SHOW_BACKFACE
- ca40H
- C_OPTIMIZE_LOFT
- ca42H
- C_TENS_DEFAULT
- ca44H
- C_CONT_DEFAULT
- ca46H
- C_BIAS_DEFAULT
- ca50H
- C_DXFNAME_SRC
- ca60H
- C_AUTO_WELD
- ca70H
- C_AUTO_UNIFY
- ca80H
- C_AUTO_SMOOTH
- ca90H
- C_DXF_SMOOTH_ANG
- caa0H
- C_SMOOTH_ANG
- cb00H
- C_WORK_MTLS_5
- cb01H
- C_WORK_MTLS_6
- cb02H
- C_WORK_MTLS_7
- cb03H
- C_WORK_MTLS_8
- cb04H
- C_WORKMTL
- cb10H
- C_SXP_TEXT_DATA
- cb11H
- C_SXP_OPAC_DATA
- cb12H
- C_SXP_BUMP_DATA
- cb13H
- C_SXP_SHIN_DATA
- cb20H
- C_SXP_TEXT2_DATA
- cb24H
- C_SXP_SPEC_DATA
- cb28H
- C_SXP_SELFI_DATA
- cb30H
- C_SXP_TEXT_MASKDATA
- cb32H
- C_SXP_TEXT2_MASKDATA
- cb34H
- C_SXP_OPAC_MASKDATA
- cb36H
- C_SXP_BUMP_MASKDATA
- cb38H
- C_SXP_SPEC_MASKDATA
- cb3aH
- C_SXP_SHIN_MASKDATA
- cb3eH
- C_SXP_REFL_MASKDATA
- cc00H
- C_NET_USE_VPOST
- cc10H
- C_NET_USE_GAMMA
- cc20H
- C_NET_FIELD_ORDER
- cd00H
- C_BLUR_FRAMES
- cd10H
- C_BLUR_SAMPLES
- cd20H
- C_BLUR_DUR
- cd30H
- C_HOT_METHOD
- cd40H
- C_HOT_CHECK
- cd50H
- C_PIXEL_SIZE
- cd60H
- C_DISP_GAMMA
- cd70H
- C_FBUF_GAMMA
- cd80H
- C_FILE_OUT_GAMMA
- cd82H
- C_FILE_IN_GAMMA
- cd84H
- C_GAMMA_CORRECT
- cd90H
- C_APPLY_DISP_GAMMA
- cda0H
- C_APPLY_FBUF_GAMMA
- cdb0H
- C_APPLY_FILE_GAMMA
- cdc0H
- C_FORCE_WIRE
- cdd0H
- C_RAY_SHADOWS
- cde0H
- C_MASTER_AMBIENT
- cdf0H
- C_SUPER_SAMPLE
- ce00H
- C_OBJECT_MBLUR
- ce10H
- C_MBLUR_DITHER
- ce20H
- C_DITHER_24
- ce30H
- C_SUPER_BLACK
- ce40H
- C_SAFE_FRAME
- ce50H
- C_VIEW_PRES_RATIO
- ce60H
- C_BGND_PRES_RATIO
- ce70H
- C_NTH_SERIAL_NUM
-
-
-
-DxxxH Group
-
- d000H
- VPDATA
- d100H
- P_QUEUE_ENTRY
- d110H
- P_QUEUE_IMAGE
- d114H
- P_QUEUE_USEIGAMMA
- d120H
- P_QUEUE_PROC
- d130H
- P_QUEUE_SOLID
- d140H
- P_QUEUE_GRADIENT
- d150H
- P_QUEUE_KF
- d152H
- P_QUEUE_MOTBLUR
- d153H
- P_QUEUE_MB_REPEAT
- d160H
- P_QUEUE_NONE
- d180H
- P_QUEUE_RESIZE
- d185H
- P_QUEUE_OFFSET
- d190H
- P_QUEUE_ALIGN
- d1a0H
- P_CUSTOM_SIZE
- d210H
- P_ALPH_NONE
- d220H
- P_ALPH_PSEUDO
- d221H
- P_ALPH_OP_PSEUDO
- d222H
- P_ALPH_BLUR
- d225H
- P_ALPH_PCOL
- d230H
- P_ALPH_C0
- d231H
- P_ALPH_OP_KEY
- d235H
- P_ALPH_KCOL
- d238H
- P_ALPH_OP_NOCONV
- d240H
- P_ALPH_IMAGE
- d250H
- P_ALPH_ALPHA
- d260H
- P_ALPH_QUES
- d265H
- P_ALPH_QUEIMG
- d270H
- P_ALPH_CUTOFF
- d280H
- P_ALPHANEG
- d300H
- P_TRAN_NONE
- d310H
- P_TRAN_IMAGE
- d312H
- P_TRAN_FRAMES
- d320H
- P_TRAN_FADEIN
- d330H
- P_TRAN_FADEOUT
- d340H
- P_TRANNEG
- d400H
- P_RANGES
- d500H
- P_PROC_DATA
-
-
-
-FxxxH Group
-
- f020H
- POS_TRACK_TAG_KEY
- f021H
- ROT_TRACK_TAG_KEY
- f022H
- SCL_TRACK_TAG_KEY
- f023H
- FOV_TRACK_TAG_KEY
- f024H
- ROLL_TRACK_TAG_KEY
- f025H
- COL_TRACK_TAG_KEY
- f026H
- MORPH_TRACK_TAG_KEY
- f027H
- HOT_TRACK_TAG_KEY
- f028H
- FALL_TRACK_TAG_KEY
- f110H
- POINT_ARRAY_ENTRY
- f111H
- POINT_FLAG_ARRAY_ENTRY
- f120H
- FACE_ARRAY_ENTRY
- f130H
- MSH_MAT_GROUP_ENTRY
- f140H
- TEX_VERTS_ENTRY
- f150H
- SMOOTH_GROUP_ENTRY
- ffffH
- DUMMY
-
-
-
-
-
-
-
-The Unofficial 3DStudio 3DS File Format / CR-MM / mediatel-admin@mediatel.lu
-
-
-
-
---------------------------------------------------------------------------------
-
-
-Comments? Send them to: webmaster@filespecs.com
-
-
-Copyright 2001 BreakPoint Software, Inc. All Rights Reserved.
-
+--------------------------------------------------------------------------------
+
+
+The Unofficial 3DStudio 3DS File Format v1.0
+
+By Jeff Lewis (werewolf@worldgate.com)
+
+Notice
+
+This document is an attempt to document the AutoDesk 3DS file format. This was
+made difficult in that I don't own or have access to a copy of the program, only
+to sample files. Fortunately, someone used AutoDesk's own 3DS file development
+kit to create a program which dumps the contents of a 3DS file into a human
+readable form - albeit somewhat inaccurately. The codes listed and their names
+come from that program and have been confirmed by testing.
+
+It should be known that the 3DS format is, as far as I know, a proprietary
+format of AutoDesk and that the format details are not widely known or are
+protected by AutoDesk.
+
+It is not my intent to infringe on AutoDesk's rights, but simply to make a
+large collection of 3D image files accessable to people who do not use 3D
+Studio - or cannot use it because AutoDesk has not chosen to provide a version
+of 3D Studio for the computer they use (ie: The Macintosh in my case).
+
+Warning
+
+This document is not intended to be a definitive definition of the 3DS format
+and is not authorised by AutoDesk. While every effort has been made to ensure
+its accuracy, or at least warn you when there's doubt about its accuracy, no
+guarantee of accuracy in any of it can be given. Use this document at your own
+risk.
+
+
+Document layout and format information
+
+In the following document, chunk names which are in bold mean the chunk format
+has been determined with certainty. Chunk names which are not bold but have
+a struct following means that this is a guess but is not substantiated. All
+others are unknown.
+
+A short is always a two byte integer.
+A long is always a four byte integer.
+A float is always a four byte IEEE floating point number.
+A cstr is a zero byte terminated ASCII string without a length.
+A char is a single byte integer.
+
+
+3DS File Format
+
+A 3DS file consists of blocks of data called chunks. Every chunk starts the
+same way:
+
+ short chunk_id;
+ long chunk_len;
+
+The chunk_id is a unique code which identifies the type of data in this chunk
+and also may indicate the existence of subordinate chunks. The chunk_len
+indicates the length of following data to be associated with this chunk. Note,
+this may contain more data than just this chunk. If the length of data is
+greater than that needed to fill in the information for the chunk, additional
+subordinate chunks are attached to this chunk immediately following any data
+needed for this chunk, and should be parsed out. These subordinate chunks may
+themselves contain subordinate chunks.
+
+Unfortunately, there is no indication of the length of data which is owned by
+the current chunk, only the total length of data attached to the chunk, which
+means that the only way to parse out subordinate chunks is to know the exact
+format of the owning chunk. On the other hand, if a chunk is unknown, the
+parsing program canskip the entire chunk and subordinate chunks in one jump.
+
+In the following list, I try when possible to indicate that a chunk is likely to
+have subordinate chunks and what kinds of subordinate chunks I've seen attached
+to it.
+
+Another problem lies in cstr names. I've seen cases where the space used by a
+name is riddled with fragments of old names. It seems that the space reserved
+for a name is not cleared if a smaller name replaces it. If the name is removed,
+you'll get a zero byte indicating an immediate end of string, followed by an
+undetermined number of characters and nulls. This seems to happen only when the
+cstr is at the end of a block of data and so you can assume that the length of
+the chunk contains no other subchunks. See viewport_data for an example of this.
+
+
+0xxxH Group
+
+ 0000H
+ NULL_CHUNK
+ 0001H
+ Unknown chunk
+ float ???
+ 0002H
+ M3D_VERSION
+ short version;
+ 0005H
+ M3D_KFVERSION
+ 0010H
+ COLOR_F
+ float red, grn, blu;
+ 0011H
+ COLOR_24
+ char red, grn, blu;
+ 0012H
+ LIN_COLOR_24
+ char red, grn, blu;
+ 0013H
+ LIN_COLOR_F
+ float red, grn, blu;
+ 0030H
+ INT_PERCENTAGE
+ short percentage;
+ 0031H
+ FLOAT_PERCENTAGE
+ float percentage;
+ 0100H
+ MASTER_SCALE
+ float scale;
+ 0995H
+ ChunkType
+ 0996H
+ ChunkUnique
+ 0997H
+ NotChunk
+ 0998H
+ Container
+ 0999H
+ IsChunk
+ 0c3cH
+ C_SXP_SELFI_MASKDATA
+
+
+
+1xxxH Group
+
+ 1100H
+ BIT_MAP
+ cstr filename;
+ 1101H
+ USE_BIT_MAP
+ 1200H
+ SOLID_BGND; followed by color_f
+ 1201H
+ USE_SOLID_BGND
+ 1300H
+ V_GRADIENT; followed by three color_f: start, mid, end
+ float midpoint;
+ 1301H
+ USE_V_GRADIENT
+ 1400H
+ LO_SHADOW_BIAS
+ float bias;
+ 1410H
+ HI_SHADOW_BIAS
+ 1420H
+ SHADOW_MAP_SIZE
+ short size;
+ 1430H
+ SHADOW_SAMPLES
+ 1440H
+ SHADOW_RANGE
+ 1450H
+ SHADOW_FILTER
+ float filter;
+ 1460H
+ RAY_BIAS
+ float bias;
+ 1500H
+ O_CONSTS
+ float plane_x, plane_y, plane_z;
+
+
+
+2xxxH Group
+
+ 2100H
+ AMBIENT_LIGHT
+ 2200H
+ FOG; followed by color_f, fog_bgnd
+ float near_plane, near_density;
+ float far_plane, far_density;
+ 2201H
+ USE_FOG
+ 2210H
+ FOG_BGND
+ 2300H
+ DISTANCE_CUE followed by dcue_bgnd
+ float near_plane, near_density;
+ float far_plane, far_density;
+ 2301H
+ USE_DISTANCE_CUE
+ 2302H
+ LAYER_FOG
+ float fog_z_from, fog_z_to;
+ float fog_density;
+ short fog_type;
+ 2303H
+ USE_LAYER_FOG
+ 2310H
+ DCUE_BGND
+ 2d2dH
+ SMAGIC
+ 2d3dH
+ LMAGIC
+
+
+
+3xxxH Group
+
+ 3000H
+ DEFAULT_VIEW
+ 3010H
+ VIEW_TOP
+ float targe_x, target_y, target_z;
+ float view_width;
+ 3020H
+ VIEW_BOTTOM
+ float targe_x, target_y, target_z;
+ float view_width;
+ 3030H
+ VIEW_LEFT
+ float targe_x, target_y, target_z;
+ float view_width;
+ 3040H
+ VIEW_RIGHT
+ float targe_x, target_y, target_z;
+ float view_width;
+ 3050H
+ VIEW_FRONT
+ float targe_x, target_y, target_z;
+ float view_width;
+ 3060H
+ VIEW_BACK
+ float targe_x, target_y, target_z;
+ float view_width;
+ 3070H
+ VIEW_USER
+ float targe_x, target_y, target_z;
+ float view_width;
+ 3080H
+ VIEW_CAMERA
+ cstr camera_name;
+ 3090H
+ VIEW_WINDOW
+ 3d3dH
+ MDATA; Mesh Data Magic Number (.3DS files sub of 4d4d)
+ 3d3eH
+ MESH_VERSION
+ 3daaH
+ MLIBMAGIC; Material Library Magic Number (.MLI files)
+ 3dc2H
+ PRJMAGIC; 3dS Project Magic Number (.PRJ files)
+ 3dffH
+ MATMAGIC; Material File Magic Number (.MAT files)
+
+
+
+4xxxH Group
+
+ 4000H
+ NAMED_OBJECT
+ cstr name;
+ 4010H
+ OBJ_HIDDEN
+ 4011H
+ OBJ_VIS_LOFTER
+ 4012H
+ OBJ_DOESNT_CAST
+ 4013H
+ OBJ_MATTE
+ 4014H
+ OBJ_FAST
+ 4015H
+ OBJ_PROCEDURAL
+ 4016H
+ OBJ_FROZEN
+ 4017H
+ OBJ_DONT_RCVSHADOW
+ 4100H
+ N_TRI_OBJECT
+ named triangle object
+ followed by point_array, point_flag_array, mesh_matrix,
+ face_array
+ 4110H
+ POINT_ARRAY
+ short npoints;
+ struct {
+ float x, y, z;
+ } points[npoints];
+ 4111H
+ POINT_FLAG_ARRAY
+ short nflags;
+ short flags[nflags];
+ 4120H
+ FACE_ARRAY may be followed by smooth_group
+ short nfaces;
+ struct {
+ short vertex1, vertex2, vertex3;
+ short flags;
+ } facearray[nfaces];
+ 4130H
+ MSH_MAT_GROUP mesh_material_group
+ cstr material_name;
+ short nfaces;
+ short facenum[nfaces];
+ 4131H
+ OLD_MAT_GROUP
+ 4140H
+ TEX_VERTS
+ short nverts;
+ struct {
+ float x, y;
+ } vertices[nverts];
+ 4150H
+ SMOOTH_GROUP
+ short grouplist[n]; determined by length, seems to be 4 per face
+ 4160H
+ MESH_MATRIX
+ float matrix[4][3];
+ 4165H
+ MESH_COLOR
+ short color_index;
+ 4170H
+ MESH_TEXTURE_INFO
+ short map_type;
+ float x_tiling, y_tiling;
+ float icon_x, icon_y, icon_z;
+ float matrix[4][3];
+ float scaling, plan_icon_w, plan_icon_h, cyl_icon_h;
+ 4181H
+ PROC_NAME
+ 4182H
+ PROC_DATA
+ 4190H
+ MSH_BOXMAP
+ 4400H
+ N_D_L_OLD
+ 4500H
+ N_CAM_OLD
+ 4600H
+ N_DIRECT_LIGHT; followed by color_f
+ float x, y, z;
+ 4610H
+ DL_SPOTLIGHT
+ float target_x, target_y, target_z;
+ float hotspot_ang;
+ float falloff_ang;
+ 4620H
+ DL_OFF
+ 4625H
+ DL_ATTENUATE
+ 4627H
+ DL_RAYSHAD
+ 4630H
+ DL_SHADOWED
+ 4640H
+ DL_LOCAL_SHADOW
+ 4641H
+ DL_LOCAL_SHADOW2
+ 4650H
+ DL_SEE_CONE
+ 4651H
+ DL_SPOT_RECTANGULAR
+ 4652H
+ DL_SPOT_OVERSHOOT
+ 4653H
+ DL_SPOT_PROJECTOR
+ 4654H
+ DL_EXCLUDE
+ 4655H
+ DL_RANGE
+ 4656H
+ DL_SPOT_ROLL
+ float roll_ang;
+ 4657H
+ DL_SPOT_ASPECT
+ 4658H
+ DL_RAY_BIAS
+ float bias;
+ 4659H
+ DL_INNER_RANGE
+ float range;
+ 465aH
+ DL_OUTER_RANGE
+ float range;
+ 465bH
+ DL_MULTIPLIER
+ float multiple;
+ 4680H
+ N_AMBIENT_LIGHT
+ 4700H
+ N_CAMERA
+ float camera_x, camera_y, camera_z;
+ float target_x, target_y, target_z;
+ float bank_angle;
+ float focus;
+ 4710H
+ CAM_SEE_CONE
+ 4720H
+ CAM_RANGES
+ float near_range, far_range;
+ 4d4dH
+ M3DMAGIC; 3DS Magic Number (.3DS file)
+ 4f00H
+ HIERARCHY
+ 4f10H
+ PARENT_OBJECT
+ 4f20H
+ PIVOT_OBJECT
+ 4f30H
+ PIVOT_LIMITS
+ 4f40H
+ PIVOT_ORDER
+ 4f50H
+ XLATE_RANGE
+
+
+
+5xxxH Group
+
+ 5000H
+ POLY_2D
+ 5010H
+ SHAPE_OK
+ 5011H
+ SHAPE_NOT_OK
+ 5020H
+ SHAPE_HOOK
+
+
+
+6xxxH Group
+
+ 6000H
+ PATH_3D
+ 6005H
+ PATH_MATRIX
+ 6010H
+ SHAPE_2D
+ 6020H
+ M_SCALE
+ 6030H
+ M_TWIST
+ 6040H
+ M_TEETER
+ 6050H
+ M_FIT
+ 6060H
+ M_BEVEL
+ 6070H
+ XZ_CURVE
+ 6080H
+ YZ_CURVE
+ 6090H
+ INTERPCT
+ 60a0H
+ DEFORM_LIMIT
+ 6100H
+ USE_CONTOUR
+ 6110H
+ USE_TWEEN
+ 6120H
+ USE_SCALE
+ 6130H
+ USE_TWIST
+ 6140H
+ USE_TEETER
+ 6150H
+ USE_FIT
+ 6160H
+ USE_BEVEL
+
+
+
+7xxxH Group
+
+ 7000H
+ VIEWPORT_LAYOUT_OLD
+ 7001H
+ VIEWPORT_LAYOUT; followed by viewport_size, viewport_data
+ short form, top, ready, wstate, swapws, swapport, swapcur;
+ 7010H
+ VIEWPORT_DATA_OLD
+ 7011H
+ VIEWPORT_DATA
+ short flags, axis_lockout;
+ short win_x, win_y, win_w, winh_, win_view;
+ float zoom;
+ float worldcenter_x, worldcenter_y, worldcenter_z;
+ float horiz_ang, vert_ang;
+ cstr camera_name;
+ 7012H
+ VIEWPORT_DATA_3
+ short flags, axis_lockout;
+ short win_x, win_y, win_w, winh_, win_view;
+ float zoom;
+ float worldcenter_x, worldcenter_y, worldcenter_z;
+ float horiz_ang, vert_ang;
+ cstr camera_name;
+ 7020H
+ VIEWPORT_SIZE
+ short x, y, w, h;
+ 7030H
+ NETWORK_VIEW
+
+
+
+8xxxH Group
+
+ 8000H
+ XDATA_SECTION
+ 8001H
+ XDATA_ENTRY
+ 8002H
+ XDATA_APPNAME
+ 8003H
+ XDATA_STRING
+ 8004H
+ XDATA_FLOAT
+ 8005H
+ XDATA_DOUBLE
+ 8006H
+ XDATA_SHORT
+ 8007H
+ XDATA_LONG
+ 8008H
+ XDATA_VOID
+ 8009H
+ XDATA_GROUP
+ 800aH
+ XDATA_RFU6
+ 800bH
+ XDATA_RFU5
+ 800cH
+ XDATA_RFU4
+ 800dH
+ XDATA_RFU3
+ 800eH
+ XDATA_RFU2
+ 800fH
+ XDATA_RFU1
+ 80f0H
+ PARENT_NAME
+
+
+
+AxxxH Group
+
+ a000H
+ MAT_NAME
+ cstr material_name;
+ a010H
+ MAT_AMBIENT; followed by color chunk
+ a020H
+ MAT_DIFFUSE; followed by color chunk
+ a030H
+ MAT_SPECULAR; followed by color chunk
+ a040H
+ MAT_SHININESS; followed by percentage chunk
+ a041H
+ MAT_SHIN2PCT; followed by percentage chunk
+ a042H
+ MAT_SHIN3PCT; followed by percentage chunk
+ a050H
+ MAT_TRANSPARENCY; followed by percentage chunk
+ a052H
+ MAT_XPFALL; followed by percentage chunk
+ a053H
+ MAT_REFBLUR; followed by percentage chunk
+ a080H
+ MAT_SELF_ILLUM
+ a081H
+ MAT_TWO_SIDE
+ a082H
+ MAT_DECAL
+ a083H
+ MAT_ADDITIVE
+ a084H
+ MAT_SELF_ILPCT; followed by percentage chunk
+ a085H
+ MAT_WIRE
+ a086H
+ MAT_SUPERSMP
+ a087H
+ MAT_WIRESIZE
+ float wire_size;
+ a088H
+ MAT_FACEMAP
+ a08aH
+ MAT_XPFALLIN
+ a08cH
+ MAT_PHONGSOFT
+ a08eH
+ MAT_WIREABS
+ a100H
+ MAT_SHADING
+ short shading_value;
+ a200H
+ MAT_TEXMAP; followed by percentage chunk, mat_mapname,
+ mat_map_tiling, mat_map_texblur...
+ a204H
+ MAT_SPECMAP; followed by percentage_chunk, mat_mapname
+ a210H
+ MAT_OPACMAP; followed by percentage_chunk, mat_mapname
+ a220H
+ MAT_REFLMAP; followed by percentage_chunk, mat_mapname
+ a230H
+ MAT_BUMPMAP; followed by percentage_chunk, mat_mapname
+ a240H
+ MAT_USE_XPFALL
+ a250H
+ MAT_USE_REFBLUR
+ a252H
+ MAT_BUMP_PERCENT
+ a300H
+ MAT_MAPNAME
+ cstr filename;
+ a310H
+ MAT_ACUBIC
+ a320H
+ MAT_SXP_TEXT_DATA
+ a321H
+ MAT_SXP_TEXT2_DATA
+ a322H
+ MAT_SXP_OPAC_DATA
+ a324H
+ MAT_SXP_BUMP_DATA
+ a325H
+ MAT_SXP_SPEC_DATA
+ a326H
+ MAT_SXP_SHIN_DATA
+ a328H
+ MAT_SXP_SELFI_DATA
+ a32aH
+ MAT_SXP_TEXT_MASKDATA
+ a32cH
+ MAT_SXP_TEXT2_MASKDATA
+ a32eH
+ MAT_SXP_OPAC_MASKDATA
+ a330H
+ MAT_SXP_BUMP_MASKDATA
+ a332H
+ MAT_SXP_SPEC_MASKDATA
+ a334H
+ MAT_SXP_SHIN_MASKDATA
+ a336H
+ MAT_SXP_SELFI_MASKDATA
+ a338H
+ MAT_SXP_REFL_MASKDATA
+ a33aH
+ MAT_TEX2MAP
+ a33cH
+ MAT_SHINMAP
+ a33dH
+ MAT_SELFIMAP
+ a33eH
+ MAT_TEXMASK
+ a340H
+ MAT_TEX2MASK
+ a342H
+ MAT_OPACMASK
+ a344H
+ MAT_BUMPMASK
+ a346H
+ MAT_SHINMASK
+ a348H
+ MAT_SPECMASK
+ a34aH
+ MAT_SELFIMASK
+ a34cH
+ MAT_REFLMASK
+ a350H
+ MAT_MAP_TILINGOLD
+ a351H
+ MAT_MAP_TILING
+ short flags;
+ a352H
+ MAT_MAP_TEXBLUR_OLD
+ a353H
+ MAT_MAP_TEXBLUR
+ float blurring;
+ a354H
+ MAT_MAP_USCALE
+ a356H
+ MAT_MAP_VSCALE
+ a358H
+ MAT_MAP_UOFFSET
+ a35aH
+ MAT_MAP_VOFFSET
+ a35cH
+ MAT_MAP_ANG
+ a360H
+ MAT_MAP_COL1
+ a362H
+ MAT_MAP_COL2
+ a364H
+ MAT_MAP_RCOL
+ a366H
+ MAT_MAP_GCOL
+ a368H
+ MAT_MAP_BCOL
+ afffH
+ MAT_ENTRY
+
+
+
+BxxxH Group
+
+ b000H
+ KFDATA; followed by kfhdr
+ b001H
+ AMBIENT_NODE_TAG
+ b002H
+ OBJECT_NODE_TAG; followed by node_hdr, pivot, pos_track_tag,
+ rot_track_tag, scl_track_tag, morph_smooth...
+ b003H
+ CAMERA_NODE_TAG; followed by node_hdr, pos_track_tag, fov_track_tag,
+ roll_track_tag...
+ b004H
+ TARGET_NODE_TAG; followed by node_hdr, pos_track_tag...
+ b005H
+ LIGHT_NODE_TAG; followed by node_hdr, pos_track_tag, col_track_tag...
+ b006H
+ L_TARGET_NODE_TAG; followed by node_id, node_hdr, pos_track_tag
+ b007H
+ SPOTLIGHT_NODE_TAG; followed by node_id, node_hdr, pos_track_tag,
+ hot_track_tag, fall_track_tag, roll_track_tag, col_track_tag...
+ b008H
+ KFSEG
+ short start, end;
+ b009H
+ KFCURTIME
+ short curframe;
+ b00aH
+ KFHDR followed by viewport_layout, kfseg, kfcurtime, object_node_tag,
+ light_node_tag, target_node_tag, camera_node_tag, l_target_node_tag,
+ spotlight_node_tag, ambient_node_tag...
+ short revision;
+ cstr filename;
+ short animlen;
+ b010H
+ NODE_HDR
+ cstr objname;
+ short flags1;
+ short flags2;
+ short heirarchy; ?
+ b011H
+ INSTANCE_NAME
+ b012H
+ PRESCALE
+ b013H
+ PIVOT
+ float pivot_x, pivot_y, pivot_z;
+ b014H
+ BOUNDBOX
+ b015H
+ MORPH_SMOOTH
+ float morph_smoothing_angle_rad;
+ b020H
+ POS_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float pos_x, pos_y, pos_z;
+ } pos[keys];
+ b021H
+ ROT_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float rotation_rad;
+ float axis_x, axis_y, axis_z;
+ } rot[keys];
+ b022H
+ SCL_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float scale_x, scale_y, scale_z;
+ } scale[keys];
+ b023H
+ FOV_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float camera_field_of_view;
+ } fov[keys]
+ b024H
+ ROLL_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float camera_roll;
+ } roll[keys];
+ b025H
+ COL_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float red, rgn, blu;
+ } color[keys];
+ b026H
+ MORPH_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ cstr obj_name;
+ } morph[keys];
+ b027H
+ HOT_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float hotspot_ang;
+ } hotspot[keys];
+ b028H
+ FALL_TRACK_TAG
+ short flags;
+ short unknown[4];
+ short keys;
+ short unknown;
+ struct {
+ short framenum;
+ long unknown;
+ float falloff_ang;
+ } falloff[keys];
+ b029H
+ HIDE_TRACK_TAG
+ b030H
+ NODE_ID
+ short id;
+
+
+
+CxxxH Group
+
+ c010H
+ C_MDRAWER
+ c020H
+ C_TDRAWER
+ c030H
+ C_SHPDRAWER
+ c040H
+ C_MODDRAWER
+ c050H
+ C_RIPDRAWER
+ c060H
+ C_TXDRAWER
+ c062H
+ C_PDRAWER
+ c064H
+ C_MTLDRAWER
+ c066H
+ C_FLIDRAWER
+ c067H
+ C_CUBDRAWER
+ c070H
+ C_MFILE
+ c080H
+ C_SHPFILE
+ c090H
+ C_MODFILE
+ c0a0H
+ C_RIPFILE
+ c0b0H
+ C_TXFILE
+ c0b2H
+ C_PFILE
+ c0b4H
+ C_MTLFILE
+ c0b6H
+ C_FLIFILE
+ c0b8H
+ C_PALFILE
+ c0c0H
+ C_TX_STRING
+ c0d0H
+ C_CONSTS
+ c0e0H
+ C_SNAPS
+ c0f0H
+ C_GRIDS
+ c100H
+ C_ASNAPS
+ c110H
+ C_GRID_RANGE
+ c120H
+ C_RENDTYPE
+ c130H
+ C_PROGMODE
+ c140H
+ C_PREVMODE
+ c150H
+ C_MODWMODE
+ c160H
+ C_MODMODEL
+ c170H
+ C_ALL_LINES
+ c180H
+ C_BACK_TYPE
+ c190H
+ C_MD_CS
+ c1a0H
+ C_MD_CE
+ c1b0H
+ C_MD_SML
+ c1c0H
+ C_MD_SMW
+ c1c3H
+ C_LOFT_WITH_TEXTURE
+ c1c4H
+ C_LOFT_L_REPEAT
+ c1c5H
+ C_LOFT_W_REPEAT
+ c1c6H
+ C_LOFT_UV_NORMALIZE
+ c1c7H
+ C_WELD_LOFT
+ c1d0H
+ C_MD_PDET
+ c1e0H
+ C_MD_SDET
+ c1f0H
+ C_RGB_RMODE
+ c200H
+ C_RGB_HIDE
+ c202H
+ C_RGB_MAPSW
+ c204H
+ C_RGB_TWOSIDE
+ c208H
+ C_RGB_SHADOW
+ c210H
+ C_RGB_AA
+ c220H
+ C_RGB_OVW
+ c230H
+ C_RGB_OVH
+ c23dH
+ CMAGIC
+ c240H
+ C_RGB_PICTYPE
+ c250H
+ C_RGB_OUTPUT
+ c253H
+ C_RGB_TODISK
+ c254H
+ C_RGB_COMPRESS
+ c255H
+ C_JPEG_COMPRESSION
+ c256H
+ C_RGB_DISPDEV
+ c259H
+ C_RGB_HARDDEV
+ c25aH
+ C_RGB_PATH
+ c25bH
+ C_BITMAP_DRAWER
+ c260H
+ C_RGB_FILE
+ c270H
+ C_RGB_OVASPECT
+ c271H
+ C_RGB_ANIMTYPE
+ c272H
+ C_RENDER_ALL
+ c273H
+ C_REND_FROM
+ c274H
+ C_REND_TO
+ c275H
+ C_REND_NTH
+ c276H
+ C_PAL_TYPE
+ c277H
+ C_RND_TURBO
+ c278H
+ C_RND_MIP
+ c279H
+ C_BGND_METHOD
+ c27aH
+ C_AUTO_REFLECT
+ c27bH
+ C_VP_FROM
+ c27cH
+ C_VP_TO
+ c27dH
+ C_VP_NTH
+ c27eH
+ C_REND_TSTEP
+ c27fH
+ C_VP_TSTEP
+ c280H
+ C_SRDIAM
+ c290H
+ C_SRDEG
+ c2a0H
+ C_SRSEG
+ c2b0H
+ C_SRDIR
+ c2c0H
+ C_HETOP
+ c2d0H
+ C_HEBOT
+ c2e0H
+ C_HEHT
+ c2f0H
+ C_HETURNS
+ c300H
+ C_HEDEG
+ c310H
+ C_HESEG
+ c320H
+ C_HEDIR
+ c330H
+ C_QUIKSTUFF
+ c340H
+ C_SEE_LIGHTS
+ c350H
+ C_SEE_CAMERAS
+ c360H
+ C_SEE_3D
+ c370H
+ C_MESHSEL
+ c380H
+ C_MESHUNSEL
+ c390H
+ C_POLYSEL
+ c3a0H
+ C_POLYUNSEL
+ c3a2H
+ C_SHPLOCAL
+ c3a4H
+ C_MSHLOCAL
+ c3b0H
+ C_NUM_FORMAT
+ c3c0H
+ C_ARCH_DENOM
+ c3d0H
+ C_IN_DEVICE
+ c3e0H
+ C_MSCALE
+ c3f0H
+ C_COMM_PORT
+ c400H
+ C_TAB_BASES
+ c410H
+ C_TAB_DIVS
+ c420H
+ C_MASTER_SCALES
+ c430H
+ C_SHOW_1STVERT
+ c440H
+ C_SHAPER_OK
+ c450H
+ C_LOFTER_OK
+ c460H
+ C_EDITOR_OK
+ c470H
+ C_KEYFRAMER_OK
+ c480H
+ C_PICKSIZE
+ c490H
+ C_MAPTYPE
+ c4a0H
+ C_MAP_DISPLAY
+ c4b0H
+ C_TILE_XY
+ c4c0H
+ C_MAP_XYZ
+ c4d0H
+ C_MAP_SCALE
+ c4e0H
+ C_MAP_MATRIX_OLD
+ c4e1H
+ C_MAP_MATRIX
+ c4f0H
+ C_MAP_WID_HT
+ c500H
+ C_OBNAME
+ c510H
+ C_CAMNAME
+ c520H
+ C_LTNAME
+ c525H
+ C_CUR_MNAME
+ c526H
+ C_CURMTL_FROM_MESH
+ c527H
+ C_GET_SHAPE_MAKE_FACES
+ c530H
+ C_DETAIL
+ c540H
+ C_VERTMARK
+ c550H
+ C_MSHAX
+ c560H
+ C_MSHCP
+ c570H
+ C_USERAX
+ c580H
+ C_SHOOK
+ c590H
+ C_RAX
+ c5a0H
+ C_STAPE
+ c5b0H
+ C_LTAPE
+ c5c0H
+ C_ETAPE
+ c5c8H
+ C_KTAPE
+ c5d0H
+ C_SPHSEGS
+ c5e0H
+ C_GEOSMOOTH
+ c5f0H
+ C_HEMISEGS
+ c600H
+ C_PRISMSEGS
+ c610H
+ C_PRISMSIDES
+ c620H
+ C_TUBESEGS
+ c630H
+ C_TUBESIDES
+ c640H
+ C_TORSEGS
+ c650H
+ C_TORSIDES
+ c660H
+ C_CONESIDES
+ c661H
+ C_CONESEGS
+ c670H
+ C_NGPARMS
+ c680H
+ C_PTHLEVEL
+ c690H
+ C_MSCSYM
+ c6a0H
+ C_MFTSYM
+ c6b0H
+ C_MTTSYM
+ c6c0H
+ C_SMOOTHING
+ c6d0H
+ C_MODICOUNT
+ c6e0H
+ C_FONTSEL
+ c6f0H
+ C_TESS_TYPE
+ c6f1H
+ C_TESS_TENSION
+ c700H
+ C_SEG_START
+ c705H
+ C_SEG_END
+ c710H
+ C_CURTIME
+ c715H
+ C_ANIMLENGTH
+ c720H
+ C_PV_FROM
+ c725H
+ C_PV_TO
+ c730H
+ C_PV_DOFNUM
+ c735H
+ C_PV_RNG
+ c740H
+ C_PV_NTH
+ c745H
+ C_PV_TYPE
+ c750H
+ C_PV_METHOD
+ c755H
+ C_PV_FPS
+ c765H
+ C_VTR_FRAMES
+ c770H
+ C_VTR_HDTL
+ c771H
+ C_VTR_HD
+ c772H
+ C_VTR_TL
+ c775H
+ C_VTR_IN
+ c780H
+ C_VTR_PK
+ c785H
+ C_VTR_SH
+ c790H
+ C_WORK_MTLS
+ c792H
+ C_WORK_MTLS_2
+ c793H
+ C_WORK_MTLS_3
+ c794H
+ C_WORK_MTLS_4
+ c7a1H
+ C_BGTYPE
+ c7b0H
+ C_MEDTILE
+ c7d0H
+ C_LO_CONTRAST
+ c7d1H
+ C_HI_CONTRAST
+ c7e0H
+ C_FROZ_DISPLAY
+ c7f0H
+ C_BOOLWELD
+ c7f1H
+ C_BOOLTYPE
+ c900H
+ C_ANG_THRESH
+ c901H
+ C_SS_THRESH
+ c903H
+ C_TEXTURE_BLUR_DEFAULT
+ ca00H
+ C_MAPDRAWER
+ ca01H
+ C_MAPDRAWER1
+ ca02H
+ C_MAPDRAWER2
+ ca03H
+ C_MAPDRAWER3
+ ca04H
+ C_MAPDRAWER4
+ ca05H
+ C_MAPDRAWER5
+ ca06H
+ C_MAPDRAWER6
+ ca07H
+ C_MAPDRAWER7
+ ca08H
+ C_MAPDRAWER8
+ ca09H
+ C_MAPDRAWER9
+ ca10H
+ C_MAPDRAWER_ENTRY
+ ca20H
+ C_BACKUP_FILE
+ ca21H
+ C_DITHER_256
+ ca22H
+ C_SAVE_LAST
+ ca23H
+ C_USE_ALPHA
+ ca24H
+ C_TGA_DEPTH
+ ca25H
+ C_REND_FIELDS
+ ca26H
+ C_REFLIP
+ ca27H
+ C_SEL_ITEMTOG
+ ca28H
+ C_SEL_RESET
+ ca29H
+ C_STICKY_KEYINF
+ ca2aH
+ C_WELD_THRESHOLD
+ ca2bH
+ C_ZCLIP_POINT
+ ca2cH
+ C_ALPHA_SPLIT
+ ca30H
+ C_KF_SHOW_BACKFACE
+ ca40H
+ C_OPTIMIZE_LOFT
+ ca42H
+ C_TENS_DEFAULT
+ ca44H
+ C_CONT_DEFAULT
+ ca46H
+ C_BIAS_DEFAULT
+ ca50H
+ C_DXFNAME_SRC
+ ca60H
+ C_AUTO_WELD
+ ca70H
+ C_AUTO_UNIFY
+ ca80H
+ C_AUTO_SMOOTH
+ ca90H
+ C_DXF_SMOOTH_ANG
+ caa0H
+ C_SMOOTH_ANG
+ cb00H
+ C_WORK_MTLS_5
+ cb01H
+ C_WORK_MTLS_6
+ cb02H
+ C_WORK_MTLS_7
+ cb03H
+ C_WORK_MTLS_8
+ cb04H
+ C_WORKMTL
+ cb10H
+ C_SXP_TEXT_DATA
+ cb11H
+ C_SXP_OPAC_DATA
+ cb12H
+ C_SXP_BUMP_DATA
+ cb13H
+ C_SXP_SHIN_DATA
+ cb20H
+ C_SXP_TEXT2_DATA
+ cb24H
+ C_SXP_SPEC_DATA
+ cb28H
+ C_SXP_SELFI_DATA
+ cb30H
+ C_SXP_TEXT_MASKDATA
+ cb32H
+ C_SXP_TEXT2_MASKDATA
+ cb34H
+ C_SXP_OPAC_MASKDATA
+ cb36H
+ C_SXP_BUMP_MASKDATA
+ cb38H
+ C_SXP_SPEC_MASKDATA
+ cb3aH
+ C_SXP_SHIN_MASKDATA
+ cb3eH
+ C_SXP_REFL_MASKDATA
+ cc00H
+ C_NET_USE_VPOST
+ cc10H
+ C_NET_USE_GAMMA
+ cc20H
+ C_NET_FIELD_ORDER
+ cd00H
+ C_BLUR_FRAMES
+ cd10H
+ C_BLUR_SAMPLES
+ cd20H
+ C_BLUR_DUR
+ cd30H
+ C_HOT_METHOD
+ cd40H
+ C_HOT_CHECK
+ cd50H
+ C_PIXEL_SIZE
+ cd60H
+ C_DISP_GAMMA
+ cd70H
+ C_FBUF_GAMMA
+ cd80H
+ C_FILE_OUT_GAMMA
+ cd82H
+ C_FILE_IN_GAMMA
+ cd84H
+ C_GAMMA_CORRECT
+ cd90H
+ C_APPLY_DISP_GAMMA
+ cda0H
+ C_APPLY_FBUF_GAMMA
+ cdb0H
+ C_APPLY_FILE_GAMMA
+ cdc0H
+ C_FORCE_WIRE
+ cdd0H
+ C_RAY_SHADOWS
+ cde0H
+ C_MASTER_AMBIENT
+ cdf0H
+ C_SUPER_SAMPLE
+ ce00H
+ C_OBJECT_MBLUR
+ ce10H
+ C_MBLUR_DITHER
+ ce20H
+ C_DITHER_24
+ ce30H
+ C_SUPER_BLACK
+ ce40H
+ C_SAFE_FRAME
+ ce50H
+ C_VIEW_PRES_RATIO
+ ce60H
+ C_BGND_PRES_RATIO
+ ce70H
+ C_NTH_SERIAL_NUM
+
+
+
+DxxxH Group
+
+ d000H
+ VPDATA
+ d100H
+ P_QUEUE_ENTRY
+ d110H
+ P_QUEUE_IMAGE
+ d114H
+ P_QUEUE_USEIGAMMA
+ d120H
+ P_QUEUE_PROC
+ d130H
+ P_QUEUE_SOLID
+ d140H
+ P_QUEUE_GRADIENT
+ d150H
+ P_QUEUE_KF
+ d152H
+ P_QUEUE_MOTBLUR
+ d153H
+ P_QUEUE_MB_REPEAT
+ d160H
+ P_QUEUE_NONE
+ d180H
+ P_QUEUE_RESIZE
+ d185H
+ P_QUEUE_OFFSET
+ d190H
+ P_QUEUE_ALIGN
+ d1a0H
+ P_CUSTOM_SIZE
+ d210H
+ P_ALPH_NONE
+ d220H
+ P_ALPH_PSEUDO
+ d221H
+ P_ALPH_OP_PSEUDO
+ d222H
+ P_ALPH_BLUR
+ d225H
+ P_ALPH_PCOL
+ d230H
+ P_ALPH_C0
+ d231H
+ P_ALPH_OP_KEY
+ d235H
+ P_ALPH_KCOL
+ d238H
+ P_ALPH_OP_NOCONV
+ d240H
+ P_ALPH_IMAGE
+ d250H
+ P_ALPH_ALPHA
+ d260H
+ P_ALPH_QUES
+ d265H
+ P_ALPH_QUEIMG
+ d270H
+ P_ALPH_CUTOFF
+ d280H
+ P_ALPHANEG
+ d300H
+ P_TRAN_NONE
+ d310H
+ P_TRAN_IMAGE
+ d312H
+ P_TRAN_FRAMES
+ d320H
+ P_TRAN_FADEIN
+ d330H
+ P_TRAN_FADEOUT
+ d340H
+ P_TRANNEG
+ d400H
+ P_RANGES
+ d500H
+ P_PROC_DATA
+
+
+
+FxxxH Group
+
+ f020H
+ POS_TRACK_TAG_KEY
+ f021H
+ ROT_TRACK_TAG_KEY
+ f022H
+ SCL_TRACK_TAG_KEY
+ f023H
+ FOV_TRACK_TAG_KEY
+ f024H
+ ROLL_TRACK_TAG_KEY
+ f025H
+ COL_TRACK_TAG_KEY
+ f026H
+ MORPH_TRACK_TAG_KEY
+ f027H
+ HOT_TRACK_TAG_KEY
+ f028H
+ FALL_TRACK_TAG_KEY
+ f110H
+ POINT_ARRAY_ENTRY
+ f111H
+ POINT_FLAG_ARRAY_ENTRY
+ f120H
+ FACE_ARRAY_ENTRY
+ f130H
+ MSH_MAT_GROUP_ENTRY
+ f140H
+ TEX_VERTS_ENTRY
+ f150H
+ SMOOTH_GROUP_ENTRY
+ ffffH
+ DUMMY
+
+
+
+
+
+
+
+The Unofficial 3DStudio 3DS File Format / CR-MM / mediatel-admin@mediatel.lu
+
+
+
+
+--------------------------------------------------------------------------------
+
+
+Comments? Send them to: webmaster@filespecs.com
+
+
+Copyright 2001 BreakPoint Software, Inc. All Rights Reserved.
diff --git a/Doc/AI.TXT b/Doc/AI.txt
index 40071ca..2396a33 100644
--- a/Doc/AI.TXT
+++ b/Doc/AI.txt
@@ -1,1248 +1,1248 @@
-==================== STARSHATTER ====================
- ACTION
-
-Starshatter is a 3D action-simulation game in a space
-combat setting. The player will control a space
-ship of one type or another, and attempt to defeat
-various enemy forces composed of small, medium
-and large space ships, space stations, and ground-
-based resources.
-
-The game is designed as a series of combat missions
-in which the goal is to destroy an enemy resource,
-secure an enemy position, or defend a friendly resource
-from an enemy attack. Unlike most space combat sims,
-Starshatter missions are fought within the context of
-a large dynamic military operation.
-
-In the attack type of mission, victory is achieved
-by destroying the resource(s) and escaping to safety.
-In the secure and defend types of missions, victory is
-achieved by preventing the destruction of the resource
-while simultaneously destroying the enemy or forcing
-the enemy to retire. In any mission, achieving a
-partial victory is a possibility.
-
-Individual mission designs will be characterized by:
-1) the locale, including various space bodies such as
- stars, planets, planetoids, asteroid fields, space
- stations, nebulae, terrain, cities, and so forth
-2) the composition and placement of enemy forces
-3) the composition and placement of friendly or neutral
- forces, if any
-4) the objectives / resources / victory conditions
- for each force element
-
-
-RELEVANT TECHNOLOGY:
-
-Space ships and ground units are each endowed with a
-group of resources that they use in battle. These
-resources fall into eight different categories:
-
-Ship System List:
-
- 1. Vital (Hull/Stabilizer/Core/Life Support)
- 2. Econ (power management)
- 3. Conventional Drive
- 4. Hyperdrive (optional)
- 5. Shields
- 6. Weapons
- 7. Flight Ops (optional)
- 8.* Systems (computer)
- a.Communications
- b.Sensors
- c.GNC
- d.Tactical (target tracking)
-
-Large space ships are capable of supralight travel by
-means of "hyperdrive," which is similar to the same
-concepts used in Star Wars and Babylon 5.
-
-Smaller ships (fighters, attack) are not capable of long
-distance travel using hyperdrive, and must be carried
-to and from missions by a larger ship (a destroyer or cruiser).
-
-All combat will occur at sublight velocities using
-conventional plasma projection or fusion drive. However,
-damage to the hyperdrive may effect the outcome of a
-mission (e.g. by delaying a safe escape).
-
-Ships and ground targets may employ various types of
-weapons, both matter and radiant energy based. From
-the AI's point of view, all weapons are of one of three
-different types: guided, unguided, or regional. Guided
-weapons include their own AI to direct their flight path
-to a target. Unguided weapons simply follow the straight
-line course set for them at launch time. Regional weapons
-inflict damage on any resources that happen to occupy the
-same volume of space as the weapon during its deployment.
-Any single ship or ground target may employ several fire
-control AI systems to manage multiple beam weapons and
-missile launchers.
-
-Ships and ground targets may employ defensive screens
-or shields. These shields are invisible barriers that
-prevent the transmission of both matter and radiant
-energy weapons. Shields (actually, shield generators)
-are degraded by the process of deflecting weapons and
-will eventually burn out, leaving the ship open to
-attack. Larger ships will employ multiple shield
-generators to screen various parts of the ship. In
-addition, larger ships can mount more robust shield
-technology, requiring heavier weapons to penetrate.
-
-Laser/Particle Beam cannon types:
-* Alpha
-* Gamma
-* Delta
-* Omega
-
-Explosive Missile weapon types:
-* Pyrotechnic
-* Thermonuclear
-* Antimatter
-* Varion (Torpedo)
-
-In addition to basic laser and explosive missile types
-of weapons, Starshatter features several advanced weapon
-types:
-
-* Cruise Missiles (very long range guided munition)
-* Bomb-pumped Laser Warheads
-* CIWS Laser Turrets
-
-* Plasma Cannon (very high power energy weapon)
-* Fusion Burst (ultra high power energy weapon)
-* Graviton Pulse (goes through all shields)
-
-Whenever any ship system takes damage, the capabilities
-of the ship in that area are temporarily or permanently
-downgraded. Most systems are capable of limited self-
-repair. Safe bases will be provided for full repair
-both during and between missions.
-
-Although there will be no powerups just lying around,
-there will be both friendly and enemy supply ships on
-each mission. Small ships can resupply themselves at
-any time by docking with a friendly supply depot or
-ship.
-
-While ships are grouped into the broad categories of
-"large," "medium," and "small", there are several
-distinct classes within those categories. Ships in
-each class will have typical size parameters as
-follows:
-
- CLASS LENGTH (m) CREW
- ----------- ----------- -------
- Fighter 10-20 1 Small
- Attack 25-50 2-3
- Destroyer 200+ Medium
- Cruiser 400+
- Battleship 800+ Large
- Carrier 1000+
-
- Station unlimited
-
-As the class names indicate, small ships are analogous
-to modern combat aircraft, while medium and large ships
-are analogous to modern naval surface warships. Medium
-and large ships are sometimes referred to as "Starships"
-because they are capable of interstellar travel.
-
-Medium ships may be outfitted with towing rigs. Large
-ships may be outfitted with flight decks. Both of these
-can be used to capture a ship. Flight decks can also
-be used to repair and re-supply smaller ships.
-
-Ships may be organized into battle groups that are led
-by a "flagship." The flagship is responsible for the
-general direction of the other ships in the battle group.
-This includes such things as setting the overall state
-of readiness, prioritizing targets, and deciding to
-pursue or retire.
-
-==================== STARSHATTER ====================
- TACTICS
-
-Aside:
-
-I really want to avoid the typical "furball" (as seen
-in XvT, WCn, etc.) as much as possible. One thing I've
-always liked about DOOM style games is the measured pace
-of the action. During the course of a single level, the
-player faces a variety of enemies and situations in small
-packets, controlled by the level architecture. I would
-like to mimic this in Starshatter somehow, but the "open-
-ness" of the space setting makes it difficult.
-
-Some ideas:
-
-Missions will be sliced up into sections by distance and
-obstacles. So there might be a group of sentry ships to
-defeat as you enter the playfield, followed by a short
-flight to the next enemy force package. The enemy will
-be somewhat slow to react to the player's presence. Per-
-haps enemy ships will need to stick close by other resources
-on guard duty or some such.
-
-A challenge:
-
-Unlike DOOM, the player and enemy ships have the same
-capabilities. This means that with reasonable AI, the
-player will get killed about as often as the enemies.
-As a result, if the player is vastly out-numbered as
-usual he won't last very long with even odds. Result:
-we may need to fudge the damage on the player's ship
-somewhat to give him an edge. Either that, or the
-player will only be allowed to battle one or two enemy
-ships at a time. Or, the enemy AI should preferentially
-attack red-shirt pilots instead of the player.
-
-USING HYPERDRIVE:
-
-How about, most ships are equipped with hyperdrive.
-This allows the player to travel to places that are too
-far away to be seen with tactical scanners. In effect,
-jumping through hyperspace places "doors" between scenes
-of action.
-
-Let's postulate that hyperdrive allows supra-light travel
-at some ridiculous velocity. While in hyperspace the ship
-is essentially impervious to everything except gravitons.
-If the ship passes too close to a gravity well or gravitic
-weapon, the hyperdrive will "stall". The ship will return
-to normal space, and the hyperdrive will be offline for
-several seconds.
-
-Further postulate that shields and weapons are powered
-down during hyperspace transit. So you can run, or you
-can fight, but not both at the same time.
-
-While in hyperspace, the player can pilot the ship in
-the usual manner (or perhaps just using the keyboard),
-but the ship is no longer as agile (perhaps 1/5th as
-agile as in sublight flight, perhaps this is variable
-depending on ship design). The point is that the player
-can point and go, without some hokey "warp out" animation
-sequence.
-
-Of course, it's a big universe out there. There is no
-point in *making* the player wander around in the middle
-of nowhere for an hour because he overshot the battle. So
-we will also provide a nav map with preset way points.
-The player can plot a course to anywhere in the mission
-profile by clicking on the way points and pressing "GO".
-While under "auto-pilot" like this, the player can still
-operate all of the ship systems, review the database, etc.
-Nav courses can also be pre-plotted as part of the mission
-profile. Nav points should be reasonably close together,
-so as to provide a "breather" but not "boredom".
-
-At any time, the player can steer the ship and break out
-of autopilot, without the navigation system forgetting
-the plan. This provides a nice possibility of "secret areas"
-like checking for the secret base on the far side of the
-3rd moon.
-
-While in hyperspace, the view of the universe is altered.
-Sublight ships are invisible, as is space dust. Planets
-and other gravity wells are important, so these are still
-visible in some way. Probably want to replace the "star
-and nebula" sky shell with something more distinctive, a'la
-Bab5 hyperspace, might be nice to have it be animated.
-
-Even though you never see your own ship go into hyperspace,
-it would be great to have a suitable special effect for when
-another ship does so. Perhaps something like the spiral
-smoke trail from "Eraser". Whatever it is, it has to convey
-a sense of speed (without silly elongation effects or fake
-motion blur).
-
-SENSORS AND SCOUTING:
-
-Ships will have access to both passive (short range) and
-active (long range) sensors. Passive sensors rely on the
-detection of radiation emissions from target ship systems
-such as shields, weapons, drive, reactors, active sensors,
-and communications (this is analogous to IR or passive sonar).
-Active sensors transmit an energy beam into space and detect
-the "echo" of the energy bouncing off a target ship (in a
-manner analogous to radar or active sonar).
-
-The fundamental strategy of scouting is to detect the enemy
-targets while simultaneously thwarting the enemy's attempt
-to detect the player. The basic tool for implementing this
-strategy is Emission Control. The player must balance the
-energy output of his own ship against the ability of the
-enemy to detect and target him.
-
-The ships will have an Emission Control system, with a range
-of EmCon options. As the EmCon level is increased, more
-ship systems are enabled and allowed to radiate. The ship's
-computer will attempt to minimize the EmCon level to the
-greatest degree in accordance with safety. If unfriendly
-ships are detected at close range, the computer will increase
-the EmCon level to allow the use of shields and weapon systems.
-The player can also override the automatic EmCon setting in
-situations where stealth is paramount.
-
-Each ship will be modeled by a passive and active sensor
-cross-section. The passive cross-section (PCS) is a dynamic
-number that represents the current radiation level of the
-entire ship. The PCS is the current sum of the radiation
-levels produced by all active ship systems. The active
-cross-section (ACS) is a fixed number for each ship type
-which represents the amount of energy reflected by the ship's
-hull (aspect angle ignored).
-
-Each sensor system will be modeled by type and efficiency.
-During each frame of simulation, the sensor system will
-sample all targets in the game. For each target, two levels
-of detection will be computed as:
-
- Detect_pas = PCS / range * Eff_pas
- Detect_act = ACS / range^2 * Eff_act(Power_act)
-
-If the level of detection for a target is 0.5 or less, the
-avionics will not register the target as a contact, and will
-not display it in the HUD or tactical viewscreens. If the
-level of detection is 1.0 or greater, the avionics will
-register the target as a contact, display it in all view-
-screens, and allow weapons targeting of the contact.
-
-If the level of detection is between 0.51 and 0.99, the
-avionics will be able to detect position and classification
-only (not velocity or capability). Weapon targeting will
-not be possible.
-
-The target's affiliation will only be displayed if its IFF
-transponder is enabled. (in all cases?)
-
------------------------------------------------------------
-EmCon 1: Silent
- Generator - idle
- Shields - disabled, discharged
- Weapons - disabled, discharged
- Sensors - passive only
- Comms - receive only, IFF disabled
-
-EmCon 2: Stealthy
- Generator - 50% limit
- Shields - disabled, discharged
- Weapons - enabled, discharged (missiles only?)
- Sensors - active low power
- Comms - receive, transmit encrypted, IFF disabled
-
-EmCon 3: Normal (launch condition)
- Generator - 100% limit
- Shields - enabled, charged
- Weapons - enabled, charged
- Sensors - active full power
- Comms - receive, transmit, IFF enabled
------------------------------------------------------------
-Table 1: EmCon Settings
-
-
-Short range (passive) sensors will be able to detect EmCon
-2 targets up to a range of 100K, and EmCon 4 targets up to
-a range of 500K. Long range (active) sensors will be able
-to track all targets up to a range of 1M (maybe as high
-as 2M).
-
-The flag ship serves as Wide Area Search Protocol (WASP)
-coordinator for the fleet. That is, all ships in the fleet
-will have access to the flag ship's target list. All ships
-will periodically send their own target list back to the
-flag ship for distribution to the fleet.
-
-==================== STARSHATTER ====================
- STORY
-
-An ancient Evil has awoken in the galaxy...
-
-The story will be told against a backdrop of two warring
-powers, one peaceful/isolationist, one warlike/imperial.
-The warlike power seeks to control less sophisticated
-races and civilizations and to lead them in an attack on
-the peaceful power. The player is a member of one of
-these "less sophisticated" races (i.e. a human) who gets
-caught up in the subtle yet violent conflict between the
-two titans.
-
-Since the conflict between the powers involves the con-
-trol of lesser species, you can never really know who is
-on your side. Or even which side is really yours. As a
-soldier, you will be forced to choose between obeying
-orders from your superiors, and doing what you believe
-is right.
-
-The game begins with the player assigned to the Tekton-
-Organon Combat Training Facility in the Janus System.
-The player can choose a career path as a fighter pilot
-or as a starship commander. In either case, they are
-assigned a first vessel, and sent through a course of
-ten or so training missions with both simulated and live
-fire against combat instructors and drone targets.
-
-During the last training mission (a sort of final exam)
-the CTF is destroyed in a hit-and-run attack by the enemy.
-The player is immediately assigned to a combat billet and
-sent into the fray. (Note that once the player has
-completed the training missions, future games will not
-require the player to repeat them.)
-
-The remainder of the game takes the player through a
-series of combat missions against more and more difficult
-alien opponents. Midway through the game, the player
-learns that the true enemy is the EVIL that has instigated
-the conflict in the first place.
-
-In the end, the "good" power offers a weapon of last
-resort to the player. This weapon will cause the explosive
-annihilation of several dozen stars in enemy space. It
-will immediately result in several billion civilian deaths,
-with tens of billions of casualties resulting from radiation
-poisoning over the next several centuries. Other, more
-dire, and more global consequences will also result...
-
-==================== STARSHATTER ====================
- STRATEGY
-
-Although Starshatter is fundamentally an action title,
-there is also a significant back-story and strategic
-element to the gameplay.
-
-The game occurs in a far-distant future of the Milky
-Way galaxy. Our corner of the galaxy, an area some
-ten or twenty thousand light years in diameter is popu-
-lated by thousands of human-intelligent species on tens
-of thousands of worlds. Many races live in approximate
-isolation, but most are organized into complex poly-
-specific civilizations spanning many star systems.
-Humans are not central in galactic affairs (as in Star
-Trek or Star Wars) but are merely another species. And
-some of the other species and civilizations are *much*
-older and *much* more advanced than ours.
-
-
-POLITICAL FACTIONS:
-
-- Starshatter (warlike/imperial power)
-
-* Sterat Empire (controlled by the Starshatter)
-
-* Brenel Core (military/intelligence corporation)
-
-* Zolon Empire (hive-like hereditary empire)
-
-* Marakan Hegemony (Failing human imperial civilization)
-
-* Terellian Alliance (peaceful commerce group)
- Alliance of Terellian Republics (ATR)
-
-+ Ele'aan Fusion (peaceful/isolationist power)
-
-The player is a human starfighter pilot in the military
-of one such civilization, Tekton-Organon, which is in
-turn part of the Terellian Alliance. The computer plays
-the part of the player's superior officers in assigning
-missions and offering criticism and praise for performance.
-In addition, the computer plays the role of all enemy
-pilots and politicians.
-
-The game follows the action in an interstellar conflict
-between the Terellian Alliance and those civilizations in
-the control of the Starshatter. The player is assigned
-missions and ships commensurate with his ability by the
-computer.
-
-==================== STARSHATTER ====================
- MISSIONS
-
-Each of the three episodes follows the action in a military
-campaign against a single enemy civilization. Individual
-missions will be constructed on the fly by the dynamic
-campaign manager (or by the player if acting as operational
-commander).
-
-Each episode takes place in a fixed volume of space con-
-taining about a dozen star systems. The global campaign
-map will treat the star systems as points in a 2D map.
-The action will take place within individual star systems,
-which use a finer grained map. The enemy will control
-most of the star systems, although a few will be neutral,
-allied, or controlled by the player's faction. These may
-need to be defended if the enemy is able to incur.
-
-Rather than being "mission based", Starshatter is an
-"operational simulation". Each campaign episode is
-broken down into a series of military operations, each
-of which occur in a given star system. Different opera-
-tions will have different rules of engagement and victory
-conditions. Some will require the player to secure a
-neutral or allied star system from hostile threats.
-Others will involve incursion into hostile territory.
-Still others will have more limited objectives, such
-as securing a friendly position in a neutral system,
-without violating neutral airspace or damaging neutral
-assets.
-
-Major resources such as space stations, ship yards,
-SAM and sensor sites will be part of the fixed universe
-design. Likewise, the initial number, type, and location
-of warships is fixed at design time. It is hoped that
-the combination of large numbers of ships and small
-random factors (battle outcome, planetary position,
-time of attack) will result in increased variety of
-enounter for the player.
-
-During the game, the campaign manager must keep track
-of the location and make-up of each ship and battle group.
-As each ship is destroyed in battle, it must be removed
-(permanently) from play. New ships and battle groups
-can be constructed on each side, at a rate dependent
-on how many critical resources the side controls. In
-addition, reserves may be advanced from rearward areas
-to support an operation.
-
-For each mission, the computer will assemble a mission
-profile by selecting one or more objectives, selecting
-a location for the battle, and assigning friendly and
-enemy forces. The computer can choose randomly from
-among the nearby resources to attack (or defend) and
-the nearby ships on both sides to fight.
-
-Missions will be generated in accordance with the current
-strategic objectives for the operation. The dynamic
-campaign manager will keep a prioritized list of
-strategic objectives, mostly related to major fixed
-resources.
-
-Before the battle, the player will be given a gene-
-rated mission briefing describing the mission objec-
-tives, locale, and the makeup of his own group.
-
-Once the player completes the mission (or loses it),
-the computer will tally up the losses on both sides
-and remove those ships from the campaign roster. A
-generated mission debriefing will detail kills and
-losses, pilot ratings, etc.
-
-In order to keep the player doing something interesting,
-he will have to be assigned to an attack force, either
-a battle group or fighter wing. Early missions will be
-shorter and simpler, with a single objective in a
-single system. Later missions will get more involved,
-with multiple objectives and sometimes requiring free
-drive travel to other systems. In addition, the com-
-plexity of missions will be modulated by the user's
-chosen difficulty level.
-
-Sometimes, the objectives will be enemy forces: e.g.
-destroy a fighter wing or cripple a battle group.
-Other times, they will be fixed resources like space
-stations or fortified moons. Still other times, they
-will be distributed or moving targets: e.g. shut down
-interplanetary shipping throughout the system.
-
-At any time, the player's group may get assigned to
-a defensive mission (scramble). This can mean defending
-a fixed resource from an incoming enemy attack. Or it
-could mean escorting an important freight convey through
-unsecured space.
-
-Mission objectives can be constructed from verb-noun
-imperatives:
-
- Verb List Object List
- ---------------- -----------------
- Intercept Ship
- Shadow Group of Ships
- Escort
- Defend
-
- Strike Space Station
- Capture
- Blockade
- Defend
-
- Launch From Starship or Station
- Dock With
- Dock/Rearm/Launch
-
- Clear Mine Field / Satellite Grid
-
- Go To Location
- Patrol
- Hold At
-
-
-We may also need to define some high-level tactics for
-achieving these objectives which can be used by the
-enemy AI.
-
-Here are some ideas:
-
- Massed or Dispersed
- Attack at Long Range or Up Close
- Stealthy or Overt Approach (psychological impact, force disposition)
-
- Clear space or Nebula (won't always have a choice)
- * Find other ways to screw up sensors
- - pulsars
- - jammers
-
- Guerre de Course?
- Use Decoys?
- Keep Reserves?
- What kind of Antiscouting/Deception?
- What kind of weapons?
-
-==================== STARSHATTER ====================
- COMMAND
-
-A unique feature of STARSHATTER is the ability to choose
-between a career as a fighter jock or a starship commander.
-The fighter side of the game will play similar to a space
-combat sim or an air combat sim. The starship side will be
-quite different:
-
-Starships are big, expensive, powerful platforms, but they
-are not terribly maneuverable. In general, one does not
-"knife fight" with a star destroyer. Starships will make
-use of a variety of long range (even beyond visual range)
-weapons including cruise missiles, varion torpedoes, and
-attack ships. These can be used to weaken or destroy an
-enemy vessel while putting the ship at minimal risk. Once
-the enemy has been sufficiently weakened, the player can
-safely close range and finish the job with supremely power-
-ful but short range energy weapons.
-
-The commander can select and direct long range weapons
-to attack enemy sub-targets to achieve a specific goal,
-whether it is to disable, disarm, or outright destroy an
-opponent. It will probably be great fun to disable an
-enemy, close range, and ask them to "surrender...or DIE!"
-
-In these long range attacks, timing and distance will be
-everything. The player must be close enough to detect the
-enemy and coordinate a strike, but not too close to be
-detected first. Then the player must close range quickly
-enough to finish off the enemy before an effective counter
-attack can be mounted. The opportunity for deception and
-possum-playing on both sides will add to the tension.
-
-However if the player is unlucky enough to find himself
-on the receiving end of a BVR attack, he still has several
-interesting options. If the long range attack has revealed
-the location of the enemy (a likelihood), the player can
-request assistance from better positioned allies (if any).
-Alternately, he can choose to hunker down into a defensive
-posture or launch a counter-attack. If the situation seems
-truly grim, he can also choose to reconfigure power systems
-and run.
-
-To compensate for the lack of maneuverability, the player
-will need to be given control over a richer variety of
-defensive assets. In addition to basic fighter cover and
-CIWS lasers, starships will be able to carry and deploy
-sensor probes and weapons pods. Sensor probes are usually
-passive sensor arrays mounted on a stable platform analogous
-to a modern sonobouy. They are deployed by the starship and
-send target contact information back to it. Weapons pods
-are more like unmanned, unshielded, undriven fighters.
-They have the ability to orient themselves in space, and may
-even be capable of limited movement through translation
-thrusters. But basically they sit where they are left and
-fire lasers and missiles at any unfriendly targets that
-wander into range.
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-Steps needed to get there:
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Passive and Active Sensors
-- Tactical Situtation MFD
-- System Targeting
-- System Damage Combat Results
-- Long Range Weapon Types
-- Sensor Probes and Weapons Pods
-- AA Turrets on Starships
-- Fighter AI Commands
-- Starship AI
-- Squadron AI Commands
-- Big Explosions and Shock Waves
-
-==================== STARSHATTER ====================
- AI
-
-AI STATE
------------------------------------------------------
-Threats
-Targets
-Allies
-Destinations
-Objectives
-Self health
-Team strength
-Morale
-Tenacity/Recklessness
-Mood/Stability
-Difficulty
-
-
-High Level Behavior
------------------------------------------------------
-Choose to continue or retire the engagement
-Guard a position or resource
-Search for a target
-Plan an assault on a group of targets
-Assign an objective to a teammate
-Call for help
-
-Mid Level Behavior
------------------------------------------------------
-Assess a threat, or group of threats
-Select a target from a group of targets
-Select a subcomponent of a larger target
-Select a weapon to use when attacking
-Attack a Target using an offensive combat maneuver
-Assess own capabilities or "health"
-Assess team capabilities or strength
-Set levels of agression and desperation
-Set desired level of stealthiness
-Choose to pursue or break-off an attack
-Seek cover
-Seek repair or supplies
-Follow a flight plan
-Launch or recall a ship
-
-Low Level Behavior
------------------------------------------------------
-Navigation:
- Idle
- Evade a Threat
- Seek an Objective
- Avoid an Obstacle
- Match Target Velocity
- Form with Target (ally)
- Dock with Target (ally)
- Hold Position
- Orbit(patrol) Position
-
-FireControl:
- Fire upon a target
- Set EMCON level
-
-Primitive Behavior
------------------------------------------------------
-Turn or Establish Heading
-Accelerate or Slow Down
-Fire a Weapon
-Target a Weapon
-Select Sensor Mode
-Set EMCON Level
-Activate Countermeasures
-
-==================== STARSHATTER ====================
- INTERFACE
-
-SCREEN CONCEPTS:
-
------------------------------------------------------
-Main Menu
------------------------------------------------------
-
- New Game
- Continue Game
- Quick Mission
- Training
-
- Player Info (callsign, difficulty level, stats)
- Game Options (controls, audio-video settings)
-
- Help!
- Exit
-
------------------------------------------------------
-Help Menu
------------------------------------------------------
-
- Online Manual
- Keymap
- About...
- Credits
-
------------------------------------------------------
-Operational Command
------------------------------------------------------
-
- Operation Name, Date, Status
- ----
- Orders (overview of operation)
- Theater (system map showing resources)
- Strat Plan (edit objective list)
- Intel Rpt (news feed)
- Status (current score, us vs. them)
-
- - missions -
- Active ## (current mission list)
- Pending ## (missions in prep)
- Scramble ## (inbound threat list)
-
- Commit (engage current mission)
- Cancel (back to main menu)
-
- Also need controls to navigate the maps, and
- control visual clutter.
-
- [May want to offer simpler versions of this
- screen for "Starship Command" and "Fighter
- Command", allowing the player to focus on
- combat simulation rather than strategy.]
-
------------------------------------------------------
-Mission Planning
------------------------------------------------------
-
- Briefing Data (scrolling text and images)
- Mission Title
- Objective List
- Force Package
- package callsign
- wingmen and loadout
- Annotated Flight Plan
- launch time
- nav points and events
- time on target
- Intel Report
- expected counterforce
- degree of confidence
-
- Package (select wingmen)
- Loadout (select weapons)
- Nav Map (edit nav points)
- Targets (assign objectives to flights)
-
- Commit (engage current mission)
- Cancel (back to previous screen)
-
- [NOTE: same screen can double as Alert Intercept
- by changing the title and removing the edit buttons]
-
-
-==================== STARSHATTER ====================
- TRAINING
-
-Training Missions (both services)
-
-1. Basic Flight and Navigation
-2. Guns
-3. Missiles
-4. Combat Maneuver
-5. Sensors / Stealth
-6. Wingman Interface
-7. Long Range Scan
-8. Tactical Navigation and Waypoint Setting
-9. Advanced Tactics
- a. Starship Assault (fighter weapon school)
- b. Cruise missiles & Flight Ops (fleet tactical school)
-10. Situation Awareness (Final Exam)
-
-
-=======================================================
- MISCELLANIA
-
-Sensor ships and stations will be important resources in
-winning the information war. Both the player and the AI
-will need to exploit and protect them appropriately.
-
-Briefings/Debriefings and other Intelligence Reports
-must adequately communicate the overall game situation
-to the player in order to allow the player to make
-meaningful decisions. This is crucial to establishing
-immersion and making the player care about the outcome
-of the game.
-
-Briefings and Info Bursts will be more visceral if they
-include simulated "news footage" of the events being
-related.
-
-
-=======================================================
- DYNAMIC CAMPAIGN NOTES
-
-1. Fighter jocks will be allowed to choose from a
- menu of generated missions that have been assigned
- to the player's squadron.
-
-2. Cruiser skippers will be given only one generated
- mission at a time (like KA or SFC), but it will be
- somewhat broader in scope.
-
-3. Carrier admirals will do what exactly?
-
-4. Both cruiser and carrier missions will often start
- in the field or on patrol. Fighter missions will
- always start and end at a base (carrier|station|
- dirtside starbase).
-
-5. Cruiser and carrier missions will not normally
- include the starsender translation to the area of
- conflict. The player will only go through the
- sender in real time as part of a mission (not as
- prelude or ending to a mission).
-
-6. Admirals will need to be able to generate orders
- for their forces during the battle. This implies
- some kind of Op Command workstation.
-
-7. The mission planner algorithm must construct
- generated missions that are "fun", not just logical
- to the campaign. I have a vague notion of using
- time/distance heuristics to place enemy units as
- "challenges" on the battle field. e.g. For xxx
- type of mission, place an enemy destroyer yyy
- minutes away from the (player|objective|sender).
-
-8. The generated missions do not have to hang together
- as well as previously planned. That is, we don't
- need to maintain the feeling that the player is just
- a unit in an RTS game. Instead, the campaign manager
- is just a device for generating interesting single
- player missions as would be found in any game with
- a static campaign.
-
- On the other hand, the player should not see any
- obvious contradictions between the big board and
- what occurred during their missions. That means,
- any kills they witnessed must still be visible
- between missions in the intel report/event log.
-
-
-=======================================================
- SAMPLE OPERATIONAL SCENARIOS
-
---- COLD WAR, LOW TENSION ---
-
-1) Training Center (see above)
-
-1a) Live Fire:
- Engage in "live fire" exercise with a friendly
- power.
-
---- COLD WAR, HIGH TENSION ---
-
-2) Restore Order:
- The enemy is supporting a terrorist puppet govt
- in an allied star system. Aid the locals in putting
- down the disturbance.
-
-3) Deliverance:
- The enemy is sponsoring terrorists and pirates
- harassing a small outpost system. Ensure free
- access to the space lanes and aid the delivery
- of needed supply convoys.
-
-4) Freedom Fighters:
- The enemy is supporting a despotic govt that is
- occupying a weaker friendly or neutral system.
- Aid the locals in driving out the occupying force.
-
-5) Strategic Withdrawal:
- Ownership of a former protected star system is
- passing back to the enemy. Oversee the withdrawal
- of friendly forces. Try to avoid active conflict.
-
---- FORMAL DECLARATION OF WAR ---
-
-6) First Blood:
- A research and educational center is on the front
- lines and in harms way. Set up a strong defensive
- posture, and oversee the evacuation of non-military
- personnel.
-
-7) Sneak Attack!
- The enemy has already struck a friendly system,
- but they have not yet had time to fortify their
- position. Coordinate with local forces and evict
- the hostiles.
-
-8) Fortress of Light:
- Protect an Eleaan frontier system from enemy
- attack.
-
-9) Turning Point:
- The enemy is seeking a decisive victory by wiping
- out the home fleet. Turn the tables on them by
- attacking first.
-
-10) Firestorm:
- Press the advantage by invading a series of
- enemy manufacturing and military systems.
-
-11) Nightfall:
- Climactic operation against the enemy home system.
-
-
-=======================================================
- MISSION TEMPLATE TYPES
-
-FIGHTER
- TACTICAL FIGHTER WING
-
- ATTACK SQUADRON
-
-DESTROYER/CRUISER
- SQUADRON
- Anti-shipping
- Shipping Escort, anti-fighter
- Shipping Escort, anti-cruiser
- Shipping Escort, general
- Picket
- Squadron Hunter
-
- BATTLE GROUP/TASK FORCE
- Force-on-Force Engagement
- Starbase Bombardment, pre-assault
- Starbase Bombardment, anti-fighter
-
-CARRIER
-
-
-=======================================================
-
-Ship Names:
-
-F-32G Falcon Squadrons
- Flying Tigers, Bearcats, Aces High, Cool Hands, Wizards
-
-F-36C Stormhawk Squadrons
- Nighthawks, Mustangs, Stallions, Chargers, Blazers
-
-F/A-38D Talon Squadrons
- Starknights, Lancers, Wild Bunch, Razorbacks, Buzzards
-
-
-Berents Class FF
- Berents, Bosporus, Barth, Bering, Balen,
- Clarkeston, Carlisle, Canton, Delmar, Dardenelles,
- Darmstadt, Leyte, Messina, Mountebank, Morgan,
- Malory, Parker, Rainier, Sorrel, Seychelles,
- Tanly, Trieste, Yarmuz, Zephyr, Zodiac
-
-
-Spectre Class DD
- Spectre, Wraith, Shadow, Warlock, Phantom,
- Mistral, Nemesis, Necromancer, Merlin, Nightshade,
- Moloch, Demon, Phobos, Deimos, Enigma,
- Phantasm, Revenant, Banshee, Barrows, Gorgon
-
-Courageous Class DG
- Courageous, Fearless, Stalwart, Defender, Guardian,
- Steadfast, Assurance, Protector, Heroic, Valiant,
- Dauntless, Vanguard, Redstone, Victory, Honor,
- Braveheart, Defiant, Audacious, Valorous, Confident
-
-Devastator Class CA
- Devastator, Annihilator, Onslaught, Relentless, Argent,
- Stormwind, Thunder, Hurricane, Inferno, Torrent,
- Typhoon, Vortex, Predator, Ravager, Demolisher,
- Havoc, Scourge, Huntress, Warrior, Shrike
-
-Orion Class CV
- Orion, Antares, Archon, Titan, Hyperion
-
-
-
-OTHERS
- Wasp, Hornet, Scorpion, Deaths Head,
- Wolf, Cobra, Viper, Raptor, Python
-
- Jackal, Zodiac, Scarab, Sphinx, Osiris,
- Onyx, Isis
-
--------------------
-1 Fleet = 95 starships + 300 fighters
-
-5 carrier groups
- 1 CV + 60 Fighters
- 2 CA
- 1 DG
- 1 DD
- 2 FF
-
-5 battle groups
- 2 CA
- 1 DG
- 1 DD
- 2 FF
-
-5 destroyer squadrons
- 2 DG
- 2 DD
- 2 FF
-
-==================== STARSHATTER ====================
- GALAXY : NAMES
-
- Adavan
- Aram
- Borreal
- Bress
- Casalle
- Chi
- Dawn
- Elkhart
- Fenn
- Gaul
- Garrison
- Haiche
- Hemmik
- Ilon
- Janek (Janus-3)
- Jarnell
- Kala
- Khalife
- Kolchev
- Korius
- Lanos
- Loris
- Marak
- Manse
- Muir
- Navara
- Nephrys
- Nergal
- Oleanne
- Omin
- Patagon
- Path
- Pollus
- Relay
- Renser
- Ri
- Rodis
- Senna
- Suven
- Tal Amin
- Tarsus
- Theramin
- Thralis
- Ur
- Volante
- Warren - world crack canyon/rain-forest settlement (must always face the sun)
- Whorl
- Xanthe
- Zephyr
- Zone
-
-==================== STARSHATTER ====================
- GALAXY : PLANET TYPES
-
- --= Landform Types =--
- Arid Desert (Arrakis)
- Frigid Desert (Mars)
- Frozen Exotic (Titan)
- Temperate Planar
- Temperate Mountainous
- Tropical Forest
- Tropical Oceanic
- Icy Oceanic (Scandinavia)
- Rocky Planar
- Rocky Mountainous
- Volcanic (Venus, Io)
- Barren (Pluto)
-
- --= Atmospheric Types =--
- Thin
- Clear, Breathable
- Dusty
- Foggy/Cloudy
- Dense Poisonous
- Layered
-
- --= Population Types =--
- Agrarian
- Industrial
- Mining
- Research/Technology
- Military
- Political
- Terraforming
-
-==================== STARSHATTER ====================
- GALAXY : RACES
-
- Human
-
- Ele'aan
- Eltaar - "Those Who Speak for Ele'aas"
-
- Marakan
- Commar
-
- Kasatti
-
- Zolon Empire
-
-
-
-==================== STARSHATTER ====================
- CAMPAIGN SEQUENCE
-
---- COLD WAR, LOW TENSION ---
-
-1) Training Center - Live Fire:
- Engage in "live fire" exercise with friendly
- units on the border of Hegemony territory.
-
---- COLD WAR, HIGH TENSION ---
-
-2) Restore Order:
- An outlying Hegemony system is using terrorist
- tactics to gain control of a neighboring neutral star
- system to create "breathing room" between themselves
- and the Alliance. Drive out the terrorists and get the
- neutrals to sign a treaty with the Alliance.
-
-3) Freedom Fighters:
- Hegemony taxation policy has driven an outlying
- system to resort to despotism to collect needed
- revenue. A group of local freedom fighters is
- attempting to overthrow the Hegemony backed govt.
- Aid the locals in driving out Hegemony forces.
-
---- OPEN WARFARE ---
-
-In response to campaign 3, the Hegemony formally
-declares war on the Alliance.
-
-4) Fortress of Light:
- The Hegemony has struck three Alliance systems,
- but they have not yet had time to fortify their
- position. Drive out the enemy forces, and
- protect Alliance citizens and assets in the area.
-
-5) Firestorm:
- Alliance Force:Command is planning a major offensive
- against the core Hegemony systems. This operation
- is to strike major war production and ship yards
- to weaken the Hegemony resistance before the
- main offensive.
-
-6) Nightfall:
- Climactic operation against the enemy home system.
- Discovery that the Hegemony worlds have been overrun
- by the Zolon Empire.
-
---- ALIEN STRIFE ---
-
-7) Spear of Triton
-
-8)
-
-
-
-
+==================== STARSHATTER ====================
+ ACTION
+
+Starshatter is a 3D action-simulation game in a space
+combat setting. The player will control a space
+ship of one type or another, and attempt to defeat
+various enemy forces composed of small, medium
+and large space ships, space stations, and ground-
+based resources.
+
+The game is designed as a series of combat missions
+in which the goal is to destroy an enemy resource,
+secure an enemy position, or defend a friendly resource
+from an enemy attack. Unlike most space combat sims,
+Starshatter missions are fought within the context of
+a large dynamic military operation.
+
+In the attack type of mission, victory is achieved
+by destroying the resource(s) and escaping to safety.
+In the secure and defend types of missions, victory is
+achieved by preventing the destruction of the resource
+while simultaneously destroying the enemy or forcing
+the enemy to retire. In any mission, achieving a
+partial victory is a possibility.
+
+Individual mission designs will be characterized by:
+1) the locale, including various space bodies such as
+ stars, planets, planetoids, asteroid fields, space
+ stations, nebulae, terrain, cities, and so forth
+2) the composition and placement of enemy forces
+3) the composition and placement of friendly or neutral
+ forces, if any
+4) the objectives / resources / victory conditions
+ for each force element
+
+
+RELEVANT TECHNOLOGY:
+
+Space ships and ground units are each endowed with a
+group of resources that they use in battle. These
+resources fall into eight different categories:
+
+Ship System List:
+
+ 1. Vital (Hull/Stabilizer/Core/Life Support)
+ 2. Econ (power management)
+ 3. Conventional Drive
+ 4. Hyperdrive (optional)
+ 5. Shields
+ 6. Weapons
+ 7. Flight Ops (optional)
+ 8.* Systems (computer)
+ a.Communications
+ b.Sensors
+ c.GNC
+ d.Tactical (target tracking)
+
+Large space ships are capable of supralight travel by
+means of "hyperdrive," which is similar to the same
+concepts used in Star Wars and Babylon 5.
+
+Smaller ships (fighters, attack) are not capable of long
+distance travel using hyperdrive, and must be carried
+to and from missions by a larger ship (a destroyer or cruiser).
+
+All combat will occur at sublight velocities using
+conventional plasma projection or fusion drive. However,
+damage to the hyperdrive may effect the outcome of a
+mission (e.g. by delaying a safe escape).
+
+Ships and ground targets may employ various types of
+weapons, both matter and radiant energy based. From
+the AI's point of view, all weapons are of one of three
+different types: guided, unguided, or regional. Guided
+weapons include their own AI to direct their flight path
+to a target. Unguided weapons simply follow the straight
+line course set for them at launch time. Regional weapons
+inflict damage on any resources that happen to occupy the
+same volume of space as the weapon during its deployment.
+Any single ship or ground target may employ several fire
+control AI systems to manage multiple beam weapons and
+missile launchers.
+
+Ships and ground targets may employ defensive screens
+or shields. These shields are invisible barriers that
+prevent the transmission of both matter and radiant
+energy weapons. Shields (actually, shield generators)
+are degraded by the process of deflecting weapons and
+will eventually burn out, leaving the ship open to
+attack. Larger ships will employ multiple shield
+generators to screen various parts of the ship. In
+addition, larger ships can mount more robust shield
+technology, requiring heavier weapons to penetrate.
+
+Laser/Particle Beam cannon types:
+* Alpha
+* Gamma
+* Delta
+* Omega
+
+Explosive Missile weapon types:
+* Pyrotechnic
+* Thermonuclear
+* Antimatter
+* Varion (Torpedo)
+
+In addition to basic laser and explosive missile types
+of weapons, Starshatter features several advanced weapon
+types:
+
+* Cruise Missiles (very long range guided munition)
+* Bomb-pumped Laser Warheads
+* CIWS Laser Turrets
+
+* Plasma Cannon (very high power energy weapon)
+* Fusion Burst (ultra high power energy weapon)
+* Graviton Pulse (goes through all shields)
+
+Whenever any ship system takes damage, the capabilities
+of the ship in that area are temporarily or permanently
+downgraded. Most systems are capable of limited self-
+repair. Safe bases will be provided for full repair
+both during and between missions.
+
+Although there will be no powerups just lying around,
+there will be both friendly and enemy supply ships on
+each mission. Small ships can resupply themselves at
+any time by docking with a friendly supply depot or
+ship.
+
+While ships are grouped into the broad categories of
+"large," "medium," and "small", there are several
+distinct classes within those categories. Ships in
+each class will have typical size parameters as
+follows:
+
+ CLASS LENGTH (m) CREW
+ ----------- ----------- -------
+ Fighter 10-20 1 Small
+ Attack 25-50 2-3
+ Destroyer 200+ Medium
+ Cruiser 400+
+ Battleship 800+ Large
+ Carrier 1000+
+
+ Station unlimited
+
+As the class names indicate, small ships are analogous
+to modern combat aircraft, while medium and large ships
+are analogous to modern naval surface warships. Medium
+and large ships are sometimes referred to as "Starships"
+because they are capable of interstellar travel.
+
+Medium ships may be outfitted with towing rigs. Large
+ships may be outfitted with flight decks. Both of these
+can be used to capture a ship. Flight decks can also
+be used to repair and re-supply smaller ships.
+
+Ships may be organized into battle groups that are led
+by a "flagship." The flagship is responsible for the
+general direction of the other ships in the battle group.
+This includes such things as setting the overall state
+of readiness, prioritizing targets, and deciding to
+pursue or retire.
+
+==================== STARSHATTER ====================
+ TACTICS
+
+Aside:
+
+I really want to avoid the typical "furball" (as seen
+in XvT, WCn, etc.) as much as possible. One thing I've
+always liked about DOOM style games is the measured pace
+of the action. During the course of a single level, the
+player faces a variety of enemies and situations in small
+packets, controlled by the level architecture. I would
+like to mimic this in Starshatter somehow, but the "open-
+ness" of the space setting makes it difficult.
+
+Some ideas:
+
+Missions will be sliced up into sections by distance and
+obstacles. So there might be a group of sentry ships to
+defeat as you enter the playfield, followed by a short
+flight to the next enemy force package. The enemy will
+be somewhat slow to react to the player's presence. Per-
+haps enemy ships will need to stick close by other resources
+on guard duty or some such.
+
+A challenge:
+
+Unlike DOOM, the player and enemy ships have the same
+capabilities. This means that with reasonable AI, the
+player will get killed about as often as the enemies.
+As a result, if the player is vastly out-numbered as
+usual he won't last very long with even odds. Result:
+we may need to fudge the damage on the player's ship
+somewhat to give him an edge. Either that, or the
+player will only be allowed to battle one or two enemy
+ships at a time. Or, the enemy AI should preferentially
+attack red-shirt pilots instead of the player.
+
+USING HYPERDRIVE:
+
+How about, most ships are equipped with hyperdrive.
+This allows the player to travel to places that are too
+far away to be seen with tactical scanners. In effect,
+jumping through hyperspace places "doors" between scenes
+of action.
+
+Let's postulate that hyperdrive allows supra-light travel
+at some ridiculous velocity. While in hyperspace the ship
+is essentially impervious to everything except gravitons.
+If the ship passes too close to a gravity well or gravitic
+weapon, the hyperdrive will "stall". The ship will return
+to normal space, and the hyperdrive will be offline for
+several seconds.
+
+Further postulate that shields and weapons are powered
+down during hyperspace transit. So you can run, or you
+can fight, but not both at the same time.
+
+While in hyperspace, the player can pilot the ship in
+the usual manner (or perhaps just using the keyboard),
+but the ship is no longer as agile (perhaps 1/5th as
+agile as in sublight flight, perhaps this is variable
+depending on ship design). The point is that the player
+can point and go, without some hokey "warp out" animation
+sequence.
+
+Of course, it's a big universe out there. There is no
+point in *making* the player wander around in the middle
+of nowhere for an hour because he overshot the battle. So
+we will also provide a nav map with preset way points.
+The player can plot a course to anywhere in the mission
+profile by clicking on the way points and pressing "GO".
+While under "auto-pilot" like this, the player can still
+operate all of the ship systems, review the database, etc.
+Nav courses can also be pre-plotted as part of the mission
+profile. Nav points should be reasonably close together,
+so as to provide a "breather" but not "boredom".
+
+At any time, the player can steer the ship and break out
+of autopilot, without the navigation system forgetting
+the plan. This provides a nice possibility of "secret areas"
+like checking for the secret base on the far side of the
+3rd moon.
+
+While in hyperspace, the view of the universe is altered.
+Sublight ships are invisible, as is space dust. Planets
+and other gravity wells are important, so these are still
+visible in some way. Probably want to replace the "star
+and nebula" sky shell with something more distinctive, a'la
+Bab5 hyperspace, might be nice to have it be animated.
+
+Even though you never see your own ship go into hyperspace,
+it would be great to have a suitable special effect for when
+another ship does so. Perhaps something like the spiral
+smoke trail from "Eraser". Whatever it is, it has to convey
+a sense of speed (without silly elongation effects or fake
+motion blur).
+
+SENSORS AND SCOUTING:
+
+Ships will have access to both passive (short range) and
+active (long range) sensors. Passive sensors rely on the
+detection of radiation emissions from target ship systems
+such as shields, weapons, drive, reactors, active sensors,
+and communications (this is analogous to IR or passive sonar).
+Active sensors transmit an energy beam into space and detect
+the "echo" of the energy bouncing off a target ship (in a
+manner analogous to radar or active sonar).
+
+The fundamental strategy of scouting is to detect the enemy
+targets while simultaneously thwarting the enemy's attempt
+to detect the player. The basic tool for implementing this
+strategy is Emission Control. The player must balance the
+energy output of his own ship against the ability of the
+enemy to detect and target him.
+
+The ships will have an Emission Control system, with a range
+of EmCon options. As the EmCon level is increased, more
+ship systems are enabled and allowed to radiate. The ship's
+computer will attempt to minimize the EmCon level to the
+greatest degree in accordance with safety. If unfriendly
+ships are detected at close range, the computer will increase
+the EmCon level to allow the use of shields and weapon systems.
+The player can also override the automatic EmCon setting in
+situations where stealth is paramount.
+
+Each ship will be modeled by a passive and active sensor
+cross-section. The passive cross-section (PCS) is a dynamic
+number that represents the current radiation level of the
+entire ship. The PCS is the current sum of the radiation
+levels produced by all active ship systems. The active
+cross-section (ACS) is a fixed number for each ship type
+which represents the amount of energy reflected by the ship's
+hull (aspect angle ignored).
+
+Each sensor system will be modeled by type and efficiency.
+During each frame of simulation, the sensor system will
+sample all targets in the game. For each target, two levels
+of detection will be computed as:
+
+ Detect_pas = PCS / range * Eff_pas
+ Detect_act = ACS / range^2 * Eff_act(Power_act)
+
+If the level of detection for a target is 0.5 or less, the
+avionics will not register the target as a contact, and will
+not display it in the HUD or tactical viewscreens. If the
+level of detection is 1.0 or greater, the avionics will
+register the target as a contact, display it in all view-
+screens, and allow weapons targeting of the contact.
+
+If the level of detection is between 0.51 and 0.99, the
+avionics will be able to detect position and classification
+only (not velocity or capability). Weapon targeting will
+not be possible.
+
+The target's affiliation will only be displayed if its IFF
+transponder is enabled. (in all cases?)
+
+-----------------------------------------------------------
+EmCon 1: Silent
+ Generator - idle
+ Shields - disabled, discharged
+ Weapons - disabled, discharged
+ Sensors - passive only
+ Comms - receive only, IFF disabled
+
+EmCon 2: Stealthy
+ Generator - 50% limit
+ Shields - disabled, discharged
+ Weapons - enabled, discharged (missiles only?)
+ Sensors - active low power
+ Comms - receive, transmit encrypted, IFF disabled
+
+EmCon 3: Normal (launch condition)
+ Generator - 100% limit
+ Shields - enabled, charged
+ Weapons - enabled, charged
+ Sensors - active full power
+ Comms - receive, transmit, IFF enabled
+-----------------------------------------------------------
+Table 1: EmCon Settings
+
+
+Short range (passive) sensors will be able to detect EmCon
+2 targets up to a range of 100K, and EmCon 4 targets up to
+a range of 500K. Long range (active) sensors will be able
+to track all targets up to a range of 1M (maybe as high
+as 2M).
+
+The flag ship serves as Wide Area Search Protocol (WASP)
+coordinator for the fleet. That is, all ships in the fleet
+will have access to the flag ship's target list. All ships
+will periodically send their own target list back to the
+flag ship for distribution to the fleet.
+
+==================== STARSHATTER ====================
+ STORY
+
+An ancient Evil has awoken in the galaxy...
+
+The story will be told against a backdrop of two warring
+powers, one peaceful/isolationist, one warlike/imperial.
+The warlike power seeks to control less sophisticated
+races and civilizations and to lead them in an attack on
+the peaceful power. The player is a member of one of
+these "less sophisticated" races (i.e. a human) who gets
+caught up in the subtle yet violent conflict between the
+two titans.
+
+Since the conflict between the powers involves the con-
+trol of lesser species, you can never really know who is
+on your side. Or even which side is really yours. As a
+soldier, you will be forced to choose between obeying
+orders from your superiors, and doing what you believe
+is right.
+
+The game begins with the player assigned to the Tekton-
+Organon Combat Training Facility in the Janus System.
+The player can choose a career path as a fighter pilot
+or as a starship commander. In either case, they are
+assigned a first vessel, and sent through a course of
+ten or so training missions with both simulated and live
+fire against combat instructors and drone targets.
+
+During the last training mission (a sort of final exam)
+the CTF is destroyed in a hit-and-run attack by the enemy.
+The player is immediately assigned to a combat billet and
+sent into the fray. (Note that once the player has
+completed the training missions, future games will not
+require the player to repeat them.)
+
+The remainder of the game takes the player through a
+series of combat missions against more and more difficult
+alien opponents. Midway through the game, the player
+learns that the true enemy is the EVIL that has instigated
+the conflict in the first place.
+
+In the end, the "good" power offers a weapon of last
+resort to the player. This weapon will cause the explosive
+annihilation of several dozen stars in enemy space. It
+will immediately result in several billion civilian deaths,
+with tens of billions of casualties resulting from radiation
+poisoning over the next several centuries. Other, more
+dire, and more global consequences will also result...
+
+==================== STARSHATTER ====================
+ STRATEGY
+
+Although Starshatter is fundamentally an action title,
+there is also a significant back-story and strategic
+element to the gameplay.
+
+The game occurs in a far-distant future of the Milky
+Way galaxy. Our corner of the galaxy, an area some
+ten or twenty thousand light years in diameter is popu-
+lated by thousands of human-intelligent species on tens
+of thousands of worlds. Many races live in approximate
+isolation, but most are organized into complex poly-
+specific civilizations spanning many star systems.
+Humans are not central in galactic affairs (as in Star
+Trek or Star Wars) but are merely another species. And
+some of the other species and civilizations are *much*
+older and *much* more advanced than ours.
+
+
+POLITICAL FACTIONS:
+
+- Starshatter (warlike/imperial power)
+
+* Sterat Empire (controlled by the Starshatter)
+
+* Brenel Core (military/intelligence corporation)
+
+* Zolon Empire (hive-like hereditary empire)
+
+* Marakan Hegemony (Failing human imperial civilization)
+
+* Terellian Alliance (peaceful commerce group)
+ Alliance of Terellian Republics (ATR)
+
++ Ele'aan Fusion (peaceful/isolationist power)
+
+The player is a human starfighter pilot in the military
+of one such civilization, Tekton-Organon, which is in
+turn part of the Terellian Alliance. The computer plays
+the part of the player's superior officers in assigning
+missions and offering criticism and praise for performance.
+In addition, the computer plays the role of all enemy
+pilots and politicians.
+
+The game follows the action in an interstellar conflict
+between the Terellian Alliance and those civilizations in
+the control of the Starshatter. The player is assigned
+missions and ships commensurate with his ability by the
+computer.
+
+==================== STARSHATTER ====================
+ MISSIONS
+
+Each of the three episodes follows the action in a military
+campaign against a single enemy civilization. Individual
+missions will be constructed on the fly by the dynamic
+campaign manager (or by the player if acting as operational
+commander).
+
+Each episode takes place in a fixed volume of space con-
+taining about a dozen star systems. The global campaign
+map will treat the star systems as points in a 2D map.
+The action will take place within individual star systems,
+which use a finer grained map. The enemy will control
+most of the star systems, although a few will be neutral,
+allied, or controlled by the player's faction. These may
+need to be defended if the enemy is able to incur.
+
+Rather than being "mission based", Starshatter is an
+"operational simulation". Each campaign episode is
+broken down into a series of military operations, each
+of which occur in a given star system. Different opera-
+tions will have different rules of engagement and victory
+conditions. Some will require the player to secure a
+neutral or allied star system from hostile threats.
+Others will involve incursion into hostile territory.
+Still others will have more limited objectives, such
+as securing a friendly position in a neutral system,
+without violating neutral airspace or damaging neutral
+assets.
+
+Major resources such as space stations, ship yards,
+SAM and sensor sites will be part of the fixed universe
+design. Likewise, the initial number, type, and location
+of warships is fixed at design time. It is hoped that
+the combination of large numbers of ships and small
+random factors (battle outcome, planetary position,
+time of attack) will result in increased variety of
+enounter for the player.
+
+During the game, the campaign manager must keep track
+of the location and make-up of each ship and battle group.
+As each ship is destroyed in battle, it must be removed
+(permanently) from play. New ships and battle groups
+can be constructed on each side, at a rate dependent
+on how many critical resources the side controls. In
+addition, reserves may be advanced from rearward areas
+to support an operation.
+
+For each mission, the computer will assemble a mission
+profile by selecting one or more objectives, selecting
+a location for the battle, and assigning friendly and
+enemy forces. The computer can choose randomly from
+among the nearby resources to attack (or defend) and
+the nearby ships on both sides to fight.
+
+Missions will be generated in accordance with the current
+strategic objectives for the operation. The dynamic
+campaign manager will keep a prioritized list of
+strategic objectives, mostly related to major fixed
+resources.
+
+Before the battle, the player will be given a gene-
+rated mission briefing describing the mission objec-
+tives, locale, and the makeup of his own group.
+
+Once the player completes the mission (or loses it),
+the computer will tally up the losses on both sides
+and remove those ships from the campaign roster. A
+generated mission debriefing will detail kills and
+losses, pilot ratings, etc.
+
+In order to keep the player doing something interesting,
+he will have to be assigned to an attack force, either
+a battle group or fighter wing. Early missions will be
+shorter and simpler, with a single objective in a
+single system. Later missions will get more involved,
+with multiple objectives and sometimes requiring free
+drive travel to other systems. In addition, the com-
+plexity of missions will be modulated by the user's
+chosen difficulty level.
+
+Sometimes, the objectives will be enemy forces: e.g.
+destroy a fighter wing or cripple a battle group.
+Other times, they will be fixed resources like space
+stations or fortified moons. Still other times, they
+will be distributed or moving targets: e.g. shut down
+interplanetary shipping throughout the system.
+
+At any time, the player's group may get assigned to
+a defensive mission (scramble). This can mean defending
+a fixed resource from an incoming enemy attack. Or it
+could mean escorting an important freight convey through
+unsecured space.
+
+Mission objectives can be constructed from verb-noun
+imperatives:
+
+ Verb List Object List
+ ---------------- -----------------
+ Intercept Ship
+ Shadow Group of Ships
+ Escort
+ Defend
+
+ Strike Space Station
+ Capture
+ Blockade
+ Defend
+
+ Launch From Starship or Station
+ Dock With
+ Dock/Rearm/Launch
+
+ Clear Mine Field / Satellite Grid
+
+ Go To Location
+ Patrol
+ Hold At
+
+
+We may also need to define some high-level tactics for
+achieving these objectives which can be used by the
+enemy AI.
+
+Here are some ideas:
+
+ Massed or Dispersed
+ Attack at Long Range or Up Close
+ Stealthy or Overt Approach (psychological impact, force disposition)
+
+ Clear space or Nebula (won't always have a choice)
+ * Find other ways to screw up sensors
+ - pulsars
+ - jammers
+
+ Guerre de Course?
+ Use Decoys?
+ Keep Reserves?
+ What kind of Antiscouting/Deception?
+ What kind of weapons?
+
+==================== STARSHATTER ====================
+ COMMAND
+
+A unique feature of STARSHATTER is the ability to choose
+between a career as a fighter jock or a starship commander.
+The fighter side of the game will play similar to a space
+combat sim or an air combat sim. The starship side will be
+quite different:
+
+Starships are big, expensive, powerful platforms, but they
+are not terribly maneuverable. In general, one does not
+"knife fight" with a star destroyer. Starships will make
+use of a variety of long range (even beyond visual range)
+weapons including cruise missiles, varion torpedoes, and
+attack ships. These can be used to weaken or destroy an
+enemy vessel while putting the ship at minimal risk. Once
+the enemy has been sufficiently weakened, the player can
+safely close range and finish the job with supremely power-
+ful but short range energy weapons.
+
+The commander can select and direct long range weapons
+to attack enemy sub-targets to achieve a specific goal,
+whether it is to disable, disarm, or outright destroy an
+opponent. It will probably be great fun to disable an
+enemy, close range, and ask them to "surrender...or DIE!"
+
+In these long range attacks, timing and distance will be
+everything. The player must be close enough to detect the
+enemy and coordinate a strike, but not too close to be
+detected first. Then the player must close range quickly
+enough to finish off the enemy before an effective counter
+attack can be mounted. The opportunity for deception and
+possum-playing on both sides will add to the tension.
+
+However if the player is unlucky enough to find himself
+on the receiving end of a BVR attack, he still has several
+interesting options. If the long range attack has revealed
+the location of the enemy (a likelihood), the player can
+request assistance from better positioned allies (if any).
+Alternately, he can choose to hunker down into a defensive
+posture or launch a counter-attack. If the situation seems
+truly grim, he can also choose to reconfigure power systems
+and run.
+
+To compensate for the lack of maneuverability, the player
+will need to be given control over a richer variety of
+defensive assets. In addition to basic fighter cover and
+CIWS lasers, starships will be able to carry and deploy
+sensor probes and weapons pods. Sensor probes are usually
+passive sensor arrays mounted on a stable platform analogous
+to a modern sonobouy. They are deployed by the starship and
+send target contact information back to it. Weapons pods
+are more like unmanned, unshielded, undriven fighters.
+They have the ability to orient themselves in space, and may
+even be capable of limited movement through translation
+thrusters. But basically they sit where they are left and
+fire lasers and missiles at any unfriendly targets that
+wander into range.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+Steps needed to get there:
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+- Passive and Active Sensors
+- Tactical Situtation MFD
+- System Targeting
+- System Damage Combat Results
+- Long Range Weapon Types
+- Sensor Probes and Weapons Pods
+- AA Turrets on Starships
+- Fighter AI Commands
+- Starship AI
+- Squadron AI Commands
+- Big Explosions and Shock Waves
+
+==================== STARSHATTER ====================
+ AI
+
+AI STATE
+-----------------------------------------------------
+Threats
+Targets
+Allies
+Destinations
+Objectives
+Self health
+Team strength
+Morale
+Tenacity/Recklessness
+Mood/Stability
+Difficulty
+
+
+High Level Behavior
+-----------------------------------------------------
+Choose to continue or retire the engagement
+Guard a position or resource
+Search for a target
+Plan an assault on a group of targets
+Assign an objective to a teammate
+Call for help
+
+Mid Level Behavior
+-----------------------------------------------------
+Assess a threat, or group of threats
+Select a target from a group of targets
+Select a subcomponent of a larger target
+Select a weapon to use when attacking
+Attack a Target using an offensive combat maneuver
+Assess own capabilities or "health"
+Assess team capabilities or strength
+Set levels of agression and desperation
+Set desired level of stealthiness
+Choose to pursue or break-off an attack
+Seek cover
+Seek repair or supplies
+Follow a flight plan
+Launch or recall a ship
+
+Low Level Behavior
+-----------------------------------------------------
+Navigation:
+ Idle
+ Evade a Threat
+ Seek an Objective
+ Avoid an Obstacle
+ Match Target Velocity
+ Form with Target (ally)
+ Dock with Target (ally)
+ Hold Position
+ Orbit(patrol) Position
+
+FireControl:
+ Fire upon a target
+ Set EMCON level
+
+Primitive Behavior
+-----------------------------------------------------
+Turn or Establish Heading
+Accelerate or Slow Down
+Fire a Weapon
+Target a Weapon
+Select Sensor Mode
+Set EMCON Level
+Activate Countermeasures
+
+==================== STARSHATTER ====================
+ INTERFACE
+
+SCREEN CONCEPTS:
+
+-----------------------------------------------------
+Main Menu
+-----------------------------------------------------
+
+ New Game
+ Continue Game
+ Quick Mission
+ Training
+
+ Player Info (callsign, difficulty level, stats)
+ Game Options (controls, audio-video settings)
+
+ Help!
+ Exit
+
+-----------------------------------------------------
+Help Menu
+-----------------------------------------------------
+
+ Online Manual
+ Keymap
+ About...
+ Credits
+
+-----------------------------------------------------
+Operational Command
+-----------------------------------------------------
+
+ Operation Name, Date, Status
+ ----
+ Orders (overview of operation)
+ Theater (system map showing resources)
+ Strat Plan (edit objective list)
+ Intel Rpt (news feed)
+ Status (current score, us vs. them)
+
+ - missions -
+ Active ## (current mission list)
+ Pending ## (missions in prep)
+ Scramble ## (inbound threat list)
+
+ Commit (engage current mission)
+ Cancel (back to main menu)
+
+ Also need controls to navigate the maps, and
+ control visual clutter.
+
+ [May want to offer simpler versions of this
+ screen for "Starship Command" and "Fighter
+ Command", allowing the player to focus on
+ combat simulation rather than strategy.]
+
+-----------------------------------------------------
+Mission Planning
+-----------------------------------------------------
+
+ Briefing Data (scrolling text and images)
+ Mission Title
+ Objective List
+ Force Package
+ package callsign
+ wingmen and loadout
+ Annotated Flight Plan
+ launch time
+ nav points and events
+ time on target
+ Intel Report
+ expected counterforce
+ degree of confidence
+
+ Package (select wingmen)
+ Loadout (select weapons)
+ Nav Map (edit nav points)
+ Targets (assign objectives to flights)
+
+ Commit (engage current mission)
+ Cancel (back to previous screen)
+
+ [NOTE: same screen can double as Alert Intercept
+ by changing the title and removing the edit buttons]
+
+
+==================== STARSHATTER ====================
+ TRAINING
+
+Training Missions (both services)
+
+1. Basic Flight and Navigation
+2. Guns
+3. Missiles
+4. Combat Maneuver
+5. Sensors / Stealth
+6. Wingman Interface
+7. Long Range Scan
+8. Tactical Navigation and Waypoint Setting
+9. Advanced Tactics
+ a. Starship Assault (fighter weapon school)
+ b. Cruise missiles & Flight Ops (fleet tactical school)
+10. Situation Awareness (Final Exam)
+
+
+=======================================================
+ MISCELLANIA
+
+Sensor ships and stations will be important resources in
+winning the information war. Both the player and the AI
+will need to exploit and protect them appropriately.
+
+Briefings/Debriefings and other Intelligence Reports
+must adequately communicate the overall game situation
+to the player in order to allow the player to make
+meaningful decisions. This is crucial to establishing
+immersion and making the player care about the outcome
+of the game.
+
+Briefings and Info Bursts will be more visceral if they
+include simulated "news footage" of the events being
+related.
+
+
+=======================================================
+ DYNAMIC CAMPAIGN NOTES
+
+1. Fighter jocks will be allowed to choose from a
+ menu of generated missions that have been assigned
+ to the player's squadron.
+
+2. Cruiser skippers will be given only one generated
+ mission at a time (like KA or SFC), but it will be
+ somewhat broader in scope.
+
+3. Carrier admirals will do what exactly?
+
+4. Both cruiser and carrier missions will often start
+ in the field or on patrol. Fighter missions will
+ always start and end at a base (carrier|station|
+ dirtside starbase).
+
+5. Cruiser and carrier missions will not normally
+ include the starsender translation to the area of
+ conflict. The player will only go through the
+ sender in real time as part of a mission (not as
+ prelude or ending to a mission).
+
+6. Admirals will need to be able to generate orders
+ for their forces during the battle. This implies
+ some kind of Op Command workstation.
+
+7. The mission planner algorithm must construct
+ generated missions that are "fun", not just logical
+ to the campaign. I have a vague notion of using
+ time/distance heuristics to place enemy units as
+ "challenges" on the battle field. e.g. For xxx
+ type of mission, place an enemy destroyer yyy
+ minutes away from the (player|objective|sender).
+
+8. The generated missions do not have to hang together
+ as well as previously planned. That is, we don't
+ need to maintain the feeling that the player is just
+ a unit in an RTS game. Instead, the campaign manager
+ is just a device for generating interesting single
+ player missions as would be found in any game with
+ a static campaign.
+
+ On the other hand, the player should not see any
+ obvious contradictions between the big board and
+ what occurred during their missions. That means,
+ any kills they witnessed must still be visible
+ between missions in the intel report/event log.
+
+
+=======================================================
+ SAMPLE OPERATIONAL SCENARIOS
+
+--- COLD WAR, LOW TENSION ---
+
+1) Training Center (see above)
+
+1a) Live Fire:
+ Engage in "live fire" exercise with a friendly
+ power.
+
+--- COLD WAR, HIGH TENSION ---
+
+2) Restore Order:
+ The enemy is supporting a terrorist puppet govt
+ in an allied star system. Aid the locals in putting
+ down the disturbance.
+
+3) Deliverance:
+ The enemy is sponsoring terrorists and pirates
+ harassing a small outpost system. Ensure free
+ access to the space lanes and aid the delivery
+ of needed supply convoys.
+
+4) Freedom Fighters:
+ The enemy is supporting a despotic govt that is
+ occupying a weaker friendly or neutral system.
+ Aid the locals in driving out the occupying force.
+
+5) Strategic Withdrawal:
+ Ownership of a former protected star system is
+ passing back to the enemy. Oversee the withdrawal
+ of friendly forces. Try to avoid active conflict.
+
+--- FORMAL DECLARATION OF WAR ---
+
+6) First Blood:
+ A research and educational center is on the front
+ lines and in harms way. Set up a strong defensive
+ posture, and oversee the evacuation of non-military
+ personnel.
+
+7) Sneak Attack!
+ The enemy has already struck a friendly system,
+ but they have not yet had time to fortify their
+ position. Coordinate with local forces and evict
+ the hostiles.
+
+8) Fortress of Light:
+ Protect an Eleaan frontier system from enemy
+ attack.
+
+9) Turning Point:
+ The enemy is seeking a decisive victory by wiping
+ out the home fleet. Turn the tables on them by
+ attacking first.
+
+10) Firestorm:
+ Press the advantage by invading a series of
+ enemy manufacturing and military systems.
+
+11) Nightfall:
+ Climactic operation against the enemy home system.
+
+
+=======================================================
+ MISSION TEMPLATE TYPES
+
+FIGHTER
+ TACTICAL FIGHTER WING
+
+ ATTACK SQUADRON
+
+DESTROYER/CRUISER
+ SQUADRON
+ Anti-shipping
+ Shipping Escort, anti-fighter
+ Shipping Escort, anti-cruiser
+ Shipping Escort, general
+ Picket
+ Squadron Hunter
+
+ BATTLE GROUP/TASK FORCE
+ Force-on-Force Engagement
+ Starbase Bombardment, pre-assault
+ Starbase Bombardment, anti-fighter
+
+CARRIER
+
+
+=======================================================
+
+Ship Names:
+
+F-32G Falcon Squadrons
+ Flying Tigers, Bearcats, Aces High, Cool Hands, Wizards
+
+F-36C Stormhawk Squadrons
+ Nighthawks, Mustangs, Stallions, Chargers, Blazers
+
+F/A-38D Talon Squadrons
+ Starknights, Lancers, Wild Bunch, Razorbacks, Buzzards
+
+
+Berents Class FF
+ Berents, Bosporus, Barth, Bering, Balen,
+ Clarkeston, Carlisle, Canton, Delmar, Dardenelles,
+ Darmstadt, Leyte, Messina, Mountebank, Morgan,
+ Malory, Parker, Rainier, Sorrel, Seychelles,
+ Tanly, Trieste, Yarmuz, Zephyr, Zodiac
+
+
+Spectre Class DD
+ Spectre, Wraith, Shadow, Warlock, Phantom,
+ Mistral, Nemesis, Necromancer, Merlin, Nightshade,
+ Moloch, Demon, Phobos, Deimos, Enigma,
+ Phantasm, Revenant, Banshee, Barrows, Gorgon
+
+Courageous Class DG
+ Courageous, Fearless, Stalwart, Defender, Guardian,
+ Steadfast, Assurance, Protector, Heroic, Valiant,
+ Dauntless, Vanguard, Redstone, Victory, Honor,
+ Braveheart, Defiant, Audacious, Valorous, Confident
+
+Devastator Class CA
+ Devastator, Annihilator, Onslaught, Relentless, Argent,
+ Stormwind, Thunder, Hurricane, Inferno, Torrent,
+ Typhoon, Vortex, Predator, Ravager, Demolisher,
+ Havoc, Scourge, Huntress, Warrior, Shrike
+
+Orion Class CV
+ Orion, Antares, Archon, Titan, Hyperion
+
+
+
+OTHERS
+ Wasp, Hornet, Scorpion, Deaths Head,
+ Wolf, Cobra, Viper, Raptor, Python
+
+ Jackal, Zodiac, Scarab, Sphinx, Osiris,
+ Onyx, Isis
+
+-------------------
+1 Fleet = 95 starships + 300 fighters
+
+5 carrier groups
+ 1 CV + 60 Fighters
+ 2 CA
+ 1 DG
+ 1 DD
+ 2 FF
+
+5 battle groups
+ 2 CA
+ 1 DG
+ 1 DD
+ 2 FF
+
+5 destroyer squadrons
+ 2 DG
+ 2 DD
+ 2 FF
+
+==================== STARSHATTER ====================
+ GALAXY : NAMES
+
+ Adavan
+ Aram
+ Borreal
+ Bress
+ Casalle
+ Chi
+ Dawn
+ Elkhart
+ Fenn
+ Gaul
+ Garrison
+ Haiche
+ Hemmik
+ Ilon
+ Janek (Janus-3)
+ Jarnell
+ Kala
+ Khalife
+ Kolchev
+ Korius
+ Lanos
+ Loris
+ Marak
+ Manse
+ Muir
+ Navara
+ Nephrys
+ Nergal
+ Oleanne
+ Omin
+ Patagon
+ Path
+ Pollus
+ Relay
+ Renser
+ Ri
+ Rodis
+ Senna
+ Suven
+ Tal Amin
+ Tarsus
+ Theramin
+ Thralis
+ Ur
+ Volante
+ Warren - world crack canyon/rain-forest settlement (must always face the sun)
+ Whorl
+ Xanthe
+ Zephyr
+ Zone
+
+==================== STARSHATTER ====================
+ GALAXY : PLANET TYPES
+
+ --= Landform Types =--
+ Arid Desert (Arrakis)
+ Frigid Desert (Mars)
+ Frozen Exotic (Titan)
+ Temperate Planar
+ Temperate Mountainous
+ Tropical Forest
+ Tropical Oceanic
+ Icy Oceanic (Scandinavia)
+ Rocky Planar
+ Rocky Mountainous
+ Volcanic (Venus, Io)
+ Barren (Pluto)
+
+ --= Atmospheric Types =--
+ Thin
+ Clear, Breathable
+ Dusty
+ Foggy/Cloudy
+ Dense Poisonous
+ Layered
+
+ --= Population Types =--
+ Agrarian
+ Industrial
+ Mining
+ Research/Technology
+ Military
+ Political
+ Terraforming
+
+==================== STARSHATTER ====================
+ GALAXY : RACES
+
+ Human
+
+ Ele'aan
+ Eltaar - "Those Who Speak for Ele'aas"
+
+ Marakan
+ Commar
+
+ Kasatti
+
+ Zolon Empire
+
+
+
+==================== STARSHATTER ====================
+ CAMPAIGN SEQUENCE
+
+--- COLD WAR, LOW TENSION ---
+
+1) Training Center - Live Fire:
+ Engage in "live fire" exercise with friendly
+ units on the border of Hegemony territory.
+
+--- COLD WAR, HIGH TENSION ---
+
+2) Restore Order:
+ An outlying Hegemony system is using terrorist
+ tactics to gain control of a neighboring neutral star
+ system to create "breathing room" between themselves
+ and the Alliance. Drive out the terrorists and get the
+ neutrals to sign a treaty with the Alliance.
+
+3) Freedom Fighters:
+ Hegemony taxation policy has driven an outlying
+ system to resort to despotism to collect needed
+ revenue. A group of local freedom fighters is
+ attempting to overthrow the Hegemony backed govt.
+ Aid the locals in driving out Hegemony forces.
+
+--- OPEN WARFARE ---
+
+In response to campaign 3, the Hegemony formally
+declares war on the Alliance.
+
+4) Fortress of Light:
+ The Hegemony has struck three Alliance systems,
+ but they have not yet had time to fortify their
+ position. Drive out the enemy forces, and
+ protect Alliance citizens and assets in the area.
+
+5) Firestorm:
+ Alliance Force:Command is planning a major offensive
+ against the core Hegemony systems. This operation
+ is to strike major war production and ship yards
+ to weaken the Hegemony resistance before the
+ main offensive.
+
+6) Nightfall:
+ Climactic operation against the enemy home system.
+ Discovery that the Hegemony worlds have been overrun
+ by the Zolon Empire.
+
+--- ALIEN STRIFE ---
+
+7) Spear of Triton
+
+8)
+
+
+
+
diff --git a/Doc/backstory.doc b/Doc/Backstory.doc
index 76a8785..76a8785 100644
--- a/Doc/backstory.doc
+++ b/Doc/Backstory.doc
Binary files differ
diff --git a/Doc/DESIGNER.TXT b/Doc/Designer.txt
index 237adb8..643722e 100644
--- a/Doc/DESIGNER.TXT
+++ b/Doc/Designer.txt
@@ -1,173 +1,173 @@
-Nicholas Walkland asked:
-
->>I'm currently researching a feature [snip] about game design ideas
->>and how to get developers and publishers
->>interested. Basically, it's [for] people who think they
->>have a good idea for a game [snip].
->>How to present the ideas?
->>Which companies accept these?
->>Any games (good or bad) that have arisen from straightforward game
->>plan/ideas?
-
-Kasey Chang answered,
->Unfortunately, if you are NOT in the industry itself, it is
->practically impossible to see your idea being even considered by major
->companies, much less implemented. Almost all companies get their
->ideas internally, esp. now in the days
->of the sequels. In fact, I am NOT aware of ANY company that accepts
->external ideas (probably due to possibility of law suits). [snip]
->I imagine that it MAY be possible to get someone interested if one has
->a complete game design document written and polished, preferably with
->some sort of tech demo (minimal graphics), but that's more of a
->"calling card" by one programmer or a small team hoping to become a
->"studio" for a major developer, than one game enthusiast's fantasy.
-
-So now, I, Tom Sloper, add in my two cents:
-
-Very well said, Kasey! That is pretty much it, in a nutshell. Only a little
-more to add, which may help outsiders understand a little more of the reasoning
-behind this admittedly unfortunate reality.
-It has been said (right here at this NG) that "ideas are free" (which is
-considerably more true than what I would have said: that "ideas are a dime a
-dozen").
-Every employee in every game company's studio or production department (or R&D
-department, whatever yawannacallit) has at least one idea for their own "dream
-game." I myself have well over half a dozen such ideas that I've been wanting
-to do for years -- and I'm a "Senior Producer" (that just means I'm an /old/
-producer!) at a major game publishing company.
-So let's say that somebody -- "Joe Gamefan" -- writes to me and says (after
-signing a Disclosure Agreement in which we mutually agree that whatever he
-tells us may in fact be something we had already thought of, in which case we
-are not obligated to pay him if we had already started working on something
-similar, and a bunch of other clauses that cover a wide range of possible
-reasons for him to sue us for nothing more than the fact that he wrote us a
-letter), "Ooh! Ooh! I have a great idea for a new game -- why don't you guys
-do Fighter Raid (the classic Atari 2600 game originally published by my
-company, Publishcom), only set in Vietnam!"
-
-Several problems with this idea:
-
-- Like, uh, you think nobody here at Publishcom ever thought of this, or
-something really really close?
-- Like, duh! We LOST Vietnam, ya know???
-- Like, what hardware are you suggesting we do this game on? The Atari 2600?
-You didn't say!
-- Like, who is going to buy this game, why are they going to buy it, why is it
-better than a jillion other jet fighter games out there, etc., etc., etc.?
-- Like, who are you anyway? If we decide we like the idea, are you going to
-program it for us? Can you show it to me on a TV screen? Is that all you're
-sending me? A one-sentence idea in a letter???
-- Fighter Raid is a Publishcom trademark, fully owned and controlled by
-Publishcom. Now that you, Joe Gamefan, have proposed to us that we do an
-updated version, is the trademark diluted? If we do your idea, have you
-somehow weaseled your way into ownership of our trademark? What shenanigans do
-our lawyers have to perform to structure the contract with you so that we
-haven't somehow given away a valuable property over to you, after all you did
-was write a letter?
-
-So guess what I write back to Joe Gamefan? "Thank you very much for your
-submission. Unfortunately, it does not fit into Publishcom's plans at this
-time." Yadda yadda yadda.
-
-I have received numerous non-industry non-professionals' ideas over the years.
-Only one of them really made me sit up and take notice, not because of the game
-idea that it described, but rather because of its excellent presentation. I
-recommended that the submitter (obviously a budding artist of some spectacular
-talent) continue to pursue his interests, even though we didn't follow up on
-his game idea. I never heard from him again, unfortunately, so I don't know
-what he's doing now.
-
-I have also received numerous industry professionals' ideas in the 19 years
-I've been in this industry (I /told/ you I was old!). Guess how many of those
-made me (and my employer) sit up and take notice? Well, I don't have an exact
-count for you, but it was approximately two. Games that subsequently got
-produced and published on (1) the Super Nintendo and Sega Genesis, and (2) the
-Sony Playstation and Sega Saturn (the DOS version was eventually canceled).
-
-Here's the secret formula:
-
-1. Game ideas by a non-industry non-professional, described in a sentence (or a
-few sentences) on paper -- Chances: ZERO! Zilch. Zip. Forget it, it ain't
-gonna happen. Not in this lifetime, nosirreebob! Uh-uh, no way, Jose! Thanks
-for writing, so long now! My employer used to accept non-professional idea
-submissions, but I think the official stance now is that such things are more
-or less discouraged. I haven't checked recently.
-
-2. Games described in an impressive design document, by a very creative guy
-(non-industry, non-professional) who details all the aspects of the game, its
-prospective audience, its chances for success in the competitive marketplace,
-with detailed sketches and illustrations, and maybe even a hint of
-acknowledgment for the technical challenges inherent in the design -- Chances:
-A little better. At the very least, we would possibly (if there were openings)
-offer the creator of such a document a job as a game designer. His game most
-likely will not get made, however.
-
-3. Games adequately described in a written concept document, supplemented by an
-impressive video animation (viewable on a computer or game machine) -- Chances:
-Even better yet. One of the two games I referred to above came in to my
-employer in this form. We can see the idea, we can see that it is fun, we can
-see that the creator(s) can take the idea to the next step -- a finished game
-that we can sell. The party bringing us such a submission may well get a
-contract to develop the game into a real product that actually makes it to
-market. Note that anybody with the wherewithal to make such a presentation is
-most likely in the industry already.
-
-4. Game partially implemented, running on a computer or game machine --
-Chances: Better still. But the game had damn well better be really original
-and exciting, or filling a niche, or in keeping with current market hot
-buttons, or able to be adapted to a hot license, yadda yadda yadda. The other
-of the two games I referred to above came in to my employer in this form --
-from industry professionals.
-
-5. Game fully implemented. All a publisher has to do is put it in a box and
-it'll sell itself -- Chances: The Best. But the game had damn well better be
-really original and exciting, or filling a niche, or in keeping with current
-market hot buttons, or able to be adapted to a hot license, yadda yadda yadda.
-And you had better be ready to make changes if you want Publishcom to
-distribute it (and if they think it needs tweaking). Here's the kicker -- my
-employer gets these submissions in all the time, yet only one in twenty of
-these do we actually pick!
-
-Do the math. Games in category Five have a one in twenty chance -- and games
-in category One have a zero chance. The pattern should be clear to anyone
-who's got a good sense for games.
-
-Still don't understand why this is (why game publishers are so unreasonable)?
-Okay. Imagine for a second that we're talking about a movie idea instead of a
-game idea:
-1. You have a one-sentence idea for a movie, and you are an outsider -- you
-think a Hollywood studio is going to do anything with it? Hah!
-2. You have a full movie script, fully fleshed out, and/or a full movie
-storyboard -- but no actors, no producer, no director -- somebody is going to
-commit money to start production on it? How? Who? In what lifetime?
-3. You have a full script and a full storyboard, and some name actors who have
-read it and found it interesting -- looking a little better -- at least you
-have grounds for starting up some ulcers now, right?
-4. You have a full script, a full storyboard, some name actors ready to go,
-locations all lined up, equipment supplier identified, and a director who is
-interested -- all you need is a movie studio producer to put up some money so
-filming can start. Those ulcers are starting to grow pretty nicely now! Guess
-what industry you are in if you are at this stage??
-5. You have a completely finished, fully edited and post-produced film. All
-you need is to get it marketed and distributed. Have those ulcers eaten their
-way through the stomach lining yet? Surely you don't work in a profession
-unrelated to movie-making if you're in this position -- ???
-
-I reiterate what I have said before at this NG: You want to get your dream
-game produced and published? Get a job in the industry. Work your way up and
-become a producer (or above), or the president of your own company. That's
-step one. Step two will be self-evident once you have completed step one. In
-addition to knowing what step two is, you only need one more thing (assuming
-that the game idea is already world-class): luck. And good timing (I lied when
-I said there was only one more thing).
-
-I suppose, though, in the end, that Kasey's brief statement of the reality of
-this situation has not been added to in large measure by what I have said. His
-4 sentences said it all. All I did was beat that dead horse into the
-GROUND!!!!
-
-Tom Sloper
-(I have mentioned in previous posts what company I work for -- WELL, FORGET IT!
- Pretend you never heard of me before! All I'm saying is, I'm stating my own
-opinions herein, and not the opinions of my employer. End of disclaimer.)
+Nicholas Walkland asked:
+
+>>I'm currently researching a feature [snip] about game design ideas
+>>and how to get developers and publishers
+>>interested. Basically, it's [for] people who think they
+>>have a good idea for a game [snip].
+>>How to present the ideas?
+>>Which companies accept these?
+>>Any games (good or bad) that have arisen from straightforward game
+>>plan/ideas?
+
+Kasey Chang answered,
+>Unfortunately, if you are NOT in the industry itself, it is
+>practically impossible to see your idea being even considered by major
+>companies, much less implemented. Almost all companies get their
+>ideas internally, esp. now in the days
+>of the sequels. In fact, I am NOT aware of ANY company that accepts
+>external ideas (probably due to possibility of law suits). [snip]
+>I imagine that it MAY be possible to get someone interested if one has
+>a complete game design document written and polished, preferably with
+>some sort of tech demo (minimal graphics), but that's more of a
+>"calling card" by one programmer or a small team hoping to become a
+>"studio" for a major developer, than one game enthusiast's fantasy.
+
+So now, I, Tom Sloper, add in my two cents:
+
+Very well said, Kasey! That is pretty much it, in a nutshell. Only a little
+more to add, which may help outsiders understand a little more of the reasoning
+behind this admittedly unfortunate reality.
+It has been said (right here at this NG) that "ideas are free" (which is
+considerably more true than what I would have said: that "ideas are a dime a
+dozen").
+Every employee in every game company's studio or production department (or R&D
+department, whatever yawannacallit) has at least one idea for their own "dream
+game." I myself have well over half a dozen such ideas that I've been wanting
+to do for years -- and I'm a "Senior Producer" (that just means I'm an /old/
+producer!) at a major game publishing company.
+So let's say that somebody -- "Joe Gamefan" -- writes to me and says (after
+signing a Disclosure Agreement in which we mutually agree that whatever he
+tells us may in fact be something we had already thought of, in which case we
+are not obligated to pay him if we had already started working on something
+similar, and a bunch of other clauses that cover a wide range of possible
+reasons for him to sue us for nothing more than the fact that he wrote us a
+letter), "Ooh! Ooh! I have a great idea for a new game -- why don't you guys
+do Fighter Raid (the classic Atari 2600 game originally published by my
+company, Publishcom), only set in Vietnam!"
+
+Several problems with this idea:
+
+- Like, uh, you think nobody here at Publishcom ever thought of this, or
+something really really close?
+- Like, duh! We LOST Vietnam, ya know???
+- Like, what hardware are you suggesting we do this game on? The Atari 2600?
+You didn't say!
+- Like, who is going to buy this game, why are they going to buy it, why is it
+better than a jillion other jet fighter games out there, etc., etc., etc.?
+- Like, who are you anyway? If we decide we like the idea, are you going to
+program it for us? Can you show it to me on a TV screen? Is that all you're
+sending me? A one-sentence idea in a letter???
+- Fighter Raid is a Publishcom trademark, fully owned and controlled by
+Publishcom. Now that you, Joe Gamefan, have proposed to us that we do an
+updated version, is the trademark diluted? If we do your idea, have you
+somehow weaseled your way into ownership of our trademark? What shenanigans do
+our lawyers have to perform to structure the contract with you so that we
+haven't somehow given away a valuable property over to you, after all you did
+was write a letter?
+
+So guess what I write back to Joe Gamefan? "Thank you very much for your
+submission. Unfortunately, it does not fit into Publishcom's plans at this
+time." Yadda yadda yadda.
+
+I have received numerous non-industry non-professionals' ideas over the years.
+Only one of them really made me sit up and take notice, not because of the game
+idea that it described, but rather because of its excellent presentation. I
+recommended that the submitter (obviously a budding artist of some spectacular
+talent) continue to pursue his interests, even though we didn't follow up on
+his game idea. I never heard from him again, unfortunately, so I don't know
+what he's doing now.
+
+I have also received numerous industry professionals' ideas in the 19 years
+I've been in this industry (I /told/ you I was old!). Guess how many of those
+made me (and my employer) sit up and take notice? Well, I don't have an exact
+count for you, but it was approximately two. Games that subsequently got
+produced and published on (1) the Super Nintendo and Sega Genesis, and (2) the
+Sony Playstation and Sega Saturn (the DOS version was eventually canceled).
+
+Here's the secret formula:
+
+1. Game ideas by a non-industry non-professional, described in a sentence (or a
+few sentences) on paper -- Chances: ZERO! Zilch. Zip. Forget it, it ain't
+gonna happen. Not in this lifetime, nosirreebob! Uh-uh, no way, Jose! Thanks
+for writing, so long now! My employer used to accept non-professional idea
+submissions, but I think the official stance now is that such things are more
+or less discouraged. I haven't checked recently.
+
+2. Games described in an impressive design document, by a very creative guy
+(non-industry, non-professional) who details all the aspects of the game, its
+prospective audience, its chances for success in the competitive marketplace,
+with detailed sketches and illustrations, and maybe even a hint of
+acknowledgment for the technical challenges inherent in the design -- Chances:
+A little better. At the very least, we would possibly (if there were openings)
+offer the creator of such a document a job as a game designer. His game most
+likely will not get made, however.
+
+3. Games adequately described in a written concept document, supplemented by an
+impressive video animation (viewable on a computer or game machine) -- Chances:
+Even better yet. One of the two games I referred to above came in to my
+employer in this form. We can see the idea, we can see that it is fun, we can
+see that the creator(s) can take the idea to the next step -- a finished game
+that we can sell. The party bringing us such a submission may well get a
+contract to develop the game into a real product that actually makes it to
+market. Note that anybody with the wherewithal to make such a presentation is
+most likely in the industry already.
+
+4. Game partially implemented, running on a computer or game machine --
+Chances: Better still. But the game had damn well better be really original
+and exciting, or filling a niche, or in keeping with current market hot
+buttons, or able to be adapted to a hot license, yadda yadda yadda. The other
+of the two games I referred to above came in to my employer in this form --
+from industry professionals.
+
+5. Game fully implemented. All a publisher has to do is put it in a box and
+it'll sell itself -- Chances: The Best. But the game had damn well better be
+really original and exciting, or filling a niche, or in keeping with current
+market hot buttons, or able to be adapted to a hot license, yadda yadda yadda.
+And you had better be ready to make changes if you want Publishcom to
+distribute it (and if they think it needs tweaking). Here's the kicker -- my
+employer gets these submissions in all the time, yet only one in twenty of
+these do we actually pick!
+
+Do the math. Games in category Five have a one in twenty chance -- and games
+in category One have a zero chance. The pattern should be clear to anyone
+who's got a good sense for games.
+
+Still don't understand why this is (why game publishers are so unreasonable)?
+Okay. Imagine for a second that we're talking about a movie idea instead of a
+game idea:
+1. You have a one-sentence idea for a movie, and you are an outsider -- you
+think a Hollywood studio is going to do anything with it? Hah!
+2. You have a full movie script, fully fleshed out, and/or a full movie
+storyboard -- but no actors, no producer, no director -- somebody is going to
+commit money to start production on it? How? Who? In what lifetime?
+3. You have a full script and a full storyboard, and some name actors who have
+read it and found it interesting -- looking a little better -- at least you
+have grounds for starting up some ulcers now, right?
+4. You have a full script, a full storyboard, some name actors ready to go,
+locations all lined up, equipment supplier identified, and a director who is
+interested -- all you need is a movie studio producer to put up some money so
+filming can start. Those ulcers are starting to grow pretty nicely now! Guess
+what industry you are in if you are at this stage??
+5. You have a completely finished, fully edited and post-produced film. All
+you need is to get it marketed and distributed. Have those ulcers eaten their
+way through the stomach lining yet? Surely you don't work in a profession
+unrelated to movie-making if you're in this position -- ???
+
+I reiterate what I have said before at this NG: You want to get your dream
+game produced and published? Get a job in the industry. Work your way up and
+become a producer (or above), or the president of your own company. That's
+step one. Step two will be self-evident once you have completed step one. In
+addition to knowing what step two is, you only need one more thing (assuming
+that the game idea is already world-class): luck. And good timing (I lied when
+I said there was only one more thing).
+
+I suppose, though, in the end, that Kasey's brief statement of the reality of
+this situation has not been added to in large measure by what I have said. His
+4 sentences said it all. All I did was beat that dead horse into the
+GROUND!!!!
+
+Tom Sloper
+(I have mentioned in previous posts what company I work for -- WELL, FORGET IT!
+ Pretend you never heard of me before! All I'm saying is, I'm stating my own
+opinions herein, and not the opinions of my employer. End of disclaimer.)
:o) \ No newline at end of file
diff --git a/Doc/dynamic campaigns.txt b/Doc/Dynamic Campaigns.txt
index 75e3263..bff41ff 100644
--- a/Doc/dynamic campaigns.txt
+++ b/Doc/Dynamic Campaigns.txt
@@ -1,701 +1,701 @@
-From - Mon Nov 02 22:29:24 1998
-Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!cpk-news-hub1.bbnplanet.com!news.news.gtei.net!firehose.mindspring.com!not-for-mail
-From: dennya@mindspring.com (Denny Atkin)
-Newsgroups: comp.sys.ibm.pc.games.flight-sim
-Subject: Dynamic Campaigns: Discuss.
-Date: Tue, 03 Nov 1998 04:03:25 GMT
-Organization: Not officially representing CGW here in my free time
-Lines: 40
-Message-ID: <364067e5.15703318@news.mindspring.com>
-Reply-To: dennya@mindspring.com
-NNTP-Posting-Host: user-38ld6ro.dialup.mindspring.com
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-X-Server-Date: 3 Nov 1998 04:05:20 GMT
-X-Newsreader: Forte Agent 1.5/32.451
-X-No-Archive: yes
-Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154235
-
-Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
-going so far as to say they won't buy a sim that doesn't feature them.
-
-Here's the big question: Which sims are you holding up as examples of good
-dynamic campaigns? Because until VERY recently, there haven't been that many
-opportunities to experience a good dynamic campaign. Falcon 3.0's is often held
-up as the previous Holy Grail, but that's mostly people remembering things
-better than they were. Falcon 3.0 had a number of kludgy elements and faked
-occurrences in its campaign--such as the MiG-19s that often spontaneously
-spawned to harass you when you were landing. EF2000 had a fully dynamic
-campaign, but the mission structures were so repetitive that I bored of it as
-quickly as I did any "canned mission" sim. Longbow 2 had a good dynamic
-campaign, but the most interesting missions were the prescripted ones.
-
-So I pose these questions, just for discussion:
-1) What are the examples of good past dynamic campaigns? What made them good,
-and kept them from getting boring?
-
-2) If a mission featured a scripted campaign, but had features that kept it
-from being repetitive -- targets that stayed destroyed, enemy locations and
-force makeups that were randomly generated to keep them from being predictable,
-being retasked to destroy missed targets -- would that be an acceptable
-substitute?
-
-3) Is it replayability or the chance to affect the outcome of the war that
-makes dynamic campaigns appealing to you?
-
-4) A dynamic campaign is never going to generate a mission such as "shoot down
-Admiral Yamamoto in your P-38. " Don't scripted campaigns have the potential to
-be a lot more interesting?
-
-(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
-what I think the perfect campaign for today's techology is in a future post.
-But I want to hear from some of the rest of you without "leading" into a
-discussion of my own theories. And let's not even open hte multiplayer can of
-worms. :-)
- ---------------------------------------------------
- Denny Atkin / dennya@mindspring.com
- I have not yet begun to procrastinate
- ---------------------------------------------------
-From - Mon Nov 02 22:29:24 1998
-Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!ix.netcom.com!news
-From: "Greg Cisko" <gcisko@nOsPaMix.netcom.net>
-Newsgroups: comp.sys.ibm.pc.games.flight-sim
-Subject: Re: Dynamic Campaigns: Discuss.
-Date: Mon, 2 Nov 1998 22:19:54 -0600
-Organization: ICGNetcom
-Lines: 81
-Message-ID: <71m0g1$bim@sjx-ixn6.ix.netcom.com>
-References: <364067e5.15703318@news.mindspring.com>
-NNTP-Posting-Host: chf-il5-83.ix.netcom.com
-X-NETCOM-Date: Mon Nov 02 8:23:29 PM PST 1998
-X-Newsreader: Microsoft Outlook Express 4.72.3110.1
-X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
-Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154240
-
-Denny Atkin wrote in message <364067e5.15703318@news.mindspring.com>...
->Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
->going so far as to say they won't buy a sim that doesn't feature them.
->
->Here's the big question: Which sims are you holding up as examples of good
->dynamic campaigns? Because until VERY recently, there haven't been that
-many
-
-
-In shirt I would almost have to say there are no good dynamic
-campaigns yet :-) I did hear the campaigns in iF22 were supposedly
-good. But the rest of the game was basicly crap so I wouldn't even
-give it a shot.
-
->opportunities to experience a good dynamic campaign. Falcon 3.0's is often
-held
->up as the previous Holy Grail, but that's mostly people remembering things
->better than they were. Falcon 3.0 had a number of kludgy elements and faked
-
-
-Correct. I remember vividly the first mission if the Kurile(sp?) campaign
-was
-always the same mission. Not very dynamic imho. Also not very realistic
-to shoot 15 migs only to get wasted while I was on final approach. Like
-there wouldn't be any air defenses near an american base...
-
->occurrences in its campaign--such as the MiG-19s that often spontaneously
->spawned to harass you when you were landing. EF2000 had a fully dynamic
->campaign, but the mission structures were so repetitive that I bored of it
-as
->quickly as I did any "canned mission" sim. Longbow 2 had a good dynamic
->campaign, but the most interesting missions were the prescripted ones.
-
-
-I guess you can't have your cake and eat it too :-)
-
->2) If a mission featured a scripted campaign, but had features that kept it
->from being repetitive -- targets that stayed destroyed, enemy locations and
->force makeups that were randomly generated to keep them from being
-predictable,
->being retasked to destroy missed targets -- would that be an acceptable
->substitute?
-
-
-For me yes definately.
-
->3) Is it replayability or the chance to affect the outcome of the war that
->makes dynamic campaigns appealing to you?
-
-
-Replayability for me is not the issue. But rather a chance to effect the
-outcome.
-
->4) A dynamic campaign is never going to generate a mission such as "shoot
-down
->Admiral Yamamoto in your P-38. " Don't scripted campaigns have the
-potential to
->be a lot more interesting?
-
-
-Yes. Until you run into one that you cannot beat. Which you always know
-a flight of migs will be at a certain place every time. Yada, yada yada :-)
-
---
-Header address intentionally scrambled to ward off the spamming hordes.
-
-cisko [AT] ix [DOT] netcom [DOT] com
-
->(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
->what I think the perfect campaign for today's techology is in a future
-post.
->But I want to hear from some of the rest of you without "leading" into a
->discussion of my own theories. And let's not even open hte multiplayer can
-of
->worms. :-)
-> ---------------------------------------------------
-> Denny Atkin / dennya@mindspring.com
-> I have not yet begun to procrastinate
-> ---------------------------------------------------
-
-
-From - Mon Nov 02 22:29:25 1998
-Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news.rdc1.bc.wave.home.com.POSTED!not-for-mail
-From: silenus@home.com (David Clark)
-Newsgroups: comp.sys.ibm.pc.games.flight-sim
-Subject: Re: Dynamic Campaigns: Discuss.
-Message-ID: <363e80ff.260853340@192.168.0.2>
-References: <364067e5.15703318@news.mindspring.com>
-X-Newsreader: Forte Free Agent 1.11/32.235
-Lines: 89
-Date: Tue, 03 Nov 1998 04:42:17 GMT
-NNTP-Posting-Host: 24.112.120.121
-NNTP-Posting-Date: Mon, 02 Nov 1998 20:42:17 PDT
-Organization: @Home Network Canada
-Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154251
-
-On Tue, 03 Nov 1998 04:03:25 GMT, dennya@mindspring.com (Denny Atkin)
-wrote:
-
->Here's the big question: Which sims are you holding up as examples of good
->dynamic campaigns?
-
-Umm... perhaps EF2000 and Longbow 2. The best "dynamic campaigns" that
-I've seen weren't Flight Sims at all - they were strategy games like
-X-Com and Jagged Alliance.
-
->So I pose these questions, just for discussion:
-
-Good questions, well phrased.
-
->1) What are the examples of good past dynamic campaigns? What made them good,
->and kept them from getting boring?
-
-IMHO, the property that makes a dynamic campaign valuable is that the
-missions seem plausible, but unplanned. Modern warfare is
-extraordinarily fluid and chaotic, and set-piece battles are very
-rare. Battles should just sort of 'precipitate' out of the strategic
-situation - often large air battles are unplanned, and are simply the
-result of a few fighters running into one another - the furball grows
-as both sides dump in additional aircraft, while neither commander
-really understands the scale of the battle that is developing.
-
-The thing that made EF2000 so enjoyable was that most of the battles
-had a 'meeting engagement' feel to them - since there was no 'plot',
-my actions weren't constrained at all. I could avoid battles (if I was
-lucky), or search out more fights, depending on my understanding of
-the tactical situation.
-
->2) If a mission featured a scripted campaign, but had features that kept it
->from being repetitive -- targets that stayed destroyed, enemy locations and
->force makeups that were randomly generated to keep them from being predictable,
->being retasked to destroy missed targets -- would that be an acceptable
->substitute?
-
-I guess so. My criteria is that the forces I face have a _reason_ for
-being there (even if the 'reason' is just random chance). If I feel
-like a scenario has been 'tweaked' for 'balance', my suspension of
-disbelief is gone. I want to fight the forces that would _probably be
-there_ in real life, not the ones that a scenario designer feels I can
-handle. I never minded being outnumbered in EF2000, since if I was, it
-was just my bad luck, not designer maliciousness.
-
->3) Is it replayability or the chance to affect the outcome of the war that
->makes dynamic campaigns appealing to you?
-
-The chance to affect the outcome of the war is not important to me at
-all. Most pilots won't affect the outcome of a war materially either
-- the reason I play flight sims is to role-play (however inaccurately)
-the experiences of someone with a much more interesting job than me -
-and the limits of individual power is part of that role.
-
-Of course, I also loved the occasional uneventful CAP mission in
-EF2000, so I guess I'm kind of peculiar.
-
->4) A dynamic campaign is never going to generate a mission such as "shoot down
->Admiral Yamamoto in your P-38. " Don't scripted campaigns have the potential to
->be a lot more interesting?
-
-I suppose. I find the generated missions in EF2000 and Longbow2 to be
-extremely interesting - no two are the same, since the strategic
-situation, the position of the threat, etc are always different.
-Others disagree, and say that after a while, one dam-busting mission
-is pretty much like the next. I've never felt that way, but I can
-understand their position.
-
->(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
->what I think the perfect campaign for today's techology is in a future post.
->But I want to hear from some of the rest of you without "leading" into a
->discussion of my own theories. And let's not even open hte multiplayer can of
->worms. :-)
-
-Without having seen the game, I guess Falcon4 offers the most
-promising type of dynamic campaign.
-
-What I really want to play is a highly detailed 'world simulator' in
-which both armies would carry out their war plans in real time. My
-aircraft would be one of the combatants, neither more or less
-influential than any other. In the end the victor would win because
-they _won_, not because I managed a 75% kill rate instead of a 65%...
-
-David Clark
-Third World War (GDW) website...
-http://members.home.net/silenus/tww/index.htm
-
-
-From - Mon Nov 02 22:29:25 1998
-Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.cwix.com!192.220.250.21!netnews1.nw.verio.net!netnews.nwnet.net!news.nodak.edu!not-for-mail
-From: "Michael J. Iverson" <micivers@badlands.nodak.edu>
-Newsgroups: comp.sys.ibm.pc.games.flight-sim
-Subject: Re: Dynamic Campaigns: Discuss.
-Date: Mon, 02 Nov 1998 22:48:53 -0600
-Organization: North Dakota Higher Ed. Network
-Lines: 62
-Message-ID: <363E8B35.64CBAFDD@badlands.nodak.edu>
-References: <364067e5.15703318@news.mindspring.com>
-NNTP-Posting-Host: und-as3p28.und.nodak.edu
-Mime-Version: 1.0
-Content-Type: text/plain; charset=us-ascii
-Content-Transfer-Encoding: 7bit
-X-Mailer: Mozilla 4.5 [en] (Win98; U)
-X-Accept-Language: en
-Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154263
-
-For me, a dynamic campaign should give me that "OK, time to go to work"
-feeling when I roll down the runway (or lift off from the FARP). It
-might not be the most challenging mission I've ever flown, but I know
-that I'm contributing towards the "war effort." I'd like to feel that
-the world is alive around me. One thing I didn't like in LB2 was that
-after a half hour or so, the "world" would just go to sleep - no more
-enemy CAPs or strike missions, no more enemy advances.
-
-Show me stats, supplies, squadron members, and info on my pilot. I
-think Red Baron II was one of the only sims that made me genuinely
-pissed off by having my pilot killed in action. I definitely wanted to
-stay alive in that sim.
-
-IMO, scripted missions have a tendency to be made a little too hard.
-Some game designers seem to think that impossible odds = fun. I
-disagree.
-
-Mike
-http://volunteers.warbirds.org
-
-From - Mon Nov 02 22:29:25 1998
-Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!newsfeed.direct.ca!cyclone.bc.net!logbridge.uoregon.edu!news.ycc.yale.edu!mars.its.yale.edu!rjl26
-From: rjl26@mars.its.yale.edu (Robin Lee)
-Newsgroups: comp.sys.ibm.pc.games.flight-sim
-Subject: Re: Dynamic Campaigns: Discuss.
-Date: 3 Nov 1998 05:14:22 GMT
-Organization: YLS
-Lines: 61
-Message-ID: <71m3fe$pk3$1@news.ycc.yale.edu>
-References: <364067e5.15703318@news.mindspring.com>
-NNTP-Posting-Host: mars.its.yale.edu
-Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154269
-
-In article <364067e5.15703318@news.mindspring.com>,
-Denny Atkin <dennya@mindspring.com> wrote:
->
->(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
->what I think the perfect campaign for today's techology is in a future post.
->But I want to hear from some of the rest of you without "leading" into a
->discussion of my own theories. And let's not even open hte multiplayer can of
->worms. :-)
-
-Just a few thoughts...
-
-1. For me, the "generic mission" problem is not a particularly
-troublesome issue because I find little appeal in the high dramatics of a
-"mission that won the war." Drama on that level does not take place very
-often in air warfare; by and large, an air campaign consists of a series
-of routinized mission profiles run on targets that aircrews know little
-about. Even for those rare missions that do wind up having a hugely
-significant impact on the war, aircrews are not likely to know about this
-until after the fact, though they may have some good guesses as to what
-they are doing (witness Smallwood's account of the anti-Saddam missions
-during Desert Storm, for instance). A so-called "routine" sortie provides
-more than enough drama for me -- "blow up the Death Star" missions have
-a little too much of Hollywood about them for my taste.
-
-2. Extension of the first point: for training, planning, and proficiency
-reasons, mission types are by nature generic. You want aircrews to be
-able to fit the mission into one of a fixed number of profiles for which
-they have been trained. Even where the mission is genuinely different,
-the operations structure of a modern air force is going to try to force
-the situation into familiar terms. Therefore, missions that "feel the
-same" may be realistic, and while some may argue that they become boring
-and therefore undesireable, I don't necessarily see them as such.
-
-3. An interesting mission does not have to be scripted; a relatively
-generic, template-based sortie can be turned into a genuinely memorable
-mission by the introduction of those random events that make tactical
-military aviation such a chaotic affair -- assigned tanker could go down,
-somebody crashes and fouls the runway, somebody goes down and you get
-called to CAP the survivors, etc. There is no particular reason that
-these events need to be scripted; their very randomness is what makes them
-exciting.
-
-4. As a general matter, I view mission generation and campaign dynamics
-in much the same light as I view sausage production; I don't really want
-to inquire too closely into the details of either. The illusion that I
-want to maintain is that the missions are generated by a real operations
-staff reacting to unpredictable events, not by a software campaign engine
-or by selection from a fixed database of mission scripts. And like
-sausages, the worst imaginable case is when the mission itself reveals
-obvious hints as to its origin. To me, a so-called "dynamic
-campaign" produces missions that simply *look* less contrived than
-"handpainted" missions, and therefore is a little better at maintaining
-the illusion.
-
-
--R.
---
-_____
-Robin John Lee <amraam@ix.netcom.com>
-YLS '99 - New Haven, Connecticut, USA
-Vulture's Row/Russian Navy - <http://www.webcom.com/amraam>
-From - Mon Nov 02 22:29:25 1998
-Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.cwix.com!204.210.0.20!news.san.rr.com!not-for-mail
-From: "Jarrod Smith" <jsmith@scripps.edu>
-Newsgroups: comp.sys.ibm.pc.games.flight-sim
-References: <364067e5.15703318@news.mindspring.com>
-Subject: Re: Dynamic Campaigns: Discuss.
-Lines: 105
-MIME-Version: 1.0
-Content-Type: text/plain;
- charset="iso-8859-1"
-Content-Transfer-Encoding: 7bit
-X-Newsreader: Microsoft Outlook Express 4.72.3155.0
-X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
-Message-ID: <2Rw%1.5101$q15.153954@news.san.rr.com>
-Date: Mon, 2 Nov 1998 21:50:44 -0800
-NNTP-Posting-Host: 204.210.61.137
-X-Trace: news.san.rr.com 910072254 204.210.61.137 (Mon, 02 Nov 1998 21:50:54 PDT)
-NNTP-Posting-Date: Mon, 02 Nov 1998 21:50:54 PDT
-Organization: TWC Road Runner, San Diego, CA
-Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154285
-
-
-Denny Atkin wrote in message <364067e5.15703318@news.mindspring.com>...
->Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
->going so far as to say they won't buy a sim that doesn't feature them.
->
->Here's the big question: Which sims are you holding up as examples of good
->dynamic campaigns?
-
-For me, it is Longbow2 and Falcon 3.0. I had a hiatus from simming during
-my collegiate years (lack of hardware fundage :-), so I can't comment on
-anything in between.
-
->
->So I pose these questions, just for discussion:
->1) What are the examples of good past dynamic campaigns? What made them
-good,
->and kept them from getting boring?
-
-
-Essentially, I don't much care for branching type missions that make up a
-"campaign". It annoys me that the mission objectives will be the same each
-time you play through the campaign in one of the "winning branches". That
-detracts from replayability which is something I value very much in a sim.
-What keeps a dynamic campaign interesting for me:
-
-Each mission provides different objectives depending on the state of the
-total war (air and ground, supply lines, etc.). If your supply lines are
-out, you open them up. If you are losing ground, you cover the retreat. If
-you are taking ground, you take out critical elements of the enemy's
-defenses, and/or defend your ground assets as they move forward to capture
-territory. This type of ebb and flow can go on indefinitely until you make
-some decisive moves toward accomplishing your objective. This is limited by
-your performance both in the cockpit as well as inventory and personnel
-management, etc. This is what immerses me into a dynamic campaign. The
-individual missions are less important, and any good stout mission generator
-with subsequent mission editing options will fill the bill in that dept. I
-did like the splash of hollywood that was infused into LB2 by virtue of its
-scripted missions interspersed with the generated ones. You still can't
-argue with the entertainment value of a well-designed scripted mission. I
-guess for me, I seperate the mission from the campaign. I can enjoy flying
-a cool scripted mission. But it is different from fighting war from the
-campaign perspective. I guess I like the illusion of a strategic element
-that is infused into a good dynamic campaign engine.
-
->2) If a mission featured a scripted campaign, but had features that kept it
->from being repetitive -- targets that stayed destroyed, enemy locations and
->force makeups that were randomly generated to keep them from being
-predictable,
->being retasked to destroy missed targets -- would that be an acceptable
->substitute?
-
-
-Much of what you said above would go a long way toward fixing some of the
-problems, but in the end, even though this is realistic and believable, it
-doesn't help the replayability aspect a whole lot. I'm not saying a sim
-like this wouldn't be fun, though. It certainly could be an acceptable
-substitute, but there would have to be some type of extraordinary
-multiplayer capability and/or mission builder to enhance the experience.
-Otherwise, it wouldn't last that long on my harddrive.
-
->3) Is it replayability or the chance to affect the outcome of the war that
->makes dynamic campaigns appealing to you?
-
-
-As outlined above, I think both are important to me. Also the illusion of
-strategy going on behind the scenes and you playing your part in that
-strategy makes a good dynamic campaign compelling to play.
-
->4) A dynamic campaign is never going to generate a mission such as "shoot
-down
->Admiral Yamamoto in your P-38. " Don't scripted campaigns have the
-potential to
->be a lot more interesting?
-
-
-Scripted *missions* do have the potential to be more interesting. Scripted
-campaigns do not, IMO.
-
->(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
->what I think the perfect campaign for today's techology is in a future
-post.
->But I want to hear from some of the rest of you without "leading" into a
->discussion of my own theories. And let's not even open hte multiplayer can
-of
->worms. :-)
-
-
-Here is what I think would be incredible in a "campaign engine". The engine
-calculates orders which get handed to you from on high. These orders state
-that you need to accomplish some objective to further the war effort. Say
-it is to reduce the opposition's EWR capabilities by some percentage, or
-reduce their naval capabilites in some capacity. Whatever. This becomes
-your short-term objective over the next handful of missions. The sim then
-hands you tools: Intelligence gathering tools, a sophisticated mission
-planner/builder, updated information on the assets that you have to complete
-the task, etc. Then you set out to work and build your own campaign, or at
-least part of it. Then jump in and fly whichever missions look to be the
-most fun to you. The combination of immersion, strategy, replayability, and
-challenge in a sim like this would make it irresistable, IMO.
-Unfortunately, it also sounds difficult and expensive to put together :-)
-
-Jarrod Smith
-The Scripps Research Institute
-http://www.scripps.edu/~jsmith
-
-From - Mon Nov 02 22:29:25 1998
-Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!newsfeed.direct.ca!newspeer.monmouth.com!newsfeed-east.supernews.com!supernews.com!Supernews69!not-for-mail
-From: "enzo" <enzo@nospam.com>
-Newsgroups: comp.sys.ibm.pc.games.flight-sim
-Subject: Re: Dynamic Campaigns: Discuss.
-Date: Mon, 2 Nov 1998 22:07:25 -0800
-Organization: http://www.supernews.com, The World's Usenet: Discussions Start Here
-Lines: 186
-Message-ID: <71m6db$49n$1@supernews.com>
-References: <364067e5.15703318@news.mindspring.com>
-NNTP-Posting-Host: 207.211.61.222
-X-Trace: 910073067 WUENVH4GT3DDECFD3C usenet78.supernews.com
-X-Complaints-To: newsabuse@supernews.com
-X-Newsreader: Microsoft Outlook Express 4.72.3110.1
-X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
-Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154288
-
-Denny's starting a new thread! I'm getting verklempt! ; )
-
-Ok, I've gotta bite on this one - can't allow the possibility for a new
-pro-canned movement (or even a "maybe scripted isn't so bad"
-movement, for that matter either!) : )
-
-Disclaimers - this is all MHO. I ended up getting really wordy. My apologies,
- but I wanted to write until I got it all off my chest.
-
-Denny Atkin wrote in message <364067e5.15703318@news.mindspring.com>...
->Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
->going so far as to say they won't buy a sim that doesn't feature them.
->
->Here's the big question: Which sims are you holding up as examples of good
->dynamic campaigns? Because until VERY recently, there haven't been that many
->opportunities to experience a good dynamic campaign. Falcon 3.0's is often held
->up as the previous Holy Grail, but that's mostly people remembering things
->better than they were. Falcon 3.0 had a number of kludgy elements and faked
->occurrences in its campaign--such as the MiG-19s that often spontaneously
->spawned to harass you when you were landing. EF2000 had a fully dynamic
->campaign, but the mission structures were so repetitive that I bored of it as
->quickly as I did any "canned mission" sim. Longbow 2 had a good dynamic
->campaign, but the most interesting missions were the prescripted ones.
->
->So I pose these questions, just for discussion:
->1) What are the examples of good past dynamic campaigns? What made them good,
->and kept them from getting boring?
-
-
-----Top examples were Falcon 3 and Longbow 2.
-
- Both integrate air and ground
-combat well, give a certain degree of flexibility, and both calculate the
-progress of the war according to the ability of the ground forces to fight, not
-according to your mission score. Therefore, you can get killed in a mission, but
-still win a battle, because you managed to make a positive impact. You are a
-part of the picture - important, but you are *in* the world, not "the world revolves
-around you" - critical distinction to make.
-
---------Good examples include iF/A-18E, TAW, and apparently Tornado (although I
-didn't get very far into Tornado's campaign, but for non-campaign related reasons)
-
-iF/A-18E is good, but TALON still needs more refinement before it will realize it's
-goals properly IMHO. Very important that friendly assets (eg friendly naval ships)
-will try to protect you/themselves with their SAM screens - opens up possibilities
-TAW took an interesting "multiple scoreboard" approach, but it seems to have taken
-a purely political aspect to the war rather than considering the ground war. That
-pays too much homage to the low-intensity conflicts IMHO. That prevents it from
-being ranked with Falcon 3/Longbow 2.
-
-(I could even sneak X-COM into the picture! : )
-
-----------Mediocre examples include RB2, EF2000, M1TP2
-
-RB2 - basically a random mission generator. M1TP2 - same thing.
-EF2000 - no ground war, your FEBA moves as a result not of
-the battle, not even of your accomplishments, but exclusively as a
-result of your mission score.
-
----------Examples that deserve to be shot are iF-22 Raptor and Team Apache.
-
-iF-22 Raptor claimed dynamic and was scripted. Team Apache either
-also claimed it, or at least hinted strongly at it with it's real time clock
-(that ended up being utterly superfluous). JSF might belong here, too, but
-frankly I got sick of it way too fast to figure that out.
-
->2) If a mission featured a scripted campaign, but had features that kept it
->from being repetitive -- targets that stayed destroyed, enemy locations and
->force makeups that were randomly generated to keep them from being predictable,
->being retasked to destroy missed targets -- would that be an acceptable
->substitute?
-
-
-You seem to be describing Janes F-15 for the most past. My answer is no.
-
-For starters, poor scripted missions are no better than random mission generators.
-Good scripted missions, no matter how you shake or stir it, end up where the
-player is always trying to second-guess the designer. Also, "randomizing" a
-scripted mission isn't a whole lot more fun than shaking up one of those
-glass paperweights with the fake snow inside. Sure, a few elements may
-shift around, but you're looking at the same scene no matter what. IMHO, even
-when dynamic campaign missions get somewhat repetitive, it still doesn't
-feel as rigidly constrained.
-
->3) Is it replayability or the chance to affect the outcome of the war that
->makes dynamic campaigns appealing to you?
-
-
-Both, but there is more to it than that.
-
-Several things (most have a little interrelation):
-
-1- Yes, replayability
-
-2- Not doing the same mission over again just because I failed it the first time
-
-3- Being able to play a part/have an affect in a simulated war, absolutely -
- as long as the designers carefully balance my ability to affect that war so as not
- to over or under value my contribution. If I find myself *caring* about the state
- of the war when I'm driving to class, that's a good sign. That's never happened
- to me in any game except those with dynamic campaigns.
-
-4- related to #3 - What you do, actually **matters**. There is a point to it
- other than simply "jumping through hoops", then getting Pavlovian
- reinforcement by little FMV treats. :^P Phooey! I want a sense of
- accomplishment that's more profound than that.
-
-5A - Not second guessing the designer. You are focused on what needs to be
- done, what you can do to help the war effort, not "Would the mission
- designers really hide an ambush over there? Do they expect me to have to resort
- to guns or try something else? Maybe I'm supposed to use a stealthy fighter?"
-
-5B - MISSIONS ARE NOT PUZZLES!!!
- the worst examples - "Ok - let me get this straight - I have to first go to point A
- and hit the tanks with the Mavericks, then I have only a few seconds left to
- afterburn to point B and use the AMRAAMs on the Mig-21's to protect my
- rescue helo from being shot down, then I have to go to point C and dogfight
- with another group of MiGs before they bomb my airbase. Whew, that only
- took eight failures to figure out!"
-
-6 - Unpredictability - I've repeatedly heard the claim that only a scripted mission can
- really surprise a player. I disagree - There are many things that I have experienced
- in dynamic campaigns that were surprising, entertaining, and all the more fun
- because elements create situations that mission designers couldn't or wouldn't
- have possibly dreamt up.
-
- Ask me if I'd prefer to explore the state by train, car, or helicopter...
- Sure, a train may go through some nice scenery, but really you're just along for the ride.
- In a car, you can go pretty much where you want. In a helicopter, you can do whatever
- you want. Even if you still choose to travel in a straight line, just the knowledge that there
- is a wide expanse of possibilities is very powerful.
-
-7 - Dynamic campaigns tend to have a world that reacts more to what you and other
- vehicles do. Scripted campaigns tend to only care about what happens in the
- context of the mission design. (Example - In Team Apache, enemy helicopters
- and AAA are only located along the line created by your waypoints. Take the
- scenic route instead, and you can completely bypass the vast majority of threats.
- Worse yet, the helicopters in Team Apache can only operate in a little tiny area.
- They're nothing more than flying roadblocks. Even if I was spotted in another
- location, they couldn't be vectored in after me.) Now while there are exceptions,
- the fact is that such omissions would be *glaringly* obvious in dynamic campaigns
- where they may be more subtle in a scripted one. In other words, you can't fake things
- as much.
-
-
->4) A dynamic campaign is never going to generate a mission such as "shoot down
->Admiral Yamamoto in your P-38. "
-
-
-Why can't it generate such a mission? It really wouldn't be all that hard if you think
-about it. Games like Warlords have "heroes" that lead the armies as they move
-around the board. A WW2 dynamic campaign could fairly easily model the
-movement of such VIPs as they travel around to lead their forces. Some dynamic
-campaigns already model intelligence assets. Given that the computer is tracking
-the movement of VIPs and an intelligence asset is present in the area (in this case,
-in-theatre codebreakers and a transmission intercept, as I recall), a dynamic "kill VIP
-mission" to "shoot down Yamamoto in your P-38", "Go shoot Saddam's Winnebago"
-or "drop a bunker-buster on Saddam's HQ" is certainly possible. It only takes
-imagination, a little development time, and perhaps the development of a few tools
-to help make such things possible.
-
-> Don't scripted campaigns have the potential to
->be a lot more interesting?
-
-I don't believe so. The simplest way to put it is this - take the number of times
-you've finished a mission and said to yourself or a friend afterward "Wow! That
-was one hell of a mission!" For me, the number of times I had that feeling in
-a scripted campaign to the number of times I felt that in a dynamic campaign
-is not even remotely close. I'd honestly ballpark the frequency at an 8-to-1 ratio
-in favor of the dynamic campaign.
-
->(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
->what I think the perfect campaign for today's techology is in a future post.
->But I want to hear from some of the rest of you without "leading" into a
->discussion of my own theories. And let's not even open hte multiplayer can of
->worms. :-)
-
-
-Good idea. Let's focus on the campaign. : )
-
-Bottom line for me - If forced to choose, I'd still take a mediocre dynamic
-campaign over the best scripted campaign any day of the week.
-
-Neil M.
-
-
+From - Mon Nov 02 22:29:24 1998
+Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!cpk-news-hub1.bbnplanet.com!news.news.gtei.net!firehose.mindspring.com!not-for-mail
+From: dennya@mindspring.com (Denny Atkin)
+Newsgroups: comp.sys.ibm.pc.games.flight-sim
+Subject: Dynamic Campaigns: Discuss.
+Date: Tue, 03 Nov 1998 04:03:25 GMT
+Organization: Not officially representing CGW here in my free time
+Lines: 40
+Message-ID: <364067e5.15703318@news.mindspring.com>
+Reply-To: dennya@mindspring.com
+NNTP-Posting-Host: user-38ld6ro.dialup.mindspring.com
+Mime-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Transfer-Encoding: 7bit
+X-Server-Date: 3 Nov 1998 04:05:20 GMT
+X-Newsreader: Forte Agent 1.5/32.451
+X-No-Archive: yes
+Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154235
+
+Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
+going so far as to say they won't buy a sim that doesn't feature them.
+
+Here's the big question: Which sims are you holding up as examples of good
+dynamic campaigns? Because until VERY recently, there haven't been that many
+opportunities to experience a good dynamic campaign. Falcon 3.0's is often held
+up as the previous Holy Grail, but that's mostly people remembering things
+better than they were. Falcon 3.0 had a number of kludgy elements and faked
+occurrences in its campaign--such as the MiG-19s that often spontaneously
+spawned to harass you when you were landing. EF2000 had a fully dynamic
+campaign, but the mission structures were so repetitive that I bored of it as
+quickly as I did any "canned mission" sim. Longbow 2 had a good dynamic
+campaign, but the most interesting missions were the prescripted ones.
+
+So I pose these questions, just for discussion:
+1) What are the examples of good past dynamic campaigns? What made them good,
+and kept them from getting boring?
+
+2) If a mission featured a scripted campaign, but had features that kept it
+from being repetitive -- targets that stayed destroyed, enemy locations and
+force makeups that were randomly generated to keep them from being predictable,
+being retasked to destroy missed targets -- would that be an acceptable
+substitute?
+
+3) Is it replayability or the chance to affect the outcome of the war that
+makes dynamic campaigns appealing to you?
+
+4) A dynamic campaign is never going to generate a mission such as "shoot down
+Admiral Yamamoto in your P-38. " Don't scripted campaigns have the potential to
+be a lot more interesting?
+
+(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
+what I think the perfect campaign for today's techology is in a future post.
+But I want to hear from some of the rest of you without "leading" into a
+discussion of my own theories. And let's not even open hte multiplayer can of
+worms. :-)
+ ---------------------------------------------------
+ Denny Atkin / dennya@mindspring.com
+ I have not yet begun to procrastinate
+ ---------------------------------------------------
+From - Mon Nov 02 22:29:24 1998
+Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!ix.netcom.com!news
+From: "Greg Cisko" <gcisko@nOsPaMix.netcom.net>
+Newsgroups: comp.sys.ibm.pc.games.flight-sim
+Subject: Re: Dynamic Campaigns: Discuss.
+Date: Mon, 2 Nov 1998 22:19:54 -0600
+Organization: ICGNetcom
+Lines: 81
+Message-ID: <71m0g1$bim@sjx-ixn6.ix.netcom.com>
+References: <364067e5.15703318@news.mindspring.com>
+NNTP-Posting-Host: chf-il5-83.ix.netcom.com
+X-NETCOM-Date: Mon Nov 02 8:23:29 PM PST 1998
+X-Newsreader: Microsoft Outlook Express 4.72.3110.1
+X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
+Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154240
+
+Denny Atkin wrote in message <364067e5.15703318@news.mindspring.com>...
+>Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
+>going so far as to say they won't buy a sim that doesn't feature them.
+>
+>Here's the big question: Which sims are you holding up as examples of good
+>dynamic campaigns? Because until VERY recently, there haven't been that
+many
+
+
+In shirt I would almost have to say there are no good dynamic
+campaigns yet :-) I did hear the campaigns in iF22 were supposedly
+good. But the rest of the game was basicly crap so I wouldn't even
+give it a shot.
+
+>opportunities to experience a good dynamic campaign. Falcon 3.0's is often
+held
+>up as the previous Holy Grail, but that's mostly people remembering things
+>better than they were. Falcon 3.0 had a number of kludgy elements and faked
+
+
+Correct. I remember vividly the first mission if the Kurile(sp?) campaign
+was
+always the same mission. Not very dynamic imho. Also not very realistic
+to shoot 15 migs only to get wasted while I was on final approach. Like
+there wouldn't be any air defenses near an american base...
+
+>occurrences in its campaign--such as the MiG-19s that often spontaneously
+>spawned to harass you when you were landing. EF2000 had a fully dynamic
+>campaign, but the mission structures were so repetitive that I bored of it
+as
+>quickly as I did any "canned mission" sim. Longbow 2 had a good dynamic
+>campaign, but the most interesting missions were the prescripted ones.
+
+
+I guess you can't have your cake and eat it too :-)
+
+>2) If a mission featured a scripted campaign, but had features that kept it
+>from being repetitive -- targets that stayed destroyed, enemy locations and
+>force makeups that were randomly generated to keep them from being
+predictable,
+>being retasked to destroy missed targets -- would that be an acceptable
+>substitute?
+
+
+For me yes definately.
+
+>3) Is it replayability or the chance to affect the outcome of the war that
+>makes dynamic campaigns appealing to you?
+
+
+Replayability for me is not the issue. But rather a chance to effect the
+outcome.
+
+>4) A dynamic campaign is never going to generate a mission such as "shoot
+down
+>Admiral Yamamoto in your P-38. " Don't scripted campaigns have the
+potential to
+>be a lot more interesting?
+
+
+Yes. Until you run into one that you cannot beat. Which you always know
+a flight of migs will be at a certain place every time. Yada, yada yada :-)
+
+--
+Header address intentionally scrambled to ward off the spamming hordes.
+
+cisko [AT] ix [DOT] netcom [DOT] com
+
+>(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
+>what I think the perfect campaign for today's techology is in a future
+post.
+>But I want to hear from some of the rest of you without "leading" into a
+>discussion of my own theories. And let's not even open hte multiplayer can
+of
+>worms. :-)
+> ---------------------------------------------------
+> Denny Atkin / dennya@mindspring.com
+> I have not yet begun to procrastinate
+> ---------------------------------------------------
+
+
+From - Mon Nov 02 22:29:25 1998
+Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news.rdc1.bc.wave.home.com.POSTED!not-for-mail
+From: silenus@home.com (David Clark)
+Newsgroups: comp.sys.ibm.pc.games.flight-sim
+Subject: Re: Dynamic Campaigns: Discuss.
+Message-ID: <363e80ff.260853340@192.168.0.2>
+References: <364067e5.15703318@news.mindspring.com>
+X-Newsreader: Forte Free Agent 1.11/32.235
+Lines: 89
+Date: Tue, 03 Nov 1998 04:42:17 GMT
+NNTP-Posting-Host: 24.112.120.121
+NNTP-Posting-Date: Mon, 02 Nov 1998 20:42:17 PDT
+Organization: @Home Network Canada
+Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154251
+
+On Tue, 03 Nov 1998 04:03:25 GMT, dennya@mindspring.com (Denny Atkin)
+wrote:
+
+>Here's the big question: Which sims are you holding up as examples of good
+>dynamic campaigns?
+
+Umm... perhaps EF2000 and Longbow 2. The best "dynamic campaigns" that
+I've seen weren't Flight Sims at all - they were strategy games like
+X-Com and Jagged Alliance.
+
+>So I pose these questions, just for discussion:
+
+Good questions, well phrased.
+
+>1) What are the examples of good past dynamic campaigns? What made them good,
+>and kept them from getting boring?
+
+IMHO, the property that makes a dynamic campaign valuable is that the
+missions seem plausible, but unplanned. Modern warfare is
+extraordinarily fluid and chaotic, and set-piece battles are very
+rare. Battles should just sort of 'precipitate' out of the strategic
+situation - often large air battles are unplanned, and are simply the
+result of a few fighters running into one another - the furball grows
+as both sides dump in additional aircraft, while neither commander
+really understands the scale of the battle that is developing.
+
+The thing that made EF2000 so enjoyable was that most of the battles
+had a 'meeting engagement' feel to them - since there was no 'plot',
+my actions weren't constrained at all. I could avoid battles (if I was
+lucky), or search out more fights, depending on my understanding of
+the tactical situation.
+
+>2) If a mission featured a scripted campaign, but had features that kept it
+>from being repetitive -- targets that stayed destroyed, enemy locations and
+>force makeups that were randomly generated to keep them from being predictable,
+>being retasked to destroy missed targets -- would that be an acceptable
+>substitute?
+
+I guess so. My criteria is that the forces I face have a _reason_ for
+being there (even if the 'reason' is just random chance). If I feel
+like a scenario has been 'tweaked' for 'balance', my suspension of
+disbelief is gone. I want to fight the forces that would _probably be
+there_ in real life, not the ones that a scenario designer feels I can
+handle. I never minded being outnumbered in EF2000, since if I was, it
+was just my bad luck, not designer maliciousness.
+
+>3) Is it replayability or the chance to affect the outcome of the war that
+>makes dynamic campaigns appealing to you?
+
+The chance to affect the outcome of the war is not important to me at
+all. Most pilots won't affect the outcome of a war materially either
+- the reason I play flight sims is to role-play (however inaccurately)
+the experiences of someone with a much more interesting job than me -
+and the limits of individual power is part of that role.
+
+Of course, I also loved the occasional uneventful CAP mission in
+EF2000, so I guess I'm kind of peculiar.
+
+>4) A dynamic campaign is never going to generate a mission such as "shoot down
+>Admiral Yamamoto in your P-38. " Don't scripted campaigns have the potential to
+>be a lot more interesting?
+
+I suppose. I find the generated missions in EF2000 and Longbow2 to be
+extremely interesting - no two are the same, since the strategic
+situation, the position of the threat, etc are always different.
+Others disagree, and say that after a while, one dam-busting mission
+is pretty much like the next. I've never felt that way, but I can
+understand their position.
+
+>(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
+>what I think the perfect campaign for today's techology is in a future post.
+>But I want to hear from some of the rest of you without "leading" into a
+>discussion of my own theories. And let's not even open hte multiplayer can of
+>worms. :-)
+
+Without having seen the game, I guess Falcon4 offers the most
+promising type of dynamic campaign.
+
+What I really want to play is a highly detailed 'world simulator' in
+which both armies would carry out their war plans in real time. My
+aircraft would be one of the combatants, neither more or less
+influential than any other. In the end the victor would win because
+they _won_, not because I managed a 75% kill rate instead of a 65%...
+
+David Clark
+Third World War (GDW) website...
+http://members.home.net/silenus/tww/index.htm
+
+
+From - Mon Nov 02 22:29:25 1998
+Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.cwix.com!192.220.250.21!netnews1.nw.verio.net!netnews.nwnet.net!news.nodak.edu!not-for-mail
+From: "Michael J. Iverson" <micivers@badlands.nodak.edu>
+Newsgroups: comp.sys.ibm.pc.games.flight-sim
+Subject: Re: Dynamic Campaigns: Discuss.
+Date: Mon, 02 Nov 1998 22:48:53 -0600
+Organization: North Dakota Higher Ed. Network
+Lines: 62
+Message-ID: <363E8B35.64CBAFDD@badlands.nodak.edu>
+References: <364067e5.15703318@news.mindspring.com>
+NNTP-Posting-Host: und-as3p28.und.nodak.edu
+Mime-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Transfer-Encoding: 7bit
+X-Mailer: Mozilla 4.5 [en] (Win98; U)
+X-Accept-Language: en
+Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154263
+
+For me, a dynamic campaign should give me that "OK, time to go to work"
+feeling when I roll down the runway (or lift off from the FARP). It
+might not be the most challenging mission I've ever flown, but I know
+that I'm contributing towards the "war effort." I'd like to feel that
+the world is alive around me. One thing I didn't like in LB2 was that
+after a half hour or so, the "world" would just go to sleep - no more
+enemy CAPs or strike missions, no more enemy advances.
+
+Show me stats, supplies, squadron members, and info on my pilot. I
+think Red Baron II was one of the only sims that made me genuinely
+pissed off by having my pilot killed in action. I definitely wanted to
+stay alive in that sim.
+
+IMO, scripted missions have a tendency to be made a little too hard.
+Some game designers seem to think that impossible odds = fun. I
+disagree.
+
+Mike
+http://volunteers.warbirds.org
+
+From - Mon Nov 02 22:29:25 1998
+Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!newsfeed.direct.ca!cyclone.bc.net!logbridge.uoregon.edu!news.ycc.yale.edu!mars.its.yale.edu!rjl26
+From: rjl26@mars.its.yale.edu (Robin Lee)
+Newsgroups: comp.sys.ibm.pc.games.flight-sim
+Subject: Re: Dynamic Campaigns: Discuss.
+Date: 3 Nov 1998 05:14:22 GMT
+Organization: YLS
+Lines: 61
+Message-ID: <71m3fe$pk3$1@news.ycc.yale.edu>
+References: <364067e5.15703318@news.mindspring.com>
+NNTP-Posting-Host: mars.its.yale.edu
+Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154269
+
+In article <364067e5.15703318@news.mindspring.com>,
+Denny Atkin <dennya@mindspring.com> wrote:
+>
+>(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
+>what I think the perfect campaign for today's techology is in a future post.
+>But I want to hear from some of the rest of you without "leading" into a
+>discussion of my own theories. And let's not even open hte multiplayer can of
+>worms. :-)
+
+Just a few thoughts...
+
+1. For me, the "generic mission" problem is not a particularly
+troublesome issue because I find little appeal in the high dramatics of a
+"mission that won the war." Drama on that level does not take place very
+often in air warfare; by and large, an air campaign consists of a series
+of routinized mission profiles run on targets that aircrews know little
+about. Even for those rare missions that do wind up having a hugely
+significant impact on the war, aircrews are not likely to know about this
+until after the fact, though they may have some good guesses as to what
+they are doing (witness Smallwood's account of the anti-Saddam missions
+during Desert Storm, for instance). A so-called "routine" sortie provides
+more than enough drama for me -- "blow up the Death Star" missions have
+a little too much of Hollywood about them for my taste.
+
+2. Extension of the first point: for training, planning, and proficiency
+reasons, mission types are by nature generic. You want aircrews to be
+able to fit the mission into one of a fixed number of profiles for which
+they have been trained. Even where the mission is genuinely different,
+the operations structure of a modern air force is going to try to force
+the situation into familiar terms. Therefore, missions that "feel the
+same" may be realistic, and while some may argue that they become boring
+and therefore undesireable, I don't necessarily see them as such.
+
+3. An interesting mission does not have to be scripted; a relatively
+generic, template-based sortie can be turned into a genuinely memorable
+mission by the introduction of those random events that make tactical
+military aviation such a chaotic affair -- assigned tanker could go down,
+somebody crashes and fouls the runway, somebody goes down and you get
+called to CAP the survivors, etc. There is no particular reason that
+these events need to be scripted; their very randomness is what makes them
+exciting.
+
+4. As a general matter, I view mission generation and campaign dynamics
+in much the same light as I view sausage production; I don't really want
+to inquire too closely into the details of either. The illusion that I
+want to maintain is that the missions are generated by a real operations
+staff reacting to unpredictable events, not by a software campaign engine
+or by selection from a fixed database of mission scripts. And like
+sausages, the worst imaginable case is when the mission itself reveals
+obvious hints as to its origin. To me, a so-called "dynamic
+campaign" produces missions that simply *look* less contrived than
+"handpainted" missions, and therefore is a little better at maintaining
+the illusion.
+
+
+-R.
+--
+_____
+Robin John Lee <amraam@ix.netcom.com>
+YLS '99 - New Haven, Connecticut, USA
+Vulture's Row/Russian Navy - <http://www.webcom.com/amraam>
+From - Mon Nov 02 22:29:25 1998
+Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!news-peer.gip.net!news.gsl.net!gip.net!newsfeed.cwix.com!204.210.0.20!news.san.rr.com!not-for-mail
+From: "Jarrod Smith" <jsmith@scripps.edu>
+Newsgroups: comp.sys.ibm.pc.games.flight-sim
+References: <364067e5.15703318@news.mindspring.com>
+Subject: Re: Dynamic Campaigns: Discuss.
+Lines: 105
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset="iso-8859-1"
+Content-Transfer-Encoding: 7bit
+X-Newsreader: Microsoft Outlook Express 4.72.3155.0
+X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
+Message-ID: <2Rw%1.5101$q15.153954@news.san.rr.com>
+Date: Mon, 2 Nov 1998 21:50:44 -0800
+NNTP-Posting-Host: 204.210.61.137
+X-Trace: news.san.rr.com 910072254 204.210.61.137 (Mon, 02 Nov 1998 21:50:54 PDT)
+NNTP-Posting-Date: Mon, 02 Nov 1998 21:50:54 PDT
+Organization: TWC Road Runner, San Diego, CA
+Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154285
+
+
+Denny Atkin wrote in message <364067e5.15703318@news.mindspring.com>...
+>Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
+>going so far as to say they won't buy a sim that doesn't feature them.
+>
+>Here's the big question: Which sims are you holding up as examples of good
+>dynamic campaigns?
+
+For me, it is Longbow2 and Falcon 3.0. I had a hiatus from simming during
+my collegiate years (lack of hardware fundage :-), so I can't comment on
+anything in between.
+
+>
+>So I pose these questions, just for discussion:
+>1) What are the examples of good past dynamic campaigns? What made them
+good,
+>and kept them from getting boring?
+
+
+Essentially, I don't much care for branching type missions that make up a
+"campaign". It annoys me that the mission objectives will be the same each
+time you play through the campaign in one of the "winning branches". That
+detracts from replayability which is something I value very much in a sim.
+What keeps a dynamic campaign interesting for me:
+
+Each mission provides different objectives depending on the state of the
+total war (air and ground, supply lines, etc.). If your supply lines are
+out, you open them up. If you are losing ground, you cover the retreat. If
+you are taking ground, you take out critical elements of the enemy's
+defenses, and/or defend your ground assets as they move forward to capture
+territory. This type of ebb and flow can go on indefinitely until you make
+some decisive moves toward accomplishing your objective. This is limited by
+your performance both in the cockpit as well as inventory and personnel
+management, etc. This is what immerses me into a dynamic campaign. The
+individual missions are less important, and any good stout mission generator
+with subsequent mission editing options will fill the bill in that dept. I
+did like the splash of hollywood that was infused into LB2 by virtue of its
+scripted missions interspersed with the generated ones. You still can't
+argue with the entertainment value of a well-designed scripted mission. I
+guess for me, I seperate the mission from the campaign. I can enjoy flying
+a cool scripted mission. But it is different from fighting war from the
+campaign perspective. I guess I like the illusion of a strategic element
+that is infused into a good dynamic campaign engine.
+
+>2) If a mission featured a scripted campaign, but had features that kept it
+>from being repetitive -- targets that stayed destroyed, enemy locations and
+>force makeups that were randomly generated to keep them from being
+predictable,
+>being retasked to destroy missed targets -- would that be an acceptable
+>substitute?
+
+
+Much of what you said above would go a long way toward fixing some of the
+problems, but in the end, even though this is realistic and believable, it
+doesn't help the replayability aspect a whole lot. I'm not saying a sim
+like this wouldn't be fun, though. It certainly could be an acceptable
+substitute, but there would have to be some type of extraordinary
+multiplayer capability and/or mission builder to enhance the experience.
+Otherwise, it wouldn't last that long on my harddrive.
+
+>3) Is it replayability or the chance to affect the outcome of the war that
+>makes dynamic campaigns appealing to you?
+
+
+As outlined above, I think both are important to me. Also the illusion of
+strategy going on behind the scenes and you playing your part in that
+strategy makes a good dynamic campaign compelling to play.
+
+>4) A dynamic campaign is never going to generate a mission such as "shoot
+down
+>Admiral Yamamoto in your P-38. " Don't scripted campaigns have the
+potential to
+>be a lot more interesting?
+
+
+Scripted *missions* do have the potential to be more interesting. Scripted
+campaigns do not, IMO.
+
+>(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
+>what I think the perfect campaign for today's techology is in a future
+post.
+>But I want to hear from some of the rest of you without "leading" into a
+>discussion of my own theories. And let's not even open hte multiplayer can
+of
+>worms. :-)
+
+
+Here is what I think would be incredible in a "campaign engine". The engine
+calculates orders which get handed to you from on high. These orders state
+that you need to accomplish some objective to further the war effort. Say
+it is to reduce the opposition's EWR capabilities by some percentage, or
+reduce their naval capabilites in some capacity. Whatever. This becomes
+your short-term objective over the next handful of missions. The sim then
+hands you tools: Intelligence gathering tools, a sophisticated mission
+planner/builder, updated information on the assets that you have to complete
+the task, etc. Then you set out to work and build your own campaign, or at
+least part of it. Then jump in and fly whichever missions look to be the
+most fun to you. The combination of immersion, strategy, replayability, and
+challenge in a sim like this would make it irresistable, IMO.
+Unfortunately, it also sounds difficult and expensive to put together :-)
+
+Jarrod Smith
+The Scripps Research Institute
+http://www.scripps.edu/~jsmith
+
+From - Mon Nov 02 22:29:25 1998
+Path: news.rdc2.occa.home.com!newshub1.home.com!news.home.com!newsfeed.direct.ca!newspeer.monmouth.com!newsfeed-east.supernews.com!supernews.com!Supernews69!not-for-mail
+From: "enzo" <enzo@nospam.com>
+Newsgroups: comp.sys.ibm.pc.games.flight-sim
+Subject: Re: Dynamic Campaigns: Discuss.
+Date: Mon, 2 Nov 1998 22:07:25 -0800
+Organization: http://www.supernews.com, The World's Usenet: Discussions Start Here
+Lines: 186
+Message-ID: <71m6db$49n$1@supernews.com>
+References: <364067e5.15703318@news.mindspring.com>
+NNTP-Posting-Host: 207.211.61.222
+X-Trace: 910073067 WUENVH4GT3DDECFD3C usenet78.supernews.com
+X-Complaints-To: newsabuse@supernews.com
+X-Newsreader: Microsoft Outlook Express 4.72.3110.1
+X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
+Xref: newshub1.home.com comp.sys.ibm.pc.games.flight-sim:30154288
+
+Denny's starting a new thread! I'm getting verklempt! ; )
+
+Ok, I've gotta bite on this one - can't allow the possibility for a new
+pro-canned movement (or even a "maybe scripted isn't so bad"
+movement, for that matter either!) : )
+
+Disclaimers - this is all MHO. I ended up getting really wordy. My apologies,
+ but I wanted to write until I got it all off my chest.
+
+Denny Atkin wrote in message <364067e5.15703318@news.mindspring.com>...
+>Okay, there are a number of folks here who SWEAR by dynamic campaigns, some
+>going so far as to say they won't buy a sim that doesn't feature them.
+>
+>Here's the big question: Which sims are you holding up as examples of good
+>dynamic campaigns? Because until VERY recently, there haven't been that many
+>opportunities to experience a good dynamic campaign. Falcon 3.0's is often held
+>up as the previous Holy Grail, but that's mostly people remembering things
+>better than they were. Falcon 3.0 had a number of kludgy elements and faked
+>occurrences in its campaign--such as the MiG-19s that often spontaneously
+>spawned to harass you when you were landing. EF2000 had a fully dynamic
+>campaign, but the mission structures were so repetitive that I bored of it as
+>quickly as I did any "canned mission" sim. Longbow 2 had a good dynamic
+>campaign, but the most interesting missions were the prescripted ones.
+>
+>So I pose these questions, just for discussion:
+>1) What are the examples of good past dynamic campaigns? What made them good,
+>and kept them from getting boring?
+
+
+----Top examples were Falcon 3 and Longbow 2.
+
+ Both integrate air and ground
+combat well, give a certain degree of flexibility, and both calculate the
+progress of the war according to the ability of the ground forces to fight, not
+according to your mission score. Therefore, you can get killed in a mission, but
+still win a battle, because you managed to make a positive impact. You are a
+part of the picture - important, but you are *in* the world, not "the world revolves
+around you" - critical distinction to make.
+
+--------Good examples include iF/A-18E, TAW, and apparently Tornado (although I
+didn't get very far into Tornado's campaign, but for non-campaign related reasons)
+
+iF/A-18E is good, but TALON still needs more refinement before it will realize it's
+goals properly IMHO. Very important that friendly assets (eg friendly naval ships)
+will try to protect you/themselves with their SAM screens - opens up possibilities
+TAW took an interesting "multiple scoreboard" approach, but it seems to have taken
+a purely political aspect to the war rather than considering the ground war. That
+pays too much homage to the low-intensity conflicts IMHO. That prevents it from
+being ranked with Falcon 3/Longbow 2.
+
+(I could even sneak X-COM into the picture! : )
+
+----------Mediocre examples include RB2, EF2000, M1TP2
+
+RB2 - basically a random mission generator. M1TP2 - same thing.
+EF2000 - no ground war, your FEBA moves as a result not of
+the battle, not even of your accomplishments, but exclusively as a
+result of your mission score.
+
+---------Examples that deserve to be shot are iF-22 Raptor and Team Apache.
+
+iF-22 Raptor claimed dynamic and was scripted. Team Apache either
+also claimed it, or at least hinted strongly at it with it's real time clock
+(that ended up being utterly superfluous). JSF might belong here, too, but
+frankly I got sick of it way too fast to figure that out.
+
+>2) If a mission featured a scripted campaign, but had features that kept it
+>from being repetitive -- targets that stayed destroyed, enemy locations and
+>force makeups that were randomly generated to keep them from being predictable,
+>being retasked to destroy missed targets -- would that be an acceptable
+>substitute?
+
+
+You seem to be describing Janes F-15 for the most past. My answer is no.
+
+For starters, poor scripted missions are no better than random mission generators.
+Good scripted missions, no matter how you shake or stir it, end up where the
+player is always trying to second-guess the designer. Also, "randomizing" a
+scripted mission isn't a whole lot more fun than shaking up one of those
+glass paperweights with the fake snow inside. Sure, a few elements may
+shift around, but you're looking at the same scene no matter what. IMHO, even
+when dynamic campaign missions get somewhat repetitive, it still doesn't
+feel as rigidly constrained.
+
+>3) Is it replayability or the chance to affect the outcome of the war that
+>makes dynamic campaigns appealing to you?
+
+
+Both, but there is more to it than that.
+
+Several things (most have a little interrelation):
+
+1- Yes, replayability
+
+2- Not doing the same mission over again just because I failed it the first time
+
+3- Being able to play a part/have an affect in a simulated war, absolutely -
+ as long as the designers carefully balance my ability to affect that war so as not
+ to over or under value my contribution. If I find myself *caring* about the state
+ of the war when I'm driving to class, that's a good sign. That's never happened
+ to me in any game except those with dynamic campaigns.
+
+4- related to #3 - What you do, actually **matters**. There is a point to it
+ other than simply "jumping through hoops", then getting Pavlovian
+ reinforcement by little FMV treats. :^P Phooey! I want a sense of
+ accomplishment that's more profound than that.
+
+5A - Not second guessing the designer. You are focused on what needs to be
+ done, what you can do to help the war effort, not "Would the mission
+ designers really hide an ambush over there? Do they expect me to have to resort
+ to guns or try something else? Maybe I'm supposed to use a stealthy fighter?"
+
+5B - MISSIONS ARE NOT PUZZLES!!!
+ the worst examples - "Ok - let me get this straight - I have to first go to point A
+ and hit the tanks with the Mavericks, then I have only a few seconds left to
+ afterburn to point B and use the AMRAAMs on the Mig-21's to protect my
+ rescue helo from being shot down, then I have to go to point C and dogfight
+ with another group of MiGs before they bomb my airbase. Whew, that only
+ took eight failures to figure out!"
+
+6 - Unpredictability - I've repeatedly heard the claim that only a scripted mission can
+ really surprise a player. I disagree - There are many things that I have experienced
+ in dynamic campaigns that were surprising, entertaining, and all the more fun
+ because elements create situations that mission designers couldn't or wouldn't
+ have possibly dreamt up.
+
+ Ask me if I'd prefer to explore the state by train, car, or helicopter...
+ Sure, a train may go through some nice scenery, but really you're just along for the ride.
+ In a car, you can go pretty much where you want. In a helicopter, you can do whatever
+ you want. Even if you still choose to travel in a straight line, just the knowledge that there
+ is a wide expanse of possibilities is very powerful.
+
+7 - Dynamic campaigns tend to have a world that reacts more to what you and other
+ vehicles do. Scripted campaigns tend to only care about what happens in the
+ context of the mission design. (Example - In Team Apache, enemy helicopters
+ and AAA are only located along the line created by your waypoints. Take the
+ scenic route instead, and you can completely bypass the vast majority of threats.
+ Worse yet, the helicopters in Team Apache can only operate in a little tiny area.
+ They're nothing more than flying roadblocks. Even if I was spotted in another
+ location, they couldn't be vectored in after me.) Now while there are exceptions,
+ the fact is that such omissions would be *glaringly* obvious in dynamic campaigns
+ where they may be more subtle in a scripted one. In other words, you can't fake things
+ as much.
+
+
+>4) A dynamic campaign is never going to generate a mission such as "shoot down
+>Admiral Yamamoto in your P-38. "
+
+
+Why can't it generate such a mission? It really wouldn't be all that hard if you think
+about it. Games like Warlords have "heroes" that lead the armies as they move
+around the board. A WW2 dynamic campaign could fairly easily model the
+movement of such VIPs as they travel around to lead their forces. Some dynamic
+campaigns already model intelligence assets. Given that the computer is tracking
+the movement of VIPs and an intelligence asset is present in the area (in this case,
+in-theatre codebreakers and a transmission intercept, as I recall), a dynamic "kill VIP
+mission" to "shoot down Yamamoto in your P-38", "Go shoot Saddam's Winnebago"
+or "drop a bunker-buster on Saddam's HQ" is certainly possible. It only takes
+imagination, a little development time, and perhaps the development of a few tools
+to help make such things possible.
+
+> Don't scripted campaigns have the potential to
+>be a lot more interesting?
+
+I don't believe so. The simplest way to put it is this - take the number of times
+you've finished a mission and said to yourself or a friend afterward "Wow! That
+was one hell of a mission!" For me, the number of times I had that feeling in
+a scripted campaign to the number of times I felt that in a dynamic campaign
+is not even remotely close. I'd honestly ballpark the frequency at an 8-to-1 ratio
+in favor of the dynamic campaign.
+
+>(I'm not at all saying I'm not a fan of dynamic campaigns, and I'll outline
+>what I think the perfect campaign for today's techology is in a future post.
+>But I want to hear from some of the rest of you without "leading" into a
+>discussion of my own theories. And let's not even open hte multiplayer can of
+>worms. :-)
+
+
+Good idea. Let's focus on the campaign. : )
+
+Bottom line for me - If forced to choose, I'd still take a mediocre dynamic
+campaign over the best scripted campaign any day of the week.
+
+Neil M.
+
+
diff --git a/Doc/Engine.txt b/Doc/Engine.txt
index ce256fe..bc0e7e8 100644
--- a/Doc/Engine.txt
+++ b/Doc/Engine.txt
@@ -1,106 +1,106 @@
-Generic 3D Game Engine
-----------------------
-
-Game // the main loop
- <Specific Game>
-
-Video // abstract video interface
- VideoDirect // any old full screen direct draw
- VideoDirect3D // direct draw and direct 3d
- VideoWindow // WinG or DDraw in a window
-
-PolyRend // abstract polygon renderer
- PolyRendSW // software renderer
- PolyRendD3D // Direct 3D renderer
- PolyRend3Dfx // Glide renderer
-
-Screen // the whole screen, a collection of canvases
- FullScreen // a single screen, full screen or in a single window
- <Various Game Screens>
- MultiWinScreen // multiple windows, one canvas per window
-
-Window // rectangular region of screen, basic 2D graphics
- Canvas // window with View attached
- Form // a collection of controls
- Control // abstract dialog widgets
- Label // static text
- Edit // text input
- List // single or multi-select
- Button // various styles and states
- Slider // also a gauge
- Scrollbox // a scrolling window, user must subclass?
-
-WinEvent
-
-Cursor // mouse pointer
-
-View // what to draw in a canvas
- CameraView // handles projection and clipping of visible polys
- FormView
- <Various Game Dialogs>
- ImageView // displays a single bitmap
- FadeView // fades the whole display in/out
- MovieView // displays a movie or animation
- <Various Game Views>
-
-Camera // position and point of view
-CameraClipper // view pyramid clipping for a given camera
-
-Color // RGBA color (32-bit)
-ColorIndex // index into 256 color palette (8-bit)
-
-fix // fixed point math
-Rect
-Vector
-Point
-Plane
-Poly
-Matrix
-
-// These are private to a particular camera view
-// Texture, MipMap, Cache, etc.
-
-DataLoader
-Asset
- Palette (and inverse palette)
- Bitmap
- Model (3d)
- Sound
- Song (RedBook / MIDI ?)
- Movie
- Text
- Font
- ColorFont
-
-Physical // an entity in a 3d simulation that responds to physical
- // forces (velocity, acceleration, drag, thrust)
-
-Director // something that controls something else, once per frame
-
-Universe // a collection of physical models
- <Game universe>
-
-Graphic3D // a generic image in a 3d scene
- Solid3D // polygon model
- Sprite3D // textured billboard, with optional animation
- Blob3D // textured poly, oriented towards camera
- Composite3D // a graphic composed of other graphics (?)
-
-Light // a point light source
-
-Scene // collection of graphics and lights
-
-Sound // abstract sound (ambient or localized, memory or streamed)
- SoundD3D // concrete sound using DirectSound(3D)
-SoundCard // something that plays sounds
- SoundCardD3D // concrete sound card using DirectSound(3D)
-
-MotionController
- Keyboard
- Joystick
- Mouse
- ComboController
-ControllerInfo
-
-
-
+Generic 3D Game Engine
+----------------------
+
+Game // the main loop
+ <Specific Game>
+
+Video // abstract video interface
+ VideoDirect // any old full screen direct draw
+ VideoDirect3D // direct draw and direct 3d
+ VideoWindow // WinG or DDraw in a window
+
+PolyRend // abstract polygon renderer
+ PolyRendSW // software renderer
+ PolyRendD3D // Direct 3D renderer
+ PolyRend3Dfx // Glide renderer
+
+Screen // the whole screen, a collection of canvases
+ FullScreen // a single screen, full screen or in a single window
+ <Various Game Screens>
+ MultiWinScreen // multiple windows, one canvas per window
+
+Window // rectangular region of screen, basic 2D graphics
+ Canvas // window with View attached
+ Form // a collection of controls
+ Control // abstract dialog widgets
+ Label // static text
+ Edit // text input
+ List // single or multi-select
+ Button // various styles and states
+ Slider // also a gauge
+ Scrollbox // a scrolling window, user must subclass?
+
+WinEvent
+
+Cursor // mouse pointer
+
+View // what to draw in a canvas
+ CameraView // handles projection and clipping of visible polys
+ FormView
+ <Various Game Dialogs>
+ ImageView // displays a single bitmap
+ FadeView // fades the whole display in/out
+ MovieView // displays a movie or animation
+ <Various Game Views>
+
+Camera // position and point of view
+CameraClipper // view pyramid clipping for a given camera
+
+Color // RGBA color (32-bit)
+ColorIndex // index into 256 color palette (8-bit)
+
+fix // fixed point math
+Rect
+Vector
+Point
+Plane
+Poly
+Matrix
+
+// These are private to a particular camera view
+// Texture, MipMap, Cache, etc.
+
+DataLoader
+Asset
+ Palette (and inverse palette)
+ Bitmap
+ Model (3d)
+ Sound
+ Song (RedBook / MIDI ?)
+ Movie
+ Text
+ Font
+ ColorFont
+
+Physical // an entity in a 3d simulation that responds to physical
+ // forces (velocity, acceleration, drag, thrust)
+
+Director // something that controls something else, once per frame
+
+Universe // a collection of physical models
+ <Game universe>
+
+Graphic3D // a generic image in a 3d scene
+ Solid3D // polygon model
+ Sprite3D // textured billboard, with optional animation
+ Blob3D // textured poly, oriented towards camera
+ Composite3D // a graphic composed of other graphics (?)
+
+Light // a point light source
+
+Scene // collection of graphics and lights
+
+Sound // abstract sound (ambient or localized, memory or streamed)
+ SoundD3D // concrete sound using DirectSound(3D)
+SoundCard // something that plays sounds
+ SoundCardD3D // concrete sound card using DirectSound(3D)
+
+MotionController
+ Keyboard
+ Joystick
+ Mouse
+ ComboController
+ControllerInfo
+
+
+
diff --git a/Doc/Eschaton-Atmosphere.txt b/Doc/Eschaton-Atmosphere.txt
index 2a50e8a..d5f23c2 100644
--- a/Doc/Eschaton-Atmosphere.txt
+++ b/Doc/Eschaton-Atmosphere.txt
@@ -1,9 +1,9 @@
-Thanks. I'm currently working as a graphics programmer at Pandemic in LA, finishing Star Wars Battlefront 2. Its alright. I still ocassionally get the urge to finish cocommand, but its demands too much.
-
-The atmosphere shader is a somewhat straightforward optimization of a typical, if simplified, offline atmosphere model. The basic idea is to accumulate/integrate the in-scattering of light along a ray based on a density function which decreases exponentially with height above the sphere's surface. You integrate the density function along the ray which represents the total number of atmosphere particles hit along that ray. The in/out scattering (which I simplified to a single replacement % - an alpha value, really) are then determined from a simple exponential function of the accumulated density.
-
-The realtime aspect is that the ray integral density function is precomputed and fetched in a pixel shader with a texture lookup. This is straightforward because the model has just three basic scalar inputs - the ray's hit angle on the sphere, and the start and end intercepts along the ray (this model handles the cases where you are inside the atmosphere.) These setup parameters are calculated in the vertex shader.
-
-I later realized it could be further simplified to a 2D lookup. . .
-
+Thanks. I'm currently working as a graphics programmer at Pandemic in LA, finishing Star Wars Battlefront 2. Its alright. I still ocassionally get the urge to finish cocommand, but its demands too much.
+
+The atmosphere shader is a somewhat straightforward optimization of a typical, if simplified, offline atmosphere model. The basic idea is to accumulate/integrate the in-scattering of light along a ray based on a density function which decreases exponentially with height above the sphere's surface. You integrate the density function along the ray which represents the total number of atmosphere particles hit along that ray. The in/out scattering (which I simplified to a single replacement % - an alpha value, really) are then determined from a simple exponential function of the accumulated density.
+
+The realtime aspect is that the ray integral density function is precomputed and fetched in a pixel shader with a texture lookup. This is straightforward because the model has just three basic scalar inputs - the ray's hit angle on the sphere, and the start and end intercepts along the ray (this model handles the cases where you are inside the atmosphere.) These setup parameters are calculated in the vertex shader.
+
+I later realized it could be further simplified to a 2D lookup. . .
+
The atmosphere is rendered as the inner surface(reversed backface culling) of a sphere which surrounds the planet, and is necessarily somewhat larger than it. The shader is also rendered directly as a second pass on the planet geometry. The atmosphere sphere-shell is used for that sliver silhoutte of atmosphere overlapping empty space and for the atmosphere up close if you are near the planet surface. \ No newline at end of file
diff --git a/Doc/ExceptionHandler.cpp.txt b/Doc/ExceptionHandler.cpp.txt
deleted file mode 100644
index 4dd5938..0000000
--- a/Doc/ExceptionHandler.cpp.txt
+++ /dev/null
@@ -1,446 +0,0 @@
-
-/* ExceptionHandler.cpp */
-
-#include <windows.h>
-#include <imagehlp.h>
-
-extern void PrintLog(const char* fmt, ...);
-
-// +--------------------------------------------------------------------+
-
-class ExceptionHandler
-{
-public:
- ExceptionHandler();
- ~ExceptionHandler();
-
-private:
- static LPTOP_LEVEL_EXCEPTION_FILTER old_filter;
-
- static LONG WINAPI ExceptionFilter(EXCEPTION_POINTERS* info);
-
- static void PrintReport(EXCEPTION_POINTERS* info);
-
- // Helper functions
- static const char* GetExceptionString(DWORD dwCode);
- static BOOL GetLogicalAddress(VOID* addr, char* module, int len,
- DWORD& section, DWORD& offset);
-
- static BOOL InitImageHelp();
- static void ImageStackTrace(CONTEXT* context);
- static void IntelStackTrace(CONTEXT* context);
-
-
- // Make typedefs for some IMAGEHLP.DLL functions so that we can use them
- // with GetProcAddress
- typedef BOOL (__stdcall * SYMINITIALIZEPROC)(HANDLE, LPSTR, BOOL);
- typedef BOOL (__stdcall * SYMCLEANUPPROC)(HANDLE);
-
- typedef LPVOID (__stdcall *SYMFUNCTIONTABLEACCESSPROC)(HANDLE, DWORD);
- typedef DWORD (__stdcall *SYMGETMODULEBASEPROC)(HANDLE, DWORD);
- typedef BOOL (__stdcall *SYMGETSYMFROMADDRPROC)(HANDLE, DWORD, PDWORD, PIMAGEHLP_SYMBOL);
-
- typedef BOOL (__stdcall * STACKWALKPROC)(DWORD,
- HANDLE,
- HANDLE,
- LPSTACKFRAME,
- LPVOID,
- PREAD_PROCESS_MEMORY_ROUTINE,
- PFUNCTION_TABLE_ACCESS_ROUTINE,
- PGET_MODULE_BASE_ROUTINE,
- PTRANSLATE_ADDRESS_ROUTINE);
-
- static SYMINITIALIZEPROC SymInitialize;
- static SYMCLEANUPPROC SymCleanup;
- static STACKWALKPROC StackTrace;
- static SYMFUNCTIONTABLEACCESSPROC SymFunctionTableAccess;
- static SYMGETMODULEBASEPROC SymGetModuleBase;
- static SYMGETSYMFROMADDRPROC SymGetSymFromAddr;
-};
-
-// +--------------------------------------------------------------------+
-
-LPTOP_LEVEL_EXCEPTION_FILTER ExceptionHandler::old_filter = 0;
-
-ExceptionHandler::SYMINITIALIZEPROC ExceptionHandler::SymInitialize = 0;
-ExceptionHandler::SYMCLEANUPPROC ExceptionHandler::SymCleanup = 0;
-ExceptionHandler::STACKWALKPROC ExceptionHandler::StackTrace = 0;
-
-ExceptionHandler::SYMFUNCTIONTABLEACCESSPROC
- ExceptionHandler::SymFunctionTableAccess = 0;
-
-ExceptionHandler::SYMGETMODULEBASEPROC
- ExceptionHandler::SymGetModuleBase = 0;
-
-ExceptionHandler::SYMGETSYMFROMADDRPROC
- ExceptionHandler::SymGetSymFromAddr = 0;
-
-ExceptionHandler global_exception_handler;
-
-
-// +--------------------------------------------------------------------+
-
-ExceptionHandler::ExceptionHandler()
-{
- old_filter = SetUnhandledExceptionFilter(ExceptionFilter);
-}
-
-ExceptionHandler::~ExceptionHandler()
-{
- SetUnhandledExceptionFilter(old_filter);
-}
-
-// +--------------------------------------------------------------------+
-
-static bool in_filter = false;
-
-LONG WINAPI
-ExceptionHandler::ExceptionFilter(EXCEPTION_POINTERS* info)
-{
- if (in_filter) {
- PrintLog("\n\n*********************************************\n");
- PrintLog("SECOND EXCEPTION CAUGHT: TERMINATING.\n");
- PrintLog("*********************************************\n");
- }
-
- else {
- in_filter = true;
- PrintReport(info);
- in_filter = false;
- }
-
- if (old_filter)
- return old_filter(info);
- else
- return EXCEPTION_CONTINUE_SEARCH;
-}
-
-// +--------------------------------------------------------------------+
-
-void
-ExceptionHandler::PrintReport(EXCEPTION_POINTERS* info)
-{
- EXCEPTION_RECORD* record = info->ExceptionRecord;
- CONTEXT* context = info->ContextRecord;
- DWORD code = record->ExceptionCode;
-
- PrintLog("\n*********************************************\n");
- PrintLog("FATAL EXCEPTION:\n");
-
- PrintLog("\nRegisters:\n");
- PrintLog("EAX: %08x\n", context->Eax);
- PrintLog("EBX: %08x\n", context->Ebx);
- PrintLog("ECX: %08x\n", context->Ecx);
- PrintLog("EDX: %08x\n", context->Edx);
- PrintLog("EDI: %08x\n", context->Edi);
- PrintLog("ESI: %08x\n", context->Esi);
- PrintLog("EBP: %08x\n", context->Ebp);
- PrintLog("\n");
- PrintLog("CS:EIP: %04x:%08x\n", context->SegCs, context->Eip);
- PrintLog("SS:ESP: %04x:%08x\n", context->SegSs, context->Esp);
- PrintLog("DS: %04x\n", context->SegDs);
- PrintLog("ES: %04x\n", context->SegEs);
- PrintLog("FS: %04x\n", context->SegFs);
- PrintLog("GS: %04x\n", context->SegGs);
- PrintLog("Flags: %08x\n", context->EFlags );
- PrintLog("\n");
-
- PrintLog("Exception Code: %08x %s\n",code, GetExceptionString(code));
- PrintLog("Exception Addr: %08x \n", record->ExceptionAddress);
-
- if (code == EXCEPTION_ACCESS_VIOLATION && record->NumberParameters >= 2) {
- if (record->ExceptionInformation[0])
- PrintLog(" Program attempted to WRITE to address 0x%08x\n", record->ExceptionInformation[1]);
- else
- PrintLog(" Program attempted to READ from address 0x%08x\n", record->ExceptionInformation[1]);
- }
-
- if (InitImageHelp()) {
- ImageStackTrace(context);
- SymCleanup(GetCurrentProcess());
- }
- else {
- IntelStackTrace(context);
- }
-
- PrintLog("\n*********************************************\nPROGRAM TERMINATED.\n");
-}
-
-// +--------------------------------------------------------------------+
-
-const char*
-ExceptionHandler::GetExceptionString(DWORD code)
-{
- #define EXCEPTION( x ) case EXCEPTION_##x: return #x;
-
- switch (code) {
- EXCEPTION( ACCESS_VIOLATION )
- EXCEPTION( DATATYPE_MISALIGNMENT )
- EXCEPTION( BREAKPOINT )
- EXCEPTION( SINGLE_STEP )
- EXCEPTION( ARRAY_BOUNDS_EXCEEDED )
- EXCEPTION( FLT_DENORMAL_OPERAND )
- EXCEPTION( FLT_DIVIDE_BY_ZERO )
- EXCEPTION( FLT_INEXACT_RESULT )
- EXCEPTION( FLT_INVALID_OPERATION )
- EXCEPTION( FLT_OVERFLOW )
- EXCEPTION( FLT_STACK_CHECK )
- EXCEPTION( FLT_UNDERFLOW )
- EXCEPTION( INT_DIVIDE_BY_ZERO )
- EXCEPTION( INT_OVERFLOW )
- EXCEPTION( PRIV_INSTRUCTION )
- EXCEPTION( IN_PAGE_ERROR )
- EXCEPTION( ILLEGAL_INSTRUCTION )
- EXCEPTION( NONCONTINUABLE_EXCEPTION )
- EXCEPTION( STACK_OVERFLOW )
- EXCEPTION( INVALID_DISPOSITION )
- EXCEPTION( GUARD_PAGE )
- EXCEPTION( INVALID_HANDLE )
- }
-
- static char buffer[512] = { 0 };
-
- FormatMessage(FORMAT_MESSAGE_IGNORE_INSERTS | FORMAT_MESSAGE_FROM_HMODULE,
- GetModuleHandle("NTDLL.DLL"),
- code, 0, buffer, sizeof(buffer), 0 );
-
- return buffer;
-}
-
-// +--------------------------------------------------------------------+
-
-BOOL
-ExceptionHandler::GetLogicalAddress(void* addr, char* mod_name, int len, DWORD& section, DWORD& offset)
-{
- MEMORY_BASIC_INFORMATION mbi;
-
- if (!VirtualQuery(addr, &mbi, sizeof(mbi)))
- return FALSE;
-
- DWORD hMod = (DWORD)mbi.AllocationBase;
-
- if (!GetModuleFileName((HMODULE)hMod, mod_name, len))
- return FALSE;
-
- PIMAGE_DOS_HEADER pDosHdr = (PIMAGE_DOS_HEADER) hMod;
- PIMAGE_NT_HEADERS pNtHdr = (PIMAGE_NT_HEADERS)(hMod + pDosHdr->e_lfanew);
- PIMAGE_SECTION_HEADER pSection = IMAGE_FIRST_SECTION( pNtHdr );
-
- DWORD rva = (DWORD)addr - hMod; // RVA is offset from module load address
-
- // Iterate through the section table, looking for the one that encompasses
- // the linear address.
- for (unsigned i = 0; i < pNtHdr->FileHeader.NumberOfSections; i++, pSection++ ) {
- DWORD sectionStart = pSection->VirtualAddress;
- DWORD sectionEnd = sectionStart
- + max(pSection->SizeOfRawData, pSection->Misc.VirtualSize);
-
- // Is the address in this section???
- if ((rva >= sectionStart) && (rva <= sectionEnd)) {
- // Yes, address is in the section. Calculate section and offset,
- // and store in the "section" & "offset" params, which were
- // passed by reference.
- section = i+1;
- offset = rva - sectionStart;
- return TRUE;
- }
- }
-
- return FALSE; // Should never get here!
-}
-
-// +--------------------------------------------------------------------+
-
-void
-ExceptionHandler::IntelStackTrace(CONTEXT* context)
-{
- PrintLog("\nStack Trace (Intel):\n");
- PrintLog("Address Frame Logical addr Module\n");
-
- DWORD pc = context->Eip;
- DWORD* pFrame;
- DWORD* pPrevFrame;
-
- pFrame = (DWORD*)context->Ebp;
-
- do {
- char mod_name[256] = { 0 };
- DWORD section = 0, offset = 0;
-
- GetLogicalAddress((void*)pc, mod_name, 256, section, offset);
-
- PrintLog("%08X %08X %04X:%08X %s\n",
- pc, pFrame, section, offset, mod_name);
-
- pc = pFrame[1];
- pPrevFrame = pFrame;
- pFrame = (PDWORD)pFrame[0]; // proceed to next higher frame on stack
-
- if ((DWORD)pFrame & 3) // Frame pointer must be aligned on a
- break; // DWORD boundary. Bail if not so.
-
- if (pFrame <= pPrevFrame)
- break;
-
- // Can two DWORDs be read from the supposed frame address?
- if (IsBadWritePtr(pFrame, sizeof(PVOID)*2))
- break;
-
- }
- while ( 1 );
-}
-
-// +--------------------------------------------------------------------+
-
-void ExceptionHandler::ImageStackTrace(CONTEXT* context)
-{
- PrintLog("\nStack Trace (Symbolic):\n");
- PrintLog("Address Frame\n");
-
- // Could use SymSetOptions here to add the SYMOPT_DEFERRED_LOADS flag
- STACKFRAME sf;
- memset(&sf, 0, sizeof(sf));
-
- // Initialize the STACKFRAME structure for the first call. This is only
- // necessary for Intel CPUs, and isn't mentioned in the documentation.
- sf.AddrPC.Offset = context->Eip;
- sf.AddrPC.Mode = AddrModeFlat;
- sf.AddrStack.Offset = context->Esp;
- sf.AddrStack.Mode = AddrModeFlat;
- sf.AddrFrame.Offset = context->Ebp;
- sf.AddrFrame.Mode = AddrModeFlat;
-
- while ( 1 ) {
- if (!StackTrace( IMAGE_FILE_MACHINE_I386,
- GetCurrentProcess(),
- GetCurrentThread(),
- &sf,
- context,
- 0,
- SymFunctionTableAccess,
- SymGetModuleBase,
- 0))
- break;
-
- if (sf.AddrFrame.Offset == 0) // Basic sanity check to make sure
- break; // the frame is OK. Bail if not.
-
- PrintLog("%08x %08x ", sf.AddrPC.Offset, sf.AddrFrame.Offset);
-
- // IMAGEHLP is wacky, and requires you to pass in a pointer to an
- // IMAGEHLP_SYMBOL structure. The problem is that this structure is
- // variable length. That is, you determine how big the structure is
- // at runtime. This means that you can't use sizeof(struct).
- // So...make a buffer that's big enough, and make a pointer
- // to the buffer. We also need to initialize not one, but TWO
- // members of the structure before it can be used.
-
- BYTE symbolBuffer[sizeof(IMAGEHLP_SYMBOL) + 512];
- PIMAGEHLP_SYMBOL pSymbol = (PIMAGEHLP_SYMBOL)symbolBuffer;
- pSymbol->SizeOfStruct = sizeof(symbolBuffer);
- pSymbol->MaxNameLength = 512;
-
- DWORD symDisplacement = 0; // Displacement of the input address,
- // relative to the start of the symbol
-
- if (SymGetSymFromAddr(GetCurrentProcess(), sf.AddrPC.Offset,
- &symDisplacement, pSymbol)) {
- PrintLog("%-40s [%04X]\n", pSymbol->Name, symDisplacement);
- }
- else {
- char mod_name[256] = { 0 };
- DWORD section = 0, offset = 0;
-
- GetLogicalAddress((PVOID)sf.AddrPC.Offset,
- mod_name, 256, section, offset );
-
- PrintLog("%04X:%08X %s\n", section, offset, mod_name);
- }
- }
-}
-
-// +--------------------------------------------------------------------+
-
-BOOL
-ExceptionHandler::InitImageHelp()
-{
- PrintLog("\n");
-
- HMODULE h = LoadLibrary("IMAGEHLP.DLL");
- if (!h) {
- PrintLog("--- could not load IMAGEHLP.DLL ---\n");
- return FALSE;
- }
-
- SymInitialize = (SYMINITIALIZEPROC) GetProcAddress(h, "SymInitialize");
- if (!SymInitialize) {
- PrintLog("--- could not find SymInitialize ---\n");
- return FALSE;
- }
-
- SymCleanup = (SYMCLEANUPPROC) GetProcAddress(h, "SymCleanup");
- if (!SymCleanup) {
- PrintLog("--- could not find SymCleanup ---\n");
- return FALSE;
- }
-
- StackTrace = (STACKWALKPROC) GetProcAddress(h, "StackWalk");
- if (!StackTrace) {
- PrintLog("--- could not find StackWalk ---\n");
- return FALSE;
- }
-
- SymFunctionTableAccess = (SYMFUNCTIONTABLEACCESSPROC)
- GetProcAddress(h, "SymFunctionTableAccess");
-
- if (!SymFunctionTableAccess) {
- PrintLog("--- could not find SymFunctionTableAccess ---\n");
- return FALSE;
- }
-
- SymGetModuleBase = (SYMGETMODULEBASEPROC) GetProcAddress(h, "SymGetModuleBase");
- if (!SymGetModuleBase) {
- PrintLog("--- could not find SymGetModuleBase ---\n");
- return FALSE;
- }
-
- SymGetSymFromAddr = (SYMGETSYMFROMADDRPROC) GetProcAddress(h, "SymGetSymFromAddr");
- if (!SymGetSymFromAddr) {
- PrintLog("--- could not find SymGetSymFromAddr ---\n");
- return FALSE;
- }
-
- if (!SymInitialize(GetCurrentProcess(), 0, TRUE)) {
- PrintLog("--- could not Initialize IMAGEHLP.DLL ---\n");
-
- DWORD glerr = GetLastError();
-
- LPVOID lpMsgBuf;
- if (!FormatMessage(
- FORMAT_MESSAGE_ALLOCATE_BUFFER |
- FORMAT_MESSAGE_FROM_SYSTEM |
- FORMAT_MESSAGE_IGNORE_INSERTS,
- NULL,
- glerr,
- MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
- (LPTSTR) &lpMsgBuf,
- 0,
- NULL ))
- {
- PrintLog(" get last error: %08x\n", glerr);
- return FALSE;
- }
-
- // Display the string.
- PrintLog((LPCTSTR)lpMsgBuf);
- PrintLog("\n\n");
-
- // Free the buffer.
- LocalFree( lpMsgBuf );
- return FALSE;
- }
-
- PrintLog("Loaded IMAGEHLP.DLL\n");
- return TRUE;
-}
-
diff --git a/Doc/GAMEPLAY.TXT b/Doc/Gameplay.txt
index a3f123d..f8bb101 100644
--- a/Doc/GAMEPLAY.TXT
+++ b/Doc/Gameplay.txt
@@ -1,124 +1,124 @@
-STARSHATTER GAMEPLAY DESIGN
-
- Challenge Skill
- ------------- ----------------
- 1 Basic flight control the stick and throttle
-
- 2 Destroy a target coordinate flight to track the target
- use the gunsight to lead
- select an appropriate weapon
- fire upon the target
-
- 3 Avoid being destroyed recognize a threat
- perform evasive ACM
-
- 4 Avoid a rear attack recognize the threat warning
- perform reversal (split-s, loop, etc)
-
- 5 Avoid a collision recognize the impending collision
- steer away or slow down to miss
-
- 6 Maintain ship integrity recognize low shield status
- disengage and wait for shields to regenerate
- -or- seek a repair site or powerup
-
- 7 Locate a target interpret the scanner
- fly towards the target
-
- 8 Coordinate with a wingman avoid colliding
- avoid friendly fire
- coordinate target selection
- provide cover fire
-
-
-
-(--misc challenges--)
-
-deal with large numbers of enemy forces
-assess enemy capabilities
-attack and destroy large (cap) ships
-partial loss of control (e.g. loss of stabilizer or loss of yaw control)
-
-(--misc skills--)
-
-manage resources and health status
-prioritize objectives
-lock and fire a smart weapon
-avoid an incoming smart weapon
-assign a target or an objective to a wingman
-navigate with ultradrive
-effectively use tactical view
-seek cover behind a large ship/station
-seek re-supply
-
--------------------------
-avoid detection / detect an enemy
-
-This needs a little explanation. I hate cloaking systems.
-They are way too common (like everything else isn't?) and
-there is no skill to using them. Instead, we will use a
-system of reduced radiation signature reducing probability
-of detection (remember F-19 Stealth Fighter?)
-
-The ships will have an Emission Control mode switch. When
-in EmCon B mode, shields, weapons, target computer and IFF
-will be disabled. Long range sensors will be disabled, and
-the ship will need to rely on short range (passive) sensors
-alone. There will be a 3 to 5 second delay between commanding
-and completing an EmCon mode change.
-
-While running silent, the ship (and especially the drive
-flares will still be visible, but much harder to track or
-detect. Possibility of detection can be reduced further
-by reducing throttle or using a flare-less "stealth" drive.
-
-Short range (passive) sensors will be able to detect EmCon
-B targets up to a range of 30K, and EmCon A targets up to
-a range of 100K. Long range (active) sensors will be able
-to track all targets up to a range of 300K (maybe as high
-as 1M). [Actually, you probably want to make these prob-
-abilities of detection.]
-
-The flag ship serves as Wide Area Search And Track (WASAT)
-coordinator for the fleet. That is, all ships in the fleet
-will have access to the flag ship's target list. All ships
-will periodically send their own target list back to the
-flag ship for distribution to the fleet.
-
--------------------------
-prioritize ship sub-targets
-
-When dealing with larger ships, there is the problem of
-"what to shoot first?" Larger ships have multiple subsystems,
-each of which may be targetted separately. (Of course, you
-can always just shoot for the hull and try to blow up the
-whole ship -- however, this will not always be the wisest
-course of action.) What system to target depends on what
-actions you are trying to prevent:
-
-Weapons: destroy these to prevent the cap-ship from attacking
- another ship or space station. Doesn't prevent
- escape or fighter operation.
-
-Ultra: destroy this to keep the ship from leaving.
-
-Drive: destroy this to keep the ship from advancing and
- forming up. The ship can still turn and fire and
- still launch and recover fighters. Also prevents
- ultra navigation.
-
-Flt Dck: destroy this to keep the ship from launching or
- recovering (or resupplying) fighters.
-
-Systems: damage here has a random effect. May take out
- targetting, or navigation, or fighter ops. Wild
- Card.
-
-Vital: the whole works. If the ship gets hulled, it dies.
- This is most relevant for smaller ships. Big ships
- have *huge* integrity values, and require huge
- amounts of force to destroy.
-
-Each of these resources has a unique location on the ship.
-They are protected by whatever shield generator is protecting
-that part of the ship.
+STARSHATTER GAMEPLAY DESIGN
+
+ Challenge Skill
+ ------------- ----------------
+ 1 Basic flight control the stick and throttle
+
+ 2 Destroy a target coordinate flight to track the target
+ use the gunsight to lead
+ select an appropriate weapon
+ fire upon the target
+
+ 3 Avoid being destroyed recognize a threat
+ perform evasive ACM
+
+ 4 Avoid a rear attack recognize the threat warning
+ perform reversal (split-s, loop, etc)
+
+ 5 Avoid a collision recognize the impending collision
+ steer away or slow down to miss
+
+ 6 Maintain ship integrity recognize low shield status
+ disengage and wait for shields to regenerate
+ -or- seek a repair site or powerup
+
+ 7 Locate a target interpret the scanner
+ fly towards the target
+
+ 8 Coordinate with a wingman avoid colliding
+ avoid friendly fire
+ coordinate target selection
+ provide cover fire
+
+
+
+(--misc challenges--)
+
+deal with large numbers of enemy forces
+assess enemy capabilities
+attack and destroy large (cap) ships
+partial loss of control (e.g. loss of stabilizer or loss of yaw control)
+
+(--misc skills--)
+
+manage resources and health status
+prioritize objectives
+lock and fire a smart weapon
+avoid an incoming smart weapon
+assign a target or an objective to a wingman
+navigate with ultradrive
+effectively use tactical view
+seek cover behind a large ship/station
+seek re-supply
+
+-------------------------
+avoid detection / detect an enemy
+
+This needs a little explanation. I hate cloaking systems.
+They are way too common (like everything else isn't?) and
+there is no skill to using them. Instead, we will use a
+system of reduced radiation signature reducing probability
+of detection (remember F-19 Stealth Fighter?)
+
+The ships will have an Emission Control mode switch. When
+in EmCon B mode, shields, weapons, target computer and IFF
+will be disabled. Long range sensors will be disabled, and
+the ship will need to rely on short range (passive) sensors
+alone. There will be a 3 to 5 second delay between commanding
+and completing an EmCon mode change.
+
+While running silent, the ship (and especially the drive
+flares will still be visible, but much harder to track or
+detect. Possibility of detection can be reduced further
+by reducing throttle or using a flare-less "stealth" drive.
+
+Short range (passive) sensors will be able to detect EmCon
+B targets up to a range of 30K, and EmCon A targets up to
+a range of 100K. Long range (active) sensors will be able
+to track all targets up to a range of 300K (maybe as high
+as 1M). [Actually, you probably want to make these prob-
+abilities of detection.]
+
+The flag ship serves as Wide Area Search And Track (WASAT)
+coordinator for the fleet. That is, all ships in the fleet
+will have access to the flag ship's target list. All ships
+will periodically send their own target list back to the
+flag ship for distribution to the fleet.
+
+-------------------------
+prioritize ship sub-targets
+
+When dealing with larger ships, there is the problem of
+"what to shoot first?" Larger ships have multiple subsystems,
+each of which may be targetted separately. (Of course, you
+can always just shoot for the hull and try to blow up the
+whole ship -- however, this will not always be the wisest
+course of action.) What system to target depends on what
+actions you are trying to prevent:
+
+Weapons: destroy these to prevent the cap-ship from attacking
+ another ship or space station. Doesn't prevent
+ escape or fighter operation.
+
+Ultra: destroy this to keep the ship from leaving.
+
+Drive: destroy this to keep the ship from advancing and
+ forming up. The ship can still turn and fire and
+ still launch and recover fighters. Also prevents
+ ultra navigation.
+
+Flt Dck: destroy this to keep the ship from launching or
+ recovering (or resupplying) fighters.
+
+Systems: damage here has a random effect. May take out
+ targetting, or navigation, or fighter ops. Wild
+ Card.
+
+Vital: the whole works. If the ship gets hulled, it dies.
+ This is most relevant for smaller ships. Big ships
+ have *huge* integrity values, and require huge
+ amounts of force to destroy.
+
+Each of these resources has a unique location on the ship.
+They are protected by whatever shield generator is protecting
+that part of the ship.
diff --git a/Doc/landscape.txt b/Doc/Landscape.txt
index 079a1fc..cfc9a85 100644
--- a/Doc/landscape.txt
+++ b/Doc/Landscape.txt
@@ -1,88 +1,88 @@
-Subject: Re: Landscape Eng
-From: "Ville Miettinen" <wili@surrender3d.com>
-Date: 1997/05/09
-Message-Id: <5kto6g$2tu$1@news.clinet.fi>
-References: <33704A59.50AB@csc.liv.ac.uk> <3371D8DE.7B8E@funcom.ie>
-X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0
-Organization: Hybrid Holding-HH Ltd.
-Newsgroups: rec.games.programmer
-[Fewer Headers]
-
-After checking out the article in Edge magazine we implemented a similar
-landscape on a PC system for mainly experimental reasons. The main point
-here was not trying to solve the problem of showing enormous
- amounts of high-detail data with less polygons, but rather adding extra
-detail to closer areas. I.e. your database consists of the 'lowest level'
-presentation of an area and if we want more precision, we can calculate it
-from the low level presentation.
-
-I used a spline heightfield where the "low level" presentation defined the
-control points. Fractal noise was then added (easiest way is to use a
-simple LUT) to produce more variance. The whole world is divided into a set
-of large grids. For each visible grid (clip the world to the view frustrum)
-we allocate
-a LOD (level of detail) value which determines how many times the grid will
-be subdivided. The LOD is calculated by a variety of factors including the
-grid bounding box projected height, z-distance etc. When subdividing the
-grid we calculate new vertex height coordinates by using the spline
-functions and fractal noise as stated before. Special care must be taken so
-that shared edges (I used a vertex cache system which finds common vertices
-between polygons) are set properly; otherwise you'll end up
-with gaps in the landscape when a lower LOD grid meets a higher LOD grid.
-
-With an octree (or quadtree for single-level heightfields) presentation, we
-can easily store higher
-resolution info for 'important areas' of the landscape. Also, using an
-efficient hidden surface removal system in as early phase as possible is
-important; otherwise you'll have a hard time rendering
-all the covered grids. A scanline-buffering (or CSG) coverage determination
-for octree branches works
-well and kills quickly most of the hidden areas.
-
-This was all simple. However the texturing proved quite a bit trickier.
-Apparently the Innerloop people hadn't solved the problem; I haven't seen
-the engine running, but all of the shots displayed landscapes with a single
-texture map wrapped over the whole world. In one of the pictures I think
-there was another texture as well, but there weren't any shots of
-individually textured polygons or grids.
-
-As our landscape engine was using individual texture maps for all 'large
-grids' (each texture map being real-time RGB alpha-blended from
-neighbouring textures), I made the grid subdivision to subdivide each grid
-into 4 parts and created four new textures for them. Each new texture was a
-corner of the old texture, bilinearly interpolated to same size, after
-which a microtexture ('detail texture') was added on top of it. This method
-brings in loads of extra detail (although random fractal detail) however
-close you zoom.
-
-cheers,
--wili
-
---
-Ville Miettinen
-3D Programmer, Hybrid Holding Ltd.
-http://hybrid.org/surrender (SurRender home page)
-http://hybrid.org/wtga (free quantization tools)
- Ivar Just Olsen wrote in article <3371D8DE.7B8E@funcom.ie>...
->N.R. Matthews wrote:
->>
->> Hi I'm trying to write a fast lasdscape engine, recenly I read an
->> article in the Edge magazine and came across a group called Innerloop
->> who had got a pretty amazing engine out. Now apparently this works of
->> something called IFS (Iterated Function Systems) a mathematical term
-for
->> a special type of fractals. Does anyone have any idea how you could use
->> a fractal to efficiently render an entire landscape. On a undulating or
->> "bumpy" landscape most of the landscape is hidden, depending on the
->> bumpiness perhaps 90% hidden.
->>
->> Any ideas appeciated NatMat
->
->I know these guys, and I know how it's done. But the method is
->copyrighted, so I can't tell. Sorry.
->
->Hint: Clever use of subdivision (and have a look at NURBS while thinking
->;-)
->
->--
+Subject: Re: Landscape Eng
+From: "Ville Miettinen" <wili@surrender3d.com>
+Date: 1997/05/09
+Message-Id: <5kto6g$2tu$1@news.clinet.fi>
+References: <33704A59.50AB@csc.liv.ac.uk> <3371D8DE.7B8E@funcom.ie>
+X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0
+Organization: Hybrid Holding-HH Ltd.
+Newsgroups: rec.games.programmer
+[Fewer Headers]
+
+After checking out the article in Edge magazine we implemented a similar
+landscape on a PC system for mainly experimental reasons. The main point
+here was not trying to solve the problem of showing enormous
+ amounts of high-detail data with less polygons, but rather adding extra
+detail to closer areas. I.e. your database consists of the 'lowest level'
+presentation of an area and if we want more precision, we can calculate it
+from the low level presentation.
+
+I used a spline heightfield where the "low level" presentation defined the
+control points. Fractal noise was then added (easiest way is to use a
+simple LUT) to produce more variance. The whole world is divided into a set
+of large grids. For each visible grid (clip the world to the view frustrum)
+we allocate
+a LOD (level of detail) value which determines how many times the grid will
+be subdivided. The LOD is calculated by a variety of factors including the
+grid bounding box projected height, z-distance etc. When subdividing the
+grid we calculate new vertex height coordinates by using the spline
+functions and fractal noise as stated before. Special care must be taken so
+that shared edges (I used a vertex cache system which finds common vertices
+between polygons) are set properly; otherwise you'll end up
+with gaps in the landscape when a lower LOD grid meets a higher LOD grid.
+
+With an octree (or quadtree for single-level heightfields) presentation, we
+can easily store higher
+resolution info for 'important areas' of the landscape. Also, using an
+efficient hidden surface removal system in as early phase as possible is
+important; otherwise you'll have a hard time rendering
+all the covered grids. A scanline-buffering (or CSG) coverage determination
+for octree branches works
+well and kills quickly most of the hidden areas.
+
+This was all simple. However the texturing proved quite a bit trickier.
+Apparently the Innerloop people hadn't solved the problem; I haven't seen
+the engine running, but all of the shots displayed landscapes with a single
+texture map wrapped over the whole world. In one of the pictures I think
+there was another texture as well, but there weren't any shots of
+individually textured polygons or grids.
+
+As our landscape engine was using individual texture maps for all 'large
+grids' (each texture map being real-time RGB alpha-blended from
+neighbouring textures), I made the grid subdivision to subdivide each grid
+into 4 parts and created four new textures for them. Each new texture was a
+corner of the old texture, bilinearly interpolated to same size, after
+which a microtexture ('detail texture') was added on top of it. This method
+brings in loads of extra detail (although random fractal detail) however
+close you zoom.
+
+cheers,
+-wili
+
+--
+Ville Miettinen
+3D Programmer, Hybrid Holding Ltd.
+http://hybrid.org/surrender (SurRender home page)
+http://hybrid.org/wtga (free quantization tools)
+ Ivar Just Olsen wrote in article <3371D8DE.7B8E@funcom.ie>...
+>N.R. Matthews wrote:
+>>
+>> Hi I'm trying to write a fast lasdscape engine, recenly I read an
+>> article in the Edge magazine and came across a group called Innerloop
+>> who had got a pretty amazing engine out. Now apparently this works of
+>> something called IFS (Iterated Function Systems) a mathematical term
+for
+>> a special type of fractals. Does anyone have any idea how you could use
+>> a fractal to efficiently render an entire landscape. On a undulating or
+>> "bumpy" landscape most of the landscape is hidden, depending on the
+>> bumpiness perhaps 90% hidden.
+>>
+>> Any ideas appeciated NatMat
+>
+>I know these guys, and I know how it's done. But the method is
+>copyrighted, so I can't tell. Sorry.
+>
+>Hint: Clever use of subdivision (and have a look at NURBS while thinking
+>;-)
+>
+>--
>Ivar, just another Funcom programmer. \ No newline at end of file
diff --git a/Doc/NEARMAP.TXT b/Doc/Nearmap.txt
index 1aa4585..83a2c06 100644
--- a/Doc/NEARMAP.TXT
+++ b/Doc/Nearmap.txt
@@ -1,117 +1,117 @@
-Stars farther than 0.00pc and closer than 7.00pc,
-Lum between 0.0 and 100.0
-Gliese StarName Spec DistPC X Y Z Xg Yg Zg Lum
- 1 DM-37 15492 M4V 4.44 3.52, 0.04, -2.71| 1.04, -0.30, -4.31 0.01
- 15A DM+43 44 M1Ve 3.55 2.56, 0.17, 2.45| -1.51, 3.01, -1.12 0.01
- 15B M6Ve 3.55 2.56, 0.17, 2.45| -1.51, 3.01, -1.12 0.00
- 19 BET HYI G1IV 6.29 1.35, 0.14, -6.14| 2.76, -3.97, -4.02 2.75
- 33 DM+04 123 K2V 6.94 6.78, 1.37, 0.61| -1.95, 3.18, -5.86 0.22
- 34A ETA CAS G0V 5.88 3.09, 0.63, 4.96| -3.16, 4.94, -0.52 1.32
- 34B M0V 5.88 3.09, 0.63, 4.96| -3.16, 4.94, -0.52 0.03
- 35 VAN MAANEN 2 G wD 4.18 4.08, 0.84, 0.38| -1.19, 1.91, -3.53 0.00
- 54.1 L 725-32 M5de 6.90 6.28, 1.99, -2.05| -1.17, 0.67, -6.76 0.00
- 65A L 726-8 M5de 2.72 2.36, 1.06, -0.85| -0.67, 0.05, -2.64 0.00
- 65B UV CET M5de 2.72 2.36, 1.06, -0.85| -0.67, 0.05, -2.64 0.00
- 66A P ERI K2V 6.54 3.29, 1.50, -5.45| 1.11, -3.11, -5.64 0.20
- 66B DM-56 328 K5Ve 6.54 3.29, 1.50, -5.45| 1.11, -3.11, -5.64 0.17
- 71 TAU CET G8Vp 3.61 3.13, 1.49, -1.01| -1.02, 0.12, -3.46 0.47
- 83.1 L 1159-16 M8de 4.69 3.99, 2.24, 1.04| -2.73, 1.73, -3.40 0.00
-139 82 ERI G5V 6.21 2.94, 3.44, -4.26| -1.14, -3.27, -5.16 0.70
-144 EPS ERI K2Ve 3.31 1.98, 2.59, -0.55| -2.13, -0.60, -2.46 0.32
-166A OMI(2) ERI K1Ve 4.88 2.18, 4.32, -0.66| -3.60, -1.36, -3.00 0.37
-166B DM-07 781 A wD 4.88 2.17, 4.32, -0.66| -3.60, -1.36, -3.00 0.00
-166C M4de 4.88 2.17, 4.32, -0.66| -3.60, -1.36, -3.00 0.00
-169.1A AC+58 25001 M4d 5.21 1.06, 2.47, 4.46| -4.38, 2.73, 0.66 0.00
-169.1B AC+58 25002 C wD 5.21 1.06, 2.47, 4.46| -4.38, 2.73, 0.66 0.00
-191 DM-45 1841 M0V 3.91 0.60, 2.70, -2.76| -1.06, -2.97, -2.30 0.00
-205 DM-03 1123 M1Ve 5.88 0.79, 5.82, -0.38| -4.95, -2.51, -1.96 0.02
-213 AC+12 1800-2 M5d 5.95 0.53, 5.79, 1.29| -5.71, -1.39, -0.95 0.00
-223.2 LP 658-2 K wDe 6.02 0.19, 6.01, -0.44| -5.04, -2.93, -1.50 0.00
-229 DM-21 1377 M1Ve 5.75 -0.20, 5.33, -2.14| -3.61, -4.09, -1.82 0.02
-234A ROSS 614 M7de 3.97 -0.46, 3.94, -0.19| -3.31, -2.14, -0.43 0.00
-234B 3.97 -0.46, 3.94, -0.19| -3.31, -2.14, -0.43 91.20
-244A ALF CMA A1V 2.65 -0.47, 2.50, -0.76| -1.78, -1.92, -0.41 24.66
-244B A wD 2.65 -0.47, 2.50, -0.76| -1.78, -1.92, -0.41 0.00
-251 AC+33 25644 M4d 5.95 -1.11, 4.85, 3.27| -5.74, -0.29, 1.56 0.00
-268 AC+38 23616 M5de 5.92 -1.33, 4.43, 3.69| -5.56, 0.10, 2.02 0.00
-273 DM+05 1668 M5d 3.70 -1.33, 3.44, 0.35| -3.08, -1.95, 0.67 0.00
-280A ALF CMI F5IV+ 3.51 -1.43, 3.19, 0.33| -2.84, -1.90, 0.79 8.02
-280B F wD 3.51 -1.43, 3.19, 0.33| -2.84, -1.90, 0.79 0.00
-285 YZ CMI M4de 6.06 -2.61, 5.46, 0.39| -4.78, -3.45, 1.41 0.00
-293 L 97-12 C wD 5.78 -1.04, 1.94, -5.35| 0.97, -5.37, -1.92 0.00
-299 ROSS 619 M5d 6.62 -3.49, 5.53, 1.04| -5.09, -3.44, 2.47 0.00
-300 L 674-15 M 5.85 -2.94, 4.59, -2.13| -2.77, -5.10, 0.70 0.00
-338A DM+53 1320 M0Ve 6.02 -2.69, 2.44, 4.80| -4.27, 1.15, 4.08 0.03
-338B DM+53 1321 M0Ve 6.02 -2.69, 2.44, 4.80| -4.27, 1.15, 4.08 0.03
-380 DM+50 1725 K7Ve 4.50 -2.57, 1.36, 3.44| -2.68, 0.68, 3.56 0.04
-388 DM+20 2465 M4Ve 4.90 -4.14, 2.00, 1.69| -2.28, -1.69, 4.00 0.00
-406 WOLF 359 M8de 2.35 -2.23, 0.66, 0.30| -0.57, -1.17, 1.95 0.00
-408 AC+23 468-46 M3d 6.62 -5.87, 1.64, 2.60| -2.30, -1.70, 5.98 0.00
-411 DM+36 2147 M2Ve 2.52 -1.96, 0.52, 1.49| -1.04, -0.09, 2.29 0.01
-412A DM+44 2051 M2Ve 5.38 -3.76, 0.96, 3.72| -2.38, 0.49, 4.80 0.01
-412B WX UMA M8de 5.38 -3.76, 0.95, 3.72| -2.38, 0.49, 4.80 0.00
-440 L 145-141 C wD 4.85 -2.08, 0.15, -4.38| 2.12, -4.36, -0.24 0.00
-445 AC+79 3888 M4sd 5.10 -0.97, 0.07, 5.01| -2.41, 3.22, 3.14 0.00
-447 ROSS 128 M5d 3.32 -3.31, 0.22, 0.06| 0.00, -1.68, 2.86 0.00
-473A WOLF 424 M5de 4.33 -4.23, -0.57, 0.70| 0.45, -1.31, 4.10 0.00
-473B 4.33 -4.23, -0.57, 0.70| 0.45, -1.31, 4.10 0.00
-477.1 DM+46 1797 K4V 6.10 -4.19, -0.62, 4.39| -1.30, 1.48, 5.77 0.05
-526 DM+15 2620 M4Ve 4.98 -4.32, -2.09, 1.30| 1.49, -0.22, 4.74 0.01
-551 PROXIMA CEN M5de 1.31 -0.49, -0.36, -1.17| 0.91, -0.94, -0.04 0.00
-555 DM-11 3759 M4d 6.25 -4.82, -3.75, -1.33| 4.24, -1.68, 4.27 0.00
-559A ALF CEN G2V 1.35 -0.51, -0.42, -1.17| 0.96, -0.94, -0.02 1.66
-559B K0V 1.35 -0.51, -0.42, -1.17| 0.96, -0.94, -0.02 0.48
-566A XI BOO G8Ve 6.76 -4.72, -4.29, 2.23| 2.98, 1.27, 5.93 0.56
-566B K4Ve 6.76 -4.72, -4.29, 2.23| 2.98, 1.27, 5.93 0.08
-570A DM-20 4125 K5Ve 5.56 -3.75, -3.57, -2.01| 4.34, -1.73, 3.00 0.14
-570B DM-20 4123 M2V 5.56 -3.75, -3.57, -2.01| 4.34, -1.73, 3.00 0.02
-581 DM-07 4003 M5d 6.54 -4.23, -4.91, -0.86| 4.98, -0.51, 4.20 0.00
-588 DM-40 9712 M4 5.92 -2.73, -3.53, -3.89| 5.14, -2.65, 1.24 0.00
-628 DM-12 4523 M5d 4.02 -1.54, -3.61, -0.87| 3.67, 0.22, 1.61 0.00
-643 WOLF 629 M4sd 6.21 -1.78, -5.88, -0.89| 5.68, 1.11, 2.24 0.00
-644A DM-08 4352 M4de 6.21 -1.78, -5.88, -0.89| 5.69, 1.11, 2.24 0.00
-644B M4d 6.21 -1.78, -5.88, -0.89| 5.69, 1.11, 2.24 0.00
-644C VB 8 6.21 -1.77, -5.88, -0.90| 5.69, 1.11, 2.23 0.00
-661A DM+45 2505 M3d 6.45 -0.96, -4.40, 4.62| 1.67, 4.95, 3.79 0.00
-661B M3 6.45 -0.96, -4.40, 4.62| 1.67, 4.95, 3.79 0.00
-663A DM-26 12026 K1Ve 5.43 -1.01, -4.76, -2.43| 5.39, -0.16, 0.65 0.26
-663B K1Ve 5.43 -1.01, -4.76, -2.43| 5.39, -0.16, 0.65 0.25
-664 DM-26 12036 K5Ve 5.43 -0.99, -4.76, -2.42| 5.39, -0.15, 0.64 0.08
-674 DM-46 11540 M4 4.63 -0.48, -3.13, -3.38| 4.40, -1.34, -0.55 0.00
-682 DM-44 11909 M5 4.69 -0.39, -3.34, -3.28| 4.52, -1.13, -0.54 0.00
-687 DM+68 946 M3V 4.69 -0.18, -1.72, 4.36| -0.60, 3.94, 2.49 0.00
-693 L 205-128 M 5.88 -0.24, -3.17, -4.95| 5.18, -2.38, -1.47 0.00
-699 BARNARD'S ST M5V 1.81 -0.04, -1.81, 0.14| 1.51, 0.90, 0.44 0.00
-702A DM+02 3482 K0Ve 5.13 0.07, -5.12, 0.22| 4.36, 2.51, 1.01 0.49
-702B K5Ve 5.13 0.07, -5.12, 0.22| 4.36, 2.51, 1.01 0.10
-725A DM+59 1915 M4d 3.55 0.33, -1.77, 3.06| 0.04, 3.23, 1.45 0.00
-725B M5d 3.55 0.33, -1.77, 3.06| 0.04, 3.23, 1.45 0.00
-729 AC-24 2833-1 M4de 2.90 0.54, -2.60, -1.17| 2.80, 0.56, -0.52 0.00
-752A DM+04 4048 M3Ve 5.78 1.84, -5.46, 0.51| 4.39, 3.75, -0.33 0.01
-752B VB 10 M5de 5.78 1.84, -5.46, 0.51| 4.39, 3.74, -0.33 0.00
-754 L 347-14 M7 5.71 1.32, -3.77, -4.08| 5.18, -0.69, -2.31 0.00
-764 SIG DRA K0V 5.68 0.78, -1.82, 5.32| -1.04, 5.17, 2.12 0.39
-768 ALF AQL A7IV 5.05 2.27, -4.44, 0.77| 3.36, 3.69, -0.78 11.59
-780 DEL PAV G8V 5.71 1.18, -1.97, -5.23| 4.17, -2.43, -3.06 1.14
-783A DM-36 13940 K3V 5.65 2.41, -3.87, -3.34| 4.83, 0.44, -2.90 0.22
-783B M5d 5.65 2.41, -3.87, -3.34| 4.83, 0.44, -2.90 0.00
-784 DM-45 13677 M0V 6.10 2.31, -3.61, -4.34| 5.09, -0.46, -3.32 0.02
-820A 61 CYG K5Ve 3.38 1.91, -1.83, 2.10| 0.45, 3.33, -0.34 0.08
-820B K7Ve 3.38 1.91, -1.83, 2.10| 0.45, 3.33, -0.34 0.04
-825 DM-39 14192 M0Ve 3.85 2.24, -1.98, -2.42| 2.75, 0.19, -2.69 0.03
-829 AC+17 534-10 M4de 6.54 4.90, -3.86, 1.96| 2.09, 5.61, -2.62 0.00
-832 DM-49 13515 M1V 4.67 2.42, -1.86, -3.54| 3.17, -0.60, -3.38 0.01
-845 EPS IND K5Ve 3.44 1.62, -0.94, -2.88| 2.10, -0.92, -2.55 0.14
-860A DM+56 2783 M3d 3.95 1.95, -0.85, 3.33| -1.00, 3.82, -0.00 0.00
-860B DO CEP M4de 3.95 1.95, -0.85, 3.33| -1.00, 3.82, -0.00 0.00
-866 L 789-6 M7de 3.28 2.95, -1.13, -0.88| 1.22, 1.31, -2.75 0.00
-873 DM+43 4305 M4de 5.13 3.49, -1.19, 3.57| -0.92, 4.91, -1.16 0.00
-876 DM-15 6290 M5d 4.78 4.42, -1.38, -1.20| 1.49, 1.91, -4.13 0.00
-880 DM+15 4733 M2de 6.85 6.30, -1.86, 1.92| 0.27, 5.38, -4.24 0.01
-881 ALF PSA A3V 6.71 5.59, -1.63, -3.34| 2.66, 1.00, -6.08 14.06
-887 DM-36 15693 M2Ve 3.58 2.80, -0.72, -2.11| 1.46, 0.13, -3.27 0.01
-892 DM+56 2966 K3V 6.80 3.63, -0.79, 5.70| -2.31, 6.39, -0.38 0.25
-896A DM+19 5116 M4de 6.45 6.02, -0.81, 2.17| -0.75, 4.95, -4.07 0.00
-896B M6de 6.45 6.02, -0.81, 2.17| -0.75, 4.95, -4.07 0.00
-905 ROSS 248 M6de 3.14 2.26, -0.20, 2.18| -1.03, 2.83, -0.92 0.00
-908 DM+01 4774 M2Ve 5.71 5.70, -0.33, 0.21| -0.19, 3.12, -4.78 0.01
+Stars farther than 0.00pc and closer than 7.00pc,
+Lum between 0.0 and 100.0
+Gliese StarName Spec DistPC X Y Z Xg Yg Zg Lum
+ 1 DM-37 15492 M4V 4.44 3.52, 0.04, -2.71| 1.04, -0.30, -4.31 0.01
+ 15A DM+43 44 M1Ve 3.55 2.56, 0.17, 2.45| -1.51, 3.01, -1.12 0.01
+ 15B M6Ve 3.55 2.56, 0.17, 2.45| -1.51, 3.01, -1.12 0.00
+ 19 BET HYI G1IV 6.29 1.35, 0.14, -6.14| 2.76, -3.97, -4.02 2.75
+ 33 DM+04 123 K2V 6.94 6.78, 1.37, 0.61| -1.95, 3.18, -5.86 0.22
+ 34A ETA CAS G0V 5.88 3.09, 0.63, 4.96| -3.16, 4.94, -0.52 1.32
+ 34B M0V 5.88 3.09, 0.63, 4.96| -3.16, 4.94, -0.52 0.03
+ 35 VAN MAANEN 2 G wD 4.18 4.08, 0.84, 0.38| -1.19, 1.91, -3.53 0.00
+ 54.1 L 725-32 M5de 6.90 6.28, 1.99, -2.05| -1.17, 0.67, -6.76 0.00
+ 65A L 726-8 M5de 2.72 2.36, 1.06, -0.85| -0.67, 0.05, -2.64 0.00
+ 65B UV CET M5de 2.72 2.36, 1.06, -0.85| -0.67, 0.05, -2.64 0.00
+ 66A P ERI K2V 6.54 3.29, 1.50, -5.45| 1.11, -3.11, -5.64 0.20
+ 66B DM-56 328 K5Ve 6.54 3.29, 1.50, -5.45| 1.11, -3.11, -5.64 0.17
+ 71 TAU CET G8Vp 3.61 3.13, 1.49, -1.01| -1.02, 0.12, -3.46 0.47
+ 83.1 L 1159-16 M8de 4.69 3.99, 2.24, 1.04| -2.73, 1.73, -3.40 0.00
+139 82 ERI G5V 6.21 2.94, 3.44, -4.26| -1.14, -3.27, -5.16 0.70
+144 EPS ERI K2Ve 3.31 1.98, 2.59, -0.55| -2.13, -0.60, -2.46 0.32
+166A OMI(2) ERI K1Ve 4.88 2.18, 4.32, -0.66| -3.60, -1.36, -3.00 0.37
+166B DM-07 781 A wD 4.88 2.17, 4.32, -0.66| -3.60, -1.36, -3.00 0.00
+166C M4de 4.88 2.17, 4.32, -0.66| -3.60, -1.36, -3.00 0.00
+169.1A AC+58 25001 M4d 5.21 1.06, 2.47, 4.46| -4.38, 2.73, 0.66 0.00
+169.1B AC+58 25002 C wD 5.21 1.06, 2.47, 4.46| -4.38, 2.73, 0.66 0.00
+191 DM-45 1841 M0V 3.91 0.60, 2.70, -2.76| -1.06, -2.97, -2.30 0.00
+205 DM-03 1123 M1Ve 5.88 0.79, 5.82, -0.38| -4.95, -2.51, -1.96 0.02
+213 AC+12 1800-2 M5d 5.95 0.53, 5.79, 1.29| -5.71, -1.39, -0.95 0.00
+223.2 LP 658-2 K wDe 6.02 0.19, 6.01, -0.44| -5.04, -2.93, -1.50 0.00
+229 DM-21 1377 M1Ve 5.75 -0.20, 5.33, -2.14| -3.61, -4.09, -1.82 0.02
+234A ROSS 614 M7de 3.97 -0.46, 3.94, -0.19| -3.31, -2.14, -0.43 0.00
+234B 3.97 -0.46, 3.94, -0.19| -3.31, -2.14, -0.43 91.20
+244A ALF CMA A1V 2.65 -0.47, 2.50, -0.76| -1.78, -1.92, -0.41 24.66
+244B A wD 2.65 -0.47, 2.50, -0.76| -1.78, -1.92, -0.41 0.00
+251 AC+33 25644 M4d 5.95 -1.11, 4.85, 3.27| -5.74, -0.29, 1.56 0.00
+268 AC+38 23616 M5de 5.92 -1.33, 4.43, 3.69| -5.56, 0.10, 2.02 0.00
+273 DM+05 1668 M5d 3.70 -1.33, 3.44, 0.35| -3.08, -1.95, 0.67 0.00
+280A ALF CMI F5IV+ 3.51 -1.43, 3.19, 0.33| -2.84, -1.90, 0.79 8.02
+280B F wD 3.51 -1.43, 3.19, 0.33| -2.84, -1.90, 0.79 0.00
+285 YZ CMI M4de 6.06 -2.61, 5.46, 0.39| -4.78, -3.45, 1.41 0.00
+293 L 97-12 C wD 5.78 -1.04, 1.94, -5.35| 0.97, -5.37, -1.92 0.00
+299 ROSS 619 M5d 6.62 -3.49, 5.53, 1.04| -5.09, -3.44, 2.47 0.00
+300 L 674-15 M 5.85 -2.94, 4.59, -2.13| -2.77, -5.10, 0.70 0.00
+338A DM+53 1320 M0Ve 6.02 -2.69, 2.44, 4.80| -4.27, 1.15, 4.08 0.03
+338B DM+53 1321 M0Ve 6.02 -2.69, 2.44, 4.80| -4.27, 1.15, 4.08 0.03
+380 DM+50 1725 K7Ve 4.50 -2.57, 1.36, 3.44| -2.68, 0.68, 3.56 0.04
+388 DM+20 2465 M4Ve 4.90 -4.14, 2.00, 1.69| -2.28, -1.69, 4.00 0.00
+406 WOLF 359 M8de 2.35 -2.23, 0.66, 0.30| -0.57, -1.17, 1.95 0.00
+408 AC+23 468-46 M3d 6.62 -5.87, 1.64, 2.60| -2.30, -1.70, 5.98 0.00
+411 DM+36 2147 M2Ve 2.52 -1.96, 0.52, 1.49| -1.04, -0.09, 2.29 0.01
+412A DM+44 2051 M2Ve 5.38 -3.76, 0.96, 3.72| -2.38, 0.49, 4.80 0.01
+412B WX UMA M8de 5.38 -3.76, 0.95, 3.72| -2.38, 0.49, 4.80 0.00
+440 L 145-141 C wD 4.85 -2.08, 0.15, -4.38| 2.12, -4.36, -0.24 0.00
+445 AC+79 3888 M4sd 5.10 -0.97, 0.07, 5.01| -2.41, 3.22, 3.14 0.00
+447 ROSS 128 M5d 3.32 -3.31, 0.22, 0.06| 0.00, -1.68, 2.86 0.00
+473A WOLF 424 M5de 4.33 -4.23, -0.57, 0.70| 0.45, -1.31, 4.10 0.00
+473B 4.33 -4.23, -0.57, 0.70| 0.45, -1.31, 4.10 0.00
+477.1 DM+46 1797 K4V 6.10 -4.19, -0.62, 4.39| -1.30, 1.48, 5.77 0.05
+526 DM+15 2620 M4Ve 4.98 -4.32, -2.09, 1.30| 1.49, -0.22, 4.74 0.01
+551 PROXIMA CEN M5de 1.31 -0.49, -0.36, -1.17| 0.91, -0.94, -0.04 0.00
+555 DM-11 3759 M4d 6.25 -4.82, -3.75, -1.33| 4.24, -1.68, 4.27 0.00
+559A ALF CEN G2V 1.35 -0.51, -0.42, -1.17| 0.96, -0.94, -0.02 1.66
+559B K0V 1.35 -0.51, -0.42, -1.17| 0.96, -0.94, -0.02 0.48
+566A XI BOO G8Ve 6.76 -4.72, -4.29, 2.23| 2.98, 1.27, 5.93 0.56
+566B K4Ve 6.76 -4.72, -4.29, 2.23| 2.98, 1.27, 5.93 0.08
+570A DM-20 4125 K5Ve 5.56 -3.75, -3.57, -2.01| 4.34, -1.73, 3.00 0.14
+570B DM-20 4123 M2V 5.56 -3.75, -3.57, -2.01| 4.34, -1.73, 3.00 0.02
+581 DM-07 4003 M5d 6.54 -4.23, -4.91, -0.86| 4.98, -0.51, 4.20 0.00
+588 DM-40 9712 M4 5.92 -2.73, -3.53, -3.89| 5.14, -2.65, 1.24 0.00
+628 DM-12 4523 M5d 4.02 -1.54, -3.61, -0.87| 3.67, 0.22, 1.61 0.00
+643 WOLF 629 M4sd 6.21 -1.78, -5.88, -0.89| 5.68, 1.11, 2.24 0.00
+644A DM-08 4352 M4de 6.21 -1.78, -5.88, -0.89| 5.69, 1.11, 2.24 0.00
+644B M4d 6.21 -1.78, -5.88, -0.89| 5.69, 1.11, 2.24 0.00
+644C VB 8 6.21 -1.77, -5.88, -0.90| 5.69, 1.11, 2.23 0.00
+661A DM+45 2505 M3d 6.45 -0.96, -4.40, 4.62| 1.67, 4.95, 3.79 0.00
+661B M3 6.45 -0.96, -4.40, 4.62| 1.67, 4.95, 3.79 0.00
+663A DM-26 12026 K1Ve 5.43 -1.01, -4.76, -2.43| 5.39, -0.16, 0.65 0.26
+663B K1Ve 5.43 -1.01, -4.76, -2.43| 5.39, -0.16, 0.65 0.25
+664 DM-26 12036 K5Ve 5.43 -0.99, -4.76, -2.42| 5.39, -0.15, 0.64 0.08
+674 DM-46 11540 M4 4.63 -0.48, -3.13, -3.38| 4.40, -1.34, -0.55 0.00
+682 DM-44 11909 M5 4.69 -0.39, -3.34, -3.28| 4.52, -1.13, -0.54 0.00
+687 DM+68 946 M3V 4.69 -0.18, -1.72, 4.36| -0.60, 3.94, 2.49 0.00
+693 L 205-128 M 5.88 -0.24, -3.17, -4.95| 5.18, -2.38, -1.47 0.00
+699 BARNARD'S ST M5V 1.81 -0.04, -1.81, 0.14| 1.51, 0.90, 0.44 0.00
+702A DM+02 3482 K0Ve 5.13 0.07, -5.12, 0.22| 4.36, 2.51, 1.01 0.49
+702B K5Ve 5.13 0.07, -5.12, 0.22| 4.36, 2.51, 1.01 0.10
+725A DM+59 1915 M4d 3.55 0.33, -1.77, 3.06| 0.04, 3.23, 1.45 0.00
+725B M5d 3.55 0.33, -1.77, 3.06| 0.04, 3.23, 1.45 0.00
+729 AC-24 2833-1 M4de 2.90 0.54, -2.60, -1.17| 2.80, 0.56, -0.52 0.00
+752A DM+04 4048 M3Ve 5.78 1.84, -5.46, 0.51| 4.39, 3.75, -0.33 0.01
+752B VB 10 M5de 5.78 1.84, -5.46, 0.51| 4.39, 3.74, -0.33 0.00
+754 L 347-14 M7 5.71 1.32, -3.77, -4.08| 5.18, -0.69, -2.31 0.00
+764 SIG DRA K0V 5.68 0.78, -1.82, 5.32| -1.04, 5.17, 2.12 0.39
+768 ALF AQL A7IV 5.05 2.27, -4.44, 0.77| 3.36, 3.69, -0.78 11.59
+780 DEL PAV G8V 5.71 1.18, -1.97, -5.23| 4.17, -2.43, -3.06 1.14
+783A DM-36 13940 K3V 5.65 2.41, -3.87, -3.34| 4.83, 0.44, -2.90 0.22
+783B M5d 5.65 2.41, -3.87, -3.34| 4.83, 0.44, -2.90 0.00
+784 DM-45 13677 M0V 6.10 2.31, -3.61, -4.34| 5.09, -0.46, -3.32 0.02
+820A 61 CYG K5Ve 3.38 1.91, -1.83, 2.10| 0.45, 3.33, -0.34 0.08
+820B K7Ve 3.38 1.91, -1.83, 2.10| 0.45, 3.33, -0.34 0.04
+825 DM-39 14192 M0Ve 3.85 2.24, -1.98, -2.42| 2.75, 0.19, -2.69 0.03
+829 AC+17 534-10 M4de 6.54 4.90, -3.86, 1.96| 2.09, 5.61, -2.62 0.00
+832 DM-49 13515 M1V 4.67 2.42, -1.86, -3.54| 3.17, -0.60, -3.38 0.01
+845 EPS IND K5Ve 3.44 1.62, -0.94, -2.88| 2.10, -0.92, -2.55 0.14
+860A DM+56 2783 M3d 3.95 1.95, -0.85, 3.33| -1.00, 3.82, -0.00 0.00
+860B DO CEP M4de 3.95 1.95, -0.85, 3.33| -1.00, 3.82, -0.00 0.00
+866 L 789-6 M7de 3.28 2.95, -1.13, -0.88| 1.22, 1.31, -2.75 0.00
+873 DM+43 4305 M4de 5.13 3.49, -1.19, 3.57| -0.92, 4.91, -1.16 0.00
+876 DM-15 6290 M5d 4.78 4.42, -1.38, -1.20| 1.49, 1.91, -4.13 0.00
+880 DM+15 4733 M2de 6.85 6.30, -1.86, 1.92| 0.27, 5.38, -4.24 0.01
+881 ALF PSA A3V 6.71 5.59, -1.63, -3.34| 2.66, 1.00, -6.08 14.06
+887 DM-36 15693 M2Ve 3.58 2.80, -0.72, -2.11| 1.46, 0.13, -3.27 0.01
+892 DM+56 2966 K3V 6.80 3.63, -0.79, 5.70| -2.31, 6.39, -0.38 0.25
+896A DM+19 5116 M4de 6.45 6.02, -0.81, 2.17| -0.75, 4.95, -4.07 0.00
+896B M6de 6.45 6.02, -0.81, 2.17| -0.75, 4.95, -4.07 0.00
+905 ROSS 248 M6de 3.14 2.26, -0.20, 2.18| -1.03, 2.83, -0.92 0.00
+908 DM+01 4774 M2Ve 5.71 5.70, -0.33, 0.21| -0.19, 3.12, -4.78 0.01
diff --git a/Doc/old manual.doc b/Doc/Old Manual.doc
index c2fd04f..c2fd04f 100644
--- a/Doc/old manual.doc
+++ b/Doc/Old Manual.doc
Binary files differ
diff --git a/Doc/OUTLINE.TXT b/Doc/Outline.txt
index b1f5809..e12d47e 100644
--- a/Doc/OUTLINE.TXT
+++ b/Doc/Outline.txt
@@ -1,47 +1,47 @@
-STARSHATTER DEMO 1.0 MANUAL (OUTLINE)
-
-1. INTRODUCTION
- What is StarShatter?
- What is this demo all about?
- What is required to play?
- Hardware
- Operating System and Drivers
-
-2. INSTALLATION
- (just unzip into a directory)
-
-3. SETUP / OPTIONS
- Video Options
- Software Only
- Direct3D
- Detail Settings
- Sound Options
- (none)
- Keyboard Config
-
-4. GAMEPLAY INSTRUCTIONS
- Fighters and Starships
- The Displays
- HUD
- NAV
- ENG
- WEP
- The Controls
- Keyboard
- Joystick
- Using the Mouse
- About Your Ship
- Drive
- Weapons
- Shields
- Sensors
-
-5. MISSION INFO
- Training Cruise
- Fighter Sweep
- Air Superiority
- Destroyer Duel
-
-6. TROUBLESHOOTING and KNOWN PROBLEMS
-
-7. CREDITS and CONTACT INFO
+STARSHATTER DEMO 1.0 MANUAL (OUTLINE)
+
+1. INTRODUCTION
+ What is StarShatter?
+ What is this demo all about?
+ What is required to play?
+ Hardware
+ Operating System and Drivers
+
+2. INSTALLATION
+ (just unzip into a directory)
+
+3. SETUP / OPTIONS
+ Video Options
+ Software Only
+ Direct3D
+ Detail Settings
+ Sound Options
+ (none)
+ Keyboard Config
+
+4. GAMEPLAY INSTRUCTIONS
+ Fighters and Starships
+ The Displays
+ HUD
+ NAV
+ ENG
+ WEP
+ The Controls
+ Keyboard
+ Joystick
+ Using the Mouse
+ About Your Ship
+ Drive
+ Weapons
+ Shields
+ Sensors
+
+5. MISSION INFO
+ Training Cruise
+ Fighter Sweep
+ Air Superiority
+ Destroyer Duel
+
+6. TROUBLESHOOTING and KNOWN PROBLEMS
+
+7. CREDITS and CONTACT INFO
diff --git a/Doc/PAVLOV.TXT b/Doc/Pavlov.txt
index 662437e..14f4289 100644
--- a/Doc/PAVLOV.TXT
+++ b/Doc/Pavlov.txt
@@ -1,59 +1,59 @@
-Freespace 2 - great game. Lots of action, great looking, good
-storyline, gotta love it.
-
-But I want the thing to be more realistic. Before you freak out and yell at me for wanting a game with subspace nodes, meson bombs, and alien critter to be realistic, let me explain what I mean.
-
-The background I'm coming from is that of a pretty serious flight simmer. Those military sims involve, like FS2 and other space sim, large amounts of moving ans shooting things, but military sims have reality to be compared against.
-
-If you look at the progression of flight sims since their inception, what you see is that the first sims were the "you against the world" sims, like Andy Hollis' F-19 Stealth Fighter and F-15 Strike Eagle 3. You'd go in by your lonesome and complete your mission.
-
-Around the time of Falcon 3, we started getting a more integrated world -- while much of the "immersion" of Falcon 3 was all cleverly faked, it sure looked good. You could plan missions for your
-squadron, enemy aircraft would show up over targets, friendly flights would appear to have their own mission, and everything would look pretty much like a real war.
-
-Moving onto Falcon 4, I think Microprose went overboard and the entire war on the Korean Peninsula is simulated down to battalion level. Sure, its really immersive, but hard as hell to debug. :-)
-
-Anyway, back to space sims.
-
-We started off with sims like Wing Commander. Remember Wing Commander and its limitations? The fixed number of objects and types. You would have you and your wingman, and up to two other flights of up to five fighters, with the possibility of a couple capital ships around. With your wingman not much better than cannon fodder (Gee! Pav, looks like you got 22 today! Spirit, you came up empty!) It pretty much was "you against the world."
-
-Enter X-Wing, Tie Fighter, X-Wing Alliance, WC 2, 3, 4, P, and
-Freespace. All these sims get better, are prettier, and allow for more ships, but unlike flight sims, they're still all canned and scripted missions. Not to fault canned missions, but they can lead to some odd situations.
-
-For example, in Freespace 2, there is a mission where a <spoiler friendly> BIG GOOD GUY SHIP faces off against a BIG BAD GUY SHIP, and what else is currently in the mission?
-
-Me. That's it. Two capital ships and me. What happened to the escorts of the big ships? What happened to the fighter cover? In this mission, the big ships never hard any support ships. Everything is canned.
-
-In Freespace 2, when you see a bunch of friendly ships jump in, what does that mean? It means that the designer told some friendly ships to jump in, and maybe some protect the others. More likely, a
-destroyer will jump in with no supporting ships, and just go attack the bad guy destroyer, also with no supporting ships.
-
-From a flight simmers perspective, used to realism and military
-organizations, this is just sort of odd. How many large ships cruise around without a battlegroup? Look at a US carrier battlegroup. One carrier, couple cruisers, some destroyers, maybe a few frigate, couple subs, and auxiliaries.
-
-Each unit has their responsbilities, and the overall goal is to
-protect the big ship at the center of the formation.
-
-<aside: Shouldn't it go Corvette->Destroyer->Cruiser when it comes to increasing ship size, and not Cruiser->Corvette->Destroyer?>
-
-Ditto for the fighters. Where do fighters in FS2 come from?
-Subspace, yeah, but why don't fighters scramble from fighterbays?
-
-It just feels artificial to me.
-
-What I want?
-
-In the missions themselves:
-I want to have a space sim where the ships on both sides fight as a cohesive unit. I want the ability to end the "massive waves of enemy fighters coming from nowhere" tactic that every major space sim relies on. I want to see a finite number of enemy fighters coming from *somewhere*, like a base or carrier somewhere. It might be too far away to reach, but that's another matter. I want to see a the GTD Aquitaine jump in with two corvettes and four cruisers in support. I want to see fighters erupt from the fighterbay when it detect the enemy. I want to *be* one of those erupting fighters.
-
-In the overall game:
-I want to have wingment with names and a dossier. I want a campaign in a space sim that doesn't consist of scripted missions. I want to see a big star map showing the current status of the war. I want to be assigned missions where I can pick and chose wingmen and loadouts. I want to be able to see my performance have effect on the war. I want to have my wingmen mean something, rather than just people who die and leave more bandits to come after you.
-
-So, in short, what do I want?
-
-I want space sims to take the step that flight sims did a long time ago -- namely, step away from completely canned missions and go for a more open-ended playing style.
-
-What suffers? The story, obviously. However, I would maintain that the story for a space sim, already secondary to gameplay and graphics, should go behind replayability.
-
-But then again, I'm a flight simmer first and foremost, and as such, I look for different things in my games than those raised on Quake.
-
-Thoughts, comments?
-
+Freespace 2 - great game. Lots of action, great looking, good
+storyline, gotta love it.
+
+But I want the thing to be more realistic. Before you freak out and yell at me for wanting a game with subspace nodes, meson bombs, and alien critter to be realistic, let me explain what I mean.
+
+The background I'm coming from is that of a pretty serious flight simmer. Those military sims involve, like FS2 and other space sim, large amounts of moving ans shooting things, but military sims have reality to be compared against.
+
+If you look at the progression of flight sims since their inception, what you see is that the first sims were the "you against the world" sims, like Andy Hollis' F-19 Stealth Fighter and F-15 Strike Eagle 3. You'd go in by your lonesome and complete your mission.
+
+Around the time of Falcon 3, we started getting a more integrated world -- while much of the "immersion" of Falcon 3 was all cleverly faked, it sure looked good. You could plan missions for your
+squadron, enemy aircraft would show up over targets, friendly flights would appear to have their own mission, and everything would look pretty much like a real war.
+
+Moving onto Falcon 4, I think Microprose went overboard and the entire war on the Korean Peninsula is simulated down to battalion level. Sure, its really immersive, but hard as hell to debug. :-)
+
+Anyway, back to space sims.
+
+We started off with sims like Wing Commander. Remember Wing Commander and its limitations? The fixed number of objects and types. You would have you and your wingman, and up to two other flights of up to five fighters, with the possibility of a couple capital ships around. With your wingman not much better than cannon fodder (Gee! Pav, looks like you got 22 today! Spirit, you came up empty!) It pretty much was "you against the world."
+
+Enter X-Wing, Tie Fighter, X-Wing Alliance, WC 2, 3, 4, P, and
+Freespace. All these sims get better, are prettier, and allow for more ships, but unlike flight sims, they're still all canned and scripted missions. Not to fault canned missions, but they can lead to some odd situations.
+
+For example, in Freespace 2, there is a mission where a <spoiler friendly> BIG GOOD GUY SHIP faces off against a BIG BAD GUY SHIP, and what else is currently in the mission?
+
+Me. That's it. Two capital ships and me. What happened to the escorts of the big ships? What happened to the fighter cover? In this mission, the big ships never hard any support ships. Everything is canned.
+
+In Freespace 2, when you see a bunch of friendly ships jump in, what does that mean? It means that the designer told some friendly ships to jump in, and maybe some protect the others. More likely, a
+destroyer will jump in with no supporting ships, and just go attack the bad guy destroyer, also with no supporting ships.
+
+From a flight simmers perspective, used to realism and military
+organizations, this is just sort of odd. How many large ships cruise around without a battlegroup? Look at a US carrier battlegroup. One carrier, couple cruisers, some destroyers, maybe a few frigate, couple subs, and auxiliaries.
+
+Each unit has their responsbilities, and the overall goal is to
+protect the big ship at the center of the formation.
+
+<aside: Shouldn't it go Corvette->Destroyer->Cruiser when it comes to increasing ship size, and not Cruiser->Corvette->Destroyer?>
+
+Ditto for the fighters. Where do fighters in FS2 come from?
+Subspace, yeah, but why don't fighters scramble from fighterbays?
+
+It just feels artificial to me.
+
+What I want?
+
+In the missions themselves:
+I want to have a space sim where the ships on both sides fight as a cohesive unit. I want the ability to end the "massive waves of enemy fighters coming from nowhere" tactic that every major space sim relies on. I want to see a finite number of enemy fighters coming from *somewhere*, like a base or carrier somewhere. It might be too far away to reach, but that's another matter. I want to see a the GTD Aquitaine jump in with two corvettes and four cruisers in support. I want to see fighters erupt from the fighterbay when it detect the enemy. I want to *be* one of those erupting fighters.
+
+In the overall game:
+I want to have wingment with names and a dossier. I want a campaign in a space sim that doesn't consist of scripted missions. I want to see a big star map showing the current status of the war. I want to be assigned missions where I can pick and chose wingmen and loadouts. I want to be able to see my performance have effect on the war. I want to have my wingmen mean something, rather than just people who die and leave more bandits to come after you.
+
+So, in short, what do I want?
+
+I want space sims to take the step that flight sims did a long time ago -- namely, step away from completely canned missions and go for a more open-ended playing style.
+
+What suffers? The story, obviously. However, I would maintain that the story for a space sim, already secondary to gameplay and graphics, should go behind replayability.
+
+But then again, I'm a flight simmer first and foremost, and as such, I look for different things in my games than those raised on Quake.
+
+Thoughts, comments?
+
diff --git a/Doc/PLAYER.DOC b/Doc/Player.doc
index 0801142..0801142 100644
--- a/Doc/PLAYER.DOC
+++ b/Doc/Player.doc
Binary files differ
diff --git a/Doc/PLAYER2.DOC b/Doc/Player2.doc
index ba1b6b8..ba1b6b8 100644
--- a/Doc/PLAYER2.DOC
+++ b/Doc/Player2.doc
Binary files differ
diff --git a/Doc/space sim market crash.txt b/Doc/SpaceSim Market Crash.txt
index 3be1f21..e728336 100644
--- a/Doc/space sim market crash.txt
+++ b/Doc/SpaceSim Market Crash.txt
@@ -1,32 +1,32 @@
-
-1997:
-X-Wing vs. Tie Fighter (Balance of Power) 333,608 units ($15,333,000)
-Wing Commander Prophecy (and gold) 210,000 units ($7,110,000)
-
-1998
-Descent Freespace (Freespace 1) (and gold) 147,158 units ($4,563,000)
-Freespace expansion pack (alone) 23,000 units ($404,000)
-(so approximately 170,000 units and $5,000,000 for Freespace 1 in total)
-
-Independence War 61,000 units ($2,210,000)
-Interplay Re-release of Battlecruiser 3000 41,037 units ($405,000)
-
-1999
-X-Wing Alliance 235,920 units ($7,457,000)
-FreeSpace 2 (including game of the year) 83,484 units ($2,703,000)
-Independence War Deluxe 23,000 units ($487,000)
-(so approximately 84,000 units and $2,700,000 for Independence War and its
-expansion)
-
-2000
-Tachyon 61,200 units ($2,112,000)
-Starlancer 27,390 units ($1,147,000)
-Allegiance 12,700 units ($443,000)
-X-Beyond the Frontier 10,834 units ($295,000)
-
-2001
-Independence War 2 10,069 units ($407,000)
-
-
-I can't find Jump Gate's stats for some reason, but as I recall it sold less
-than 10,000 units.
+
+1997:
+X-Wing vs. Tie Fighter (Balance of Power) 333,608 units ($15,333,000)
+Wing Commander Prophecy (and gold) 210,000 units ($7,110,000)
+
+1998
+Descent Freespace (Freespace 1) (and gold) 147,158 units ($4,563,000)
+Freespace expansion pack (alone) 23,000 units ($404,000)
+(so approximately 170,000 units and $5,000,000 for Freespace 1 in total)
+
+Independence War 61,000 units ($2,210,000)
+Interplay Re-release of Battlecruiser 3000 41,037 units ($405,000)
+
+1999
+X-Wing Alliance 235,920 units ($7,457,000)
+FreeSpace 2 (including game of the year) 83,484 units ($2,703,000)
+Independence War Deluxe 23,000 units ($487,000)
+(so approximately 84,000 units and $2,700,000 for Independence War and its
+expansion)
+
+2000
+Tachyon 61,200 units ($2,112,000)
+Starlancer 27,390 units ($1,147,000)
+Allegiance 12,700 units ($443,000)
+X-Beyond the Frontier 10,834 units ($295,000)
+
+2001
+Independence War 2 10,069 units ($407,000)
+
+
+I can't find Jump Gate's stats for some reason, but as I recall it sold less
+than 10,000 units.
diff --git a/Doc/squadron (wc) info.txt b/Doc/Squadron Info.txt
index 0352983..1415ae2 100644
--- a/Doc/squadron (wc) info.txt
+++ b/Doc/Squadron Info.txt
@@ -1,96 +1,96 @@
-
-
-SQUADRON
-
-
-PRODUCT DESCRIPTION
-
-Background
- By the year 2654 AD, mankind has spread throughout his section of the galaxy. Along the way, humanity has come in contact with a handful of sentient races. Soon after first contact, most of these races have proven friendly.
- The Kilrathi definitely are not.
- Vessels of the Empire of Humanity first encountered Kilrathi explorers twenty-five years ago, in 2629. The Imperials offered the standard, non-linguistic greeting to the new aliens this opening gesture of friendship was met with a volley of laser fire. Within five years, the Empire and the Kilrathi were locked in an all-out-war for survival.
-
-The Kilrathi
- The Kilrathi are a vaguely mammalian race from a planet several hundred light years from Sol. Before they encountered humanity, the Kilrathi had never met a race capable of faster-than-light travel. Their warlike nature and technological superiority over their near neighbors led the Kilrathi to conquer and enslave every race they encountered. Over four centuries, the Kilrathi built a martial state two hundred light years across, ruled by the Supreme General of Kilrah.
- When the Kilrathi met humankind, they had finally encountered a race whose technology and power rivaled their own. Unfortunately, half a millennium of experience made it impossible for the Kilrathi to accept another race as their equal -- their only method for dealing with alien cultures was to conquer and subjugate them.
-
-The War
- In 2634, the Supreme General committed the entirety of the Kilrathi to the defeat or destruction of humankind. The ferocity of their initial attacks caught the Empire by surprise; thousands of worlds and billions of lives were lost before the Empire could marshal any serious opposition to the alien onslaught.
- The desperate struggle between man and Kilrath has pitted the determination and ingenuity of human defenders against the specialization and fanaticism of the genetically-engineered Kilrathi war machine. Through desperation as much as genius, the humans have fought back after their early losses. Today, twenty years after the war broke out, the conflict has devolved into a bloody stalemate, typified by a constant stream of dirty little skirmishes over war-torn worlds.
-
-
-Premise
- You are one of the Imperial Navy's finest --- a hot, young starfighter pilot, fresh from the Imperial Academy on Terra and combat flight training in the Vega system. All your life, you've heard the stories of the brave Imperial pilots, defending humanity against the vicious Kilrathi monsters. As you arrive on the Kilrathi frontier, your heart soars in anticipation of a life of glory and adventure.
- A newly-commissioned officer, you've been assigned to a strike carrier, the ISS Tiger's Claw. Your exemplary performance back at Vega has earned you the position of a flight leader with the 2411th Imperial Fighter Squadron -- the well-known "Blood Hawks." The men and women who have served before you, both on the Tiger's Claw and in the Blood Hawks, have established a tradition of bravery, skill and excellence you will be proud to uphold.
- One of the Empire's fastest carrier ships, the Tiger's Claw fulfills a troubleshooting role in the 36th Imperial Battle Fleet. It is one of the Fleet's "first response" vessels, usually the first Imperial ship to encounter the enemy in a combat situation.
-
-
-Spaceflight and Combat
- The core of Squadron is a state-of-the-art spaceflight combat simulation in which you and your two wingmen dogfight with the fighters, corvettes, cruisers, dreadnoughts, and other ships of the Kilrathi Star Force.
-
-Imperial Starships
- The starships that battle in the Squadron universe are not the simple, blocky polygon vessels that populate most space games. Instead, Squadron's starfighters -- and all the other vessels and objects in the game -- are amazingly photo-realistic, bit-mapped images, offering a crispness and tangibility previous games have lacked. The computer will depict every vessel using 64 ray-traced images, providing the smooth, realistic movement in any direction in three-dimensional space.
- Approximately 25 to 30 different vessel designs will appear in Squadron. You will be able to lead wings composed of four or five different Imperial fighter ships, ranging from the small, lightly-armed one-man Hornet to the two-man Raptor, a heavy fighter featuring a wide array of laser and missile systems. Other vessels in the Imperial fleet will include the strike carrier Tiger's Claw as well as the Venture-class corvette, the Drayman-class transport and the Diligent-class tanker.
-
-Kilrathi Starships
- The half-dozen starfighters representing the Kilrathi Star Fleet will run a gamut similar to that of the Imperial fighters, ranging from a light, highly-maneuverable ship to a tough, heavily-armed one. The Kilrathi battlefleet will be even more completely represented than the human one, though, five larger warships will be included as well; from smallest to largest, they include the corvette, the destroyed, the cruiser, the carrier, and the dreadnought.The dreadnought sports a number of independently-controlled weapons turrets, which pivot on the surface of the vessel to target enemy ships. Supporting the Kilrathi fleet will be transport and ranker ships, as well as a large starbase.
- Adding color to the Kilrathi fleet are four unique vessels, flown by NPC Kilrathi aces in key battles; once encountered, these distinctive starfighters will be instantly recognizable, allowing you to establish rivalries with enemy pilots over the course of a campaign.
-
-The Environment
- But starships are not the only photo-realistic, ray-traced objects in the Squadron universe. Some of the battles against the Kilrathi will take place in fields of spinning, drifting asteroids, or around large spare stations. And the projectiles launched by starships -- from laser bolts to mines to heat-seeking, image recognizing, or dead-fire misfiles -- will also be represented with three-dimensional, ray-traced graphics.
- Beyond the spaceships, missiles and asteroids, at the very limit of Squadron space, are a variety of celestial bodies. Though they will be so far away from the player's vessel that they will seem fixed in place, these planets, stars and nebulae provide the game with a reference for the pilots. For example, one battle may take place in an alien solar system; the star would be similar in the distance on one side, while its planets could be seen in other directions. Of course, the inner planets, whose dark sides would be turned to the battlefield, would appear as only crescent-shaped slivers, while those farther out will be nearly-full spheres, since it is their lit faces that will be turned towards the combatants.
-
-
-In the Cockpit
- But the breathtaking realism of Squadron doesn't end at the edge of the pilots windshield -- the interior of his ship is also depicted in vivid detail.
-
-Control Panels
- In fact, each of the four or five fighter-ships you can fly will have a different interior. Arranged around the control panels are a variety of functional scanners, readouts, and displays. Two scanners show the position of the enemy ships, one short-range and the other long. Other displays indicate the ship's available power, its shield level, its armament. As your ship is damaged, various displays will spark, explode or go dead, depriving you of vital information.
-
-The Pilot
- The heart of a starfighter is its pilot, and the ships in Squadron are no exception. Unlike existing airplane and spaceflight simulators, which show -- at best -- the pilots hand on the joystick, Squadron offers a full-body, over-the-shoulder of an animated pilot. Not only does his right hand steer the on-screen joystick along with your maneuvers, but his whole body moves in response to your actions and the environment. When the ship pulls a tight turn, the pilot's hand tilts with the G-force of the maneuver; when the ship is hit by lasers or missiles his whole body shakes with the impact. If you hit a key, to drop your shields or fire a missile, the on-screen pilot reaches with his left hand to hit the appropriate button on his control panel. The pilot even expresses emotion, to convey the drama of the dogfight -- when things get tense, you'll see him clench his fist to hold his nerves in check, and when you score a hit, he'll flash a quick, self-congratulatory thumbs-up sign!
-
-Radio Communications
- One of the most important parts of any dogfight is the radio chatter that accompanies and describes the action. This too will be reflected in Squadron. A video screen on the pilot's control panel will display a close-up shot of who ever happens to be speaking to you at any given moment -- your commander back on the Tiger's Claw, one of your wingmen, or the alien ace you've met in previous battles. the speaker's situation will be reflected on the video screen-- if he's been damaged, the image will be fuzzy and flickering. If he blows up, the screen glows white, then goes dead.
- The speaker's message will scroll across the bottom of the cockpit screen, like subtitles in a movie a tornado warning on television the speech of your fellow Imperials will appear as white text, while aliens talk in yellow or lime-green text.
-
-
-Scenarios
- At its most basic level, Squadron can be played by electing any of roughly 10 to 15 stand-alone battle scenarios. Each scenario is a unique combat situation, pitting you and your wingmen against a different assortment of enemy starships, and offering a different mission objective. Before the Battle
- Each scenario begins with a briefing, in which your squadron commander aboard the Tiger's Claw describes your mission, the opposition you are likely to face, and your mission objectives. Using a simple keyword system, you can ask your commander for additional information about the mission or strategic advice.
- From the briefing, the action cuts to the flight deck, where you see yourself climbing into the cockpit of your starfighter. The screen then cuts to the cockpit interior, where you'll have a few moments to go over your equipment, pre-set your shield levels, review your array of missiles, etc. Looking out the viewscreen of the fighter, you can see down the launch tubes; when you're ready to begin your mission, you hit the launch button. Through the viewscreen, you'll see the launch tube rushing by at a frightening speed -- then blackness surrounds you and you're in space. Your wingmen are just a bit head of you, to the right and left. You check your long-range scanners for bogeys, and head off to intercept the enemy.
-
-Killed in Action
- You should already have a feel for Squadron's remarkable space-combat simulation. Worth mentioning here, however, is the animated sequence which will run if your ship is destroyed.
- Should you suffer a fatal hit, the action will cut from the interior cockpit view to an exterior shot of your vessel. In a brief animation, your ship will explode in bright red and orange flames, with small bits of debris flying off in all directions. Once the explosion has faded to black, the scene cuts back to the briefing room, for the post-mission debriefing. Your pilots seat in the room will be conspicuously absent at the debriefing.
-
-Coming Home
- If you managed to survive to the conclusion of your mission, whether successful or not, the screen will cut from the cockpit view you saw throughout the battle to an exterior view of the Tiger's Claw. If the Claw suffered damage during the scenario, this will be apparent from this vantage.
- Your ship, and those of your wingmen if they survived, can be seen approaching in the distance, returning to the carrier after the mission. As you draw near, a tractor beam from the Tiger's Claw grabs your ships and guides them into the landing bay on the flight deck. Next, the scene cuts to a view of you climbing out of your fighter while an attentive mechanic inspects the ship for damage. In the background are the ships of your wingmen, if they made it back; if they were lost in combat, the next two spaces in the landing bay are conspicuously empty.
- When you leave the landing bay, you report to the briefing room for a mission analysis and debriefing. There, your squadron commander briefly analyzes your performance, and assesses mission success. He offers his congratulations if you've done well, or chews you out if you've performed poorly.
- After debriefing, the game returns to the main menu screen, where you can select another stand-alone scenario or begin the full-scale Squadron campaign.
-
-
-The Campaign
- Squadron is at its richest, most satisfying, and best when played as a Campaign. The Campaign version of Squadron allows you to participate in a series of crucial battles in the year 2654, at the height of the Imperial-Kilrathi war. By performing well in the scenarios, you can advance in rank, receive a variety of decorations, and be reassigned to various types of starfighters. Poor performance on the other hand, will weaken the Imperial position in the war, and result in more and harder scenarios later on, as the Kilrathi erode Imperial resources and personnel while suffering minimal losses themselves.
-
-Campaign Structure
- The Campaign consists of 20 scenarios, linked by a branching flow-chart. Your performance on earlier missions will directly affect your position in later ones, not to mention occasionally determining which branch you'll follow through the Campaign.
- In many cases, the effects of your performance might be subtle. For example, in the first scenario, you might be pitted against three alien starfighters. If any of these ships escape your dogfight, they will also appear in the second scenario, along with the ships which would appear in any case. Later on, if you fail to protect a supply ship, the Tiger's Claw may find itself short of material in the following scenarios, resulting in fuel and ammo rationing, and preventing certain repairs from being made to your starfighters between missions.
- In other instances, your performance may divert the Campaign onto another path of scenarios. If you destroy a Kilrathi strike carrier in the Symmett system, for example, this may set you up to press your advantage, making a direct assault on the Kilrathi starbase in that system. Or, if you fail to make it back from a scouting mission in a certain period of time, you may return to the Tiger's Claw only to find it under attack by Kilrathi fighters, which you'll have to defeat before you can land.
- In all, a typical run through the Squadron Campaign will involve you in about 12 of the 20 scenarios. This will add to the replay value of the game -- you'll have to play the Campaign several times before you've encountered every possible situation in every possible scenario. Further enhancing replay value is the fact that none of the stand-alone scenarios are included in the Campaign -- each battle in the Campaign will be completely new to the player.
-
-Beginning the Campaign
- You'll begin the Squadron Campaign by selecting the appropriate option on the main men u screen. From there, the game will take you to briefing room, for your mission briefing, just as with a stand-alone scenario. At the end of your briefing, however, you'll be asked to choose your wingmen for the mission from among the members of your squadron.
- A screen showing pictures and brief descriptions of the available pilots will appear. Based on your personal style of play and the information in the mission briefing, you may want to choose flashier, reckless and more daring pilots, or more careful and conservative wingmates. Of course, as you proceed through the Campaign, you'll come to know the members of your squadron better, and will settle on a handful of pilots you can count on as your regular wingman. In later scenarios, when you've moved up to a larger, two-man fighter, you'll also need to pick your own tailgunner.
- After you've chosen your crew, the game will proceed just as described for a stand-alone scenario -- climbing into your ship, launching and fighting the battle.
-
-Back on the Carrier
- After you've completed your missions, you'll return to the Tiger's Claw just as described for the stand-alone scenarios, above. The game will cut to the animated docking sequence, then the landing bay scene, and finally take you into the mission debriefing. After debriefing, if you've performed especially well, you may be awarded a promotion or a decoration. These honors are conferred by the commander of the Claw in an awards ceremony with simple animation.
- Following the debriefing, the game may take you to any of a handful of inter-scenario scenes, showing you sharing a drink in the officer's club with your fellow pilots, enjoying a brief shore leave planetside, or watching the news in the Claw's recreation hall.
- Of course, the lead story on the newscast is the latest update on the war against the Kilrathi. The holovision newscast will show highlights of your most recent battle as a miniaturized, holographic dogfight over the holoprojector in the rec hall. You and your fellow pilots can be seen sitting around the projector, watching the progress.
-
-Technical Notes
- [Chris -- you'll have to add this yourself if you need it. I'd recommend covering all the things the program covers that are transparent to someone playing the game, such as NPC morale, NPC intelligence, and ship's characteristics.
- You'll probably want to make a list of technical features, which I really can't do with any hope of accuracy. Things that would fit on this list would be the changing cockpit interiors for side and rear views, the ability to customize the key assignment for keyboard controls, the PC's ability to choose his complement of missiles for each mission, etc.]
-
+
+
+SQUADRON
+
+
+PRODUCT DESCRIPTION
+
+Background
+ By the year 2654 AD, mankind has spread throughout his section of the galaxy. Along the way, humanity has come in contact with a handful of sentient races. Soon after first contact, most of these races have proven friendly.
+ The Kilrathi definitely are not.
+ Vessels of the Empire of Humanity first encountered Kilrathi explorers twenty-five years ago, in 2629. The Imperials offered the standard, non-linguistic greeting to the new aliens this opening gesture of friendship was met with a volley of laser fire. Within five years, the Empire and the Kilrathi were locked in an all-out-war for survival.
+
+The Kilrathi
+ The Kilrathi are a vaguely mammalian race from a planet several hundred light years from Sol. Before they encountered humanity, the Kilrathi had never met a race capable of faster-than-light travel. Their warlike nature and technological superiority over their near neighbors led the Kilrathi to conquer and enslave every race they encountered. Over four centuries, the Kilrathi built a martial state two hundred light years across, ruled by the Supreme General of Kilrah.
+ When the Kilrathi met humankind, they had finally encountered a race whose technology and power rivaled their own. Unfortunately, half a millennium of experience made it impossible for the Kilrathi to accept another race as their equal -- their only method for dealing with alien cultures was to conquer and subjugate them.
+
+The War
+ In 2634, the Supreme General committed the entirety of the Kilrathi to the defeat or destruction of humankind. The ferocity of their initial attacks caught the Empire by surprise; thousands of worlds and billions of lives were lost before the Empire could marshal any serious opposition to the alien onslaught.
+ The desperate struggle between man and Kilrath has pitted the determination and ingenuity of human defenders against the specialization and fanaticism of the genetically-engineered Kilrathi war machine. Through desperation as much as genius, the humans have fought back after their early losses. Today, twenty years after the war broke out, the conflict has devolved into a bloody stalemate, typified by a constant stream of dirty little skirmishes over war-torn worlds.
+
+
+Premise
+ You are one of the Imperial Navy's finest --- a hot, young starfighter pilot, fresh from the Imperial Academy on Terra and combat flight training in the Vega system. All your life, you've heard the stories of the brave Imperial pilots, defending humanity against the vicious Kilrathi monsters. As you arrive on the Kilrathi frontier, your heart soars in anticipation of a life of glory and adventure.
+ A newly-commissioned officer, you've been assigned to a strike carrier, the ISS Tiger's Claw. Your exemplary performance back at Vega has earned you the position of a flight leader with the 2411th Imperial Fighter Squadron -- the well-known "Blood Hawks." The men and women who have served before you, both on the Tiger's Claw and in the Blood Hawks, have established a tradition of bravery, skill and excellence you will be proud to uphold.
+ One of the Empire's fastest carrier ships, the Tiger's Claw fulfills a troubleshooting role in the 36th Imperial Battle Fleet. It is one of the Fleet's "first response" vessels, usually the first Imperial ship to encounter the enemy in a combat situation.
+
+
+Spaceflight and Combat
+ The core of Squadron is a state-of-the-art spaceflight combat simulation in which you and your two wingmen dogfight with the fighters, corvettes, cruisers, dreadnoughts, and other ships of the Kilrathi Star Force.
+
+Imperial Starships
+ The starships that battle in the Squadron universe are not the simple, blocky polygon vessels that populate most space games. Instead, Squadron's starfighters -- and all the other vessels and objects in the game -- are amazingly photo-realistic, bit-mapped images, offering a crispness and tangibility previous games have lacked. The computer will depict every vessel using 64 ray-traced images, providing the smooth, realistic movement in any direction in three-dimensional space.
+ Approximately 25 to 30 different vessel designs will appear in Squadron. You will be able to lead wings composed of four or five different Imperial fighter ships, ranging from the small, lightly-armed one-man Hornet to the two-man Raptor, a heavy fighter featuring a wide array of laser and missile systems. Other vessels in the Imperial fleet will include the strike carrier Tiger's Claw as well as the Venture-class corvette, the Drayman-class transport and the Diligent-class tanker.
+
+Kilrathi Starships
+ The half-dozen starfighters representing the Kilrathi Star Fleet will run a gamut similar to that of the Imperial fighters, ranging from a light, highly-maneuverable ship to a tough, heavily-armed one. The Kilrathi battlefleet will be even more completely represented than the human one, though, five larger warships will be included as well; from smallest to largest, they include the corvette, the destroyed, the cruiser, the carrier, and the dreadnought.The dreadnought sports a number of independently-controlled weapons turrets, which pivot on the surface of the vessel to target enemy ships. Supporting the Kilrathi fleet will be transport and ranker ships, as well as a large starbase.
+ Adding color to the Kilrathi fleet are four unique vessels, flown by NPC Kilrathi aces in key battles; once encountered, these distinctive starfighters will be instantly recognizable, allowing you to establish rivalries with enemy pilots over the course of a campaign.
+
+The Environment
+ But starships are not the only photo-realistic, ray-traced objects in the Squadron universe. Some of the battles against the Kilrathi will take place in fields of spinning, drifting asteroids, or around large spare stations. And the projectiles launched by starships -- from laser bolts to mines to heat-seeking, image recognizing, or dead-fire misfiles -- will also be represented with three-dimensional, ray-traced graphics.
+ Beyond the spaceships, missiles and asteroids, at the very limit of Squadron space, are a variety of celestial bodies. Though they will be so far away from the player's vessel that they will seem fixed in place, these planets, stars and nebulae provide the game with a reference for the pilots. For example, one battle may take place in an alien solar system; the star would be similar in the distance on one side, while its planets could be seen in other directions. Of course, the inner planets, whose dark sides would be turned to the battlefield, would appear as only crescent-shaped slivers, while those farther out will be nearly-full spheres, since it is their lit faces that will be turned towards the combatants.
+
+
+In the Cockpit
+ But the breathtaking realism of Squadron doesn't end at the edge of the pilots windshield -- the interior of his ship is also depicted in vivid detail.
+
+Control Panels
+ In fact, each of the four or five fighter-ships you can fly will have a different interior. Arranged around the control panels are a variety of functional scanners, readouts, and displays. Two scanners show the position of the enemy ships, one short-range and the other long. Other displays indicate the ship's available power, its shield level, its armament. As your ship is damaged, various displays will spark, explode or go dead, depriving you of vital information.
+
+The Pilot
+ The heart of a starfighter is its pilot, and the ships in Squadron are no exception. Unlike existing airplane and spaceflight simulators, which show -- at best -- the pilots hand on the joystick, Squadron offers a full-body, over-the-shoulder of an animated pilot. Not only does his right hand steer the on-screen joystick along with your maneuvers, but his whole body moves in response to your actions and the environment. When the ship pulls a tight turn, the pilot's hand tilts with the G-force of the maneuver; when the ship is hit by lasers or missiles his whole body shakes with the impact. If you hit a key, to drop your shields or fire a missile, the on-screen pilot reaches with his left hand to hit the appropriate button on his control panel. The pilot even expresses emotion, to convey the drama of the dogfight -- when things get tense, you'll see him clench his fist to hold his nerves in check, and when you score a hit, he'll flash a quick, self-congratulatory thumbs-up sign!
+
+Radio Communications
+ One of the most important parts of any dogfight is the radio chatter that accompanies and describes the action. This too will be reflected in Squadron. A video screen on the pilot's control panel will display a close-up shot of who ever happens to be speaking to you at any given moment -- your commander back on the Tiger's Claw, one of your wingmen, or the alien ace you've met in previous battles. the speaker's situation will be reflected on the video screen-- if he's been damaged, the image will be fuzzy and flickering. If he blows up, the screen glows white, then goes dead.
+ The speaker's message will scroll across the bottom of the cockpit screen, like subtitles in a movie a tornado warning on television the speech of your fellow Imperials will appear as white text, while aliens talk in yellow or lime-green text.
+
+
+Scenarios
+ At its most basic level, Squadron can be played by electing any of roughly 10 to 15 stand-alone battle scenarios. Each scenario is a unique combat situation, pitting you and your wingmen against a different assortment of enemy starships, and offering a different mission objective. Before the Battle
+ Each scenario begins with a briefing, in which your squadron commander aboard the Tiger's Claw describes your mission, the opposition you are likely to face, and your mission objectives. Using a simple keyword system, you can ask your commander for additional information about the mission or strategic advice.
+ From the briefing, the action cuts to the flight deck, where you see yourself climbing into the cockpit of your starfighter. The screen then cuts to the cockpit interior, where you'll have a few moments to go over your equipment, pre-set your shield levels, review your array of missiles, etc. Looking out the viewscreen of the fighter, you can see down the launch tubes; when you're ready to begin your mission, you hit the launch button. Through the viewscreen, you'll see the launch tube rushing by at a frightening speed -- then blackness surrounds you and you're in space. Your wingmen are just a bit head of you, to the right and left. You check your long-range scanners for bogeys, and head off to intercept the enemy.
+
+Killed in Action
+ You should already have a feel for Squadron's remarkable space-combat simulation. Worth mentioning here, however, is the animated sequence which will run if your ship is destroyed.
+ Should you suffer a fatal hit, the action will cut from the interior cockpit view to an exterior shot of your vessel. In a brief animation, your ship will explode in bright red and orange flames, with small bits of debris flying off in all directions. Once the explosion has faded to black, the scene cuts back to the briefing room, for the post-mission debriefing. Your pilots seat in the room will be conspicuously absent at the debriefing.
+
+Coming Home
+ If you managed to survive to the conclusion of your mission, whether successful or not, the screen will cut from the cockpit view you saw throughout the battle to an exterior view of the Tiger's Claw. If the Claw suffered damage during the scenario, this will be apparent from this vantage.
+ Your ship, and those of your wingmen if they survived, can be seen approaching in the distance, returning to the carrier after the mission. As you draw near, a tractor beam from the Tiger's Claw grabs your ships and guides them into the landing bay on the flight deck. Next, the scene cuts to a view of you climbing out of your fighter while an attentive mechanic inspects the ship for damage. In the background are the ships of your wingmen, if they made it back; if they were lost in combat, the next two spaces in the landing bay are conspicuously empty.
+ When you leave the landing bay, you report to the briefing room for a mission analysis and debriefing. There, your squadron commander briefly analyzes your performance, and assesses mission success. He offers his congratulations if you've done well, or chews you out if you've performed poorly.
+ After debriefing, the game returns to the main menu screen, where you can select another stand-alone scenario or begin the full-scale Squadron campaign.
+
+
+The Campaign
+ Squadron is at its richest, most satisfying, and best when played as a Campaign. The Campaign version of Squadron allows you to participate in a series of crucial battles in the year 2654, at the height of the Imperial-Kilrathi war. By performing well in the scenarios, you can advance in rank, receive a variety of decorations, and be reassigned to various types of starfighters. Poor performance on the other hand, will weaken the Imperial position in the war, and result in more and harder scenarios later on, as the Kilrathi erode Imperial resources and personnel while suffering minimal losses themselves.
+
+Campaign Structure
+ The Campaign consists of 20 scenarios, linked by a branching flow-chart. Your performance on earlier missions will directly affect your position in later ones, not to mention occasionally determining which branch you'll follow through the Campaign.
+ In many cases, the effects of your performance might be subtle. For example, in the first scenario, you might be pitted against three alien starfighters. If any of these ships escape your dogfight, they will also appear in the second scenario, along with the ships which would appear in any case. Later on, if you fail to protect a supply ship, the Tiger's Claw may find itself short of material in the following scenarios, resulting in fuel and ammo rationing, and preventing certain repairs from being made to your starfighters between missions.
+ In other instances, your performance may divert the Campaign onto another path of scenarios. If you destroy a Kilrathi strike carrier in the Symmett system, for example, this may set you up to press your advantage, making a direct assault on the Kilrathi starbase in that system. Or, if you fail to make it back from a scouting mission in a certain period of time, you may return to the Tiger's Claw only to find it under attack by Kilrathi fighters, which you'll have to defeat before you can land.
+ In all, a typical run through the Squadron Campaign will involve you in about 12 of the 20 scenarios. This will add to the replay value of the game -- you'll have to play the Campaign several times before you've encountered every possible situation in every possible scenario. Further enhancing replay value is the fact that none of the stand-alone scenarios are included in the Campaign -- each battle in the Campaign will be completely new to the player.
+
+Beginning the Campaign
+ You'll begin the Squadron Campaign by selecting the appropriate option on the main men u screen. From there, the game will take you to briefing room, for your mission briefing, just as with a stand-alone scenario. At the end of your briefing, however, you'll be asked to choose your wingmen for the mission from among the members of your squadron.
+ A screen showing pictures and brief descriptions of the available pilots will appear. Based on your personal style of play and the information in the mission briefing, you may want to choose flashier, reckless and more daring pilots, or more careful and conservative wingmates. Of course, as you proceed through the Campaign, you'll come to know the members of your squadron better, and will settle on a handful of pilots you can count on as your regular wingman. In later scenarios, when you've moved up to a larger, two-man fighter, you'll also need to pick your own tailgunner.
+ After you've chosen your crew, the game will proceed just as described for a stand-alone scenario -- climbing into your ship, launching and fighting the battle.
+
+Back on the Carrier
+ After you've completed your missions, you'll return to the Tiger's Claw just as described for the stand-alone scenarios, above. The game will cut to the animated docking sequence, then the landing bay scene, and finally take you into the mission debriefing. After debriefing, if you've performed especially well, you may be awarded a promotion or a decoration. These honors are conferred by the commander of the Claw in an awards ceremony with simple animation.
+ Following the debriefing, the game may take you to any of a handful of inter-scenario scenes, showing you sharing a drink in the officer's club with your fellow pilots, enjoying a brief shore leave planetside, or watching the news in the Claw's recreation hall.
+ Of course, the lead story on the newscast is the latest update on the war against the Kilrathi. The holovision newscast will show highlights of your most recent battle as a miniaturized, holographic dogfight over the holoprojector in the rec hall. You and your fellow pilots can be seen sitting around the projector, watching the progress.
+
+Technical Notes
+ [Chris -- you'll have to add this yourself if you need it. I'd recommend covering all the things the program covers that are transparent to someone playing the game, such as NPC morale, NPC intelligence, and ship's characteristics.
+ You'll probably want to make a list of technical features, which I really can't do with any hope of accuracy. Things that would fit on this list would be the changing cockpit interiors for side and rear views, the ability to customize the key assignment for keyboard controls, the PC's ability to choose his complement of missiles for each mission, etc.]
+
diff --git a/Doc/Starshatter Campaign.txt b/Doc/Starshatter Campaign.txt
index 18dc72b..2f0bbab 100644
--- a/Doc/Starshatter Campaign.txt
+++ b/Doc/Starshatter Campaign.txt
@@ -1,998 +1,998 @@
-
-==================== STARSHATTER ====================
- STRATEGY
-
-Although Starshatter is fundamentally an action title,
-there is also a significant back-story and strategic
-element to the gameplay.
-
-The game occurs in a far-distant future of the Milky
-Way galaxy. Our corner of the galaxy, an area some
-ten or twenty thousand light years in diameter is popu-
-lated by thousands of human-intelligent species on tens
-of thousands of worlds. Many races live in approximate
-isolation, but most are organized into complex poly-
-specific civilizations spanning many star systems.
-Humans are not central in galactic affairs (as in Star
-Trek or Star Wars) but are merely another species. And
-some of the other species and civilizations are *much*
-older and *much* more advanced than ours.
-
-
-POLITICAL FACTIONS:
-
-- Starshatter (warlike/imperial power)
-
-* Sterat Empire (controlled by the Starshatter)
-
-* Brenel Core (military/intelligence corporation)
-
-* Zolon Empire (hive-like hereditary empire)
-
-* Marakan Hegemony (Failing human imperial civilization)
-
-* Terellian Alliance (peaceful commerce group)
- Alliance of Terellian Republics (ATR)
-
-+ Ele'aan Fusion (peaceful/isolationist power)
-
-The player is a human starfighter pilot in the military
-of one such civilization, the Terellian Alliance or ATR.
-The computer plays the part of the player's superior
-officers in assigning missions and offering criticism
-and praise for performance. In addition, the computer
-plays the role of all enemy pilots and politicians.
-
-The game follows the action in an interstellar conflict
-between the Terellian Alliance and those civilizations in
-the control of the Starshatter. The player is assigned
-missions and ships commensurate with his ability by the
-computer.
-
-==================== STARSHATTER ====================
- MISSIONS
-
-Each of the three episodes follows the action in a military
-campaign against a single enemy civilization. Individual
-missions will be constructed on the fly by the dynamic
-campaign manager (or by the player if acting as operational
-commander).
-
-Each episode takes place in a fixed volume of space con-
-taining about a dozen star systems. The global campaign
-map will treat the star systems as points in a 2D map.
-The action will take place within individual star systems,
-which use a finer grained map. The enemy will control
-most of the star systems, although a few will be neutral,
-allied, or controlled by the player's faction. These may
-need to be defended if the enemy is able to incur.
-
-Rather than being "mission based", Starshatter is an
-"operational simulation". Each campaign episode is
-broken down into a series of military operations, each
-of which occur in a given star system. Different opera-
-tions will have different rules of engagement and victory
-conditions. Some will require the player to secure a
-neutral or allied star system from hostile threats.
-Others will involve incursion into hostile territory.
-Still others will have more limited objectives, such
-as securing a friendly position in a neutral system,
-without violating neutral airspace or damaging neutral
-assets.
-
-Major resources such as space stations, ship yards,
-SAM and sensor sites will be part of the fixed universe
-design. Likewise, the initial number, type, and location
-of warships is fixed at design time. It is hoped that
-the combination of large numbers of ships and small
-random factors (battle outcome, planetary position,
-time of attack) will result in increased variety of
-enounter for the player.
-
-During the game, the campaign manager must keep track
-of the location and make-up of each ship and battle group.
-As each ship is destroyed in battle, it must be removed
-(permanently) from play. New ships and battle groups
-can be constructed on each side, at a rate dependent
-on how many critical resources the side controls. In
-addition, reserves may be advanced from rearward areas
-to support an operation.
-
-For each mission, the computer will assemble a mission
-profile by selecting one or more objectives, selecting
-a location for the battle, and assigning friendly and
-enemy forces. The computer can choose randomly from
-among the nearby resources to attack (or defend) and
-the nearby ships on both sides to fight.
-
-Missions will be generated in accordance with the current
-strategic objectives for the operation. The dynamic
-campaign manager will keep a prioritized list of
-strategic objectives, mostly related to major fixed
-resources.
-
-Before the battle, the player will be given a gene-
-rated mission briefing describing the mission objec-
-tives, locale, and the makeup of his own group.
-
-Once the player completes the mission (or loses it),
-the computer will tally up the losses on both sides
-and remove those ships from the campaign roster. A
-generated mission debriefing will detail kills and
-losses, pilot ratings, etc.
-
-In order to keep the player doing something interesting,
-he will have to be assigned to an attack force, either
-a battle group or fighter wing. Early missions will be
-shorter and simpler, with a single objective in a
-single system. Later missions will get more involved,
-with multiple objectives and sometimes requiring free
-drive travel to other systems. In addition, the com-
-plexity of missions will be modulated by the user's
-chosen difficulty level.
-
-Sometimes, the objectives will be enemy forces: e.g.
-destroy a fighter wing or cripple a battle group.
-Other times, they will be fixed resources like space
-stations or fortified moons. Still other times, they
-will be distributed or moving targets: e.g. shut down
-interplanetary shipping throughout the system.
-
-At any time, the player's group may get assigned to
-a defensive mission (scramble). This can mean defending
-a fixed resource from an incoming enemy attack. Or it
-could mean escorting an important freight convey through
-unsecured space.
-
-Mission objectives can be constructed from verb-noun
-imperatives:
-
- Verb List Object List
- ---------------- -----------------
- Intercept Ship
- Shadow Group of Ships
- Escort
- Defend
-
- Strike Space Station
- Capture
- Blockade
- Defend
-
- Recon Ship, building, or station
- Jam
- Designate
-
- Launch From Starship or Station
- Dock With
- Dock/Rearm/Launch
-
- Clear Mine Field / Satellite Grid
- Deploy
-
- Go To Location
- Patrol
- Hold At
-
-
-==================== STARSHATTER ====================
- INTERFACE
-
-SCREEN CONCEPTS:
-
------------------------------------------------------
-Main Menu
------------------------------------------------------
-
- New Game
- Continue Game
- Quick Mission
- Training
-
- Player Info (callsign, difficulty level, stats)
- Game Options (controls, audio-video settings)
-
- Help!
- Exit
-
------------------------------------------------------
-Help Menu
------------------------------------------------------
-
- Online Manual
- Keymap
- About...
- Credits
-
------------------------------------------------------
-Operational Command
------------------------------------------------------
-
- Operation Name, Date, Status
- ----
- Orders (overview of operation)
- Theater (system map showing resources)
- Strat Plan (edit objective list)
- Intel Rpt (news feed)
- Status (current score, us vs. them)
-
- - missions -
- Active ## (current mission list)
- Pending ## (missions in prep)
- Scramble ## (inbound threat list)
-
- Commit (engage current mission)
- Cancel (back to main menu)
-
- Also need controls to navigate the maps, and
- control visual clutter.
-
- [May want to offer simpler versions of this
- screen for "Starship Command" and "Fighter
- Command", allowing the player to focus on
- combat simulation rather than strategy.]
-
------------------------------------------------------
-Mission Planning
------------------------------------------------------
-
- Briefing Data (scrolling text and images)
- Mission Title
- Objective List
- Force Package
- package callsign
- wingmen and loadout
- Annotated Flight Plan
- launch time
- nav points and events
- time on target
- Intel Report
- expected counterforce
- degree of confidence
-
- Package (select wingmen)
- Loadout (select weapons)
- Nav Map (edit nav points)
- Targets (assign objectives to flights)
-
- Commit (engage current mission)
- Cancel (back to previous screen)
-
- [NOTE: same screen can double as Alert Intercept
- by changing the title and removing the edit buttons]
-
-
-==================== STARSHATTER ====================
- TRAINING
-
-Training Missions (both services)
-
-1. Basic Flight and Navigation
-2. Guns
-3. Missiles
-4. Combat Maneuver
-5. Sensors / Stealth
-6. Wingman Interface
-7. Long Range Scan
-8. Tactical Navigation and Waypoint Setting
-9. Advanced Tactics
- a. Starship Assault (fighter weapon school)
- b. Cruise missiles & Flight Ops (fleet tactical school)
-10. Situation Awareness (Final Exam)
-
-
-=======================================================
- MISCELLANIA
-
-Sensor ships and stations will be important resources in
-winning the information war. Both the player and the AI
-will need to exploit and protect them appropriately.
-
-Briefings/Debriefings and other Intelligence Reports
-must adequately communicate the overall game situation
-to the player in order to allow the player to make
-meaningful decisions. This is crucial to establishing
-immersion and making the player care about the outcome
-of the game.
-
-Briefings and Info Bursts will be more visceral if they
-include simulated "news footage" of the events being
-related.
-
-
-=======================================================
- DYNAMIC CAMPAIGN NOTES
-
-1. Fighter jocks will be allowed to choose from a
- menu of generated missions that have been assigned
- to the player's squadron.
-
-2. Cruiser skippers will be given only one generated
- mission at a time (like KA or SFC), but it will be
- somewhat broader in scope.
-
-3. Carrier admirals will do what exactly?
-
-4. Both cruiser and carrier missions will often start
- in the field or on patrol. Fighter missions will
- always start and end at a base (carrier|station|
- dirtside starbase).
-
-5. Cruiser and carrier missions will not normally
- include the starsender translation to the area of
- conflict. The player will only go through the
- sender in real time as part of a mission (not as
- prelude or ending to a mission).
-
-6. Admirals will need to be able to generate orders
- for their forces during the battle. This implies
- some kind of Op Command workstation.
-
-7. The mission planner algorithm must construct
- generated missions that are "fun", not just logical
- to the campaign. I have a vague notion of using
- time/distance heuristics to place enemy units as
- "challenges" on the battle field. e.g. For xxx
- type of mission, place an enemy destroyer yyy
- minutes away from the (player|objective|sender).
-
-8. The generated missions do not have to hang together
- as well as previously planned. That is, we don't
- need to maintain the feeling that the player is just
- a unit in an RTS game. Instead, the campaign manager
- is just a device for generating interesting single
- player missions as would be found in any game with
- a static campaign.
-
- On the other hand, the player should not see any
- obvious contradictions between the big board and
- what occurred during their missions. That means,
- any kills they witnessed must still be visible
- between missions in the intel report/event log.
-
-
-=======================================================
- SHIP NAMES
-
---- TERELLIAN SHIP NAMES ---
-
-F-32 Falcon Squadrons
- Tigers Bearcats Avengers Windriders Wizards Warriors Aces
-
-F-36C Stormhawk Squadrons
- Nighthawks Mustangs Stallions Chargers Hunters Broncos Trailblazers
-
-F/A-38D Talon Squadrons
- Starknights Lancers Warbirds Razorbacks Rangers Sabres Kings
-
-
-Berents Class FF (922 - 951) 924
- 1............2............3............4............5............6............7............
-22 Berents Bosporus Belfast Bering Dalton Surrey Halston
-27 Clarkeston Carlisle Canton Davis Delmar Kent Portsmouth
-32 Darvon Leyte Hemmet Messina Morgan Durham Bristol
-37 Avalon Argiles Essex Nalu Normandy Kingston Oxford
-42 Malory Parker Rainier Kelvin Nellis Saratoga Columbia
-47 Sorrel Suffolk Tanner Trieste Wolfram Broome Orleans
-
-Asher Class DDK (708 - 737) 710
-08 Asher Ryan Gerson Reynolds Nordic Vernor Arthur
-13 Shaw Card Simmons Hawker Hughes Nichols Smith
-18 Vance Gibson Raven Hale Salas Hoffman Parks
-23 Douglas Mahan Brunner Weber Smith Deforest Standish
-28 Robinson Clarke Gerrond Gamma Roberts Bear Drayton
-33 Keller Jackson Radix Lawrence Rand Chance Cavanaugh
-
-Spectre Class DD (350 - 395) 352
-50 Spectre Wraith Shadow Warlock Phantom
-55 Charon Nemesis Necromancer Merlin Nightshade
-60 Morlock Demon Hydra Typhon Enigma
-65 Phantasm Revenant Banshee Chimaera Gorgon
-70 Nightmare Darkmage Ogre Chaos Death's Head
-75 Ghola Efrite Ettin Incubus Secret Fire
-80 Siren Cerberus Mantis Orknies Fell Hunter
-85 Warspite Fire Angel Silence Mysterious Flame of Gorath
-90 Centaur Minotaur Dark Spirit Aegis Void Walker
-
-Courageous Class CG (521 - 545)
- 1............2............3............4............5............6............7............
-21 Courageous Fearless Stalwart Defender Guardian Loyalty Forthright
-26 Steadfast Assurance Protector Heroic Valiant Justice Honesty
-31 Dauntless Vanguard Redstone Victorious Honorable Truth Gallantry
-36 Braveheart Defiant Audacious Valorous Confident Response Resolve
-41 Integrity Capable Fortitude Intrepid Virtuous Daring Bold
-
-Devastator Class CA (400 - 419)
-00 Devastator Annihilator Onslaught Relentless Furious Stormwind Demolisher
-05 --------- Thunder Hurricane Inferno Torrent Typhoon Shrike
-10 ------- Vortex Predator Ravager
-15 Havoc Scourge Huntress Warrior
-
-Orion Class CVF
- Orion Antares Archon Titan Hyperion Atlas Hercules
- Chronos Poseidon Cygnus
-
---- MARAKAN SHIP NAMES ---
-
-F-MK1 Viper Squadrons
- Scorpions Dragons Hornets Sharks Demons Vipers Black Widows
-
-F-MK2 Razor Squadrons
- Raptors Vultures Cougars Vandals Vigilantes Wolfpack Black Diamonds
-
-F-MK3 Cobra Squadrons
- Avengers Vampires Lions Kestrels Ravens Bounty Hunters Panthers
-
-Baikal Class FF
- Baikal Irkutsk Olkha Iskra Lebedinka
- Meget Homutovo Ivanovka Yagat Kyren
- Vasad Nasaly Letkes Dorog Pomoz
- Lovo Kerta Nova Marcali Csorna
- Bajna Vorka Setla Rodina Markov
- Dolina Porac Tarnov Udel Karalon
-
-Tiger Bay Class FF
- 1............2............3............4............5............6............7............
-
-01 Tiger Bay
-08 Southern Isles
-15 Hellas Point
-22 Iron Canyon
-29 Mount Teras
-36 Black River
-43 Guard Hills
-50 Gulf of Kirt
-57 Star Island
-64 Rodis Station
-
-02 Tarsus Pride
-09 Eternal City
-16 Kala Docks
-23 Outer Rim
-30 Kolchev
-37 Rock Ridge
-44 Aenia
-51 Boma Beach
-58 Falcrest
-65 Angel Shore
-
-03 Valley of Flame
-10 Leopard Ridge
-17 Kalis Basin
-24 Cape Nor
-31 Blue Forest
-38 Landfall
-45 Lake Orsan
-52 Wind River
-59 Tolan Locks
-66 Mount Zoare
-
-04 Silas Cave
-11 River Ceres
-18 Elkhorn Pass
-25 Port Hanson
-32 Oak Hall
-39 North Point
-46 Loris Dunes - not used
-53 Beacon Bay - not used
-60 Sand Canyon - not used
-67 Iron Mountain - not used
-
-05 Khaital
-12 Ash Hills
-19 Albus Gulf
-26 Siren Island
-33 Neptune Station
-40 Trocanther
-47 Night City
-54 Joran Docks
-61 Hunter Coast
-68 Nephrys
-
-06 Storm Island
-13 Orinoco
-20 Jewel Beach
-27 Knife Ridge
-34 Secret Shore
-41 Crown of Fire
-48 Hilger Coast
-55 Sword Cliffs
-62 Capetown
-69 Smoke Forest
-
-07 Blackrock
-14 Sutton Lake
-21 Fourth Sector
-28 Kans Ferry
-35 Tol Harbor
-42 Gunston
-49 Fort Hollis
-56 Shield Mountains
-63 Sea of Glass
-70 Tannis Port
-
-80 Ramek
-83 Senna
-86 Radelix
-91 Arcturus
-94 Pelius
-96 Matrix
-98 Clavius
-
-
-Broadsword Class DD (3C21 - 3C51)
- 1............2............3............4............5............6............7............
-21 Broadsword Starknight Battleaxe Claymore Scimitar Saber Morningstar
-28 Truncheon Poleaxe Clovis Gladius Trident Lance Crossbow
-35 Warsign Warhammer Longbow Ironhelm Boneclaw Shield Longsword
-42 Quickbolt Kindjal Siege Mattock Runesword Blacknife Pike
-49 Scepter Icefang Rapier
-56 Firebolt Shortsword Joust Attack
-
-Volnaris Class DD (4D01 - 4D40)
-
-01 Alin Volnaris
-05 Pav Enke
-09 Pol Basilus
-13 Hal Rifa
-17 Kalas Gannet
-
-21 Senn Alon
-25 Jan Boma
-29 Tremel Isa
-33 Joran Kas
-37 Ambassador Ston
-
-02 Tol Branta
-06 Gol Duvain
-10 Jiri Sutton
-14 Famis Tett
-18 Hett Galinas
-22 Nova Sem
-
-26 Gray Lars - 4th fleet?
-30 Penn Sidus
-34 Savan Joss
-38 Kans Sefa
-03 Jael Pelorus
-07 Kel Masten
-
-11 Mos Antares
-15 Vin Silas
-19 Lieutentant Bolis
-23 Telen Setana
-27 Galen Teras
-31 Ro Hollis
-
-35 Tor Palver
-39 Rath Karalan
-04 Nels Berens
-08 Masil Korius
-12 Toran Elos
-16 Thule Arven
-
-20 Jes Kirta
-24 Loma Alta
-28 Merin Asgar
-32 Dian Soma
-36 Commander Sumas
-40 Bail Ennis
-
-45 Rik Eranes
-49 Senator Hasla
-
-51 Variak
-53 Talus
-55 Mindalante
-57 Manarkan
-59 Velan
-
-Imperial Class CA (5C44 - 5C73)
-44 Imperial Coronation Clavius Ascendance Marak I
-51 Marak II Imperator Overlord Throne Glory
-58 Principality Bennet Powerful Viceroy Regal Primacy
-65 Excellence Cleon I Marak IV Eminence Royale
-
-
-Vendetta Class CA (5D15 - 5D39)
-15 Vendetta Malice Wrath Rage Fury Menace Intruder
-22 Risk Hazard Peril Threat Exigency Attack Avalanche
-29 Assailant Raider Agressor Invader Retaliator Pursuit Darkness
-36 Silencer Punisher Vengeance xxxxxx Terror Dread Savage
-43 Hood Omega
-
-
-Dragon Class CVF (7A1 - 7A7)
- Dragon Serpent Gryphon Manticore Baldread Cyclops Argus Blackwing
-
-OTHERS
- Wasp Hornet Scorpion Deaths Head
- Wolf Cobra Viper Raptor Python
-
- Jackal Zodiac Scarab Sphinx Osiris
- Onyx Isis
-
- Bellerophon Hephaestus
-
- Tiger Panther Cougar Sea Lion Leopard Wildcat Jaguar
- Bengal Claw Lynx Ursa Orca Jackal White Lion
-
-
-Terellian Fleet Makeup
-----------------------
-
-1 carrier battle group
- 1 CVF + 60 Fighters + 8 LCAs
- 1 CG
- 2 DDK
-
-2 cruiser battle groups
- 1 CA
- 2 CG
- 1 DDK
-
-2 destroyer squadrons
- 2 DD
- 2 FF
-
-1 destroyer/escort squadron
- 2 DDK
- 2 FF
-
-
-
-Marakan Fleet Makeup
---------------------
-
-1 carrier battle group
- 1 CVF + 60 Fighters + 8 LCAs
- 2 DDK (Volnaris)
- 2 FF (Tiger Bay)
-
-2 cruiser battle groups
- 2 CA (Vendetta)
- 1 DDK (Volnaris)
- 1 FF (Tiger Bay)
-
-2 destroyer squadrons
- 2 DD (Broadsword)
- 2 FF (Tiger Bay)
-
-1 destroyer/escort squadron
- 2 DDK (Volnaris)
- 2 FF (Tiger Bay)
-
-
-==================== STARSHATTER ====================
- COMMERCIAL NAMES
-Ahime-Maru
-Boko-Maru
-Hikawa-Maru
-Hokko-Maru
-Junyo-Maru
-Kaijin-Maru
-Kankoh-Maru
-Komagata-Maru
-Koro-Maru
-Tankai-Maru
-Tenyo-Maru
-Yumigo-Maru
-
-Roika Adventure
-Roika Endurance
-Roika Mariner
-Roika Vantage
-Roika Wayfarer
-
-Roika Challenger
-Roika Explorer
-Roika Seeker
-Roika Viking
-Roika Wanderer
-
-Roika Discovery
-Roika Harvester
-Roika Sojourner
-Roika Voyager
-Roika Windward
-
-Chemstar One (through Twelve)
-
-
-==================== STARSHATTER ====================
- GALAXY : NAMES
-
- Adavan Alban Aram Aslan Athenar Avalon
- Borreal Borova Bryn
- Casalle Chi
- Dawn
- Eiller Elkhart
- Fenn
- Gaul Garden Garrison
- Haiche Hiro
- Ilon Isham
- Janek Jarnell
- Kala Khalife Kolchev Korius
- Lanos Loris
- Marak Muir
- Navara Nephrys Nergal
- Oleanne Omin Ostara
- Paragon Path Pirrin Pollus
- Relay Renser Ri Radix
- Senna Silessia Solus Suven
- Tal Amin Tarsus Theramin Thrale Trocanther
- Ur
- Vail Vesta Volante
- Warren Whorl
- Xanthe
- Zephyr Zoare
-
-
-
-==================== STARSHATTER ====================
- SECTOR : NAMES
-
-TERELLIAN ALLIANCE
- Jarnell
- Adonai
- Jarnell
- Caladan
- Dawn
-
- Borova
- Talistar
- Maraner
- Borova
- Danova
- Zhalisal
- Tulkas
-
- Athenar
- Athenar
- Pallas
-
- Paragon
- Dorrath
- Paragon
- Bryn
- Atlan
-
- Thralis
- Pollux
- Thrale
- Hera
- Zeus
- Sparta
-
- Janus
- Dante
- Janek Station
- Janek
- Alystra
- Navara
-
-INDEPENDENT SYSTEMS
- Solus
- Meridian
- Solus
- Telmera
- Omane
- Jalah
- Trellis
-
- Silessia
- Silessia
- Prosenar
- Vesta
- Nero
-
- Haiche
- Haiche
- Cygnus
- Tal Amin
- Kala
-
-MARAKAN SYSTEMS
- Renser
- Garana
- Rhomindal
- Renser
- Marisol
- Lornas
- Khaital
-
- Loris
- Duna
- Kaius
- Loris
- Casalle
-
- Ostara
- Aram
-
- Kolchev
- Ilya
- Kolchev
- Anatoly
- Volova
-
- Korius
- Moneta
- Korius
- Adantar
- Solnas
-
- Tarsus
- Tarsus
- Theramin
-
- Nephrys
- Nergal
-
- Radix
- Senna
- Radix
- Cavenda
-
- Isham
- Garden
- Senesca
- Rom
- Relay
-
- Garrison
- Garrison
-
- Trocanther
- Volante
- Narcissus
- Path
-
- Marakan
- Marak
- Xanthe
-
-
-==================== STARSHATTER ====================
- GALAXY : PLANET TYPES
-
- --= Landform Types =--
- Arid Desert (Arrakis)
- Frigid Desert (Mars)
- Frozen Exotic (Titan)
- Temperate Planar
- Temperate Mountainous
- Tropical Forest
- Tropical Oceanic
- Icy Oceanic (Scandinavia)
- Rocky Planar
- Rocky Mountainous
- Volcanic (Venus, Io)
- Barren (Pluto)
-
- --= Atmospheric Types =--
- Thin
- Clear, Breathable
- Dusty
- Foggy/Cloudy
- Dense Poisonous
- Layered
-
- --= Population Types =--
- Agrarian
- Industrial
- Mining
- Research/Technology
- Military
- Political
- Terraforming
-
-==================== STARSHATTER ====================
- GALAXY : RACES
-
- Human
- Terrelian Alliance
- Marakan Hegemony
-
- Ele'aan
-
- Zolon Empire
-
-
-==================== STARSHATTER ====================
- CAMPAIGN SEQUENCE
-
---- COLD WAR, LOW TENSION ---
-
-1) Training Center - Live Fire:
- JANEK SHIPYARD / HEPHAESTUS STATION
- Engage in "live fire" exercise with friendly
- units on the border of Hegemony territory.
-
---- COLD WAR, HIGH TENSION ---
-
-2) Highland:
- SOLUS(N) RENSER(H)
- An outlying Hegemony system is using terrorist
- tactics to gain control of a neighboring neutral star
- system to create "breathing room" between themselves
- and the Alliance. Drive out the terrorists and get the
- neutrals to sign a treaty with the Alliance.
-
-Quest Notes:
-* Restore free shipping by tracking down pirate base
- in asteroid field.
-* Terrorists have declared they will destroy prominent
- landmarks or assets in the system, stop them.
-* Find the terrorist base.
-* Protect local officials on a tour of afflicted areas.
-* Demonstrate Hegemony involvement by tracking down
- Renser military ships supporting the terrorists.
-* Establish a no-fly zone around a vulnerable space
- station.
-* Deliver humanitarian assistance to a station or city
- that has been attacked by the terrorists.
-* Some kind of covert op in the Renser system - spy
- insertion and/or recovery or hostage extraction.
-* Evacuate wounded civilians from an attacked station
- or city.
-
-3) Freedom Fighters:
- HAICHE(H)
- Hegemony taxation policy has driven an outlying
- system to resort to despotism to collect needed
- revenue. A group of local freedom fighters is
- attempting to overthrow the Hegemony backed govt.
- Aid the locals in driving out Hegemony forces.
-
---- OPEN WARFARE ---
-
-In response to campaign 3, the Hegemony formally
-declares war on the Alliance.
-
-4) Shining Fortress:
- JARNELL BOROVA ATHENAR
- The Hegemony has struck three Alliance systems,
- but they have not yet had time to fortify their
- position. Drive out the enemy forces, and
- protect Alliance citizens and assets in the area.
-
-5) Firestorm:
- OSTARA ARAM KOLCHEV KORIUS TARSUS LORIS NEPHRYS NERGAL
- Alliance Force:Command is planning a major offensive
- against the core Hegemony systems. This operation
- is to strike major war production and ship yards
- to weaken the Hegemony resistance before the
- main offensive.
-
-6) Nightfall:
- MARAKAN ISHAM GARRISON TROCANTHER
- Climactic operation against the enemy home system.
- Discovery that the Hegemony worlds have been overrun
- by the Zolon Empire.
-
---- ALIEN STRIFE ---
-
-7) Fatal Spear
- Alliance forces attack the Zolon border worlds
-
-8) Iron Mountain
- THRALIS PARAGON
- Zolon counter-attack, defense of the remaining
- core Alliance worlds
-
-9) No Refuge
- Purge of Zolon Royal Breeding Colonies
-
-
-==================== STARSHATTER ====================
- COMBAT SEQUENCE
-
-Each campaign will include a set of combat sequences
-for each combatant. The combat sequences will guide
-mission generation and statistical simulation, as well
-as providing supporting background fiction in the form
-of news items, intel reports, directives from Command,
-and game-rendered movie scripts/clips.
-
-
+
+==================== STARSHATTER ====================
+ STRATEGY
+
+Although Starshatter is fundamentally an action title,
+there is also a significant back-story and strategic
+element to the gameplay.
+
+The game occurs in a far-distant future of the Milky
+Way galaxy. Our corner of the galaxy, an area some
+ten or twenty thousand light years in diameter is popu-
+lated by thousands of human-intelligent species on tens
+of thousands of worlds. Many races live in approximate
+isolation, but most are organized into complex poly-
+specific civilizations spanning many star systems.
+Humans are not central in galactic affairs (as in Star
+Trek or Star Wars) but are merely another species. And
+some of the other species and civilizations are *much*
+older and *much* more advanced than ours.
+
+
+POLITICAL FACTIONS:
+
+- Starshatter (warlike/imperial power)
+
+* Sterat Empire (controlled by the Starshatter)
+
+* Brenel Core (military/intelligence corporation)
+
+* Zolon Empire (hive-like hereditary empire)
+
+* Marakan Hegemony (Failing human imperial civilization)
+
+* Terellian Alliance (peaceful commerce group)
+ Alliance of Terellian Republics (ATR)
+
++ Ele'aan Fusion (peaceful/isolationist power)
+
+The player is a human starfighter pilot in the military
+of one such civilization, the Terellian Alliance or ATR.
+The computer plays the part of the player's superior
+officers in assigning missions and offering criticism
+and praise for performance. In addition, the computer
+plays the role of all enemy pilots and politicians.
+
+The game follows the action in an interstellar conflict
+between the Terellian Alliance and those civilizations in
+the control of the Starshatter. The player is assigned
+missions and ships commensurate with his ability by the
+computer.
+
+==================== STARSHATTER ====================
+ MISSIONS
+
+Each of the three episodes follows the action in a military
+campaign against a single enemy civilization. Individual
+missions will be constructed on the fly by the dynamic
+campaign manager (or by the player if acting as operational
+commander).
+
+Each episode takes place in a fixed volume of space con-
+taining about a dozen star systems. The global campaign
+map will treat the star systems as points in a 2D map.
+The action will take place within individual star systems,
+which use a finer grained map. The enemy will control
+most of the star systems, although a few will be neutral,
+allied, or controlled by the player's faction. These may
+need to be defended if the enemy is able to incur.
+
+Rather than being "mission based", Starshatter is an
+"operational simulation". Each campaign episode is
+broken down into a series of military operations, each
+of which occur in a given star system. Different opera-
+tions will have different rules of engagement and victory
+conditions. Some will require the player to secure a
+neutral or allied star system from hostile threats.
+Others will involve incursion into hostile territory.
+Still others will have more limited objectives, such
+as securing a friendly position in a neutral system,
+without violating neutral airspace or damaging neutral
+assets.
+
+Major resources such as space stations, ship yards,
+SAM and sensor sites will be part of the fixed universe
+design. Likewise, the initial number, type, and location
+of warships is fixed at design time. It is hoped that
+the combination of large numbers of ships and small
+random factors (battle outcome, planetary position,
+time of attack) will result in increased variety of
+enounter for the player.
+
+During the game, the campaign manager must keep track
+of the location and make-up of each ship and battle group.
+As each ship is destroyed in battle, it must be removed
+(permanently) from play. New ships and battle groups
+can be constructed on each side, at a rate dependent
+on how many critical resources the side controls. In
+addition, reserves may be advanced from rearward areas
+to support an operation.
+
+For each mission, the computer will assemble a mission
+profile by selecting one or more objectives, selecting
+a location for the battle, and assigning friendly and
+enemy forces. The computer can choose randomly from
+among the nearby resources to attack (or defend) and
+the nearby ships on both sides to fight.
+
+Missions will be generated in accordance with the current
+strategic objectives for the operation. The dynamic
+campaign manager will keep a prioritized list of
+strategic objectives, mostly related to major fixed
+resources.
+
+Before the battle, the player will be given a gene-
+rated mission briefing describing the mission objec-
+tives, locale, and the makeup of his own group.
+
+Once the player completes the mission (or loses it),
+the computer will tally up the losses on both sides
+and remove those ships from the campaign roster. A
+generated mission debriefing will detail kills and
+losses, pilot ratings, etc.
+
+In order to keep the player doing something interesting,
+he will have to be assigned to an attack force, either
+a battle group or fighter wing. Early missions will be
+shorter and simpler, with a single objective in a
+single system. Later missions will get more involved,
+with multiple objectives and sometimes requiring free
+drive travel to other systems. In addition, the com-
+plexity of missions will be modulated by the user's
+chosen difficulty level.
+
+Sometimes, the objectives will be enemy forces: e.g.
+destroy a fighter wing or cripple a battle group.
+Other times, they will be fixed resources like space
+stations or fortified moons. Still other times, they
+will be distributed or moving targets: e.g. shut down
+interplanetary shipping throughout the system.
+
+At any time, the player's group may get assigned to
+a defensive mission (scramble). This can mean defending
+a fixed resource from an incoming enemy attack. Or it
+could mean escorting an important freight convey through
+unsecured space.
+
+Mission objectives can be constructed from verb-noun
+imperatives:
+
+ Verb List Object List
+ ---------------- -----------------
+ Intercept Ship
+ Shadow Group of Ships
+ Escort
+ Defend
+
+ Strike Space Station
+ Capture
+ Blockade
+ Defend
+
+ Recon Ship, building, or station
+ Jam
+ Designate
+
+ Launch From Starship or Station
+ Dock With
+ Dock/Rearm/Launch
+
+ Clear Mine Field / Satellite Grid
+ Deploy
+
+ Go To Location
+ Patrol
+ Hold At
+
+
+==================== STARSHATTER ====================
+ INTERFACE
+
+SCREEN CONCEPTS:
+
+-----------------------------------------------------
+Main Menu
+-----------------------------------------------------
+
+ New Game
+ Continue Game
+ Quick Mission
+ Training
+
+ Player Info (callsign, difficulty level, stats)
+ Game Options (controls, audio-video settings)
+
+ Help!
+ Exit
+
+-----------------------------------------------------
+Help Menu
+-----------------------------------------------------
+
+ Online Manual
+ Keymap
+ About...
+ Credits
+
+-----------------------------------------------------
+Operational Command
+-----------------------------------------------------
+
+ Operation Name, Date, Status
+ ----
+ Orders (overview of operation)
+ Theater (system map showing resources)
+ Strat Plan (edit objective list)
+ Intel Rpt (news feed)
+ Status (current score, us vs. them)
+
+ - missions -
+ Active ## (current mission list)
+ Pending ## (missions in prep)
+ Scramble ## (inbound threat list)
+
+ Commit (engage current mission)
+ Cancel (back to main menu)
+
+ Also need controls to navigate the maps, and
+ control visual clutter.
+
+ [May want to offer simpler versions of this
+ screen for "Starship Command" and "Fighter
+ Command", allowing the player to focus on
+ combat simulation rather than strategy.]
+
+-----------------------------------------------------
+Mission Planning
+-----------------------------------------------------
+
+ Briefing Data (scrolling text and images)
+ Mission Title
+ Objective List
+ Force Package
+ package callsign
+ wingmen and loadout
+ Annotated Flight Plan
+ launch time
+ nav points and events
+ time on target
+ Intel Report
+ expected counterforce
+ degree of confidence
+
+ Package (select wingmen)
+ Loadout (select weapons)
+ Nav Map (edit nav points)
+ Targets (assign objectives to flights)
+
+ Commit (engage current mission)
+ Cancel (back to previous screen)
+
+ [NOTE: same screen can double as Alert Intercept
+ by changing the title and removing the edit buttons]
+
+
+==================== STARSHATTER ====================
+ TRAINING
+
+Training Missions (both services)
+
+1. Basic Flight and Navigation
+2. Guns
+3. Missiles
+4. Combat Maneuver
+5. Sensors / Stealth
+6. Wingman Interface
+7. Long Range Scan
+8. Tactical Navigation and Waypoint Setting
+9. Advanced Tactics
+ a. Starship Assault (fighter weapon school)
+ b. Cruise missiles & Flight Ops (fleet tactical school)
+10. Situation Awareness (Final Exam)
+
+
+=======================================================
+ MISCELLANIA
+
+Sensor ships and stations will be important resources in
+winning the information war. Both the player and the AI
+will need to exploit and protect them appropriately.
+
+Briefings/Debriefings and other Intelligence Reports
+must adequately communicate the overall game situation
+to the player in order to allow the player to make
+meaningful decisions. This is crucial to establishing
+immersion and making the player care about the outcome
+of the game.
+
+Briefings and Info Bursts will be more visceral if they
+include simulated "news footage" of the events being
+related.
+
+
+=======================================================
+ DYNAMIC CAMPAIGN NOTES
+
+1. Fighter jocks will be allowed to choose from a
+ menu of generated missions that have been assigned
+ to the player's squadron.
+
+2. Cruiser skippers will be given only one generated
+ mission at a time (like KA or SFC), but it will be
+ somewhat broader in scope.
+
+3. Carrier admirals will do what exactly?
+
+4. Both cruiser and carrier missions will often start
+ in the field or on patrol. Fighter missions will
+ always start and end at a base (carrier|station|
+ dirtside starbase).
+
+5. Cruiser and carrier missions will not normally
+ include the starsender translation to the area of
+ conflict. The player will only go through the
+ sender in real time as part of a mission (not as
+ prelude or ending to a mission).
+
+6. Admirals will need to be able to generate orders
+ for their forces during the battle. This implies
+ some kind of Op Command workstation.
+
+7. The mission planner algorithm must construct
+ generated missions that are "fun", not just logical
+ to the campaign. I have a vague notion of using
+ time/distance heuristics to place enemy units as
+ "challenges" on the battle field. e.g. For xxx
+ type of mission, place an enemy destroyer yyy
+ minutes away from the (player|objective|sender).
+
+8. The generated missions do not have to hang together
+ as well as previously planned. That is, we don't
+ need to maintain the feeling that the player is just
+ a unit in an RTS game. Instead, the campaign manager
+ is just a device for generating interesting single
+ player missions as would be found in any game with
+ a static campaign.
+
+ On the other hand, the player should not see any
+ obvious contradictions between the big board and
+ what occurred during their missions. That means,
+ any kills they witnessed must still be visible
+ between missions in the intel report/event log.
+
+
+=======================================================
+ SHIP NAMES
+
+--- TERELLIAN SHIP NAMES ---
+
+F-32 Falcon Squadrons
+ Tigers Bearcats Avengers Windriders Wizards Warriors Aces
+
+F-36C Stormhawk Squadrons
+ Nighthawks Mustangs Stallions Chargers Hunters Broncos Trailblazers
+
+F/A-38D Talon Squadrons
+ Starknights Lancers Warbirds Razorbacks Rangers Sabres Kings
+
+
+Berents Class FF (922 - 951) 924
+ 1............2............3............4............5............6............7............
+22 Berents Bosporus Belfast Bering Dalton Surrey Halston
+27 Clarkeston Carlisle Canton Davis Delmar Kent Portsmouth
+32 Darvon Leyte Hemmet Messina Morgan Durham Bristol
+37 Avalon Argiles Essex Nalu Normandy Kingston Oxford
+42 Malory Parker Rainier Kelvin Nellis Saratoga Columbia
+47 Sorrel Suffolk Tanner Trieste Wolfram Broome Orleans
+
+Asher Class DDK (708 - 737) 710
+08 Asher Ryan Gerson Reynolds Nordic Vernor Arthur
+13 Shaw Card Simmons Hawker Hughes Nichols Smith
+18 Vance Gibson Raven Hale Salas Hoffman Parks
+23 Douglas Mahan Brunner Weber Smith Deforest Standish
+28 Robinson Clarke Gerrond Gamma Roberts Bear Drayton
+33 Keller Jackson Radix Lawrence Rand Chance Cavanaugh
+
+Spectre Class DD (350 - 395) 352
+50 Spectre Wraith Shadow Warlock Phantom
+55 Charon Nemesis Necromancer Merlin Nightshade
+60 Morlock Demon Hydra Typhon Enigma
+65 Phantasm Revenant Banshee Chimaera Gorgon
+70 Nightmare Darkmage Ogre Chaos Death's Head
+75 Ghola Efrite Ettin Incubus Secret Fire
+80 Siren Cerberus Mantis Orknies Fell Hunter
+85 Warspite Fire Angel Silence Mysterious Flame of Gorath
+90 Centaur Minotaur Dark Spirit Aegis Void Walker
+
+Courageous Class CG (521 - 545)
+ 1............2............3............4............5............6............7............
+21 Courageous Fearless Stalwart Defender Guardian Loyalty Forthright
+26 Steadfast Assurance Protector Heroic Valiant Justice Honesty
+31 Dauntless Vanguard Redstone Victorious Honorable Truth Gallantry
+36 Braveheart Defiant Audacious Valorous Confident Response Resolve
+41 Integrity Capable Fortitude Intrepid Virtuous Daring Bold
+
+Devastator Class CA (400 - 419)
+00 Devastator Annihilator Onslaught Relentless Furious Stormwind Demolisher
+05 --------- Thunder Hurricane Inferno Torrent Typhoon Shrike
+10 ------- Vortex Predator Ravager
+15 Havoc Scourge Huntress Warrior
+
+Orion Class CVF
+ Orion Antares Archon Titan Hyperion Atlas Hercules
+ Chronos Poseidon Cygnus
+
+--- MARAKAN SHIP NAMES ---
+
+F-MK1 Viper Squadrons
+ Scorpions Dragons Hornets Sharks Demons Vipers Black Widows
+
+F-MK2 Razor Squadrons
+ Raptors Vultures Cougars Vandals Vigilantes Wolfpack Black Diamonds
+
+F-MK3 Cobra Squadrons
+ Avengers Vampires Lions Kestrels Ravens Bounty Hunters Panthers
+
+Baikal Class FF
+ Baikal Irkutsk Olkha Iskra Lebedinka
+ Meget Homutovo Ivanovka Yagat Kyren
+ Vasad Nasaly Letkes Dorog Pomoz
+ Lovo Kerta Nova Marcali Csorna
+ Bajna Vorka Setla Rodina Markov
+ Dolina Porac Tarnov Udel Karalon
+
+Tiger Bay Class FF
+ 1............2............3............4............5............6............7............
+
+01 Tiger Bay
+08 Southern Isles
+15 Hellas Point
+22 Iron Canyon
+29 Mount Teras
+36 Black River
+43 Guard Hills
+50 Gulf of Kirt
+57 Star Island
+64 Rodis Station
+
+02 Tarsus Pride
+09 Eternal City
+16 Kala Docks
+23 Outer Rim
+30 Kolchev
+37 Rock Ridge
+44 Aenia
+51 Boma Beach
+58 Falcrest
+65 Angel Shore
+
+03 Valley of Flame
+10 Leopard Ridge
+17 Kalis Basin
+24 Cape Nor
+31 Blue Forest
+38 Landfall
+45 Lake Orsan
+52 Wind River
+59 Tolan Locks
+66 Mount Zoare
+
+04 Silas Cave
+11 River Ceres
+18 Elkhorn Pass
+25 Port Hanson
+32 Oak Hall
+39 North Point
+46 Loris Dunes - not used
+53 Beacon Bay - not used
+60 Sand Canyon - not used
+67 Iron Mountain - not used
+
+05 Khaital
+12 Ash Hills
+19 Albus Gulf
+26 Siren Island
+33 Neptune Station
+40 Trocanther
+47 Night City
+54 Joran Docks
+61 Hunter Coast
+68 Nephrys
+
+06 Storm Island
+13 Orinoco
+20 Jewel Beach
+27 Knife Ridge
+34 Secret Shore
+41 Crown of Fire
+48 Hilger Coast
+55 Sword Cliffs
+62 Capetown
+69 Smoke Forest
+
+07 Blackrock
+14 Sutton Lake
+21 Fourth Sector
+28 Kans Ferry
+35 Tol Harbor
+42 Gunston
+49 Fort Hollis
+56 Shield Mountains
+63 Sea of Glass
+70 Tannis Port
+
+80 Ramek
+83 Senna
+86 Radelix
+91 Arcturus
+94 Pelius
+96 Matrix
+98 Clavius
+
+
+Broadsword Class DD (3C21 - 3C51)
+ 1............2............3............4............5............6............7............
+21 Broadsword Starknight Battleaxe Claymore Scimitar Saber Morningstar
+28 Truncheon Poleaxe Clovis Gladius Trident Lance Crossbow
+35 Warsign Warhammer Longbow Ironhelm Boneclaw Shield Longsword
+42 Quickbolt Kindjal Siege Mattock Runesword Blacknife Pike
+49 Scepter Icefang Rapier
+56 Firebolt Shortsword Joust Attack
+
+Volnaris Class DD (4D01 - 4D40)
+
+01 Alin Volnaris
+05 Pav Enke
+09 Pol Basilus
+13 Hal Rifa
+17 Kalas Gannet
+
+21 Senn Alon
+25 Jan Boma
+29 Tremel Isa
+33 Joran Kas
+37 Ambassador Ston
+
+02 Tol Branta
+06 Gol Duvain
+10 Jiri Sutton
+14 Famis Tett
+18 Hett Galinas
+22 Nova Sem
+
+26 Gray Lars - 4th fleet?
+30 Penn Sidus
+34 Savan Joss
+38 Kans Sefa
+03 Jael Pelorus
+07 Kel Masten
+
+11 Mos Antares
+15 Vin Silas
+19 Lieutentant Bolis
+23 Telen Setana
+27 Galen Teras
+31 Ro Hollis
+
+35 Tor Palver
+39 Rath Karalan
+04 Nels Berens
+08 Masil Korius
+12 Toran Elos
+16 Thule Arven
+
+20 Jes Kirta
+24 Loma Alta
+28 Merin Asgar
+32 Dian Soma
+36 Commander Sumas
+40 Bail Ennis
+
+45 Rik Eranes
+49 Senator Hasla
+
+51 Variak
+53 Talus
+55 Mindalante
+57 Manarkan
+59 Velan
+
+Imperial Class CA (5C44 - 5C73)
+44 Imperial Coronation Clavius Ascendance Marak I
+51 Marak II Imperator Overlord Throne Glory
+58 Principality Bennet Powerful Viceroy Regal Primacy
+65 Excellence Cleon I Marak IV Eminence Royale
+
+
+Vendetta Class CA (5D15 - 5D39)
+15 Vendetta Malice Wrath Rage Fury Menace Intruder
+22 Risk Hazard Peril Threat Exigency Attack Avalanche
+29 Assailant Raider Agressor Invader Retaliator Pursuit Darkness
+36 Silencer Punisher Vengeance xxxxxx Terror Dread Savage
+43 Hood Omega
+
+
+Dragon Class CVF (7A1 - 7A7)
+ Dragon Serpent Gryphon Manticore Baldread Cyclops Argus Blackwing
+
+OTHERS
+ Wasp Hornet Scorpion Deaths Head
+ Wolf Cobra Viper Raptor Python
+
+ Jackal Zodiac Scarab Sphinx Osiris
+ Onyx Isis
+
+ Bellerophon Hephaestus
+
+ Tiger Panther Cougar Sea Lion Leopard Wildcat Jaguar
+ Bengal Claw Lynx Ursa Orca Jackal White Lion
+
+
+Terellian Fleet Makeup
+----------------------
+
+1 carrier battle group
+ 1 CVF + 60 Fighters + 8 LCAs
+ 1 CG
+ 2 DDK
+
+2 cruiser battle groups
+ 1 CA
+ 2 CG
+ 1 DDK
+
+2 destroyer squadrons
+ 2 DD
+ 2 FF
+
+1 destroyer/escort squadron
+ 2 DDK
+ 2 FF
+
+
+
+Marakan Fleet Makeup
+--------------------
+
+1 carrier battle group
+ 1 CVF + 60 Fighters + 8 LCAs
+ 2 DDK (Volnaris)
+ 2 FF (Tiger Bay)
+
+2 cruiser battle groups
+ 2 CA (Vendetta)
+ 1 DDK (Volnaris)
+ 1 FF (Tiger Bay)
+
+2 destroyer squadrons
+ 2 DD (Broadsword)
+ 2 FF (Tiger Bay)
+
+1 destroyer/escort squadron
+ 2 DDK (Volnaris)
+ 2 FF (Tiger Bay)
+
+
+==================== STARSHATTER ====================
+ COMMERCIAL NAMES
+Ahime-Maru
+Boko-Maru
+Hikawa-Maru
+Hokko-Maru
+Junyo-Maru
+Kaijin-Maru
+Kankoh-Maru
+Komagata-Maru
+Koro-Maru
+Tankai-Maru
+Tenyo-Maru
+Yumigo-Maru
+
+Roika Adventure
+Roika Endurance
+Roika Mariner
+Roika Vantage
+Roika Wayfarer
+
+Roika Challenger
+Roika Explorer
+Roika Seeker
+Roika Viking
+Roika Wanderer
+
+Roika Discovery
+Roika Harvester
+Roika Sojourner
+Roika Voyager
+Roika Windward
+
+Chemstar One (through Twelve)
+
+
+==================== STARSHATTER ====================
+ GALAXY : NAMES
+
+ Adavan Alban Aram Aslan Athenar Avalon
+ Borreal Borova Bryn
+ Casalle Chi
+ Dawn
+ Eiller Elkhart
+ Fenn
+ Gaul Garden Garrison
+ Haiche Hiro
+ Ilon Isham
+ Janek Jarnell
+ Kala Khalife Kolchev Korius
+ Lanos Loris
+ Marak Muir
+ Navara Nephrys Nergal
+ Oleanne Omin Ostara
+ Paragon Path Pirrin Pollus
+ Relay Renser Ri Radix
+ Senna Silessia Solus Suven
+ Tal Amin Tarsus Theramin Thrale Trocanther
+ Ur
+ Vail Vesta Volante
+ Warren Whorl
+ Xanthe
+ Zephyr Zoare
+
+
+
+==================== STARSHATTER ====================
+ SECTOR : NAMES
+
+TERELLIAN ALLIANCE
+ Jarnell
+ Adonai
+ Jarnell
+ Caladan
+ Dawn
+
+ Borova
+ Talistar
+ Maraner
+ Borova
+ Danova
+ Zhalisal
+ Tulkas
+
+ Athenar
+ Athenar
+ Pallas
+
+ Paragon
+ Dorrath
+ Paragon
+ Bryn
+ Atlan
+
+ Thralis
+ Pollux
+ Thrale
+ Hera
+ Zeus
+ Sparta
+
+ Janus
+ Dante
+ Janek Station
+ Janek
+ Alystra
+ Navara
+
+INDEPENDENT SYSTEMS
+ Solus
+ Meridian
+ Solus
+ Telmera
+ Omane
+ Jalah
+ Trellis
+
+ Silessia
+ Silessia
+ Prosenar
+ Vesta
+ Nero
+
+ Haiche
+ Haiche
+ Cygnus
+ Tal Amin
+ Kala
+
+MARAKAN SYSTEMS
+ Renser
+ Garana
+ Rhomindal
+ Renser
+ Marisol
+ Lornas
+ Khaital
+
+ Loris
+ Duna
+ Kaius
+ Loris
+ Casalle
+
+ Ostara
+ Aram
+
+ Kolchev
+ Ilya
+ Kolchev
+ Anatoly
+ Volova
+
+ Korius
+ Moneta
+ Korius
+ Adantar
+ Solnas
+
+ Tarsus
+ Tarsus
+ Theramin
+
+ Nephrys
+ Nergal
+
+ Radix
+ Senna
+ Radix
+ Cavenda
+
+ Isham
+ Garden
+ Senesca
+ Rom
+ Relay
+
+ Garrison
+ Garrison
+
+ Trocanther
+ Volante
+ Narcissus
+ Path
+
+ Marakan
+ Marak
+ Xanthe
+
+
+==================== STARSHATTER ====================
+ GALAXY : PLANET TYPES
+
+ --= Landform Types =--
+ Arid Desert (Arrakis)
+ Frigid Desert (Mars)
+ Frozen Exotic (Titan)
+ Temperate Planar
+ Temperate Mountainous
+ Tropical Forest
+ Tropical Oceanic
+ Icy Oceanic (Scandinavia)
+ Rocky Planar
+ Rocky Mountainous
+ Volcanic (Venus, Io)
+ Barren (Pluto)
+
+ --= Atmospheric Types =--
+ Thin
+ Clear, Breathable
+ Dusty
+ Foggy/Cloudy
+ Dense Poisonous
+ Layered
+
+ --= Population Types =--
+ Agrarian
+ Industrial
+ Mining
+ Research/Technology
+ Military
+ Political
+ Terraforming
+
+==================== STARSHATTER ====================
+ GALAXY : RACES
+
+ Human
+ Terrelian Alliance
+ Marakan Hegemony
+
+ Ele'aan
+
+ Zolon Empire
+
+
+==================== STARSHATTER ====================
+ CAMPAIGN SEQUENCE
+
+--- COLD WAR, LOW TENSION ---
+
+1) Training Center - Live Fire:
+ JANEK SHIPYARD / HEPHAESTUS STATION
+ Engage in "live fire" exercise with friendly
+ units on the border of Hegemony territory.
+
+--- COLD WAR, HIGH TENSION ---
+
+2) Highland:
+ SOLUS(N) RENSER(H)
+ An outlying Hegemony system is using terrorist
+ tactics to gain control of a neighboring neutral star
+ system to create "breathing room" between themselves
+ and the Alliance. Drive out the terrorists and get the
+ neutrals to sign a treaty with the Alliance.
+
+Quest Notes:
+* Restore free shipping by tracking down pirate base
+ in asteroid field.
+* Terrorists have declared they will destroy prominent
+ landmarks or assets in the system, stop them.
+* Find the terrorist base.
+* Protect local officials on a tour of afflicted areas.
+* Demonstrate Hegemony involvement by tracking down
+ Renser military ships supporting the terrorists.
+* Establish a no-fly zone around a vulnerable space
+ station.
+* Deliver humanitarian assistance to a station or city
+ that has been attacked by the terrorists.
+* Some kind of covert op in the Renser system - spy
+ insertion and/or recovery or hostage extraction.
+* Evacuate wounded civilians from an attacked station
+ or city.
+
+3) Freedom Fighters:
+ HAICHE(H)
+ Hegemony taxation policy has driven an outlying
+ system to resort to despotism to collect needed
+ revenue. A group of local freedom fighters is
+ attempting to overthrow the Hegemony backed govt.
+ Aid the locals in driving out Hegemony forces.
+
+--- OPEN WARFARE ---
+
+In response to campaign 3, the Hegemony formally
+declares war on the Alliance.
+
+4) Shining Fortress:
+ JARNELL BOROVA ATHENAR
+ The Hegemony has struck three Alliance systems,
+ but they have not yet had time to fortify their
+ position. Drive out the enemy forces, and
+ protect Alliance citizens and assets in the area.
+
+5) Firestorm:
+ OSTARA ARAM KOLCHEV KORIUS TARSUS LORIS NEPHRYS NERGAL
+ Alliance Force:Command is planning a major offensive
+ against the core Hegemony systems. This operation
+ is to strike major war production and ship yards
+ to weaken the Hegemony resistance before the
+ main offensive.
+
+6) Nightfall:
+ MARAKAN ISHAM GARRISON TROCANTHER
+ Climactic operation against the enemy home system.
+ Discovery that the Hegemony worlds have been overrun
+ by the Zolon Empire.
+
+--- ALIEN STRIFE ---
+
+7) Fatal Spear
+ Alliance forces attack the Zolon border worlds
+
+8) Iron Mountain
+ THRALIS PARAGON
+ Zolon counter-attack, defense of the remaining
+ core Alliance worlds
+
+9) No Refuge
+ Purge of Zolon Royal Breeding Colonies
+
+
+==================== STARSHATTER ====================
+ COMBAT SEQUENCE
+
+Each campaign will include a set of combat sequences
+for each combatant. The combat sequences will guide
+mission generation and statistical simulation, as well
+as providing supporting background fiction in the form
+of news items, intel reports, directives from Command,
+and game-rendered movie scripts/clips.
+
+
diff --git a/Doc/TASK.TXT b/Doc/Task.txt
index c0dc2ca..939cac2 100644
--- a/Doc/TASK.TXT
+++ b/Doc/Task.txt
@@ -1,380 +1,380 @@
-STARSHATTER TASK LIST AND SCHEDULE
-
-AUGUST 1997
-
-1 Magic Enhancements
- * modify poly (finish)
- * triangulate poly
- * remove degenerate polys (fewer than 3 distinct verts)
- * scale selection
- * rotate selection
- * primitives (sphere, cylinder, cone)
-
-SEPTEMBER 1997
-
-1 Magic Enhancements
- * texture mapping
- * new test ship designs and textures
- + stabilization (bug fixing)
-
-1 Low-level AI (idle / attack / reverse / evade)
- * Auto-bank on turn
- * 2 AI fighters attacking each other
- * 1+ AI fighters attacking the player
-
-1 Flocking AI
- * Collision Avoidance
- * Seek Target
- * Flee, Avoid object
- * Evade Threat
- * Drop/re-acquire target
- * Fire control based on Projected Silhouette
- * Readiness (speed multiplier, likelihood of fire)
-
-1 Combat results (damage to resources/ships)
- * Fix sprite animation rate
- + Shields
- * Explosions / Flashes / Particles
- * Ship-to-ship collisions
- * Impulse from collisions and shots
-
-1 Compound data file and asset manager
- * including zlib compression
-
- Misc.
- * test mode
- * respawn
- * gaea texture generator
-
-OCTOBER 1997
-
-1 Sound
- * Ambient Sound Effects
- * 3D Sound Effects
- + Streamed Sound (e.g. voice over)
-
-1 Renderer Architecture
- * get rid of span buffer (CamView, SpanBuff)
- * get rid of poly id and key (Geometry)
- * single clipped polygon
- * no more clipped_verts in poly (Geometry)
- * ClipPoly just before ProjectPoly (CamView)
- * Clip from source poly into dest poly (CamClip)
- * fixed overhead of 16 verts in vertex set (Solid::Allocate)
- * colored lights
- * directional backlighting
- * z-scaling for 3Dfx
- * snapshot of D3D frame buffer (not working on 3Dfx?)
- * remove Span pointer from poly
-
-1 Memory Leak Debugging
- * MemDebug class
-
-1 Idle (schedule slip)
- Played Wing Commander 3 and Darklight Conflict a bit
- Thought a lot about game design
- Learned to use Photoshop
-
-NOVEMBER 1997
-
-1 Renderer Architecture
- * move texture indices from vertex to poly (Geometry)
- * modify nGen to support new formats
-
-1 Misc.
- * Polygon-accurate shot-intersection
- * Translucent shield bubble
- * Improved laser graphics
- * Target "Pickle"
-
-1 Combat
- * seeker missiles
- * missile cam
- * smooth camera zoom
- * improved ship collision logic
- * physical vibration
-
-DECEMBER 1997
-
-1 Misc.
- * Lens flare occlusion
- * improved collision avoidance AI
- * improved seeker AI
- * ship physics for missile carrying and launch
- o starfield texture in sw (tried and removed: too slow)
-
-1 Misc.
- * additional sounds (engines, shot-impact)
- * 3Dfx bug fixes
- * upgraded data archiver
- * planetary rings
- * clipping/zooming bug fixes
- * simple ultra-drive
-
-1 Collision Detection
- * RAPID Collision detection
-
-JANUARY 1998
-
-1 Misc.
- * polygon properties (e.g. flat-shaded, transparent)
- * bridge cam
- * independent agility parameters
- * LOD clipping of graphics
- - LOD model support for ships and planets
-
-1 Key/joystick button mapper
- * define key codes for actions and load from file
- - GUI support for mapping keys within the game
-
-1 Weapon Aiming AI
- * Improved missile graphics
- * Load weapon/shot parameters from data file
- * Handle slow charging / variable charge cap ship guns
- * Compute deflection vector to lead target
-
-FEBRUARY
- * completed font designer
- * designed HUD font
- * basic button control
- * basic form class
- * improved collision avoidance AI
- * physical modeling - vibration
- * improved shield graphics
-
-MARCH
- * simple padlock view
- * improved gaea planetary texture
- * fixed planet texture mapping defects
- * multi-quality bitmaps
- * use 8-bit texture format in hardware, when available
- * power management and multiple reactors
- * HUD view
- * 2D cockpit view
-
- HUD enhancements
- * IFF color indications
- * markers for distant contacts
- * weapon range bar
- * mode indicator
- * fullscreen mode for external cameras
-
- Guns and Missiles
- * weapon selection (G for guns, M for missiles?)
- * weapon range indicator
- * chase vector indicator
- * missile lock
- + missile track/lock graphic and audio cue
-
-APRIL
- Misc
- * HUD display off
- * HUD color/brightness
- * Doppler shift and distance roll off
- * Orient theater/padlock views to world coordinates
- * AI roll to orient with world coordinates (y+ is up)
- * Fighter AI: roll+pitch instead of yaw
-
- Sensor/Scanner and Emission Control
- * passive and active sensors
- - manual emcon
- - environmental sensor efficiency
-
-MAY
- Misc
- * joystick configuration
- * performance tuning (clip vertex set in view space)
- * (x,y,z) translation thrusters
- * movable external camera (rotate, zoom, center on object)
- * "enhanced" two-frequency doppler effect
-
- Tactical Situation MFD
- * properly clipped 3D grid
- * contact info for each contact
- * tactical hud
- * cycle view object
- ? clipped circles indicating target weapon range
-
- Magic Enhancements
- * optional second texture and flag set per polygon
- * specular highlight flag
- * two-pass texture rendering in nGen (sw and d3d)
-
- Combat Results
- * System Damage Combat Results
- * particle burst/trail for severe system damage
- * caution and warning panel
- - target damage feedback
- - vocal warning system
-
- System Damage Modeling
- * avionics HUD/NAV degradation
- * attitude stabilizer
- - attitude control
- - throttle control
- - sensor weapon aiming control
-
-JUNE
- Combat Enhancements
- - subsystem targeting for starship targets
- - AA turrets on starships
- - mines and/or gunpods
- - long range weapon types
-
-JULY
- Simulation and Navigation
- * star system modeling
- * orbital mechanics
- * navigation map
- * autonav ai
- * hyperdrive navigation
- * improved planetary texture mapping
-
-AUGUST
- Operational Simulation and Navigation
- * performance optimization for large fleets
- * enhanced hyperdrive auto nav ai
- * animated hyperspace effects
- * new navigation mfd design
- * starship fire control mfd
-
- Misc
- * improved plasma trail effect
- * corrected rendering of large grids
- * improved performance of button control
- * fixed lighting and lens flare bugs
- * improved star shell texture mapping
-
-SEPTEMBER
- Operational Simulation
- * fire control mfd
- * weapon firing orders
- * flight deck modeling
- * flight deck control (recover/launch ships)
- * created starship ai
- * improved fighter evasion techniques
- * starship point defense
-
- Graphics and Collision Detection
- * fixed specular highlighting
- * fixed collision matrix
- * removed collision resolution for fighter/fighter
- * render planetary atmosphere
- * improved planet generator
-
-OCTOBER
- Operational Simulation
- - air tasking orders, manual order assignment
- - starship ai threat assessment, targetting and navigation
- - starship ai flight deck control
- - time skip, including combat resolution
- - hyperspatial navigation
- - packages, cooperation, formations, orders
- - communications and squadron commands
-
-----------------------------(unscheduled)------------------------------------
-
- Other HUD Modes
- - IDS (docking)
- - RHAW
- - MAW
-
- Misc
- - reactor power level control
- - planet craters
-
- Bug List
- * faceting (flat-shading) in D3D
- * nebula sky invisible during fade in
- * specular highlights visible during fade in
- * show missile count in HUD
- * correct ship class determination
- * improve fighter steering behavior
- * extraneous keys on startup
- - sound memory leak
- - sound dropouts
-
- Auto Pilots
- - match velocity
- - form up
- - approach
- - dock
-
-? DX6 DrawPrimitive support
-
-2 Mid/High level AI
- - strategy and tactics
- - stealth and detection
- - morale simulation
- - difficulty settings
-
-2 Docking and Resupply
-
-1 Ship model parts
- - additional ship designs
- - solid model loading using surfaces for sub parts
- - Complex explosions for composite ships
-
-1 Fonts (including alpha blended anti-aliased)
-
-1 GUI logic / real menu tree
-
-8+ Final ship designs
-1 Final weapon designs
-
-1 Death-spiral Animations
-
-2 Special Effects
- + Shields
- + Hyperspace
- - Starshatter and other Big Explosions
- - Shock waves, weapon trails
- * Planetary Rings
-
-1 Wingman command interface
-
-2 Cockpit designs
-
-1 Other External Views
- + theater view
- + padlock
- - rear view
- - (looping) flyby
-
-2 Save/Restore Game
-
-2 Galaxy Design
-2 Planet, moon, and starfield textures
-2 Campaign Logic
-? Mission Design
-1 Mission Objectives Representation
-
-1 Promotions / Scoring
-1 Mission Briefing System
-1 Animation Cutscene System
-1 Strategic Briefing Data and Design
-
-? Info Database and Help content
- User's Manual
-
-2 Sound Effects Production
- - Foley editing
-
-1 Music
- - Midi or digital audio streaming
-
-3 Music Production
- - Composition and recording
-
- High quality renderer for Magic
- - phong shading
- - multiple colored light sources with shadows
- * double precision z buffer
- - very high resolution (1280 x 960)
- - high polygon count
-
-
-(possibles)
-
-1 WinGlide support for 3Dfx?
-
+STARSHATTER TASK LIST AND SCHEDULE
+
+AUGUST 1997
+
+1 Magic Enhancements
+ * modify poly (finish)
+ * triangulate poly
+ * remove degenerate polys (fewer than 3 distinct verts)
+ * scale selection
+ * rotate selection
+ * primitives (sphere, cylinder, cone)
+
+SEPTEMBER 1997
+
+1 Magic Enhancements
+ * texture mapping
+ * new test ship designs and textures
+ + stabilization (bug fixing)
+
+1 Low-level AI (idle / attack / reverse / evade)
+ * Auto-bank on turn
+ * 2 AI fighters attacking each other
+ * 1+ AI fighters attacking the player
+
+1 Flocking AI
+ * Collision Avoidance
+ * Seek Target
+ * Flee, Avoid object
+ * Evade Threat
+ * Drop/re-acquire target
+ * Fire control based on Projected Silhouette
+ * Readiness (speed multiplier, likelihood of fire)
+
+1 Combat results (damage to resources/ships)
+ * Fix sprite animation rate
+ + Shields
+ * Explosions / Flashes / Particles
+ * Ship-to-ship collisions
+ * Impulse from collisions and shots
+
+1 Compound data file and asset manager
+ * including zlib compression
+
+ Misc.
+ * test mode
+ * respawn
+ * gaea texture generator
+
+OCTOBER 1997
+
+1 Sound
+ * Ambient Sound Effects
+ * 3D Sound Effects
+ + Streamed Sound (e.g. voice over)
+
+1 Renderer Architecture
+ * get rid of span buffer (CamView, SpanBuff)
+ * get rid of poly id and key (Geometry)
+ * single clipped polygon
+ * no more clipped_verts in poly (Geometry)
+ * ClipPoly just before ProjectPoly (CamView)
+ * Clip from source poly into dest poly (CamClip)
+ * fixed overhead of 16 verts in vertex set (Solid::Allocate)
+ * colored lights
+ * directional backlighting
+ * z-scaling for 3Dfx
+ * snapshot of D3D frame buffer (not working on 3Dfx?)
+ * remove Span pointer from poly
+
+1 Memory Leak Debugging
+ * MemDebug class
+
+1 Idle (schedule slip)
+ Played Wing Commander 3 and Darklight Conflict a bit
+ Thought a lot about game design
+ Learned to use Photoshop
+
+NOVEMBER 1997
+
+1 Renderer Architecture
+ * move texture indices from vertex to poly (Geometry)
+ * modify nGen to support new formats
+
+1 Misc.
+ * Polygon-accurate shot-intersection
+ * Translucent shield bubble
+ * Improved laser graphics
+ * Target "Pickle"
+
+1 Combat
+ * seeker missiles
+ * missile cam
+ * smooth camera zoom
+ * improved ship collision logic
+ * physical vibration
+
+DECEMBER 1997
+
+1 Misc.
+ * Lens flare occlusion
+ * improved collision avoidance AI
+ * improved seeker AI
+ * ship physics for missile carrying and launch
+ o starfield texture in sw (tried and removed: too slow)
+
+1 Misc.
+ * additional sounds (engines, shot-impact)
+ * 3Dfx bug fixes
+ * upgraded data archiver
+ * planetary rings
+ * clipping/zooming bug fixes
+ * simple ultra-drive
+
+1 Collision Detection
+ * RAPID Collision detection
+
+JANUARY 1998
+
+1 Misc.
+ * polygon properties (e.g. flat-shaded, transparent)
+ * bridge cam
+ * independent agility parameters
+ * LOD clipping of graphics
+ - LOD model support for ships and planets
+
+1 Key/joystick button mapper
+ * define key codes for actions and load from file
+ - GUI support for mapping keys within the game
+
+1 Weapon Aiming AI
+ * Improved missile graphics
+ * Load weapon/shot parameters from data file
+ * Handle slow charging / variable charge cap ship guns
+ * Compute deflection vector to lead target
+
+FEBRUARY
+ * completed font designer
+ * designed HUD font
+ * basic button control
+ * basic form class
+ * improved collision avoidance AI
+ * physical modeling - vibration
+ * improved shield graphics
+
+MARCH
+ * simple padlock view
+ * improved gaea planetary texture
+ * fixed planet texture mapping defects
+ * multi-quality bitmaps
+ * use 8-bit texture format in hardware, when available
+ * power management and multiple reactors
+ * HUD view
+ * 2D cockpit view
+
+ HUD enhancements
+ * IFF color indications
+ * markers for distant contacts
+ * weapon range bar
+ * mode indicator
+ * fullscreen mode for external cameras
+
+ Guns and Missiles
+ * weapon selection (G for guns, M for missiles?)
+ * weapon range indicator
+ * chase vector indicator
+ * missile lock
+ + missile track/lock graphic and audio cue
+
+APRIL
+ Misc
+ * HUD display off
+ * HUD color/brightness
+ * Doppler shift and distance roll off
+ * Orient theater/padlock views to world coordinates
+ * AI roll to orient with world coordinates (y+ is up)
+ * Fighter AI: roll+pitch instead of yaw
+
+ Sensor/Scanner and Emission Control
+ * passive and active sensors
+ - manual emcon
+ - environmental sensor efficiency
+
+MAY
+ Misc
+ * joystick configuration
+ * performance tuning (clip vertex set in view space)
+ * (x,y,z) translation thrusters
+ * movable external camera (rotate, zoom, center on object)
+ * "enhanced" two-frequency doppler effect
+
+ Tactical Situation MFD
+ * properly clipped 3D grid
+ * contact info for each contact
+ * tactical hud
+ * cycle view object
+ ? clipped circles indicating target weapon range
+
+ Magic Enhancements
+ * optional second texture and flag set per polygon
+ * specular highlight flag
+ * two-pass texture rendering in nGen (sw and d3d)
+
+ Combat Results
+ * System Damage Combat Results
+ * particle burst/trail for severe system damage
+ * caution and warning panel
+ - target damage feedback
+ - vocal warning system
+
+ System Damage Modeling
+ * avionics HUD/NAV degradation
+ * attitude stabilizer
+ - attitude control
+ - throttle control
+ - sensor weapon aiming control
+
+JUNE
+ Combat Enhancements
+ - subsystem targeting for starship targets
+ - AA turrets on starships
+ - mines and/or gunpods
+ - long range weapon types
+
+JULY
+ Simulation and Navigation
+ * star system modeling
+ * orbital mechanics
+ * navigation map
+ * autonav ai
+ * hyperdrive navigation
+ * improved planetary texture mapping
+
+AUGUST
+ Operational Simulation and Navigation
+ * performance optimization for large fleets
+ * enhanced hyperdrive auto nav ai
+ * animated hyperspace effects
+ * new navigation mfd design
+ * starship fire control mfd
+
+ Misc
+ * improved plasma trail effect
+ * corrected rendering of large grids
+ * improved performance of button control
+ * fixed lighting and lens flare bugs
+ * improved star shell texture mapping
+
+SEPTEMBER
+ Operational Simulation
+ * fire control mfd
+ * weapon firing orders
+ * flight deck modeling
+ * flight deck control (recover/launch ships)
+ * created starship ai
+ * improved fighter evasion techniques
+ * starship point defense
+
+ Graphics and Collision Detection
+ * fixed specular highlighting
+ * fixed collision matrix
+ * removed collision resolution for fighter/fighter
+ * render planetary atmosphere
+ * improved planet generator
+
+OCTOBER
+ Operational Simulation
+ - air tasking orders, manual order assignment
+ - starship ai threat assessment, targetting and navigation
+ - starship ai flight deck control
+ - time skip, including combat resolution
+ - hyperspatial navigation
+ - packages, cooperation, formations, orders
+ - communications and squadron commands
+
+----------------------------(unscheduled)------------------------------------
+
+ Other HUD Modes
+ - IDS (docking)
+ - RHAW
+ - MAW
+
+ Misc
+ - reactor power level control
+ - planet craters
+
+ Bug List
+ * faceting (flat-shading) in D3D
+ * nebula sky invisible during fade in
+ * specular highlights visible during fade in
+ * show missile count in HUD
+ * correct ship class determination
+ * improve fighter steering behavior
+ * extraneous keys on startup
+ - sound memory leak
+ - sound dropouts
+
+ Auto Pilots
+ - match velocity
+ - form up
+ - approach
+ - dock
+
+? DX6 DrawPrimitive support
+
+2 Mid/High level AI
+ - strategy and tactics
+ - stealth and detection
+ - morale simulation
+ - difficulty settings
+
+2 Docking and Resupply
+
+1 Ship model parts
+ - additional ship designs
+ - solid model loading using surfaces for sub parts
+ - Complex explosions for composite ships
+
+1 Fonts (including alpha blended anti-aliased)
+
+1 GUI logic / real menu tree
+
+8+ Final ship designs
+1 Final weapon designs
+
+1 Death-spiral Animations
+
+2 Special Effects
+ + Shields
+ + Hyperspace
+ - Starshatter and other Big Explosions
+ - Shock waves, weapon trails
+ * Planetary Rings
+
+1 Wingman command interface
+
+2 Cockpit designs
+
+1 Other External Views
+ + theater view
+ + padlock
+ - rear view
+ - (looping) flyby
+
+2 Save/Restore Game
+
+2 Galaxy Design
+2 Planet, moon, and starfield textures
+2 Campaign Logic
+? Mission Design
+1 Mission Objectives Representation
+
+1 Promotions / Scoring
+1 Mission Briefing System
+1 Animation Cutscene System
+1 Strategic Briefing Data and Design
+
+? Info Database and Help content
+ User's Manual
+
+2 Sound Effects Production
+ - Foley editing
+
+1 Music
+ - Midi or digital audio streaming
+
+3 Music Production
+ - Composition and recording
+
+ High quality renderer for Magic
+ - phong shading
+ - multiple colored light sources with shadows
+ * double precision z buffer
+ - very high resolution (1280 x 960)
+ - high polygon count
+
+
+(possibles)
+
+1 WinGlide support for 3Dfx?
+
diff --git a/Doc/starshatter.Doxyfile b/Doc/starshatter.Doxyfile
deleted file mode 100644
index 0e2d041..0000000
--- a/Doc/starshatter.Doxyfile
+++ /dev/null
@@ -1,3438 +0,0 @@
-# Doxyfile 1.7.3
-
-# This file describes the settings to be used by the documentation system
-# doxygen (www.doxygen.org) for a project
-#
-# All text after a hash (#) is considered a comment and will be ignored
-# The format is:
-# TAG = value [value, ...]
-# For lists items can also be appended using:
-# TAG += value [value, ...]
-# Values that contain spaces should be placed between quotes (" ")
-
-#---------------------------------------------------------------------------
-# Project related configuration options
-#---------------------------------------------------------------------------
-
-# This tag specifies the encoding used for all characters in the config file
-# that follow. The default is UTF-8 which is also the encoding used for all
-# text before the first occurrence of this tag. Doxygen uses libiconv (or the
-# iconv built into libc) for the transcoding. See
-# http://www.gnu.org/software/libiconv for the list of possible encodings.
-
-DOXYFILE_ENCODING = UTF-8
-
-# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
-# by quotes) that should identify the project.
-
-PROJECT_NAME = Starshatter_Open
-
-# The PROJECT_NUMBER tag can be used to enter a project or revision number.
-# This could be handy for archiving the generated documentation or
-# if some version control system is used.
-
-PROJECT_NUMBER =
-
-# Using the PROJECT_BRIEF tag one can provide an optional one line description
-# for a project that appears at the top of each page and should give viewer
-# a quick idea about the purpose of the project. Keep the description short.
-
-PROJECT_BRIEF = "Open source Starshatter engine"
-
-# With the PROJECT_LOGO tag one can specify an logo or icon that is
-# included in the documentation. The maximum height of the logo should not
-# exceed 55 pixels and the maximum width should not exceed 200 pixels.
-# Doxygen will copy the logo to the output directory.
-
-PROJECT_LOGO =
-
-# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
-# base path where the generated documentation will be put.
-# If a relative path is entered, it will be relative to the location
-# where doxygen was started. If left blank the current directory will be used.
-
-OUTPUT_DIRECTORY = doxygen
-
-# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
-# 4096 sub-directories (in 2 levels) under the output directory of each output
-# format and will distribute the generated files over these directories.
-# Enabling this option can be useful when feeding doxygen a huge amount of
-# source files, where putting all generated files in the same directory would
-# otherwise cause performance problems for the file system.
-
-CREATE_SUBDIRS = NO
-
-# The OUTPUT_LANGUAGE tag is used to specify the language in which all
-# documentation generated by doxygen is written. Doxygen will use this
-# information to generate all constant output in the proper language.
-# The default language is English, other supported languages are:
-# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
-# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
-# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
-# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
-# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak,
-# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.
-
-OUTPUT_LANGUAGE = English
-
-# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
-# include brief member descriptions after the members that are listed in
-# the file and class documentation (similar to JavaDoc).
-# Set to NO to disable this.
-
-BRIEF_MEMBER_DESC = YES
-
-# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
-# the brief description of a member or function before the detailed description.
-# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
-# brief descriptions will be completely suppressed.
-
-REPEAT_BRIEF = YES
-
-# This tag implements a quasi-intelligent brief description abbreviator
-# that is used to form the text in various listings. Each string
-# in this list, if found as the leading text of the brief description, will be
-# stripped from the text and the result after processing the whole list, is
-# used as the annotated text. Otherwise, the brief description is used as-is.
-# If left blank, the following values are used ("$name" is automatically
-# replaced with the name of the entity): "The $name class" "The $name widget"
-# "The $name file" "is" "provides" "specifies" "contains"
-# "represents" "a" "an" "the"
-
-ABBREVIATE_BRIEF = "The $name class" \
- "The $name widget" \
- "The $name file" \
- is \
- provides \
- specifies \
- contains \
- represents \
- a \
- an \
- the
-
-# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
-# Doxygen will generate a detailed section even if there is only a brief
-# description.
-
-ALWAYS_DETAILED_SEC = NO
-
-# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
-# inherited members of a class in the documentation of that class as if those
-# members were ordinary class members. Constructors, destructors and assignment
-# operators of the base classes will not be shown.
-
-INLINE_INHERITED_MEMB = NO
-
-# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
-# path before files name in the file list and in the header files. If set
-# to NO the shortest path that makes the file name unique will be used.
-
-FULL_PATH_NAMES = YES
-
-# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
-# can be used to strip a user-defined part of the path. Stripping is
-# only done if one of the specified strings matches the left-hand part of
-# the path. The tag can be used to show relative paths in the file list.
-# If left blank the directory from which doxygen is run is used as the
-# path to strip.
-
-STRIP_FROM_PATH =
-
-# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
-# the path mentioned in the documentation of a class, which tells
-# the reader which header file to include in order to use a class.
-# If left blank only the name of the header file containing the class
-# definition is used. Otherwise one should specify the include paths that
-# are normally passed to the compiler using the -I flag.
-
-STRIP_FROM_INC_PATH =
-
-# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
-# (but less readable) file names. This can be useful if your file system
-# doesn't support long names like on DOS, Mac, or CD-ROM.
-
-SHORT_NAMES = NO
-
-# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
-# will interpret the first line (until the first dot) of a JavaDoc-style
-# comment as the brief description. If set to NO, the JavaDoc
-# comments will behave just like regular Qt-style comments
-# (thus requiring an explicit @brief command for a brief description.)
-
-JAVADOC_AUTOBRIEF = NO
-
-# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
-# interpret the first line (until the first dot) of a Qt-style
-# comment as the brief description. If set to NO, the comments
-# will behave just like regular Qt-style comments (thus requiring
-# an explicit \brief command for a brief description.)
-
-QT_AUTOBRIEF = NO
-
-# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
-# treat a multi-line C++ special comment block (i.e. a block of //! or ///
-# comments) as a brief description. This used to be the default behaviour.
-# The new default is to treat a multi-line C++ comment block as a detailed
-# description. Set this tag to YES if you prefer the old behaviour instead.
-
-MULTILINE_CPP_IS_BRIEF = NO
-
-# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
-# member inherits the documentation from any documented member that it
-# re-implements.
-
-INHERIT_DOCS = YES
-
-# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
-# a new page for each member. If set to NO, the documentation of a member will
-# be part of the file/class/namespace that contains it.
-
-SEPARATE_MEMBER_PAGES = NO
-
-# The TAB_SIZE tag can be used to set the number of spaces in a tab.
-# Doxygen uses this value to replace tabs by spaces in code fragments.
-
-TAB_SIZE = 8
-
-# This tag can be used to specify a number of aliases that acts
-# as commands in the documentation. An alias has the form "name=value".
-# For example adding "sideeffect=\par Side Effects:\n" will allow you to
-# put the command \sideeffect (or @sideeffect) in the documentation, which
-# will result in a user-defined paragraph with heading "Side Effects:".
-# You can put \n's in the value part of an alias to insert newlines.
-
-ALIASES =
-
-# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
-# sources only. Doxygen will then generate output that is more tailored for C.
-# For instance, some of the names that are used will be different. The list
-# of all members will be omitted, etc.
-
-OPTIMIZE_OUTPUT_FOR_C = NO
-
-# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
-# sources only. Doxygen will then generate output that is more tailored for
-# Java. For instance, namespaces will be presented as packages, qualified
-# scopes will look different, etc.
-
-OPTIMIZE_OUTPUT_JAVA = NO
-
-# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
-# sources only. Doxygen will then generate output that is more tailored for
-# Fortran.
-
-OPTIMIZE_FOR_FORTRAN = NO
-
-# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
-# sources. Doxygen will then generate output that is tailored for
-# VHDL.
-
-OPTIMIZE_OUTPUT_VHDL = NO
-
-# Doxygen selects the parser to use depending on the extension of the files it
-# parses. With this tag you can assign which parser to use for a given extension.
-# Doxygen has a built-in mapping, but you can override or extend it using this
-# tag. The format is ext=language, where ext is a file extension, and language
-# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
-# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
-# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
-# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
-# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
-
-EXTENSION_MAPPING =
-
-# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
-# to include (a tag file for) the STL sources as input, then you should
-# set this tag to YES in order to let doxygen match functions declarations and
-# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
-# func(std::string) {}). This also makes the inheritance and collaboration
-# diagrams that involve STL classes more complete and accurate.
-
-BUILTIN_STL_SUPPORT = NO
-
-# If you use Microsoft's C++/CLI language, you should set this option to YES to
-# enable parsing support.
-
-CPP_CLI_SUPPORT = NO
-
-# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
-# Doxygen will parse them like normal C++ but will assume all classes use public
-# instead of private inheritance when no explicit protection keyword is present.
-
-SIP_SUPPORT = NO
-
-# For Microsoft's IDL there are propget and propput attributes to indicate getter
-# and setter methods for a property. Setting this option to YES (the default)
-# will make doxygen replace the get and set methods by a property in the
-# documentation. This will only work if the methods are indeed getting or
-# setting a simple type. If this is not the case, or you want to show the
-# methods anyway, you should set this option to NO.
-
-IDL_PROPERTY_SUPPORT = YES
-
-# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
-# tag is set to YES, then doxygen will reuse the documentation of the first
-# member in the group (if any) for the other members of the group. By default
-# all members of a group must be documented explicitly.
-
-DISTRIBUTE_GROUP_DOC = NO
-
-# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
-# the same type (for instance a group of public functions) to be put as a
-# subgroup of that type (e.g. under the Public Functions section). Set it to
-# NO to prevent subgrouping. Alternatively, this can be done per class using
-# the \nosubgrouping command.
-
-SUBGROUPING = YES
-
-# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
-# is documented as struct, union, or enum with the name of the typedef. So
-# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
-# with name TypeT. When disabled the typedef will appear as a member of a file,
-# namespace, or class. And the struct will be named TypeS. This can typically
-# be useful for C code in case the coding convention dictates that all compound
-# types are typedef'ed and only the typedef is referenced, never the tag name.
-
-TYPEDEF_HIDES_STRUCT = NO
-
-# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
-# determine which symbols to keep in memory and which to flush to disk.
-# When the cache is full, less often used symbols will be written to disk.
-# For small to medium size projects (<1000 input files) the default value is
-# probably good enough. For larger projects a too small cache size can cause
-# doxygen to be busy swapping symbols to and from disk most of the time
-# causing a significant performance penalty.
-# If the system has enough physical memory increasing the cache will improve the
-# performance by keeping more symbols in memory. Note that the value works on
-# a logarithmic scale so increasing the size by one will roughly double the
-# memory usage. The cache size is given by this formula:
-# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
-# corresponding to a cache size of 2^16 = 65536 symbols
-
-SYMBOL_CACHE_SIZE = 0
-
-#---------------------------------------------------------------------------
-# Build related configuration options
-#---------------------------------------------------------------------------
-
-# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
-# documentation are documented, even if no documentation was available.
-# Private class members and static file members will be hidden unless
-# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
-
-EXTRACT_ALL = YES
-
-# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
-# will be included in the documentation.
-
-EXTRACT_PRIVATE = NO
-
-# If the EXTRACT_STATIC tag is set to YES all static members of a file
-# will be included in the documentation.
-
-EXTRACT_STATIC = NO
-
-# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
-# defined locally in source files will be included in the documentation.
-# If set to NO only classes defined in header files are included.
-
-EXTRACT_LOCAL_CLASSES = YES
-
-# This flag is only useful for Objective-C code. When set to YES local
-# methods, which are defined in the implementation section but not in
-# the interface are included in the documentation.
-# If set to NO (the default) only methods in the interface are included.
-
-EXTRACT_LOCAL_METHODS = NO
-
-# If this flag is set to YES, the members of anonymous namespaces will be
-# extracted and appear in the documentation as a namespace called
-# 'anonymous_namespace{file}', where file will be replaced with the base
-# name of the file that contains the anonymous namespace. By default
-# anonymous namespaces are hidden.
-
-EXTRACT_ANON_NSPACES = NO
-
-# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
-# undocumented members of documented classes, files or namespaces.
-# If set to NO (the default) these members will be included in the
-# various overviews, but no documentation section is generated.
-# This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_MEMBERS = NO
-
-# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
-# undocumented classes that are normally visible in the class hierarchy.
-# If set to NO (the default) these classes will be included in the various
-# overviews. This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_CLASSES = NO
-
-# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
-# friend (class|struct|union) declarations.
-# If set to NO (the default) these declarations will be included in the
-# documentation.
-
-HIDE_FRIEND_COMPOUNDS = NO
-
-# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
-# documentation blocks found inside the body of a function.
-# If set to NO (the default) these blocks will be appended to the
-# function's detailed documentation block.
-
-HIDE_IN_BODY_DOCS = NO
-
-# The INTERNAL_DOCS tag determines if documentation
-# that is typed after a \internal command is included. If the tag is set
-# to NO (the default) then the documentation will be excluded.
-# Set it to YES to include the internal documentation.
-
-INTERNAL_DOCS = NO
-
-# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
-# file names in lower-case letters. If set to YES upper-case letters are also
-# allowed. This is useful if you have classes or files whose names only differ
-# in case and if your file system supports case sensitive file names. Windows
-# and Mac users are advised to set this option to NO.
-
-CASE_SENSE_NAMES = NO
-
-# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
-# will show members with their full class and namespace scopes in the
-# documentation. If set to YES the scope will be hidden.
-
-HIDE_SCOPE_NAMES = NO
-
-# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
-# will put a list of the files that are included by a file in the documentation
-# of that file.
-
-SHOW_INCLUDE_FILES = YES
-
-# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen
-# will list include files with double quotes in the documentation
-# rather than with sharp brackets.
-
-FORCE_LOCAL_INCLUDES = NO
-
-# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
-# is inserted in the documentation for inline members.
-
-INLINE_INFO = YES
-
-# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
-# will sort the (detailed) documentation of file and class members
-# alphabetically by member name. If set to NO the members will appear in
-# declaration order.
-
-SORT_MEMBER_DOCS = YES
-
-# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
-# brief documentation of file, namespace and class members alphabetically
-# by member name. If set to NO (the default) the members will appear in
-# declaration order.
-
-SORT_BRIEF_DOCS = NO
-
-# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen
-# will sort the (brief and detailed) documentation of class members so that
-# constructors and destructors are listed first. If set to NO (the default)
-# the constructors will appear in the respective orders defined by
-# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS.
-# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
-# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
-
-SORT_MEMBERS_CTORS_1ST = NO
-
-# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
-# hierarchy of group names into alphabetical order. If set to NO (the default)
-# the group names will appear in their defined order.
-
-SORT_GROUP_NAMES = NO
-
-# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
-# sorted by fully-qualified names, including namespaces. If set to
-# NO (the default), the class list will be sorted only by class name,
-# not including the namespace part.
-# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
-# Note: This option applies only to the class list, not to the
-# alphabetical list.
-
-SORT_BY_SCOPE_NAME = NO
-
-# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to
-# do proper type resolution of all parameters of a function it will reject a
-# match between the prototype and the implementation of a member function even
-# if there is only one candidate or it is obvious which candidate to choose
-# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen
-# will still accept a match between prototype and implementation in such cases.
-
-STRICT_PROTO_MATCHING = NO
-
-# The GENERATE_TODOLIST tag can be used to enable (YES) or
-# disable (NO) the todo list. This list is created by putting \todo
-# commands in the documentation.
-
-GENERATE_TODOLIST = YES
-
-# The GENERATE_TESTLIST tag can be used to enable (YES) or
-# disable (NO) the test list. This list is created by putting \test
-# commands in the documentation.
-
-GENERATE_TESTLIST = YES
-
-# The GENERATE_BUGLIST tag can be used to enable (YES) or
-# disable (NO) the bug list. This list is created by putting \bug
-# commands in the documentation.
-
-GENERATE_BUGLIST = YES
-
-# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
-# disable (NO) the deprecated list. This list is created by putting
-# \deprecated commands in the documentation.
-
-GENERATE_DEPRECATEDLIST= YES
-
-# The ENABLED_SECTIONS tag can be used to enable conditional
-# documentation sections, marked by \if sectionname ... \endif.
-
-ENABLED_SECTIONS =
-
-# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
-# the initial value of a variable or macro consists of for it to appear in
-# the documentation. If the initializer consists of more lines than specified
-# here it will be hidden. Use a value of 0 to hide initializers completely.
-# The appearance of the initializer of individual variables and macros in the
-# documentation can be controlled using \showinitializer or \hideinitializer
-# command in the documentation regardless of this setting.
-
-MAX_INITIALIZER_LINES = 30
-
-# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
-# at the bottom of the documentation of classes and structs. If set to YES the
-# list will mention the files that were used to generate the documentation.
-
-SHOW_USED_FILES = YES
-
-# If the sources in your project are distributed over multiple directories
-# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
-# in the documentation. The default is NO.
-
-SHOW_DIRECTORIES = NO
-
-# Set the SHOW_FILES tag to NO to disable the generation of the Files page.
-# This will remove the Files entry from the Quick Index and from the
-# Folder Tree View (if specified). The default is YES.
-
-SHOW_FILES = YES
-
-# Set the SHOW_NAMESPACES tag to NO to disable the generation of the
-# Namespaces page. This will remove the Namespaces entry from the Quick Index
-# and from the Folder Tree View (if specified). The default is YES.
-
-SHOW_NAMESPACES = YES
-
-# The FILE_VERSION_FILTER tag can be used to specify a program or script that
-# doxygen should invoke to get the current version for each file (typically from
-# the version control system). Doxygen will invoke the program by executing (via
-# popen()) the command <command> <input-file>, where <command> is the value of
-# the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file
-# provided by doxygen. Whatever the program writes to standard output
-# is used as the file version. See the manual for examples.
-
-FILE_VERSION_FILTER =
-
-# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
-# by doxygen. The layout file controls the global structure of the generated
-# output files in an output format independent way. The create the layout file
-# that represents doxygen's defaults, run doxygen with the -l option.
-# You can optionally specify a file name after the option, if omitted
-# DoxygenLayout.xml will be used as the name of the layout file.
-
-LAYOUT_FILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to warning and progress messages
-#---------------------------------------------------------------------------
-
-# The QUIET tag can be used to turn on/off the messages that are generated
-# by doxygen. Possible values are YES and NO. If left blank NO is used.
-
-QUIET = NO
-
-# The WARNINGS tag can be used to turn on/off the warning messages that are
-# generated by doxygen. Possible values are YES and NO. If left blank
-# NO is used.
-
-WARNINGS = YES
-
-# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
-# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
-# automatically be disabled.
-
-WARN_IF_UNDOCUMENTED = YES
-
-# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
-# potential errors in the documentation, such as not documenting some
-# parameters in a documented function, or documenting parameters that
-# don't exist or using markup commands wrongly.
-
-WARN_IF_DOC_ERROR = YES
-
-# The WARN_NO_PARAMDOC option can be enabled to get warnings for
-# functions that are documented, but have no documentation for their parameters
-# or return value. If set to NO (the default) doxygen will only warn about
-# wrong or incomplete parameter documentation, but not about the absence of
-# documentation.
-
-WARN_NO_PARAMDOC = NO
-
-# The WARN_FORMAT tag determines the format of the warning messages that
-# doxygen can produce. The string should contain the $file, $line, and $text
-# tags, which will be replaced by the file and line number from which the
-# warning originated and the warning text. Optionally the format may contain
-# $version, which will be replaced by the version of the file (if it could
-# be obtained via FILE_VERSION_FILTER)
-
-WARN_FORMAT = "$file:$line: $text"
-
-# The WARN_LOGFILE tag can be used to specify a file to which warning
-# and error messages should be written. If left blank the output is written
-# to stderr.
-
-WARN_LOGFILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the input files
-#---------------------------------------------------------------------------
-
-# The INPUT tag can be used to specify the files and/or directories that contain
-# documented source files. You may enter file names like "myfile.cpp" or
-# directories like "/usr/src/myproject". Separate the files or directories
-# with spaces.
-
-INPUT = ../FoundationEx ../Magic2 ../NetEx ../nGenEx ../Parser ../Stars45
-
-# This tag can be used to specify the character encoding of the source files
-# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
-# also the default input encoding. Doxygen uses libiconv (or the iconv built
-# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
-# the list of possible encodings.
-
-INPUT_ENCODING = UTF-8
-
-# If the value of the INPUT tag contains directories, you can use the
-# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank the following patterns are tested:
-# *.c *.cc *.cxx *.cpp *.c++ *.d *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh
-# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py
-# *.f90 *.f *.for *.vhd *.vhdl
-
-FILE_PATTERNS = *.c \
- *.cc \
- *.cxx \
- *.cpp \
- *.c++ \
- *.d \
- *.java \
- *.ii \
- *.ixx \
- *.ipp \
- *.i++ \
- *.inl \
- *.h \
- *.hh \
- *.hxx \
- *.hpp \
- *.h++ \
- *.idl \
- *.odl \
- *.cs \
- *.php \
- *.php3 \
- *.inc \
- *.m \
- *.mm \
- *.dox \
- *.py \
- *.f90 \
- *.f \
- *.for \
- *.vhd \
- *.vhdl
-
-# The RECURSIVE tag can be used to turn specify whether or not subdirectories
-# should be searched for input files as well. Possible values are YES and NO.
-# If left blank NO is used.
-
-RECURSIVE = YES
-
-# The EXCLUDE tag can be used to specify files and/or directories that should
-# excluded from the INPUT source files. This way you can easily exclude a
-# subdirectory from a directory tree whose root is specified with the INPUT tag.
-
-EXCLUDE =
-
-# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
-# directories that are symbolic links (a Unix file system feature) are excluded
-# from the input.
-
-EXCLUDE_SYMLINKS = NO
-
-# If the value of the INPUT tag contains directories, you can use the
-# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
-# certain files from those directories. Note that the wildcards are matched
-# against the file with absolute path, so to exclude all test directories
-# for example use the pattern */test/*
-
-EXCLUDE_PATTERNS = */.svn/*
-
-# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
-# (namespaces, classes, functions, etc.) that should be excluded from the
-# output. The symbol name can be a fully qualified name, a word, or if the
-# wildcard * is used, a substring. Examples: ANamespace, AClass,
-# AClass::ANamespace, ANamespace::*Test
-
-EXCLUDE_SYMBOLS =
-
-# The EXAMPLE_PATH tag can be used to specify one or more files or
-# directories that contain example code fragments that are included (see
-# the \include command).
-
-EXAMPLE_PATH =
-
-# If the value of the EXAMPLE_PATH tag contains directories, you can use the
-# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank all files are included.
-
-EXAMPLE_PATTERNS = *
-
-# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
-# searched for input files to be used with the \include or \dontinclude
-# commands irrespective of the value of the RECURSIVE tag.
-# Possible values are YES and NO. If left blank NO is used.
-
-EXAMPLE_RECURSIVE = NO
-
-# The IMAGE_PATH tag can be used to specify one or more files or
-# directories that contain image that are included in the documentation (see
-# the \image command).
-
-IMAGE_PATH =
-
-# The INPUT_FILTER tag can be used to specify a program that doxygen should
-# invoke to filter for each input file. Doxygen will invoke the filter program
-# by executing (via popen()) the command <filter> <input-file>, where <filter>
-# is the value of the INPUT_FILTER tag, and <input-file> is the name of an
-# input file. Doxygen will then use the output that the filter program writes
-# to standard output. If FILTER_PATTERNS is specified, this tag will be
-# ignored.
-
-INPUT_FILTER =
-
-# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
-# basis. Doxygen will compare the file name with each pattern and apply the
-# filter if there is a match. The filters are a list of the form:
-# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
-# info on how filters are used. If FILTER_PATTERNS is empty or if
-# non of the patterns match the file name, INPUT_FILTER is applied.
-
-FILTER_PATTERNS =
-
-# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
-# INPUT_FILTER) will be used to filter the input files when producing source
-# files to browse (i.e. when SOURCE_BROWSER is set to YES).
-
-FILTER_SOURCE_FILES = NO
-
-# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
-# pattern. A pattern will override the setting for FILTER_PATTERN (if any)
-# and it is also possible to disable source filtering for a specific pattern
-# using *.ext= (so without naming a filter). This option only has effect when
-# FILTER_SOURCE_FILES is enabled.
-
-FILTER_SOURCE_PATTERNS =
-
-#---------------------------------------------------------------------------
-# configuration options related to source browsing
-#---------------------------------------------------------------------------
-
-# If the SOURCE_BROWSER tag is set to YES then a list of source files will
-# be generated. Documented entities will be cross-referenced with these sources.
-# Note: To get rid of all source code in the generated output, make sure also
-# VERBATIM_HEADERS is set to NO.
-
-SOURCE_BROWSER = YES
-
-# Setting the INLINE_SOURCES tag to YES will include the body
-# of functions and classes directly in the documentation.
-
-INLINE_SOURCES = NO
-
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
-# doxygen to hide any special comment blocks from generated source code
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS = YES
-
-# If the REFERENCED_BY_RELATION tag is set to YES
-# then for each documented function all documented
-# functions referencing it will be listed.
-
-REFERENCED_BY_RELATION = NO
-
-# If the REFERENCES_RELATION tag is set to YES
-# then for each documented function all documented entities
-# called/used by that function will be listed.
-
-REFERENCES_RELATION = NO
-
-# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
-# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
-# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
-# link to the source code. Otherwise they will link to the documentation.
-
-REFERENCES_LINK_SOURCE = YES
-
-# If the USE_HTAGS tag is set to YES then the references to source code
-# will point to the HTML generated by the htags(1) tool instead of doxygen
-# built-in source browser. The htags tool is part of GNU's global source
-# tagging system (see http://www.gnu.org/software/global/global.html). You
-# will need version 4.8.6 or higher.
-
-USE_HTAGS = NO
-
-# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
-# will generate a verbatim copy of the header file for each class for
-# which an include is specified. Set to NO to disable this.
-
-VERBATIM_HEADERS = YES
-
-#---------------------------------------------------------------------------
-# configuration options related to the alphabetical class index
-#---------------------------------------------------------------------------
-
-# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
-# of all compounds will be generated. Enable this if the project
-# contains a lot of classes, structs, unions or interfaces.
-
-ALPHABETICAL_INDEX = YES
-
-# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
-# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
-# in which this list will be split (can be a number in the range [1..20])
-
-COLS_IN_ALPHA_INDEX = 5
-
-# In case all classes in a project start with a common prefix, all
-# classes will be put under the same header in the alphabetical index.
-# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
-# should be ignored while generating the index headers.
-
-IGNORE_PREFIX =
-
-#---------------------------------------------------------------------------
-# configuration options related to the HTML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
-# generate HTML output.
-
-GENERATE_HTML = YES
-
-# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `html' will be used as the default path.
-
-HTML_OUTPUT = html
-
-# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
-# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
-# doxygen will generate files with .html extension.
-
-HTML_FILE_EXTENSION = .html
-
-# The HTML_HEADER tag can be used to specify a personal HTML header for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard header.
-
-HTML_HEADER =
-
-# The HTML_FOOTER tag can be used to specify a personal HTML footer for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard footer.
-
-HTML_FOOTER =
-
-# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
-# style sheet that is used by each HTML page. It can be used to
-# fine-tune the look of the HTML output. If the tag is left blank doxygen
-# will generate a default style sheet. Note that doxygen will try to copy
-# the style sheet file to the HTML output directory, so don't put your own
-# stylesheet in the HTML output directory as well, or it will be erased!
-
-HTML_STYLESHEET =
-
-# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
-# Doxygen will adjust the colors in the stylesheet and background images
-# according to this color. Hue is specified as an angle on a colorwheel,
-# see http://en.wikipedia.org/wiki/Hue for more information.
-# For instance the value 0 represents red, 60 is yellow, 120 is green,
-# 180 is cyan, 240 is blue, 300 purple, and 360 is red again.
-# The allowed range is 0 to 359.
-
-HTML_COLORSTYLE_HUE = 220
-
-# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of
-# the colors in the HTML output. For a value of 0 the output will use
-# grayscales only. A value of 255 will produce the most vivid colors.
-
-HTML_COLORSTYLE_SAT = 100
-
-# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to
-# the luminance component of the colors in the HTML output. Values below
-# 100 gradually make the output lighter, whereas values above 100 make
-# the output darker. The value divided by 100 is the actual gamma applied,
-# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2,
-# and 100 does not change the gamma.
-
-HTML_COLORSTYLE_GAMMA = 80
-
-# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
-# page will contain the date and time when the page was generated. Setting
-# this to NO can help when comparing the output of multiple runs.
-
-HTML_TIMESTAMP = YES
-
-# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
-# files or namespaces will be aligned in HTML using tables. If set to
-# NO a bullet list will be used.
-
-HTML_ALIGN_MEMBERS = YES
-
-# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
-# documentation will contain sections that can be hidden and shown after the
-# page has loaded. For this to work a browser that supports
-# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
-# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
-
-HTML_DYNAMIC_SECTIONS = NO
-
-# If the GENERATE_DOCSET tag is set to YES, additional index files
-# will be generated that can be used as input for Apple's Xcode 3
-# integrated development environment, introduced with OSX 10.5 (Leopard).
-# To create a documentation set, doxygen will generate a Makefile in the
-# HTML output directory. Running make will produce the docset in that
-# directory and running "make install" will install the docset in
-# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
-# it at startup.
-# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
-# for more information.
-
-GENERATE_DOCSET = NO
-
-# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
-# feed. A documentation feed provides an umbrella under which multiple
-# documentation sets from a single provider (such as a company or product suite)
-# can be grouped.
-
-DOCSET_FEEDNAME = "Doxygen generated docs"
-
-# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
-# should uniquely identify the documentation set bundle. This should be a
-# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
-# will append .docset to the name.
-
-DOCSET_BUNDLE_ID = org.doxygen.Project
-
-# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
-# the documentation publisher. This should be a reverse domain-name style
-# string, e.g. com.mycompany.MyDocSet.documentation.
-
-DOCSET_PUBLISHER_ID = org.doxygen.Publisher
-
-# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher.
-
-DOCSET_PUBLISHER_NAME = Publisher
-
-# If the GENERATE_HTMLHELP tag is set to YES, additional index files
-# will be generated that can be used as input for tools like the
-# Microsoft HTML help workshop to generate a compiled HTML help file (.chm)
-# of the generated HTML documentation.
-
-GENERATE_HTMLHELP = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
-# be used to specify the file name of the resulting .chm file. You
-# can add a path in front of the file if the result should not be
-# written to the html output directory.
-
-CHM_FILE =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
-# be used to specify the location (absolute path including file name) of
-# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
-# the HTML help compiler on the generated index.hhp.
-
-HHC_LOCATION =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
-# controls if a separate .chi index file is generated (YES) or that
-# it should be included in the master .chm file (NO).
-
-GENERATE_CHI = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING
-# is used to encode HtmlHelp index (hhk), content (hhc) and project file
-# content.
-
-CHM_INDEX_ENCODING =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
-# controls whether a binary table of contents is generated (YES) or a
-# normal table of contents (NO) in the .chm file.
-
-BINARY_TOC = NO
-
-# The TOC_EXPAND flag can be set to YES to add extra items for group members
-# to the contents of the HTML help documentation and to the tree view.
-
-TOC_EXPAND = NO
-
-# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
-# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
-# that can be used as input for Qt's qhelpgenerator to generate a
-# Qt Compressed Help (.qch) of the generated HTML documentation.
-
-GENERATE_QHP = NO
-
-# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
-# be used to specify the file name of the resulting .qch file.
-# The path specified is relative to the HTML output folder.
-
-QCH_FILE =
-
-# The QHP_NAMESPACE tag specifies the namespace to use when generating
-# Qt Help Project output. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#namespace
-
-QHP_NAMESPACE = org.doxygen.Project
-
-# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
-# Qt Help Project output. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#virtual-folders
-
-QHP_VIRTUAL_FOLDER = doc
-
-# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
-# add. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#custom-filters
-
-QHP_CUST_FILTER_NAME =
-
-# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
-# custom filter to add. For more information please see
-# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">
-# Qt Help Project / Custom Filters</a>.
-
-QHP_CUST_FILTER_ATTRS =
-
-# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
-# project's
-# filter section matches.
-# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">
-# Qt Help Project / Filter Attributes</a>.
-
-QHP_SECT_FILTER_ATTRS =
-
-# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
-# be used to specify the location of Qt's qhelpgenerator.
-# If non-empty doxygen will try to run qhelpgenerator on the generated
-# .qhp file.
-
-QHG_LOCATION =
-
-# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
-# will be generated, which together with the HTML files, form an Eclipse help
-# plugin. To install this plugin and make it available under the help contents
-# menu in Eclipse, the contents of the directory containing the HTML and XML
-# files needs to be copied into the plugins directory of eclipse. The name of
-# the directory within the plugins directory should be the same as
-# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before
-# the help appears.
-
-GENERATE_ECLIPSEHELP = NO
-
-# A unique identifier for the eclipse help plugin. When installing the plugin
-# the directory name containing the HTML and XML files should also have
-# this name.
-
-ECLIPSE_DOC_ID = org.doxygen.Project
-
-# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
-# top of each HTML page. The value NO (the default) enables the index and
-# the value YES disables it.
-
-DISABLE_INDEX = NO
-
-# This tag can be used to set the number of enum values (range [0,1..20])
-# that doxygen will group on one line in the generated HTML documentation.
-# Note that a value of 0 will completely suppress the enum values from
-# appearing in the overview section.
-
-ENUM_VALUES_PER_LINE = 4
-
-# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
-# structure should be generated to display hierarchical information.
-# If the tag value is set to YES, a side panel will be generated
-# containing a tree-like index structure (just like the one that
-# is generated for HTML Help). For this to work a browser that supports
-# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser).
-# Windows users are probably better off using the HTML help feature.
-
-GENERATE_TREEVIEW = YES
-
-# By enabling USE_INLINE_TREES, doxygen will generate the Groups, Directories,
-# and Class Hierarchy pages using a tree view instead of an ordered list.
-
-USE_INLINE_TREES = NO
-
-# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
-# used to set the initial width (in pixels) of the frame in which the tree
-# is shown.
-
-TREEVIEW_WIDTH = 250
-
-# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open
-# links to external symbols imported via tag files in a separate window.
-
-EXT_LINKS_IN_WINDOW = NO
-
-# Use this tag to change the font size of Latex formulas included
-# as images in the HTML documentation. The default is 10. Note that
-# when you change the font size after a successful doxygen run you need
-# to manually remove any form_*.png images from the HTML output directory
-# to force them to be regenerated.
-
-FORMULA_FONTSIZE = 10
-
-# Use the FORMULA_TRANPARENT tag to determine whether or not the images
-# generated for formulas are transparent PNGs. Transparent PNGs are
-# not supported properly for IE 6.0, but are supported on all modern browsers.
-# Note that when changing this option you need to delete any form_*.png files
-# in the HTML output before the changes have effect.
-
-FORMULA_TRANSPARENT = YES
-
-# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax
-# (see http://www.mathjax.org) which uses client side Javascript for the
-# rendering instead of using prerendered bitmaps. Use this if you do not
-# have LaTeX installed or if you want to formulas look prettier in the HTML
-# output. When enabled you also need to install MathJax separately and
-# configure the path to it using the MATHJAX_RELPATH option.
-
-USE_MATHJAX = NO
-
-# When MathJax is enabled you need to specify the location relative to the
-# HTML output directory using the MATHJAX_RELPATH option. The destination
-# directory should contain the MathJax.js script. For instance, if the mathjax
-# directory is located at the same level as the HTML output directory, then
-# MATHJAX_RELPATH should be ../mathjax. The default value points to the
-# mathjax.org site, so you can quickly see the result without installing
-# MathJax, but it is strongly recommended to install a local copy of MathJax
-# before deployment.
-
-MATHJAX_RELPATH = http://www.mathjax.org/mathjax
-
-# When the SEARCHENGINE tag is enabled doxygen will generate a search box
-# for the HTML output. The underlying search engine uses javascript
-# and DHTML and should work on any modern browser. Note that when using
-# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets
-# (GENERATE_DOCSET) there is already a search function so this one should
-# typically be disabled. For large projects the javascript based search engine
-# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution.
-
-SEARCHENGINE = YES
-
-# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
-# implemented using a PHP enabled web server instead of at the web client
-# using Javascript. Doxygen will generate the search PHP script and index
-# file to put on the web server. The advantage of the server
-# based approach is that it scales better to large projects and allows
-# full text search. The disadvantages are that it is more difficult to setup
-# and does not have live searching capabilities.
-
-SERVER_BASED_SEARCH = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the LaTeX output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
-# generate Latex output.
-
-GENERATE_LATEX = YES
-
-# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `latex' will be used as the default path.
-
-LATEX_OUTPUT = latex
-
-# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
-# invoked. If left blank `latex' will be used as the default command name.
-# Note that when enabling USE_PDFLATEX this option is only used for
-# generating bitmaps for formulas in the HTML output, but not in the
-# Makefile that is written to the output directory.
-
-LATEX_CMD_NAME = latex
-
-# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
-# generate index for LaTeX. If left blank `makeindex' will be used as the
-# default command name.
-
-MAKEINDEX_CMD_NAME = makeindex
-
-# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
-# LaTeX documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_LATEX = YES
-
-# The PAPER_TYPE tag can be used to set the paper type that is used
-# by the printer. Possible values are: a4, letter, legal and
-# executive. If left blank a4wide will be used.
-
-PAPER_TYPE = a4
-
-# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
-# packages that should be included in the LaTeX output.
-
-EXTRA_PACKAGES =
-
-# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
-# the generated latex document. The header should contain everything until
-# the first chapter. If it is left blank doxygen will generate a
-# standard header. Notice: only use this tag if you know what you are doing!
-
-LATEX_HEADER =
-
-# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
-# is prepared for conversion to pdf (using ps2pdf). The pdf file will
-# contain links (just like the HTML output) instead of page references
-# This makes the output suitable for online browsing using a pdf viewer.
-
-PDF_HYPERLINKS = YES
-
-# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
-# plain latex in the generated Makefile. Set this option to YES to get a
-# higher quality PDF documentation.
-
-USE_PDFLATEX = YES
-
-# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
-# command to the generated LaTeX files. This will instruct LaTeX to keep
-# running if errors occur, instead of asking the user for help.
-# This option is also used when generating formulas in HTML.
-
-LATEX_BATCHMODE = NO
-
-# If LATEX_HIDE_INDICES is set to YES then doxygen will not
-# include the index chapters (such as File Index, Compound Index, etc.)
-# in the output.
-
-LATEX_HIDE_INDICES = NO
-
-# If LATEX_SOURCE_CODE is set to YES then doxygen will include
-# source code with syntax highlighting in the LaTeX output.
-# Note that which sources are shown also depends on other settings
-# such as SOURCE_BROWSER.
-
-LATEX_SOURCE_CODE = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the RTF output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
-# The RTF output is optimized for Word 97 and may not look very pretty with
-# other RTF readers or editors.
-
-GENERATE_RTF = NO
-
-# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `rtf' will be used as the default path.
-
-RTF_OUTPUT = rtf
-
-# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
-# RTF documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_RTF = NO
-
-# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
-# will contain hyperlink fields. The RTF file will
-# contain links (just like the HTML output) instead of page references.
-# This makes the output suitable for online browsing using WORD or other
-# programs which support those fields.
-# Note: wordpad (write) and others do not support links.
-
-RTF_HYPERLINKS = NO
-
-# Load stylesheet definitions from file. Syntax is similar to doxygen's
-# config file, i.e. a series of assignments. You only have to provide
-# replacements, missing definitions are set to their default value.
-
-RTF_STYLESHEET_FILE =
-
-# Set optional variables used in the generation of an rtf document.
-# Syntax is similar to doxygen's config file.
-
-RTF_EXTENSIONS_FILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the man page output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
-# generate man pages
-
-GENERATE_MAN = NO
-
-# The MAN_OUTPUT tag is used to specify where the man pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `man' will be used as the default path.
-
-MAN_OUTPUT = man
-
-# The MAN_EXTENSION tag determines the extension that is added to
-# the generated man pages (default is the subroutine's section .3)
-
-MAN_EXTENSION = .3
-
-# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
-# then it will generate one additional man file for each entity
-# documented in the real man page(s). These additional files
-# only source the real man page, but without them the man command
-# would be unable to find the correct page. The default is NO.
-
-MAN_LINKS = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the XML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_XML tag is set to YES Doxygen will
-# generate an XML file that captures the structure of
-# the code including all documentation.
-
-GENERATE_XML = NO
-
-# The XML_OUTPUT tag is used to specify where the XML pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `xml' will be used as the default path.
-
-XML_OUTPUT = xml
-
-# The XML_SCHEMA tag can be used to specify an XML schema,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_SCHEMA =
-
-# The XML_DTD tag can be used to specify an XML DTD,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_DTD =
-
-# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
-# dump the program listings (including syntax highlighting
-# and cross-referencing information) to the XML output. Note that
-# enabling this will significantly increase the size of the XML output.
-
-XML_PROGRAMLISTING = YES
-
-#---------------------------------------------------------------------------
-# configuration options for the AutoGen Definitions output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
-# generate an AutoGen Definitions (see autogen.sf.net) file
-# that captures the structure of the code including all
-# documentation. Note that this feature is still experimental
-# and incomplete at the moment.
-
-GENERATE_AUTOGEN_DEF = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the Perl module output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_PERLMOD tag is set to YES Doxygen will
-# generate a Perl module file that captures the structure of
-# the code including all documentation. Note that this
-# feature is still experimental and incomplete at the
-# moment.
-
-GENERATE_PERLMOD = NO
-
-# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
-# the necessary Makefile rules, Perl scripts and LaTeX code to be able
-# to generate PDF and DVI output from the Perl module output.
-
-PERLMOD_LATEX = NO
-
-# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
-# nicely formatted so it can be parsed by a human reader. This is useful
-# if you want to understand what is going on. On the other hand, if this
-# tag is set to NO the size of the Perl module output will be much smaller
-# and Perl will parse it just the same.
-
-PERLMOD_PRETTY = YES
-
-# The names of the make variables in the generated doxyrules.make file
-# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
-# This is useful so different doxyrules.make files included by the same
-# Makefile don't overwrite each other's variables.
-
-PERLMOD_MAKEVAR_PREFIX =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the preprocessor
-#---------------------------------------------------------------------------
-
-# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
-# evaluate all C-preprocessor directives found in the sources and include
-# files.
-
-ENABLE_PREPROCESSING = YES
-
-# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
-# names in the source code. If set to NO (the default) only conditional
-# compilation will be performed. Macro expansion can be done in a controlled
-# way by setting EXPAND_ONLY_PREDEF to YES.
-
-MACRO_EXPANSION = NO
-
-# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
-# then the macro expansion is limited to the macros specified with the
-# PREDEFINED and EXPAND_AS_DEFINED tags.
-
-EXPAND_ONLY_PREDEF = NO
-
-# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
-# in the INCLUDE_PATH (see below) will be search if a #include is found.
-
-SEARCH_INCLUDES = YES
-
-# The INCLUDE_PATH tag can be used to specify one or more directories that
-# contain include files that are not input files but should be processed by
-# the preprocessor.
-
-INCLUDE_PATH =
-
-# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
-# patterns (like *.h and *.hpp) to filter out the header-files in the
-# directories. If left blank, the patterns specified with FILE_PATTERNS will
-# be used.
-
-INCLUDE_FILE_PATTERNS =
-
-# The PREDEFINED tag can be used to specify one or more macro names that
-# are defined before the preprocessor is started (similar to the -D option of
-# gcc). The argument of the tag is a list of macros of the form: name
-# or name=definition (no spaces). If the definition and the = are
-# omitted =1 is assumed. To prevent a macro definition from being
-# undefined via #undef or recursively expanded use the := operator
-# instead of the = operator.
-
-PREDEFINED =
-
-# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
-# this tag can be used to specify a list of macro names that should be expanded.
-# The macro definition that is found in the sources will be used.
-# Use the PREDEFINED tag if you want to use a different macro definition that
-# overrules the definition found in the source code.
-
-EXPAND_AS_DEFINED =
-
-# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
-# doxygen's preprocessor will remove all references to function-like macros
-# that are alone on a line, have an all uppercase name, and do not end with a
-# semicolon, because these will confuse the parser if not removed.
-
-SKIP_FUNCTION_MACROS = YES
-
-#---------------------------------------------------------------------------
-# Configuration::additions related to external references
-#---------------------------------------------------------------------------
-
-# The TAGFILES option can be used to specify one or more tagfiles.
-# Optionally an initial location of the external documentation
-# can be added for each tagfile. The format of a tag file without
-# this location is as follows:
-# TAGFILES = file1 file2 ...
-# Adding location for the tag files is done as follows:
-# TAGFILES = file1=loc1 "file2 = loc2" ...
-# where "loc1" and "loc2" can be relative or absolute paths or
-# URLs. If a location is present for each tag, the installdox tool
-# does not have to be run to correct the links.
-# Note that each tag file must have a unique name
-# (where the name does NOT include the path)
-# If a tag file is not located in the directory in which doxygen
-# is run, you must also specify the path to the tagfile here.
-
-TAGFILES =
-
-# When a file name is specified after GENERATE_TAGFILE, doxygen will create
-# a tag file that is based on the input files it reads.
-
-GENERATE_TAGFILE =
-
-# If the ALLEXTERNALS tag is set to YES all external classes will be listed
-# in the class index. If set to NO only the inherited external classes
-# will be listed.
-
-ALLEXTERNALS = NO
-
-# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
-# in the modules index. If set to NO, only the current project's groups will
-# be listed.
-
-EXTERNAL_GROUPS = YES
-
-# The PERL_PATH should be the absolute path and name of the perl script
-# interpreter (i.e. the result of `which perl').
-
-PERL_PATH = /usr/bin/perl
-
-#---------------------------------------------------------------------------
-# Configuration options related to the dot tool
-#---------------------------------------------------------------------------
-
-# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
-# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
-# or super classes. Setting the tag to NO turns the diagrams off. Note that
-# this option also works with HAVE_DOT disabled, but it is recommended to
-# install and use dot, since it yields more powerful graphs.
-
-CLASS_DIAGRAMS = YES
-
-# You can define message sequence charts within doxygen comments using the \msc
-# command. Doxygen will then run the mscgen tool (see
-# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
-# documentation. The MSCGEN_PATH tag allows you to specify the directory where
-# the mscgen tool resides. If left empty the tool is assumed to be found in the
-# default search path.
-
-MSCGEN_PATH =
-
-# If set to YES, the inheritance and collaboration graphs will hide
-# inheritance and usage relations if the target is undocumented
-# or is not a class.
-
-HIDE_UNDOC_RELATIONS = YES
-
-# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
-# available from the path. This tool is part of Graphviz, a graph visualization
-# toolkit from AT&T and Lucent Bell Labs. The other options in this section
-# have no effect if this option is set to NO (the default)
-
-HAVE_DOT = NO
-
-# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is
-# allowed to run in parallel. When set to 0 (the default) doxygen will
-# base this on the number of processors available in the system. You can set it
-# explicitly to a value larger than 0 to get control over the balance
-# between CPU load and processing speed.
-
-DOT_NUM_THREADS = 0
-
-# By default doxygen will write a font called Helvetica to the output
-# directory and reference it in all dot files that doxygen generates.
-# When you want a differently looking font you can specify the font name
-# using DOT_FONTNAME. You need to make sure dot is able to find the font,
-# which can be done by putting it in a standard location or by setting the
-# DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory
-# containing the font.
-
-DOT_FONTNAME = Helvetica
-
-# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs.
-# The default size is 10pt.
-
-DOT_FONTSIZE = 10
-
-# By default doxygen will tell dot to use the output directory to look for the
-# FreeSans.ttf font (which doxygen will put there itself). If you specify a
-# different font using DOT_FONTNAME you can set the path where dot
-# can find it using this tag.
-
-DOT_FONTPATH =
-
-# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect inheritance relations. Setting this tag to YES will force the
-# the CLASS_DIAGRAMS tag to NO.
-
-CLASS_GRAPH = YES
-
-# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect implementation dependencies (inheritance, containment, and
-# class references variables) of the class with other documented classes.
-
-COLLABORATION_GRAPH = YES
-
-# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for groups, showing the direct groups dependencies
-
-GROUP_GRAPHS = YES
-
-# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
-# collaboration diagrams in a style similar to the OMG's Unified Modeling
-# Language.
-
-UML_LOOK = NO
-
-# If set to YES, the inheritance and collaboration graphs will show the
-# relations between templates and their instances.
-
-TEMPLATE_RELATIONS = NO
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
-# tags are set to YES then doxygen will generate a graph for each documented
-# file showing the direct and indirect include dependencies of the file with
-# other documented files.
-
-INCLUDE_GRAPH = YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
-# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
-# documented header file showing the documented files that directly or
-# indirectly include this file.
-
-INCLUDED_BY_GRAPH = YES
-
-# If the CALL_GRAPH and HAVE_DOT options are set to YES then
-# doxygen will generate a call dependency graph for every global function
-# or class method. Note that enabling this option will significantly increase
-# the time of a run. So in most cases it will be better to enable call graphs
-# for selected functions only using the \callgraph command.
-
-CALL_GRAPH = NO
-
-# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
-# doxygen will generate a caller dependency graph for every global function
-# or class method. Note that enabling this option will significantly increase
-# the time of a run. So in most cases it will be better to enable caller
-# graphs for selected functions only using the \callergraph command.
-
-CALLER_GRAPH = NO
-
-# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
-# will generate a graphical hierarchy of all classes instead of a textual one.
-
-GRAPHICAL_HIERARCHY = YES
-
-# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
-# then doxygen will show the dependencies a directory has on other directories
-# in a graphical way. The dependency relations are determined by the #include
-# relations between the files in the directories.
-
-DIRECTORY_GRAPH = YES
-
-# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
-# generated by dot. Possible values are png, svg, gif or svg.
-# If left blank png will be used.
-
-DOT_IMAGE_FORMAT = png
-
-# The tag DOT_PATH can be used to specify the path where the dot tool can be
-# found. If left blank, it is assumed the dot tool can be found in the path.
-
-DOT_PATH =
-
-# The DOTFILE_DIRS tag can be used to specify one or more directories that
-# contain dot files that are included in the documentation (see the
-# \dotfile command).
-
-DOTFILE_DIRS =
-
-# The MSCFILE_DIRS tag can be used to specify one or more directories that
-# contain msc files that are included in the documentation (see the
-# \mscfile command).
-
-MSCFILE_DIRS =
-
-# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
-# nodes that will be shown in the graph. If the number of nodes in a graph
-# becomes larger than this value, doxygen will truncate the graph, which is
-# visualized by representing a node as a red box. Note that doxygen if the
-# number of direct children of the root node in a graph is already larger than
-# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
-# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
-
-DOT_GRAPH_MAX_NODES = 50
-
-# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
-# graphs generated by dot. A depth value of 3 means that only nodes reachable
-# from the root by following a path via at most 3 edges will be shown. Nodes
-# that lay further from the root node will be omitted. Note that setting this
-# option to 1 or 2 may greatly reduce the computation time needed for large
-# code bases. Also note that the size of a graph can be further restricted by
-# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
-
-MAX_DOT_GRAPH_DEPTH = 0
-
-# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
-# background. This is disabled by default, because dot on Windows does not
-# seem to support this out of the box. Warning: Depending on the platform used,
-# enabling this option may lead to badly anti-aliased labels on the edges of
-# a graph (i.e. they become hard to read).
-
-DOT_TRANSPARENT = NO
-
-# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
-# files in one run (i.e. multiple -o and -T options on the command line). This
-# makes dot run faster, but since only newer versions of dot (>1.8.10)
-# support this, this feature is disabled by default.
-
-DOT_MULTI_TARGETS = NO
-
-# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
-# generate a legend page explaining the meaning of the various boxes and
-# arrows in the dot generated graphs.
-
-GENERATE_LEGEND = YES
-
-# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
-# remove the intermediate dot files that are used to generate
-# the various graphs.
-
-DOT_CLEANUP = YES
-# Doxyfile 1.7.3
-
-# This file describes the settings to be used by the documentation system
-# doxygen (www.doxygen.org) for a project
-#
-# All text after a hash (#) is considered a comment and will be ignored
-# The format is:
-# TAG = value [value, ...]
-# For lists items can also be appended using:
-# TAG += value [value, ...]
-# Values that contain spaces should be placed between quotes (" ")
-
-#---------------------------------------------------------------------------
-# Project related configuration options
-#---------------------------------------------------------------------------
-
-# This tag specifies the encoding used for all characters in the config file
-# that follow. The default is UTF-8 which is also the encoding used for all
-# text before the first occurrence of this tag. Doxygen uses libiconv (or the
-# iconv built into libc) for the transcoding. See
-# http://www.gnu.org/software/libiconv for the list of possible encodings.
-
-DOXYFILE_ENCODING = UTF-8
-
-# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
-# by quotes) that should identify the project.
-
-PROJECT_NAME = Starshatter_Open
-
-# The PROJECT_NUMBER tag can be used to enter a project or revision number.
-# This could be handy for archiving the generated documentation or
-# if some version control system is used.
-
-PROJECT_NUMBER =
-
-# Using the PROJECT_BRIEF tag one can provide an optional one line description
-# for a project that appears at the top of each page and should give viewer
-# a quick idea about the purpose of the project. Keep the description short.
-
-PROJECT_BRIEF = "Open source Starshatter engine"
-
-# With the PROJECT_LOGO tag one can specify an logo or icon that is
-# included in the documentation. The maximum height of the logo should not
-# exceed 55 pixels and the maximum width should not exceed 200 pixels.
-# Doxygen will copy the logo to the output directory.
-
-PROJECT_LOGO =
-
-# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
-# base path where the generated documentation will be put.
-# If a relative path is entered, it will be relative to the location
-# where doxygen was started. If left blank the current directory will be used.
-
-OUTPUT_DIRECTORY = doxygen
-
-# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
-# 4096 sub-directories (in 2 levels) under the output directory of each output
-# format and will distribute the generated files over these directories.
-# Enabling this option can be useful when feeding doxygen a huge amount of
-# source files, where putting all generated files in the same directory would
-# otherwise cause performance problems for the file system.
-
-CREATE_SUBDIRS = NO
-
-# The OUTPUT_LANGUAGE tag is used to specify the language in which all
-# documentation generated by doxygen is written. Doxygen will use this
-# information to generate all constant output in the proper language.
-# The default language is English, other supported languages are:
-# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
-# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
-# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
-# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
-# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak,
-# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.
-
-OUTPUT_LANGUAGE = English
-
-# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
-# include brief member descriptions after the members that are listed in
-# the file and class documentation (similar to JavaDoc).
-# Set to NO to disable this.
-
-BRIEF_MEMBER_DESC = YES
-
-# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
-# the brief description of a member or function before the detailed description.
-# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
-# brief descriptions will be completely suppressed.
-
-REPEAT_BRIEF = YES
-
-# This tag implements a quasi-intelligent brief description abbreviator
-# that is used to form the text in various listings. Each string
-# in this list, if found as the leading text of the brief description, will be
-# stripped from the text and the result after processing the whole list, is
-# used as the annotated text. Otherwise, the brief description is used as-is.
-# If left blank, the following values are used ("$name" is automatically
-# replaced with the name of the entity): "The $name class" "The $name widget"
-# "The $name file" "is" "provides" "specifies" "contains"
-# "represents" "a" "an" "the"
-
-ABBREVIATE_BRIEF = "The $name class" \
- "The $name widget" \
- "The $name file" \
- is \
- provides \
- specifies \
- contains \
- represents \
- a \
- an \
- the
-
-# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
-# Doxygen will generate a detailed section even if there is only a brief
-# description.
-
-ALWAYS_DETAILED_SEC = NO
-
-# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
-# inherited members of a class in the documentation of that class as if those
-# members were ordinary class members. Constructors, destructors and assignment
-# operators of the base classes will not be shown.
-
-INLINE_INHERITED_MEMB = NO
-
-# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
-# path before files name in the file list and in the header files. If set
-# to NO the shortest path that makes the file name unique will be used.
-
-FULL_PATH_NAMES = YES
-
-# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
-# can be used to strip a user-defined part of the path. Stripping is
-# only done if one of the specified strings matches the left-hand part of
-# the path. The tag can be used to show relative paths in the file list.
-# If left blank the directory from which doxygen is run is used as the
-# path to strip.
-
-STRIP_FROM_PATH =
-
-# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
-# the path mentioned in the documentation of a class, which tells
-# the reader which header file to include in order to use a class.
-# If left blank only the name of the header file containing the class
-# definition is used. Otherwise one should specify the include paths that
-# are normally passed to the compiler using the -I flag.
-
-STRIP_FROM_INC_PATH =
-
-# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
-# (but less readable) file names. This can be useful if your file system
-# doesn't support long names like on DOS, Mac, or CD-ROM.
-
-SHORT_NAMES = NO
-
-# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
-# will interpret the first line (until the first dot) of a JavaDoc-style
-# comment as the brief description. If set to NO, the JavaDoc
-# comments will behave just like regular Qt-style comments
-# (thus requiring an explicit @brief command for a brief description.)
-
-JAVADOC_AUTOBRIEF = NO
-
-# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
-# interpret the first line (until the first dot) of a Qt-style
-# comment as the brief description. If set to NO, the comments
-# will behave just like regular Qt-style comments (thus requiring
-# an explicit \brief command for a brief description.)
-
-QT_AUTOBRIEF = NO
-
-# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
-# treat a multi-line C++ special comment block (i.e. a block of //! or ///
-# comments) as a brief description. This used to be the default behaviour.
-# The new default is to treat a multi-line C++ comment block as a detailed
-# description. Set this tag to YES if you prefer the old behaviour instead.
-
-MULTILINE_CPP_IS_BRIEF = NO
-
-# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
-# member inherits the documentation from any documented member that it
-# re-implements.
-
-INHERIT_DOCS = YES
-
-# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
-# a new page for each member. If set to NO, the documentation of a member will
-# be part of the file/class/namespace that contains it.
-
-SEPARATE_MEMBER_PAGES = NO
-
-# The TAB_SIZE tag can be used to set the number of spaces in a tab.
-# Doxygen uses this value to replace tabs by spaces in code fragments.
-
-TAB_SIZE = 8
-
-# This tag can be used to specify a number of aliases that acts
-# as commands in the documentation. An alias has the form "name=value".
-# For example adding "sideeffect=\par Side Effects:\n" will allow you to
-# put the command \sideeffect (or @sideeffect) in the documentation, which
-# will result in a user-defined paragraph with heading "Side Effects:".
-# You can put \n's in the value part of an alias to insert newlines.
-
-ALIASES =
-
-# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
-# sources only. Doxygen will then generate output that is more tailored for C.
-# For instance, some of the names that are used will be different. The list
-# of all members will be omitted, etc.
-
-OPTIMIZE_OUTPUT_FOR_C = NO
-
-# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
-# sources only. Doxygen will then generate output that is more tailored for
-# Java. For instance, namespaces will be presented as packages, qualified
-# scopes will look different, etc.
-
-OPTIMIZE_OUTPUT_JAVA = NO
-
-# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
-# sources only. Doxygen will then generate output that is more tailored for
-# Fortran.
-
-OPTIMIZE_FOR_FORTRAN = NO
-
-# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
-# sources. Doxygen will then generate output that is tailored for
-# VHDL.
-
-OPTIMIZE_OUTPUT_VHDL = NO
-
-# Doxygen selects the parser to use depending on the extension of the files it
-# parses. With this tag you can assign which parser to use for a given extension.
-# Doxygen has a built-in mapping, but you can override or extend it using this
-# tag. The format is ext=language, where ext is a file extension, and language
-# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
-# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
-# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
-# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
-# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
-
-EXTENSION_MAPPING =
-
-# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
-# to include (a tag file for) the STL sources as input, then you should
-# set this tag to YES in order to let doxygen match functions declarations and
-# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
-# func(std::string) {}). This also makes the inheritance and collaboration
-# diagrams that involve STL classes more complete and accurate.
-
-BUILTIN_STL_SUPPORT = NO
-
-# If you use Microsoft's C++/CLI language, you should set this option to YES to
-# enable parsing support.
-
-CPP_CLI_SUPPORT = NO
-
-# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
-# Doxygen will parse them like normal C++ but will assume all classes use public
-# instead of private inheritance when no explicit protection keyword is present.
-
-SIP_SUPPORT = NO
-
-# For Microsoft's IDL there are propget and propput attributes to indicate getter
-# and setter methods for a property. Setting this option to YES (the default)
-# will make doxygen replace the get and set methods by a property in the
-# documentation. This will only work if the methods are indeed getting or
-# setting a simple type. If this is not the case, or you want to show the
-# methods anyway, you should set this option to NO.
-
-IDL_PROPERTY_SUPPORT = YES
-
-# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
-# tag is set to YES, then doxygen will reuse the documentation of the first
-# member in the group (if any) for the other members of the group. By default
-# all members of a group must be documented explicitly.
-
-DISTRIBUTE_GROUP_DOC = NO
-
-# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
-# the same type (for instance a group of public functions) to be put as a
-# subgroup of that type (e.g. under the Public Functions section). Set it to
-# NO to prevent subgrouping. Alternatively, this can be done per class using
-# the \nosubgrouping command.
-
-SUBGROUPING = YES
-
-# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
-# is documented as struct, union, or enum with the name of the typedef. So
-# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
-# with name TypeT. When disabled the typedef will appear as a member of a file,
-# namespace, or class. And the struct will be named TypeS. This can typically
-# be useful for C code in case the coding convention dictates that all compound
-# types are typedef'ed and only the typedef is referenced, never the tag name.
-
-TYPEDEF_HIDES_STRUCT = NO
-
-# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
-# determine which symbols to keep in memory and which to flush to disk.
-# When the cache is full, less often used symbols will be written to disk.
-# For small to medium size projects (<1000 input files) the default value is
-# probably good enough. For larger projects a too small cache size can cause
-# doxygen to be busy swapping symbols to and from disk most of the time
-# causing a significant performance penalty.
-# If the system has enough physical memory increasing the cache will improve the
-# performance by keeping more symbols in memory. Note that the value works on
-# a logarithmic scale so increasing the size by one will roughly double the
-# memory usage. The cache size is given by this formula:
-# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
-# corresponding to a cache size of 2^16 = 65536 symbols
-
-SYMBOL_CACHE_SIZE = 0
-
-#---------------------------------------------------------------------------
-# Build related configuration options
-#---------------------------------------------------------------------------
-
-# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
-# documentation are documented, even if no documentation was available.
-# Private class members and static file members will be hidden unless
-# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
-
-EXTRACT_ALL = YES
-
-# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
-# will be included in the documentation.
-
-EXTRACT_PRIVATE = NO
-
-# If the EXTRACT_STATIC tag is set to YES all static members of a file
-# will be included in the documentation.
-
-EXTRACT_STATIC = NO
-
-# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
-# defined locally in source files will be included in the documentation.
-# If set to NO only classes defined in header files are included.
-
-EXTRACT_LOCAL_CLASSES = YES
-
-# This flag is only useful for Objective-C code. When set to YES local
-# methods, which are defined in the implementation section but not in
-# the interface are included in the documentation.
-# If set to NO (the default) only methods in the interface are included.
-
-EXTRACT_LOCAL_METHODS = NO
-
-# If this flag is set to YES, the members of anonymous namespaces will be
-# extracted and appear in the documentation as a namespace called
-# 'anonymous_namespace{file}', where file will be replaced with the base
-# name of the file that contains the anonymous namespace. By default
-# anonymous namespaces are hidden.
-
-EXTRACT_ANON_NSPACES = NO
-
-# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
-# undocumented members of documented classes, files or namespaces.
-# If set to NO (the default) these members will be included in the
-# various overviews, but no documentation section is generated.
-# This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_MEMBERS = NO
-
-# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
-# undocumented classes that are normally visible in the class hierarchy.
-# If set to NO (the default) these classes will be included in the various
-# overviews. This option has no effect if EXTRACT_ALL is enabled.
-
-HIDE_UNDOC_CLASSES = NO
-
-# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
-# friend (class|struct|union) declarations.
-# If set to NO (the default) these declarations will be included in the
-# documentation.
-
-HIDE_FRIEND_COMPOUNDS = NO
-
-# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
-# documentation blocks found inside the body of a function.
-# If set to NO (the default) these blocks will be appended to the
-# function's detailed documentation block.
-
-HIDE_IN_BODY_DOCS = NO
-
-# The INTERNAL_DOCS tag determines if documentation
-# that is typed after a \internal command is included. If the tag is set
-# to NO (the default) then the documentation will be excluded.
-# Set it to YES to include the internal documentation.
-
-INTERNAL_DOCS = NO
-
-# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
-# file names in lower-case letters. If set to YES upper-case letters are also
-# allowed. This is useful if you have classes or files whose names only differ
-# in case and if your file system supports case sensitive file names. Windows
-# and Mac users are advised to set this option to NO.
-
-CASE_SENSE_NAMES = NO
-
-# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
-# will show members with their full class and namespace scopes in the
-# documentation. If set to YES the scope will be hidden.
-
-HIDE_SCOPE_NAMES = NO
-
-# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
-# will put a list of the files that are included by a file in the documentation
-# of that file.
-
-SHOW_INCLUDE_FILES = YES
-
-# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen
-# will list include files with double quotes in the documentation
-# rather than with sharp brackets.
-
-FORCE_LOCAL_INCLUDES = NO
-
-# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
-# is inserted in the documentation for inline members.
-
-INLINE_INFO = YES
-
-# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
-# will sort the (detailed) documentation of file and class members
-# alphabetically by member name. If set to NO the members will appear in
-# declaration order.
-
-SORT_MEMBER_DOCS = YES
-
-# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
-# brief documentation of file, namespace and class members alphabetically
-# by member name. If set to NO (the default) the members will appear in
-# declaration order.
-
-SORT_BRIEF_DOCS = NO
-
-# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen
-# will sort the (brief and detailed) documentation of class members so that
-# constructors and destructors are listed first. If set to NO (the default)
-# the constructors will appear in the respective orders defined by
-# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS.
-# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
-# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
-
-SORT_MEMBERS_CTORS_1ST = NO
-
-# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
-# hierarchy of group names into alphabetical order. If set to NO (the default)
-# the group names will appear in their defined order.
-
-SORT_GROUP_NAMES = NO
-
-# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
-# sorted by fully-qualified names, including namespaces. If set to
-# NO (the default), the class list will be sorted only by class name,
-# not including the namespace part.
-# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
-# Note: This option applies only to the class list, not to the
-# alphabetical list.
-
-SORT_BY_SCOPE_NAME = NO
-
-# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to
-# do proper type resolution of all parameters of a function it will reject a
-# match between the prototype and the implementation of a member function even
-# if there is only one candidate or it is obvious which candidate to choose
-# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen
-# will still accept a match between prototype and implementation in such cases.
-
-STRICT_PROTO_MATCHING = NO
-
-# The GENERATE_TODOLIST tag can be used to enable (YES) or
-# disable (NO) the todo list. This list is created by putting \todo
-# commands in the documentation.
-
-GENERATE_TODOLIST = YES
-
-# The GENERATE_TESTLIST tag can be used to enable (YES) or
-# disable (NO) the test list. This list is created by putting \test
-# commands in the documentation.
-
-GENERATE_TESTLIST = YES
-
-# The GENERATE_BUGLIST tag can be used to enable (YES) or
-# disable (NO) the bug list. This list is created by putting \bug
-# commands in the documentation.
-
-GENERATE_BUGLIST = YES
-
-# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
-# disable (NO) the deprecated list. This list is created by putting
-# \deprecated commands in the documentation.
-
-GENERATE_DEPRECATEDLIST= YES
-
-# The ENABLED_SECTIONS tag can be used to enable conditional
-# documentation sections, marked by \if sectionname ... \endif.
-
-ENABLED_SECTIONS =
-
-# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
-# the initial value of a variable or macro consists of for it to appear in
-# the documentation. If the initializer consists of more lines than specified
-# here it will be hidden. Use a value of 0 to hide initializers completely.
-# The appearance of the initializer of individual variables and macros in the
-# documentation can be controlled using \showinitializer or \hideinitializer
-# command in the documentation regardless of this setting.
-
-MAX_INITIALIZER_LINES = 30
-
-# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
-# at the bottom of the documentation of classes and structs. If set to YES the
-# list will mention the files that were used to generate the documentation.
-
-SHOW_USED_FILES = YES
-
-# If the sources in your project are distributed over multiple directories
-# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
-# in the documentation. The default is NO.
-
-SHOW_DIRECTORIES = NO
-
-# Set the SHOW_FILES tag to NO to disable the generation of the Files page.
-# This will remove the Files entry from the Quick Index and from the
-# Folder Tree View (if specified). The default is YES.
-
-SHOW_FILES = YES
-
-# Set the SHOW_NAMESPACES tag to NO to disable the generation of the
-# Namespaces page. This will remove the Namespaces entry from the Quick Index
-# and from the Folder Tree View (if specified). The default is YES.
-
-SHOW_NAMESPACES = YES
-
-# The FILE_VERSION_FILTER tag can be used to specify a program or script that
-# doxygen should invoke to get the current version for each file (typically from
-# the version control system). Doxygen will invoke the program by executing (via
-# popen()) the command <command> <input-file>, where <command> is the value of
-# the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file
-# provided by doxygen. Whatever the program writes to standard output
-# is used as the file version. See the manual for examples.
-
-FILE_VERSION_FILTER =
-
-# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
-# by doxygen. The layout file controls the global structure of the generated
-# output files in an output format independent way. The create the layout file
-# that represents doxygen's defaults, run doxygen with the -l option.
-# You can optionally specify a file name after the option, if omitted
-# DoxygenLayout.xml will be used as the name of the layout file.
-
-LAYOUT_FILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to warning and progress messages
-#---------------------------------------------------------------------------
-
-# The QUIET tag can be used to turn on/off the messages that are generated
-# by doxygen. Possible values are YES and NO. If left blank NO is used.
-
-QUIET = NO
-
-# The WARNINGS tag can be used to turn on/off the warning messages that are
-# generated by doxygen. Possible values are YES and NO. If left blank
-# NO is used.
-
-WARNINGS = YES
-
-# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
-# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
-# automatically be disabled.
-
-WARN_IF_UNDOCUMENTED = YES
-
-# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
-# potential errors in the documentation, such as not documenting some
-# parameters in a documented function, or documenting parameters that
-# don't exist or using markup commands wrongly.
-
-WARN_IF_DOC_ERROR = YES
-
-# The WARN_NO_PARAMDOC option can be enabled to get warnings for
-# functions that are documented, but have no documentation for their parameters
-# or return value. If set to NO (the default) doxygen will only warn about
-# wrong or incomplete parameter documentation, but not about the absence of
-# documentation.
-
-WARN_NO_PARAMDOC = NO
-
-# The WARN_FORMAT tag determines the format of the warning messages that
-# doxygen can produce. The string should contain the $file, $line, and $text
-# tags, which will be replaced by the file and line number from which the
-# warning originated and the warning text. Optionally the format may contain
-# $version, which will be replaced by the version of the file (if it could
-# be obtained via FILE_VERSION_FILTER)
-
-WARN_FORMAT = "$file:$line: $text"
-
-# The WARN_LOGFILE tag can be used to specify a file to which warning
-# and error messages should be written. If left blank the output is written
-# to stderr.
-
-WARN_LOGFILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the input files
-#---------------------------------------------------------------------------
-
-# The INPUT tag can be used to specify the files and/or directories that contain
-# documented source files. You may enter file names like "myfile.cpp" or
-# directories like "/usr/src/myproject". Separate the files or directories
-# with spaces.
-
-INPUT = ../FoundationEx ../Magic2 ../NetEx ../nGenEx ../Parser ../Stars45
-
-# This tag can be used to specify the character encoding of the source files
-# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
-# also the default input encoding. Doxygen uses libiconv (or the iconv built
-# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
-# the list of possible encodings.
-
-INPUT_ENCODING = UTF-8
-
-# If the value of the INPUT tag contains directories, you can use the
-# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank the following patterns are tested:
-# *.c *.cc *.cxx *.cpp *.c++ *.d *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh
-# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py
-# *.f90 *.f *.for *.vhd *.vhdl
-
-FILE_PATTERNS = *.c \
- *.cc \
- *.cxx \
- *.cpp \
- *.c++ \
- *.d \
- *.java \
- *.ii \
- *.ixx \
- *.ipp \
- *.i++ \
- *.inl \
- *.h \
- *.hh \
- *.hxx \
- *.hpp \
- *.h++ \
- *.idl \
- *.odl \
- *.cs \
- *.php \
- *.php3 \
- *.inc \
- *.m \
- *.mm \
- *.dox \
- *.py \
- *.f90 \
- *.f \
- *.for \
- *.vhd \
- *.vhdl
-
-# The RECURSIVE tag can be used to turn specify whether or not subdirectories
-# should be searched for input files as well. Possible values are YES and NO.
-# If left blank NO is used.
-
-RECURSIVE = YES
-
-# The EXCLUDE tag can be used to specify files and/or directories that should
-# excluded from the INPUT source files. This way you can easily exclude a
-# subdirectory from a directory tree whose root is specified with the INPUT tag.
-
-EXCLUDE =
-
-# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
-# directories that are symbolic links (a Unix file system feature) are excluded
-# from the input.
-
-EXCLUDE_SYMLINKS = NO
-
-# If the value of the INPUT tag contains directories, you can use the
-# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
-# certain files from those directories. Note that the wildcards are matched
-# against the file with absolute path, so to exclude all test directories
-# for example use the pattern */test/*
-
-EXCLUDE_PATTERNS = */.svn/*
-
-# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
-# (namespaces, classes, functions, etc.) that should be excluded from the
-# output. The symbol name can be a fully qualified name, a word, or if the
-# wildcard * is used, a substring. Examples: ANamespace, AClass,
-# AClass::ANamespace, ANamespace::*Test
-
-EXCLUDE_SYMBOLS =
-
-# The EXAMPLE_PATH tag can be used to specify one or more files or
-# directories that contain example code fragments that are included (see
-# the \include command).
-
-EXAMPLE_PATH =
-
-# If the value of the EXAMPLE_PATH tag contains directories, you can use the
-# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
-# and *.h) to filter out the source-files in the directories. If left
-# blank all files are included.
-
-EXAMPLE_PATTERNS = *
-
-# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
-# searched for input files to be used with the \include or \dontinclude
-# commands irrespective of the value of the RECURSIVE tag.
-# Possible values are YES and NO. If left blank NO is used.
-
-EXAMPLE_RECURSIVE = NO
-
-# The IMAGE_PATH tag can be used to specify one or more files or
-# directories that contain image that are included in the documentation (see
-# the \image command).
-
-IMAGE_PATH =
-
-# The INPUT_FILTER tag can be used to specify a program that doxygen should
-# invoke to filter for each input file. Doxygen will invoke the filter program
-# by executing (via popen()) the command <filter> <input-file>, where <filter>
-# is the value of the INPUT_FILTER tag, and <input-file> is the name of an
-# input file. Doxygen will then use the output that the filter program writes
-# to standard output. If FILTER_PATTERNS is specified, this tag will be
-# ignored.
-
-INPUT_FILTER =
-
-# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
-# basis. Doxygen will compare the file name with each pattern and apply the
-# filter if there is a match. The filters are a list of the form:
-# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
-# info on how filters are used. If FILTER_PATTERNS is empty or if
-# non of the patterns match the file name, INPUT_FILTER is applied.
-
-FILTER_PATTERNS =
-
-# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
-# INPUT_FILTER) will be used to filter the input files when producing source
-# files to browse (i.e. when SOURCE_BROWSER is set to YES).
-
-FILTER_SOURCE_FILES = NO
-
-# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
-# pattern. A pattern will override the setting for FILTER_PATTERN (if any)
-# and it is also possible to disable source filtering for a specific pattern
-# using *.ext= (so without naming a filter). This option only has effect when
-# FILTER_SOURCE_FILES is enabled.
-
-FILTER_SOURCE_PATTERNS =
-
-#---------------------------------------------------------------------------
-# configuration options related to source browsing
-#---------------------------------------------------------------------------
-
-# If the SOURCE_BROWSER tag is set to YES then a list of source files will
-# be generated. Documented entities will be cross-referenced with these sources.
-# Note: To get rid of all source code in the generated output, make sure also
-# VERBATIM_HEADERS is set to NO.
-
-SOURCE_BROWSER = YES
-
-# Setting the INLINE_SOURCES tag to YES will include the body
-# of functions and classes directly in the documentation.
-
-INLINE_SOURCES = NO
-
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
-# doxygen to hide any special comment blocks from generated source code
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS = YES
-
-# If the REFERENCED_BY_RELATION tag is set to YES
-# then for each documented function all documented
-# functions referencing it will be listed.
-
-REFERENCED_BY_RELATION = NO
-
-# If the REFERENCES_RELATION tag is set to YES
-# then for each documented function all documented entities
-# called/used by that function will be listed.
-
-REFERENCES_RELATION = NO
-
-# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
-# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
-# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
-# link to the source code. Otherwise they will link to the documentation.
-
-REFERENCES_LINK_SOURCE = YES
-
-# If the USE_HTAGS tag is set to YES then the references to source code
-# will point to the HTML generated by the htags(1) tool instead of doxygen
-# built-in source browser. The htags tool is part of GNU's global source
-# tagging system (see http://www.gnu.org/software/global/global.html). You
-# will need version 4.8.6 or higher.
-
-USE_HTAGS = NO
-
-# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
-# will generate a verbatim copy of the header file for each class for
-# which an include is specified. Set to NO to disable this.
-
-VERBATIM_HEADERS = YES
-
-#---------------------------------------------------------------------------
-# configuration options related to the alphabetical class index
-#---------------------------------------------------------------------------
-
-# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
-# of all compounds will be generated. Enable this if the project
-# contains a lot of classes, structs, unions or interfaces.
-
-ALPHABETICAL_INDEX = YES
-
-# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
-# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
-# in which this list will be split (can be a number in the range [1..20])
-
-COLS_IN_ALPHA_INDEX = 5
-
-# In case all classes in a project start with a common prefix, all
-# classes will be put under the same header in the alphabetical index.
-# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
-# should be ignored while generating the index headers.
-
-IGNORE_PREFIX =
-
-#---------------------------------------------------------------------------
-# configuration options related to the HTML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
-# generate HTML output.
-
-GENERATE_HTML = YES
-
-# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `html' will be used as the default path.
-
-HTML_OUTPUT = html
-
-# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
-# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
-# doxygen will generate files with .html extension.
-
-HTML_FILE_EXTENSION = .html
-
-# The HTML_HEADER tag can be used to specify a personal HTML header for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard header.
-
-HTML_HEADER =
-
-# The HTML_FOOTER tag can be used to specify a personal HTML footer for
-# each generated HTML page. If it is left blank doxygen will generate a
-# standard footer.
-
-HTML_FOOTER =
-
-# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
-# style sheet that is used by each HTML page. It can be used to
-# fine-tune the look of the HTML output. If the tag is left blank doxygen
-# will generate a default style sheet. Note that doxygen will try to copy
-# the style sheet file to the HTML output directory, so don't put your own
-# stylesheet in the HTML output directory as well, or it will be erased!
-
-HTML_STYLESHEET =
-
-# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
-# Doxygen will adjust the colors in the stylesheet and background images
-# according to this color. Hue is specified as an angle on a colorwheel,
-# see http://en.wikipedia.org/wiki/Hue for more information.
-# For instance the value 0 represents red, 60 is yellow, 120 is green,
-# 180 is cyan, 240 is blue, 300 purple, and 360 is red again.
-# The allowed range is 0 to 359.
-
-HTML_COLORSTYLE_HUE = 220
-
-# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of
-# the colors in the HTML output. For a value of 0 the output will use
-# grayscales only. A value of 255 will produce the most vivid colors.
-
-HTML_COLORSTYLE_SAT = 100
-
-# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to
-# the luminance component of the colors in the HTML output. Values below
-# 100 gradually make the output lighter, whereas values above 100 make
-# the output darker. The value divided by 100 is the actual gamma applied,
-# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2,
-# and 100 does not change the gamma.
-
-HTML_COLORSTYLE_GAMMA = 80
-
-# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
-# page will contain the date and time when the page was generated. Setting
-# this to NO can help when comparing the output of multiple runs.
-
-HTML_TIMESTAMP = YES
-
-# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
-# files or namespaces will be aligned in HTML using tables. If set to
-# NO a bullet list will be used.
-
-HTML_ALIGN_MEMBERS = YES
-
-# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
-# documentation will contain sections that can be hidden and shown after the
-# page has loaded. For this to work a browser that supports
-# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
-# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
-
-HTML_DYNAMIC_SECTIONS = NO
-
-# If the GENERATE_DOCSET tag is set to YES, additional index files
-# will be generated that can be used as input for Apple's Xcode 3
-# integrated development environment, introduced with OSX 10.5 (Leopard).
-# To create a documentation set, doxygen will generate a Makefile in the
-# HTML output directory. Running make will produce the docset in that
-# directory and running "make install" will install the docset in
-# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
-# it at startup.
-# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
-# for more information.
-
-GENERATE_DOCSET = NO
-
-# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
-# feed. A documentation feed provides an umbrella under which multiple
-# documentation sets from a single provider (such as a company or product suite)
-# can be grouped.
-
-DOCSET_FEEDNAME = "Doxygen generated docs"
-
-# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
-# should uniquely identify the documentation set bundle. This should be a
-# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
-# will append .docset to the name.
-
-DOCSET_BUNDLE_ID = org.doxygen.Project
-
-# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
-# the documentation publisher. This should be a reverse domain-name style
-# string, e.g. com.mycompany.MyDocSet.documentation.
-
-DOCSET_PUBLISHER_ID = org.doxygen.Publisher
-
-# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher.
-
-DOCSET_PUBLISHER_NAME = Publisher
-
-# If the GENERATE_HTMLHELP tag is set to YES, additional index files
-# will be generated that can be used as input for tools like the
-# Microsoft HTML help workshop to generate a compiled HTML help file (.chm)
-# of the generated HTML documentation.
-
-GENERATE_HTMLHELP = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
-# be used to specify the file name of the resulting .chm file. You
-# can add a path in front of the file if the result should not be
-# written to the html output directory.
-
-CHM_FILE =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
-# be used to specify the location (absolute path including file name) of
-# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
-# the HTML help compiler on the generated index.hhp.
-
-HHC_LOCATION =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
-# controls if a separate .chi index file is generated (YES) or that
-# it should be included in the master .chm file (NO).
-
-GENERATE_CHI = NO
-
-# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING
-# is used to encode HtmlHelp index (hhk), content (hhc) and project file
-# content.
-
-CHM_INDEX_ENCODING =
-
-# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
-# controls whether a binary table of contents is generated (YES) or a
-# normal table of contents (NO) in the .chm file.
-
-BINARY_TOC = NO
-
-# The TOC_EXPAND flag can be set to YES to add extra items for group members
-# to the contents of the HTML help documentation and to the tree view.
-
-TOC_EXPAND = NO
-
-# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
-# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
-# that can be used as input for Qt's qhelpgenerator to generate a
-# Qt Compressed Help (.qch) of the generated HTML documentation.
-
-GENERATE_QHP = NO
-
-# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
-# be used to specify the file name of the resulting .qch file.
-# The path specified is relative to the HTML output folder.
-
-QCH_FILE =
-
-# The QHP_NAMESPACE tag specifies the namespace to use when generating
-# Qt Help Project output. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#namespace
-
-QHP_NAMESPACE = org.doxygen.Project
-
-# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
-# Qt Help Project output. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#virtual-folders
-
-QHP_VIRTUAL_FOLDER = doc
-
-# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
-# add. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#custom-filters
-
-QHP_CUST_FILTER_NAME =
-
-# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
-# custom filter to add. For more information please see
-# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">
-# Qt Help Project / Custom Filters</a>.
-
-QHP_CUST_FILTER_ATTRS =
-
-# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
-# project's
-# filter section matches.
-# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">
-# Qt Help Project / Filter Attributes</a>.
-
-QHP_SECT_FILTER_ATTRS =
-
-# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
-# be used to specify the location of Qt's qhelpgenerator.
-# If non-empty doxygen will try to run qhelpgenerator on the generated
-# .qhp file.
-
-QHG_LOCATION =
-
-# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
-# will be generated, which together with the HTML files, form an Eclipse help
-# plugin. To install this plugin and make it available under the help contents
-# menu in Eclipse, the contents of the directory containing the HTML and XML
-# files needs to be copied into the plugins directory of eclipse. The name of
-# the directory within the plugins directory should be the same as
-# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before
-# the help appears.
-
-GENERATE_ECLIPSEHELP = NO
-
-# A unique identifier for the eclipse help plugin. When installing the plugin
-# the directory name containing the HTML and XML files should also have
-# this name.
-
-ECLIPSE_DOC_ID = org.doxygen.Project
-
-# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
-# top of each HTML page. The value NO (the default) enables the index and
-# the value YES disables it.
-
-DISABLE_INDEX = NO
-
-# This tag can be used to set the number of enum values (range [0,1..20])
-# that doxygen will group on one line in the generated HTML documentation.
-# Note that a value of 0 will completely suppress the enum values from
-# appearing in the overview section.
-
-ENUM_VALUES_PER_LINE = 4
-
-# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
-# structure should be generated to display hierarchical information.
-# If the tag value is set to YES, a side panel will be generated
-# containing a tree-like index structure (just like the one that
-# is generated for HTML Help). For this to work a browser that supports
-# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser).
-# Windows users are probably better off using the HTML help feature.
-
-GENERATE_TREEVIEW = YES
-
-# By enabling USE_INLINE_TREES, doxygen will generate the Groups, Directories,
-# and Class Hierarchy pages using a tree view instead of an ordered list.
-
-USE_INLINE_TREES = NO
-
-# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
-# used to set the initial width (in pixels) of the frame in which the tree
-# is shown.
-
-TREEVIEW_WIDTH = 250
-
-# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open
-# links to external symbols imported via tag files in a separate window.
-
-EXT_LINKS_IN_WINDOW = NO
-
-# Use this tag to change the font size of Latex formulas included
-# as images in the HTML documentation. The default is 10. Note that
-# when you change the font size after a successful doxygen run you need
-# to manually remove any form_*.png images from the HTML output directory
-# to force them to be regenerated.
-
-FORMULA_FONTSIZE = 10
-
-# Use the FORMULA_TRANPARENT tag to determine whether or not the images
-# generated for formulas are transparent PNGs. Transparent PNGs are
-# not supported properly for IE 6.0, but are supported on all modern browsers.
-# Note that when changing this option you need to delete any form_*.png files
-# in the HTML output before the changes have effect.
-
-FORMULA_TRANSPARENT = YES
-
-# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax
-# (see http://www.mathjax.org) which uses client side Javascript for the
-# rendering instead of using prerendered bitmaps. Use this if you do not
-# have LaTeX installed or if you want to formulas look prettier in the HTML
-# output. When enabled you also need to install MathJax separately and
-# configure the path to it using the MATHJAX_RELPATH option.
-
-USE_MATHJAX = NO
-
-# When MathJax is enabled you need to specify the location relative to the
-# HTML output directory using the MATHJAX_RELPATH option. The destination
-# directory should contain the MathJax.js script. For instance, if the mathjax
-# directory is located at the same level as the HTML output directory, then
-# MATHJAX_RELPATH should be ../mathjax. The default value points to the
-# mathjax.org site, so you can quickly see the result without installing
-# MathJax, but it is strongly recommended to install a local copy of MathJax
-# before deployment.
-
-MATHJAX_RELPATH = http://www.mathjax.org/mathjax
-
-# When the SEARCHENGINE tag is enabled doxygen will generate a search box
-# for the HTML output. The underlying search engine uses javascript
-# and DHTML and should work on any modern browser. Note that when using
-# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets
-# (GENERATE_DOCSET) there is already a search function so this one should
-# typically be disabled. For large projects the javascript based search engine
-# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution.
-
-SEARCHENGINE = YES
-
-# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
-# implemented using a PHP enabled web server instead of at the web client
-# using Javascript. Doxygen will generate the search PHP script and index
-# file to put on the web server. The advantage of the server
-# based approach is that it scales better to large projects and allows
-# full text search. The disadvantages are that it is more difficult to setup
-# and does not have live searching capabilities.
-
-SERVER_BASED_SEARCH = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the LaTeX output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
-# generate Latex output.
-
-GENERATE_LATEX = YES
-
-# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `latex' will be used as the default path.
-
-LATEX_OUTPUT = latex
-
-# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
-# invoked. If left blank `latex' will be used as the default command name.
-# Note that when enabling USE_PDFLATEX this option is only used for
-# generating bitmaps for formulas in the HTML output, but not in the
-# Makefile that is written to the output directory.
-
-LATEX_CMD_NAME = latex
-
-# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
-# generate index for LaTeX. If left blank `makeindex' will be used as the
-# default command name.
-
-MAKEINDEX_CMD_NAME = makeindex
-
-# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
-# LaTeX documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_LATEX = NO
-
-# The PAPER_TYPE tag can be used to set the paper type that is used
-# by the printer. Possible values are: a4, letter, legal and
-# executive. If left blank a4wide will be used.
-
-PAPER_TYPE = a4
-
-# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
-# packages that should be included in the LaTeX output.
-
-EXTRA_PACKAGES =
-
-# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
-# the generated latex document. The header should contain everything until
-# the first chapter. If it is left blank doxygen will generate a
-# standard header. Notice: only use this tag if you know what you are doing!
-
-LATEX_HEADER =
-
-# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
-# is prepared for conversion to pdf (using ps2pdf). The pdf file will
-# contain links (just like the HTML output) instead of page references
-# This makes the output suitable for online browsing using a pdf viewer.
-
-PDF_HYPERLINKS = YES
-
-# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
-# plain latex in the generated Makefile. Set this option to YES to get a
-# higher quality PDF documentation.
-
-USE_PDFLATEX = YES
-
-# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
-# command to the generated LaTeX files. This will instruct LaTeX to keep
-# running if errors occur, instead of asking the user for help.
-# This option is also used when generating formulas in HTML.
-
-LATEX_BATCHMODE = NO
-
-# If LATEX_HIDE_INDICES is set to YES then doxygen will not
-# include the index chapters (such as File Index, Compound Index, etc.)
-# in the output.
-
-LATEX_HIDE_INDICES = NO
-
-# If LATEX_SOURCE_CODE is set to YES then doxygen will include
-# source code with syntax highlighting in the LaTeX output.
-# Note that which sources are shown also depends on other settings
-# such as SOURCE_BROWSER.
-
-LATEX_SOURCE_CODE = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the RTF output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
-# The RTF output is optimized for Word 97 and may not look very pretty with
-# other RTF readers or editors.
-
-GENERATE_RTF = NO
-
-# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `rtf' will be used as the default path.
-
-RTF_OUTPUT = rtf
-
-# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
-# RTF documents. This may be useful for small projects and may help to
-# save some trees in general.
-
-COMPACT_RTF = NO
-
-# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
-# will contain hyperlink fields. The RTF file will
-# contain links (just like the HTML output) instead of page references.
-# This makes the output suitable for online browsing using WORD or other
-# programs which support those fields.
-# Note: wordpad (write) and others do not support links.
-
-RTF_HYPERLINKS = NO
-
-# Load stylesheet definitions from file. Syntax is similar to doxygen's
-# config file, i.e. a series of assignments. You only have to provide
-# replacements, missing definitions are set to their default value.
-
-RTF_STYLESHEET_FILE =
-
-# Set optional variables used in the generation of an rtf document.
-# Syntax is similar to doxygen's config file.
-
-RTF_EXTENSIONS_FILE =
-
-#---------------------------------------------------------------------------
-# configuration options related to the man page output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
-# generate man pages
-
-GENERATE_MAN = NO
-
-# The MAN_OUTPUT tag is used to specify where the man pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `man' will be used as the default path.
-
-MAN_OUTPUT = man
-
-# The MAN_EXTENSION tag determines the extension that is added to
-# the generated man pages (default is the subroutine's section .3)
-
-MAN_EXTENSION = .3
-
-# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
-# then it will generate one additional man file for each entity
-# documented in the real man page(s). These additional files
-# only source the real man page, but without them the man command
-# would be unable to find the correct page. The default is NO.
-
-MAN_LINKS = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the XML output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_XML tag is set to YES Doxygen will
-# generate an XML file that captures the structure of
-# the code including all documentation.
-
-GENERATE_XML = NO
-
-# The XML_OUTPUT tag is used to specify where the XML pages will be put.
-# If a relative path is entered the value of OUTPUT_DIRECTORY will be
-# put in front of it. If left blank `xml' will be used as the default path.
-
-XML_OUTPUT = xml
-
-# The XML_SCHEMA tag can be used to specify an XML schema,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_SCHEMA =
-
-# The XML_DTD tag can be used to specify an XML DTD,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_DTD =
-
-# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
-# dump the program listings (including syntax highlighting
-# and cross-referencing information) to the XML output. Note that
-# enabling this will significantly increase the size of the XML output.
-
-XML_PROGRAMLISTING = YES
-
-#---------------------------------------------------------------------------
-# configuration options for the AutoGen Definitions output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
-# generate an AutoGen Definitions (see autogen.sf.net) file
-# that captures the structure of the code including all
-# documentation. Note that this feature is still experimental
-# and incomplete at the moment.
-
-GENERATE_AUTOGEN_DEF = NO
-
-#---------------------------------------------------------------------------
-# configuration options related to the Perl module output
-#---------------------------------------------------------------------------
-
-# If the GENERATE_PERLMOD tag is set to YES Doxygen will
-# generate a Perl module file that captures the structure of
-# the code including all documentation. Note that this
-# feature is still experimental and incomplete at the
-# moment.
-
-GENERATE_PERLMOD = NO
-
-# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
-# the necessary Makefile rules, Perl scripts and LaTeX code to be able
-# to generate PDF and DVI output from the Perl module output.
-
-PERLMOD_LATEX = NO
-
-# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
-# nicely formatted so it can be parsed by a human reader. This is useful
-# if you want to understand what is going on. On the other hand, if this
-# tag is set to NO the size of the Perl module output will be much smaller
-# and Perl will parse it just the same.
-
-PERLMOD_PRETTY = YES
-
-# The names of the make variables in the generated doxyrules.make file
-# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
-# This is useful so different doxyrules.make files included by the same
-# Makefile don't overwrite each other's variables.
-
-PERLMOD_MAKEVAR_PREFIX =
-
-#---------------------------------------------------------------------------
-# Configuration options related to the preprocessor
-#---------------------------------------------------------------------------
-
-# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
-# evaluate all C-preprocessor directives found in the sources and include
-# files.
-
-ENABLE_PREPROCESSING = YES
-
-# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
-# names in the source code. If set to NO (the default) only conditional
-# compilation will be performed. Macro expansion can be done in a controlled
-# way by setting EXPAND_ONLY_PREDEF to YES.
-
-MACRO_EXPANSION = NO
-
-# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
-# then the macro expansion is limited to the macros specified with the
-# PREDEFINED and EXPAND_AS_DEFINED tags.
-
-EXPAND_ONLY_PREDEF = NO
-
-# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
-# in the INCLUDE_PATH (see below) will be search if a #include is found.
-
-SEARCH_INCLUDES = YES
-
-# The INCLUDE_PATH tag can be used to specify one or more directories that
-# contain include files that are not input files but should be processed by
-# the preprocessor.
-
-INCLUDE_PATH =
-
-# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
-# patterns (like *.h and *.hpp) to filter out the header-files in the
-# directories. If left blank, the patterns specified with FILE_PATTERNS will
-# be used.
-
-INCLUDE_FILE_PATTERNS =
-
-# The PREDEFINED tag can be used to specify one or more macro names that
-# are defined before the preprocessor is started (similar to the -D option of
-# gcc). The argument of the tag is a list of macros of the form: name
-# or name=definition (no spaces). If the definition and the = are
-# omitted =1 is assumed. To prevent a macro definition from being
-# undefined via #undef or recursively expanded use the := operator
-# instead of the = operator.
-
-PREDEFINED =
-
-# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
-# this tag can be used to specify a list of macro names that should be expanded.
-# The macro definition that is found in the sources will be used.
-# Use the PREDEFINED tag if you want to use a different macro definition that
-# overrules the definition found in the source code.
-
-EXPAND_AS_DEFINED =
-
-# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
-# doxygen's preprocessor will remove all references to function-like macros
-# that are alone on a line, have an all uppercase name, and do not end with a
-# semicolon, because these will confuse the parser if not removed.
-
-SKIP_FUNCTION_MACROS = YES
-
-#---------------------------------------------------------------------------
-# Configuration::additions related to external references
-#---------------------------------------------------------------------------
-
-# The TAGFILES option can be used to specify one or more tagfiles.
-# Optionally an initial location of the external documentation
-# can be added for each tagfile. The format of a tag file without
-# this location is as follows:
-# TAGFILES = file1 file2 ...
-# Adding location for the tag files is done as follows:
-# TAGFILES = file1=loc1 "file2 = loc2" ...
-# where "loc1" and "loc2" can be relative or absolute paths or
-# URLs. If a location is present for each tag, the installdox tool
-# does not have to be run to correct the links.
-# Note that each tag file must have a unique name
-# (where the name does NOT include the path)
-# If a tag file is not located in the directory in which doxygen
-# is run, you must also specify the path to the tagfile here.
-
-TAGFILES =
-
-# When a file name is specified after GENERATE_TAGFILE, doxygen will create
-# a tag file that is based on the input files it reads.
-
-GENERATE_TAGFILE =
-
-# If the ALLEXTERNALS tag is set to YES all external classes will be listed
-# in the class index. If set to NO only the inherited external classes
-# will be listed.
-
-ALLEXTERNALS = NO
-
-# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
-# in the modules index. If set to NO, only the current project's groups will
-# be listed.
-
-EXTERNAL_GROUPS = YES
-
-# The PERL_PATH should be the absolute path and name of the perl script
-# interpreter (i.e. the result of `which perl').
-
-PERL_PATH = /usr/bin/perl
-
-#---------------------------------------------------------------------------
-# Configuration options related to the dot tool
-#---------------------------------------------------------------------------
-
-# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
-# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
-# or super classes. Setting the tag to NO turns the diagrams off. Note that
-# this option also works with HAVE_DOT disabled, but it is recommended to
-# install and use dot, since it yields more powerful graphs.
-
-CLASS_DIAGRAMS = YES
-
-# You can define message sequence charts within doxygen comments using the \msc
-# command. Doxygen will then run the mscgen tool (see
-# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
-# documentation. The MSCGEN_PATH tag allows you to specify the directory where
-# the mscgen tool resides. If left empty the tool is assumed to be found in the
-# default search path.
-
-MSCGEN_PATH =
-
-# If set to YES, the inheritance and collaboration graphs will hide
-# inheritance and usage relations if the target is undocumented
-# or is not a class.
-
-HIDE_UNDOC_RELATIONS = YES
-
-# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
-# available from the path. This tool is part of Graphviz, a graph visualization
-# toolkit from AT&T and Lucent Bell Labs. The other options in this section
-# have no effect if this option is set to NO (the default)
-
-HAVE_DOT = NO
-
-# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is
-# allowed to run in parallel. When set to 0 (the default) doxygen will
-# base this on the number of processors available in the system. You can set it
-# explicitly to a value larger than 0 to get control over the balance
-# between CPU load and processing speed.
-
-DOT_NUM_THREADS = 0
-
-# By default doxygen will write a font called Helvetica to the output
-# directory and reference it in all dot files that doxygen generates.
-# When you want a differently looking font you can specify the font name
-# using DOT_FONTNAME. You need to make sure dot is able to find the font,
-# which can be done by putting it in a standard location or by setting the
-# DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory
-# containing the font.
-
-DOT_FONTNAME = Helvetica
-
-# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs.
-# The default size is 10pt.
-
-DOT_FONTSIZE = 10
-
-# By default doxygen will tell dot to use the output directory to look for the
-# FreeSans.ttf font (which doxygen will put there itself). If you specify a
-# different font using DOT_FONTNAME you can set the path where dot
-# can find it using this tag.
-
-DOT_FONTPATH =
-
-# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect inheritance relations. Setting this tag to YES will force the
-# the CLASS_DIAGRAMS tag to NO.
-
-CLASS_GRAPH = YES
-
-# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for each documented class showing the direct and
-# indirect implementation dependencies (inheritance, containment, and
-# class references variables) of the class with other documented classes.
-
-COLLABORATION_GRAPH = YES
-
-# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
-# will generate a graph for groups, showing the direct groups dependencies
-
-GROUP_GRAPHS = YES
-
-# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
-# collaboration diagrams in a style similar to the OMG's Unified Modeling
-# Language.
-
-UML_LOOK = NO
-
-# If set to YES, the inheritance and collaboration graphs will show the
-# relations between templates and their instances.
-
-TEMPLATE_RELATIONS = NO
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
-# tags are set to YES then doxygen will generate a graph for each documented
-# file showing the direct and indirect include dependencies of the file with
-# other documented files.
-
-INCLUDE_GRAPH = YES
-
-# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
-# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
-# documented header file showing the documented files that directly or
-# indirectly include this file.
-
-INCLUDED_BY_GRAPH = YES
-
-# If the CALL_GRAPH and HAVE_DOT options are set to YES then
-# doxygen will generate a call dependency graph for every global function
-# or class method. Note that enabling this option will significantly increase
-# the time of a run. So in most cases it will be better to enable call graphs
-# for selected functions only using the \callgraph command.
-
-CALL_GRAPH = NO
-
-# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
-# doxygen will generate a caller dependency graph for every global function
-# or class method. Note that enabling this option will significantly increase
-# the time of a run. So in most cases it will be better to enable caller
-# graphs for selected functions only using the \callergraph command.
-
-CALLER_GRAPH = NO
-
-# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
-# will generate a graphical hierarchy of all classes instead of a textual one.
-
-GRAPHICAL_HIERARCHY = YES
-
-# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
-# then doxygen will show the dependencies a directory has on other directories
-# in a graphical way. The dependency relations are determined by the #include
-# relations between the files in the directories.
-
-DIRECTORY_GRAPH = YES
-
-# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
-# generated by dot. Possible values are png, svg, gif or svg.
-# If left blank png will be used.
-
-DOT_IMAGE_FORMAT = png
-
-# The tag DOT_PATH can be used to specify the path where the dot tool can be
-# found. If left blank, it is assumed the dot tool can be found in the path.
-
-DOT_PATH =
-
-# The DOTFILE_DIRS tag can be used to specify one or more directories that
-# contain dot files that are included in the documentation (see the
-# \dotfile command).
-
-DOTFILE_DIRS =
-
-# The MSCFILE_DIRS tag can be used to specify one or more directories that
-# contain msc files that are included in the documentation (see the
-# \mscfile command).
-
-MSCFILE_DIRS =
-
-# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
-# nodes that will be shown in the graph. If the number of nodes in a graph
-# becomes larger than this value, doxygen will truncate the graph, which is
-# visualized by representing a node as a red box. Note that doxygen if the
-# number of direct children of the root node in a graph is already larger than
-# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
-# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
-
-DOT_GRAPH_MAX_NODES = 50
-
-# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
-# graphs generated by dot. A depth value of 3 means that only nodes reachable
-# from the root by following a path via at most 3 edges will be shown. Nodes
-# that lay further from the root node will be omitted. Note that setting this
-# option to 1 or 2 may greatly reduce the computation time needed for large
-# code bases. Also note that the size of a graph can be further restricted by
-# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
-
-MAX_DOT_GRAPH_DEPTH = 0
-
-# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
-# background. This is disabled by default, because dot on Windows does not
-# seem to support this out of the box. Warning: Depending on the platform used,
-# enabling this option may lead to badly anti-aliased labels on the edges of
-# a graph (i.e. they become hard to read).
-
-DOT_TRANSPARENT = NO
-
-# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
-# files in one run (i.e. multiple -o and -T options on the command line). This
-# makes dot run faster, but since only newer versions of dot (>1.8.10)
-# support this, this feature is disabled by default.
-
-DOT_MULTI_TARGETS = NO
-
-# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
-# generate a legend page explaining the meaning of the various boxes and
-# arrows in the dot generated graphs.
-
-GENERATE_LEGEND = YES
-
-# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
-# remove the intermediate dot files that are used to generate
-# the various graphs.
-
-DOT_CLEANUP = YES
generated by cgit v1.1 at 2024-11-09 15:16:30 +0000