========================== 
Red Alert Mission Compiler  (v 1.1)      (C)opyright David Louisson 1997
========================== 

Existing users: see the section - 'What's New in Version 1.1'


Contents
--------
Introduction
A Word on Mission Creation, RAMC, and other Editors
Acknowledgements
Functional Overview
What's New in Version 1.1
Files Shipped
Breakdown of the .INI file
Mission Creation Cycle Steps
   Hints for Windows 95 Users
   Running Instructions
Debugging, Feedback and Support
Elements and Fundamentals of the RAMC Language
RAMC Language Reference
   Zone 1
   Zone 2
   Trigger Attachments and 'Null' Triggers
   Cell Referencing
   Cell References - entries in Zones 4-7
   The CELL Keyword
   Defining ITEMs
   Defining TEAMs
      TEAM keyword
      MEM (team members) keyword
      ACT (team actions) keyword
         Zones 3-4 - valid commands and parameters for Team actions
   Defining TRIGGERs
      TRIGGER keyword
      IF / AND / OR  keywords (Trigger Event definition)
         Zones 3-4 - valid events and parameters
      THEN keyword (Trigger Action definition)
         Zones 3-4 - valid actions and parameters
   Globals
Customizing TEMPLATE.DEF and RAMC.REF
Importing unit/structure definitions created by other tools

Appendices
   1. Customizing the RAMC Language
   2. Error Messages
   3. RAMC Language Quick Reference
   4. About the Author


Introduction
------------
Thanks for taking the time to test drive my Red Alert Mission Compiler
(RAMC). I hope that you find it useful. The program is released as
freeware, so that it can be used and distributed without charge, and is
supplied on an 'as is' basis. As a result, I make no guarantees of
continued support in the future, nor accept any liability for any damage
caused by running the program, correctly or otherwise. You agree to use it
at your own risk.

RAMC is written using an old version of Microsoft QuickBASIC, so there
is no GUI to speak of, but this makes for a small, portable .EXE file,
and ensures compatibility and fast runtime on virtually all IBM PC clones.
In any case, the emphasis is on functionality rather than presentation.

RAMC requires approx 0.7 MB of free disk space for its own use, as it
creates temporary files during the course of its execution.


A Word on Mission Creation, RAMC, and other Editors
---------------------------------------------------
RAMC is a professional tool for the serious mission creator. If you're
looking for a graphical editor that lets you 'point-and-click' objects
onto the play map, then RAMC is probably not for you (although it does
automate the calculation of cell locations to a high degree). Also,   
version 1.1 now allows importing map placements defined by other tools.

But building missions consists of much more than this!  Complex strings
for triggers, team types and so forth, must be created, and then expanded
and co-ordinated as the 'plot' of your mission takes shape. To build a
mission that is both fun and playable, there are many parameters that
must be finely balanced, and that balance can only be achieved through
repeated play-testing, and continuous refinement. The mission must be
neither too easy nor too difficult, the player's opportunity to develop
his base must be carefully synchronized with the computer's attacks, and
so on. Too few items on the play area makes for a simplistic mission, too
many and the game slows to a crawl.

Once you have created your map using Westwood Studios' Terrain Editor,
RAMC lets you create ALL of the other mission definitions in plain
English. No Windows API, runtime or graphics libraries are needed.
Complete, full-featured missions can be built to the same extent as
'manual' .INI editing, but without the hassle of defining waypoints,
cell triggers, trigger and team type strings.

Assuming that you understand the basics of creating RA missions, then the
RAMC language, and all of its associated concepts, should be learnt easily
enough. If you have previously created your missions 'the hard way', then
you will (I hope) be impressed not only by the ease of the learning curve,
but also the completeness and high level of automation that RAMC offers.

The ability to make rapid, wholesale changes to sections of your mission
parameters (as brilliant new ideas suddenly grab you), and then toggle
quickly between mission definition and play-testing modes, is probably
the single most important factor in rapid, successful mission building.
RAMC has been designed with these criteria uppermost in mind.

Ed Morrow's superb RASPMCT.DOC ('Step-by-Step RA Single Player Mission
Creation Tutorial') gives an in-depth outline of many of the points
discussed above.


Acknowledgements
----------------
Most Red Alert gamers are aware of Andrew Griffin and Charles Francis
Harkins' excellent RA Single Player Mission Creation Guide (RASPMCG),
which can be downloaded from many RA web sites. This Guide is a 'must
read' for anybody serious about creating missions, and is referred to
here, by using curly braces. For example, {2-1} means 'for more
information on this topic, refer to section 2-1 of RASPMCG (ver 1.1)'

Trademarks and copyrights of Westwood Studios, Microsoft, and any other
manufacturers or contributors, are similarly acknowledged.


Functional Overview
-------------------
RAMC's aim is to automate the normally painstaking task of turning your
ideas into playable missions, as quickly and seamlessly as is possible.
It will automatically build a single player mission file (e.g. SCG01EA.INI)
from a map (.MPR) file and a user-definition (.DEF) file of the same root
name. A .XRF file is also output, displaying a map of target definitions
vs user symbols.

     Inputs                                      Outputs
   ------------                                --------------
   |  Map     |                                | Cross-ref  |
   |  file    |            ============        | map file   |
   |  (.MPR)  |  ------->  |          | ---->  |  (.XRF)    |
   ------------            | Compiler |        --------------
                           |   RAMC   |
   ------------            |   .EXE   |        --------------
   | User def |  ------->  |          | ---->  | Executable |
   | file     |  <-------  |          |        | mission    | ----> Red
   |  (.DEF)  |    error   ============        |  (.INI)    |       Alert
   ------------    report        ^             --------------
                                 |                 
  ----------------               |                 
  | Customizable |               |                 
  | parameters   |  -------------/
  |  RAMC.LIB    |
  ---------------- 

Apart from the RA Terrain Editor, RAMC is ALL you need to create complete,
full-featured missions. Structures, triggers, team types and all of the
other RA mission elements are defined in the .DEF file using simple English
text (the 'RAMC language'). This language can be customized to virtually
any degree, as all the component element names and symbols are stored in
the RAMC.LIB file, which can be modified using your favourite text editor.
For more information, see Appendix 1, and read the comments in RAMC.LIB.

RAMC's runtime is lightning fast. Compile times for complex missions
(e.g. 20 team types, 60 triggers) complete in less than half a second on
my Pentium-166 (32 MB RAM).

As part of the compilation process, RAMC performs a full syntax check of
your language definitions, and reports errors back to the .DEF file. You
simply type in any necessary correction(s), and re-compile. The .INI file
is built only when an error-free compile takes place. Once this file has
been built, the mission is immediately playable.

The files SCG01EA.INI, SCG01EA.DEF, SCG01EA.MPR and SCG01EA.ANN are
supplied with RAMC. SCG01EA.DEF is a fully working mission (it's the first
Allied mission from the original RA), and gives a good illustration of the
RAMC language.

As a 'Getting Started' tutorial, try making simple changes to SCG01EA.DEF,
compile them as described in the 'Mission Cycle Creation Steps' section,
and then play-test the result!

Also supplied are the text files:

   TEMPLATE.DEF  - which contains the basic 'code skeleton' to which
                   your RAMC definitions are added

   RAMC.REF      - a reference help library from which you can copy and
                   paste RAMC statements into your .DEF file

Both these files can also be customized to suit your personal needs. By
adding your own 'frequently-used code' to these, you can greatly enhance
your productivity.


What's New in Version 1.1
-------------------------
Version 1.1 includes the following features:

  *  Allows importing of structure/unit defintions created using other
     map editors, or from other .INI missions. See the later section
     'Importing unit/structure definitions created by other tools'.

  *  The format of RAMC.REF has been enhanced.

  *  The SCG01EA.MPR file has been included, so that you can experiment
     by making changes to, and then compiling SCG01EA.DEF. 

  *  Enhancements to the 'Hints for Windows 95 users', and other sections
     of this document. Also corrected some minor errors in the text.


Files shipped
-------------
READ_ME.TXT   - the document that you're currently reading
RAMC.EXE      - executable compiler program
RAMC.LIB      - modifiable parameter resource library
RAMC.REF      - RAMC help reference
LAST.DAT      - stores your default entries from the last run
TEMPLATE.DEF  - RAMC language skeleton 
SCG01EA.DEF   - sample illustration of the RAMC language
SCG01EA.MPR   - map used in conjunction with SCG01EA.DEF
SCG01EA.INI   - mission file, compiled from SCG01EA.DEF/.MPR
SCG01EA.ANN   - annotation of SCG01EA.INI, created by RAMA
PREVIEW.TXT   - RAMC product preview


Breakdown of the .INI file
--------------------------
This section describes how RAMC generates the mission (.INI) file from
its component elements.

The following sections are copied in, unaltered, from the .MPR file: 
[Map], [MapPack], [TERRAIN], [OverlayPack]
All other sections, like [Waypoints] and [Digest], are discarded.

The following sections are copied in, unaltered, from the .DEF file:
1. Any RULES.INI overrides (e.g. [General], [AI], [1TNK], [FACT], [SCUD],
[HeatSeeker], [HE], [Powerups] etc).
2. The [Basic] section.
3. Any country related sections ([Greece], [USSR], etc).
4. The [Briefing] section, if it exists.

The following sections are created by converting definitions in the
[RAMC] section at the foot of the .DEF file:
[TeamTypes], [Trigs], [UNITS], [SHIPS], [INFANTRY], [STRUCTURES]

