In order for Warzone 2100 scripts to function properly two files are required: a file with a .slo extension and a file with a .vlo extension.
A .slo file is the main part of the script and holds executable instructions while the .vlo file holds additional variable declarations necessary for the .slo file to function properly.
It is common for a script to deal with new or existing game components such as research topics, structures, unit bodies, propulsions, weapons etc. All these components are defined in appropriate text files such as body.txt or structure.txt. For more information on those text files take a look at Txt Editing. If you want to use any of these components in your script - in your .slo file - like for example if you want to place certain structures on the map using scripts or enable a certain research topic, you must first make these components available to your script by defining them in a .vlo file.
Roughly said a .slo file is equivalent to a ".c" file and .vlo to a header file in C/C++.
Note for skirmish/multiplayer: Some things of this manual do not apply to skirmish scripts. Make your changes to player0.slo and vlo -> player7.slo and vlo.
Comments
There are two types of comments for the script language. A multi-line comment is started by the characters /* and finishes with */. A single line comment is started by and automatically ends at the end of the line.
Vlo files
When writing a script it is usually known what data (as defined in data .txt files, located in 'stats' folder) will be used in the script, so it is a good idea to start writing the script with a .vlo file.
Vlo files are structured as follows:
script "myScript.slo"
run
{
<variable_definitions>
}
In the first line a .slo file is attached to this particular .vlo file. variable_definitions that resides inside the curly braces is the heart of every .vlo file, it contains definitions of the data that will be used in the main script part - the .slo file. Each variable definition starts on a new line and is structured as follows:
<variable_name> <variable_type> <variable_value>
Note: Available data types are covered in Scripting Data Types.
For example if you want to have access to certain droid bodies, like "Python" in your script you have to define it in your .vlo file and assign it to a variable of type BODY with some descriptive name, like:
myPythonBody BODY "Body11ABT"
"Body11ABT" is an internal name of the "Python" body used by Warzone 2100, it is defined in the body.txt file. Since it is a string it must be put inside quotation marks. All components, be it some research, structure, droid template or a weapon are referred to by their internal names in the game and are defined in the appropriate text files.
Each variable definition in a .vlo file starts on a new line and ends at the end of the line.
It is also possible to define arrays of some data type. For example if you want to use the following 3 research topics in your script you might want to define them like this:
myResearch[0] RESEARCHSTAT "R-Vehicle-Body11" myResearch[1] RESEARCHSTAT "R-Vehicle-Prop-Tracks" myResearch[2] RESEARCHSTAT "R-Vehicle-Prop-Hover"
This defines an array of size 3 of type RESEARCHSTAT.
Slo files
As already mentioned the .slo file is the heart of every script, it is the place for the executable code. Slo files can be devided into 3 main parts: #Variable declarations #Event and function declaration #Executable code
Variables used throughout the script are defined in the variable declarations part, with exception of the local variables ?.
For the .slo file to be able to access variables declared in the .vlo file they must be declared as public variables in the corresponding .slo file.
Coming back to the two examples above you will have to add the following lines to the .slo file:
public BODY myPythonBody; public RESEARCHSTAT myResearch[3];
The keyword public signals that the variable is defined in the corresponding .vlo files. Note that unlike in .vlo files variable declarations in .slo files end with a semicolon and unlike in .vlo files it is possible to declare more than one variable of the same type at once.
More generally a variable declaration in a .slo file looks like this:
<storage> <variable_type> <variable_name1> [, <variable_name2>, ...];
storage is one of public or private. public means that the variable is declared and defined in the corresponding .vlo file. private means the value is only used in the .slo file. Unlike local variables public and private variables are global variables that can be accessed from anywhere in the .slo file.
Note: All variables are initialized to their default values when created. STRUCTURE/DROID/FEATURE variables are initialized to NULLOBJECT, STRINGs to "", FLOATs to 0.0, INTs to 0, BOOLs to FALSE etc.
Event/trigger concept
In Warzone 2100 scripts executable code consists of events. An event is a list of instructions activated by some trigger attached to it. Event defines what to do, a trigger defines when to run an event, i. e. when to execute the code inside an event.
All events are structured as follows:
event <event_name>(<trigger>)
{
<code>
}
Example:
event myFirstEvent(every, 50)
{
console("Hello world!");
}
This piece of code will output "Hello world!" to the game console every 5 seconds. Note that triggers are put inside the round braces after the event name while code that is to be executed resides inside the curly braces. The syntax of the executable code is very close to the C/C++ syntax.
The only difference between a WZ events and a function as used in programming languages like C/C++ is that an event is not called or activated by another function, but rather by a trigger attached to it.
It is always possible to interrupt execution of an event with the exit keyword, which is a counterpart of the return keyword used for functions; the exit keyword does not deactivate an event.
Example:
event myEvent(every, 10) //run every second
{
console ("this text will be printed every second");
if((gameTime / 10) > 60) //did more than a minute pass?
{
exit; //anything that comes after 'exit' will not be executed
console("this text will only get printed in the first");
}
}
Events must be defined before they can be referenced. If an event definition comes after the place where this event is referenced it is necessary to declare this event beforehand in the event and function declaration section.
Events are declared like this:
event <event_name>;
Such a declaration reserves the event name as an identifier.
Example:
event myEvent; //declaration of the event
...
// another event that references myEvent
event anotherEvent(wait, 10)
{
setEventTrigger(myEvent, inactive); //deactivate myEvent
}
...
// myEvent is defined after being referenced by anotherEvent,
// but it works, since we declared myEvent beforehand
event myEvent(wait, 20)
{
console("It all compiles, because I was declared beforehand!");
}
If myEvent was not declared before being referenced by anotherEvent then this example would not compile.
Triggers
In Warzone 2100 triggers are usually simple timers that repeatedly trigger execution of events, but triggers can also be callbacks (special events that occur in the game, like destruction of a building) that are listed and explained in script function callbacks ?.
Here are the available trigger types:
! Trigger type ! Effect
| wait, <time> | Run the event after delay <time>.
| every, <time> | Run the event at every <time> interval.
| <callback> | Run when callback occurs.
| <bool exp>, <time> | Run the event if <bool exp> is true, checking every <time> interval.
| init | Run the event when the script starts.
| inactive | Do not run the event until a trigger is assigned to it. |} Note: All time intervals are in 1/10 of a second.
For example every, 10 will trigger every second while wait, 50 will only activate once: 5 seconds after the game has started. If an event has inactive assigned as a trigger this event will never execute unless its trigger is reassigned by some other event with setEventTrigger(<event>, <trigger>) function.
Note: Complete lists of all script functions and script function callbacks can be found in the appendices script functions ?, debugging script functions ? and script function callbacks ?.
A few examples:
// 1. output text to game console every second
event everySecond(every, 10)
{
console("The game has started " + gameTime/10 + " seconds ago");
}
// 2. Code inside this event will never execute unless its event is reassigned later
event inactiveEvent(inactive)
{
console("Someone has just reactivated me!");
}
// 3. CALL_NEWDROID callback with parameters
event droidBuilt(CALL_NEWDROID, 5, ref newDroid, ref myFactory)
{
console("We got a new droid at coordinates " &
newDroid.x &
"-" &
newDroid.y);
}
In the last example the event droidBuilt will be triggered every time a factory belonging to player 5 produces a new droid. The variable newDroid refers to the new droid that was just built and myFactory to the factory that produced this droid. This example assumes that newDroid and myFactory were correctly defined in the variable declarations section. For more callbacks see script function callbacks ?.
Note: The ref keyword means that a pointer to the provided variable is passed to the interpreter, so that a callback can modify the value of the variable.
It is possible to reuse a trigger for more than one event if a trigger is declared in the event and function declaration. The declaration of triggers has the following syntax:
trigger <trigger_name> (<trigger>);
Example:
trigger everySecond (every, 10); //trigger declaration
...
event eventOne(everySecond) // uses the trigger we declared above
{
...
}
event eventTwo(everySecond) // uses the trigger we declared above
{
...
}
In this example the everySecond trigger is defined outside of an event. Such a trigger can be reused by its name. Note that the trigger declaration ends with a semicolon.
{{Scripting manual}} Category:Scripting manual ?
