BWD file tags

Binary formats and related hacking.

Moderator: Skyfaller

User avatar
Skyfaller
Clan 2nd MechWarrior
Clan 2nd MechWarrior
Posts: 991
Joined: Sat Apr 12, 2008 2:58 am
Location: Germany
Contact:

BWD file tags

Post by Skyfaller » Sun Nov 16, 2008 1:22 am

The current list of tags in a BWD file, mostly taken from quota4stupid's list, and broken into small sections for the individual tags.

The BWD file consists of tags. Each tag starts with a four-byte name, followed by a DWORD giving the tag's size, and the tag's data, if any.
AFFL - Set affiliation
8 - 11 : Affiliation

FIXME: Isn't documented by MW2DOC.HTM or Dan Kegers FAQ, but Kegers FAQ does contain the "affiliation" command
in a sample "xxxxAREx.WLD" file. Based on this usage, I assume it is intended to affiliate a particular
set of objects defined in a "xxxxAREx.WLD" file with a particular alliance (I assume the "affiliation"
field value matches an alliance ID (see "STAR" & "CAMO") but I will need to investigate a complete set
of mission BWD files to confirm this).
NB: Set by "affiliation" in "xxxxAREx.WLD" files.
ANIM - Set animation file for gamepiece
8 - 9 : Animation ID.
10 + : Animation name (ASCII) - NUL terminated and/or zero-padded??

NB: Animation ID & name identify an ANIM entry in the MW2.PRJ file (the name/ID pair given here
should match the name/ID pair in PRJ file, case-insensitive). For example, if name was "garganim",
then the animation file to use would be "MW2.PRJ$ANIM/GARGANIM.3DI".
NB: Set by "animfile" in "*.MEC" files???
ANM2 - ?
4 - 7 : Chunk size (20 for 31cc/GBL, 24 for Mercs)
8 + : ????

FIXME: Mercs Tools doco implies that this chunk will contain a list of 2D bitmap animations used in the cockpit,
and that the only one actually used is the static animation.
FIXME: Appears only in "MW2PIT.BWD".
ASND - Define ??? sound for mech???
8 - 9 : ID of SFL file in MW2.PRJ to use
10 + : Name of SFL file in MW2.PRJ to use (ie: "mechvft1" -> "MW2.PRJ$SNDS/MECHVFT1.SFL"). Appears to be
NUL terminated and/or zero padded??

FIXME: Links a sound file to a mech, but I'm not sure why yet - will have to listen to a few of the sound
files later to try to guess... Ambient/animation sounds????
UPDATE: Juding by the sounds associated with the TimberWolf and FireMoth, the linked file is the sound
of the Mechs footsteps as it is walking/running. The file associated with the Atlas was rather
garbled, which means my interpretation of the SFL format still has some work :-P
UPDATE: According to MW2DOC.HTM the sound is:
* Only loaded for the user gamepiece (mech)
* Played when the associated animation track hits the "s" code in its flags track
NB: Set by "AnimSound" in "*.MEC" files???
BLK - Start block
8 - 11 : X #1
12 - 15 : Y #1
16 - 19 : Z #1
20 - 23 : X #2
24 - 27 : Y #2
28 - 31 : Z #2

NB: Set by "block" in "xxxxAREx.WLD" file - terminated by "endblock" (see "ENDB").
NB: According to MW2DOC.HTM the "block/endblock" construct encapsulates a static block of data that
should be cached and loaded when the eyepoint (the user I presume) enters the given coordinate
range.
FIXME: It specifies the coordinates as "x, y, z dx, dy, dz", which suggests the second set of
values are width/height/depth, but based on the examples in DEM1, I believe "x1, y1, z1 x2, y2, z2"
designation is a more suitable interpretation (ie: two points that define a bounding box).
FIXME: Another possible interpretation of MW2DOC.HTM would be that the delta values apply on either side
of the first triplet (ie: the first three values identify the center of the bounding box????)
BLKX - Set block transformation
8 - 11 : Scale X (integer)
12 - 15 : Scale Y (integer)
16 - 19 : Scale Z (integer)
20 - 23 : Rotate X (degrees? - fixed point: divide by 65536 to get real number)
24 - 27 : Rotate Y (degrees? - fixed point: divide by 65536 to get real number)
28 - 31 : Rotate Z (degrees? - fixed point: divide by 65536 to get real number)
32 - 35 : Translate X (integer, cm?)
36 - 39 : Translate Y (integer, cm?)
40 - 43 : Translate Z (integer, cm?)

NB: Set by "block_xform" in "xxxxWLD1.WLD" file.
NB: According to MW2DOC.HTM this sets the transformation to be applied to the next "block/endblock" construct.
BMEN - ?
8 - 9 : Associated 3dbitmap_idlist ID.
10 - 11 : Type

Where type can be:
0 - Disable
1 - Enable
2 - One shot

NB: Set by "3dbitmap_enable" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).
BMID - ?
8 - 9 : List ID?
10 - 11 : Always 0xffff?

NB: As best I can tell these always follow one or more BMPJ tags (which identify XEL files) and assigns them an ID value.
NB: Based on the example MAP files in DEM1/DEM2, it looks like you can assign the same sequence of BMPJ tags different
ID values by following them with more than one BMID tag. I believe the BMPJ list is then reset once another BMPJ tag
is encountered *after* the BMID tags??
FIXME: Not sure what these IDs map to, but assume they have some relation to a value in the WTB files...
NB: Set by "3dbitmap_idlist" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).
BMPJ - ?
8 - 9 : ID of a texture file in the MW2.PRJ CEL folder
10 + : Name of a texture file (sans extension) in the MW2.PRJ CEL folder. Appears to be zero-terminated/padded??

NB: Set by "3dbitmap_prj" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).
NB: Based on the DEM1/DEM2 examples, it looks like the tag sequence is:
- One or more BMPJ tags.
- One or more sequences of: BMID [BSEC [BMEN]]
BSEC - ?
8 - 9 : Associated 3dbitmap_idlist ID.
10 - 11 : Time, in 1/180th seconds.

NB: Based on the DEM1/DEM2 examples, I think that the BSEC tag is used to animate a sequence of BMPJ tags (and their associated
BMID tag), where the time value is the time to elapse between one BMPJ and the next in sequence) ????
NB: Also based on DEM1/DEM2, it looks like the ID value is optional if only one BMID follows a collection of BMPJ tags?
NB: Set by "3dbitmap_sec" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).
BTHG - ?
8 - 9 : Object ID
10 - 11 : ? unk1 ?

NB: Always follows after an OBJ chunk. The "Object ID" field will always match the ID of the preceeding OBJ chunk.
(I have proven this programatically against all of the BWDs in 31cc/GBL/Mercs).
FIXME: I believe the unk1 field connects a set of BTHG chunks together - the value here always seems to be the same
for a consecutive set of BTHG chunks, after which the value is not used again in the same BWD file. The number of
BTHG in a group is variable. They don't necessarily appear in order.
FIXME: Appears in "xxxxSHTx.BWD"
BWD - "Header" tag
4 - 7 : Tag size = File size
8 - 11 : This is the size of the largest chunk in the BWD file (this size includes the four character type
field, chunk size field, and any embedded chunks).
Proven programmatically against all of the BWD files in 31cc, GBL & Mercs by quota4stupid

This header record is immediately followed by a "REV" record, then a "DTBL" record, and then the records
that make up the BWD payload.
CAMO - Set camo pattern for alliance
8 - 11 : Alliance ID (see "STAR" I think???? FIXME: Need to test this...)
12 - 15 : Camo pattern ID (see below)

The camo pattern IDs (taken straight from Dan Kegers Mercnet Mission Building FAQ):
0 - Plain steel panels
1 - Dark steel panels
2 - Medium steel panels
3 - Tiger stripe pattern
4 - Lined pattern
5 - Cow pattern
6 - Flat colored panels
7 - Pirate flat black panels

NB: Set by "camo" in the "xxxxSCN1.WLD" files.
CLIM - ?
8 - 31 : ???? (always zero?)