The following sections are created automatically (i.e. with no additional
user entry required):
[Waypoints], [CellTriggers], [Base]


Mission Creation Cycle Steps
----------------------------
1. Use Westwood's Terrain Editor to build your mission map. Or, if you
want to get started more quickly, use any of the third party developed
maps available on RA web sites. Also included here are SCG01EA.DEF and
SCG01EA.MPR, which you can experiment with, for tutorial purposes.

To create a map that is not a standard size (64x64, 96x96 etc) you will
have to manually edit the [Map] section of the .MPR file. Placing flags
or trees to calculate cell positions {2-2} is unnecessary. Assuming that
you want to play-test your mission as you build it, rename the map file to
SCG01EA.MPR (for an Allied mission) or SCU01EA.MPR (for a Soviet mission).

2. Copy the file TEMPLATE.DEF to either SCG01EA.DEF or SCU01EA.DEF.

3. Modify the SCx01EA.DEF file using a text editor. Entries in the
RULES.INI overrides, [Basic], country-related and/or [Briefing] sections
must be made manually. (Given that TEMPLATE.DEF contains many of these,
and that your editor permits you to copy text directly from RULES.INI,
this is a simple enough task.) All other entries are made in the [RAMC]
section, using the RAMC language. Keep the template ruler and language
reference lines below you as you type - or copy and paste these lines
throughout the file, as needed. (Note: any lines beginning with a
semi-colon (;) are treated as 'comments' by the compiler.) Have the
RAMC.REF help reference file loaded, so that you can copy skeleton
text directly into the .DEF file.

4. When you are ready to play-test your mission, save your file and run
RAMC as described in the 'Running Instructions' section below. If RAMC
reports syntax errors, re-edit the .DEF file. Perform a text search for
each error (marked by ????), and type in the necessary correction at that
point. Error messages are explained in detail in Appendix 2. It is not
necessary to delete the error messages themselves out of the file, as
RAMC will do this for you on your next compile.

5. When you achieve an error-free compile, the mission (.INI) file is
built, ready for play-testing. Run Red Alert, select 'Start New Game',
any difficulty level, and 'Allies' or 'Soviet' as appropriate. When you
are finished, choose 'Options' then 'Abort Mission' to exit in the normal
manner. Return to step 3 to make any additions or changes that you wish.

Hints for Windows 95 users
--------------------------
I have two sessions, running Red Alert, and MS-DOS prompt, simultaneously.
In the latter, I have a batch file (R.BAT) which calls DOS's EDIT.COM, and
automatically loads 8 different files for editing, thus:

edit  sc%101ea.def  ramc.ref  ramc.lib  read_me.txt  racg110.txt
         sc%101ea.ini  sc%101ea.xrf sc%101ea.ann

After invoking this ('r g' for Allied mission, 'r u' for Soviet), I can
then toggle (Alt-1, Alt-2, etc) between these 8 windows, to copy and
paste definitions from RAMC.REF, customize RAMC.LIB, refer to RASPMCG or
this document, view the .INI, .XRF and .ANN files, etc.

I also have DOSKEY running to automate the typing of 'r u', 'ramc', 'rama'
and so forth. As soon as the mission has compiled, I can Ctrl-Tab
across to the Red Alert session, for immediate play-testing. With
multiple sessions, there is no need to endure the long wait while Red
Alert loads (apart from the first time). Restarting the mission using
'Options -> Abort -> Restart' bypasses the need to view any movies
during repeated play-testing.

This approach allows 'incremental' mission building. You can refine
your definition, and then compile and play-test the refinement, with
virtually no wait time between each step.

The above is designed merely to stimulate ideas; there are no hard and
fast rules to this process. By all means experiment and devise a system
that works best for you.

Running Instructions
--------------------
RAMC expects to find the files LAST.DAT and RAMC.LIB in the directory
(folder) from which it is being run. If RAMC.LIB is missing, the 
compiler will not run.

If the TUTORIAL.INI file resides in the same directory as the .DEF and
.MPR files, then it is possible for RAMC to automatically update the
trigger text in this file for you (explained later).

To run the program, type   RAMC [Enter]

You will be asked to input two parameters:

1. Path (folder) where the .DEF and .MPR files reside.

2. Name of the file to be compiled. Do not enter an extension. Note that
   the .DEF, .MPR, .INI and .XRF files all share this same root name.

In each case, simply pressing [Enter] accepts the default value
(highlighted in reverse image). These defaults are your entries from the
previous run, and are saved in LAST.DAT from one run to the next.
So, if you are repeatedly re-compiling the same mission, the only key
you'll need to use is [Enter]

To exit the program at any time, press Ctrl-Break. If you're running from
the DOS prompt, pressing F3 then [Enter] will re-start from the beginning.


Debugging, Feedback and Support
-------------------------------
Queries, suggestions and bug reports are all welcome.

However, please note that there are two types of bugs. If RAMC is
generating incorrect text into the .INI file, then please advise me   
urgently. If, however, Red Alert is not following your mission
instructions, or is otherwise behaving strangely, then the fault can
only be remedied by the manufacturers of Red Alert.

If you get stuck debugging your missions, you could try the following:

1. If you are getting compile errors that you do not understand, please
   read Appendix 2 at the end of this document.

2. Try running the Mission Annotater program (RAMA) across your mission
   file. Whereas RAMC only looks for syntax errors in the .DEF file,
   RAMA is able to highlight a wide range of logic-type errors. The
   .XRF file generated by RAMC is useful for mapping Trigger, TeamType
   and Global switch names used in the .ANN file back to their .DEF
   equivalents.

3. If you are experiencing difficulty with cell placements, the .XRF
   file includes an outline of cell name relationships and formulae.

4. If Red Alert appears to be behaving incorrectly, refer to the relevant
   section in RASPMCG. There is plenty of information here regarding
   Triggers and TeamTypes that don't work as was probably intended, and
   other anomalies. There are also other informative mission creation
   guides available on several RA web sites.

Finally, if you are convinced that RAMC is not generating the .INI file
correctly, please feel welcome to E-mail me a bug report. Be sure to
include copies of your .DEF and .MPR files (and RAMC.LIB, if you have
modified it), along with a FULL description of the problem, so that
I can attempt to reproduce it here. I will endeavour to respond as
time permits. Submissions will be investigated on a first-come,
first-serve basis.

Send any E-mail to:  dave@bsnz.co.nz


Elements and Fundamentals of the RAMC Language
----------------------------------------------
All trigger, teamtype, structure, unit (etc) definitions are entered
under the [RAMC] section of the .DEF file, using the RAMC language.
Note that the [RAMC] section must be the FINAL section in the file.

You type your definitions into the 11 ZONES on each statement line.
The TEMPLATE.DOC file includes a ruler line illustrating where each
zone starts and ends, thus:

;.......2........3............4.........5.........6...7...8...9...0.1.........
xxxxxxxx         xxxxxxxxxxxxx          xxxxxxxxxx                xx      
|                |                      |                         |      
Zone 1           Zone 3                 Zone 5                    Zone 10

Note that the ruler line begins with a semi-colon (;)
Any characters to the right of the first semi-colon on any line are
ignored by RAMC. In this way, you can enter comments to make your
definitions more readable, thus:

;  this entire line is a comment

<RAMC definition>    ; everything from this point is a comment

Editing Hints:

1. Do all your typing just above the ruler line, to ensure that your
   entries are made in the correct zones. As you press [Enter] at the
   end of each line of 'code', the ruler drops down to accommodate
   the typing of your next line.

2. Copy the ruler line to separate logical sections in your code. This
   not only enhances the readability, but also ensures that a ruler is
   always handy when making changes to a previously entered section.

3. Use an editor that allows you to use Ctrl-RightArrow and Ctrl-LeftArrow
   to move quickly to the start of each zone on the ruler line.
   Most editors allow this - including even DOS's EDIT !

4. To avoid repetitive typing, use the Copy/Paste facilities in your
   editor frequently. Modifying copied trigger or team definitions
   (instead of typing them 'from scratch') can save a lot of work.             

5. Use your editor's text search facilities to locate items, trigger
   names, etc quickly. Use global search/replace to change names,
   items, countries throughout the entire [RAMC] section, if necessary.

6. To temporarily disable statements, 'comment' them out by inserting a  ;
   at the left of the line. Later, you can easily reinstate them by
   removing the  ;   This is very useful for play-testing separate parts
   of your mission. To cut out a large area quickly, you can type // in
   the first 2 character positions of a line to start a comment 'block',
   and \\ to end the block. All text inside the block, including both
   lines containing the slashes, will be ignored by RAMC, just as if
   each line began with a semi-colon. Example:

//   everything 
     in this area
\\   is a comment


The RAMC language is case INSENSITIVE. That means that you can make all
your entries in any mixture of capitals, or lowercase. For example, you
could name a trigger as KillUSSR and later refer to it as killussr or
even KILLUSSR - they are all equivalent. This applies to every aspect
of the language - keywords; structure, event and action types; names
you might give to triggers, teams, cells and globals - EVERYTHING.

You can make entries anywhere within a zone, as long as the entry fits
entirely within the zone. This also applies without exception, and
allows you improve readability by indenting your code. For example, the
following statements are both equivalent:

;.......2........3............4.........5.........6...7...8...9...0.1.........
Greece    ITEM   ConstYard    cy        rf1       +10 -5            R
  GREECEItem       coNstYaRd         CY     rf1    +10-5                r     

