*** How to build a single-player Myth II map with Fear and Loathing ***

Making single player Myth maps requires a fair amount of
script work.  It's not the easiest thing in the world, but
it can be fun and very absorbing.  Fear and Loathing are why
why I bought Myth II, and I applaud Bungie as a game company for
seeing the worth of relatively open-architecture games.  It's the
game within a game that I always enjoy even more than the game itself.

This tutorial is designed to be worked through from the beginning,
and is geared toward folks who may be running Fear and Loathing
for the first time, but have a reasonably high level of confidence
and can learn on their own via rooting around in the Fear and
Loathing HTML files and experimenting.

It builds on stuff created earlier, so that the end result is a
small but functional map.  The first part of this tutorial takes
one through creating a bare-bones working map, and the remainder
is dedicated to writing a very basic script for it.

You might want to make a cursory read through the tutorial before
digging into it just so you have an overall idea of what's ahead.
Heeere we go...

1. For PCs, create a 256-color .BMP file with dimensions that are a
   multiple of 256.  In the example I give here, I'm using a tiny
   512x512 image using textures that came from the Mountain Forts
   level.  Feel free to use it (example.bmp) to jump right into
   the tutorial.  For Macs, 16-color 72 dpi PICT files appear to be
   the ticket.

2. Run Loathing, select File->New Map, pick a name for the map
   and hit Save.  I used "example".  Pick a Media Type and
   hit Open.  I used "water".  Now, select the graphic file that you
   created.  If you cancel out of this dialog, you'll probably need
   to go delete the image-deprived map from your local\meshes directory
   because Loathing will be crashing whenever you try to open it.

   Open your BMP or PICT file and after a moment, Loathing should
   start you out roughly in the center of a flat landscape.  Within
   Loathing, you move around using the same keys that you use within
   Myth.

3. Let's edit some height: Choose the Height Painter (3rd button
   on the toolbar palette) and raise some cool topography.  Search
   for "Displacement Brush" in the Loathing HTML doc file for more
   information about how to use the Height Painter. You'll be using
   the F7-F12 keys a lot with this:
     F7 - Changes what the Height Painter brush does.
	 F8 - Toggles between square and round brush.
	 F9 - Decreases brush size.
	 F10 - Increases brush size (On PC also selects File. Hit ESC. grrr)
	 F11 - Decreases brush feather.
	 F12 - Increases brush feather.  Feather is the sloped area between
	       the part that gets raised or flattened and the part outside
		   the brush that stays put.  For sharp peaks, use small feather.
		   For rolling hills, use large feather.

   Change to Select Vertex (2nd button on tollbar palette) mode, select
   some vertices, and raise and lower them.  Multiple vertices may be
   selected using shift-click, or by drawing a rectangle around the
   vertices.

4. The edges of your map are currently flat, perhaps a bit like ancient
   sailors or Dan Quayle imagined the edge of the world might be.  We
   want to raise them up high to make it harder for a player to see
   over the edge of the world.  Loathing can do this for us.  Set the
   amount to raise the edges using Mesh->Edit Mesh Edge Raise Amount...
   try a value of 10 or so, and then Mesh->Raise Mesh Edges and
   Mesh->Make Mesh Edges Impassable.  This causes the very edges of the
   map to be very steep and sets them to impassable.  With a larger map,
   you can do this and also use Mesh->Set Mesh Parameters to play with
   the observer bounds.  Nonzero observer bounds values are what keeps
   the view trapezoid from being able to move close enough to the edges
   to see over them.  For an example, load up level 06 Destroy Bridge
   with Loathing and look at its observer bounds values - it keeps the
   view trapezoid well away from the edges of the map.

   ---------------------------------------------------------------
   Is Loathing crashing on you?  It was on me when working on
   brand new maps, yet it seemed fairly stable when looking at
   the Bungie maps.  My theory is that Loathing is happier with
   a map that has had more of its various tags initialized.  If
   Loathing is crashing on you, try gingerly getting through
   step 4 without getting too far off the center of the map, then
   save the map, load it into Fear, check single player map, exit
   Fear, and come back to continue with step 5.  That seemed to
   work for me.  Best of luck.
   ---------------------------------------------------------------

