Advanced Scripting

42.  How do I work with gates?    

Gates are a bit tricky to work with in scripts, and how you handle them depends on whether they are to be used by the player's units directly or will have units scripted to pass through them.  Let's look at both these possibilities in detail.  One thing is common for both uses: you should first place the gate in its own Mission Group within the Map Editor so you can easily reference and control it in your scenario.

A.   Gates for the Player.

For a gate that opens when the player approaches, you'll need the gate Mission Group as well as a "detection zone" surrounding it.  Set these up in the Map Editor.  You will then need to detect friendly units in that zone, open the gates, and keep the trigger active.  A second trigger is needed to close them again.  It's also a good idea to insert a flag in the triggers, so that when no units are being detected the gates aren't being constantly told to close.

- Open Gates

CONDITION

      Number of units of player <Red> in zone <GateZone> is more than 0.

ACTION

      Select all units of group <Gates>.

      Open selected gates of player <Black>.

      Turn flag <GatesClosed> off.

      Activate current trigger.

 

- Close Gates

CONDITION

      Flag <GatesClosed> is off.

      Number of units of player <Red> in zone <GateZone> is less than 1.

ACTION

      Select all units of group <Gates> by changing previous selection.

      Close selected gates of player <Black>.

      Turn flag <GatesClosed> on.

      Activate current trigger.

NOTE:  Remember, flags are by default ON, so the first "change in status" for GatesClosed is turning it off.

B.   Gates for Scripted Units

Gates through which units will pass by script command are one of the most complex "basic" functions of the game to replicate.  This is because the gates have a slight delay between being ordered to open and the path being clear.  Without a clear path, units ordered into a zone won't budge.  The following example will show you how to open a gate, order a group of units through it, and have it close behind them with a timer.  It is assumed that another trigger CONCEPTUALLY causes the gates to open, e.g. two units being in a zone engage in dialogue and negotiate an alliance between the player (Red) and a city controlled by player Orange.

- Alliance Formed

CONDITION:

            Number of units of group <Contact> in zone <ContactZone> is more than 0.

            Number of units of group <RedGeneral> in zone <ContactZone> is more than 0.

ACTION:

            Set timer <GateTimer> for 2000 ticks.

            Turn flag <GateFlag> off.

- OpenGates

CONDITION:

            Number of ticks left before timer <GateTimer> snaps into action is less than 1030.

            Flag <GateFlag> is off.

ACTION:

            Select all units of group <OrangeGate> by changing previous selection.

            Open selected gates of player <orange>.

- ThroughGates

CONDITION:

            Number of ticks left before timer <GateTimer> snaps into action is less than 1000.

            Flag <GateFlag> is off.

ACTION:

            Select all units of group <OrangePikes> by changing previous selection.

            Order selected units of player <orange> to go and attack to zone <OrangeWaypoint> saving waypoints and place them in direction 90.

- CloseGates

CONDITION:

            Timer <GateTimer> has snapped into action.

ACTION:

            Select all units of group <OrangeGate> by changing previous selection.

            Close selected gates of player <orange>.

NOTE:  This trigger only opens and closes the gate for player Orange once, and uses one timer to regulate the whole operation.  That timer in turn is regulated by a flag, to prevent the gates from opening at the beginning of the game (before the timer has been set).

NOTE:  There are other ways, obviously, to set up and close gates... but the critical factor in all cases will be a delay between when a gate is opened and when units are ordered to pass through them.

43.  How do I display messages?    

Messages can add a little spice to your games, help structure them, and give the player ideas on what he or she is supposed to be doing anyway.  They're also a source of significant bugs in the game, as mentioned earlier on.  Follow those guidelines to ensure your scenario doesn't suffer when adding messages.

Adding messages to the game is otherwise quite easy.  Based on conditions you set (say, units are present in a zone), simply choose the action "Bring on message."  You will see a dialogue in which you can type your message, and a menu from which you can select a graphic to be displayed along with it.

Example:

CONDITION

      Number of units of player <Red> in zone <TownZone> is more than 0.

ACTION

      Bring on message: "We have arrived safely at the town of Muddleberg."

NOTE:  Numerals at the beginning of a message get cut off, e.g. "300 men are advancing!" will be displayed as "men are advancing!" in game.

NOTE:  In the .txt file in which messages are stored, the image numbers are offset by one.  Thus, the image numbered 6 in the Ukraine image folder is referenced to as file no. 5 in the folder (the first file, image 1, being referenced as 0).
  

44.  How do I use Inserted Condition Blocks (ICBs)?    

Inserted Condition Blocks (ICBs) are one of the more powerful tools available to the Cossacks scriptwriter.  They enable you to establish secondary conditions to a trigger, set alternative responses, and ask yes/no questions of the player.

 After setting up your first condition for a trigger, select "Basic > Inserted Condition Block" as one of the actions.  You will see three parts to this action:

 

IF -- defines the secondary condition

THEN -- directs the response to the trigger if the secondary condition is met

ELSE -- directs the response to the trigger if the secondary condition is not met

 