Here's a good example of using indenting within zone 2 to keep the MEMbers
and ACTions appearing neatly within a team:

;.......2........3............4.........5.........6...7...8...9...0.1.........
USSR      TEAM   -TANKS1-                                           RE
            MEM  HeavyTank    3
                 Mammoth      2
            ACT  Move                   cy1
                 Guard        0.5
                 Move                   ^         +4  -11
                 Guard        2
                 Attack       Any

A minor point, I agree, but it depends what price you place on clarity.

Before we discuss in detail the contents of each zone, a brief word on
customization. You can modify almost EVERY aspect of the RAMC language
to suit your own preferences. The elements of the language are kept in
the RAMC.LIB file, which you can change with a text editor. For example,
if you feel that HeavyTank requires too much typing, you might want to
abbreviate it to HTank, or even just HT - it's entirely up to you as to
how you balance readability against number of keystrokes. Appendix 1
deals with the customization process in greater detail.

RAMC also allows you to provide names - 10 characters maximum - for
teamtypes, triggers, cells, and global switches. These names, or
identifiers, may use any characters from the keyboard, except:
1. Obviously semi-colons are prohibited.
2. The identifier may not begin with a digit (0 thru 9).
Embedded spaces are permissible.

Rules for numeric entries:
Positive numbers may optionally be entered with a leading plus (+) sign.
Negative numbers MUST be entered with a LEADING minus (-) sign.
A decimal point is permitted; commas (to separate thousands) are not.
Finally, the number zero should always be entered simply as  0


The following 'Quick Reference' chart illustrates all of the permissible
statements in the RAMC language, and how each element fits into the
relevant zones. All constructs in the language follow one of the displayed
patterns - they are all that's needed to build complete, full-featured
missions.

;.......2........3............4.........5.........6...7...8...9...0.1.........
country TRIGGER  trigname     R
country   IF     event        param     cellpos   +ns +we
country   THEN   action       param     cellpos   +ns +we param2
country   TEAM   teamname     cellname  cellpos   +ns +we pr  mi    RSADE
            MEM  unittype     num
            ACT  command      param     cellpos   +ns +we
country   ITEM   structtype   cellname  cellpos   +ns +we hc% dir   R+
country   ITEM   unittype     cellname  cellpos   +ns +we hc% dir s command
          CELL   wp           cellname  cellpos   +ns +we hhh www

A version of this chart is included in TEMPLATE.DEF for you to copy and
paste as often as you need. 


RAMC LANGUAGE REFERENCE
=======================
Note: the following section is really only intended as a reference.
The fastest way to learn the RAMC language is to study the sample
SCG01EA.DEF file shipped with the software, and then refer to the
relevant sections below when aspects require clarification.

ZONE 1
------
;.......2........3............4.........5.........6...7...8...9...0.1.........
xxxxxxxx

Zone 1 always contains the country name. The valid country names are:

Spain    Greece   USSR     England  Germany   France   Ukraine   Turkey
GoodGuy  BadGuy   Neutral  Special  Multi1    Multi2   Multi3    Multi4
Multi5   Multi6   Multi7   Multi8

although, of course, you can customize these if you wish.

If you leave Zone 1 blank, then the country defaults to the last non-blank
entry (the 'current' country). Alternatively, you may use the caret (^)
as a ditto symbol. In each of the following situations, all the structures
are owned by Greece:

;.......2........3............4.........5.........6...7...8...9...0.1.........
Greece    ITEM   ConstYard              c1
                 Power                  c2
                 Refinery               c3
                 Silo                   c4
;.......2........3............4.........5.........6...7...8...9...0.1.........
Greece    ITEM   ConstYard              c1
^                Power                  c2
^                Refinery               c3
^                Silo                   c4
;.......2........3............4.........5.........6...7...8...9...0.1.........
Greece    ITEM   ConstYard              c1
Greece           Power                  c2
Greece           Refinery               c3
Greece           Silo                   c4

Whichever system you use is entirely your choice. My preference is for
the first - there is less typing involved, and, for the sake of clarity,
I think that in this case 'less is best'.


ZONE 2
======
;.......2........3............4.........5.........6...7...8...9...0.1.........
        xxxxxxxxx

Zone 2 always contains a RAMC KEYWORD. The full list of valid keywords is:

TRIGGER - begins the definition of a trigger.
IF      - defines a trigger event.
AND     - defines a second trigger event.
OR      - defines a second trigger event.
THEN    - defines a trigger action.

TEAM    - begins the definition of a teamtype.
MEM     - defines a member of a team.
ACT     - defines an action that a team will follow.

ITEM    - defines a structure, unit, infantryman or ship. (RAMC picks
          up which type from the Zone 3 entry, e.g. RadarDome, HeavyTank
          Rifleman, Cruiser). Note: throughout the remainder of this
          document, the word 'item' is used to mean any one of these
          four ITEM types.

CELL    - defines a cell.

That's the entire RAMC language!  Of course, you can customize keywords
by changing RAMC.LIB if you wish. Does TRIGGER involve too much typing?
No problem - change it to TRIG, TRG or even just T
But make sure that it's unique - changing both TRIGGER and TEAM to T
will cause major problems. So if you're planning to customize, exercise
some care, and read Appendix 1 before you begin.

As with the country entries in Zone 1, either a blank entry, or a caret
(^) in Zone 2 causes the last entered keyword to repeat as a default.
Notice how the keyword  ITEM  was not re-typed in the previous example.

As shown in the Quick Reference, entries in zones 3-11 differ slightly,
depending on the keyword. So the following sections are ordered by
keyword rather than zone. But first, an explanation of the [RAMC]
section structure.....


Trigger Attachments and 'Null' Triggers
----------------------------------------
In Red Alert, triggers may be attached to teams, cells (creating a
"cell trigger") or an item (i.e. structure, unit, infantryman or ship).
RAMC achieves this by having you list all TEAMs, CELLs and/or ITEMs
directly underneath the definition of the TRIGGER which is to be attached
to them, up until the next TRIGGER keyword. An example should make all
this clear:

;.......2........3............4.........5.........6...7...8...9...0.1.........
        TRIGGER  trig1
Greece    IF     EnteredBy    
          THEN   FireTrigger  trig2
          CELL                          c23

; cell c23 appears below the 'trig1' definition, so 'trig1' is attached to
; it, making it a cell trigger

        TRIGGER  trig2
          THEN   Destroy
USSR      ITEM   ConstYard              ^         +2
                 Power                  ^             +3
                 BombSilo               ^             +3

; similarly, the above 3 items ALL have trigger 'trig2' attached to them

The result of the above example is that if any Greek unit enters the cell
represented by the name 'c23', then USSR's Construction Yard, Power Plant
and Bomb Silo will all self-destruct!

