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.
Creating missions for MercNet requires using several cryptic tools, none of which have a GUI or are particularly "user friendly." It also requires extraordinary patience. If you aren't familliar with the DOS commandline, you probably aren't ready to use the tools.
There are currently some limitations on the kinds of missions you can build. We hope to relax these in a future version.
CD \MERCS MKDIR TOOLS XCOPY D:\TOOLS TOOLS /S
CD \MERCS\TOOLS STRIP1.BAT DEM1This will run the stripwld program, assemble an MWM file for you, and place it into your Missions subdirectory. Then test as follows:
CD \MERCS MERCNEThost a mission, select "Demo 1" from the team mission menu, click on dropship, and launch. (You need Mercs 1.06 or later to launch alone.)
CD \MERCS\TOOLS MKDIR TES1 COPY DEM1 TES1 REN TES1\DEM1*.* TES1*.*
CD \MERCS\TOOLS\TES1 EDIT TES1NAME.TXT (change "Demo 1" to "My test mission") FOR %A IN (*.*) DO FIND /I "DEM1" %A >> \LOG MORE < \LOG (list the files that need changing) EDIT TES1.WLD (change DEM1 to TES1 and save) ... (then do the same thing to the other files)
Or, if you have downloaded a copy of Perl from http://www.perl.hip.com, you can replace all instances of dem1 with TES1 with a single command:
CD \MERCS\TOOLS\TES1 perl -i.bak -p -e "s/dem1/TES1/gi" *.wld del *.wld.bak
CD \MERCS\TOOLS STRIP1.BAT TES1 CD \MERCS MERCNETand test as above.
CD \MERCS\TOOLS\TES1 EDIT TES1SCN1.WLDAdvanced mission writers can also modify the planet file and the world files. See below for walk-throughs of each file type.
CD \MERCS\TOOLS STRIP1.BAT TES1This will run the stripwld program, assemble an MWM file for you, and place it into your Missions subdirectory. If the mission works properly, you can share it with others by having them download it to their MISSIONS subdirectory.
Error running WASM -- see WASMERR.TXTyou need to check for errors (not warnings; you can ignore them) in WASMERR.TXT. Make sure you have all the files you need, and maybe edit a file to fix the error noted in WASMERR.TXT.
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.
????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.
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.
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.
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!
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.
# {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
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:
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
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 yl0nand add PAL1.WLD to the end, e.g. BR0FPAL1.WLD.
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
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
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
Carrier | S_1CRIER | SA1CRIER | SCGCRIER |
Shadow of Carrier | S_1CRSDW |
Name | Main | Alternate | Chunk |
---|---|---|---|
Dropship | V_BDROPA | VA1DROPA | VCCDROPA |
Windshield of Dropship | V_BDRPWS | VA1DRPWS | |
Engine Fire Polys | V_AFLAMA |
Name | Main | Alternate | Chunk |
---|---|---|---|
Dropship | V_BDROPB | VA1DROPB | VCCDROPB |
Engine Fire Polys | V_AFLAMB |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
First Half | TL1WREKA | ||
Second Half | TL1WREKB |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk | |
---|---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
Name | Main | Alternate | Chunk |
---|---|---|---|
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 |
S_BAPGLS
SA1APGLS
SCDAPGLS
S_BAPHGR
SA1APHGR
SCDAPHGR
SA1APTWR
SCDAPTWR
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
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.