The MercNet ™ Mission Building FAQ

Beta Edition

Last revised: 24 Jan 1997
This document answers many Frequently Asked Questions about building missions for MechWarrior® 2: Mercenaries™.
The original copy of this document is located at http://www.activision.com/mercnet/mercmfaq.htm.

Table of Contents


Where else can I learn about building missions?


What should I know before I start?


What kind of missions can I build?

There are currently some limitations on the kinds of missions you can build. We hope to relax these in a future version.


What are the steps in building a new mission?


What files should I modify when building a new mission?

The Main File: ????.wld

DEM1.wld - This file actually is the four character name of your mission, be it DEM1, bob1, or whatever. It is how stripwld determines how to name the MWM file. All that has to be included in this file is: include ????scn1, where ???? is the name of the mission.

The Netshell Briefing Files: ????brf?.TXT, ????name.TXT

????brf.txt - this file is just a plain text file that contains all the briefing data that gets displayed in the host setup screen… and (in two-team games) for Team A.
There are special escape sequences you can use to change the color of text:

Very long lines are wrapped properly in the display window. It must end with &X to indicate end of file.

????brf1.txt - This file need not be present. If it is present, when users pick a team game, it will be displayed as the briefing for players in Team B.

????name.txt - This is the name of the mission that gets displayed at the top of the mission briefing screen. It must end with &X to indicate end of file.

The Netshell Limit Files: ????lim?.txt

These files can have several commands, including

????lim0.txt - This file sets the limits for the whole mission. Usually it just contains FREE or TEAM, plus MAXPLAYERS.

????lim1.txt - This file, if present, sets the limits for Team A. Usually it just has one line. That line sets the tech level for Team A, i.e., Clan or IS.
????lim2.txt - This file, if present, sets the limits for Team B. Usually it just has one line. That line sets the tech level for Team B, i.e., Clan or IS.

The Main Scenario File ????SCN1.WLD

Open up the main scenario file, in this example TES1scn1.wld. In it you will see many wondrous things. Do a quick run through of what is in the scn1 file and decide why it is important to you. First comes the line:

include formatns

What this does is include a standard file that defines the placement of 'Mechs in different formations. Don't worry about it, but also don't forget it. Otherwise, you'll get what we call the 'Mech totem pole, where all the 'Mechs are stacked on top of each other… a bad thing… Next we have the alliance declarations, like so:

alliance
  FC
  Draconis
  FRR
  Wolf
  SmokeJaguar
  GhostBear
  Wild1
  Wild2
end

This defines the names for all the different teams that are in the game. There can only be a total of 8 different alliances. Names do matter. This name determines what logo to put on the coinciding 'Mech. Now comes the star declarations, which look like this:

star
  #Star       #Alliance     #Formation    #Disposition
  en00star    FC            star          Enemy
  en01star    Draconis      star          Enemy
  en02star    FRR           star          Enemy
  en03star    Wolf          star          Enemy
  en04star    SmokeJaguar   star          Enemy
  en05star    GhostBear     star          Enemy
  en06star    Wild1         star          Enemy
  en07star    Wild2         star          Enemy
end