To define teams, cells or items that DON'T have an attached trigger, you
have two options: either (1) place them at the very beginning of the
[RAMC] section (so that they don't appear underneath any trigger), or
(2) place them underneath a NULL TRIGGER.

A null trigger is really a 'dummy' entry to allow the definition of
'triggerless' CELLs, TEAMs and ITEMs. It is a trigger that has neither
events (IF...AND/OR keywords) nor actions (THEN keyword) defined
underneath. RAMC does NOT generate a trigger in the mission file in
this case. I enter the word '*NONE' in Zone 3 as a trigger name, although
this in itself does not make the trigger 'null' - it is purely there
for clarity. An example should make all of this clear....

;.......2........3............4.........5.........6...7...8...9...0.1.........
[RAMC]
Greece    TEAM   team1
            MEM  Rifleman     2
            ACT  Do           Hunt
          ITEM   Power                            60  40
USSR             Refinery               cellref1  +8  -1
//      
  All of the above items don't appear under any trigger definition,
  therefore they have no trigger attached. Note that both the team and
  Powerplant are owned by Greece, the Refinery by USSR.
\\
        TRIGGER  trig1
          IF     Destroyed
          THEN   RevealMap

          ITEM   HeavyTank              ^         +2  -2
          TEAM   team2
            MEM  Dog          3
                 Grenadier    2

; Both the heavy tank and the team of 3 dogs and 2 grenadiers appear  
; underneath 'trig1', so 'trig1' is attached to them. If either the
; tank, or 'team2' in its entirety, are destroyed, then the whole map
; will be revealed. Notice that all items here are owned by USSR, as
; the country entry from the previous area repeats as a default.

        TRIGGER  *NONE
          ITEM   HeavyTank              ^         +2  -2
          
; this is a null trigger, because there are no trigger events or actions
; immediately following the trigger keyword. Hence the tank defined
; here has no trigger attached. RAMC will not generate an entry in
; the [Trigs] section of the mission; the only entry generated will be
; the HeavyTank in the [UNITS] section. The '*NONE' text is optional.


The ability to define null triggers gives great flexibility - you can
define your ITEMs, CELLs and TEAMs in any order you wish, and then
simply place the relevant triggers immediately above those items to which
each trigger is to be attached - and use null triggers to define 'blocks'
of items to which no trigger will be attached. This flexibility is
further enhanced by the fact that you can change country 'on the fly',
so neither is it necessary to sort your entries country by country.


Cell Referencing
----------------
One of the biggest challenges in writing a non-graphical mission
builder lies in automating the placement of objects on the map.
How well have I achieved this?  I'll let you be the judge!

You have several options in the way in which you specify cell locations -
by defining a cell as an 'absolute' value, or relative to another cell
by using vertical (North-South) or horizontal (East-West) displacement
values, or relative to the map boundaries. You can use the caret (^) to
ditto a previous reference, and you can also assign a cell a name, 
which can be referenced anywhere else in the [RAMC] section. All of this
is explained in detail, with examples, below.

There are a number of ways to calculate INITIAL positions on the map.
TEMPLATE.DEF starts with 9 APC's evenly spaced around the map. These
APC's are owned by a neutral country (Turkey), to whom player control
has been assigned, and also the allies USSR and Greece (check this out
in the sections [Turkey], [USSR], [Greece]). This means that these
brown-coloured APC's can be moved around the map, 2 or 3 cells at a
time - enabling you to count cells - without firing or being fired at.
Their starting positions can be used to define new names for other cell
positions, and so forth, building up a library of geographical
landmarks, e.g. 'tree1', 'cliff2', 'endbridge'. You can then position all
of your starting units and structures relative to these landmarks (and
then use the structures as new landmarks). The more entries in this
'chain', the faster the process becomes. The examples below should make
all of this clear.

I chose APC's because they are the fastest moving land vehicle. If an
APC happens to start on a water cell, simply change it to an LST, and
you have a mobile naval cell counter. When you have finished defining
cell positions, simply change each occurrence of "ITEM  APC" to "CELL"
- and, presto! - the APC's vanish, leaving you with a playable mission.

Note: if you want to use Turkey as a player in your mission, simply
switch the 'dummy' country to another by altering the relevant countries'
sections in the .DEF file.

As an alternative to this method, you can create your own grid template.
In Windows 95 mode, a PC monitor displays a 20 (width) x 16 (height)
area of the Red Alert map at any given time. Measuring this area with a
ruler enables you to accurately calculate the height and width of each
cell. I used Microsoft Excel (any CAD program will also do) to draw this
grid (by switching gridlines off, and placing borders around a 20 x 16
cell area. Then I adjusted cell widths and heights until - 3 attempts
later - the printout was an exact fit). Finally I photocopied this
grid onto a plastic sheet. Any last minute minor adjustments can be
made by using the vertical and horizontal "stretch" and "squeeze"
adjustment knobs on your monitor. The end result is a transparent grid
that can be superimposed over your Red Alert map, to make cell counting 
a very simple exercise.

You may devise a better system than either of these (if so, I'd like
to hear about it!)  To users of 'graphical' editors (those that allow
you to 'point-and-click' objects directly onto the map), this may all
sound a little cumbersome. Granted, some trial-and-error might be needed
to perfect your map placements, but I would argue that, no matter what
type of editor you use, mission play-testing involves much trial-and-error
processing in any case, so map placements simply become another task
in the overall process.

The next section explains how you define those cell locations......

Cell References - entries in Zones 4-7
--------------------------------------
Cell definition in RAMC always uses zones 4-7, in exactly the same
way, irrespective of whether you are defining the position of an
item, an element of a trigger event or action, or a waypoint for
a teamtype reinforcement drop.

Zone 5 is used to store the base, or 'absolute' reference to a cell.
You can enter any one of the following:

  - zero (0), or leave blank, which refers to the top left cell position
  - a number (e.g. 4663), just as if you were calculating the location
    manually
  - the name identifying another cell location
  - a caret (^), to refer to the most recently specified cell location
  - a compass point (@...), which defines a point relative to the
    dimensions of the map

The following diagram shows the dimensions of the play area, absolute 
cell addresses, and the locations of the pre-defined compass points.
See {4-11} for an explanation of how cells are numbered.

             Maximum possible play area (128 x 128)
       --------------------------------------------------------------------
       |0                                                              127|
       |128                                                            255|
       |256      Edge of map (as defined in [Map] section)             383|
       | :    -----------------------------------------------------     : |
       | :    |@NW           @NNW      @N        @NNE          @NE|     : |
       |      |                                                   |       |
       |      |                                                   |       |
       |      |@WNW      @NW2          @N2          @NE2      @ENE|       |
       |      |                                                   |       |
       |      |                                                   |       |
       |      |@W         @W2          @O           @E2         @E|       |
       |      |                                                   |       |
       |      |                                                   |       |
       |      |@WSW      @SW2          @S2          @SE2      @ESE|       |
       |      |                                                   |       |
       |      |                                                   |       |
       |      |@SW           @SSW      @S        @SSE          @SE|       |
       |      -----------------------------------------------------       |
       |  :                                                            :  |
       |16256                                                        16383|
       --------------------------------------------------------------------

@O  represents the center of the map (based on your entries in the
    [Map] section). You can also use  @0

@N, @NE, etc represent the cells at the extreme edges of the map
    (north, north-east etc). These are very handy for defining the
    starting point for reinforcements that are entering the game
    from near (or just outside) the map edge.

@N2, @NE2, etc represent the cells HALF way from the centre to the
    relevant edge.

You can customize by adding your own compass point symbols in section 6
of the RAMC.LIB file (explained in Appendix 1).


Zones 6 and 7 define the vertical and horizontal displacement from the
base reference, by the number of cells specified:

A positive (+) value in zone 6 moves the position south (downwards)
A negative (-) value in zone 6 moves the position north (upwards)

A positive (+) value in zone 7 moves the position east (to the right)
A negative (-) value in zone 7 moves the position west (to the left)

Either leave blank, or enter  0  to specify no displacement.

                           North (negative)
                                 :
                                - 0
                            -- - : -- +
                                 :
                      - --       :       - ++
      West   ...  0 - ...........:........... 0 + ...  East 
   (negative)         + --       :       + ++        (positive)
                                 :
                            ++ - : ++ +
                                + 0
                                 :
                           South (positive)

Sketch your own copy of the above diagram, and keep it handy. When
you're placing objects, remember that  - ++  means a smaller negative
number (zone 6) followed by a larger positive number (zone 7).


Zone 4 is where you (optionally) assign a name to the new location,
which can then be later referenced anywhere in the [RAMC] section
as a new base reference. RAMC allows a maximum of 500 names to be
defined. Each name must be unique.


In summary:

  Location      Cell name
  of object  =  (optional) = base cell + 128 x vert disp + horiz disp
                  Zone 4      Zone 5             Zone 6      Zone 7

      where base cell can be an (earlier or later defined) cell name,
           an absolute address, a ditto (^) or a compass position (@xx)


Examples of all of the above:
;.......2........3............4.........5.........6...7...8...9...0.1.........

Greece    ITEM   ConstYard    cy1       @SW       -5  +4   
; the construction yard is placed 5 cells north and 4 cells east of the
; bottom left cell on the map (@SW). Its position is given the name 'cy1'

                 Refinery               ^             +3
; the refinery is placed 3 cells east of the construction yard. The ^
; refers to the most recent position, i.e. that occupied by the cons. yard
; (entering 'cy1' in zone 5 here would have had exactly the same effect)

                 BarrTent     tent      cy1       -4
; the barracks tent is 4 cells north of the cons. yard. The name 'tent'
; has been assigned to its map location. That enables any other items
; to be defined, anywhere in the [RAMC] section, at a location relative
; to the barracks tent.

                 MediumTank             tree1     +2  +2
; the tank is positioned 2 cells diagonally south-east of the cell
; 'tree1'. Notice how the location for 'tree1' isn't defined until later. 
; That is perfectly permissible.

          CELL                ridge               70  59
; 'ridge' is located 70 cells south, and 59 cells east of cell 0 (the
; top left cell of an imaginary 128 x 128 map). Hence the value RAMC
; will place in the .INI file will be 128 x 70 + 59 = 9019

          CELL                tree1         5698
; 'tree1' defines the 'absolute' cell location 5698. With RAMC, there's
; never any need to calculate values like this manually. However, if you
; want to give names to cells defined in the [TERRAIN] section, for
; example, then this is the way to do it.

          CELL                center    @O
; 'center' names the cell in center of the defined playing area (@O).


Whether you prefer to use dittos (^), or cell names, is entirely your
decision. A word of warning, however: cutting and pasting objects using
dittos (to place them under a different trigger, perhaps) will
necessarily change their location on the map!



The CELL keyword    {2-2} {4-11} {4-12}
----------------
The CELL keyword serves three purposes:
1. It provides one means of allowing you to define names for cell
locations on the map.
2. It allows you to define cell triggers.
3. It allows you to define waypoints.

Experienced mission creators: please note that waypoint definition is
TOTALLY AUTOMATIC. All you do is define the CELL location where an event
is to take place, and RAMC will assign an unused waypoint number, and
generate the [Waypoints] entry completely transparently. A maximum of
100 waypoints is permitted. You may, however, wish to 'force' the
assignment for waypoint 98 {4-11}.

The previous section 'Trigger Attachments and Null Triggers' illustrates
the creation of cell triggers. Placing a CELL definition between TRIGGER
definitions causes the prior TRIGGER to be attached to the cell, creating
a cell trigger. Placing a CELL definition at the start of the [RAMC]
section, or after a null trigger, simply allows the definition of a
cell name.

To define a waypoint, you simply place the number of the waypoint in
zone 3. Zones 4-7 behave exactly as described in the previous section.

;.......2........3............4.........5.........6...7...8...9...0.1.........
        CELL     98                     @N        -5
; this sets waypoint 98 to the cell 5 cells south of the top center
; of the defined playing area

You can define a rectangular block of cell triggers using a single
CELL statement, by making entries in zones 8, 9 and 11. The defined
CELL becomes the top left cell in the block, which extends downward
(south) by the number of cells you enter in zone 8, and rightwards
(east) by the number of cells entered in zone 9. Note: using negative
numbers in zones 8 or 9 will not work.

Zone 11, if left blank, will cause a 'perimeter-only' block of cell
triggers to be generated, thus:

                       XXXXXXXXXXXXXXXXXXXX
                       X                  X
                       X                  X
                       XXXXXXXXXXXXXXXXXXXX

While an F in zone 11 causes a 'filled' block of cell triggers to
be generated:

                       XXXXXXXXXXXXXXXXXXXX
                       XXXXXXXXXXXXXXXXXXXX
                       XXXXXXXXXXXXXXXXXXXX
                       XXXXXXXXXXXXXXXXXXXX

Examples:
 
;.......2........3............4.........5.........6...7...8...9...0.1.........
        TRIGGER  trig1
Greece    IF     EnteredBy    
          THEN   FireTrigger  trig2
          CELL                          c23       +1  -6
; a single cell trigger 

          CELL   98                               79  66  5   4
; a 5 x 4 perimeter-only block of cell triggers - top left cell in the
; block is 79 x 128 + 66 = 10178, to which waypoint 98 will be assigned

          CELL                mark1     @SE       -10 -10 1   6     F
; a 1 x 6 filled block of cell triggers - top left cell in the
; block is 10 units diagonally NW from the bottom right corner of the
; defined play area, to which the name 'mark1' has been assigned


The [CellTriggers] section is generated automatically. There is no limit
(at least as far as RAMC is concerned) to the number of cell triggers
you may define (provided that the [CellTriggers] maximum in section 2 of
RAMC.LIB is set to a high enough value - see Appendix 1 for details).


Defining ITEMs  {4-4} {4-5} {4-6} {4-7}
--------------
The ITEM keyword allows RAMC to generate:

Structures (buildings) - in the [STRUCTURES] section
Units (vehicles etc)   - in the [UNITS] section
Infantrymen            - in the [INFANTRY] section
Ships                  - in the [SHIPS] section

Also, the [Base] section is automatically created from your
structure definitions.

Zone 1 (country name) has been explained earlier in this document.
Zone 2 must contain the keyword ITEM (or ^, or be blank)

Zone 3 defines the item type, and determines which section
([STRUCTURES], [UNITS], [INFANTRY] or [SHIPS]) the entry will be made in.
Note that Red Alert doesn't allow aircraft to be defined in this manner.
You can type any valid item name, or its abbreviation, into zone 3.
For example, to define a heavy tank, type either  HeavyTank  or  3TNK
The full list of valid item types is stored in section 15 of RAMC.LIB,
and (as explained in Appendix 1) can be customized using a text editor.

Zones 4-7 define the item's anchor cell (in the case of a structure),
or starting cell (in the case of all others) on the map. This works
as described in the 'Cell Referencing' section above.

Zone 8 defines the item's starting health condition, as a percentage.
Enter a value between 1 and 100 (inclusive), or leave blank to have
RAMC generate the default value in section 4 of RAMC.LIB (originally
set to 100 in the shipped file). RAMC converts this percentage into
a base 256 number for you.

Zone 9 defines the direction the item is facing when play begins.
Enter a compass direction (N, NE, etc) - WITHOUT the  @ prefix -
or leave blank to have RAMC generate the default value in section 4 of
RAMC.LIB. RAMC converts this value into a base 256 number for you. Valid
compass directions are listed in section 6 of RAMC.LIB.

Zone 10 is valid for infantry and structures only, and should otherwise
be left blank.

For infantry:
Enter the sub-cell value (0,1,2,3 or 4) into which the infantryman is to
be placed at the start of play, or leave blank to have RAMC generate the
default value in section 4 of RAMC.LIB (set to 0 in the shipped file).

For structures:
Type the 'unknown' entry, which will ultimately be generated as the
SEVENTH parameter in the [STRUCTURES] entry. {4-4} Either type in
the required number, or leave blank to have the default value in section
4 of RAMC.LIB generated (set to 0 in the shipped version).


Zone 11 - operates differently for structures, and other items (units,
ships and infantry).

For structures:
Type an  R  to make the structure repairable/replaceable. {4-4}
In addition, you may also include a plus (+) or minus (-) sign, which
controls the way in which the [Base] section {4-10} is generated.
  +  means that an entry will also be made in the [Base] section
     for this structure, in addition to its [STRUCTURES] entry
  -  means that an entry will be made in the [Base] section, but NOT
     in the [STRUCTURES] section. This allows buildings to be
     constructed as part of the computer's production process. {4-10}

For units, ships and infantry:
Type the item's initial command (e.g. Guard, Sleep), or leave blank to
have RAMC generate the default entry in RAMC.LIB. Valid commands are
listed in section 9 of RAMC.LIB, and may be customized (see Appendix 1).

For examples on the use of ITEM, see the SCG01EA.DEF file.


Defining TEAMs  {4-14}
--------------
The TEAM (team type) entry consists of three parts:
1. TEAM keyword, which allows for the definition of a team name (optional),
   country, starting cell location, and the other parameters listed below.
2. MEM (members) keyword(s), defining the members (units) in the team
3. ACT (actions) keyword(s), defining the series of actions that the
   team will perform.

The correct keyword sequence is:
TEAM, followed by one or more MEMbers, followed by one or more ACTions.
At least one MEM statement, and one ACT statement must be specified.
Up to 200 teams may be defined overall, although this can be extended
by increasing the [TeamTypes] entry in section 2 of RAMC.LIB.

TEAM keyword
------------
Zone 1 (country name) has been explained earlier in this document.
The 'current' country at this point will be generated as the FIRST
parameter in the [TeamTypes] entry, i.e. zone 1 entries in any
following MEM or ACT statements occur too late to change this.

Zone 2 must contain the keyword TEAM

Zone 3 contains the name you want to use to reference the team elsewhere
(above or below) in the [RAMC] section. If the team is not referenced
anywhere, then the name may be omitted. Each name defined in this manner
can be up to 10 characters long, and must be unique (although you may
give a TRIGGER, CELL or a global the same name as a TEAM). A maximum
number of 200 team names may be used.

Zones 4-7 define the team's starting cell on the map, and is optional.
It appears to be significant only in defining the drop point for
reinforcement teams. See the 'Cell Referencing' section above for
further details.

Zone 8 contains the team 'priority', which will ultimately be generated
as the THIRD parameter in the [TeamTypes] entry. {4-14} Either type in
the required number, or leave blank to have the default value in
section 4 of RAMC.LIB generated.

Zone 9 contains the maximum number of instances of the team, which will
ultimately be generated as the FIFTH parameter in the [TeamTypes] entry.
{4-14} Either type in the required number, or leave blank to have the
default value in section 4 of RAMC.LIB generated.

Zone 10 contains the 'unknown' entry, which will ultimately be generated
as the FOURTH parameter in the [TeamTypes] entry. {4-14} Either type in
the required number, or leave blank to have the default value in section
4 of RAMC.LIB generated.

Zone 11 contains flags that will ultimately be converted into the SECOND
parameter in the [TeamTypes] entry. {4-14} Type in the required options,
or leave blank if none apply. The valid values are: 
  R  (replace)    = destroyed members of this team are Replaced
  S  (surplus)    = an inactive duplicate of this team is produced
  A  (autocreate) = this is an autocreate team
  D  (direct)     = this team executes orders regardless of enemy actions
  E  (evade)      = this team takes evasive action

MEM (teamtype members) keyword
------------------------------
Zone 1 (country name) has been explained earlier in this document.
Zone 2 must contain the keyword MEM (or ^, or blank)

Zone 3 defines the type of unit (vehicle, infantryman, ship or aircraft)
in the team. You can type any valid item name, or its abbreviation, here.
For example, to define a heavy tank, type either  HeavyTank  or  3TNK
The full list of valid item types in stored in section 15 of RAMC.LIB,
and (as explained in Appendix 1) can be customized using a text editor.

Zone 4 defines the number of units of a given type. Enter the number,
or leave blank to have the default in section 4 of RAMC.LIB generated
(this is set to 1 in the shipped version).

Zones 5-11 are not used and should be left blank.

ACT (teamtype actions) keyword
------------------------------
Zone 1 (country name) has been explained earlier in this document.
Zone 2 must contain the keyword ACT (or ^, or blank)

Zone 3 must contain a valid command, as listed in section 14 of RAMC.LIB.
Each command is documented in full below. Zone 4 contains any parameter
associated with the command (see below).

Zones 5-7 apply only if the parameter in Zone 4 is a cell location,
in which case the previous 'Cell Referencing' section explains all.
In all other cases leave zones 5-7 blank.

Zones 8-11 are not used and should be left blank.

Zones 3-4 - Valid commands and parameters for Team actions
----------------------------------------------------------
These are listed below. The value generated in the .INI file for the
command is shown at right as a comment. See {4-14-1} for more information.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  AttackAt     cellname  cellpos   +ns +we           ; 1
            ACT  Move         cellname  cellpos   +ns +we           ; 3
            ACT  Patrol       cellname  cellpos   +ns +we           ; 16

In each case the appropriate action is taken. A cell location in zones
5-7 is mandatory, which RAMC converts into a waypoint automatically.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  MoveTo       cellname  cellpos   +ns +we           ; 4

MoveTo effectively achieves the same result as Move, although RAMC
generates an absolute cell address as opposed to a Waypoint.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  Align        formtype                              ; 2

Aligns the units into the designated formation. Valid formation types
are listed in section 11 of RAMC.LIB.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  Guard        minutes                               ; 5

Causes the team to guard the area around their current location for the
specified number of minutes. Enter a number in zone 4, with a maximum of
1 decimal place. RAMC will multiply this value by 10 to generate the
correct entry in the .INI file.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  AttackTarcom                                       ; 7
            ACT  Unload                                             ; 8
            ACT  Deploy                                             ; 9
            ACT  Follow                                             ; 10
            ACT  Invulnerize                                        ; 13
            ACT  Load                                               ; 14
            ACT  SpyOn                                              ; 15

These commands require no parameter in zone 4. RAMC generates the code
necessary to have the team perform the specified action.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  Attack       targettype                            ; 0

Causes the team to attack the specified target type. Valid target types
are listed in section 10 of RAMC.LIB.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  Set          globalname                            ; 12

Sets the designated global switch to ON (1). RAMC assigns globalname a
number, which ultimately gets passed to the .INI file. A maximum of
60 different global names are permitted (at least as far RAMC is
concerned). See later section on Globals for more info.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  Do           command                               ; 11

Causes the team to perform the command as a specified action. This is the
same set of commands used in Zone 11 of an ITEM statement. The list of
valid commands in section 9 of RAMC.LIB can be customized, as explained
in Appendix 1.

;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  Repeat                                             ; 6

Experienced mission developers, note: this command probably works
differently to the way in which you'd expect. It causes every command
below to be repeatedly executed, in cyclic fashion.

Example:
;.......2........3............4.........5.........6...7...8...9...0.1.........
            ACT  Move                   point1       ; action 1
                 Guard        0.5                    ; action 2
                 Repeat
                 Move                   point2       ; action 3
                 Guard        0.5                    ; action 4
                 Move                   point3       ; action 5
                 Guard        0.5                    ; action 6

In this example, point1 is guarded once, while points 2 and 3 are
guarded repeatedly, for 0.5 minutes each.

For further examples on the use of TEAM types, see the SCG01EA.DEF file.


Defining TRIGGERs   {4-13}
-----------------
The TRIGGER entry consists of three parts:
1. TRIGGER keyword, which allows for the definition of a trigger name
   (optional), country, cell location, and the other parameters listed
   below.
2. IF, AND, OR keyword(s), defining the EVENTS that cause the trigger
   to be fired.
3. THEN keyword(s), defining the series of ACTIONS that will take place
   if the trigger is fired.

Two keyword sequences are permitted:

1. TRIGGER
   IF      (optional. Only one IF statement is permitted)
   AND/OR  (optional, permitted only if there was a prior IF. Only
            one AND, or OR, is permitted) 
   THEN    (at least one THEN must be present. Any number of additional
            THEN statements may follow)

In this case, all defined actions (THEN) will be executed, if the
IF....AND/OR...... event combination occurs, or evaluates as true.
    AND means that BOTH events must occur, or evaluate as true.
    OR  means that either event must occur, or evaluate as true.
If the IF statement is omitted (i.e. the trigger consists of THEN
statements only), then the trigger can only be fired externally
(i.e. by another trigger issuing a FireTrigger action).
There is no limit to the number of THEN statements that a trigger
may have. (RAMC transparently generates the additional triggers
necessary to process each statement, along with the code required
to fire successive triggers in the 'chain'.)

2. TRIGGER
   IF
   THEN
   IF
   THEN

In this case, the keywords must appear exactly as above. Only one
consecutive occurrence of each is permitted. The first action is
executed if the first event occurs; the second action is executed
if the second event occurs. Both parts operate independently of each
other.

Up to 300 different triggers may be defined in the [RAMC] section,
although this can be extended by increasing the [TeamTypes] entry in
section 2 of RAMC.LIB.

TRIGGER keyword
---------------
Zone 1 (country name) has been explained earlier in this document.
Please note that the country assigned to the SECOND parameter of the
[Trigs] entry is that which is current when the first THEN statement
is encountered (see below).

Zone 2 must contain the keyword TRIGGER

Zone 3 contains the name you want to use to reference the trigger
elsewhere (above or below) in the [RAMC] section. If the trigger is not
referenced anywhere, then the name may be omitted. Each name defined in
this manner can be up to 10 characters long, and must be unique (although
you may give a TEAM, CELL or a global the same name as a TRIGGER). A
maximum number of 300 trigger names may be used.

Zones 4-11: the FIRST parameter of the [Trigs] entry may be defined in
any one of these zones. Valid values are:
  O  (once-only)   = the trigger is fired only once
  R  (repeating)   = fired whenever the event has occurred to all
                      attached items
  F  (free repeat) = will repeat every time the event is true
If you leave columns 4-11 entirely blank, the default entry from
section 4 in RAMC.LIB will be used (set to O in the shipped version).

IF / AND / OR  keywords (Trigger Event definition)
--------------------------------------------------
Zone 1 (country name) has been explained earlier in this document.
Please note that country assigned to SECOND parameter of the [Trigs]
entry is that which is current when the first THEN statement is
encountered (see below).

Zone 2 must contain one of the keywords:  IF  AND  OR

Zone 3 must contain a valid event, as listed in section 12 of RAMC.LIB.
Each event is documented in full below. Zone 4 contains any parameter
associated with the event (see below).

Zones 5-7 apply only if the parameter in Zone 4 is a cell location,
in which case the previous 'Cell Referencing' section explains all.
In all other cases leave zones 5-7 blank.

Zones 8-11 are not used and should be left blank.

Zones 3-4 - Valid events and parameters
---------------------------------------
These are listed below. The value generated in the .INI file for the
command is shown at right as a comment. See {4-13-2} for more information.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     EnteredBy    country                               ; 1
          IF     CountrySeen  country                               ; 5
          IF     AllUnitsLost country                               ; 9
          IF     AllBldgsLost country                               ; 10
          IF     AllLost      country                               ; 11
          IF     ZoneEntered  country                               ; 24
          IF     LowPower     country                               ; 30

In each case the a valid country must be specified in Zone 4, unless you
leave Zone 4 blank, in which case the 'current' country will be built
into the correct parameter in the [Trig] entry. In other words, you
could specify the country in Zone 1 instead, if you wish.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     CreditsAbove amount                                ; 12

Enter the number of credits in Zone 4. (Note: RAMC neither multiplies nor
divides this value by 100 prior to generating the relevant value)

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     ElapsedTime  minutes                               ; 13

Enter the number of minutes in zone 4, with a maximum of 1 decimal place.
RAMC will multiply this value by 10 to generate the correct entry in the
.INI file.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     BldgBuilt    bldgtype                              ; 19
          IF     BldgExists   bldgtype                              ; 32
          IF     UnitBuilt    unittype                              ; 20
          IF     InfBuilt     inftype                               ; 21
          IF     AircBuilt    airctype                              ; 22

Enter either the full name, or abbreviation, of the item type, in Zone 4.
(e.g. ConstYard or FACT; Chinook or TRAN; etc)

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     TeamLeftMap  teamname                              ; 23

Enter a valid team name (defined in a TEAM statement) in Zone 4.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     IsSet        globname                              ; 27
          IF     IsClear      globname                              ; 28

Enter the name of a global switch in Zone 4. RAMC assigns globalname a
number, which ultimately gets passed to the .INI file. A maximum of
60 different global names are permitted (at least as far RAMC is
concerned). See later section on Globals for more info.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     AllFactsLost                                       ; 17
          IF     CivsLeftMap                                        ; 18

RAMC uses the 'current' country to generate the correct code.
Leave Zone 4 blank.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     BldgsLost    number                                ; 15
          IF     UnitsLost    number                                ; 16

Specify the number of buildings in Zone 4. RAMC uses the 'current' country
to generate the correct code.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          IF     NoEvent                                            ; 0 
          IF     Spied                                              ; 2 
          IF     Thieved                                            ; 3 
          IF     Discovered                                         ; 4 
          IF     Attacked                                           ; 6 
          IF     Destroyed                                          ; 7 
          IF     Any                                                ; 8 
          IF     TimerExpired                                       ; 14
          IF     CrossHoriz                                         ; 25
          IF     CrossVert                                          ; 26
          IF     AllFakesLost                                       ; 29
          IF     BridgesLost                                        ; 31

These events require no parameter in zone 4 - leave it blank.
The  NoEvent  option is redundant (since the IF keyword is optional, it
can simply be omitted), but is included for the sake of completeness.
The  Any  option will cause the trigger to be fired at any time, i.e.
at the start of the mission.

THEN keyword (Trigger Action definition)
----------------------------------------
Zone 1 (country name) has been explained earlier in this document.
Please note that the country assigned to the SECOND parameter of the
[Trigs] entry is that which is current when the first THEN statement
is encountered (see below).

Zone 2 must contain the keyword  THEN  (or ^ or blank)

Zone 3 must contain a valid action, as listed in section 13 of RAMC.LIB.
Each action is documented in full below. Zone 4 contains any parameter
associated with the action (see below).

Zones 5-7 apply only if the parameter in Zone 4 is a cell location,
in which case the previous 'Cell Referencing' section explains all.
In all other cases leave zones 5-7 blank.

Zones 8-11 are not used and should be left blank (except where
otherwise noted below).

Zones 3-4 - Valid actions and parameters
----------------------------------------
These are listed below. The value generated in the .INI file for the
command is shown at right as a comment. See {4-13-3} for more information.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   Winner       country                               ; 1
          THEN   Loser        country                               ; 2
          THEN   BeginProd    country                               ; 3
          THEN   AllHunt      country                               ; 6
          THEN   FireSale     country                               ; 9
          THEN   BeginAutoc   country                               ; 13
          THEN   BeginBaseAI  country                               ; 30

In each case the a valid country must be specified in Zone 4, unless you
leave Zone 4 blank, in which case the 'current' country will be built
into the correct parameter in the [Trigs] entry. In other words, you
could specify the country in Zone 1 instead, if you wish.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   CreateTeam   teamname                              ; 4
          THEN   DisbandTeam  teamname                              ; 5

Enter a valid team name (defined in a TEAM statement) in Zone 4.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   DropFlare    cellname  cellpos   +ns +we           ; 8
          THEN   Reveal       cellname  cellpos   +ns +we           ; 17
          THEN   RevealZone   cellname  cellpos   +ns +we           ; 18

In each case the appropriate action is taken. A cell location in zones
5-7 is mandatory, which RAMC converts into a waypoint automatically.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   Movie        number                                ; 10
          THEN   Sound        number                                ; 19
          THEN   Music        number                                ; 20
          THEN   Speech       number                                ; 21

Enter a number in Zone 4, corresponding to the desired effect.
For lists of valid movies, sound, music and speeches, see {5-1} {5-4}
{5-2} {5-3} respectively.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   KillTrigger  trigname                              ; 12
          THEN   FireTrigger  trigname                              ; 22

Enter a valid trigger name (defined in another TRIGGER statement) in Zone 4.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   ExtendTimer  minutes                               ; 25
          THEN   ReduceTimer  minutes                               ; 26
          THEN   SetTimer     minutes                               ; 27

Enter the number of minutes in zone 4, with a maximum of 1 decimal place.
RAMC will multiply this value by 10 to generate the correct entry in the
.INI file.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   Set          globname                              ; 28
          THEN   Clear        globname                              ; 29

Enter the name of a global switch in Zone 4. RAMC assigns globalname a
number, which ultimately gets passed to the .INI file. A maximum of
60 different global names are permitted (at least as far RAMC is
concerned). See later section on Globals for more info.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   AddOneWeapon weapontype                            ; 33
          THEN   AddRepWeapon weapontype                            ; 34

Enter the name of a valid special weapon type in Zone 4, as listed
in section 8 of RAMC.LIB.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   Reinforce    cellname  cellpos   +ns +we teamname  ; 7

A cell location entry in zones 4-7 is optional, but if entered, RAMC
will automatically generate the necessary waypoint for the appearance
of the reinforcements. You must enter a valid team name (defined in a
TEAM statement) anywhere in Zones 8-11, to specify the reinforcing team.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   PrefTarget   targettype                            ; 34

Enter the name of a valid target type in Zone 4, as listed in section 10
of RAMC.LIB.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   Text         number    ; `TUTORIAL.INI entry`      ; 11

Enter the number of the text item in Zone 4 {6-1} and RAMC will generate
the code necessary for Red Alert to display the correct text from
TUTORIAL.INI. 
To update TUTORIAL.INI directly, enter the desired text FOLLOWING a
semi-colon and EMBEDDED between two grave (`) characters. (This is the
one occasion where text to the right of the semi-colon is not entirely
treated as a comment). RAMC will update TUTORIAL.INI for you, either
overwriting an existing message, or creating a new one. Note that you
will probably have to re-load Red Alert for changes to TUTORIAL.INI
to take effect.

;.......2........3............4.........5.........6...7...8...9...0.1.........
          THEN   NoAction                                           ; 0
          THEN   AllowWin                                           ; 15
          THEN   RevealMap                                          ; 16
          THEN   StartTimer                                         ; 23
          THEN   StopTimer                                          ; 24
          THEN   GrowShroud                                         ; 31
          THEN   Destroy                                            ; 32
          THEN   LaunchNukes                                        ; 36

These events require no parameter in Zone 4 - leave it blank.
The  NoAction  option is redundant (if nothing is to happen, why create
a trigger?), but is included for the sake of completeness.


For further examples on the use of TRIGGERs, see the SCG01EA.DEF file.


Globals
-------
To understand globals, read {7-10}

RAMC allows you to define and use your own names, which allows for
much greater readability than simply using numbers. If you prefer to
use numbers, there's nothing to stop you from naming them (e.g.)
g1, g2, g3, etc. RAMC allows you to define up to a maximum of 60
global names. Each name can contain up to 10 characters, excluding
semi-colons, and it must NOT begin with a digit (0-9). Apart from
that, any characters from the keyboard are permissible.

Unlike team, trigger and cell names, global names aren't formally
defined - RAMC simply picks them up 'on the fly', so there is no
'undefined global' error message. It follows that you must take
care to keep the spelling consistent, when referring to the same
global in two or more places in the [RAMC] section.

Globals used in your mission definition are listed in the .XRF file.


Customizing TEMPLATE.DEF and RAMC.REF
-------------------------------------
Remember that you can customize, and save, TEMPLATE.DEF, so that you
begin editing with your own preset preferences. Or better still, create
multiple template files, e.g. one for Allied missions, another for
Soviet missions, and so on.

Likewise, customize RAMC.REF to suit your requirements. The more
pre-defined blocks of re-usable logic you create in RAMC.REF, the
more productive your mission development will become.


Importing unit/structure definitions created by other tools
-----------------------------------------------------------
Version 1.1 allows you to import these definitions directly into the
[RAMC] section, and then build cell reference names, teams, triggers,
and so forth, around them. So now there are 3 ways to create map
placements:

1. By using RAMC as described in the 'Defining ITEMs' section above.
2. By using a 'graphical' or other 'third party' tool.
3. By importing definitions directly from an .INI (or other) file.

RAMC permits any combination of these to be used in the same mission.
Each imported item is reverse engineered back into the RAMC language
(updating the .DEF file accordingly), and then processed in the normal
manner.

The importing process is very simple. You simply run the third party
tool to create definitions like:

0=Greece,JEEP,256,6463,128,Guard,None
8=USSR,E1,256,8125,0,Sticky,128,None
22=USSR,POWR,256,8267,0,None,0,1

and then copy these anywhere into the [RAMC] section of your .DEF file.
Any triggers created by the other tool will be ignored, and overridden
by trigger definitions surrounding the copied items.

WARNING: do NOT copy the section headers ([UNITS], [INFANTRY], etc)
into the .DEF file, as this will cause disastrous results!  RAMC uses
the object type (JEEP, E1, POWR, etc) to determine the correct section,
and re-numbers each item accordingly.

In addition to the above parameters, you can manually add a cell
reference name, and (for structures only) add the [Base] section
entry (+ or -). The full list of parameters is (additions in CAPITALS):

Unit or ship:
#=country,itemtype,health,cell#,facing,command,trigger,CELLNAME

Infantryman:
#=country,itemtype,health,cell#,subcell#,command,facing,trigger,CELLNAME

Structure:
#=country,itemtype,health,cell#,facing,trigger,?,repairable,BASE,CELLNAME

where 'CELLNAME' is an optional entry providing an identifier used to
reference 'cell#'. As with any cell name, it can be used to reference
the cell anywhere else in the [RAMC] section. See the 'Cell Referencing'
section above for more information.

'BASE' can either be left null, or contain either  +  or  -
which operates exactly as described in the 'Defining ITEMs' section above.

Examples:
0=Greece,JEEP,256,6463,128,Guard,None,Jeeppos
8=USSR,E1,256,8125,0,Sticky,128,None
22=USSR,POWR,256,8267,0,None,0,1,,Pplant1
37=USSR,DOME,256,8387,0,None,0,0,+

In item 0, cell 6463 has been given the name 'Jeeppos'
Item 8 contains no further RAMC enhancement
Item 22 has no [Base] enhancement, but cell 8267 has been assigned
the name 'Pplant1' for subsequent referencing
Item 37 has the [Base] enhancement '+' which means that the relevant
entries will be generated in both the [Base] and [STRUCTURES] sections


APPENDICES
==========


Appendix 1 - Customizing the RAMC Language
------------------------------------------
As has been alluded to throughout this document, you can customize the
RAMC language by editing the text in the RAMC.LIB file. Be careful,
however, to retain its existing format: do NOT embed additional
commas in text, for example. You can however, safely modify virtually
all aspects of the RAMC language to achieve the style of readability,
and typing workload, that suits your personal taste. Also, remember to
update RAMC.REF accordingly, to keep both files compatible.

If you make changes to RAMC.LIB, then the file is likely to become
incompatible with previous missions you have made. It is recommended,
then, that you make a backup copy of RAMC.LIB before modifying it.

The following outlines what you can and can't do to each section of
RAMC.LIB.

Section 1 - Zone widths - this section controls the width, and starting
position of each zone. I haven't thought through all the ramifications
of modifying it, so it's probably safest to leave it alone.

Section 2 - Sections maximum - this controls the maximum number of lines
that can be output to each section in the generated .INI file. You may 
freely increase any value which is too low.

Section 3 - Language Keywords - you may freely change the spelling of
the existing keywords. Do NOT attempt to renumber the keywords, or
add new ones, however. Ensure that each entry is unique.

Section 4 - Language Defaults - the format of each line here is:
index=keyword#,zone#,default-text. The keyword number refers to the
index alongside the keyword in section 3. So an entry in this section
reading:    1=5,8,7     means - if the zone 8 entry of a TEAM statement
(TEAM is keyword# 5) is left blank, then substitute the character
string '7'. You can set up a maximum of 30 defaults in this section.
The number of characters in 'default-text' is limited only by the zone
width into which the substitution will be made.

Section 5 - Compiler States - this section controls the sequence in
which keywords may follow each other, and should NOT be modified.

Section 6 - Compass directions - this section serves 2 purposes:
1. Controls the direction names (N, NE, etc) which, when entered in
   Zone 9 of an ITEM statement, control the direction that the item
   faces when play begins.
2. Controls the special cell locations (prefixed with @) that may be
   used to define an object's location relative to the dimensions
   of the play map.
Bear in mind that any change made to the text in the third parameter
of entries 0 thru 15 impacts upon both of these criteria. This text
should not exceed the width of Zone 9 (4 characters).
Changing the first and second parameters impacts only on point (2).
These parameters define the position on the play map, relative to
[Map] section definition, at which the special location is to be set.
The origin (0,0) is the NW corner of the map, and the parameter
expresses as a fraction the distance from the origin (0) to the
opposite edge (1). The first parameter contains the vertical (N-S)
distance, the second the horizontal (W-E) distance. The entries in
RAMC.LIB themselves should serve adequately as examples.
You may modify existing entries, or create new ones up to a total
of 100 entries. Do not attempt to renumber entries 0 thru 15, however.

Section 7 - Country names - the first parameter contains the text that
RAMC will generate to the .INI file, and should therefore NOT be
modified. The second parameter contains the RAMC language element, and
may be changed to any unique identifier that you wish. Do not attempt to
renumber the entries, or add new ones, however.

Section 8 - Valid special weapon types - the text in the first parameter
may be modified to anything you wish, up to a maximum of 10 characters.
Do not attempt to renumber the entries, or add new ones, however.

Section 9 - Unit commands - the first parameter contains the text that
RAMC will generate to the .INI file, and should therefore NOT be
modified. The second parameter contains the RAMC language element, and
may be changed to any unqiue identifier that you wish. Do not attempt to
renumber the entries, or add new ones, however. Entry 23 gives the
default that will be substituted if the Zone 11 entry for a unit, ship
or infantryman's ITEM definition is left blank.

Section 10 - Valid target types - the text in the first parameter
may be modified to anything you wish, up to a maximum of 10 characters.
Do not attempt to renumber the entries, or add new ones, however.

Section 11 - Valid team formations - the text in the first parameter
may be modified to anything you wish, up to a maximum of 10 characters.
Do not attempt to renumber the entries, or add new ones, however.

Section 12 - Trigger Events - the first parameter controls the way
in which RAMC processes the entry in Zone 4 of an IF/AND/OR
statement, and should NOT be modified. The second parameter contains the
RAMC language element, and may be modified to anything you wish, up
to a maximum of 10 characters. Do not attempt to renumber the entries,
or add new ones, however.

Section 13 - Trigger Actions - the first parameter controls the way
in which RAMC processes the entry in Zone 4 of a THEN statement, and
should NOT be modified. The second parameter contains the RAMC language
element, and may be modified to anything you wish, up to a maximum of
10 characters. Do not attempt to renumber the entries, or add new ones,
however.

Section 14 - Team Type Actions - the first parameter controls the way
in which RAMC processes the entry in Zone 4 of an ACT statement, and
should NOT be modified. The second parameter contains the RAMC language
element, and may be modified to anything you wish, up to a maximum of
10 characters. Do not attempt to renumber the entries, or add new ones,
however.

Section 15 - Valid Item types - the first and second parameters contain
entries that RAMC will generate to the .INI file, and should therefore
NOT be modified. The third parameter contains the RAMC language element,
and may be modified to anything you wish, up to a maximum of 10
characters. Do not attempt to renumber the entries, or add new ones,
however.

Section 16 - Error Messages - the first parameter governs whether the
error message is enabled (1) or disabled (0). Disabling error messages
will likely cause incorrect .INI file entries to be generated, so all
errors should be left as enabled. The text in the second parameter can
be freely modified to anything that you wish. Do not attempt to renumber
the entries, or add new ones, however.


Appendix 2 - Error Messages
---------------------------
Whenever it locates a syntax error, RAMC displays one of the following
messages on the line immediately BELOW the error (although these may be
separated by one or more comment lines). The zone that the error refers
to is highlighted by a row of question marks (?????).

Please note that only the [RAMC] section is syntax checked. The RA
Mission Annotater program (RAMA) performs a wider range of checks,
including section headings. It is recommended that you run RAMA across
your completed .INI file before releasing the final version of your
mission to the RA community.

Here is the full list of RAMC messages, with explanation:

001: invalid country                         (see RAMC.LIB section 7)
002: invalid command                         (see RAMC.LIB section 9)
003: invalid target type                     (see RAMC.LIB section 10)
004: invalid direction                       (see RAMC.LIB section 6)
005: invalid formation                       (see RAMC.LIB section 11)
006: invalid spec. weapon                    (see RAMC.LIB section 8)
007: invalid team action                     (see RAMC.LIB section 14)
008: invalid trigger event                   (see RAMC.LIB section 12)
009: invalid trigger action                  (see RAMC.LIB section 13)
       In the case of any of the above errors, the designated item has
       been mis-spelled. Check RAMC.LIB for a list of valid items. Also,
       make sure that you have all items in their correct zones.

010: undefined trigger name
       The trigger name doesn't match one defined in a TRIGGER statement.

011: undefined team name
       The team type doesn't match one defined in a TEAM statement.

012: not a numeric value
       A numeric value must comply with the following rules:
         Positive numbers may be entered with a leading plus (+) sign.
         Negative numbers MUST be entered with a LEADING minus (-) sign.
         A decimal point (.) is permitted; embedded commas are not.
         The number zero must always be entered simply as  0
       Make sure that all items on the line are in the correct zones.

013: number out of range
       The highlighted number lies outside the valid range, which is
       shown in square brackets, e.g. [1,6] means your entry must lie
       between 1 and 6 (inclusive).

014: invalid flag value
       The entry in this zone is invalid. Valid entries are shown inside
       square brackets, e.g. [ RFO] means that your entry must be one of
       blank, R, F or O.

015: keyword not allowed
       The highlighted keyword may not follow the keyword immediately
       above it. Either you've mis-spelled the keyword, the sequence of
       keywords is incorrect, or the statement 'block' is incomplete
       (e.g. TEAM definition without a ACTion statement).

016: invalid unit/structure
       The unit of structure has been mis-spelled. Check section 15 of
       RAMC.LIB for a list of valid items, and that all items are within
       the correct zones.

017: item not allowed here
       The item type is incorrect. Possible item types are structures,
       units (vehicles), infantrymen, aircraft and ships. For example,
       you can't use an aircraft type in an ITEM statement.

018: trigger name already used
       You may only define a trigger name once. Two or more TRIGGER
       statements are using the same name. Assign any duplicate
       trigger a different name.

019: team name already used
       You may only define a team type name once. Two or more TEAM
       statements are using the same name. Assign any duplicate team
       type a different name.

020: cell name used elsewhere
       You may only define a cell name once. Two or more CELL statements
       are using the same name. Assign any duplicate a different name.

021: undefined cell name
       The reference in Zone 5 may be mis-spelled, or perhaps you've
       forgotten to create its definition (i.e. elsewhere in Zone 4).

022: dual [Base] ownership
       Only one country may have entries in the [Base] section. You may
       not use the  +  or  -  sign in Zone 11 for more than one country.

023: waypoint already used
       In general, you should allow RAMC to define waypoints for you
       automatically. In assigning waypoints, RAMC takes the first
       unused waypoint number it can find. This error is caused by the
       fact that you are attempting to assign a waypoint number that
       RAMC has already taken for its own use (earlier in the code).
       Three possible solutions: either (1) type in a higher waypoint
       number, or (2) move the CELL definition nearer the start of the
       [RAMC] section, or (3) remove the waypoint number altogether.

024: cell definition missing
       You must define a cell location here, by making an entry in
       at least one of Zones 5, 6 or 7. To refer to cell location zero,
       type  0  into Zone 5. To refer to the last defined cell, type
       a ditto (^) into Zone 5.

025: final block incomplete
       The final statement 'block' in your .DEF file is incomplete.
       For example, your TEAM definition might be lacking ACTions.


Appendix 3 - RAMC Language Quick Reference
------------------------------------------
;.......2........3............4.........5.........6...7...8...9...0.1.........
;ountry TRIGGER  trigname     R
;         IF     event        param     cellpos   +ns +we
;         THEN   action       param     cellpos   +ns +we param2
;ountry   TEAM   teamname     cellname  cellpos   +ns +we pr  mi    RSADE
;           MEM  unittype     num
;           ACT  command      param     cellpos   +ns +we
;ountry   ITEM   structtype   cellname  cellpos   +ns +we hc% dir   R+
;ountry   ITEM   unittype     cellname  cellpos   +ns +we hc% dir s command
;         CELL   wp           cellname  cellpos   +ns +we hhh www


Appendix 4 - About the Author
-----------------------------
RAMC is (C)opyright David Louisson
                    Hamilton, New Zealand
                    E-mail:  dave@bsnz.co.nz



                     ======= END OF DOCUMENT ======

