The
  Way Of
    The Wombat
Handlers

Contents

2.0 Handlers
2.1 Events Trigger the Handlers
2.2 Handler Structure
2.3 Example
2.0 Handlers

Open any SLIC file, and somewhere in it will be an event handler. Event handlers 'see' the event happening, and trigger the code that you want to react to that event (They recognise a specific x and trigger your code to make y occur)


2.1 Events Trigger the Handlers

Events are things that happen in the game. Most are fairly self-explanatory. BeginTurn 'fires' every time a turn begins (once for each player including the barbarians, not once for every human turn). MoveUnit fires every time a unit is moved. Activision provided a list of the events that SLIC recognises.
Note that for each event, there are one or two (and occasionally three or more) variables listed after the event. They look like this:
GetExpelledOrder(army_t, location_t, int_t<player>)
This is an event that will trigger a handler. For example, you want to make it so that whenever an army is expelled, the player who owns the army will be told about it.
The variables after the event are automatically generated into the built-in arrays so that when you trigger a handler on the GetExpelledOrder event, army[0] will be the "name" the game will use temporarily for that army in context, location[0] will be the army's location in context, and player[0] will be the army's owner.

See chapter 3 for more on variables.

In diplomacy events in particular, you often get 2 players listed. These will be stored as player[0] (the person making the proposal for instance) and player[1] (the recipient). This is different from player 0 (barbarians) and player 1 (Usually the human. Almost always the civ in blue).



2.2 Structure of Handlers

Event Handlers will all look something like this:

HandleEvent(BeginTurn) 'handler_name' post {
  • The first bit 'HandleEvent' is always there. It defines the next block of code as an event handler.
  • Then the parentheses open, and you have to fill in an event that you want the code to fire on. (ie. define your x)
  • Between the ' ' marks, fill in a handler name. To avoid confusion (for yourself and the game) this has to be named differently to every other handler, and not have the same name as any variables you are using, or functions, or events. This can be avoided 99% of the time by naming it, and then adding an H on the end, to denote that is a handler.
  • Then comes the pre/post bit. 'Pre' handlers trigger before the in-game stuff occurs, 'post' triggers afterwards. Most of the time it doesn't matter whether the code fires before or after the in-game stuff has been taken care of, but occasionally if you want one trigger to fire before the other, then set one to pre (before) and one to post (after). Also, for things like CaptureCity, and the city's owner will have changed between 'pre' and 'post', which you can use to your benefit if you know about it, or be confused by if you don't.
  • Finally, the brackets open, to signify that everything inside them is part of the event handler.

If you are using EditPlus2 with the SLIC addon, you should get a colourful line of blue-red-pink-blue, and then you know you didn't make any typos or whatever.



2.3 Example

HandleEvent(SleepUnit) 'kill_the_unit' pre { KillUnit(unit[0]); }

This is a very simple event handler. It consists of one event (the SleepUnit event), and one reaction, a function. It kills the unit that has just been put to sleep.

back close forward