just some ideas i'm thorwoing around to explain the sqs/sqf syntax a little better
Into[ | ]
Ofp Scripting Grammar
Scripts[ | ]
Scripts in OFP are humanly readable text files which, by convention, have a sqs or sqf extension. However, any extension is 'ok', there is no default. When referencing these these scripts, normally via a trigger condition in the mission.sqm, the full extension name (eg "hello.sqs") must be supplied.
sqf[ | ]
sqf are function scripts. Unlike scripts which are read into memory each time they are referenced, a function script is read and compiled. (wasn't much difference in ofp, maybe arma has sorted this out)
Syntax[ | ]
Whitespace[ | ]
Whitespace consists of tabs and/or space characters.
For the
purposes of the
engine
The 'line' begins at the first non whitespace character.
Similarly, trailing whitespace (if any) at the end of a line (or statement;} is also ignored.
In general whitespace is used for legibility, it is often optional in the syntax.
eg:
A = B + C;
and
A=B+C;
are synonmous. One of them reads 'better'.
The engine (like C) interprets tokens up to and including the last character that can make sense.
if(any)then"do something"
will be interpreted correctly, but is a mess for a human to read. The point being, the author of the script needs to separate out 'tokens' to make them humanly understandable.
Syntax2[ | ]
Each line of a script file contains either
- one or more statements
- a comment
- a blank line
Comments[ | ]
Comments begin with the ; (semicolon) character.
; Conventionally
; a semicolon is the first character of the line
; but
; it
; need not be,
; providing only whitespace occurs beforehand
Eg, leading whitespace is ignored.
The Semicolon is also used to separate multiple statements in a line (see below)
Blanklines[ | ]
are lines containing nothing but whitespace. Whitespace can be tabs, or space characters, or, nothing at all.
Blank lines and comments are ignored by the engine.
Statements[ | ]
One or more statements appear in a line
Individual statements IN a line are separated by a semicolon. In fact, the semicolon is mostly overused by authors and is ignored by the engine. It is common to see single line statements ending in a semicolon that in effect, have no effect.
a=1; b=2; c= a + b; exit;
The Statement[ | ]
A statement is any syntactic expression that stands alone.
a = b ;
is a stand alone statement.
a=;
is not.
the formal syntax the engine understands is
a = b + c;
or more formally
Expression= Expression OPERATOR Expression;
operators[ | ]
Operators are 'commands' otherwise known as 'functions'.
GetPos SetPos exit + >=
are operators.
Since many operators return nothing, a common form of the above syntax is
a OPERATOR b;
and, since many operators need only one, or no paramaters
OPERTOR b;
OPERATOR;
Examples.
exit; getpos player
Expressions[ | ]
A = B;
A (and B) are expressions
expressions appearing before the assignment operator (=) is 'odd' for most programmers. However
group player = group leader player
sets the player's group to some value after the =
Literals vs Variables[ | ]
Literal 'expressions' are hard values.
_something=77 _somethingElse="String"
A variable, is '_somethingElse'
_thisVariable= _SomeOtherVariable
Variables are referemces to hard values. Variables do NOT 'contain' a value.
see the assignment operator(=) below for the twists and curls of what a reference is.
Parenthesis ()[ | ]
Parenthesis are used where, either the human, or the engine, could get confused
a = b + (c - d);
Orders of Precedence[ | ]
The standard mathmatical orders of precedence are true for sqs syntax BOMDAS
a = b + c/d
c is divided by d first. Parenthesis , change the precedence, or, can be used when your 'not sure'. Eg an explicit precedence.
a = (b+c)/d
Misuse[ | ]
if (something==anything) then.... if something==anything then...
are synonomous. The Parenthesis are not required. This is a throwback to other programming languages (eg c).
Braces {}[ | ]
Braces are used as an alternative to quotes ("). They are sytactically identical
{This is a "funny" line};
and
"This is a ""funny"" line";
are both identical string statments. The {} reads 'better' in this instance.
However, thru useage, authors 'prefer' the brace, or indicate to themselves with brace, that the enclosed 'string', is, in fact, some form of command, Be it statement or other. Thus a command Parm2 above is
parm1 + {[] Exec "Some statement"};
Strings[ | ]
Strings are enclosed in " (quotes) and / or braces '{' and '}'
The engine treats quotes and braces identically IN PAIRS
{A string is wrong"
"and so is this}
"{this is fine}"
"{and this is not"}
cojoined quotes[ | ]
Like most other languages, to embed a quote IN a string
"an ""embedded"" quote"
double quote PAIRS are used.
"Note that { { braces } } do not have same effect"
Other[ | ]
if and ?[ | ]
the if operator is less robust than the ?
if requires brackets around the boolean condition for multiple expressions
if a > b then ... is ok
if a>b and _anthingElse then ... will fail
in general, it is 'better' (tm) to play safe and always use brackets
if (a>b and _anthingElse) then ...
The which operator (?) does not suffer this limitation, but, for consistency, it too shouldd be bracketed.
Assignment Operator[ | ]
_array = [1,2,3]
The equals assigns a Reference To the literal array after the equals to, a variabale.
variables to NOT contain the 'value'. The contain a reference to the value.
_String1="Hello" _string2=String1
_string2 does NOT contain the 'value' "Hello", it, just like String1 has a reference, a memory pointer to the hard literal "Hello"
This has implications for Arrays
_Array1=[1,2,3] _array2=[4,5,6]
legends[ | ]
use _label to denote variables so that command names, and, fixed variables aren't confused
_thing = SomeCommand "text"
use quotes to intuitively see string types
_unit = a soldier _vehicle = a vehicle _unit(s) = Either a single soldier, or, and array of soldiers _vehicle(s) ditto