5. Go into Terrain Type editing mode (10th button from the left,
   between the eyeball and bottle) and note that step 4's Make Mesh
   Edges Impassable turned the edge cells bright green, corresponding
   to impassable-to-all.  Reduce the size of the brush down to about
   .75 with the F9 key, and change the terrain type to red for Steep.
   Paint some steep terrain with red to define areas where ground troops
   cannot walk but soulless can still fly over.  You don't have to paint
   the entire mountain... just cordon off some areas so your wolves
   can't go running over mountaintops to kill soulless.  The "Grass"
   terrain type is the default type, so you can paint over other terrain
   types with grass to erase them.  To put it another way, if it has
   no terrain type painted on it, it's grass.  Remember that a player
   can't see any of this - they'll be taking their cues about where
   their troops can walk or fly from the looks of the landscape, but
   in fact you've defined all that with Terrain Types.  I tried to
   make some spots on top of hills where the soulless, if chased away
   from his mountaintop, might end up at which would allow him to turn
   and start hucking spears at his pursuers.

6. Double-click the Place Scenery icon (6th button, just before the
   house icon) to bring up the Scenery Palette dialog.  Hit Add and
   choose "82 longhorn skull", and also Add "tikki torch" to the
   palette list.  Leave the Team as -1.  Close the scenery palette
   dialog, select the skull from the Scenery pulldown listbox, and
   click somewhere on the map view to add it.  Now, select it, and
   while holding the mouse button down (left button if PC), turn it
   to make it face a particular direction.  Drop a tikki torch down
   somewhere for good measure.

   After placing scenery, you can delete it by clicking on it to select
   it (a green box should appear around it) and hitting the delete key.

   If you want to add other items to the Scenery pulldown listbox
   so you can add them to the map, you just bring up the scenery
   palette dialog again and add them there.  Removing an item from
   the scenery palette dialog will also delete any instances of that
   item from the map.

   Adding models, player and enemy troops, and "observers" all work
   like this - before you can add them to the map, you first add them
   to a pulldown listbox via a palette dialog.

7. Double-click the Place Model (the "house" icon) button to bring up
   the Model Palette dialog.  Hit Add and choose "03 signpost".  For
   For now, avoid models such as 14 wallcorn; some models only work when
   butted up against other models, and they must be oriented correctly
   to avoid "hall of mirrors" effects.  Close the model palette dialog,
   select the signpost from the model pulldown listbox, and click
   somewhere on the map to add the model.
   
   To orient a model, go into Preview Mode (you can hit spacebar a few
   times to cycle to it, or select the mouse icon from the toolbar
   palette), select the model (a yellow wireframe will appear around
   it) and drag it around.
   
   Note that the model can cause heights of vertices on your map
   to change.  To delete a model that you added, go to Preview mode,
   select the model, and hit the delete key.  Now, go into Select
   Vertex mode and fix any vertices that the model screwed up.  Repeat
   this half a dozen times until the model is finally where you want
   it, or until you scream in frusteration and hurl your monitor
   across the room. Good thing you found that great deal on 12-packs
   of monitors before you started editing.

8. Double-click the Place Unit button (the thing between the House
   and Eyeball icons) to bring up the Unit Palette dialog and add
   Brigands, Wolves, Dwarves, and Soulless to the palette.  Use
   Team 0 for the brigands, wolves, and dwarves (player units)
   and Team 1 for the soulless (enemy units).  Now, on the map,
   place 4 Brigands and 4 Wolves obediently heeling at their master's
   sides, and one Dwarf behind them.  Add 1 Soulless somewhere a little
   bit in front of them all, close enough to lob a spear but far
   enough away to get a good head start if he wanted to run for it.
   We'll use these guys to test some scripting in a moment.