NOTE:  Secondary conditions are all-or-nothing deals.  If part -- but not all -- of the secondary condition is met, nothing will happen until either all conditions are true (producing a THEN reaction) or all conditions are falls (producing an ELSE reaction).

 

Example:

 

CONDITION

      Number of units of player <red> in zone <MountainPass> is more than 0.

ACTION

      IF

            If number of units of player <blue> in zone <MountainPass> is more than 0.

      THEN

            Bring on message: "Sir!  The Austrians have blocked our path through the mountains!  We will need to fight our way through!"

      ELSE

            Bring on message: "Sir, we are in luck!  We have succeeded in cutting the enemy off at the pass.  If we fortify here they will be easy prey for our cannons."

 

This example first checks to see that player Red has reached a zone called "MountainPass."  Once the player's units are in the zone, it will check if Blue is also present.  If Blue is, the first message is displayed informing the player of the danger.  If Blue is not present, the game gives him a little tactical advice on how to capitalize on the situation.

 

Note:  ICBs cannot be nested, but several can be used in the same trigger (in parallel). 

 

 

45.  How do I ask questions?    
 ICBs have an additional, unique pair of conditions listed under "Questions" -- whether the player clicks "Yes" or "No."  These conditions act as a special Message action.  Define your question using this condition and the responses via "THEN" and "ELSE." 

 

Example:

 

CONDITION

      IF

            Affirmative answer to "Hold, sir!  Strangers do not pass through these lands without paying tribute to Duke Griedemann.  Are your lives worth 500 gold?"

      THEN

            Bring on message: "Most wise of you, sir.  Now pass quickly before the toll rises!"

            Take from player <Red> 500 of gold.

      ELSE

            Bring on message: "We are agreed that your lives are worthless, then.  Men, KILL THEM!"

            Change relations between players [break alliance between Red and Black]

            Deselect units of player <Black>.

            Select all units of group <Bandits>.

            Attack group <Travelers> with selected units of player <Black>.

 

This trigger will ask for a tribute to Duke Griedemann's men.  If the player pays the toll, gold is deducted from his treasury and he's allowed to pass unmolested.  If the player opts not to pay, his treasury remains intact but he suffers the wrath of Griedemann's bandits.

 

NOTE     There is no appreciable difference in using the affirmative or negative option; it depends on whether you are an optimist or a pessimist.  :)

 

 

 

46.  What's a Dynamic Group?    
 A Dynamic Group (DG) is a collection of units defined "on the fly" during the course of the game.  Unlike Mission Groups, they are not fixed and predetermined; their makeup can be changed at will based on scripted conditions.  This is what makes them dynamic -- and dynamic means powerful.

 

All functions dealing with the creation of DGs are found in the "Operations on Units" section.  There are two basic ways of creating DGs:  By selecting and saving units, and by creating new units.  We'll deal with creating units later; for now, we'll focus on selecting and saving.

 

You have a number of means available to select units, explained in detail earlier: by existing group, by type, by zone, etc.  One of the most useful in this instance is selecting player units in a zone, so let's follow that through from start to finish.

 

The action we will want to use for this operation is "Save selected units of player <color> to dynamic group <groupname> by <changing/adding> previous units."  The <color> choice behaves as in other triggers, but the rest has some subtle but important differences to it.

 

Firstly -- unlike Mission Groups -- Dynamic Groups can be renamed in the Scenario Editor, in the same way that flags and timers can be renamed.  It's a good idea to name your dynamic groups intelligently (and of course with no spaces).  "_Dyn" is automatically appended to Dynamic Groups, so you needn't worry about adding that specification.

 

Secondly, note the slight change of wording in regards to changing/adding to previous units.  This has nothing to do with the selection (as opposed to other triggers).  Instead, it gives you the option to clear out an existing DG (by "changing" the units), or adding to the units *already in the group*.  Thus, for example, one can have several different triggers adding to the same big dynamic group.

 

Say you want to take all Red units in zone <TargetZone> and put them into one DG.  Your trigger should look something like:

 

CONDITION

      Number of units of player <Red> in zone <TargetZone> is more than 0.

ACTION

      Deselect units of player <red> (as explained earlier)

      Select units of player <Red> in zone <TargetZone> by changing previous selection

      Save selected units of player <Red> to dynamic group <TargetGroup_Dyn> by adding to previous units.

      Activate Current Trigger.

 

This trigger will put any and all Red units passing through TargetZone into the group TargetGroup_Dyn.  Because we are adding to the group (not changing it), and the trigger remains active, even units that wander outside of TargetZone will still be part of this growing DG.  Of course, there may be situations where you want only a few units put into the group, or only units in a specific zone... it's up to you and your game plans.
47.  What are some uses for Dynamic Groups?    
 The possibilities are almost endless.  Using DGs you can:

      - More accurately direct "AI" attack responses

      - Check for and regulate a certain type of unit in a zone (e.g. keeping battleships out of shallows)

      - Get artillery units to use round shot on a group

      - Use player-built structures appropriately in the game

      - ... and much much more!