This document is separated into three main parts with an appendix. Part one gives a very rudimentary explanation of the simulation and the steps to take when putting mission design ideas to work in the sim. Part two gives a general explanation of the files used by the sim. It gives the naming convention for the files and how each file is used by the sim. The third part gives detailed descriptions of the commands used in each mission file and examples when helpful. The appendix contains a reference for the scenario building tools themselves.
After deciding what is going to happen in a mission or 'scenario', the first step is to create any necessary geometry for the world, then transform the mission proceedings, object locations and movements, lighting direction, types of 'players', and whatever else specific to that scenario into text files- following the format specified in the third part of this document. These text files are called world files as they are scripted text descriptors of the world that you are creating, and they use a WLD extension (i.e. userstar.wld).
Binary versions of these files are then created by a tool (assembler) called WASM which will automatically work with text files carrying a WLD extension.
These binary files keep the same name but use a BWD extension.
The BWD files are then added to the project file (in MechWarrior II the project file was named mw2.prj). The project file is the game file that contains all of the binary versions of the mission files (BWD's), all of the gamepieces, all of the objects, sounds, animations, etc...
Then when the sim is started, a world loader will pull information from the project file and plug the numbers into the sim engine so that what you created will (hopefully) show up in the sim.
To keep the files organized according to what scenario they belong to and what part of the scenario they dictate, and to make mission changes and debugging easier, the world files use a naming convention. The first four letters of the world file name are used to differentiate the world file according to what scenario it belongs to. In MechWarrior II the different missions had colors for their codenames, therefore the scenario files for mission brown would use 'brow' for the first four letters of the filename. The last four letters are then used to describe the file type- what it does in the scenario. Therefore the second briefing file for mission brown would be 'browbrf2.wld' ('brf' standing for briefing and the '2' at the end because it is the second briefing file).
The sim can only actually load one file, so to get the information from all of the other files relating to the scenario a top level file will call out other lower level files relating to it, which will in turn call out other lower level files. This is done by using a command called include.
Scenario files follow the xxxxSCN1.wld naming convention.
Briefing file names follow xxxxBRF1.wld, xxxxBRF2,
xxxxDBFS, and xxxxDBFF
General formation file follows Formatns.wld
Specific formation files follow xxxxFRM1.wld
User's star file follows Userstar.wld
Friendly Mech stars follow xxxxUSR#.wld
Enemy Mech stars follow xxxxENS#.wld
Other vehicle star types are discussed in part iii of this document.
Planet files follow xxxxPLT1.wld
Palette files follow xxxxPAL1.wld
The general map file follows MW2_MAP1.wld (for MechWarrior II)
Specific map files follow xxxxMAP1.wld
The general shot file follows MW2_SHT1.wld
The general shot file follows MW2_XPL1.wld
World files follow xxxxWLD1.wld
Area files follow xxxxARE#.wld
Start points follow xxxxST#1.wld (# = 0 for userstar, 1 for the next star, etc...)
Navpoint files follow xxxxNAV#.wld
Other navpoint types are explained in part iii of this document.
Scrounge files follow xxxxSCRI.wld
INCLUDE
include <called_file>
called_file is the name of the file that you wish to include
in this file. An include can be used in any file, but most occur
in the SCN1 file and the WLD1 file.
ALLIANCE
alliance
<alliance1>
<alliance2>
<alliance3>
...
end
alliance1, alliance2, alliance3, etc.. are all possible
alliances (teams) for that particular scenario. These get used
later in the SCN1 file in the star declaration fields to
assign the proper bitmaps and camos to the players' vehicles.
STAR
star
<star_filename> <star_alliance> <star_formation> <star_disposition>
<star_filename> <star_alliance> <star_formation> <star_disposition>
<star_filename> <star_alliance> <star_formation> <star_disposition>
...
end
The star declaration fields determine the alliances, formations,
and dispositions that all of the gamepiece players in the world
will have. The order in which you enter these will also determine
which 'group' each star is numbered. The first star declared will
become star 0, the next star 1, star 2, etc... These group numbers
will be used later in the gp_spec files. Furthermore, the
order in which the stars are declared here must be followed when
making mission tables (i.e. if the userstar is the first
star declared, its mission table must be the first one).
star_filename is the gp_spec file that is being defined
in this part of the star declaration for the particular scenario
that you are working on (i.e. Userstar, xxxxENS1, etc...).
star_alliance is the alliance that you want the star to
be grouped with. This has nothing to do with how one star will react to
another (whether they are considered an ally or enemy), but rather
dictates what camos and texture maps will show up on their vehicle
(i.e. clan insignias). This has to be one of the alliances declared
in the alliance field (above).
star_formation is the formation that you want the star
to start out in when the sim begins. The possible formations come
from the list in the formatns.wld file or any other scenario specific
formation files that have already been included in the SCN1 file.
star_disposition determines what side the star is on (friendly,
enemy, neutral), and how each star will react when in contact
with another star. Any of the same type will not fire upon eachother.
Friendlies will fire upon enemies and vice-versa. Neutrals are
only supposed to fire if fired upon (not used yet).
MISSION
mission <star_filename> <total_mission_time> <mission_result_audio>
<ID#><action><type><target ><(start)>< time><mpt><dnd><priority><critical><audio>"<text>"
<ID#><action><type><target ><(start)>< time><mpt><dnd><priority><critical><audio>"<text>"
<ID#><action><type><target ><(start)>< time><mpt><dnd><priority><critical><audio>"<text">
...
end
These mission tables are necessary for every star you
include in the scenario. They determine exactly what each star
will try to do and how they will react to other stars or occurrences
in the game. Furthermore, the mission tables should follow the
order given in the star declaration fields (i.e. if star declaration
field gives userstar first then browens1, browent1, browusr1,
then the userstar mission table should come first followed by
browens1's, browent1's and then browusr1's).
star_filename is the gp_spec file to which you wish to
give these orders to (i.e. userstar, browens1).
total_mission_time is the total time for the mission in
seconds. If the mission is not already successful before this
time expires, then the mission will fail automatically. This is
used to keep people from sitting around and waiting for things
to happen. If the time is set to -1 then the mission's time limit
never ends.
mission_reslt_audio is the audio file that gets called
up when the user either fails or succeeds a mission. If a mission
is successful, the sim plays the mission_result_audio with
an 's' appended to the end of it. If the mission is failed, it
appends an 'f". Therefore, if the mission_result_audio
is 'gene001', the resultant audio file called up upon a successful
mission will be 'gene001s'. These filenames must be seven characters
or shorter so that when the "s" or "f" is appended to it, it will
still be only eight characters long.
ID# is the objective number (0,1,2,3,4,...). The objective to start the Mech out at its starting point is always the first objective (0), so any real objectives start from ID# 1 and go from there. Unfortunately, the sim cannot simply look at the ID number to know what order to check the objectives and therefore the objective must follow the order of the ID# (i.e. objective with id# 0 comes first, id# 1 comes second, etc...). AI stars look for the first active objective among the mission table as its current one, therefore, the order in which the objectives are placed is very important (i.e. if you want to have a particular star of Mechs to attack the user above all else if the user destroys a particular item, the ID# for that objective should be 1), otherwise, the objectives should follow the order in which they are supposed to be done. The user's star of Mechs will ignore the objectives in the mission table. In that case the table is used solely for keeping track of what the user has done, and therefore the order, except for the start objective, is of no importance.
Tip: The mission tables, especially for the userstar, get
very complex, so if at all possible, leave comments after each
objective with a rem statement (#) so that comprehension and debugging
will not be impossibe a month later.
action is the command that you want to give for that particular objective. The list of possible commands follows:
Begin- puts the star at its begin file's (startpoint)
location in its predefined (in the star declaration) location.
This objective is always successful.
Recon- means that every object in the target file that is labeled with Recon must be reconnoitered, or "reconned" (i.e. the user must get up to the targets and press the inspect key). Reconning the labeled objects can be done in any order, and they can also be destroyed immediately after successful inspection. It will succeed once all labeled objects are successfully inspected. Failure of this objective will only come once the objective time has expired, once the mission time has expired, or if a forced failure (another objective) has been applied to it. This has only been used for user's stars- whether or not this can be used for AI Mechs is not known.
Destroy- means that every object in the target file labeled
with Destroy must be destroyed. This will succeed once all objects
labeled with Destroy are destroyed. Failure of this objective
will only come once the objective time has expired, once the mission
time has expired, or if a forced failure (another objective) has
been applied to it.
Defend- means that the star must protect the objects listed
as Defend in the target file. This will fail as soon as any of
the labeled objects are destroyed. Success of this objective
will only come once the objective time has expired, once the mission
time has expired, or if a forced succeed (another objective)
has been applied to it.
Goto- means that the leader of the star must come within
X meters of the navpoint, object, or gamepiece labeled with Goto
in the target file. The distance (X) is 100 meters for all objects
and gamepieces. The distance for navpoints is determined in the
navpoint file. Success of this objective comes as soon as the
leader has reached X meters from the target. Failure of this
objective will only come once the objective time has expired,
once the mission time has expired, or if a forced failure (another
objective) has been applied to it.
Wait- is mainly used for AI stars. It forces
that star to go to within X meters of the targeted navpoint labeled
with a Goto and wait until the objective is completed or another
objective with a lower ID# has been activated. The distance (X)
is defined in the navpoint file.
Sleep- is mainly used for AI stars. It
forces that star to go to within X meters of the targeted navpoint
labeled with a Goto and sleep until the objective is completed
or another objective with a lower ID# has been activated. Sleeping
means that the star is shutdown, not visible on radar, and will
only wake up if an enemy star comes within a certain distance
(defined in the gp_spec file of the sleeping star) or is shot
at. The distance (X) is defined in the navpoint file.
Shutdown- is mainly used for AI stars.
It forces that star to go to within X meters of the targeted navpoint
labeled with a Goto and sleep until the objective is completed
or another objective with a lower ID# has been activated. Shutdown
means that the star is shutdown, not visible on radar, and will not
wake up until the objective is completed or another objective
with a lower ID# has been activated. The distance (X) is defined
in the navpoint file.
Return- is mainly used for AI stars. The
Return objective forces the gamepieces within that star to
go to the targeted and Return labeled navpoints if they go into
a retreat or if they are given a Return objective. This objective
is infrequently used as the AI Mechs will automatically return
to their return labeled navpoints automatically if retreating,
and Goto objectives are just as easy to use.
Objsucceed- forces the objective in the target field to
succeed. The target field must list the objective as follows:
<star_filename'_'objective_number> (i.e. to succeed
the user's fifth objective it would be userstar_5) . This
has only been used with user's mission tables.
Objfail- forces the objective in the target field to fail.
The target field must list the objective as follows: <star_filename'_'objective_number>
(i.e. to fail the user's fifth objective, it would be userstar_5)
. This has only been used with user's mission tables.
Objshow- forces the objective in the target field to toggle
its type. If the type is Visible, it switches to hidden
and vice-versa (see type field later in this mission section).
The target field must list the objective as follows: <star_filename'_'objective_number>
(i.e. to toggle the user's fifth objective from visible to hidden
or vice-versa, it would be userstar_5) . This has only been
used with user's mission tables.
Msnsucceed- forces the mission to succeed. The target
field must be userstar_0. This has only been used with
user's mission tables.
Msnfail- forces the mission to fail. The target field
must be userstar_0. This has only been used with user's
mission tables.
Leave- used as an opposite to Goto. This will
succeed if the star (only used with user's stars so far) goes
X meters away from the targeted, Leave- labeled navpoint. The
distance (X) is defined in the navpoint file.
type defines whether or not the objective is visible on
the user's objective list screen. If it is tagged visible,
it is seen. If it is tagged hidden, it is not.
target lists the file that the sim looks in to attach the
appropriately labeled objects to the objective (i.e. on a destroy,
the star must destroy all of the objects that are listed in the
targeted file with a destroy label attached to it).
(start) - Start (<result> <objective_number>) defines when the objective has become active and when the countdown on the time begins. Activation is done upon failure or completion of other objectives. In the <result> field of the start declaration, a letter is used to dictate whether the current objective should become active on the Success (S), Failure (F), or just completion (C) (completion means success or failure) of another objective. Then the <objective_number> field is the ID# of the objective that is being watched for completion. If the objective being watched is in the same mission table as the objective that is watching it is, then simply use the ID# in the <objective_number> field (i.e. a start based on the failure of objective three would be (F 3)). If the objective being watched is in another star's mission table then the <objective_number> should be preceded by the star's filename and an underscore (i.e. if activation of an enemy star's objective is based on the user succeeding its fifth objective, then the start field would look like (S userstar_5).
Start fields can also call a table to use ANDs or Ors to link the activation of an objective to the result of many other objectives. In this case the start field would simply become (table). The next line would then state either Table and or Table or (can only be one or the other). Then, on the next lines, use the <result> <objective_number> format to pick which objective results are to be watched. Finally, end the table with endtable.
(Example: a destroy objective that would start on the success of the third objective, the failure of the second objective, OR just the completion of the sixth, tenth, and thirteenth objective would be:
4 destroy hidden userstar (table) -1 1 0 None None None ""
table or
S 3
F 2
C 6
C 10
C 13
endtable )
time defines how long the star has to complete the objective.
If the objective is not completed before the countdown completes,
then it automatically fails. If the time is set to -1 then the
objective's time limit never ends.
mpt means Mechs-per-target. This defines how many Mechs
from the star will attach themselves to each target from the list
of labeled objects.
dnd is the do-not-disturb setting. This changes how stars
will react around enemy gamepieces. If dnd is set to 0
and an enemy Mech comes in range (defined in the gp_spec file),
then the star will send out gamepieces to fight. If it is set
to 1 then the star of Mechs will ignore any approaching enemies
and continue its objective unless they are shot. If it is set
to 2, then the star will ignore everything and just try to complete
its objectives. This applies to AI Mechs only.
priority is set to either primary, secondary, tertiary,
or return. These settings define the priority of the
objectives for the userstar. These objectives don't actually effect
how they're seen by the sim at all; they only change how they
show up in the sim objective screen. If no priority is desired
then None should be used.
critical is set to either Mandatory or Optional.
This determines whether or not the objective must be completed
before the mission is considered successful.
audio names the audio files that get played when an objective
is succeeded or failed. If the objective is succeeded then the
sim plays the audio file with the same name as the audio
string appended with an 's'. If the objective is failed then the
sim plays the audio file appended with an 'f' (i.e. if
the objective with an audio string of 'brow002' is succeeded
then the sim plays the audio file named 'brow002s", and if
failed then 'brow002f'). If no audio is desired then None
should be used.
text is the text string that shows up as the objective
on the sim objective string. This text must be enclosed in quotes
(i.e. "Destroy the Reactor at Nav Omega").
orders_begin
<text w/ control characters>
orders_end
text w/ control characters - contains the body of the briefing. The following control characters may be used; all must be proceeded by a backslash (\)
n - carriage return. The text will auto wrap unless a carriage return is specified. \n on a blank line will cause the shell to display a blank line.
c -centers text on line.
t - tab.
s - hard page.
q - includes information returned by sim (used in de-briefing).
r# - If #=0 then this character gets replaced by the player's current rank. \r1 for the next rank, \r2 for the rank after next.
S_desc (es-desk), or star description, is used to define certain
parameters about the make-up of the user's star in all missions
and also for the enemy stars in Instant Action missions. The
first s_desc is always for the userstar. Every mission must have
one. The second s_desc will be applied to all enemy stars in
Instant Action missions. A second s_desc is not used or necessary
in other types of missions.
s_desc<pilot_rank><max_tonnage><rec_mechs><max_mechs><default_mech1><default_mech2>
pilot_rank determines the A.I. values (pilot skill, gunnery
skill, rubberband radius, target radius, sleep radius) that will
be set in the gp_spec declaration for A.I. controlled Mechs.
The A.I. controlled Mechs start at the rank declared, but each
succeeding wave has better skills. Allowed values are between
1 to 8, with 1 the best and 8 the worst.
(table showing A.I. values and ranks corresponding to pilot_rank
value?)
max_tonnage determines the heaviest Mech that can be taken
into a mission. The user will not be allowed to select a Mech,
either for himself or his starmates, whose weight exceeds this
number.
rec_mechs determines the recommended number of Mechs for
a mission. This is the number of Mechs that will appear in the
shell star configuration and will be brought into the mission
by default.
max_mechs determines the maximum number of starmates that
the user can bring into a mission. This should always be equal
to or greater than recommended_mechs. If the value is
greater than recommended_mechs, the user can add Mechs
until max_mechs is reached.
default_mech should name an MEK file (i.e. smn03std).
The first default_mech will be the user's default Mech.
Additional default_mech declarations must be included
so that all possible starmates have a default declared. If max_mechs
is 2, than there should be 3 default_mech declarations,
one for the user and one for each starmate. Even if recommended_mechs
is less than max_mechs, there must still be a default_mech
for every possible Mech.
supscreen <start_up_screen>
start_up_screen names an existing launch screen that the
shell will display while the world is loading. It is a file name,
but 7 characters long, since the last character tells the shell
what resolution the picture is.
Planet_desc declarations are only necessary for Instant Action
missions. They have no effect on career missions, and are not
currently being used for Net missions.
planet_desc_begin <planet_anim_#>
<text>
planet_desc_end
planet_anim_# gives the number of the small planet animation
that should be shown on the Instant Action screen.
text can be any three lines of ASCII text that will be
displayed in the shell to describe the setting for an Instant
Action mission.
The userstar contains the user's Mech and his starmates. The
ENS files contain enemy Mechs. Other special purpose Star files
are explained below.
gp_spec <chassis_name> <configuration>
<group_id> <authority> <control> <appl_actions>
"<target_text>" "<contents_text>"
gp_spec <chassis_name> <configuration>
<group_id> <authority> <control> <appl_actions>
<gunnery_skill> <rubberband_range> <sleep_range>
<target_range> <pilot_skill> "<target_text>"
"<contents_text>" <targeting>
but see also the new syntax for Mercenaries.
chassis_name is the name of the MEC file (converted to
BWD) for this Mech. MEC (BWD) file should contain the geometry
declarations for a Mech. It is described elsewhere in this document.
configuration is the name of the MEK file to use for this
Mech. MEK file should contain the weapons, armor, and other configuration
information for a Mech. It is described elsewhere in this document.
group_id is the number given to this star in the SCN file.
All Mechs in a star have the same group_id. The userstar
is always 0, the next star declared is 1, the third star declared
is 2, etc.
authority is either leader or follower.
A star can have only one leader and any number of followers.
control can be user, internal, or remote.
A gamepiece with user control is controlled by a human
player. There can be only one of these in a mission. A gamepiece
with remote control is controlled by a network player.
A gamepiece with internal control is controlled by the
A.I.
appl_actions are actions that can be applied to a gamepiece
as an objective in the SCN file for a mission. There can be any
number of these in a gp_spec declaration; they are separated
by a semicolon (i.e. destroy;defend;explode).
The following five fields are only applicable to Mechs with
internal control. They have no effect on Mechs with user
or remote control. They are usually excluded from the
gp_spec declarations for user and remote Mechs.
gunnery_skill is a number between 1 and 5, with 1 being
the best and 5 being the worst.
rubberband_range is the distance a Mech will go from his
star leader, in meters. Default value is 250 meters.
sleep_range is the distance at which a sleeping Mech will
be awakened by the presence of an enemy Mech, in meters. Default
value is 250 meters.
target_range is the distance at which a Mech shoots at an
enemy mech, in meters. Default value is 250 meters.
pilot_skill is a number between 1 and 5, with 1 being the
best and 5 being the worst.
The following two text fields are not applicable to a Mech
with user control in a career mission, but should be used
in Net missions.
target_text is the string that appears when the gamepiece
is targeted. Length is 20 characters.
contents_text is the string that appears when the game
piece is inspected. Length is 20 characters.
The targeting field is only applicable to Mechs with internal
control.
targeting can be NoTarget, NeverTarget, AlwaysTarget.
A gamepiece set to NoTarget is not put on the user's targeting
list, and can only be targeted by a "Q" target. A gamepiece
set to NeverTarget is not put on the user's targeting list,
and cannot ever be targeted, even with "Q" target.
A gamepiece set to AlwaysTarget will always be on the user's
targeting list, regardless of range, unless the Mech is shutdown
or sleeping.
xxxxEND#
gp_spec file for a enemy dropship gamepiece.
xxxxDOR#
gp_spec file for a door gamepiece. (Gamepieces are used as doors
when they must be able to move (open or close) as a reaction to
another gamepiece's objective.)
xxxxBOOM
gp_spec file for a nuke gamepiece. (Used as an objective-based
trigger of a nuclear blast.)
planet <gravity> <atmosphere> <seconds_in_day>
<days_in_year> <tilt> <circumference>
gravity is the force of gravity felt on the planet's surface,
in Gs. Usable values range from 0.0 - 2.0.
atmosphere Unknown. Use default value 0.
seconds_in_day number of seconds in a day. Must be an
integer.
days_in_year number of days in a year. Must be an integer.
tilt Axial tilt of the planet. Must be an integer.
circumference Circumference of the planet. Must be an
integer.
planet2<mean_temp><max_jump_height><max_height><min_height><coef_friction><can_eject>
mean_temp sets the ambient temperature for the planet,
in degrees Celsius. This only affects the Mech's rates of heat
dissipation. If mean_temperature < -30, heat is dissipated
at a faster rate than normal. If mean_temperature >
-30, but < 50, the rate of heat dissipation is normal. If
mean_temperature > 50, heat is dissipated at a slower
rate than normal. Must be an integer.
max_jump_height in centimeters. The sim will limit jumpjets
so a Mech will be able to get to half of the value set in max_jump_height
with fully charged jumpjets.
max_height sets the maximum height of the terrain for a
world, in centimeters. The sim uses this information to color
code the map view.
min_height sets the minimum height of the terrain for a
world, in centimeters. The sim uses this information to color
code the map view.
coef_friction can range fro 0.0 to 1.0. It determines
the how steep of a surface that a Mech can walk up. The higher
the coef_friction, the steeper the surface.
can_eject is a boolean value that determines whether the
user can eject or not in this world. 0 for no, 1 for yes.
planet3 <reverse_damage_shade> <no_light_shifting>
<hide_sky> <hide_ground> <hide_horizon>
reverse_damage_shade is a boolean value. If it is set
to 1, then the Mech's damage shade in reverse. Usually only used
in a world with an inverted fog palette.
no_light_shifting is a boolean value. If it is set to
1, then the sim never does light source shifting for explosions.
hide_sky is a boolean value. If it is set to 1, then the
sim will not draw or refresh the sky. Usually only used for enclosed
missions.
hide_ground is a boolean value. If it is set to 1, then
the sim will not draw or refresh the ground.
hide_horizon is a boolean value. If it is set to 1, then
the sim does not draw the horizon.
now <now_in_day> <now_in_year>
now_in_day the sim will start a mission at the time indicated,
in seconds.
now_in_year the sim will start the mission the indicated
number of days into the year. Has no effect.
light <x,y,z> <type>
x,y,z is the coordinates of the light source, in centimeters.
type if type is set to 0, the sim will use a "point"
light source, if type is set to 1, the sim will use a "omni-directional"
light source.
ambient <amount>
amount varies the amount of ambient light in the sim.
Values can be integers from 0 to 256. Lower numbers give a higher
proportion of directional light and therefore produce more contrast
on visible objects.
shadedist <distance>
distance is the distance beyond which objects receive only
ambient light.
view <hither_clip_plane> <yaw_clip_plane>
hither_clip_plane in centimeters. Objects will no longer
be drawn if they are closer to the user than the value set in
hither_clip_plane. Usually set to 64.
yaw_clip_plane in centimeters. Objects will no longer
be drawn if they are farther from the user than the value set
in yaw_clip_plane.
luma <type>
type tells the sim the type of luminosity for this planet.
Almost always standard.
hidden_text "<text>"
text is the default string that the sim will display if
an object or a gamepiece does not have a value entered in its
contents_text field.
horizon_map <color>,<height>
color unknown. Set to 0.
height determines the height, in pixels, of the horizon
ramp.
lightobj <object>
object to tie the light source to. It must be placed in
a static block, and the object must be declared immediately
before the lightobj declaration.
The planet file for a mission should include the palette file
for that mission.
include xxxxPAL1
palette_grp <type> <standard> <explosion>
<flash> <smoke>
type of palette being declared. Types currently being used
are day, dusk, night, ir (for infrared).
standard name of the palette file (COL) that will be called
out as the standard palette.
explosion name of the palette file (COL) that will be called
out as the explosion palette.
flash name of the palette file (COL) that will be called
out as the flash palette.
smoke name of the palette file (COL) that will be called
out as the smoke palette.
palette_misc <black> <red> <cockpit>
<alternate>
black name of the palette file (COL) that will be called
out as the black palette. The sim will fade up from this palette
at startup.
red name of the palette file (COL) that will be called
out as the red palette. The sim will fade to and from this palette
when the user has taken a substantial amount of damage.
cockpit name of the palette file (COL) that will be called
out as the cockpit palette.
alternate name of the palette file (COL) that will be called
out as the alternate palette.
include testare1.wld include testare2.wldetc.
task <taskname> <period> <parameters>
where taskname is the name as described below, period is how often in program cycles the animation is updated, and parameters are different for each type of task, as described below.
Period can be used to lower the load on the sim of calculating animations. If period is zero, the animation task will be updated every cycle. For slow moving tasks, period can be used to have it updated only periodically.
Taskname is one of the following:
task spinner <period> <objinst>;<rx>,<ry>,<rz>,<time>Where objinst is an object instance from a previous object directive, rx, ry, and rz are the amount (in degrees) that the object will rotate per time, where time is in seconds (floating point).
task colorspin <period> <objinst>;<color1>,<color2>,...Where period defines how often (in seconds) the cycle will complete, objinst is an object instance from a previous object directive, and each of color1, color2, etc. indicate a specific color. There is a limit of 16 colors which can be specified currently.
task flycircle <period> <objinst>;<radius>,<interval>,<enable>,<sign>Where objinst is an object instance from a previous object directive, radius is the distance (in cm, the world file unit) from the center of the flight circle, interval is the number of seconds per revolution of the object, enable is a flag determining whether the animation is to be enabled or not (0 for disabled, 1 for enabled), and sign is ignored.
task animator <period> <objinst>;<interval>,<enable>,<track>Where objinst is an object instance from a previous object directive, interval gives period (in seconds) of the animation (note: I am not entirely sure on the use of interval for this one; I can look further if you need), enable is a flag indicating whether the animation is initially on or off, and whether it is a master animation (0 for off, 1 for on, 128 to declare it as a master animation). The master is the track which indicates the completion of all animation tracks. If you are declaring a hierarchy of animations, they should be declared in the reverse order of the tracks, and the master must come first.
path <name> x y z rx ry rz t x y z rx ry rz t ... endWhere name gives a name to this list of points, and each line in between the path command and the end command specifies one point along the path. The x, y, and z coordinates are absolute world coordinates in centimeters. The rx, ry, and rz coordinates are rotation angles in degrees (see rotation below), and the t variable is the time in seconds that the object should take to go from this point to the next in the path. If the path is looping, the time on the last point will specify how long to take from the last point back to the first.
task path <period> <objinst>;<looping>,<rotation>,<name>Where objinst is an object instance from a previous object directive, looping is either loop, repeat, or oneshot, rotation is either rotate or norotate, and name is the name given in the path directive.
If loop is specified, the object will continue from the last point back to the first and repeat forever. If oneshot is specified, the object will follow the path once and stop, never to go again. Finally, if repeat is specified, the object will instantaneously pop back to the beginning after completing the path.
If rotate is specified, the object will turn towards the next point when moving. Otherwise it will not rotate at all. This rotation (or lack of) is always added to the rotation angles specified in each line of the path.
task AmbientSound 0 objName;radius,sndfile,enableThis lets you trigger a sound file when the user is near an object.
object heli1=helicop 1,1,1 0,0,0 0,0,0 0 . world task AmbientSound 0 heli1;50,whoop,1
mangle_on
block -12830,-1630,-14100 29080,15500,29450
light_begin
position -1296,20,123
radius 10000
light_end
object tl1sigcb=tl1sigcb 1,1,1 0,0,0 -20376,0,153042 0 terrain fixed
collision tl1sigcb ground
object smo2_0210=fir2_3 6,10,6 0,0,0 -1296,20,123 0 flame world
task ambientsound 0 smo2_0210;400,mecfire1,1
endblock
mangle_off
NAV files are for the user's visible navpoints. These will be targetable in the sim and usually relate to the user's mission objectives.
GOU files are for the user's hidden navpoints. These are often used for triggering other objectives in the mission table.
GOE files contain navpoints for enemy stars.
LVE files contain navpoints that are associated with a leave
objective. Often, two of these are used to define the area for
a mission. Both have the same center, but one has a slightly
larger radius. If the user leaves the smaller navpoint, they
are given a warning. If they leave the larger navpoint, they
fail the mission.
navpoint <x,y,z> <angle> <enable> <flags> <key> <group_id> <radius> <appl_actions> "<text>"
navobject <group_id> <object> <radius>
<appl_actions> "<text>"
x,y,z coordinates of the navpoint in the world, in centimeters.
angle if the navpoint is used as a start point,
this is the angle at which the gamepieces will start facing.
0 is due north.
enable is a boolean value. If it is set to 1, then it
will be targetable by the group that "owns" this navpoint
(see group_id). All navpoints used by A.I. gamepieces
should be enabled. GOU points that the user should not see should
not be enabled, but NAVs should.
flags not used. Set to 0.
key not used. Set to 0.
group_id the number of the group that "owns"
this navpoint. A gamepiece cannot ever goto, leave,
target, or otherwise interact with another group's navpoint.
radius in meters. This is the radius at which the sim
will register a gamepiece as being at the navpoint.
appl_actions are actions that can be applied to the navpoint
as an objective in the SCN file for a mission. There can be any
number of these in a navpoint declaration; they are separated
by a semicolon (i.e. begin;goto;wait).
text is the text that will appear when the navpoint is
targeted. Up to 20 characters.
object is the name of the object that will be the navobject. navobjects currently do not work as intended.
Wasm
Wasm is the primary world building tool. It converts the text WLD (WorLD) files into the binary BWD (Binary WorlD) files used by the sim.
wasm </a> </wX> </v> </p=pathname> <input_file_name> <output_file_name>
/v Optional. This causes WASM to simply echo the version number of the program and exit.
/p=pathname Optional. This overrides the pathname that WASM uses to find the project file. If no switch is given, WASM looks for an environment variable called "MW2PROJ". Otherwise it uses the default directory.
/a Optional. This causes WASM to parse all included files. This is a guru option; don't use it unless you know what you are doing.
/wX Optional. Set the warning level to X (default is 3)
input_file The input file must be a text MW2 world data file. The WASM tool defaults to an extension of .WLD if none is given.
output_file Optional. The output file identifies the name of the
file for writing out the binary version of the world text file.
A default extension of .BWD is used if none is specified. If
no output file is specified then the input file with a .BWD extension
is used.
Stripwld.exe
Stripwld is a utility that writes out a batch file for processing a world.
Stripwld will read through a world following the includes and build a bat file that processes the includes in reverse order so that you can properly process and add a world to the project file.
Usage:
stripwld <world>
Output:
Stripwld will output a bat file that is a series of lines
with the includes used throughout the world files in reverse order.