9. Double-click the Eyeball icon to bring up the Place Observer palette
   dialog.  Add an observer for Team 0, close the dialog, and click
   somewhere on the map to place a big eyeball where you want the
   player's viewpoint to begin.  Be sure to select it and orient it
   to the direction you want them to be looking as well.

10. We're done here for now.  File->Save Map and File->Close Map and
   exit Loathing.

11. Run Fear.  Go down to Meshes, open it, and scroll down until you
   see the map you created.  Right click on it and choose Open.  You
   should get a big dialog with lots of things to check and select on
   it.  Check Single Player Map and hit OK.  Exit Fear.

At this point, the map is playable but unscripted, which means that
you'll need to manually quit out of the level when you're tired of
moving around.  You will need to hold the shift key down when you select
New Game in order to see the new map in the list.  Myth II appears to
poll for the shift key a little slowly, so if you don't see it at first,
go back out and try again, holding Shift down a little longer.  You'll
see no map name while the "Loading" thermometer bar is displaying and
will also see an error message about overhead map preprocessing when the
level comes up - don't worry about it.  Give it a try and see what
you've got so far!


Wulp, that was fun.  If you tested what you've made so far, you
may have noticed several things that need some attention before
this can be called a full-blown single-player map:

- You saw the hall-of-mirrors effect when you got too close to the edge.
  See step 4 above for ways to eliminate this.  For now, don't
  worry about it.  When you move to a larger map, you'll have more
  room on the edges to gradually slope them up and use step 4's
  observer bounding to keep the player from seeing over the map edges.

- There was a little error message from Myth II about overhead map
  preprocessing failing, and there was no mini-map in the upper right.
  We'll take care of this in a moment by creating an overhead map
  for the level.

- The game did not end, even if everything was dead.
  We'll handle this with some basic scripting, starting with a
  "player loses" script that ends the game when the player's guys
  are all dead and ending with a "player wins" script that ends
  the game when some player troops make it to a certain spot on
  the map.

- The soulless was fairly boring, and the brigands could chase him
  down and kill him with little difficulty.  The enemy needs some AI
  scripting.  This is where things start getting interesting.  We'll
  write a script that makes the soulless guard the exit spot and
  use hit-and-run tactics against the player's troops.


-----------------------------------------------------------------------  

Here's how to create an overhead map for the level...

(This seems to work for PCs.  I'm unclear about what needs to be
done for Macs.  For now, I suggest that Mac folks skip this part.
In particular, don't check "Has Limited Terrain Visibility" in
Fear for the tutorial map, or Myth won't let you play it without
an overhead map.)

The Fear HTML document file has this to say:

Import 
    Overhead Map - This command is used to import a pict file for use
	as an overhead map in a netmap.  It imports it, names it, and
	creates a new collection tag for it.  The Windows version of Fear
	does the same, except that it imports Windows bitmap files.

Unfortunately, they leave a lot unmentioned.  You need to fire up
your favorite paint program and resample your color .BMP file (the
one you originally loaded with Loathing) to make it a size that will
work as an overhead map.  If your original color map is square or
close to square, resample it to 128x128.  If you're dealing with
a width/height size of 1536x1792, for example, resample it to 128x128
and call it close enough.  Myth II can handle niftier overhead maps,
scrolling them as the player moves, but I couldn't figure out how to
make it do that.  After spending about six hours on this, I was ready
to settle for 128x128 overhead maps and move on to scripting.  I'm
confident that others in the Myth community will bail us out here.

Once you have created your overhead map .BMP file (or you can use
"examover.bmp"), open up Fear and do a File->Import Bitmap->Overhead
Map.  Select your overhead map .BMP file and hit OK.  Fear will move it
into the local\collections directory, where it will become available in
a mesh's Overhead Map pulldown listbox.  To get there, open up
"meshes", right-click on your map, and open it.  Go to the Overhead Map
pulldown listbox and you should find the overhead map file that you
just imported (such as "examover.bmp").  You may also want to check
Has Limited Terrain Visibility if you don't want the player to be able
to see the entire mini-map when they start out.  Hit OK and exit Fear.
Your level now has an overhead map.  Run it and see!