As you may have guessed, this is where the actual stars (i.e.: individual units of 'Mechs) are defined. These must be declared in a specific way. En00star, En01star, and so on are not changeable. These are the names that the net shell uses to write out who is driving which 'Mech. You must use these names for MercNet to work properly. After the star name comes the alliance, which you defined earlier. Make sure that you list them in the order you defined them. After that comes the starting formation of the star. This can be any of the formations in the game, such as line abreast, wedge, star, etc. It doesn't really matter which one, just as long as there is a valid one there. Now comes the disposition. This determines how the 'Mechs appear in the game, meaning whether they'll be green dots, blue dots, or red dots (and automatically targetable using the 'e' key). Now comes the fun stuff, the mission table. Here is the mission table for en00star:

#Mission Decl   #Star Name    #Time     #Audio
mission         en00star      -1        gene001
  #ID #Action  #Type   #Target #Activation  #Time #Priority #Critical  #Audio  #Text
   0   Begin    Hidden  TES1st10 (Initial)   -1    None     Mandatory   None    ""
   1   Wait     Visible Null     (C 1)        1    Primary  Mandatory   None    "Destroy all enemy 'Mechs"
end

Line 1 tells the sim that a mission table is being defined, who it is for, how long it is for (-1 meaning infinity), and what audio file to play when the mission begins. It is advised that you leave it at gene001. Now comes the goal definitions. Let's look at the first one with its comment line:

#ID #Action  #Type   #Target #Activation  #Time #Priority  #Critical  #Audio  #Text
   0   Begin      Hidden  TES1st10 (Initial)   -1 None     Mandatory   None    ""

The first number is the goal number. This can be used to create tables and stuff, but don't worry about it. Just make sure that each goal is sequentially ordered and unique and you'll be just fine. Next comes the action goal. In this case the goal is to begin, which means this is where en00star will start. Next is hidden, which means that this particular goal will not show up on the objectives ('F12') list. Next is the target or where the goal will occur. In this case, the target is TES1st10, which is a nav point, which we call the start point, for obvious reasons. Next comes the activation or when this goal should happen. In this case, it is initial, which means it occurs when the game begins. Next is the time allowed for this goal, its priority, how important it is to the completion of the mission, the audio file to play when the goal is acheived, and what text to display in the objectives list. The first two lines of this mission table should be identical for all the stars in your mission, which accounts for the different star and start point names.

Now we come to the next goal: the kill goal. This goal really doesn't do anything. As you can see, the action is to wait, which does nothing. The main reason for the existence of this goal is to have the Destroy All Enemy 'Mechs displayed in the F12 display. Look at the activation parameter, though. See that (C 1)? That means that upon Completion of goal # 1, this goal will be successful. But since it is goal number one, it can never be completed. So you can go about merrily killing your friends to your heart's content. For basic, free-for-all, kill-or-be-killed missions, this will be fine. For more complex ones, examine the examples to see how the devious minds of our game designers really work.

The most important thing to remember about mission tables is that it is really easy to screw things up, and even easier to miss where you might have made a mistake. This will be one of the most frustrating things in mission creation. Getting the tables to do what you want them to. Have fun… Make sure that you have a mission table for every one of the stars that you have declared...or bad things will happen. After the mission tables come the include files. Here's what each one does:

include en00star
.
.
.
include en07star

This includes the different star definition files written out by the net shell. It's needed in order to have something to drive in the game. You'd probably feel really stupid if you went into the game without your 'Mech!

include DEM1plt1

This includes the planet definition file, which defines everything from the gravity and ambient temperature of the world you're on, to how long the days are, to where the light comes from, even which palette file to use.

include DEM1are1

This is the file where all geometry is defined, placed, and given meaning in this shallow world we live in.

include MW2_SHT1    # includes includes shot geometry and explosions

This is one of those "must be here files." It defines all the geometry for lasers, missiles, fires, explosions, and so on. If this isn't here, have fun trying to kill anything…

include DEM1st10    # includes includes 'mech starting navpoint
  .
  .
  .
include DEM1st80    # includes includes 'mech starting navpoint

These are all the starting points of the stars. They must be included so the sim will know where to put everyone. And that's it. Now we get to go to all the other files.

Formatns:

Don't worry about this one. Just use it.

The Star Files: ????STAR

En00star - En07star:

These files are written out by the net shell at run time. They define the 'Mechs used by each star. You don't change these. You only need to know about them because they need to be in your TOOLS folder to compile missions!

The Planet file: ????PLT1

This defines the environment of the mission, and includes everything from gravity to length of day. There are several different parameters to set and play with.

To begin with, we have:

planet 0.8 0 1000000 365 0 27000

(or the generic listing of)

planet <gravity><atmosphere><seconds_in_day><days_in_year><tilt> <circumference>

This line does the following:

planet - Starts the line.

gravity - Strength of gravity, values can be 0.0 - 4.0.

atmosphere - Unknown. Use 0. (Yes, that's what it says in OUR docs…)

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 - The circumference of the planet. Must be an integer. (Don't ask…)

Next, we have the planet2 line, which goes like this:

planet2 -101 50000 10000 0 0 1

(or…)

planet2 <mean_temp>

<max_jump_height><max_height><min_height><coef_friction><can_eject>

mean_temp - Ambient temp. of the planet in Celsius. This affects the speed at which 'Mechs dissipate heat. If less than -30, heat bleeds off faster. If more than -30 but less than 50, heat dissipates normally. If more than 50, heat bleeds slower. Must be an integer.

max_jump_height - In centimeters. Limits how high one can jumpjet… A 'Mech will be able to reach half the set height with fully charged jumpjets.

max_height - Sets the maximum height of the terrain in the world, in centimeters. This is used to compute the color used in the satellite view.

min_height - Sets the minimum height of the terrain, in centimeters.

coef_friction - Can range from 0.0 to 1.0. It determines the steepest surface a 'Mech can walk up. The higher the value, the steeper the surface.

can_eject - A boolean value that determines if a pilot is allowed to eject on this planet. 0 means no, 1 means yes.

And, of course, what world would be complete without the following planet3 line:

planet3 0 1 0 0 0

(or rather…)

planet3 <reverse_damage_shading><no_light_shifting><hide_sky><hide_ground><hide_horizon>

reverse_damage_shading - Used in fog worlds so when 'Mech parts take damage they still get darker, instead of lighter…

no_light_shifting - Not used anymore, leave it at 1.

hide_sky - Tells the sim whether or not to render the sky. Useful for upping frame rates a tiny bit in enclosed missions. 0 = no, 1 = yes.

hide_ground - same as above but for the ground plane instead.

hide_horizon - same as above but for the horizon gradient.

Let's go onto the other stuff now…

now 0 0

now - first value sets what time of day it is. 0 = dawn, 1 = day, 2 = dusk, 3 = night, second value isn't used…

light 2450,25000,1314 1

light - defines the position of the light with the first three numbers <x,y,z>, and the type of light with the fourth. The two types of light are point (0) and infinite (1). When a light is point, the x,y,z coordinates give a position, when the light is infinite, the x,y,z value becomes a vector.

ambient 75

ambient - Sets the lowest level of light. i.e., how dark it gets.

shadedist 25000

shadedist - The maximum distance to compute shading information for an object, in centimeters. Very useful for optimization.

view 1 50000

view - The first number is the near clipping plane, in centimeters. Anything in front of it doesn't get rendered. The second number is the far clipping plane, in centimeters. Anything behind that also doesn't get rendered. Very useful for optimization.

luma standard

luma - Defines which luminosity lookup table to use. Always use standard.

hidden_text "empty"

hidden_text - This is a string. It is the default text displayed for any object that is inspected, but didn't have an inspection string set for it.

horizon_map 0,75,0 0 0 0

horizon_map - This defines the length of the horizon gradient.

You'll notice that there are files included here. These files set the palette and map information for the world.

Palette files:

The pal1 files each have a specific look and feel. You should basically check the palette description appendix to see which one you want to include here.

Map files:

The map1 files contain what we call the map ID declarations. The way our sim assigns texture maps to objects is by assigning a number to each polygon. This number is what we call the map ID. At render time, the sim looks in the specified map1 file for the ID of the poly it's trying to render. The map1 file lists those IDs and associates them with textures. See the example map1 file for a description of all the different ID #s and textures associated with them.

Camo Pattern Assignments:

Last in the PLT1 file is the camo declarations. This is where we define which camo set to use for each alliance. Take a peek:

camo 0 3
camo 1 1
camo 2 0
camo 3 2
camo 4 4
camo 5 5
camo 6 6
camo 7 7

The basic idea is as follows: the first alliance, alliance 0, receives camo set 3; the second alliance, alliance 1, receives camo set 1, and so on. These are the differences between different camo sets:
camo 0 - Plain steel panels
camo 1 - Dark steel panels
camo 2 - Medium steel panels
camo 3 - Tiger stripe camo pattern
camo 4 - Lined camo pattern
camo 5 - Cow camo pattern
camo 6 - Flat colored panels
camo 7 - Pirate flat black panels

So, you can determine who gets what by setting the appropriate camo variables.

Multiple Light Sources:

We have ways to slow the sim down. They are called light sources. The more you add, the slower you get. But, on the off chance you want to add more for various reasons, here you go:

light_begin
 position <x,y,z>
 radius I
light_end

The <x,z,y> value should be replaced with a coordinate in space, and should be replaced with the maximum range you want this light to affect, both in centimeters. Having multiple light sources are helpful when you have a cavern or canyon scenario and need certain places lit. These light sources are point sources, like little light bulbs, so keep that in mind when placing them. Also, you must declare each light source individually, so for more than one light, you'd have more than one of the above declarations.

An example Planet File

# {The first area of the planet file sets up various planet settings. 
#  Most settings aren't important to the look of the game}

planet 0.8 0 10000 365 0 27000
planet2 -101 50000 10000 0 0 1
planet3 0 1 0 0 0            # {The first value is important, 0 for no fog, 1 for fog}
# {The next section controls the main light source and its placement}
# Choose just one of these light lines:
light 888888,888888,888888 1 # {Makes the user the light source, good for night missions}
light 0,20000,0 1            # {Use in a fog world}
light 999999,999999,999999 1 # {Turns off the light source}
light 100000,20000,0 1       # {Good general light source placement. Adds a lot of depth.}
light -100000,20000,0 1      # {Another good general}
ambient 45                   # {The ambient light strength. 10 for night, 60 for bright day}
view 64 80000                # {How far out the renderer actually displays geometry}
shadedist 400000             # {How far out things start to get flat shaded without textures}
now 0 0                      # {The first number is the time of day 0-dawn, 1-day, 2-dusk, 3-night}
horizon_map 0,35,0 0 0 0     # {Second number controls height of the sky gradiation}
hidden_text "Empty"          # 
luma standard                # {"standard" or "fog" shading)

# Include the Palette file
# { The first 2 letters are the general color scheme,
# the 3 letter is color scheme version, the 4 letter is "N"
# for normal palette or "F" for fog, The file concludes
# with PAL1.WLD. NOTE: Some palette files don't support day, dawn,
# or dusk, most do. }
include yl0npal1             

# Include the Map File 
# { Map files contain the name of the texture and where
# it goes. They are named identical to Planet files except they
# conclude with MAP1.WLD. The list is the same as the Planet Files.
# I do not recommend editing map files. If you want to, just open
# one up and you'll see that it is self explanatory.}
include bas3map1 

World and area files: ????WLD1, ????ARE1

There are a couple ways to go about laying out the actual geometry in a mission. One is to take the existing geometry (the stuff in the project file) and place it about. Another is to use one of the mission layouts from one of our Mercs missions, which is the easiest because all you have to do is include the WLD1 file of that mission…

The WLD1 files are the main world description files. They don't actually declare any geometry themselves, but include the ARE? files, where all geometry is actually declared. This is primarily for organizational purposes, but can help when debugging as well… The only thing you should ever really see in a WLD1 file is a bunch of include statements. The real work is done in the ARE files, which we'll start dealing with now.

The ARE1 files are initially created by the tool grouper. Grouper takes an .ASC file that is created by 3D Studio and parses it for placement, rotation, object names, copies of objects, proper object hierarchy, object LODs, alternate objects, and chunk objects. What this all means, in an ARE1 file, using 3D Studio, we place our objects and layout the level. This can be everything from putting one measly little hill in the middle of the world to having an entire city of destroyable, multi-LODed buildings. The difference is that a hill often won't have more then one LOD (that's Level Of Detail for the acronymically impaired), because it is difficult to make LODs for terrain that don't cause many fun and annoying problems. Let's start from the top.

Geometry - What and why:

Geometry comes in many different flavors. Since our entire sim is based on the rendering of polygons, we have developed many methods of optimizing our poly counts for maximum frame rate. One of these methods is LODs, or Levels Of Detail. How this works is let's say you have a really cool looking 3-D tree, that uses about 250 polygons. However, you don't want that object to still be at 250 polygons when it's 300 meters away, because at that distance, it's no more than a dozen pixels on the screen, and to have the sim rendering all 250 polygons for 12 pixels of screen is a major waste. So, you make a few versions of your tree. Your highly detailed one at 250 polygons would be the first LOD, the next one you make would be around 150 polygons being the second LOD, and a 75 or less polygon one for third LOD. Then you set up the object so when the camera is 120 meters away, the 1st LOD object gets swapped with the 2nd LOD object, and you just saved 100 poly render cycles. Then, at 300 meters, you switch to the third, and your total poly savings becomes over 175 polys. So what? Well, that might not make a difference with one tree, but imagine a forest, and you'll see why every poly counts.

Most objects, multi-LODed or not, also need some other related objects if you want to be able to blow them up. In order for an object to be destroyed, it must have an alternate. This is the object that replaces the object that was just destroyed, like a tree stump in place of the tree… Also, if you want to see parts of your object flying off in random directions, you need to make chunks for it. And all these objects, LODs, alternate, and chunks have to placed in the same place for the illusion of them all being the same entity at different stages of existence. Now comes the glory of grouper. You may be thinking to yourself "But that would mean I'd have to have thousands of unique objects in each world. Not so. With grouper, all you have to do is have the original object, and then copy it around a bunch of times. When 3D Studio makes a copy of an object, it tacks a number on the end, like s_1treea becomes s_1treea01. What grouper does is go through and find all instances of a unique object, and links them all to the original. With that said, I think it's time to describe how the object declaration parameters work. Here we go:

object s_1treea=s_1treea 1,1,1 0,0,0 -199490,0,124119 0 none world

First we have object, which simply states that an object is being defined. Next comes a name. This name can be any name you want from billyjoebob to Q. Whatever, as long as it is unique in the mission you're using it in. After the '=' comes another name. This is the actual name of the geometry in the project file, and must match it exactly, sans extension, of course. Why we did this is so we could have several instances of the exact same object. For example, let's say I want a whole forest, not just one crummy tree. What I would do is this:

object s_1treea=s_1treea 1,1,1 0,0,0 -199490,0,124119 0 none world
object s_1treea01=s_1treea 1,1,1 0,0,0 -199490,0,124119 0 none world
object s_1treea02=s_1treea 1,1,1 0,0,0 -199490,0,124119 0 none world
.
.
.
object s_1treea9999=s_1treea 1,1,1 0,0,0 -199490,0,124119 0 none world

I think you get the idea. While we're still on the topic of names, now would be a good time to discuss the naming conventions and their significance. Since we have so many different types of objects, each with its own purpose, we had to devise a scheme that would make it obvious, just by the object's name, what its purpose was. This is what we came up with:

???<5 char name>

Where the first ? can be either a 't', 's', or 'v'. If it's a 't', then the object is terrain. If it's an 's', then the object is a structure of some sort. And, if it's a 'v', then the object is a vehicle. Vehicle geometry is not to be confused with 'Mech geometry or any other AI controlled entity. All AI controlled entities are called gamepieces (that includes user or remotely controlled entities as well). These have a whole different set of conventions and religious beliefs and we will not be discussing them. But back to the topic of name conventions. After the first ? will be either an 'a', a 'c', an 'l', an 'm', and 's', or an '_'.

If the first letter of the name is 's', meaning it is a structure (or building), the following applies:
If there is an 'a', then the object is an alternate.
If there is a 'c', then the object is a chunk.
If there is an '_', then the object is main geometry.

If the first letter of the name is 't', meaning it is terrain, the following applies:
If there is an 'l', then the object is large terrain.
If there is an 'm', then the object is medium terrain.
If there is an 's', then the object is small terrain.
If there is an '_', then the object is terrain that was not named correctly.

The third letter in the name is even harder to understand than the first two. That is because it has different meanings at different levels. At the single object level, the third letter is the LOD number. For example, LOD 1 would have a 1 there, LOD 2 would have a 2, and so on. But at the multi-object level, the one the sim sees, the third letter stands for number of LODs. A 2 LOD object (the lowest number of LODs you can have) would have an 'a' in the third position, a 3 LOD object would have a 'b' there, and so on down the alphabet.

Examples:

Let's say I have a tree with no LODs, alternates or chunks. Since you can't walk on trees, and it is not a vehicle, the first letter is 's'. Since it is main geometry, the second letter is '_'. It is automatically the first LOD, as there is nothing more detailed than it is, so the third letter is 1. The last five letters must be used. They can be any valid LETTER. The last five letters cannot contain ANY numbers. To do so will confuse grouper immensely. For this example, treea will be the last 5 letters. So, we now have the name s_1treea. What would the second LOD be called? s_2treea. Third LOD? s_3treea. The alternate? sa1treea. The first chunk? sc1treea. The second chunk? sc2treea. Get the idea? Now that you understand all of this, it's time to confuse you again.

Normally, when we create geometry, we create it in 3D Studio, then pass it through a series of programs to massage it into an ARE file useable by wasm. These tools and their documentation will be released later; for now, we'll just discribe the ARE files so you can create them manually.

ARE files are where all the actual geometry is placed and defined. Let's go over everything you'll need to know to get a regular object in and working.

Well, there is a specific order in which each component of the object must be defined in. Each component, from alternate to chunks, must be defined in a specific order. For an example, let's turn to Fred. Fred is an ARE I made with one building that has an alternate and 2 chunks. Here is that ARE file:

mangle_on
block -9000,-784,-9000 18000,10981,19500
     object sa1gurpa=sa1gurpa 1,1,1 0,0,0 0,0,0 0 none world
     collision sa1gurpa allpoly
     object s_1gurpa=s_1gurpa 1,1,1 0,0,0 0,0,0 0 none world
     collision s_1gurpa orthorect
     gamething s_1gurpa 25 sa1gurpa defend "Structure"
     object scbgurpa=scbgurpa 1,1,1 0,0,0 0,0,0 0 none sa1gurpa
     gamething scbgurpa 0 . . "none" chunky
endblock
mangle_off

The mangle_on and mangle_off lines are a WASM flag that tells WASM to make sure all the names used in this file are unique. It's a good idea to use it in geometry files only…

Now, first notice that the alternate, sa1gurpa is declared first. That is because WASM has to know the name of the alternate before you can define an object that references it. Also notice that the collision type for the alternate is allpoly. This is because most alternates have VERY low poly counts, so they cause a sim hit. They are also shaped very strangely, so allpoly is the only collision type that works well with them.

Following the alternate is the definition of the main object, s_1gurpa. You'll notice that there's only one LOD. That's because this object is a rectangular building, and you can't LOD a box. Its collision is set to orthorect because it is a rectangle. The next line is rather important. Gamething tells the sim that the object can be targeted with the 'q' key, inspected, and destroyed. After that comes the name of the gamething, in this case, s_1gurpa. The number after that is the strength of the building, or how many points of damage it can take before blowing up. Next comes the object to replace it with when it is destroyed, i.e. the object's alternate. Defend means that it can be the target of a defend goal, and the last string, which must be in quotes, is the text you see when the object is targeted.

Now we have the chunks. You'll notice that the chunks are the child of the alternate. The way our sim does it is once the alternate is swapped into being, so are its children, and then the children are cut into their sub-pieces and thrown in random directions. This gives the illusion that your building has just been blown into lots of pieces. This is not necessary, but always nice… You can see in the geometry appendix which objects have alternates and chunks. Odds are that if an alternate for an object has been made, chunks for it have been made as well. You'll also notice in the appendix that chunks have different numbers of LODs. That is because the number of chunks made for each object really depended on the complexity of the object. If you know how to place geometry in your world and make it mean something, you're almost done. All you have do now is get your layout the way you want it, and set your NAV points.

Let's go over NAV points now… The declaration looks like this:

 navpoint       0,0,25000 180 0 0 0 0 0 BEGIN;RETURN;sleep;wait ""

or

navpoint       x,y,z<heading><enable><flags><key><group_id><radius><appl_actions>"text"

The format for these is as follows:

navpoint - Declares a NAV point…

x,y,z - The point in space where the NAV is located.

Heading - What direction a 'Mech starting there is facing. 0 = North.

Enable - A boolean value that determines if the NAV is targetable. That is, if enabled, the NAV point will come up by cycling through with the 'n' key and shows up on radar. If disabled, it is not targetable and does not show up on radar. 1 = Enabled, 0 = Disabled.

Flags - Not used, set to 0.

Key - Not used, set to 0.

Group_id - The number of the group that "owns" the NAV point. For example, if this is a NAV point for en00star, then the group_id is 0; if it belongs to en01star, then the group_id is 1, and so on.

Radius - The radius at which the sim decides that a 'Mech has reached the NAV.

Appl_actions - Any actions that the NAV point could be used for in the SCN1 file. Anything you want to be able to use this NAV point for should be listed there.

"text" - What the NAV point says when targeted i.e., Nav Alpha, or Liftoff Site…
After you've gotten all this done, and your SCN1 file wasms without any errors, only warnings, then you're almost ready to make a MWM file and send it to the net. But there are a few more files you need to make. Here they are:


What predefined building-blocks are included with Mercs?

Note: This is not a complete list. More reusable things can be found by examining the demo mission sources.

Predefined Mission Names

The following is a complete list of the missions defined in the basic game. Please don't use these for your custom missions. However, if you want to use a resource (such as a planet file) defined by one of these missions, feel free. Planet file names are the first three letters of a mission name plus the number of the mission plus PLT1.WLD, e.g. BET1PLT1.WLD.
bet1 bet2 bet3 bet4 bet5 big1 buz1 dom1 dou1
dow2 gra1 gra2 gra3 gra4 gra5 iva1 iva2 iva3
iva4 iva5 lut1 lut2 lut3 lut4 lut5 lut6 mcc1
mcc2 mcc3 mcc4 mcc5 mcc6 mcc7 med1 mou1 myb1
out1 out2 out3 out4 rec1 rec2 rev1 rog1 sig1
sig2 sig3 sig4 sol1 sol2 sol3 sol4 sol5 sol6
spa1 spa2 spa3 sur1 tra1 tra2 tra3 tra4 wol1
wol2 wol3 wol4 wol5 wou1

Available Predefined Palette Files

To use one of the predefined palettes, choose one of these palette names:
br0f br0n br0t br1n fi0f gr0f gr0n gy0f gy0n 
ib0f ib0n m50n ol0f ol0n pr0f pr0n ra0f ra0n 
rb0n s10n s20n sp0n sp1n t10n t30n ta0f ta0n 
tb0f tb0n w10f yl0f yl0n
and add PAL1.WLD to the end, e.g. BR0FPAL1.WLD.

Animations

These are polygons that happen to have animated pictures playing on them. You can use them like any other object; inside an Area file, use the object statement to load one. Note: none of these were used in the missions shipped with Mercs, so there's no assurance that they actually work - but give them a try. An example of how smoke was used in another product can be found below.

Fire

fir0_0 fir0_1 fir0_2 fir0_3 fir0_4
fir1_0 fir1_1 fir1_2 fir1_3 fir1_4
fir2_0 fir2_1 fir2_2 fir2_3 fir2_4 
fir2_01 fir2_02 fir2_03 fir2_04 fir2_05

Smoke

smo0_0 smo0_1 smo0_2 smo0_3 smo0_4
smo1_0 smo1_1 smo1_2 smo1_3 smo1_4
smo2_0 smo2_1 smo2_2 smo2_3 smo2_4
smo2_01 smo2_02 smo2_03 smo2_04 smo2_05
smoke_01 smoke_02 smoke_03 smoke_04 smoke_05

Structures


Name MainAlternateChunk
Chippewa Aircraft: S_1CHIPE SA1CHIPE SCFCHIPE
Reiver Aircraft: S_1REIVR SA1REIVR SCFREIVR
Slayer Aircraft S_1SLAYR SA1SLAYR SCDSLAYR
Thrush Aircraft S_1THRSH SA1THRSH SCETHRSH
Stringray Aircraft S_1STING SA1STING SCFSTING
Shilone Aircraft S_1SHILO SA1SHILO SCFSHILO
Sholagar Aircraft S_1SHOLA SA1SHOLA SCESHOLA
Dual Rotor Rescue Helicopter S_1AHUEY SA1AHUEY SCFAHUEY

Rebel Base

Name MainAlternateChunk
One side of Gate: S_1FENCQ
Other side of Gate S_1FENCR
Barracks S_ABARIC SA1BARIC SCCBARIC
Surrounding wall S_AFENCJ SA1FENCJ SCEFENCJ
Surrounding wall S_AFENCP SA1FENCP SCFFENCP
Surrounding wall S_AFENCQ
Surrounding wall S_AFENCR
Building S_ATFBSA SAATFBSA SCFTFBSA
Building S_ATFBSD SAATFBSD SCFTFBSD
Building S_ATFBSI SAATFBSI SCFTFBSI
Building S_ATFBSJ SAATFBSJ SCFTFBSJ

Fire Base

Name MainAlternateChunk
Outer Tower S_BBASEA SAABASEA SCDBASEA
Long pipe connecting towers S_BBASEB SAABASEB SCDBASEB
Building S_BBASEE SAABASEE SCDBASEE
Building S_BBASEF SAABASEF SCFBASEF
Building S_BBASEG SAABASEG SCDBASEG
Building S_BBASEH SAABASEH SCDBASEH

Chemical Plant

Name MainAlternateChunk
Chemical Tank S_1CHEMA SA1CHEMA SCACHEMA
Pipe S_1CHEMB SA1CHEMB SCCCHEMB
Pipe S_1CHEMC SA1CHEMC
Building S_1CHEMD SA1CHEMD SCCCHEMD
Building S_1CHEME SA1CHEME SCACHEME

Draconis 'Mech Carrier

Name MainAlternateChunk
Carrier S_1CRIER SA1CRIER SCGCRIER
Shadow of Carrier S_1CRSDW

Broadsword Class Dropship

Name MainAlternateChunk
Dropship V_BDROPA VA1DROPA VCCDROPA
Windshield of Dropship V_BDRPWS VA1DRPWS
Engine Fire Polys V_AFLAMA

Union Class Dropship

Name MainAlternateChunk
Dropship V_BDROPB VA1DROPB VCCDROPB
Engine Fire Polys V_AFLAMB

Spam Class Dropship

Name MainAlternateChunk
Dropship V_BDROPC VA1DROPC VCCDROPC
Engine Fire Polys V_AFLAMC
Class Dropship V_BDROPD VA1DROPD VCCDROPD
Engine Fire Polys V_AFLAMD
Overlord Class Dropship V_BDROPE VA1DROPE VCCDROPE
Engine Fire Polys V_AFLAME

Wrecked Ship

Name MainAlternateChunk
First Half TL1WREKA
Second Half TL1WREKB

REALLY big HPG Uplink

Name MainAlternateChunk
Central Focal Area S_1FOCAL SA1FOCAL SCAFOCAL
Support Arm S_1FOCLA SA1FOCLA SCGFOCLA
Support Arm S_1FOCLB SA1FOCLB SCGFOCLB
Support Arm S_1FOCLC SA1FOCLC SCGFOCLC
Support Arm S_1FOCLD SA1FOCLD SCGFOCLD
Main Building S_1HPGHQ SCEHPGHQ SA1HPGHQ
Inner Dish T_1DSHLD
Main Dish T_1MNDSH

Windmills on New Ivaarsen

Name MainAlternateChunk
Inner Rotating Blades S_BFBLAD SA1FBLAD SCBFBLAD
Inner Rotating Blades S_BRBLAD SA1RBLAD SCBRBLAD
Main body of Windmill S_BWNDML SA1WNDML SCGWNDML
Central Power Station S_BWNDPR SA1WNDPR SCHWNDPR

Base On New Ivaarsen

Name MainAlternateChunk
Interior Building S_1BSBLD SA1BSBLD
Side of Entrance S_1BSGTA SA1BSGTA SCBBSGTA
Gas Tank Inside Base S_1BSTNK SA1BSTNK SCDBSTNK
Corner Tower S_1BSTWR SA1BSTWR SCBBSTWR
Surrounding Wall S_1BSWLA SA1BSWLA SCDBSWLA
Liquid Petroleum Tank S_BLPGTA SA1LPGTA SCELPGTA

Luthien City

Name MainAlternateChunk
Building S_1LUTBF SA1LUTBF SCALUTBF
Building S_1LUTBG SA1LUTBG SCALUTBG
Building S_1LUTBH SA1LUTBH SCALUTBH
Building S_1LUTBI SA1LUTBI SCALUTBI
Building S_1LUTBJ SA1LUTBJ SCALUTBJ
Building S_1LUTBK SA1LUTBK SCALUTBK
Building S_1LUTBL SA1LUTBL SCALUTBL
Building S_1LUTBM SA1LUTBM SCALUTBM
Building S_1LUTBN SA1LUTBN SCALUTBN
Building S_1LUTBO SA1LUTBO SCALUTBO
Building S_1LUTBP SA1LUTBP SCALUTBP
Mining Rig V_1MINRG VA1MINRG VCFMINRG

Nuclear Power Plant

Name MainAlternateChunk
Long Rectangular Building S_BNUCBA SAANUCBA SCBNUCBB
Small Square Building S_BNUCBB SAANUCBB SCFNUCBA
Cooling Tower S_BNUCTR SAANUCTR SCFNUCTR
Roadblock Spikes S_1SPIKE SA1SPIKE SCBSPIKE

City Buildings

S_1BLDAB SA1BLDAB
S_1BLDAC SA1BLDAC
S_1BLDAD SA1BLDAD
S_1BLDAE SA1BLDAE
S_1BLDAG SA1BLDAG
S_1BLDAH SA1BLDAH
S_1BLDAI SA1BLDAI
S_1BLDAJ SA1BLDAJ
S_1BLDAK SA1BLDAK
S_1BLDAM SA1BLDAM
S_1BLDAO SA1BLDAO
S_1BLDAP SA1BLDAP
S_1BLDAQ SA1BLDAQ
S_1BLDAR SA1BLDAR
S_1BLDAS SA1BLDAS
S_1BLDAU SA1BLDAU
S_1BLDAW SA1BLDAW
S_1BLDAY SA1BLDAY
S_1BLDBA SA1BLDBA
S_1BLDBB SA1BLDBB
S_1BLDBC SA1BLDBC
S_1BLDBD SA1BLDBD
S_1BLDBE SA1BLDBE
S_1BLDBK SA1BLDBK
S_1BLDBL SA1BLDBL
S_1BLDBM SA1BLDBM
S_1BLDGA SA1BLDGA
S_1BLDGB SA1BLDGB
S_1BLDGC SA1BLDGC
S_1BLDGD SA1BLDGD
S_1BLDGE SA1BLDGE
S_1BLDGF SA1BLDGF
S_1BLDGG SA1BLDGG
S_1BLDGH SA1BLDGH
S_1BLDGI SA1BLDGI
S_1BLDGJ SA1BLDGJ
S_1BLDGK SA1BLDGK
S_1BLDGM SA1BLDGM
S_1BLDGO SA1BLDGO
S_1BLDGP SA1BLDGP
S_1BLDGQ SA1BLDGQ
S_1BLDGS SA1BLDGS
S_1BLDGT SA1BLDGT
S_1BLDGU SA1BLDGU
S_1BLDGV SA1BLDGV
S_1BLDGW SA1BLDGW
S_1BLDGX SA1BLDGX
S_1BLDGY SA1BLDGY
S_1BLDGZ SA1BLDGZ

Glass windows of Airport Tower

S_BAPGLS

SA1APGLS

SCDAPGLS

Airport Hangar

S_BAPHGR

SA1APHGR

SCDAPHGR

Airport Tower

S_BAPTWR

SA1APTWR

SCDAPTWR

Terrain

Skeleton of Dead Whale

TL1WHALE
TL1_RIBA
TL1_RIBB
TL1_TAIL

Canyons Of Alshain

TM1TBLA
TM1TBLB
TM1TBLC
TM1TBLD
TM1TBLE
TM1TBLF
TM1TBLG
TM1TBLH
TM1TBLI
TM1TBLJ
TM1TBLK
TM1TBLL
TM1TBLM

Mountains

TLAMNTNA
TLAMNTNB
TLAMNTNC
TLAMNTND
TLAMTNAA
TLAMTNAB
TLAMTNAC
TLAMTNAD
TLAMTNBA
TLAMTNCA
TLAMTNDA
TLAMTNEA
TLAMTNEB
TLAMTNEC
TLAMTNED
TLAMTNFA
TLAMTNGA
TLAMTNGB
TLAMTNGC
TLAMTNGD
TLAMTNHA
TLAMTNHB
TLAMTNHC
TLAMTNHD
TLAMTNIA
TLAMTNIB
TLAMTNIC
TLAMTNID
TLAMTNJA
TLAMTNJB
TLAMTNJC
TLAMTNKA
TLAMTNLA
TLAMTNLB
TLAMTNLC
TLAMTNMA
TLAMTNMB
TLAMTNQA
TLAMTNQB
TLAMTNQC
TLAMTNQD
TLAMTNRA
TLAMTNRB
TLAMTNRC
TLAMTNRD
TLAMTNSA
TLAMTNTA
TLAMTNUA
TLAMTNVA
TLAMTNWA
TLBMNTNG
TLBMNTNJ
TLBMNTNK
TLBMTNXA
TLBMTNXB
TLBMTNXC
TLBMTNXD
TLBMTNYA
TLBMTNYB
TLBMTNYC
TLBMTNYD
TLBMTNZA
TLBMTNZB
TMAMNTNA

Crystalline Structures

TMBCSTA TA1CSTA
TMBCSTB TA1CSTB
TMBCSTC TA1CSTC
TMBCSTD TA1CSTD
TMBCSTE TA1CSTE
TMBCSTF TA1CSTF
TMBCSTG TA1CSTG
TMBCSTH TA1CSTH
TMBCSTI TA1CSTI
TMBCSTJ TA1CSTJ

Mesas

TL1MESAM
TL1MESAN
TL1MESAO
TL1MESAP
TL1MESAQ
TL1MESAR
TL1MESAS
TM1MESAT
TM1MESAU
TMBMESAB
TMBMESAE
TMBMESAF
TMBMESAG
TMBMESAT
TMBMESAU
TLBMESAA
TLBMESAC
TLBMESAD
TLBMESAH
TLBMESAI
TLBMESAJ
TLBMESAK
TLBMESAL
TLBMESAM
TLBMESAN
TLBMESAO
TLBMESAP
TLBMESAQ
TLBMESAR
TLBMESAS

Maze in Rat Maze

TS1MAZA
TS1MAZAA
TS1MAZAB
TS1MAZAC
TS1MAZAD
TS1MAZAE
TS1MAZAF
TS1MAZAG
TS1MAZAH
TS1MAZAI
TS1MAZAJ
TS1MAZAK
TS1MAZAL
TS1MAZAM
TS1MAZAN
TS1MAZAO
TS1MAZAP
TS1MAZAQ
TS1MAZB
TS1MAZC
TS1MAZD
TS1MAZE
TS1MAZF
TS1MAZG
TS1MAZH
TS1MAZI
TS1MAZJ
TS1MAZK
TS1MAZL
TS1MAZM
TS1MAZN
TS1MAZO
TS1MAZP
TS1MAZQ
TS1MAZR
TS1MAZS
TS1MAZT
TS1MAZU
TS1MAZV
TS1MAZW
TS1MAZX
TS1MAZY
TS1MAZZ

Trees

T_1TRESA
T_1TRESB

Training Valley from Alshain

T_1VALLA
T_1VALLB
T_1VALLC
T_1VALLD
T_1VALLE
T_1VALLF

Craters

(External walls of craters:)
T_ACRTRA
T_ACRTRB
T_ACRTRC
T_ACRTRD
T_ACRTRE
T_ACRTRF
T_ACRTRG
T_ACRTRH
T_ACRTRI
T_ACRTRJ
T_ACRTRK
T_ACRTRL
T_ACRTRM
T_ACRTRN
T_ACRTRO
T_ACRTRP
T_ACRTRQ

(Internal walls of craters:)
T_ACRTZA
T_ACRTZB
T_ACRTZC
T_ACRTZD
T_ACRTZE
T_ACRTZF
T_ACRTZG
T_ACRTZH
T_ACRTZI
T_ACRTZJ
T_ACRTZK
T_ACRTZL
T_ACRTZM
T_ACRTZN
T_ACRTZO
T_ACRTZP
T_ACRTZQ

Rolling Hills (High)

T_ARHIAA
T_ARHIAB
T_ARHIAC
T_ARHIAD
T_ARHIAE
T_ARHIAF
T_ARHIAG
T_ARHIAH
T_ARHIAI
T_ARHIAJ
T_ARHIAK
T_ARHIAL
T_ARHIAM
T_ARHIAN
T_ARHIAO
T_ARHIAP
T_ARHIAQ
T_ARHIAR
T_ARHIAS
T_ARHIAT
T_ARHIAU
T_ARHIAV
T_ARHIAW
T_ARHIAX
T_ARHIAY
T_ARHIAZ
T_ARHIBA
T_ARHIBB
T_ARHIBC
T_ARHIBD
T_ARHIBE
T_ARHIBF
T_ARHIBG
T_ARHIBH
T_ARHIBI
T_ARHIBJ

Rolling Hills (Low)

T_ARLLAA
T_ARLLAB
T_ARLLAC
T_ARLLAD
T_ARLLAE
T_ARLLAF
T_ARLLAG
T_ARLLAH
T_ARLLAI
T_ARLLAJ
T_ARLLAK
T_ARLLAL
T_ARLLAM
T_ARLLAN
T_ARLLAO
T_ARLLAP
T_ARLLAQ
T_ARLLAR
T_ARLLAS
T_ARLLAT
T_ARLLAU
T_ARLLAV
T_ARLLAW
T_ARLLAX
T_ARLLAY
T_ARLLAZ
T_ARLLBA
T_ARLLBB
T_ARLLBC
T_ARLLBD
T_ARLLBE
T_ARLLBF
T_ARLLBG
T_ARLLBH
T_ARLLBI
T_ARLLBJ

Dunes

T_ASDUNA
T_ASDUNB
T_ASDUNC
TLADUNA
TLADUNB
TLADUNC
TLADUND
TLADUNE
TLADUNF
TLADUNG
TLADUNH
TLADUNI
TLADUNJ
TLADUNK
TLADUNL
TLADUNM
TLADUNN
TLADUNO
TLADUNP
TLADUNQ
TLADUNR
TLADUNS
TLADUNT
TLADUNU
TLADUNV
TLADUNW
TLADUNX
TLADUNY

Example of use of animations

mangle_on
block -22506,-1022,-20940 45000,24481,45000
Affiliation 0
     object sa1nuctr=sa1nuctr 1,1,1 0,0,0 -2500,0,2100 0 . world
     collision sa1nuctr allpoly

     object s_1nuctr=s_1nuctr 1,1,1 0,0,0 -2500,0,2100 0 . world
     collision s_1nuctr cylinder
     gamething s_1nuctr 40 sa1nuctr destroy;defend "Nuclear Plant" "Core"

     object sa1nucba=sa1nucba 1,1,1 0,0,0 600,0,-700 0 . world
     collision sa1nucba allpoly

     object s_1nucba=s_1nucba 1,1,1 0,0,0 600,0,-700 0 . world
     collision s_1nucba orthorect
     gamething s_1nucba 30 sa1nucba destroy;defend "Nuclear Plant" "Heat Processor"

     object sa1nucbb=sa1nucbb 1,1,1 0,0,0 3500,0,100 0 . world
     collision sa1nucbb allpoly

     object s_1nucbb=s_1nucbb 1,1,1 0,0,0 3500,0,100 0 landmine world
     collision s_1nucbb allpoly
     gamething s_1nucbb 10 sa1nucbb destroy;defend "Nuclear Plant" "Steam Relief"

     object scfnucba=scfnucba 1,1,1 0,0,0 0,0,0 0 none sa1nucba
     gamething scfnucba 0 . . "none" chunky

     object scbnucbb=scbnucbb 1,1,1 0,0,0 0,0,0 0 none sa1nucbb
     gamething scbnucbb 0 . . "none" chunky

     object scfnuctr=scfnuctr 1,1,1 0,0,0 0,0,0 0 none sa1nuctr
     gamething scfnuctr 0 . . "none" chunky

     object sa1nucbb01=sa1nucbb 1,1,1 0,0,0 3500,0,2100 0 . world
     collision sa1nucbb01 allpoly

     object s_1nucbb01=s_1nucbb 1,1,1 0,0,0 3500,0,2100 0 landmine world
     collision s_1nucbb01 allpoly
     gamething s_1nucbb01 10 sa1nucbb01 destroy;defend "Nuclear Plant" "Steam Relief"

     object scbnucbb01=scbnucbb 1,1,1 0,0,0 0,0,0 0 none sa1nucbb01
     gamething scbnucbb01 0 . . "none" chunky

     object sa1nucbb02=sa1nucbb 1,1,1 0,0,0 3500,0,4100 0 . world
     collision sa1nucbb02 allpoly

     object s_1nucbb02=s_1nucbb 1,1,1 0,0,0 3500,0,4100 0 landmine world
     collision s_1nucbb02 allpoly
     gamething s_1nucbb02 10 sa1nucbb02 destroy;defend "Nuclear Plant" "Steam Relief"

     object scbnucbb02=scbnucbb 1,1,1 0,0,0 0,0,0 0 none sa1nucbb02
     gamething scbnucbb02 0 . . "none" chunky

     object sa1nucbb03=sa1nucbb 1,1,1 0,0,0 3500,0,-1900 0 . world
     collision sa1nucbb03 allpoly

     object s_1nucbb03=s_1nucbb 1,1,1 0,0,0 3500,0,-1900 0 landmine world
     collision s_1nucbb03 allpoly
     gamething s_1nucbb03 10 sa1nucbb03 destroy;defend "Nuclear Plant" "Steam Relief"

     object scbnucbb03=scbnucbb 1,1,1 0,0,0 0,0,0 0 none sa1nucbb03
     gamething scbnucbb03 0 . . "none" chunky

     object sa1nucbb04=sa1nucbb 1,1,1 0,0,0 3500,0,-3900 0 . world
     collision sa1nucbb04 allpoly

     object s_1nucbb04=s_1nucbb 1,1,1 0,0,0 3500,0,-3900 0 landmine world
     collision s_1nucbb04 allpoly
     gamething s_1nucbb04 10 sa1nucbb04 destroy;defend "Nuclear Plant" "Steam Relief"

     # Here's where a smoke animation was used.
     object smoke1=smo1_2 1,2,1 0,0,0 0,300,0 0 flame s_1nucbb
     object smoke2=smo1_1 1,2,1 0,0,0 0,300,0 0 flame s_1nucbb01
     object smoke3=smo1_3 1,2,1 0,0,0 0,300,0 0 flame s_1nucbb02
     object smoke4=smo1_2 1,2,1 0,0,0 0,300,0 0 flame s_1nucbb03
     object smoke5=smo1_0 1,2,1 0,0,0 0,300,0 0 flame s_1nucbb04

     object scbnucbb04=scbnucbb 1,1,1 0,0,0 0,0,0 0 none sa1nucbb04
     gamething scbnucbb04 0 . . "none" chunky

     object sa1nuctr01=sa1nuctr 1,1,1 0,270,0 -2153,0,-1938 0 . world
     collision sa1nuctr01 allpoly

     object s_1nuctr01=s_1nuctr 1,1,1 0,270,0 -2153,0,-1938 0 . world
     collision s_1nuctr01 cylinder
     gamething s_1nuctr01 40 sa1nuctr01 destroy;defend "Nuclear Plant" "Core"
task ambientsound 0 s_1nuctr;200,mecreact,1
task ambientsound 0 s_1nuctr01;200,mecreact,1

     object scfnuctr01=scfnuctr 1,1,1 0,0,0 0,0,0 0 none sa1nuctr01
     gamething scfnuctr01 0 . . "none" chunky

endblock

mangle_off


Back to Mercenaries Home Page
Back to Activision Home Page

Written by J.J. Franzen and Dan Kegel
Edited by: David J. Vonderhaar

Activision is a registered trademark of Activision, Inc. © 1996 Activision, Inc. MechWarrior, BattleTech, BattleMech, and 'Mech are registered trademarks and MechWarrior 2: Mercenaries and MercNet are trademarks of FASA CORPORATION. © 1996 FASA CORPORATION. All rights reserved. All other trademarks and trade names are the properties of their respective owners.