FIXME: Set by "???" in the "xxxxPLT1.WLD" file???
FIXME: Checked this chunk programatically - in all cases bytes 8-31 are always zero, across 31cc, GBL & Mercs,
except for ZACKPLT1.BWD & BRANPLT1.BWD in GBL - both have 0x0A at byte 12 (but all other bytes are zero).
CPGN - Define campaign parameters (????)
FIXME: TBI
FIXME: Appears in the "xxxxCAM1.WLD" files ????
FIXME: A quick inspection of a few hexdumps suggest that these "xxxxCAM1" files add additional mercs related parameters to missions
described by a matching "xxxxSCN1" file. The CPGN record appears to contain a number of embedded records (including "NEWS",
which seems to give the accompanying ComStar news report relating to the mission), and links to a variety of related BWD files
(including "xxxxSCN1", "xxxxBRF1", and other "xxxxCAM1" files (a believe the CAM links indicate the next mission, based on the
success or failure of this one).
CPTF - Define cockpit for mech??
8 - 9 : ID of CPI file in MW2.PRJ to use
10 + : Name of CPI file in MW2.PRJ to use (ie: "mw2mech" -> "MW2.PRJ$CPIT/MW2MECH.CPI"). Appears to be
NUL terminated and/or zero padded???

NB: ID and name must identify the same CPIT entry.
NB: Set by "cptfile" in mech definition "*.WLD" files???
DTBL - ????
8 - 27 : ????

FIXME: bwd\dtbl.txt contains a list of BWD files (for mercs) that contain a DTBL record with non-zero payload.
Looks to be mostly mechs and xxxxAREx files.
FIXME: Not sure what the purpose of this record is, but there is one in every BWD file immediately following
the "REV" record.
FIXME: Suspect this may be a "static data table" based on the following WASM.EXE message:
Error - BWD file is missing static data table chunk
Would need to test this by removing the DTBL chunk from a BWD in the project file and then including it in a WLD file
and running WASM I guess. Still no idea what it's for.
FIXME: I've got a sample MEC file for an Awesome floating around which, when compiled, has non-zero values in the DTBL chunk.
I would say that experimenting with this would be a good way to figure DTBL out some (in the very least, by removing
WASM commands one at a time I should be able to figure out which ones affect DTBL). NB: There is definately no command
that I can find to set the values explicitly - it seems to be implicit somehow.
ENDB - End block
NB: Set by "endblock" in "xxxxAREx.WLD" - terminates a "block" construct (see "BLK")
ENDR - Terminate a series of REPR records?
FIXME: Seems to terminate a series of REPR chunks (refer to REPR chunk later in this doc).
EYEO - Define eye object of pilot in mech??
8 - 11 : Object ID???

FIXME: TBI
FIXME: Appears in mech definition BWD files.
FIXME: Based on observation, quota4stupid believes that this chunk identifies an OBJ chunk to use as the location of the pilots
eye within a mech model. I assume this based on the fact that interpreting the 32-bit field as an object ID
seems to always identify an OBJ chunk that is:
- A child of the mech head object.
- Has a DUMMY mesh.
- Has a transform that positions it more or less behind the windshield geometry.
- As such I believe it is used to position the camera inside the mech model for the first person pilot view??
FTBL - Define mech formation table
8 - 15 : Formation name (ASCII)
16 - 23 : ???? (always zero?)

This is then followed by a series of 12-byte records that define the location and orientation of each mech in the formation:
0 - 3 : X coordinate (cm?)
4 - 7 : Y coordinate (cm?)
8 - 11 : Rotation (degrees?, 0 faces north?, cw/ccw?)

NB: Set by the "formation" construct in "xxxxFRM1.WLD".
GP - Define gamepiece ????
8 - 9 : Object ID (root object for gamepiece, defined previously in BWD)
10 - 11 : Type

Type values:
0x0001 - mw2mech
0x0002 - mw2truck
0x0003 - mw2artillery
0x0004 - mw2tank
0x0005 - mw2helicopter
0x0006 - mw2wanderer
0x0007 - mw2door
0x0008 - mw2aerotech

NB: Set by "gamepiece" command in *.mec files (gamepiece <object-name> <gp-type>)
GPS - Game Piece Specification
8-9: MEK File Number, FFFEh=-2: select file by name, below
10-11: BWD File Number, FFFEh=-2: select file by name, below
12 : Group ID (WASM accepts values from 0 to 16)
13 : Authority
14 - 15 : Control
16 - 17 : Gunnery skill
18 - 19 : Rubberband range
20 - 21 : Sleep range
22 - 23 : Target range
24 - 25 : Pilot skill
26 - 31 : ?unk?
32 - 33 : Applicable actions flags
34 : ?unk?
35 : Targeting
36 - 44 : Chassis name (MEC BWD filename sans extension), NUL-terminated
45 - 53 : Config name (MEK filename sans extension), NUL-terminated
54 - 75 : Target text, NUL terminated (max length 21 - WASM silently discards anything past that)
76 - 97 : Content text, NUL terminated (max length 21 - WASM silently discards anything past that)
98 - 99 : ?unk?

Authority values:
0 - follower
1 - leader

Control values:
0 - user
1 - remote
2 - internal

Targeting values:
0x00 - NoTarget
0x04 - <none - no value specified>
0x0c - NeverTarget
0x14 - AlwaysTarget
GT - Define gamething ????
8 - 9 : ID of object this record applies to - see "OBJ"
10 - 11 : ID of alternate object (replaces the main object when the GT is destroyed, 0xffff=none)
12 - 15 : (always 0xffffffff) ????
16 - 19 : (always 0xffffffff) ????
20 - 23 : (always 0xffffffff) ????
24 - 25 : Strength/health (how many points of damage the GT can take before it is destroyed)
26 - 27 : Allowed goal flags
28 - 29 : Chunky flag (true=0x8000) ????
30 - 31 : (always 0) ????
32 - 75 : Description (this text is displayed when the GT is targeted)

Goal flag values:
0x0000 - None
0x0002 - Destroy
0x0004 - Defend
0x0008 - Recon
0x0020 - Return
0x0030 - Begin
0x0100 - Goto
0x0200 - Wait
0x0400 - Sleep
0x0800 - Shutdown
0x2000 - Leave

FIXME: Kegels FAQ doesn't explain what the chunky flag is for??? I believe that this signals
to the sim that this GT is the chunks for another object (since the only other way to
tell, as far as I can see, is from the naming convention used for the WTB files, but
since this is a *convention* I suspect the flag is required to make it definitive).
NB: According to Dan Kegels FAQ, declaring an object to be a "gamething" means it can be
targeted with "q", inspected and destroyed.
NB: Set by "gamething" in"xxxxAREx.WLD" files ????
HRZM - Set horizon gradient
8 - 11 : Color ??
12 - 15 : Height ??
16 - 19 : Unused (can't set with WASM as far as I can tell?)
20 - 23 : Unused (can't set with WASM as far as I can tell?)
24 - 27 : Unused (can't set with WASM as far as I can tell?)
28 - 31 : Unused (can't set with WASM as far as I can tell?)

FIXME: The following from Dan Kegers Mission Building FAQ:
horizon_map 0,75,0 0 0 0
horizon_map - This defines the length of the horizon gradient.
But he doesn't explain what the parameters mean, nor their range of values :-(
FIXME: At this stage, I'm not even sure if the 6 parameters to horizon_map are writen in
sequence to our 6 32-bit word slots above :-P
FIXME: According to MW2DOC.HTM, the declaration is actually "horizon_map <color> <height>"
and that the <color> parameter is "unknown. Set to 0" :-P No mention of those last
two parameters at all :-( The <height> parameter is the "height, in pixels, of the
horizon ramp".
NB: Set by "horizon_map" in "xxxxPLT1.WLD".
HTXT - Set hidden text
8 - 23 : Default string for any object that is inspected and doesn't have an explicit description (ASCII).
This string has a maximum length of 15 characters, and MUST be NUL terminated.

NB: Set by "hidden_text" in "xxxxPLT1.WLD".
HUDF - Set HUD file for mech
8 - 9 : ID of HUD file in MW2.PRJ to use.
10 + : Name of HUD file in MW2.PRJ to use (ie: if this field is "mw2hud" then use "MW2.PRJ$HUD/MW2HUD.HDI").
Appears to be NUL terminated and/or zero-padded???

NB: ID and name must identify the same HUD entry.
NB: Set by "hudfile" in mech definition "*.WLD" files???
INCL - Include BWD file
8 - 9 : ID of BWD file to include
10 - 19 : Name of BWD file to include (ie: "bet1brf1" -> "MW2.PRJ$BWD/BET1BRF1.BWD")

NB: Set by "include" command in a variety of "*.WLD" files.
INIT - Init sim clock (?)
8 - 11 : 00000000 ????
12 - 15 : 00000000 ????
16 - 19 : Time of day (0=dawn, 1=day, 2=dusk, 3=night, "now" digit 1)
20 - 23 : Unused ("now" digit 2)
24 - 27 : 00000000 ????

NB: Set by "now" in "xxxxPLT1.WLD".
FIXME: Unsure if the other parameters are set by anything?
LITE - Set light source
8 - 11 : ???? (always zero?)
12 - 15 : ???? (always zero?)
16 - 19 : Light X coordinate (cm)
20 - 23 : Light Y coordinate (cm)
24 - 27 : Light Z coordinate (cm)
28 - 29 : Ambient light level (integer, 0 - 256)
30 - 31 : Light type (0=point, 1=directional)
32 - 35 : Shade distance (cm) (objects outside this range are only light by ambient light, not the main light source)
36 - 39 : ???? (always one??)

NB: Set by "light", "ambient" and "shadedist" in "xxxxPLT1.WLD".
FIXME: Unsure what if anything sets the unknown values??? Maybe experiment with "lightobj" ?????

NB: Appear to only be able to define one light source - if multiple light sources are defined in the WLD file, the last one is used,
and the ones before it seem to be ignored.
LITO - ???
8 - 11 : ? unk1 (always zero?) ?

FIXME: Lit object???
NB: Only appears in 31cc & GBL (in xxxxPLT1.BWD).
LTBL - Set light table (?)
8 - 9 : ???? (observed values are 1 & 2)
10 - 17 : Name of luminosity lookup table to use (ie: "standard" or "FOG")
18 - 21 : ???? (always zero???)
22 - 23 : ???? (always zero???)

NB: Set by "luma" in the "xxxxPLT1.WLD" file.
FIXME: Unsure what sets the unknown values???
MGDF - Set additional geometry information file for mech
8 - 9 : ID of MGI file in PRJ file to use
10 + : Name of MGI file in PRJ file to use. Appears to be NUL terminated and padded to an
even number of bytes (ie: "timbrwlf" identifies "MW2.PRJ$MGEO/TIMBRWLF.MGI")

NB: ID and name must identify the same MGEO entry.
FIXME: Set by "mgdfile" in mech definition "*.WLD" files???
FIXME: According to Merc Tools doco: "The Mech Geometry file contains some additional data required
to fully simulate the gamepiece. " This seems to include stuff like Y offset (height) of the
root object from the ground, max torso/turret twist, etc etc.
MLIT - Multiple light source creation
8 - 11 : Position X (integer, cm) ????
12 - 15 : Position Y (integer, cm) ????
16 - 19 : Position Z (integer, cm) ????
20 - 23 : Radius (integer, cm) ????

NB: Used to define additional light sources to that defined by "LITE". The (x, y, z) coordinate
is the position of the light center and radius defines the size of the area affected by it.
FIXME: I can't be sure about the layout of the fields above, as there appears to be a bug in WASM
when parsing the light_begin/end construct? (the sample I tried from the MW2DOC.HTM, plus
a few other tests, put the radius where I believe the Z coordinate should be, and completely
disregarded the Y and Z coordinates I provided)-:
NB: Set by "light_begin/light_end" construct in "xxxxAREx.WLD" and "xxxxSMO1.WLD" files.
MOFF - Mangle Off
NB: Set by "mangle_off" in various geometry "*.WLD" files - terminates "mangle_on" (see "MON")
MON - Mangle On
FIXME: Dunno what this is for exactly, but MON and MOFF seem to wrap any BWD that defines a physical entity
(ie: mech, dunes, buildings, etc). MON always appears to be the first record in these files, and MOFF
is the final record. Clearly seems to be flagging some condition - M ON and then M OFF - but what the
hell is "M"??
UPDATE: Judging by some of the demo source files, "M" stands for "mangle" (in the source file it's mangle_on
and mangle_off), but it's not documented in the world building information, so I still dunno what it's for :-P
UPDATE: According to Dan Kegels Mission Building FAQ, enclosing stuff in mangle_on/off will ensure that all
names defined within the block are unique, but doesn't specify exactly how it does that (etc). Given that
they appear as tags in the BWD, I can only assume it's not done by wasm.exe, but at runtime by the sim???
NB: Set by "mangle_on" in various geometry "*.WLD" files.
MTBL - Set mission objective table for star
8 - 11 : ID of star this mission table applies to (see "STAR")
12 - 15 : Mission time (signed integer, seconds, -1=infinite time)
16 - 17 : ID of mission success audio file (in "MW2.PRJ$SNDS")
18 - 26 : Name of mission success audio file (in "MW2.PRJ$SNDS", with ".SFL" extension)
27 - 28 : ID of mission fail audio file (in "MW2.PRJ$SNDS")
29 - 37 : Name of mission fail audio file (in "MW2.PRJ$SNDS", with ".SFL" extension)

This is then followed by a series of 151 byte records:
0 - 1 : Action
2 - 3 : (always 0) ???
4 - 5 : Type
6 - 9 : Activation record logic operator (all 4 bytes? probably not)
10 - 13 : Activation record #1
14 - 17 : Activation record #2
18 - 21 : Activation record #3
22 - 25 : Activation record #4
26 - 29 : Activation record #5
30 - 33 : Activation record #6
34 - 37 : Activation record #7
38 - 41 : Activation record #8
42 - 45 : Time (integer, seconds)
46 : Priority
47 : Critical
48 : Mechs per target
49 : Do-not-disturb (AI only)
50 - 51 : Success audio ID (0xffff=none)
52 - 60 : Success audio name
61 - 62 : Fail audio ID (0xffff=none)
63 - 71 : Fail audio name
72 - 73 : Target BWD ID
74 - 82 : Target BWD name
83 - 84 : ? WASM sets this to 0 if a target objective number is specified, -1 if there is none ?
85 - 86 : Target objective number (ie: userstar_4) or -1 if none.
87 - 150 : Objective description text (ASCII)

Activation record format:
0 : Result
1 : Objective number
2 : Star number
3 : (always 0) ????

Activation record result values:
0x43 - C(ompleted)
0x46 - F(ailed)
0x49 - Initial
0x53 - S(ucceeded)
0xff - None

Activation record logic operator values:
0 - OR
1 - AND

Type values:
0x48 - Hidden
0x56 - Visible

Priority values:
0x00 - None
0x01 - Primary
0x02 - Secondary
0x04 - Tertiary
0x08 - Return

Critical values:
0x4d - Mandatory
0x4f - Optional

Do-not-disturb values:
0 - Attack enemies if they come in range
1 - Attack enemies only if fired upon
2 - Ignore enemies and focus on objective

Action values:
0x0000 - None
0x0002 - Destroy
0x0004 - Defend
0x0008 - Recon
0x0020 - Return
0x0030 - Begin
0x0100 - Goto
0x0200 - Wait
0x0400 - Sleep
0x0800 - Shutdown
0x2000 - Leave

NB: According to MW2DOC.HTM, the Target BWD file contains the objects that are the target of the objective.
For example, for a "begin" objective, the target should be a navpoint. For "destroy" or "defend" it
should be a building (etc).
FIXME: Does star ID (field 8-11) match with group_id in gp_spec???
FIXME: In the mission table, the "Begin" action appears as 0x0010, rather than the 0x0030 as it does everywhere else
(is this perhaps an error in WASM????)
FIXME: Have codes for all of the action types, except for "Objsucceed", "Objfail", "Objshow", "Msnsucceed" and "Msnfail".
NB: Set by "mission/end" construct in "xxxxSCN1.WLD" files.
MUSI - Set music track for mission
8 - 9 : ID of music track in MW2.PRJ
10 - 23 : Name of music track in MW2.PRJ (ie: "track12" -> "MW2.PRJ$MUS/TRACK12.MUS")

NB: Identifies the music track file in MW2.PRJ to play for the mission.
FIXME: I believe this *.MUS file is used to identify a CD track to play???
NB: Set by "music" in the "xxxxSCN1.WLD" file.
NAVP - Define navpoint
8 - 11 : X (cm)
12 - 15 : Y (cm)
16 - 19 : Z (cm)
20 - 21 : Always 0 ????
22 - 23 : Starting angle of gamepieces if this is a start point
24 - 25 : Enabled for targeting by group (1=TRUE)
26 - 27 : Flags (unused, set to 0)
28 - 29 : Key (unused, set to 0)
30 - 31 : ID of group that owns the navpoint
32 - 33 : Radius (m)
34 - 35 : Action flags
36 - 56 : ASCII text displayed when targeted (spec says 20 chars, but seems to allow 21)
57 - 79 : Always 0 ????

Action flag values:
0x0002 - Destroy
0x0004 - Defend
0x0008 - Recon
0x0020 - Return
0x0030 - Begin
0x0100 - Goto
0x0200 - Wait
0x0400 - Sleep
0x0800 - Shutdown
0x2000 - Leave

NB: Set by "navpoint" in "xxxxSTx1.WLD", "xxxxGOUx.WLD", "xxxxGOEx.WLD", "xxxxNAVx.WLD" and "xxxxLVEx.WLD".
FIXME: Does "navobject" also set this chunk, or something else??? Need to test with WASM. (I think it sets NAVO chunk).
OBJ - Define object
8 - 9 : Object ID (unique within the scope of the parent container ("REPR", "BLK"????, BWD file), starting from zero) ????
10 - 11 : Parent object ID (0xffff=world, 0xfffe=fixed)
12 - 13 : Collision type
14 - 17 : Scale X (integer)
18 - 21 : Scale Y (integer)
22 - 25 : Scale Z (integer)
26 - 29 : Rotate X (degrees? - fixed point: divide by 65536 to get real number) ????
30 - 33 : Rotate Y (degrees? - fixed point: divide by 65536 to get real number) ????
34 - 37 : Rotate Z (degrees? - fixed point: divide by 65536 to get real number) ????
38 - 41 : Translate X (integer, cm)
42 - 45 : Translate Y (integer, cm)
46 - 49 : Translate Z (integer, cm)
50 - 51 : Scrounge type (MW2DOC.HTM says: 0 or 1 for objecType=Scrounge, and 0 otherwise - purpose unknown?)
52 - 53 : Object type
54 - 55 : ???? (always zero????)
56 - 57 : ID of mesh in "MW2.PRJ$POLY"
58 - 59 : ???? (always zero????)

Object type values:
0x0000 - None
0x0010 - Flame
0x0020 - Explosion
0x0030 - Scrounge
0x0040 - Chunklet
0x0050 - Chunk
0x0060 - Rotator
0x0070 - Hidden
0x0090 - Far
0x00a0 - Near
0x00b0 - Landmine
0x00c0 - Expendable
0x08c0 - Mirage
0x0800 - Terrain

Collision type values:
0x0000 - Orthorect
0x0001 - Cylinder
0x0002 - ceiling
0x0003 - Orthorotate
0x0004 - Null
0x0005 - Ground
0x0006 - Sphere
0x0007 - AllPoly

FIXME: MW2DOC.HTM only gives a few hints about the purpose of "object type"???
FIXME: The object ID field is based only on hexdump observation at present, and is yet to be proved by WASM tests
(ie: by setting the parentObject field to something other than fixed/world). The scope of the ID is still to
be confirmed (at present the BWD file / "REPR" level appears to be confirmed based on ATLAS.BWD, but I'm only
guessing on "BLK", though it seems logical).
FIXME: Based on observation (only of ATLAS.BWD so far) the first object in a mech BWD has type "HIDDEN" and identies
"DUMMY.WTB" for its mesh - I believe this is meant to be a virtual root node. It also has collision type 0xffff?!
NB: Set by "object" (and "collision"???) in "xxxxAREx.WLD" and mech geometry files???
OBJL - ?
8 - 9 : Object ID ???
10 - 11 : Group ID ???

FIXME: TBI
FIXME: Appears in mech definition WLD files.
FIXME: Based on observation, I believe this chunk is used to group OBJ chunks together for purposes of the wireframe mech
damage display in the cockpit. The "Group ID" values seem to be:
1 - Head (for ATLAS, this is the windshield mesh)
2 - Right torso ? (not used in mechs, only seems to be used in aircraft - ie: REIVER - right fuselage & fin)
3 - Center Torso (for ATLAS, this is the head and hip meshes)
4 - Left torso ? (not used in mechs, only seems to be used in aircraft - ie: REIVER - left fuselage & fin)
5 - R Arm
6 - L Arm
7 - R Leg
8 - L Leg
ORDR - Provide orders for briefing & debriefing ????
8 + : Order text (zero-padded to a multiple of four bytes????)

NB: Order text uses the following control codes:
\n Newline
\c Center text on line
\t Tab
\s Hard page (??? - in practise, this seems to split the order into "Briefing" and "Situation" sections in Mercs)
\q Includes information returned by sim (used in debriefing) ????
\r0 Current rank
\r1 Next rank
\r2 Rank after next
\l ????
\p ????

NB: Set by "orders_begin" & "orders_end " in "xxxxBRF1.WLD", "xxxxDBFF.WLD" and "xxxxDBFS.WLD".
PALG - Sets the palette files used by the sim
8 - 9 : ID of day standard palette in MW2.PRJ$PAL
10 - 11 : ID of day explosion palette in MW2.PRJ$PAL
12 - 13 : ID of day flash palette in MW2.PRJ$PAL
14 - 15 : ID of day smoke palette in MW2.PRJ$PAL
16 - 17 : ID of dusk standard palette in MW2.PRJ$PAL
18 - 19 : ID of dusk explosion palette in MW2.PRJ$PAL
20 - 21 : ID of dusk flash palette in MW2.PRJ$PAL
22 - 23 : ID of dusk smoke palette in MW2.PRJ$PAL
24 - 25 : ID of night standard palette in MW2.PRJ$PAL
26 - 27 : ID of night explosion palette in MW2.PRJ$PAL
28 - 29 : ID of night flash palette in MW2.PRJ$PAL
30 - 31 : ID of night smoke palette in MW2.PRJ$PAL
32 - 33 : ID of IR standard palette in MW2.PRJ$PAL
34 - 35 : ID of IR explosion palette in MW2.PRJ$PAL
36 - 37 : ID of IR flash palette in MW2.PRJ$PAL
38 - 39 : ID of IR smoke palette in MW2.PRJ$PAL
40 - 41 : ID of black palette in MW2.PRJ$PAL
42 - 43 : ID of red palette in MW2.PRJ$PAL
44 - 45 : ID of cockpit palette in MW2.PRJ$PAL
46 - 47 : ID of alternate palette in MW2.PRJ$PAL

NB: These are set by "palette_grp" and "palette_misc" in "xxxxPAL1.WLD".
PDSC - Planet description ???
8 - 11 : ? unk1 ?
12 + : Description (plain text)

FIXME: Appears to provide a brief planet description for Trial of Grievance missions (planet name and environment).
FIXME: Not sure what the unk1 is for though...
NB: Only appears in 31cc & GBL (in xxxxBRF2.BWD).
PILT - Define mechwarrior pilot (can be hired in Mercenaries)
8 - 39 : Pilot name (ASCII)
40 - 41 : Gunnery skill
42 - 43 : Rubberband range
44 - 45 : Sleep range
46 - 47 : Target range
48 - 49 : Pilot skill
50 - 51 : Mech affiliation (FIXME: What is it???)
52 - 53 : Personality
54 - 55 : Voice ID (FIXME: What is it???)
56 - 59 : Pilot salary
60 - 75 : Chassis name (name of gamepiece file in BWD folder, sans extension)
76 - 91 : Config name (name of configuration file in MEK folder, sans extension)

After this comes what appears to be an embedded record:
8 + : Pilot description text (ASCII) (including callsign, gunnery & piloting grades, psychological
profile & career history). Includes some escape codes (only witnessed \n for newline so far).
Appears to be zero-padded to a multiple of 4 bytes???

FIXME: In all of the PILOTx.BWD files I've looked at from the project file, "chassis" and "config"
are both set to "dizz" - wtf is this?!
FIXME: WASM appears to only accept values between 0 and 32,767 for pilot salary, however the value is
written as 32-bits - the value 32,768 is output as 0xffff8000 (-32,768). Need to check if the
sim accepts values outside this range (ie: is this a WASM bug?).
NB: Set by pilot_begin/pilot_end in "PILOTx.WLD" files.
PITF - Define ??? for mech?
8 - 9 : ID of BWD file in MW2.PRJ to use
10 + : Name of BWD file in MW2.PRJ to use (ie: "mw2pit" -> "MW2.PRJ$BWD/MW2PIT.BWD"). Appears to be NUL
terminated and/or zero-padded???

FIXME: According to Merc Tools doco, the PIT File contains a list of the 2D bitmap animations that are used
in the 2D cockpit.
NB: Set by "pitfile" in mech definition "*.WLD" files???
PLNT - Set planet parameters
8 - 11 : Gravity (signed integer / 65536.0 = float value) (0.0 - 4.0)
12 - 15 : Atmosphere (always 0)
16 - 19 : No. days in year (integer)
20 - 23 : No. seconds in day (integer)
24 - 27 : Axial tilt (integer)
28 - 31 : Circumference (integer)
32 - 35 : Unknown - always 0????
36 - 39 : Mean temp. (integer, celcius)
40 - 43 : Max. jump height (cm)
44 - 47 : Max. terrain height (cm)
48 - 51 : Min. terrain height (cm)
52 - 55 : Friction coefficient (0.0 - 1.0, determines max steepness a mech can walk up, with 1.0 being the steepest)
56 - 59 : Can pilot eject? (boolean, 0=false 1=true)
60 - 63 : Reverse damage shading? (boolean, 0=false 1=true, should be enabled for fog worlds)
64 - 67 : No light shifting? (boolean, 0=false 1=true, no longer used - should always be 1)
68 - 71 : Hide sky? (boolean, 0=false 1=true, if TRUE the sim doesn't draw the sky)
72 - 75 : Hide ground? (boolean, 0=false 1=true, if TRUE the sim doesn't draw the ground)
76 - 79 : Hide horizon? (boolean, 0=false 1=true, if TRUE the sim doesn't draw the horizon gradient)

NB: Set by "planet", "planet2" and "planet3" in "xxxxPLT1.WLD".
POFO - Set point-of-fire object?
8 - 9 : Object ID ???
10 - 11 : Pofo ID ???

FIXME: TBI
FIXME: Appears in MEC files.
FIXME: Based on observation, I believe that these chunks define "point of fire" on gamepiece BWDs. I base this on:
- The "Object ID" field always identifies an OBJ chunk that uses a DUMMY mesh.
- On the models I've been able to observe with my shonky renderer (and where I've put in special case handling
code to draw a big red sphere anytime the DUMMY mesh is used) most of the identified dummy objects appear in
logical weapon fire locations (ie: in front of the mechs arms, just below the center torso (hip), in front of
the center torso, etc).
- I figure the last field for the "Pofo ID" because within any given BWD (that I've checked) these numbers form
a consecutive range (not necessarily in order), starting from zero.
- In a nutshell, I believe each POFO chunk creates a map between a zero-based ID value and a dummy object in the
model from which weapons fire geometry should originate (laser, missiles, etc).
PTBL - Define path
8 - 71 : Path name (ASCII)

This is then followed by a series of point records of the form:
0 - 3 : X (integer, cm)
4 - 7 : Y (integer, cm)
8 - 11 : Z (integer, cm)
12 - 15 : Rotate X (integer, degrees)
16 - 19 : Rotate Y (integer, degrees)
20 - 23 : Rotate Z (integer, degrees)
24 - 27 : Travel time from this point to the next (in 1/182 seconds - ie: 0xb6=1 second)

FIXME: I'm not 100% certain of the length of the "path name" field (maximum length not specified in MW2DOC.HTM),
but the given range of bytes are either all for the name, or part for the name with the rest unused, as
best as I can tell.
FIXME: Could test this with WASM....
NB: Defines a series of points for use the "path" animation task (see "TSK" & MW2DOC.HTM for details).
NB: Set by "path" construct in "xxxxAREx.WLD" files, or anywhere else the "TSK" record is used.
REPR - Start object LOD representation ????
FIXME: TBI
FIXME: Based on observation of ATLAS.BWD, it appears to encapsulate a LOD for an object (mech, buildings, terrain, etc)?????
FIXME: Also based on observation, each "REPR" appears to be terminated by the next "REPR" or (finally) by an "ENDR" record.
FIXME: Since it doesn't contain any fields (and based on observation of ATLAS.BWD) I assume that LOD level is assigned
implicitly in the order the "REPR" records occur, starting with the highest LOD, and ending with the least LOD.
FIXME: Appears in mech definition WLD files - seems to be terminated by the "ENDR" record.
REV - Record of WASM version used to created BWD
8 - 11 : Version of WASM used to generate the file (ASCII - always "1.22"??)

NB: Appears in every BWD file between the main header record and the "DTBL" record.
FIXME: My interpretation appears to be supported (apart from the fact that 1.22 is the version of WASM shipped with Mercs tools)
by the following warning/error messages in WASM.EXE:
Warning - BWD file generated by WASM rev %s - Current WASM is rev %s
Error - BWD file generated by old WASM version - Current WASM is rev %s
If this chunk isn't intended to convey the version of WASM used, then I don't see how else it could tell. It should be
relatively straight forward to test this theory (ie: modify the REV string of a BWD in the project file, and then include
this BWD in a WLD file and compile it with WASM - WASM should print one of these error messages).
SCRG - ?
8 - 11 : Always 0

FIXME: TBI
FIXME: Used in "xxxxSCRI.WLD" files (something to do with "scrounge") ????
FIXME: No idea what these are for. Ran a check on the project files for 31cc, GBL & Mercs, and in all
cases, the field @8 is ALWAYS zero. Can only assume the chunk is a marker of some sort with a
useless payload :-P
SDSC - Star description
8 - 11 : Pilot rank (from 1 to 8, where 1=best and 8=worst, determines AI level)
12 - 15 : Max tonnage (heaviest mech that may be in a star)
16 - 19 : Recommended number of mechs for mission
20 - 23 : Maximum number of mechs for mission
24 - 39 : Name of default mech for user (MEK file)
40 - 55 : Name of default mech for starmate #1 (MEK file)
56 - 71 : Name of default mech for starmate #2 (MEK file)

NB: Set by "sdesc" command in xxxxBRF2.WLD files.
STAR - Define mech star arrangements
A series of 24 byte records:
0 - 3 : Alliance ID (see below)
4 - 7 : Disposition (0=Friendly, 1=Enemy, 2=Neutral)
8 - 15 : Name of formation to use (matches the name in an FTBL record - match appears to be case insensitive?)
16 - 19 : (unknown - always zero) ????
20 - 23 : (unknown - always zero) ????

The alliance IDs are:
0 - FC
1 - Draconis
2 - FRR
3 - Wolf
4 - SmokeJaguar
5 - GhostBear
6 - Wild1
7 - Wild2

NB: This matches the order of the alliances as specified in the xxxxSCN1.WLD file. If these entries
are reordered, then the values in the BWD file *WILL* change. However, I would suspect that since
the name isn't stored in the BWD but only the index value that the mapping of ID values to alliance
logos is probably fixed in *THIS* order (ie: I think if you reorder the alliance names in the WLD
files, you'll just end up with your mechs having the wrong logo???).
FIXME: Each entry under STAR is linked to a GPS record (according to MW2DOC.HTM, this link is a group_id
field in the gp_spec record; on the STAR record end, this ID is implicit based on the order the
records are declared, starting at zero). Need to make sure this all matches up.

NB: Set by the "star" construct in "xxxxSCN1.WLD".
SUPS - Set startup screen
8 - 23 : Name of image file to display while world is loading (although this field is, or appears to
be, 16 bytes long, the max length of the name is actually 7 according to MW2DOC.HTM)

FIXME: I have absolutely *NO* idea where exactly this file is located :-( I couldn't find any of the
filenames from sample SUPS in the MW2.PRJ file. The next most logical place is probably
DATABASE.MW2, but these entries don't have names????
NB: Set by "supscreen" in the "xxxxBRF2.WLD" file.
TECH - Define aerotech pilot (can be hired in Mercenaries)
8 - 39 : Pilot name (ASCII)
40 - 41 : Gunnery skill
42 - 43 : Rubberband range
44 - 45 : Sleep range
46 - 47 : Target range
48 - 49 : Pilot skill
50 - 51 : Mech affiliation (FIXME: What is it???)
52 - 53 : Personality
54 - 55 : Voice ID (FIXME: What is it???)
56 - 59 : Pilot salary
60 - 75 : Chassis name (name of gamepiece file in BWD folder, sans extension)
76 - 91 : Config name (name of configuration file in MEK folder, sans extension)
92 + : Embedded "DSSR" chunk (refer to "PILT" chunk)

NB: Set by tech_begin/tech_end in "AEROTECx.WLD" files.
THNG - ?
8 - 11 : Thing OBJect ID ????

FIXME: TBI
FIXME: Every mech appears to have two of these tags.
FIXME: Mercs Tools doco states "Programmatically controlled objects are typically identified in the thing
directive shown below." Unfortunately it doesn't actually define this directive :-P
FIXME: Based on a few observations:
- I believe the 32-bit THNG field is meant to match an OBJ chunk object ID defined previously in the BWD
- If this is correct, it should be noted that the two THNG chunks that appear in mech BWDs identify the
mechs head object and a dummy object that the mechs arms are attached to.
- Considering the directive description from the FAQ, I would guess that this identifies parts of the mech
geometry that are transformed programatically - ie: the first (head) would probably be for torso twist
(since the entire upper part of the mechs geometry seems to be descended from this node), not sure about
the second one... tilt forward/backward maybe???
- This theory is further supported by the fact that in TANKA.BWD, the first THNG identifies the tank turret,
and the second identifies the gun barrel (torso twist & tilt would work here).
- BODYSUIT.BWD has no THNG chunks (kind of makes sense - they can't torso twist... can't tilt either??)
- AEROA.BWD also has no THNG chunks.
- DROPA.BWD & DROPZ.BWD each have two THNG chunks that identify the same object - a DUMMY with multiple DUMMY children.
TSK - Define animation task?
8 - 9 : Task name
10 - 13 : Update period (in game cycles, 0=update on every cycle - 182 cycles/second according to Merc Tools doco)
14 + : Task parameters (ASCII, zero-padded to a multiple of 4 bytes???)

Task name values:
0x0000 - Spinner
0x0001 - ColorSpin
0x0002 - FlyCircle
0x0003 - Animator
0x0005 - Path
0x0004 - AmbientSound

NB: The task parameters are copied verbatim from the WLD file into this record, except that any references
to objects by name are resolved into their integer IDs (or the ASCII text representation of that integer).
NB: Refer to MW2DOC.HTM for task parameter documentation - couldn't be arsed copying it all into here ;-P
NB: According to MW2DOC.HTM (2.1) - all task definitions refer to the most recently loaded 3DI file ("ANIM").
Once a new 3DI file is loaded, all subsequent tasks refer to it.
NB: Set by "task" in various geometry "*.WLD" files (ie: "xxxxAREx.WLD", mech definition files, etc).
VIEW - Set view parameters
8 - 11 : Near clipping plane (cm)
12 - 15 : Far clipping plane (cm)

NB: Set by "view" in the "xxxxPLT1.WLD" file.
VPTF - Set View Port File for mech
8 - 9 : ID of BWD file in MW2.PRJ to use
10 + : Name of BWD file in MW2.PRJ to use (ie: "mw2mech" -> "MW2.PRJ$BWD/MW2MECH.BWD"). Appears to be NUL
terminated and/or zero-padded????

NB: Identifies the View Port File to use for a mech. The View Port File is a BWD file containing a VWSP chunk.
This file is used to position view screens (ie: radar) in the cockpit.
NB: Set by "vptfile" in MEC files???
VWSP - ?
This is then followed by a series of eight 32-byte records:
4 - 7 : ? X ?
8 - 11 : ? Y ?
12 - 15 : ? Width ?
16 - 19 : ? Height ?
20 - 31 : ? always 0 ?

Type values are (I think):
0 - VIEW_INTERNAL_FRONT (Internal front view w/ Cpit on - used to clip bottom of screen)
1 - VIEW_INTERNAL_RIGHT (Not used)
2 - VIEW_INTERNAL_LEFT (Not used)
3 - VIEW_INTERNAL_UP (Not used)
4 - VIEW_EXTERNAL (External view - track or independent)
5 - VIEW_AUX_0 (Cpit view screen used for rear and missile eye views)
6 - VIEW_AUX_1 (Cpit view screen used for radar - fixed and directional)
7 - VIEW_AUX_2 (Not used)

FIXME: TBI
FIXME: Appears only in "MW2MECH.BWD".
FIXME: The Mercs Tools doco suggests that the 32-byte records are created with a series of "window" declarations,
and that "This file may not be necessary with a 3D cockpit" (refer to "VPT File", near end of doco).
FIXME: Not sure if I've ordered the x/y/width/height fields correctly, but am pretty sure that that's what they
are (since doco says the "window" declaration sets the "size and screen location of a viewport"). So, it
maybe is width/height/x/y instead??? Need to test...
WTHR - Set weather?
0 - 3 : "WTHR"
4 - 7 : Chunk size (always 2,384)
8 - 11 : Type
12 - 15 : Weather flags?
16 - 143 : Color table (32 entries, each 4 bytes) ???
144 - 147 : Random percentage ???
148 - 151 : Random min X ???
152 - 155 : Random min Y ???
156 - 159 : Random min Z ???
160 - 163 : Random max X ???
164 - 167 : Random max Y ???
168 - 171 : Random max Z ???
172 - 175 : Velocity X ???
176 - 179 : Velocity Y ???
180 - 183 : Velocity Z ???
184 - 187 : Parsec ???

This is then followed by 9 patch records (implicitly numbered 0 to 8), each 244 bytes:
0 - 3 : ?unk?
4 - 7 : Patch flags?
8 - 11 : Placement?
12 - 15 : Position X?
16 - 19 : Position Y?
20 - 23 : Position Z?
24 - 151 : ?unk?
152 - 155 : Death ??
156 - 159 : ?unk?
160 - 163 : Lifetime AND Distance ?!?! (FIXME: No idea how this field is encoded!)-:
164 - 167 : ?unk?
168 - 171 : Colordef??
172 - 215 : ?unk?
216 - 219 : Volume min X??
220 - 223 : Volume min Y??
224 - 227 : Volume min Z??
228 - 231 : Volume max X??
232 - 235 : Volume max Y??
236 - 239 : Volume max Z??
240 - 243 : Shape?

Shape values:
0x00000000 - Point
0x00000001 - Line
0x00000002 - Square
0xffffffff - <WASM inserts this value for invalid values>

Patch flag values (FIXME: This is based on solely iterative testing with WASM):
0x00000001 - Placement value is defined.
0x00000002 - Position values are defined.
0x00000008 - Death value is defined.
0x00000010 - Colordef value is defined.
0x00000020 - Distance type value is defined.
0x00000200 - Volume min & max values are defined.
0x00000400 - Shape value is defined.

Type values:
0x00000000 - (FIXME: Default - no weather?)
0x00000001 - rain
0x00000002 - snow
0x00000003 - hail
0x00000004 - dust
0x00000005 - user (FIXME: what the hell does this do???
0xffffffff - <invalid - WASM puts this value in if the 'type' parameter given is unknown>

Weather flag values (FIXME: This is based on solely iterative testing with WASM):
0x00000001 - Color table is defined.
0x00000002 - Random min, max and percentage are defined.
0x00000004 - Parsec value is defined.
0x00000008 - Velocity values are defined.
0x00010000 - Patch record #0 is defined.
0x00020000 - Patch record #1 is defined.
0x00040000 - Patch record #2 is defined.
0x00080000 - Patch record #3 is defined.
0x00100000 - Patch record #4 is defined.
0x00200000 - Patch record #5 is defined.
0x00400000 - Patch record #6 is defined.
0x00800000 - Patch record #7 is defined.
0x01000000 - Patch record #8 is defined.

FIXME: Only a handful of WTHR chunks occur (a total of 8 mercs missions use them). Of these:
- None of them use patches.
- Only types "rain" and "snow" are used.
- None of the rain chunks set any other parameters (the whole chunk is literally the chunk tag and size, the value 1
for rain and then all zeros).
- All but one of the snow chunks do set parameters. Those that do always use "Color table", "Parsec" and "Velocity".
NB: This particular observation supports my theory on "Velocity" - all the missions that set the parameter have snow
that blows sideways, whereas the one that doesn't has snow that falls straight down vertically.
FIXME: Wow... the whole "Color table" bit blows my mind :-P When setting these values with WASM:
- Each occurrence of the "color <integer>" or "colorscale <integer> <integer> commands adds entries to the
table, without overwriting previous entries, up to the maximum of 32 (after which, the color commands are
silently ignored). So:
color 1
color 2
creates a table with the values 1, 2 and then thirty zeros.
- When adding entries with "color", it appears to accept any 32-bit integer (FIXME: Didn't check if it interprets
it as signed or not).
- However when adding entries with "colorscale", WASM will puke if either of the values is outside the range [0, 255]!
- The "colorscale <lo> <hi>" command will add a sequence of values to the table, starting with the value <lo>, then
<lo+1>, ..., until either <hi> is reached or the table contains the maximum 32 entries. If <lo> is actually greater
than <hi>, WASM appears to automatically swap the values so they are in the correct order.
As with every other field in this chunk, I have no idea what the color table is for, although I suppose the most logical
guess would be that it provides a palette for the weather pixels...
FIXME: Dunno what the "Velocity" fields are for, but they're set in WASM by "velocity <integer> <integer> <integer>".
I think this gives the velocity of the weather defined by type (ie: rain, snow, etc). Which would make sense
considering that velocity is a vector (so the values are vx/vy/vz) ???
FIXME: Also no idea what "Parsec" is for (set by "parsec <integer>" in WASM).
FIXME: And no idea what "Random min/max" is (set by "random_min/max <integer> <integer> <integer>" in WASM). The "Random
percentage" value is set by "random_percentage <integer>" in WASM. My best guess would be that setting the random
fields allows the sim to vary velocity over time, and that the random fields give the parameters for randomly
adjusting velocity???
FIXME: Appears only in "xxxxWTHR.WLD" files.
FIXME: No idea at this stage. The name suggests "weather" (maybe)???? All I know for sure is that they're always
2,384 bytes and that they only appear in Mercs (NOT in 31cc or GBL).
NB: Set by "weather_begin/weather_end" construct in xxxxWTHR.BWD files.
XPLO - ?
8 - 9 : Object ID
10 - 11 : ? unk1 ?
12 - 13 : ? unk2 ?
14 - 15 : ? unk3 ?

NB: Always follows an OBJ chunk. The "Object ID" field in XPLO will always match the ID of the OBJ chunk that
preceeds it (I have proven this programatically against 31cc/GBL/Mercs).
FIXME: unk1 usually seems to form a contiguous range of values, or is the same value.
FIXME: Whenever unk1 changes by more than one, unk2 appears to change value also.
FIXME: unk3 seems to always be zero - could be part of unk2 (ie: unk2 might actually be a 32-bit field).
FIXME: Suspect unk2 is probably meant to group a set of XPLO chunks together.
FIXME: Appears in "xxxxSHTx.BWD".
FIXME: Presumably something to do with explosions (based on the name and that xxxxSHTx files are meant to define
weapon related geometry).


[hide=Complete list of known tags][ AFFL - Set affiliation ]
8 - 11 : Affiliation

FIXME: Isn't documented by MW2DOC.HTM or Dan Kegers FAQ, but Kegers FAQ does contain the "affiliation" command
in a sample "xxxxAREx.WLD" file. Based on this usage, I assume it is intended to affiliate a particular
set of objects defined in a "xxxxAREx.WLD" file with a particular alliance (I assume the "affiliation"
field value matches an alliance ID (see "STAR" & "CAMO") but I will need to investigate a complete set
of mission BWD files to confirm this).
NB: Set by "affiliation" in "xxxxAREx.WLD" files.

[ ANIM - Set animation file for gamepiece ]
8 - 9 : Animation ID.
10 + : Animation name (ASCII) - NUL terminated and/or zero-padded??

NB: Animation ID & name identify an ANIM entry in the MW2.PRJ file (the name/ID pair given here
should match the name/ID pair in PRJ file, case-insensitive). For example, if name was "garganim",
then the animation file to use would be "MW2.PRJ$ANIM/GARGANIM.3DI".
NB: Set by "animfile" in "*.MEC" files???

[ ANM2 - ? ]
4 - 7 : Chunk size (20 for 31cc/GBL, 24 for Mercs)
8 + : ????

FIXME: Mercs Tools doco implies that this chunk will contain a list of 2D bitmap animations used in the cockpit,
and that the only one actually used is the static animation.
FIXME: Appears only in "MW2PIT.BWD".

[ ASND - Define ??? sound for mech??? ]
8 - 9 : ID of SFL file in MW2.PRJ to use
10 + : Name of SFL file in MW2.PRJ to use (ie: "mechvft1" -> "MW2.PRJ$SNDS/MECHVFT1.SFL"). Appears to be
NUL terminated and/or zero padded??

FIXME: Links a sound file to a mech, but I'm not sure why yet - will have to listen to a few of the sound
files later to try to guess... Ambient/animation sounds????
UPDATE: Juding by the sounds associated with the TimberWolf and FireMoth, the linked file is the sound
of the Mechs footsteps as it is walking/running. The file associated with the Atlas was rather
garbled, which means my interpretation of the SFL format still has some work :-P
UPDATE: According to MW2DOC.HTM the sound is:
* Only loaded for the user gamepiece (mech)
* Played when the associated animation track hits the "s" code in its flags track
NB: Set by "AnimSound" in "*.MEC" files???

[ BLK - Start block ]
8 - 11 : X #1
12 - 15 : Y #1
16 - 19 : Z #1
20 - 23 : X #2
24 - 27 : Y #2
28 - 31 : Z #2

NB: Set by "block" in "xxxxAREx.WLD" file - terminated by "endblock" (see "ENDB").
NB: According to MW2DOC.HTM the "block/endblock" construct encapsulates a static block of data that
should be cached and loaded when the eyepoint (the user I presume) enters the given coordinate
range.
FIXME: It specifies the coordinates as "x, y, z dx, dy, dz", which suggests the second set of
values are width/height/depth, but based on the examples in DEM1, I believe "x1, y1, z1 x2, y2, z2"
designation is a more suitable interpretation (ie: two points that define a bounding box).
FIXME: Another possible interpretation of MW2DOC.HTM would be that the delta values apply on either side
of the first triplet (ie: the first three values identify the center of the bounding box????)


[ BLKX - Set block transformation ]
8 - 11 : Scale X (integer)
12 - 15 : Scale Y (integer)
16 - 19 : Scale Z (integer)
20 - 23 : Rotate X (degrees? - fixed point: divide by 65536 to get real number)
24 - 27 : Rotate Y (degrees? - fixed point: divide by 65536 to get real number)
28 - 31 : Rotate Z (degrees? - fixed point: divide by 65536 to get real number)
32 - 35 : Translate X (integer, cm?)
36 - 39 : Translate Y (integer, cm?)
40 - 43 : Translate Z (integer, cm?)

NB: Set by "block_xform" in "xxxxWLD1.WLD" file.
NB: According to MW2DOC.HTM this sets the transformation to be applied to the next "block/endblock" construct.

[ BMEN - ? ]
8 - 9 : Associated 3dbitmap_idlist ID.
10 - 11 : Type

Where type can be:
0 - Disable
1 - Enable
2 - One shot

NB: Set by "3dbitmap_enable" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).

[ BMID - ? ]
8 - 9 : List ID?
10 - 11 : Always 0xffff?

NB: As best I can tell these always follow one or more BMPJ tags (which identify XEL files) and assigns them an ID value.
NB: Based on the example MAP files in DEM1/DEM2, it looks like you can assign the same sequence of BMPJ tags different
ID values by following them with more than one BMID tag. I believe the BMPJ list is then reset once another BMPJ tag
is encountered *after* the BMID tags??
FIXME: Not sure what these IDs map to, but assume they have some relation to a value in the WTB files...
NB: Set by "3dbitmap_idlist" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).

[ BMPJ - ? ]
8 - 9 : ID of a texture file in the MW2.PRJ CEL folder
10 + : Name of a texture file (sans extension) in the MW2.PRJ CEL folder. Appears to be zero-terminated/padded??

NB: Set by "3dbitmap_prj" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).
NB: Based on the DEM1/DEM2 examples, it looks like the tag sequence is:
- One or more BMPJ tags.
- One or more sequences of: BMID [BSEC [BMEN]]

[ BSEC - ? ]
8 - 9 : Associated 3dbitmap_idlist ID.
10 - 11 : Time, in 1/180th seconds.

NB: Based on the DEM1/DEM2 examples, I think that the BSEC tag is used to animate a sequence of BMPJ tags (and their associated
BMID tag), where the time value is the time to elapse between one BMPJ and the next in sequence) ????
NB: Also based on DEM1/DEM2, it looks like the ID value is optional if only one BMID follows a collection of BMPJ tags?
NB: Set by "3dbitmap_sec" in the "xxxxMAP1.WLD" file (or "MW2_MAP1/2/3.WLD" for defaults).

[ BTHG - ? ]
8 - 9 : Object ID
10 - 11 : ? unk1 ?

NB: Always follows after an OBJ chunk. The "Object ID" field will always match the ID of the preceeding OBJ chunk.
(I have proven this programatically against all of the BWDs in 31cc/GBL/Mercs).
FIXME: I believe the unk1 field connects a set of BTHG chunks together - the value here always seems to be the same
for a consecutive set of BTHG chunks, after which the value is not used again in the same BWD file. The number of
BTHG in a group is variable. They don't necessarily appear in order.
FIXME: Appears in "xxxxSHTx.BWD"

[ BWD - "Header" tag ]
4 - 7 : Tag size = File size
8 - 11 : This is the size of the largest chunk in the BWD file (this size includes the four character type
field, chunk size field, and any embedded chunks).
Proven programmatically against all of the BWD files in 31cc, GBL & Mercs by quota4stupid

This header record is immediately followed by a "REV" record, then a "DTBL" record, and then the records
that make up the BWD payload.


[ CAMO - Set camo pattern for alliance ]
8 - 11 : Alliance ID (see "STAR" I think???? FIXME: Need to test this...)
12 - 15 : Camo pattern ID (see below)

The camo pattern IDs (taken straight from Dan Kegers Mercnet Mission Building FAQ):
0 - Plain steel panels
1 - Dark steel panels
2 - Medium steel panels
3 - Tiger stripe pattern
4 - Lined pattern
5 - Cow pattern
6 - Flat colored panels
7 - Pirate flat black panels

NB: Set by "camo" in the "xxxxSCN1.WLD" files.

[ CLIM - ? ]
8 - 31 : ???? (always zero?)

FIXME: Set by "???" in the "xxxxPLT1.WLD" file???
FIXME: Checked this chunk programatically - in all cases bytes 8-31 are always zero, across 31cc, GBL & Mercs,
except for ZACKPLT1.BWD & BRANPLT1.BWD in GBL - both have 0x0A at byte 12 (but all other bytes are zero).

[ CPGN - Define campaign parameters (????) ]

FIXME: TBI
FIXME: Appears in the "xxxxCAM1.WLD" files ????
FIXME: A quick inspection of a few hexdumps suggest that these "xxxxCAM1" files add additional mercs related parameters to missions
described by a matching "xxxxSCN1" file. The CPGN record appears to contain a number of embedded records (including "NEWS",
which seems to give the accompanying ComStar news report relating to the mission), and links to a variety of related BWD files
(including "xxxxSCN1", "xxxxBRF1", and other "xxxxCAM1" files (a believe the CAM links indicate the next mission, based on the
success or failure of this one).

[ CPTF - Define cockpit for mech?? ]
8 - 9 : ID of CPI file in MW2.PRJ to use
10 + : Name of CPI file in MW2.PRJ to use (ie: "mw2mech" -> "MW2.PRJ$CPIT/MW2MECH.CPI"). Appears to be
NUL terminated and/or zero padded???

NB: ID and name must identify the same CPIT entry.
NB: Set by "cptfile" in mech definition "*.WLD" files???

[ DTBL - ???? ]
8 - 27 : ????

FIXME: bwd\dtbl.txt contains a list of BWD files (for mercs) that contain a DTBL record with non-zero payload.
Looks to be mostly mechs and xxxxAREx files.
FIXME: Not sure what the purpose of this record is, but there is one in every BWD file immediately following
the "REV" record.
FIXME: Suspect this may be a "static data table" based on the following WASM.EXE message:
Error - BWD file is missing static data table chunk
Would need to test this by removing the DTBL chunk from a BWD in the project file and then including it in a WLD file
and running WASM I guess. Still no idea what it's for.
FIXME: I've got a sample MEC file for an Awesome floating around which, when compiled, has non-zero values in the DTBL chunk.
I would say that experimenting with this would be a good way to figure DTBL out some (in the very least, by removing
WASM commands one at a time I should be able to figure out which ones affect DTBL). NB: There is definately no command
that I can find to set the values explicitly - it seems to be implicit somehow.

[ ENDB - End block ]
NB: Set by "endblock" in "xxxxAREx.WLD" - terminates a "block" construct (see "BLK")

[ ENDR - Terminate a series of REPR records? ]
FIXME: Seems to terminate a series of REPR chunks (refer to REPR chunk later in this doc).

[ EYEO - Define eye object of pilot in mech?? ]
8 - 11 : Object ID???

FIXME: TBI
FIXME: Appears in mech definition BWD files.
FIXME: Based on observation, quota4stupid believes that this chunk identifies an OBJ chunk to use as the location of the pilots
eye within a mech model. I assume this based on the fact that interpreting the 32-bit field as an object ID
seems to always identify an OBJ chunk that is:
- A child of the mech head object.
- Has a DUMMY mesh.
- Has a transform that positions it more or less behind the windshield geometry.
- As such I believe it is used to position the camera inside the mech model for the first person pilot view??

[ FTBL - Define mech formation table ]
8 - 15 : Formation name (ASCII)
16 - 23 : ???? (always zero?)

This is then followed by a series of 12-byte records that define the location and orientation of each mech in the formation:
0 - 3 : X coordinate (cm?)
4 - 7 : Y coordinate (cm?)
8 - 11 : Rotation (degrees?, 0 faces north?, cw/ccw?)

NB: Set by the "formation" construct in "xxxxFRM1.WLD".

[ GP - Define gamepiece ???? ]
8 - 9 : Object ID (root object for gamepiece, defined previously in BWD)
10 - 11 : Type

Type values:
0x0001 - mw2mech
0x0002 - mw2truck
0x0003 - mw2artillery
0x0004 - mw2tank
0x0005 - mw2helicopter
0x0006 - mw2wanderer
0x0007 - mw2door
0x0008 - mw2aerotech

NB: Set by "gamepiece" command in *.mec files (gamepiece <object-name> <gp-type>)

[ GPS - ? ]

FIXME: TBI
FIXME: "gp_spec" command in "xxxxENSx.WLD", "xxxxUSRx.WLD", "xxxxNUKx.WLD", etc.
FIXME: Description for enemy mech: Mech configuration, pilot's name

[ GT - Define gamething ???? ]
8 - 9 : ID of object this record applies to - see "OBJ"
10 - 11 : ID of alternate object (replaces the main object when the GT is destroyed, 0xffff=none)
12 - 15 : (always 0xffffffff) ????
16 - 19 : (always 0xffffffff) ????
20 - 23 : (always 0xffffffff) ????
24 - 25 : Strength/health (how many points of damage the GT can take before it is destroyed)
26 - 27 : Allowed goal flags
28 - 29 : Chunky flag (true=0x8000) ????
30 - 31 : (always 0) ????
32 - 75 : Description (this text is displayed when the GT is targeted)

Goal flag values:
0x0000 - None
0x0002 - Destroy
0x0004 - Defend
0x0008 - Recon
0x0020 - Return
0x0030 - Begin
0x0100 - Goto
0x0200 - Wait
0x0400 - Sleep
0x0800 - Shutdown
0x2000 - Leave

FIXME: Kegels FAQ doesn't explain what the chunky flag is for??? I believe that this signals
to the sim that this GT is the chunks for another object (since the only other way to
tell, as far as I can see, is from the naming convention used for the WTB files, but
since this is a *convention* I suspect the flag is required to make it definitive).
NB: According to Dan Kegels FAQ, declaring an object to be a "gamething" means it can be
targeted with "q", inspected and destroyed.
NB: Set by "gamething" in"xxxxAREx.WLD" files ????

[ HRZM - Set horizon gradient ]
8 - 11 : Color ??
12 - 15 : Height ??
16 - 19 : Unused (can't set with WASM as far as I can tell?)
20 - 23 : Unused (can't set with WASM as far as I can tell?)
24 - 27 : Unused (can't set with WASM as far as I can tell?)
28 - 31 : Unused (can't set with WASM as far as I can tell?)

FIXME: The following from Dan Kegers Mission Building FAQ:
horizon_map 0,75,0 0 0 0
horizon_map - This defines the length of the horizon gradient.
But he doesn't explain what the parameters mean, nor their range of values :-(
FIXME: At this stage, I'm not even sure if the 6 parameters to horizon_map are writen in
sequence to our 6 32-bit word slots above :-P
FIXME: According to MW2DOC.HTM, the declaration is actually "horizon_map <color> <height>"
and that the <color> parameter is "unknown. Set to 0" :-P No mention of those last
two parameters at all :-( The <height> parameter is the "height, in pixels, of the
horizon ramp".
NB: Set by "horizon_map" in "xxxxPLT1.WLD".

[ HTXT - Set hidden text ]
8 - 23 : Default string for any object that is inspected and doesn't have an explicit description (ASCII).
This string has a maximum length of 15 characters, and MUST be NUL terminated.

NB: Set by "hidden_text" in "xxxxPLT1.WLD".

[ HUDF - Set HUD file for mech ]
8 - 9 : ID of HUD file in MW2.PRJ to use.
10 + : Name of HUD file in MW2.PRJ to use (ie: if this field is "mw2hud" then use "MW2.PRJ$HUD/MW2HUD.HDI").
Appears to be NUL terminated and/or zero-padded???

NB: ID and name must identify the same HUD entry.
NB: Set by "hudfile" in mech definition "*.WLD" files???

[ INCL - Include BWD file ]
8 - 9 : ID of BWD file to include
10 - 19 : Name of BWD file to include (ie: "bet1brf1" -> "MW2.PRJ$BWD/BET1BRF1.BWD")

NB: Set by "include" command in a variety of "*.WLD" files.

[ INIT - Init sim clock (?) ]
8 - 11 : 00000000 ????
12 - 15 : 00000000 ????
16 - 19 : Time of day (0=dawn, 1=day, 2=dusk, 3=night) [ "now" digit 1 ]
20 - 23 : Unused [ "now" digit 2 ]
24 - 27 : 00000000 ????

NB: Set by "now" in "xxxxPLT1.WLD".
FIXME: Unsure if the other parameters are set by anything?

[ LITE - Set light source ]
8 - 11 : ???? (always zero?)
12 - 15 : ???? (always zero?)
16 - 19 : Light X coordinate (cm)
20 - 23 : Light Y coordinate (cm)
24 - 27 : Light Z coordinate (cm)
28 - 29 : Ambient light level (integer, 0 - 256)
30 - 31 : Light type (0=point, 1=directional)
32 - 35 : Shade distance (cm) (objects outside this range are only light by ambient light, not the main light source)
36 - 39 : ???? (always one??)

NB: Set by "light", "ambient" and "shadedist" in "xxxxPLT1.WLD".
FIXME: Unsure what if anything sets the unknown values??? Maybe experiment with "lightobj" ?????

NB: Appear to only be able to define one light source - if multiple light sources are defined in the WLD file, the last one is used,
and the ones before it seem to be ignored.

[ LITO - ??? ]
8 - 11 : ? unk1 (always zero?) ?

FIXME: Lit object???
NB: Only appears in 31cc & GBL (in xxxxPLT1.BWD).

[ LTBL - Set light table (?) ]
8 - 9 : ???? (observed values are 1 & 2)
10 - 17 : Name of luminosity lookup table to use (ie: "standard" or "FOG")
18 - 21 : ???? (always zero???)
22 - 23 : ???? (always zero???)

NB: Set by "luma" in the "xxxxPLT1.WLD" file.
FIXME: Unsure what sets the unknown values???

[ MGDF - Set additional geometry information file for mech ]
8 - 9 : ID of MGI file in PRJ file to use
10 + : Name of MGI file in PRJ file to use. Appears to be NUL terminated and padded to an
even number of bytes (ie: "timbrwlf" identifies "MW2.PRJ$MGEO/TIMBRWLF.MGI")

NB: ID and name must identify the same MGEO entry.
FIXME: Set by "mgdfile" in mech definition "*.WLD" files???
FIXME: According to Merc Tools doco: "The Mech Geometry file contains some additional data required
to fully simulate the gamepiece. " This seems to include stuff like Y offset (height) of the
root object from the ground, max torso/turret twist, etc etc.

[ MLIT - Multiple light source creation ]
8 - 11 : Position X (integer, cm) ????
12 - 15 : Position Y (integer, cm) ????
16 - 19 : Position Z (integer, cm) ????
20 - 23 : Radius (integer, cm) ????

NB: Used to define additional light sources to that defined by "LITE". The (x, y, z) coordinate
is the position of the light center and radius defines the size of the area affected by it.
FIXME: I can't be sure about the layout of the fields above, as there appears to be a bug in WASM
when parsing the light_begin/end construct? (the sample I tried from the MW2DOC.HTM, plus
a few other tests, put the radius where I believe the Z coordinate should be, and completely
disregarded the Y and Z coordinates I provided)-:
NB: Set by "light_begin/light_end" construct in "xxxxAREx.WLD" and "xxxxSMO1.WLD" files.

[ MOFF - Mangle Off ]

NB: Set by "mangle_off" in various geometry "*.WLD" files - terminates "mangle_on" (see "MON")

[ MON - Mangle On ]
FIXME: Dunno what this is for exactly, but MON and MOFF seem to wrap any BWD that defines a physical entity
(ie: mech, dunes, buildings, etc). MON always appears to be the first record in these files, and MOFF
is the final record. Clearly seems to be flagging some condition - M ON and then M OFF - but what the
hell is "M"??
UPDATE: Judging by some of the demo source files, "M" stands for "mangle" (in the source file it's mangle_on
and mangle_off), but it's not documented in the world building information, so I still dunno what it's for :-P
UPDATE: According to Dan Kegels Mission Building FAQ, enclosing stuff in mangle_on/off will ensure that all
names defined within the block are unique, but doesn't specify exactly how it does that (etc). Given that
they appear as tags in the BWD, I can only assume it's not done by wasm.exe, but at runtime by the sim???
NB: Set by "mangle_on" in various geometry "*.WLD" files.

[ MTBL - Set mission objective table for star ]
8 - 11 : ID of star this mission table applies to (see "STAR")
12 - 15 : Mission time (signed integer, seconds, -1=infinite time)
16 - 17 : ID of mission success audio file (in "MW2.PRJ$SNDS")
18 - 26 : Name of mission success audio file (in "MW2.PRJ$SNDS", with ".SFL" extension)
27 - 28 : ID of mission fail audio file (in "MW2.PRJ$SNDS")
29 - 37 : Name of mission fail audio file (in "MW2.PRJ$SNDS", with ".SFL" extension)

This is then followed by a series of 151 byte records:
0 - 1 : Action
2 - 3 : (always 0) ???
4 - 5 : Type
6 - 9 : Activation record logic operator (all 4 bytes? probably not)
10 - 13 : Activation record #1
14 - 17 : Activation record #2
18 - 21 : Activation record #3
22 - 25 : Activation record #4
26 - 29 : Activation record #5
30 - 33 : Activation record #6
34 - 37 : Activation record #7
38 - 41 : Activation record #8
42 - 45 : Time (integer, seconds)
46 : Priority
47 : Critical
48 : Mechs per target
49 : Do-not-disturb (AI only)
50 - 51 : Success audio ID (0xffff=none)
52 - 60 : Success audio name
61 - 62 : Fail audio ID (0xffff=none)
63 - 71 : Fail audio name72 - 73 : Target BWD ID
74 - 82 : Target BWD name
83 - 84 : ? WASM sets this to 0 if a target objective number is specified, -1 if there is none ?
85 - 86 : Target objective number (ie: userstar_4) or -1 if none.
87 - 150 : Objective description text (ASCII)

Activation record format:
0 : Result
1 : Objective number
2 : Star number
3 : (always 0) ????

Activation record result values:
0x43 - C(ompleted)
0x46 - F(ailed)
0x49 - Initial
0x53 - S(ucceeded)
0xff - None

Activation record logic operator values:
0 - OR
1 - AND

Type values:
0x48 - Hidden
0x56 - Visible

Priority values:
0x00 - None
0x01 - Primary
0x02 - Secondary
0x04 - Tertiary
0x08 - Return

Critical values:
0x4d - Mandatory
0x4f - Optional

Do-not-disturb values:
0 - Attack enemies if they come in range
1 - Attack enemies only if fired upon
2 - Ignore enemies and focus on objective

Action values:
0x0000 - None
0x0002 - Destroy
0x0004 - Defend
0x0008 - Recon
0x0020 - Return
0x0030 - Begin
0x0100 - Goto
0x0200 - Wait
0x0400 - Sleep
0x0800 - Shutdown
0x2000 - Leave

NB: According to MW2DOC.HTM, the Target BWD file contains the objects that are the target of the objective.
For example, for a "begin" objective, the target should be a navpoint. For "destroy" or "defend" it
should be a building (etc).
FIXME: Does star ID (field 8-11) match with group_id in gp_spec???
FIXME: In the mission table, the "Begin" action appears as 0x0010, rather than the 0x0030 as it does everywhere else
(is this perhaps an error in WASM????)
FIXME: Have codes for all of the action types, except for "Objsucceed", "Objfail", "Objshow", "Msnsucceed" and "Msnfail".
NB: Set by "mission/end" construct in "xxxxSCN1.WLD" files.

[ MUSI - Set music track for mission ]
8 - 9 : ID of music track in MW2.PRJ
10 - 23 : Name of music track in MW2.PRJ (ie: "track12" -> "MW2.PRJ$MUS/TRACK12.MUS")

NB: Identifies the music track file in MW2.PRJ to play for the mission.
FIXME: I believe this *.MUS file is used to identify a CD track to play???
NB: Set by "music" in the "xxxxSCN1.WLD" file.

[ NAVP - Define navpoint ]
8 - 11 : X (cm)
12 - 15 : Y (cm)
16 - 19 : Z (cm)
20 - 21 : Always 0 ????
22 - 23 : Starting angle of gamepieces if this is a start point
24 - 25 : Enabled for targeting by group (1=TRUE)
26 - 27 : Flags (unused, set to 0)
28 - 29 : Key (unused, set to 0)
30 - 31 : ID of group that owns the navpoint
32 - 33 : Radius (m)
34 - 35 : Action flags
36 - 56 : ASCII text displayed when targeted (spec says 20 chars, but seems to allow 21)
57 - 79 : Always 0 ????

Action flag values:
0x0002 - Destroy
0x0004 - Defend
0x0008 - Recon
0x0020 - Return
0x0030 - Begin
0x0100 - Goto
0x0200 - Wait
0x0400 - Sleep
0x0800 - Shutdown
0x2000 - Leave

NB: Set by "navpoint" in "xxxxSTx1.WLD", "xxxxGOUx.WLD", "xxxxGOEx.WLD", "xxxxNAVx.WLD" and "xxxxLVEx.WLD".
FIXME: Does "navobject" also set this chunk, or something else??? Need to test with WASM. (I think it sets NAVO chunk).

[ OBJ - Define object ]
8 - 9 : Object ID (unique within the scope of the parent container ("REPR", "BLK"????, BWD file), starting from zero) ????
10 - 11 : Parent object ID (0xffff=world, 0xfffe=fixed)
12 - 13 : Collision type
14 - 17 : Scale X (integer)
18 - 21 : Scale Y (integer)
22 - 25 : Scale Z (integer)
26 - 29 : Rotate X (degrees? - fixed point: divide by 65536 to get real number) ????
30 - 33 : Rotate Y (degrees? - fixed point: divide by 65536 to get real number) ????
34 - 37 : Rotate Z (degrees? - fixed point: divide by 65536 to get real number) ????
38 - 41 : Translate X (integer, cm)
42 - 45 : Translate Y (integer, cm)
46 - 49 : Translate Z (integer, cm)
50 - 51 : Scrounge type (MW2DOC.HTM says: 0 or 1 for objecType=Scrounge, and 0 otherwise - purpose unknown?)
52 - 53 : Object type
54 - 55 : ???? (always zero????)
56 - 57 : ID of mesh in "MW2.PRJ$POLY"
58 - 59 : ???? (always zero????)

Object type values:
0x0000 - None
0x0010 - Flame
0x0020 - Explosion
0x0030 - Scrounge
0x0040 - Chunklet
0x0050 - Chunk
0x0060 - Rotator
0x0070 - Hidden
0x0090 - Far
0x00a0 - Near
0x00b0 - Landmine
0x00c0 - Expendable
0x08c0 - Mirage
0x0800 - Terrain

Collision type values:
0x0000 - Orthorect
0x0001 - Cylinder
0x0002 - ceiling
0x0003 - Orthorotate
0x0004 - Null
0x0005 - Ground
0x0006 - Sphere
0x0007 - AllPoly

FIXME: MW2DOC.HTM only gives a few hints about the purpose of "object type"???
FIXME: The object ID field is based only on hexdump observation at present, and is yet to be proved by WASM tests
(ie: by setting the parentObject field to something other than fixed/world). The scope of the ID is still to
be confirmed (at present the BWD file / "REPR" level appears to be confirmed based on ATLAS.BWD, but I'm only
guessing on "BLK", though it seems logical).
FIXME: Based on observation (only of ATLAS.BWD so far) the first object in a mech BWD has type "HIDDEN" and identies
"DUMMY.WTB" for its mesh - I believe this is meant to be a virtual root node. It also has collision type 0xffff?!
NB: Set by "object" (and "collision"???) in "xxxxAREx.WLD" and mech geometry files???

[ OBJL - ? ]
8 - 9 : Object ID ???
10 - 11 : Group ID ???

FIXME: TBI
FIXME: Appears in mech definition WLD files.
FIXME: Based on observation, I believe this chunk is used to group OBJ chunks together for purposes of the wireframe mech
damage display in the cockpit. The "Group ID" values seem to be:
1 - Head (for ATLAS, this is the windshield mesh)
2 - Right torso ? (not used in mechs, only seems to be used in aircraft - ie: REIVER - right fuselage & fin)
3 - Center Torso (for ATLAS, this is the head and hip meshes)
4 - Left torso ? (not used in mechs, only seems to be used in aircraft - ie: REIVER - left fuselage & fin)
5 - R Arm
6 - L Arm
7 - R Leg
8 - L Leg

[ ORDR - Provide orders for briefing & debriefing ???? ]
8 + : Order text (zero-padded to a multiple of four bytes????)

NB: Order text uses the following control codes:
\n Newline
\c Center text on line
\t Tab
\s Hard page (??? - in practise, this seems to split the order into "Briefing" and "Situation" sections in Mercs)
\q Includes information returned by sim (used in debriefing) ????
\r0 Current rank
\r1 Next rank
\r2 Rank after next
\l ????
\p ????

NB: Set by "orders_begin" & "orders_end " in "xxxxBRF1.WLD", "xxxxDBFF.WLD" and "xxxxDBFS.WLD".

[ PALG - Sets the palette files used by the sim ]
8 - 9 : ID of day standard palette in MW2.PRJ$PAL
10 - 11 : ID of day explosion palette in MW2.PRJ$PAL
12 - 13 : ID of day flash palette in MW2.PRJ$PAL
14 - 15 : ID of day smoke palette in MW2.PRJ$PAL
16 - 17 : ID of dusk standard palette in MW2.PRJ$PAL
18 - 19 : ID of dusk explosion palette in MW2.PRJ$PAL
20 - 21 : ID of dusk flash palette in MW2.PRJ$PAL
22 - 23 : ID of dusk smoke palette in MW2.PRJ$PAL
24 - 25 : ID of night standard palette in MW2.PRJ$PAL
26 - 27 : ID of night explosion palette in MW2.PRJ$PAL
28 - 29 : ID of night flash palette in MW2.PRJ$PAL
30 - 31 : ID of night smoke palette in MW2.PRJ$PAL
32 - 33 : ID of IR standard palette in MW2.PRJ$PAL
34 - 35 : ID of IR explosion palette in MW2.PRJ$PAL
36 - 37 : ID of IR flash palette in MW2.PRJ$PAL
38 - 39 : ID of IR smoke palette in MW2.PRJ$PAL
40 - 41 : ID of black palette in MW2.PRJ$PAL
42 - 43 : ID of red palette in MW2.PRJ$PAL
44 - 45 : ID of cockpit palette in MW2.PRJ$PAL
46 - 47 : ID of alternate palette in MW2.PRJ$PAL

NB: These are set by "palette_grp" and "palette_misc" in "xxxxPAL1.WLD".

[ PDSC - Planet description ??? ]
8 - 11 : ? unk1 ?
12 + : Description (plain text)

FIXME: Appears to provide a brief planet description for Trial of Grievance missions (planet name and environment).
FIXME: Not sure what the unk1 is for though...
NB: Only appears in 31cc & GBL (in xxxxBRF2.BWD).

[ PILT - Define mechwarrior pilot (can be hired in Mercenaries) ]
8 - 39 : Pilot name (ASCII)
40 - 41 : Gunnery skill
42 - 43 : Rubberband range
44 - 45 : Sleep range
46 - 47 : Target range
48 - 49 : Pilot skill
50 - 51 : Mech affiliation (FIXME: What is it???)
52 - 53 : Personality
54 - 55 : Voice ID (FIXME: What is it???)
56 - 59 : Pilot salary
60 - 75 : Chassis name (name of gamepiece file in BWD folder, sans extension)
76 - 91 : Config name (name of configuration file in MEK folder, sans extension)

After this comes what appears to be an embedded record:
8 + : Pilot description text (ASCII) (including callsign, gunnery & piloting grades, psychological
profile & career history). Includes some escape codes (only witnessed \n for newline so far).
Appears to be zero-padded to a multiple of 4 bytes???

FIXME: In all of the PILOTx.BWD files I've looked at from the project file, "chassis" and "config"
are both set to "dizz" - wtf is this?!
FIXME: WASM appears to only accept values between 0 and 32,767 for pilot salary, however the value is
written as 32-bits - the value 32,768 is output as 0xffff8000 (-32,768). Need to check if the
sim accepts values outside this range (ie: is this a WASM bug?).
NB: Set by pilot_begin/pilot_end in "PILOTx.WLD" files.

[ PITF - Define ??? for mech? ]
8 - 9 : ID of BWD file in MW2.PRJ to use
10 + : Name of BWD file in MW2.PRJ to use (ie: "mw2pit" -> "MW2.PRJ$BWD/MW2PIT.BWD"). Appears to be NUL
terminated and/or zero-padded???

FIXME: According to Merc Tools doco, the PIT File contains a list of the 2D bitmap animations that are used
in the 2D cockpit.
NB: Set by "pitfile" in mech definition "*.WLD" files???

[ PLNT - Set planet parameters ]
8 - 11 : Gravity (signed integer / 65536.0 = float value) (0.0 - 4.0)
12 - 15 : Atmosphere (always 0)
16 - 19 : No. days in year (integer)
20 - 23 : No. seconds in day (integer)
24 - 27 : Axial tilt (integer)
28 - 31 : Circumference (integer)
32 - 35 : Unknown - always 0????
36 - 39 : Mean temp. (integer, celcius)
40 - 43 : Max. jump height (cm)
44 - 47 : Max. terrain height (cm)
48 - 51 : Min. terrain height (cm)
52 - 55 : Friction coefficient (0.0 - 1.0, determines max steepness a mech can walk up, with 1.0 being the steepest)
56 - 59 : Can pilot eject? (boolean, 0=false 1=true)
60 - 63 : Reverse damage shading? (boolean, 0=false 1=true, should be enabled for fog worlds)
64 - 67 : No light shifting? (boolean, 0=false 1=true, no longer used - should always be 1)
68 - 71 : Hide sky? (boolean, 0=false 1=true, if TRUE the sim doesn't draw the sky)
72 - 75 : Hide ground? (boolean, 0=false 1=true, if TRUE the sim doesn't draw the ground)
76 - 79 : Hide horizon? (boolean, 0=false 1=true, if TRUE the sim doesn't draw the horizon gradient)

NB: Set by "planet", "planet2" and "planet3" in "xxxxPLT1.WLD".

[ POFO - Set point-of-fire object? ]
8 - 9 : Object ID ???
10 - 11 : Pofo ID ???

FIXME: TBI
FIXME: Appears in MEC files.
FIXME: Based on observation, I believe that these chunks define "point of fire" on gamepiece BWDs. I base this on:
- The "Object ID" field always identifies an OBJ chunk that uses a DUMMY mesh.
- On the models I've been able to observe with my shonky renderer (and where I've put in special case handling
code to draw a big red sphere anytime the DUMMY mesh is used) most of the identified dummy objects appear in
logical weapon fire locations (ie: in front of the mechs arms, just below the center torso (hip), in front of
the center torso, etc).
- I figure the last field for the "Pofo ID" because within any given BWD (that I've checked) these numbers form
a consecutive range (not necessarily in order), starting from zero.
- In a nutshell, I believe each POFO chunk creates a map between a zero-based ID value and a dummy object in the
model from which weapons fire geometry should originate (laser, missiles, etc).

[ PTBL - Define path ]
8 - 71 : Path name (ASCII)

This is then followed by a series of point records of the form:
0 - 3 : X (integer, cm)
4 - 7 : Y (integer, cm)
8 - 11 : Z (integer, cm)
12 - 15 : Rotate X (integer, degrees)
16 - 19 : Rotate Y (integer, degrees)
20 - 23 : Rotate Z (integer, degrees)
24 - 27 : Travel time from this point to the next (in 1/182 seconds - ie: 0xb6=1 second)

FIXME: I'm not 100% certain of the length of the "path name" field (maximum length not specified in MW2DOC.HTM),
but the given range of bytes are either all for the name, or part for the name with the rest unused, as
best as I can tell.
FIXME: Could test this with WASM....
NB: Defines a series of points for use the "path" animation task (see "TSK" & MW2DOC.HTM for details).
NB: Set by "path" construct in "xxxxAREx.WLD" files, or anywhere else the "TSK" record is used.

[ REPR - Start object LOD representation ???? ]

FIXME: TBI
FIXME: Based on observation of ATLAS.BWD, it appears to encapsulate a LOD for an object (mech, buildings, terrain, etc)?????
FIXME: Also based on observation, each "REPR" appears to be terminated by the next "REPR" or (finally) by an "ENDR" record.
FIXME: Since it doesn't contain any fields (and based on observation of ATLAS.BWD) I assume that LOD level is assigned
implicitly in the order the "REPR" records occur, starting with the highest LOD, and ending with the least LOD.
FIXME: Appears in mech definition WLD files - seems to be terminated by the "ENDR" record.

[ REV - Record of WASM version used to created BWD ]
8 - 11 : Version of WASM used to generate the file (ASCII - always "1.22"??)

NB: Appears in every BWD file between the main header record and the "DTBL" record.
FIXME: My interpretation appears to be supported (apart from the fact that 1.22 is the version of WASM shipped with Mercs tools)
by the following warning/error messages in WASM.EXE:
Warning - BWD file generated by WASM rev %s - Current WASM is rev %s
Error - BWD file generated by old WASM version - Current WASM is rev %s
If this chunk isn't intended to convey the version of WASM used, then I don't see how else it could tell. It should be
relatively straight forward to test this theory (ie: modify the REV string of a BWD in the project file, and then include
this BWD in a WLD file and compile it with WASM - WASM should print one of these error messages).

[ SCRG - ? ]
8 - 11 : Always 0

FIXME: TBI
FIXME: Used in "xxxxSCRI.WLD" files (something to do with "scrounge") ????
FIXME: No idea what these are for. Ran a check on the project files for 31cc, GBL & Mercs, and in all
cases, the field @8 is ALWAYS zero. Can only assume the chunk is a marker of some sort with a
useless payload :-P

[ SDSC - Star description ]
8 - 11 : Pilot rank (from 1 to 8, where 1=best and 8=worst, determines AI level) ???
12 - 15 : Max tonnage (heaviest mech that may be in a star) ????
16 - 19 : Recommended number of mechs for mission ????
20 - 23 : Maximum number of mechs for mission ????
24 - 31 : Name of default mech for user (MEK file) ????
32 - 39 : Name of default mech for starmate #1 (MEK file) ????
40 - 47 : Name of default mech for starmate #2 (MEK file) ????
48 - 55 : Name of default mech for starmate #3 (MEK file) ????
56 - 63 : Name of default mech for starmate #4 (MEK file) ????
64 - 71 : Name of default mech for starmate #5 (MEK file) ????

FIXME: Haven't tested by compiling an s_desc with WASM yet, so not 100% about these fields,
but it seems consistent with the description in MW2DOC.HTM and the hexdumps I've checked.
FIXME: Not sure if the recommended and max mech counts are meant to include the user or not
(MW2DOC.HTM isn't completely clear on this - but I assume that it does)
NB: There will be "max mech count" number of "name of default mech" fields with valid values (the
rest are zero filled)
NB: Set by "s_desc" in the "xxxxBRF2.WLD" file.

[ STAR - Define mech star arrangements ]
A series of 24 byte records:
0 - 3 : Alliance ID (see below)
4 - 7 : Disposition (0=Friendly, 1=Enemy, 2=Neutral)
8 - 15 : Name of formation to use (matches the name in an FTBL record - match appears to be case insensitive?)
16 - 19 : (unknown - always zero) ????
20 - 23 : (unknown - always zero) ????

The alliance IDs are:
0 - FC
1 - Draconis
2 - FRR
3 - Wolf
4 - SmokeJaguar
5 - GhostBear
6 - Wild1
7 - Wild2

NB: This matches the order of the alliances as specified in the xxxxSCN1.WLD file. If these entries
are reordered, then the values in the BWD file *WILL* change. However, I would suspect that since
the name isn't stored in the BWD but only the index value that the mapping of ID values to alliance
logos is probably fixed in *THIS* order (ie: I think if you reorder the alliance names in the WLD
files, you'll just end up with your mechs having the wrong logo???).
FIXME: Each entry under STAR is linked to a GPS record (according to MW2DOC.HTM, this link is a group_id
field in the gp_spec record; on the STAR record end, this ID is implicit based on the order the
records are declared, starting at zero). Need to make sure this all matches up.

NB: Set by the "star" construct in "xxxxSCN1.WLD".

[ SUPS - Set startup screen ]
8 - 23 : Name of image file to display while world is loading (although this field is, or appears to
be, 16 bytes long, the max length of the name is actually 7 according to MW2DOC.HTM)

FIXME: I have absolutely *NO* idea where exactly this file is located :-( I couldn't find any of the
filenames from sample SUPS in the MW2.PRJ file. The next most logical place is probably
DATABASE.MW2, but these entries don't have names????
NB: Set by "supscreen" in the "xxxxBRF2.WLD" file.

[ TECH - Define aerotech pilot (can be hired in Mercenaries) ]
8 - 39 : Pilot name (ASCII)
40 - 41 : Gunnery skill
42 - 43 : Rubberband range
44 - 45 : Sleep range
46 - 47 : Target range
48 - 49 : Pilot skill
50 - 51 : Mech affiliation (FIXME: What is it???)
52 - 53 : Personality
54 - 55 : Voice ID (FIXME: What is it???)
56 - 59 : Pilot salary
60 - 75 : Chassis name (name of gamepiece file in BWD folder, sans extension)
76 - 91 : Config name (name of configuration file in MEK folder, sans extension)
92 + : Embedded "DSSR" chunk (refer to "PILT" chunk)

NB: Set by tech_begin/tech_end in "AEROTECx.WLD" files.

[ THNG - ? ]
8 - 11 : Thing OBJect ID ????

FIXME: TBI
FIXME: Every mech appears to have two of these tags.
FIXME: Mercs Tools doco states "Programmatically controlled objects are typically identified in the thing
directive shown below." Unfortunately it doesn't actually define this directive :-P
FIXME: Based on a few observations:
- I believe the 32-bit THNG field is meant to match an OBJ chunk object ID defined previously in the BWD
- If this is correct, it should be noted that the two THNG chunks that appear in mech BWDs identify the
mechs head object and a dummy object that the mechs arms are attached to.
- Considering the directive description from the FAQ, I would guess that this identifies parts of the mech
geometry that are transformed programatically - ie: the first (head) would probably be for torso twist
(since the entire upper part of the mechs geometry seems to be descended from this node), not sure about
the second one... tilt forward/backward maybe???
- This theory is further supported by the fact that in TANKA.BWD, the first THNG identifies the tank turret,
and the second identifies the gun barrel (torso twist & tilt would work here).
- BODYSUIT.BWD has no THNG chunks (kind of makes sense - they can't torso twist... can't tilt either??)
- AEROA.BWD also has no THNG chunks.
- DROPA.BWD & DROPZ.BWD each have two THNG chunks that identify the same object - a DUMMY with multiple DUMMY children.

[ TSK - Define animation task? ]
8 - 9 : Task name
10 - 13 : Update period (in game cycles, 0=update on every cycle - 182 cycles/second according to Merc Tools doco)
14 + : Task parameters (ASCII, zero-padded to a multiple of 4 bytes???)

Task name values:
0x0000 - Spinner
0x0001 - ColorSpin
0x0002 - FlyCircle
0x0003 - Animator
0x0005 - Path
0x0004 - AmbientSound

NB: The task parameters are copied verbatim from the WLD file into this record, except that any references
to objects by name are resolved into their integer IDs (or the ASCII text representation of that integer).
NB: Refer to MW2DOC.HTM for task parameter documentation - couldn't be arsed copying it all into here ;-P
NB: According to MW2DOC.HTM (2.1) - all task definitions refer to the most recently loaded 3DI file ("ANIM").
Once a new 3DI file is loaded, all subsequent tasks refer to it.
NB: Set by "task" in various geometry "*.WLD" files (ie: "xxxxAREx.WLD", mech definition files, etc).

[ VIEW - Set view parameters ]
8 - 11 : Near clipping plane (cm)
12 - 15 : Far clipping plane (cm)

NB: Set by "view" in the "xxxxPLT1.WLD" file.

[ VPTF - Set View Port File for mech ]
8 - 9 : ID of BWD file in MW2.PRJ to use
10 + : Name of BWD file in MW2.PRJ to use (ie: "mw2mech" -> "MW2.PRJ$BWD/MW2MECH.BWD"). Appears to be NUL
terminated and/or zero-padded????

NB: Identifies the View Port File to use for a mech. The View Port File is a BWD file containing a VWSP chunk.
This file is used to position view screens (ie: radar) in the cockpit.
NB: Set by "vptfile" in MEC files???

[ VWSP - ? ]
This is then followed by a series of eight 32-byte records:
4 - 7 : ? X ?
8 - 11 : ? Y ?
12 - 15 : ? Width ?
16 - 19 : ? Height ?
20 - 31 : ? always 0 ?

Type values are (I think):
0 - VIEW_INTERNAL_FRONT (Internal front view w/ Cpit on - used to clip bottom of screen)
1 - VIEW_INTERNAL_RIGHT (Not used)
2 - VIEW_INTERNAL_LEFT (Not used)
3 - VIEW_INTERNAL_UP (Not used)
4 - VIEW_EXTERNAL (External view - track or independent)
5 - VIEW_AUX_0 (Cpit view screen used for rear and missile eye views)
6 - VIEW_AUX_1 (Cpit view screen used for radar - fixed and directional)
7 - VIEW_AUX_2 (Not used)

FIXME: TBI
FIXME: Appears only in "MW2MECH.BWD".
FIXME: The Mercs Tools doco suggests that the 32-byte records are created with a series of "window" declarations,
and that "This file may not be necessary with a 3D cockpit" (refer to "VPT File", near end of doco).
FIXME: Not sure if I've ordered the x/y/width/height fields correctly, but am pretty sure that that's what they
are (since doco says the "window" declaration sets the "size and screen location of a viewport"). So, it
maybe is width/height/x/y instead??? Need to test...

[ WTHR - Set weather? ]
0 - 3 : "WTHR"
4 - 7 : Chunk size (always 2,384)
8 - 11 : Type
12 - 15 : Weather flags?
16 - 143 : Color table (32 entries, each 4 bytes) ???
144 - 147 : Random percentage ???
148 - 151 : Random min X ???
152 - 155 : Random min Y ???
156 - 159 : Random min Z ???
160 - 163 : Random max X ???
164 - 167 : Random max Y ???
168 - 171 : Random max Z ???
172 - 175 : Velocity X ???
176 - 179 : Velocity Y ???
180 - 183 : Velocity Z ???
184 - 187 : Parsec ???

This is then followed by 9 patch records (implicitly numbered 0 to 8), each 244 bytes:
0 - 3 : ?unk?
4 - 7 : Patch flags?
8 - 11 : Placement?
12 - 15 : Position X?
16 - 19 : Position Y?
20 - 23 : Position Z?
24 - 151 : ?unk?
152 - 155 : Death ??
156 - 159 : ?unk?
160 - 163 : Lifetime AND Distance ?!?! (FIXME: No idea how this field is encoded!)-:
164 - 167 : ?unk?
168 - 171 : Colordef??
172 - 215 : ?unk?
216 - 219 : Volume min X??
220 - 223 : Volume min Y??
224 - 227 : Volume min Z??
228 - 231 : Volume max X??
232 - 235 : Volume max Y??
236 - 239 : Volume max Z??
240 - 243 : Shape?

Shape values:
0x00000000 - Point
0x00000001 - Line
0x00000002 - Square
0xffffffff - <WASM inserts this value for invalid values>

Patch flag values (FIXME: This is based on solely iterative testing with WASM):
0x00000001 - Placement value is defined.
0x00000002 - Position values are defined.
0x00000008 - Death value is defined.
0x00000010 - Colordef value is defined.
0x00000020 - Distance type value is defined.
0x00000200 - Volume min & max values are defined.
0x00000400 - Shape value is defined.

Type values:
0x00000000 - (FIXME: Default - no weather?)
0x00000001 - rain
0x00000002 - snow
0x00000003 - hail
0x00000004 - dust
0x00000005 - user (FIXME: what the hell does this do???
0xffffffff - <invalid - WASM puts this value in if the 'type' parameter given is unknown>

Weather flag values (FIXME: This is based on solely iterative testing with WASM):
0x00000001 - Color table is defined.
0x00000002 - Random min, max and percentage are defined.
0x00000004 - Parsec value is defined.
0x00000008 - Velocity values are defined.
0x00010000 - Patch record #0 is defined.
0x00020000 - Patch record #1 is defined.
0x00040000 - Patch record #2 is defined.
0x00080000 - Patch record #3 is defined.
0x00100000 - Patch record #4 is defined.
0x00200000 - Patch record #5 is defined.
0x00400000 - Patch record #6 is defined.
0x00800000 - Patch record #7 is defined.
0x01000000 - Patch record #8 is defined.

FIXME: Only a handful of WTHR chunks occur (a total of 8 mercs missions use them). Of these:
- None of them use patches.
- Only types "rain" and "snow" are used.
- None of the rain chunks set any other parameters (the whole chunk is literally the chunk tag and size, the value 1
for rain and then all zeros).
- All but one of the snow chunks do set parameters. Those that do always use "Color table", "Parsec" and "Velocity".
NB: This particular observation supports my theory on "Velocity" - all the missions that set the parameter have snow
that blows sideways, whereas the one that doesn't has snow that falls straight down vertically.
FIXME: Wow... the whole "Color table" bit blows my mind :-P When setting these values with WASM:
- Each occurrence of the "color <integer>" or "colorscale <integer> <integer> commands adds entries to the
table, without overwriting previous entries, up to the maximum of 32 (after which, the color commands are
silently ignored). So:
color 1
color 2
creates a table with the values 1, 2 and then thirty zeros.
- When adding entries with "color", it appears to accept any 32-bit integer (FIXME: Didn't check if it interprets
it as signed or not).
- However when adding entries with "colorscale", WASM will puke if either of the values is outside the range [0, 255]!
- The "colorscale <lo> <hi>" command will add a sequence of values to the table, starting with the value <lo>, then
<lo+1>, ..., until either <hi> is reached or the table contains the maximum 32 entries. If <lo> is actually greater
than <hi>, WASM appears to automatically swap the values so they are in the correct order.
As with every other field in this chunk, I have no idea what the color table is for, although I suppose the most logical
guess would be that it provides a palette for the weather pixels...
FIXME: Dunno what the "Velocity" fields are for, but they're set in WASM by "velocity <integer> <integer> <integer>".
I think this gives the velocity of the weather defined by type (ie: rain, snow, etc). Which would make sense
considering that velocity is a vector (so the values are vx/vy/vz) ???
FIXME: Also no idea what "Parsec" is for (set by "parsec <integer>" in WASM).
FIXME: And no idea what "Random min/max" is (set by "random_min/max <integer> <integer> <integer>" in WASM). The "Random
percentage" value is set by "random_percentage <integer>" in WASM. My best guess would be that setting the random
fields allows the sim to vary velocity over time, and that the random fields give the parameters for randomly
adjusting velocity???
FIXME: Appears only in "xxxxWTHR.WLD" files.
FIXME: No idea at this stage. The name suggests "weather" (maybe)???? All I know for sure is that they're always
2,384 bytes and that they only appear in Mercs (NOT in 31cc or GBL).
NB: Set by "weather_begin/weather_end" construct in xxxxWTHR.BWD files.

[ XPLO - ? ]
8 - 9 : Object ID
10 - 11 : ? unk1 ?
12 - 13 : ? unk2 ?
14 - 15 : ? unk3 ?

NB: Always follows an OBJ chunk. The "Object ID" field in XPLO will always match the ID of the OBJ chunk that
preceeds it (I have proven this programatically against 31cc/GBL/Mercs).
FIXME: unk1 usually seems to form a contiguous range of values, or is the same value.
FIXME: Whenever unk1 changes by more than one, unk2 appears to change value also.
FIXME: unk3 seems to always be zero - could be part of unk2 (ie: unk2 might actually be a 32-bit field).
FIXME: Suspect unk2 is probably meant to group a set of XPLO chunks together.
FIXME: Appears in "xxxxSHTx.BWD".
FIXME: Presumably something to do with explosions (based on the name and that xxxxSHTx files are meant to define
weapon related geometry).
Updates:
March 23rd, 2009: Updated SDSC tag
April 14th, 2009: Updated GPS tag
Download MechVM

If you have problems with MechVM, please attach the files MechVM.cfg and install-report.txt from the folder where MechVM installed your game.

User avatar
quota4stupid
House Steiner Private First Class
House Steiner Private First Class
Posts: 81
Joined: Mon Dec 29, 2008 7:40 am
Location: Australia

Re: BWD file tags

Post by quota4stupid » Sun Feb 08, 2009 8:09 am

For anyone who's interested I've uploaded an updated copy of this file at the same address. It's still got a lot of gaps and is missing my notes on the
"CPGN" chunk, but is otherwise my current understanding of the BWD file format.

User avatar
Skyfaller
Clan 2nd MechWarrior
Clan 2nd MechWarrior
Posts: 991
Joined: Sat Apr 12, 2008 2:58 am
Location: Germany
Contact:

Re: BWD file tags

Post by Skyfaller » Thu Mar 19, 2009 2:14 am

quota4stupid wrote:
For anyone who's interested I've uploaded an updated copy of this file at the same address.
That URL seems to be inactive (404). What happened?
Download MechVM

If you have problems with MechVM, please attach the files MechVM.cfg and install-report.txt from the folder where MechVM installed your game.

User avatar
quota4stupid
House Steiner Private First Class
House Steiner Private First Class
Posts: 81
Joined: Mon Dec 29, 2008 7:40 am
Location: Australia

Re: BWD file tags

Post by quota4stupid » Thu Mar 19, 2009 3:08 am

Argh, sorry! I reorganized the files and forgot to update the URL here :oops:

The file is now located in http://users.tpg.com.au/nkjd245/mw2/bin/ with copies of some of my other notes on MW2 binary formats.

(Huh... I seem to be a "2nd Mechwarrior" now... I was kind of enjoying being an "Iron Womb Baby" ;-))

User avatar
Skyfaller
Clan 2nd MechWarrior
Clan 2nd MechWarrior
Posts: 991
Joined: Sat Apr 12, 2008 2:58 am
Location: Germany
Contact:

Re: BWD file tags

Post by Skyfaller » Thu Mar 19, 2009 4:30 am

You have advanced in rank. This is meant to encourage posting. You seem to pour a lot of work into this without a posting a lot.

I have removed earlier notes and reformatted your notes as you see above. Please notify us of any changes you make, so that I can update the information above. I have edited it a bit, please check if you like some of the changes. For instance, repeating the meaning of byte 0-7 for every tag seems excessive ... except for tags that deviate from this scheme and for tags with variable length.
Attachments
BWD tags.zip
Skyfaller's edited version of quota4stupid's notes on the tags
(16.17 KiB) Downloaded 278 times
Download MechVM

If you have problems with MechVM, please attach the files MechVM.cfg and install-report.txt from the folder where MechVM installed your game.

User avatar
quota4stupid
House Steiner Private First Class
House Steiner Private First Class
Posts: 81
Joined: Mon Dec 29, 2008 7:40 am
Location: Australia

Re: BWD file tags

Post by quota4stupid » Thu Mar 19, 2009 6:35 am

Skyfaller wrote:You have advanced in rank. This is meant to encourage posting. You seem to pour a lot of work into this without a posting a lot.
I am a man of few words... except when I'm at the pub ;-)
Skyfaller wrote:I have removed earlier notes and reformatted your notes as you see above. Please notify us of any changes you make, so that I can update the information above. I have edited it a bit, please check if you like some of the changes. For instance, repeating the meaning of byte 0-7 for every tag seems excessive ... except for tags that deviate from this scheme and for tags with variable length.
I plan to eventually upload all of my notes to my website (probably reformatted to HTML for easier reading - maybe ;-)).

The following are a set of "mystery chunks" (and probable associated WASM command) that I found in WASM.EXE when I hexdumped it the other week (this is also how I found the commands to setup weather and campaign info, etc). I haven't investigated any of these at this stage, and it should be noted that as far as I can tell, none of them exist in any MW2.PRJ (at least, none of the DOS versions anyway), so they may not actually be implemented by the sim:

ELSB (elseblock??)
FPRJ (frame_prj??)
GNDM (ground_map??)
GOFF (goal_off??)
GON (goal_on??)
GRP (group??)
GTBL (gp_chassis_table??)
NAVO (navobject I think - off the top of my head I'm pretty sure this one got a mention in the Mercs tools doco)
PLGO (polyoffset????)
POS (position??)
ROT (rotate??)
SKYM (sky_map??)
STBL (scenario_table??)
TERR (terrain??)
VWST (????)

User avatar
Col.Kell
House Steiner Archon
House Steiner Archon
Posts: 868
Joined: Sat Sep 27, 2008 7:44 am
Location: An Isolated Tennessee Valley.

Re: BWD file tags

Post by Col.Kell » Fri Mar 20, 2009 1:01 pm

quota4stupid wrote:The following are a set of "mystery chunks" ...

ELSB (elseblock??)
FPRJ (frame_prj??)
GNDM (ground_map??)
GOFF (goal_off??)
GON (goal_on??)
GRP (group??)
GTBL (gp_chassis_table??)
NAVO (navobject I think - off the top of my head I'm pretty sure this one got a mention in the Mercs tools doco)
PLGO (polyoffset????)
POS (position??)
ROT (rotate??)
SKYM (sky_map??)
STBL (scenario_table??)
TERR (terrain??)
VWST (????)
I have never seen those tags before. Where in the PRJ did you find these? (This is the 31stCC PRJ right?)
MechWarrior 2: 31stCC
Image

User avatar
quota4stupid
House Steiner Private First Class
House Steiner Private First Class
Posts: 81
Joined: Mon Dec 29, 2008 7:40 am
Location: Australia

Re: BWD file tags

Post by quota4stupid » Fri Mar 20, 2009 11:38 pm

Col.Kell wrote:I have never seen those tags before. Where in the PRJ did you find these? (This is the 31stCC PRJ right?)
Those chunks don't appear in any PRJ (at least, not in any of the DOS versions). I found them when I did a hexdump of WASM.EXE (it seemed like a good idea at the time ;-)) This is also where I found the WASM command strings that I believe are translated into them. The bottom line with these chunks is that they can be compiled into the BWD by WASM, but at this stage I don't know if they are actually supported by the sim or not (ie: they might be some old legacy commands from a previous version of WASM, or for that matter maybe they were new commands being tested) and have even less idea what they do :?

User avatar
Col.Kell
House Steiner Archon
House Steiner Archon
Posts: 868
Joined: Sat Sep 27, 2008 7:44 am
Location: An Isolated Tennessee Valley.

Re: BWD file tags

Post by Col.Kell » Sat Mar 21, 2009 8:05 am

Something with my two cents worth on a couple of tags in quota's notes:
CPTF - Not used to define mech cockpit
-- As described here, the cockpit declaration is in the OBJ tags within the mech BWD, much like all the other geometry. Say for example you have a Timberwolf, the Timberwolf would use TW1_HEAD as its ordinary head. Well, it turns out that TW5_HEAD would be the cockpit geometry. All the **5_HEADs are used as cockpit frames. I stumbled on that when I messed with the EYEO tag and the camera was outside the cockpit frame.
GPS - Game Piece Spec
-- This tag calls out the chassis and MEK file of a mech star. (e.g., GPS.d . . . . {chassis} . {MEK} . ) The BWD tag for the mech would go in the chassis slot, while the tag for a MEK file goes in the MEK slot.
MechWarrior 2: 31stCC
Image

User avatar
quota4stupid
House Steiner Private First Class
House Steiner Private First Class
Posts: 81
Joined: Mon Dec 29, 2008 7:40 am
Location: Australia

Re: BWD file tags

Post by quota4stupid » Sat Mar 21, 2009 9:47 am

Col.Kell wrote:
CPTF - Not used to define mech cockpit
-- As described here, the cockpit declaration is in the OBJ tags within the mech BWD, much like all the other geometry. Say for example you have a Timberwolf, the Timberwolf would use TW1_HEAD as its ordinary head. Well, it turns out that TW5_HEAD would be the cockpit geometry. All the **5_HEADs are used as cockpit frames. I stumbled on that when I messed with the EYEO tag and the camera was outside the cockpit frame.
It's not used to define the 3D geometry of the cockpit, but to name the CPI file within the project file that gives the location and size of the different 2D displays in the cockpit... or at least that's how I read MW2DOC.HTM in the Mercs tools directory (look for "cptfile").
Col.Kell wrote:
GPS - Game Piece Spec
-- This tag calls out the chassis and MEK file of a mech star. (e.g., GPS.d . . . . {chassis} . {MEK} . ) The BWD tag for the mech would go in the chassis slot, while the tag for a MEK file goes in the MEK slot.
I know - I just hadn't done the decoding in the copy of bwd.txt that Skyfaller posted ;-) It also sets AI parameters, etc for computer controlled mechs.

Post Reply