If you run into problems with this, you can always uncheck Has Limited
Terrain Visibility, change Overhead Map to "No Tag", and live with the
preprocessor error message until we get this overhead map stuff
squared away.  Overhead maps are proving to be a bit, um, nonintuitive,
or I'm just a bit thick.

-----------------------------------------------------------------------

How to script the "player loses" scenario, with the endgame being
triggered by a player's troops all being dead...

1. DEFINE SOME PLAYER TROOPS

    At this point, the player should have 4 brigands, 4 wolves, and
    a dwarf.  We'll	create three groups of troops, and then we'll
    lump those groups together into a larger group called "Player Units".
    Fire up Loathing, open your map, and select the Map Actions button
    on the toolbar palette to open up the 3-pane script editor.  The
	PC script editor has three panes from left to right, labeled
	"Map Actions", "Parameters", and "Elements".  The Mac script
	editor has the same three panes, only they're unlabeled and
	oriented vertically, with "Map Actions" on top, "Parameters"
	in the middle, and "Elements" on the bottom.
    
    Using the script editor, add these Map Actions:

  Name: Brigands
  Type: NONE
  Expires: on trigger
    OK that, and then...
  Hit the "Add Custom..." button in the Parameter pane, and in the
    dialog that comes up, enter "subj" in the Name field and
    select "monster_identifier" for the Type field.
    OK that, and then...
  Click on the brigand troops to add them to the new "Brigands" group.
  Numbered diamonds should appear superimposed over each troop
  as you click on them.  Now go back to the Map Actions pane and Add:

  Name: Wolves
  Type: NONE
  Expires: on trigger
  Add Custom parameter: name "subj" type "monster identifier".
    Click on the doggies to add them to the new "Wolves" group.

  Name: Dwarves
  Type: NONE
  Expires: on trigger
  Add Custom parameter: name "subj" type "monster identifier".
    Click on the dorf to add him to the your "Dwarves" group.

  You can export your script from Loathing using Mesh->Export Map Actions.
  This is a good way to look at Bungie single player level scripts to
  see how they do things, and is what I did to figure out how to do
  this.  If you were to export your Map Actions at this point, you should
  get a file that looks something like this:

Brigands
{
	(subj, monster_identifier)
		10076 (brigand)
		10075 (brigand)
		10074 (brigand)
		10073 (brigand)
}

Wolves
{
	(subj, monster_identifier)
		10080 (wolf)
		10079 (wolf)
		10078 (wolf)
		10077 (wolf)
}

Dwarves
{
	(subj, monster_identifier)
		10081 (dwarf)
}

  Now let's create "Player Units", which is a collection of
  the units that we've grouped so far.

  Name: Player Units
  Type: NONE
  Expires: on trigger
  Add Custom Parameter: name "link" and type "action_identifier"
    Now, over in the elements pane, select Add.  The Edit Map Action
    Element dialog's Value listbox should now contain "Brigands",
    "Wolves", and "Dwarves" among other things, to be added.  It
    will also allow you to select things that make no sense, such as
    a recursive reference to "Player Units", so be careful to add
    only the groups of actual troops that you just created: Add Brigands,
	Wolves, and Dwarves	to the Elements pane for the Player Units
	Link parameter.

  That should cause something like the following to be added to an
  exported version of your Map Action script:
  
Player Units
{
	Link
		Brigands
		Wolves
		Dwarves
}


2. ADD AN ENDGAME CONDITION

  This condition can be triggered many different ways, but the
  Map Action itself first needs to exist.  We'll define it now:

  Name: Player Loses
  Type: Endgame Condition
  Expires: on trigger
  OK that, and you've got "ENDG.Player Loses" in the Map Action pane.
  Hit the "Add..." parameter button, and the Edit Map Action Parameter
  dialog should come up with Dark Victory Flag.  OK that, and something
  like the following should be added to the Map Action script:

Player Loses [Endgame Condition]
	deactivates_on_trigger
	0.00, 0.00
{
	Dark Victory Flag
}


3. ACTIVATE "Player Loses" WHEN ALL "Player Units" ARE DEAD

  Name: Player Units Dead?
  Type: Test Unit
  Expires: on successful execution
  Initially Active is checked.
  This gives you "TUNI.Player Units Dead?" as a Map Action.
  For parameters, Add "Unit Count Equal To" and Add an Element of 0.
  Now, we tell the "Unit Count Equal" which group of units to test:
  Add Custom parameter with name "link" and type "action identifier"
    Hit Add in the Elements pane and choose "Player Units" from the
	pulldown listbox.
  Finally, Add another parameter of type "Activates on Success" and
    Add an element, choosing "ENDG.Player Loses" from the pulldown list.
  The following should have been added to the Map Action script:

Player Units Dead? [Test Unit]
	initially_active
	deactivates_on_successful_execution
	0.00, 0.00
{
	Unit Count Equal To
		0
	Link
		Player Units
	Activates on Success
		Player Loses
}

Let's ponder this heaviness for a moment... Because "Initially Active"
is checked for the "Player Units Dead?" action, the game is going
to start testing that action right off the bat, without any other
actions needing to have triggered it.  Also, because it expires
"on successful execution", that means that as long as its action
(which is "Unit Count Equal") does not execute successfully (does
not equal whatever value was given in the element field) then the
game is going to keep testing it over and over and over and over.

This is in contrast to the "Player Loses" action, which the game
does not execute until it has been explicitly activated by some
other action.  If the "Player Loses" action had "Initially Active"
checked, the level would probably be ended before the player could
get a shot off.

An activated Action will execute over and over, or "loop", until it
"expires" or is deactivated.  This, plus the ability to either make
an Action Initally Active or to activate or deactivate it from another
Action is the basis of script execution in Myth.

Anyway, that should do it.  The map should now end when all of the
units that are members of the "Player Units" group (or whatever
group was linked to the "Unit Count Equal" test) are dead.  Go ahead
and run the level, kill off all your guys, and the level should end.

However, it just cycles right back into itself without putting up
a statistics screen.  To fix that, run Fear, open the map, and in
the Collections box, choose a Postgame screen such as "25 postgame"
or something.  Now would probably also be a good time to choose
what level to go on to in the event of Success, in the Next Mesh
box.  I recommend 04a hunting party.  OK that, exit Fear, and the
next run of the map should behave more like one would hope.

-----------------------------------------------------------------------

How to script the "player wins" scenario, with the endgame being
triggered by some of the player's troops reaching a certain location
on the map...

We'll assume that you've already defined "Player Units" in the manner
described above.

1. DEFINE ANOTHER ENDGAME CONDITION

  Name: Player Wins
  Type: Endgame Condition
  Expires: on trigger
  Hit the Add parameter button, and the Edit Map Action Parameter
  dialog should come up with Dark Victory Flag.  Open the listbox
  and select the Light Victory Flag.  OK that.
  Now, if this action is executed, there should be no way that the
  player loses.  So, we want activation of this action to disable
  the looping test for all the Player Units being dead.  To do
  that, Add another Parameter: "Deactivates on Activation", and
  then in the Elements pane, Add "*TUNI.Player Units Dead?"
  The following should have been added to the Map Action script:

Player Wins [Endgame Condition]
	deactivates_on_trigger
	0.00, 0.00
{
	Light Victory Flag
	Deactivates On Activation
		Player Units Dead?
}


2. ADD A TRIGGER FOR "Player Wins" WHEN A "Player Units" GETS SOMEWHERE

  Name: Player Unit made it?
  Type: Test Unit
  Expires: on successful execution
  Initially Active is checked.
  For Parameters, Add "Unit Count Greater Than" and an Element of 0.
  Narrow the scope of the test to just the units in Player Units with
  Add Custom parameter of name "link" and type "action identifier",
    then Add "Player Units" from the pulldown listbox in Elements pane.
  Now we define a region on the map where the game will end when a
  Player Unit walks into it...
  Add "Polygon" and click (in a clockwise direction) on the map to
    define the vertices of a box or pentagon or something convex.
  Add "Closed Polygon Flag".
  Finally, Add "Activates on Success" and for an Element, select
    ENDG.Player Wins from the pulldown listbox.

  That should add something like this to the Map Action script:

Player Unit made it? [Test Unit]
	initially_active
	deactivates_on_successful_execution
	0.00, 0.00
{
	Unit Count Greater Than
		0
	Link
		Player Units
	Polygon
		51.463, 2.204
		46.049, 2.243
		41.008, 7.547
		45.389, 10.467
	Closed Polygon Flag
	Activates on Success
		Player Wins
}

The above test for whether a Player Unit is within a defined region
is activating the Player Wins action.  Consider that it could
just as easily activate some other action, such as causing a
drawbridge to raise or bringing an attacking enemy force into play.

The "Player Unit made it?" test is initally active, so it's going to
be testing over and over and over.  If the "Player Loses" action is
activated, it should deactivate "Player Unit made it?"  At this point,
you should be able to figure out how to go back to the Player Loses
Map Action and add the Parameter and Element to do that.

Give your level a try and walk one of the members of Player Units
into the exit region.  The Team 0 units should cheer, the level should
end, and the Success statistics screen should display.

-----------------------------------------------------------------------

How to make the Soulless more interesting...

After a bit of this, multiplayer map making will feel dull and lifeless.

1. ADD A TROUBLESHOOTING AID

  In the course of developing complex Action activation dependencies,
  you may occasionally wonder why a particular action isn't getting
  activated or deactivated.  The Myth II script interpreter doesn't
  appear to come with much in the way of debugging tools, so an
  Action that you could activate that would do nothing but print
  something on the screen when it ran could be used as a lame but
  handy way of finding out whether something's working or not.
  Others will no doubt improve on this.

  Name: Great!
  Type: Sound Action
  Expires: on trigger
  Select "Sound Tag" over in the Parameters pane and Add "00 pan right"
    in the Elements pane.  That should add the following code to the
	Map Actions script:

Great! [Sound Action]
	deactivates_on_trigger
	0.00, 0.00
{
	Sound Tag
		00 pan right
}


2. MAKE THE SOULLESS MOVE SOMEWHERE (and say "Great!" when he arrives)

  When the game starts, let's have the Soulless start moving from
  his starting position over to some position where he can better
  guard the exit.  For a good effect, have the Soulless start out
  fairly close to the Player Units at the beginning of the map,
  and have the place where he runs to be high enough so that
  the brigands and wolves can't reach him.

  Name: Soulless Guards
  Type: Movement
  Expires: on successful execution
  Initially Active is checked.
  Add Parameter type Monsters and click on the Soulless.
  Add Parameter type Waypoints and click where you want him to go.
  Add Parameter type Final Facing and then click and drag the arrow
    in the direction you want him to turn and face once he's there.
  Add Parameter type Activate on Success with Element "Great!"

  If the map is played, the Soulless should now take off, even
  he was standing right in front of the Brigands, and head for
  his waypoint.  When he reaches it, he should turn around to the
  facing angle and you should hear and see "Great!".

  Here's what I got when I exported my Map Actions:

Soulless Guards [Movement]
	initially_active
	deactivates_on_successful_execution
	0.00, 0.00
{
	Monsters
		10009 (soulless)
	Waypoints
		43.022, 17.836
	Final Facing
		135.70
	Activates on Success
		Great!
}


3. ADD AN ACTION FOR THE SOULLESS ATTACKING THE PLAYER TROOPS

  Name: Attack Player
  Type: Attack
  Expires: on trigger
  Add Parameter "Attackers" and click on the Soulless.
  Add Parameter "Attack All Enemies" flag.

Attack Player [Attack]
	deactivates_on_trigger
	0.00, 0.00
{
	Attackers
		10009 (soulless)
	Attack All Enemies Flag
}


4. ATTACK THE PLAYER IF THEY DIDN'T FOLLOW THE SOULLESS

  Name: Consider Attacking
  Type: Test Unit
  Expires: on failed execution
  Add Parameter "Enemy Closer Than Radius" with Elements value of 14.
  Add Custom Parameter with name "subj" and type "monster_identifier"
    and click on the Soulless.
  Add Parameter "Activates on Failure" and Elements "Attack Player".
  This will cause the Soulless to perch on his waypoint if the
    player is within 14 units away, or leave his waypoint to attack
    the player if the player is farther than that.

Consider Attacking [Test Unit]
	flag
	0.00, 0.00
{
	Enemy Closer Than Radius
		14.001
	(subj, monster_identifier)
		10009 (soulless)
	Activates on Failure
		Attack Player
}

5. TEACH THE SOULLESS WHEN TO RUN FROM BRIGANDS, WOLVES, AND DWARVES

  The soulless can risk getting closer to brigands and wolves than
  he can to dwarves.  We'll create two different actions that the
  soulless will use to decide when he's dangerously close to player
  troops.

  Name: Retreat From Ground Troops?
  Type: Test Unit
  Expires: on successful execution
  Add Custom Parameter name "subj", type "monster_identifier", and
    click on the soulless.
  Add Parameter "Enemy Closer Than Radius" with element of 6.
  Add Parameter "Enemy List", and click on all of the player's brigands
    and wolves.  We'll leave the dwarf off this list.
  Add Parameter "Activates On Success" with element of "Soulless Guards".

  Add another Map Action:

  Name: Retreat From Dwarf?
  Type: Test Unit
  Expires: on successful execution
  Add Custom Parameter name "subj", type "monster_identifier", and
    click on the soulless.
  Add Parameter "Enemy Closer Than Radius" with element of 12.
  Add Parameter "Enemy List", and click on the player's dwarf.
  Add Parameter "Activates On Success" with element of "Soulless Guards".


6. ACTIVATE THE RETREAT TESTS AND TIE THEM ALL TOGETHER

  When we added the actions Soulless Guards and Consider Attacking
  earlier, the Retreat actions didn't exist yet, so we didn't
  add activation parameters for them.  The actions that drive the
  soulless are intended to be run as different states.  While
  Soulless Guards is active, the soulless is running back to his
  waypoint.  After he's done that, he transits to a state where
  he's Considering Attacking.  If he decides to attack, Attack Player
  is activated along with constantly thinking about whether to
  Retreat or not.  If either Retreat action decides that retreating
  would be wise, then we're back to the Soulless Guards state.
  Here's a flow diagram of the states that our soulless will run
  through.  We just need to add a few more activation and deactivation
  parameters to hook them up this way:

                   Great!                Attack Player
Soulless Guards -> Consider Attacking -> Retreat From Ground Troops? \_
                                         Retreat From Dwarf?         / |
      ^                                                                |
      |________________________________________________________________|

  A. Select Soulless Guards and add Consider Attacking to the
     actions that it activates on success.  Hit Add... in the
     Elements pane, since Activates on Success can take more than
	 one action to activate.
  B. Select Consider Attacking and add Retreat From Ground Troops?
     and Retreat From Dwarf? to the actions it activates on failure.
	 Consider Attacking now activates three different actions when
	 its test returns "false".
  C. Select Retreat From Ground Troops? and add parameter
     Deactivates On Success with element of Retreat From Dwarf?
  D. Select Retreat From Dwarf? and add parameter Deactivates On
     Success with element of Retreat From Ground Troops?
	 The reason for C and D is that a decision to retreat from either
	 ground troops or the dwarf commits the soulless to going back
	 to the waypoint, so it's pointless to have Myth checking to see
	 if it should recommit to this due to getting too close to the
	 other type of player units.

This guy should now be a smarter-than-average Soulless, but of
course there's always room for improvement.  Another thing that
could be added would be to make him smart enough to know when he's
retreated far enough to be able to turn and lob a few more spears
without having to go all the way back to his guard waypoint.
Exercise left to reader.  :)

-----------------------------------------------------------------------

An obscure note:  Loathing exports Map Action files as ASCII
with the carriage return/linefeed characters reversed.  That
is, instead of ending lines with CRLF, they end them with LFCR.
Repair your files as needed, if needed.  If you don't understand
this, don't worry about it.

Another note on the Tools Docs files.  The Fear HTML file worked
alright for me off the CD-ROM, but the Loathing HTML file's
graphics links were all broken.  To fix it, I moved the
"Tools Docs" directory (TOOLSD~9 for those of you who work like
I do) onto my hard drive and replaced all occurrences of
"../Game%20Apps/Myth%20II%20C4/Tools%20Docs/gfx" with "gfx".
It's worth taking the trouble to make these files work nicely,
since you'll be referencing them often at first.

Some attack actions use Link, taking a "subj" as an attacker
and an "action identifier" as the targets.  For these, the
scripts seem to want a group of Player Units defined as an
object, which can be referenced as an "action identifier",
I guess.  I'm a little unclear on the semantics of all this,
but it appeared to work fine once I got through it all.  Many
Bungie factory scripts have some code that looks something
like this at the beginning of them:

Create Player Units Object [Geometry Filter]
	initially_active
	deactivates_on_execution
	0.00, 0.00
{
	Entire Map
	Tested items Inside Field Name
		obje
	Results Action Identifier
		Player Units as Object
	Link
		Player Units
}

Player Units as Object
{
}

so they are then able to use the Link parameter in an Attack action
with two elements: a group of monsters defined in a similar manner
to how we grouped the player troops, and an "action identifier"
of "Player Units as Object", or whatever the name of some of the
player's units are.  You could use them like this:

Soulless Group 1 Attacks [Attack]
	deactivates_never
	0.00, 0.00
{
	Link
		Soulless Group 1
		Player Units as Object
	Attack Nearest Flag
}

-----------------------------------------------------------------------

Here are the files included with this tutorial and their locations.
"myth2" is assumed to be the name of the directory where your Myth II
executable is installed.

myth2\howtosin.txt                   - this file
myth2\example.txt                    - this tutorial's exported map actions
myth2\example.bmp                    - a 512x512 color landscape image
myth2\examover.bmp                   - Resampled to 128x128 for overhead map
myth2\local\meshes\example           - Myth II's map data 
myth2\local\collections\example      - Myth II's map data
myth2\local\collections\examover.bmp - Overhead map created by Fear

If you unzip this file, with directories, to your Myth II main
directory, you should get a playable demo of the level that I
created as I went through my own tutorial.  To uninstall this
tutorial, just find and delete the above 7 files.

Thar ya have it.  Hopefully this thing will be useful to folks
and help give a few people a start on making some spifty single
player maps - so I can play them!  :)  Maybe someone will be
able to come up with a single player version of Body Count where
the enemy AI is smart enough to retreat and group into a hardcore
defense once they get lead...

- gyro@cryogenius.com  1/24/99


*** Ver. 1.01  1/26/99
Incorporated Alvin's comments, tried to make tutorial more universal
across PC/Mac platforms, added local\collec~1\examover.bmp (it's
absence prevented Myth II from running the pre-built tutorial level
unless "Has Limited Terrain Visibility" was unchecked with Fear),
used WinZIP to build the tutorial .ZIP file so that "collections"
will be created rather than "collec~1" if it doesn't already exist
(by the horns on Bill Gates' head, I swear that people that use long
filenames will ultimately wind up with their souls imprisoned in
road turtles on a Seattle freeway for all eternity, and the tires of
my hog shall slap over their wispy selves whenever I change lanes)