SCM language
This article may need to be rewritten. Please help improve this article. The discussion page may contain suggestions. |
It may incorporate nonstandard specifications due to the fact R* hasn't published enough documentation about yet.
On the occasion of the "Grand Theft Auto III 10th Anniversary", after a long period of darkness where we fell about the real scripting language syntax, R* finally treated us (or was it, as it seems, a War Drum Studios sloppy oversight?) by attaching part of its own original source code into the Mobile release, available for iOS and Android devices. A year later, the so-called official compiler, somewhat customized for the sake of convenience, was shipped via the remastered edition of Vice City. As far back as 2001, a snip of some debugging scripts has been already provided with main.sc and debug.sc script files that were allegedly meaningful for a sort of script version checker uncut on debug builds. Nonetheless, many secrets are still unrevealed, thus some stuff cannot be fully documented at the moment, hopefully, and so they can be merely guessed. The .scm format abbreviation is one of countless proofs of such a downside which probably stands for Script Multifile, while .scc might be in turn the short form of Compiled Script. No doubt comes with source files, whose .sc extension is the contraction of Mission Script. Although we have enough information to suppose the currently unknown mysteries of the used language, we still have no safe clue about what was its original denomination. Furthermore, it is a matter of fact that R* developers have been left intact the miss2 executable filename of third generation compilers since the chapter 2. In this connection, we could imagine the newer language is a variant or an evolution of the GTA2script which label, initially referred to as GBHscript, expressly popped up in the ancient documentation by DMA Design Ltd. (at present Rockstar North). On those grounds, we are almost sure to say the name of the scripting language targeting each game with all peculiar but minimal enhancements or regressions is most likely GTA3script (as-is casing) for III, GTAVCscript for Vice City, GTASAscript for San Andreas, GTALCSscript for Liberty City Stories and lastly GTAVCSscript for Vice City Stories. However, it is definitely based on BASIC.
Fundamentals
Comments
Codes are usually self-explanatory for the author but large sources can compromise everyone's management capability, that means some annotation can save much time on the long-term particularly when being stuck trying to understand old stuff which should never happen in the first place, not to mention team mates would certainly blame the original writer on each revision and slow down the completion of cooperative projects. Sometimes, it is also required to temporarily/permanently disable code lines for testing purposes. Fortunately, the language supports the following typologies of comments:
- Line comment, prefixed with // (two forward slashes), which extends till the end of the line. Everything is ignored inside:
// Some comment.
; - Block comment, enclosed with a pair of /* (a slash plus an asterisk) and */ (the other way around), which embodies a circumscribed text area. Several blocks can be nested together:
/* Some /* comment */ . */
.
Delimiters
Conventionally, lines can be splitted into various regions in order to enhance the code legibility through bracket-delimited and/or comma-separated elements. As being pure whitespaces, the opening parenthesis delimiter doesn't necessarily need to match the closing counterpart and viceversa. The only tangible use of separators carried out in public sources is related to inline declaration of multiple variables, text keys of print-commands and SETUP_ZONE_PED_INFO
but codes can be organized to one's liking. Here are some demonstrations:
VAR_INT joeys_buggy, swank_taxi PRINT_NOW (ASUKA) 2000 1 SETUP_ZONE_PED_INFO CHINA DAY (30) 350 600 0 (0 0 0 0) 0
Integers and Floating-points
Numeric values are used extensively throughout the whole script following no particular notation besides the decimal one. The specializing number representation tells whether a literal is an integer or a floating-point value: an appending f
or F
floatifies a number, whose suffix becomes superfluous if a radix point, discerning decimals from integral digits, is supplied. Float parts are alternatively omissible hence a 0 digit is implied if one and only one of them is missing. Literal parsing starts from the minus sign, radix point or number digit and stops at the first non number character after a series of digits, leading and/or trailing an eventual radix point, or float suffix. To sum things up, these values are valid numbers: 1
, -0
, 1f
, -0f
, 1.0
, 1.0f
, 1.
, 1.f
, .0
, .0f
and also 1-2
(ill-formed on basic or compound assignments), 1..2
, 1f2
, producing 1
(1f-2
is ill-formed a priori). In the first Trilogy chapter, the fixed-point format was chosen meaning precision was guaranteed to not get lost if the decimal part wasn't lesser than just one-tenth.
Labels, Text labels and Strings
Thanks to the beneficial code fragmentation, the source is subject to script file inclusions, favouring modularity, and sparse goto branches, involving embedded code blocks diversification. Both kinds of partitioning are accomplished respectively through the specification of:
- Filenames, that is special labels which somehow resemble legit pathnames, starting with any valid pathname character but not containing whitespaces. They are relative to the root path deriving from the .sc extension removal of the main script full path where files are searched in by default:
X:\folder\main
. Subfolders are scanned as well:- Till the first tree level if inside one of the subdirectories:
X:\parent\main\child
; - Till the second tree level if inside one of the parent directories:
X:\parent
orX:\parent\main
; - Indefinitely (unlimited recursion till the maximum path length allowed).
- Till the first tree level if inside one of the subdirectories:
- The .sc extension at the end of filenames is mandatory else an argument mismatch is warned, by contrast the main script can have any extension to which m (multifile) or c (compiled) is appended in the target pathname. Due to a Cd image system limitation, all sorts of filename must be shorter than 20 characters and conventionally they must be free of extra dots for streamed scripts;
- Labels, that is unique identifiers suffixed by a colon which identify a precise location of the source code representing the target position of goto-like, script starter, subroutine or function caller commands:
my_label:
(on a new line). Weirdly enough, they may begin with any character alike filenames or be empty despite being susceptible to the same restrictions of string identifiers whenever passed as arguments but, regardless, must not exceed 39 characters (colon included, yet blanked out) and whereas these are not commands, anything else can follow next to and be inlined so long as a splitting character is inserted.
- Labels store a reference depicting either an absolute address falling within the main script space (including main extensions and generic subscripts) or a relative and negative address pointing to a place of the mission script space or that of a particular streamed script. Albeit addresses are zero-based anyway, it is discouraged to use a
WHILE
construct at or branch by hand to the almost very top of a mission/streamed script file or even communicate between different script spaces with gotos.
That said, labels are basically user-supplied identifiers whose existence is verified. The text label or text string counterpart is not fully compliant to this standard (script names are exempt, for instance) since string identifiers are massively employed as main/mission text keys or whatever referring to an internal resource, which the game handles according to a well-defined associative scheme. As a general rule, these are primarily supposed to be at most 7 characters long and must begin with a letter and never end with a colon or either begin with an underscore or an alphanumeric character in the last Trilogy and Stories chapter where text label variables are supported, provided that here their literals are not valid integer or floating-point numbers taking the precedence over string identifiers on parsing:
LOAD_SPECIAL_CHARACTER 1 eight CUSTOM_PLATE_FOR_NEXT_CAR CAR_TAMPA _FELTCH_ SCRIPT_NAME 99red
In the last Trilogy chapter and nowhere else, longer text labels were introduced, some sort of Pascal strings having a variable length of maximum 40 characters for literals or a fixed length of 16 bytes for variables, twice as big as the shorter text label ones. Speaking of which, it is prohibited to get or handle a longer text label using a variable of shorter length but this one is rather passable to those text label parameters also permitting long-lengthed literals. Notoriously, identifiers length is anything but expensive for readability reasons, in addition they do not even offer the ability to insert whitespaces or other inadmissible characters owing to the by-design absence of delimiting tokens. At this matter, debug texts are sent as 127-character string literals enclosed by double quotes:
SAVE_STRING_TO_DEBUG_FILE "current_wanted_list = "
These quoted strings are, in essence, made up of four text labels aligned to 32 bytes (at the highest power of two possible per parameter) individually accessible as a result of a compiler bug, cause the first character of each literal-only argument is trimmed out as a quotemark – during the line reconstruction phase, the opening and closing quotemarks along with
/
,
(
)
\t
are swapped to A
\0
\xD1
-\xD6
and back again on code generation (the NUL
-terminator at the end of string literals makes them rightmost arguments, ignoring the rest).
Unlike string literals, empty text labels are impracticable though $
alone compiles a NUL
-string identifier in the last Stories chapter[no source] – as reported by some indiscreet speculations, the rearrangement of crucial commands signals a syntax enhancement the language has undergone which sees delimited strings superseding text labels, lowly probable because string constants are still disallowed for multi-type parameters. In San Andreas, text labels are implicitly comparable against NUL
-string identifiers but no syntactical facility accommodates an explicit use.
It's worth noting text labels and string literals are not interchangeable because of their syntactic differences even if they present semantic similarities, moreover text labels do not ever interfere with command names and string constants. A final quirk to note concerning labels as a whole is they are automatically converted to upper case: this obvious evidence proves identifiers and whatnot are all case insensitive with the exemption that string literals are left as-is for remastered game builds.
Data types
Forasmuch as the language obeys the strong typing paradigm, the syntactic elements that denote a value during execution do have fixed data types, most of which are appended as a suffix at variable declaration. Their conspicuous assortment is listed below:
Name | Format | Size | Range | Is main |
Is basic |
Derivative data types | Immediate support |
Variable support |
---|---|---|---|---|---|---|---|---|
NONE | ||||||||
LABEL | String identifier (translated to address) |
1, 2 or 4 | 1 to 38 | Since | ||||
Filename (translated to address or index) |
1 to 19 | |||||||
INT | Signed integer | -2n-1 to 2n-1-1 (where n is 8, 16 or 32) |
✓ | ✓ | VAR_INT, VAR_INT_OPT, LVAR_INT, LVAR_INT_OPT, (Vice City Stories apart) INPUT_INT, OUTPUT_INT |
Since | ||
FLOAT | Q11.4 fixed-point (III only) |
2 | -211 to 211-2-4 | ✓ | ✓ | VAR_FLOAT, VAR_FLOAT_OPT, LVAR_FLOAT, LVAR_FLOAT_OPT, (Vice City Stories apart) INPUT_FLOAT, OUTPUT_FLOAT | ||
IEEE-754 floating-point (packed in Stories) |
1-4 | ±2-126 to ±2127(2-2-23) | ||||||
TEXT_LABEL | String identifier (NUL-terminated) |
8 | 1 to 7 | ✓ | VAR_TEXT_LABEL, VAR_TEXT_LABEL_OPT, LVAR_TEXT_LABEL, LVAR_TEXT_LABEL_OPT, (Vice City Stories apart) INPUT_TEXT_LABEL, OUTPUT_TEXT_LABEL (Vice City Stories only) |
Since | and | |
TEXT_LABEL16 | String identifier (if non variable-only, accepts TEXT_LABEL variables) |
9-41 (Pascal string) |
8 to n (where n is <= 40) |
✓ | VAR_TEXT_LABEL16, VAR_TEXT_LABEL16_OPT, LVAR_TEXT_LABEL16, LVAR_TEXT_LABEL16_OPT |
only | ||
16 | 1 to 15 | |||||||
TEXT_LABEL32 | String identifier (NUL-terminated) |
32 | 1 to 39 (bugged) |
only | ||||
String literal (NUL-terminated) |
32×4 | 1 to 127 | ||||||
INPUT (optional) |
Includes INT and FLOAT | |||||||
Includes TEXT_LABEL (Vice City Stories only) | ||||||||
STRING (internal only) |
Label, Variable name, String constant[*], Text labels, Quoted string |
✓ | ||||||
UNKNOWN |
^ String constants are only compatible with INPUT_INT data type but default constants favour INT regardless.
Immediates and Variables
Data can take the appearance of a few expressions varying from numeric, text label and string literals each of which occupies a certain area of storage with unfixed size. Immediates can also be preserved for later use and therefore reserve space over the private script memory corresponding to a variable. The strongly-typed language property imposes to explicitly declare variables anywhere in the current scope, namely the context inside which they are visible for usage. Sensibly, declarations should figure beforehand but likewise it is allowed for accessing backward declarations. Variables accessible from any location are marked as globals (starting from offset 8 or more, occupying lots of space in the script multifile, up to 64 kibibytes) and their declaration is achieved by prepending the VAR
wording followed by one of the basic data types (multiple declarations of the same type can be inlined), both separated by an in-between underscore:
VAR_INT player scplayer VAR_FLOAT x_float, y_float, z_float VAR_TEXT_LABEL interior_name VAR_TEXT_LABEL16 shop_item
Globals are capable of being selectively marked as saveable using the SAVE_VAR
prefix, in order to restore their value on savegame loading and free generic variables. In Trilogy chapters, if enabled properly in a hacky manner, these are solely common variable declarations with no additional purpose, a plan not gone through. On the other hand, globals declared within the mission context are not visible outside in Stories chapters since they overlap the same space, making a discernment among true and al-most globals. However, there's no exact rule for variable naming apart they must begin with a specific character and never end with a colon just like string identifiers, expanding till a maximum of 39 characters. It's preferable definitions shall not contain operator tokens to prevent any parsing ambiguity plus, most importantly, they must not conflict with string constants and local timers. Nevertheless, text labels and variable names semantics may collide: in this case, the formers have priority over the latters unless a preceding dollar sign is added:
PRINT_BIG TEXTKEY 5000 2 // Compiles a text label literal. PRINT_BIG $textkey 5000 2 // Compiles a text label variable.
Despite variables are freed and zero-initialized at runtime on new/load game or script allocation in broad terms, statistical information are still gathered whenever they are read before being written, besides if they are never read or never written (passing a variable as reference has no effect onto the content). Furthermore, if a variable is set to hold an entity handle (alias unique index) returned by a specific create-command it cannot be assigned to any other entity-command of different kind or none, including the forseeable assignment operations. This restriction propagates on script and function callings as well: starting/streaming the same script or calling the same function multiple times with variables of dissimilar entity types is forbidden if triggers are encountered prior the script or function lexical scope is fetched, in which case entities are explicitly initialized in the form of unreachable code:
{ LVAR_INT fellow_char robbery_car money_bag sanity sanity = 0 IF sanity = -1 CREATE_CHAR PEDTYPE_CIVMALE male01 0f 0f 0f fellow_char CREATE_CAR admiral 0f 0f 0f robbery_car CREATE_OBJECT woodenbox 0f 0f 0f money_bag ENDIF }
Lexical scope
Once a script is launched, a local storage space consisting of a context-dependent set of variables (16+2 in III/Vice City, 32+2 in San Andreas and 40+2 on Mobile, 96+8+2 in Stories) ready for use is also reserved. As opposed to global variables, locals have visibility only inside a particular region of the source code and are preceded by the LVAR
wording at declaration within a nonnestable block embraced by {
and }
:
{ LVAR_INT pickup message_num }
Local names do not override global definitions, they must not collide together otherwise a warn is issued. Beyond user-defined locals, predefined TIMERA
and TIMERB
variables are provided: these timers measures the playing time milliseconds passed since the script beginning but they can be reset just fine. In the last Trilogy chapter, mission locals are mainly static variables starting from index 34 or 42 on Mobile whose space (having a size of 4 kibibytes) is shared among each mission thus being reasonably more abundant in this scenario but, as a side effect, local timers are unavailable. Transferring the control over and above the lexical scope boundaries or to another multiscript leaves the active context and hides local definitions, thereby switching across lexical scopes is bad practice and can lead to unpredictable results if contexts are not strictly equivalent in the variable declarations.
Arrays
Since the last Trilogy chapter, instead of declaring multiple scalar variables of same type, a one-dimensional indexed array can be defined. Each element is accessed through either a zero-based[no source] positive number or a variable index (local-only in Stories) in a subscript expression on assignment or argument passing. On declaration, a pair of square brackets enclose the array size which mustn't be bigger than 255 units:
VAR_INT prop_assets[32] CREATE_FORSALE_PROPERTY_PICKUP -1969.27 282.47 34.6 50000 PROP_3 prop_assets[0]
In sooth, one-based arrays were already supported in the second Trilogy chapter but in a manner which is defective and incomplete: they missed the intrinsic data type, giving no reference point on how to interpret the compiled operands, producing corrupted intermediate code because of fall-through reading. There is no precedent to safely assert that arrays became zero-based later on the language evolution but what is certain is this sort of indexing lines up immediate with variable indices. Oddly, as a result of the uni-dimensionality constraint implementation, a complementary yet nonfactual identifier can follow the closing bracket immediately afterwards with no redundancy notice (i.e. prop_assets[0]anything
). Moreover, scalar variables have an implicit array size of one element which is needlessly accessible and plus the index part of the first element of an array is in turn omissible, everything notwithstanding the misleading declaration. Granted that brackets do not encompass any separator character or identifiers wider than 39 characters, array indices reject string constants but admit local timers.
String constants
Very often, numeric literals express arbitrary values which are far from being self-documenting without descriptive labels belonging to a list of predefined names. These strings or enumerators are guaranteed to store an immutable constant and must forcibly pertain to the required enumeration if passed as arguments unless, if and only if no enumeration is set, the enumeration-free default constants TRUE
/FALSE
, ON
/OFF
, DAY
/NIGHT
or KILLFRENZY
enumerators are supplied:
CHANGE_BLIP_DISPLAY blip1_jm1 BLIP_ONLY flag_car_blip_displayed_jm1 = TRUE
Assignments and comparisons do not suffer such a restriction and, what's more, in case of too long lines (wider than 255 characters) immediates can safely replace string constants to shorten the exceeding length and fall within the limits. Of course, string constants are bound to the same parsing rules as string identifiers but, as being mainly hardcoded, they are just as limitless in length.
During the development stage, the game's map experiences lots of continuous changes that make the management of objects, as a result of having a fixed indexing, pretty awkward without taking into account their bulk amount. In this respect, parameters expecting level objects are able to define the used objects (no more longer than 23 characters) under the hood, bringing them together in a sorted array whose criteria depends on the order of their appearance, something other than the default models which are hardcoded (for peds, cars, weapons, wheels, cutscene objects and the like). A blank, unavailable object is always reserved, shifting ahead each next negated position becoming one-based. Negative indices assure models fit in the used objects array, according to which the runtime matches the right index through a lookup table:
REQUEST_MODEL bridgefuka // First use ever. It compiles -1 from now on. REQUEST_MODEL bridgefukb // First use again. This time it compiles -2. LOAD_ALL_MODELS_NOW CREATE_OBJECT_NO_OFFSET bridgefuka 715.746 -937.908 40.194 damagea CREATE_OBJECT_NO_OFFSET bridgefukb 787.835 -939.24 38.971 damageb
The lack of error-checking requires a meticulous handwriting to avoid script deadlocks at runtime, the reason why default models of which undefined names follow the format NOT_USED%d
(where %d
is a model index from 0 to 299) and level objects are loaded straight from IDE files for Vice City's remastered build. Nonetheless, iterating among several objects can be very expensive for a poorly optimized, rough compiler even on fast machines, not to mention enumerators are likely to collide without specializing prefixes (i.e. SNIPER
camera mode and weapon name, formerly WEAPON_SNIPER
), enough to revert back thereafter.
Assignments and comparisons have no clue about used objects and are therefore not designed to accommodate or implicitly define one on their own, because they are supposed to be strict with the identifier existence as being more prone to work out with variables. This concept somehow extends to those parameters not featuring used objects as a general rule. If an unusual application needs to take place, making use of non-inlined CONSTANT_INT
declarations would hint the compiler to treat unequivocally the specified string constants as used objects, truly defining a new one on the first practical usage wherever it occurs and not yielding an undefined variable error:
CONSTANT_INT cj_pizza_1 CONSTANT_INT cj_pizza_2 VAR_INT food_model1 food_model2 REQUEST_MODEL pizzahigh // -1 food_model1 = cj_pizza_1 // -2 food_model2 = cj_pizza_2 // -3 REQUEST_MODEL food_model1 REQUEST_MODEL food_model2
Any string constant passed in place of an object model compiles a used object indiscriminately assuming no CONSTANT_INT
declaration, also preventing redefinitions towards default constants, enumerators and variable names, does exist. Messing around with frequent compiler tool recompilations can be tedious solely to establish broad, same-indexed or math-related string constants but fortunately, in the last Trilogy chapter, the language offers the opportunity to settle user-supplied default constants for numeric literals using CONST
-prefixed declarations (maximum 39 characters long) which, alike for variables and CONSTANT_INT
s, are backwards accessible:
CONST_INT gf_date_active 1 CONST_FLOAT math_pi 3.1415927 SET_BIT gf_date_flags gf_date_active rad_angle = deg_angle * math_pi rad_angle /= 180.0
Given that default models are also default constants in Stories chapters[no source], default constants and used objects count as pseudoconstants: contrary to what non-default enumerators entail, generic alternatives are favoured on assignment or comparison command matching. It should be pointed out that, due to a critical compiler bug, the high-order word of the value held by any enumerator is unexpectedly discarded on assignment or comparison and that, if set, the 16th bit yields a nonexistent variable error (i.e. THREAT_GANG9
flag) prior Stories chapters, after which a default constant is compiled instead (buggy behaviour) and recognized only if the low-order word represents a value not equal to -1[no source]:
Mission script | Script multifile | |
SET_CHAR_THREAT_SEARCH npc_char THREAT_GANG_GOLFER SET_CHAR_THREAT_SEARCH npc_char THREAT_GANG9 SET_CHAR_THREAT_SEARCH npc_char THREAT_EMERGENCY threat_flag = THREAT_GANG_GOLFER threat_flag = THREAT_GANG9 // Ill-formed in Trilogy. threat_flag = THREAT_EMERGENCY |
SET_CHAR_THREAT_SEARCH npc_char 16384 SET_CHAR_THREAT_SEARCH npc_char 32768 SET_CHAR_THREAT_SEARCH npc_char 65536 SET_VAR_INT_TO_CONSTANT threat_flag 16384 SET_VAR_INT threat_flag 32768 SET_VAR_INT_TO_CONSTANT threat_flag 0 |
This drawback unwittingly affects real code in Liberty City Stories in one circumstance. On a final note, string constants are incompatible with optional arguments and thus taking advantage of a temporary variable would overcome this syntactic limitation.
Operators
As soon as a numeric or text label variable is declared, it can be subjected to algebric operations and/or logical comparisons by virtue of several operators. Their support is sadly very primitive, in fact the ability to establish complex expressions with parentheses and such is not featured albeit one and only binary operation is enabled to follow the basic assignment. In this regard, the variable being assigned to the lvalue cannot be the same as the outer rvalue for non-commutative operations: VAR1 = THING - VAR1
, VAR1 = THING / VAR1
, VAR1 = THING +@ VAR1
and VAR1 = THING -@ VAR1
are all ill-formed (where THING
≠ VAR1
). This issue arises because the explicit usage of a temporary variable is needed which would be harmful for the compiler to waste by itself under the hood, thus here expressions are necessarily made up of distinct two-operand instructions, that is the lvalue content is initialized prior encoding any supplementary rvalue arithmetic:
Mission script | Script multifile | |
VAR1 = 1 - VAR1 // Invalid, cause VAR1 = 1; VAR1 -= VAR1 doesn't make sense. // It would perform 1 - 1 = 0. Workaround needed. VAR1 = 1 / VAR1 // Invalid, cause VAR1 = 1; VAR1 /= VAR1 does no effect. // It would perform 1 / 1 = 1. Workaround needed. VAR1 = 1 - VAR2 // Valid, cause VAR1 = 1; VAR1 -= VAR2 doesn't null itself like above. // It performs x = 1 - y. VAR1 = 1 + VAR1 // Valid, addition (as well as multiplication) is commutative so VAR1 += 1. // It performs x = x + 1. |
NEGATE VAR1 // Unknown command (speculative). It would do x = -x. ADD_THING_TO_THING VAR1 1 ONEOVER VAR1 // Unknown command (speculative). It would do x = 1 / x. MULT_THING_BY_THING VAR1 1 SET VAR1 1 SUB_THING_FROM_THING VAR1 VAR2 ADD_THING_TO_THING VAR1 1 |
The subtraction of positive or negative rvalues necessitates a splitting character in order to discern the infix operator unambiguously, which would be treated as part of the literal or a variable decrement otherwise (i.e. VAR1 = VAR1 -1
or VAR1 = VAR1 --1
). Typically, string constants are not suitable for math calculations because of the lack of matchable alternative commands but even so they are semantically contemplated as long as a non-default enumerator is provided as the inner rvalue of a ternary operation or a default constant or enumerator is passed to any rvalue (i.e. VAR1 = PAD1 + 1
, VAR1 = DAY + 1
or VAR1 = 1 + KILLFRENZY_INITIALLY
). Another clear limitation is prefix and postfix operators do not apply onto arguments, hence there's no concrete differentiation. However, the language introduces the timed addition/subtraction to looply update a variable in a frame-rate independent way, the cast assignment to do a mutual conversion between integers and floats but it doesn't give support for the modulo operation as its predecessor. The inequality comparison was planned but quickly gone obsolete[no source] – availing of the negated form of the equality operator would have sounded more intuitive but one should be aware the not-flag is not bundled with the command index when matching alternative commands. Due to a negligence of the programmers in charge, liable for forgetting some assets of the scripting environment, the local-global in/equality comparison between integer or float variables is not feasible except in the last chapter of Trilogy and Stories series. Surprisingly enough, the basic assignment may prepend ABS
which in so doing would be capable of receiving numeric literals because of the pre-empted rvalue assigning (i.e. VAR = ABS THING
). In principle, SET
is not compiled only if both lvalue and rvalue (whether inner or outer) of a ternary operation or ABS
assignment collide (identity).
Arithmetic operators
Name | Syntax | INT | FLOAT | TEXT_LABEL/16 | |
---|---|---|---|---|---|
Basic assignment | VAR = THING |
✓ | ✓ | ✓ | |
Addition | THING + THING |
✓ | ✓ | ||
Subtraction | THING - THING |
✓ | ✓ | ||
Multiplication | THING * THING |
✓ | ✓ | ||
Division | THING / THING |
✓ | ✓ | ||
Timed addition | THING +@ THING |
✓ | |||
Timed subtraction | THING -@ THING |
✓ | |||
Increment | Prefix | ++ VAR |
✓ | ||
Postfix | VAR ++ | ||||
Decrement | Prefix | -- VAR |
✓ | ||
Postfix | VAR -- |
Compound assignment operators
Name | Syntax | Meaning | INT | FLOAT |
---|---|---|---|---|
Addition assignment | VAR += THING |
VAR1 = VAR1 + THING |
✓ | ✓ |
Subtraction assignment | VAR -= THING |
VAR1 = VAR1 - THING |
✓ | ✓ |
Multiplication assignment | VAR *= THING |
VAR1 = VAR1 * THING |
✓ | ✓ |
Division assignment | VAR /= THING |
VAR1 = VAR1 / THING |
✓ | ✓ |
Timed addition assignment | VAR +=@ THING |
VAR1 = VAR1 +@ THING |
✓ | |
Timed subtraction assignment | VAR -=@ THING |
VAR1 = VAR1 -@ THING |
✓ | |
Cast assignment | VAR =# THING |
AS IS | ✓ | ✓ |
Comparison operators/relational operators
Name | Syntax | INT | FLOAT | TEXT_LABEL/16 |
---|---|---|---|---|
Equal to | VAR = THING |
✓ | ✓ | ✓ |
Not equal to[no source] | VAR <> THING |
✓ | ✓ | |
Greater than | THING > THING |
✓ | ✓ | |
Less than | THING < THING |
✓ | ✓ | |
Greater than or equal to | THING >= THING |
✓ | ✓ | |
Less than or equal to | THING <= THING |
✓ | ✓ |
Logical operators
Name | Syntax |
---|---|
Logical negation | NOT |
Logical conjunction | AND |
Logical disjunction | OR |
Commands
The imperative programming paradigm provides for a conglomerate of commands the script is filled up of and structured in, which are seen as orders to instruct the execution of the relative built-in portion of game code at runtime. Their invocation is faithful to procedure calls: they may feature zero or more parameters (up to 16+ in III\Vice City, 32+ in San Andreas and Stories) of any type or indefinite, depending on whether or not qualified as optional, and receive as much as arguments either by-value or by-reference affecting the read/written access accordingly (do note a pure reference does not initialize anything). Alike procedures, no assignable result is returned but a boolean state is caught anyway on conditional evaluation. One major peculiarity is command names are usually identified by a verb in its imperative form:
GIVE_WEAPON_TO_CHAR mafia_1X WEAPONTYPE_UZI 999
Command names are leftmost identifiers not ending with a colon (not a label) and not preceded or followed by an operator token (not a variable). On code generation, their definition is turned into a 15-bit index reflecting the position the name is matched at in a list of command descriptors and packed with the not-flag stored in the most significant bit, accompained by a known or indeterminate number of typified, somewhat typified or thorougly nontypified operands completing several instructions which are arranged in order to bring forth the intermediate script bytecode. At every command corresponds an output except for variable, string constant and lexical scope declarators or for the classic NOP
(no operation). Operand immediates mainly use the shortest representation for size optimization, yet label references always yield 32-bit addresses.
Game progress rely on many countable stuff to determine the percentage acquired at any given time which are extremely time spending and easily error-prone to quantize manually. Counter-commands come to aid, sort of adaptive counters featuring a possibly zero-valued argument updated automatically during the compilation process that keeps track of the times a few commands are used or of the total sum of some argument value of certain commands, discarding nonimmediates:
Initializer | Dependency | Is addend |
---|---|---|
SET_COLLECTABLE1_TOTAL |
CREATE_COLLECTABLE1 |
|
SET_PROGRESS_TOTAL |
PLAYER_MADE_PROGRESS |
✓ |
SET_TOTAL_NUMBER_OF_MISSIONS |
REGISTER_MISSION_PASSED |
|
REGISTER_ODDJOB_MISSION_PASSED |
||
SET_MISSION_RESPECT_TOTAL |
AWARD_PLAYER_MISSION_RESPECT |
✓ |
Condition-based statements and counter-commands along with the file includers outside of the main script or main extensions, where labels are expected instead of filenames, are mostly parameterized regardless of their own descriptor (the type-check is still done though), while another category consisting of multicommands is able to look for the matching prototype into a list of akin commands on the basis of the data type of the passed arguments and choose, accordingly, the equivalent alternative in a direct and effortless way. Although the alternative commands are also accessible by and can share the same definition, the selection process is not entirely conform to function overloading because these still retain their exclusive name as being plainly resolved through weak aliases. A complete listing is shown below:
Control flows
Insofar as subprograms, scripts are organized in a systematic arrangement through which goto branches, subroutine branches, function calls and returns or cutscene area markers are executed to form control flow statements and structures. These alter the program counter most of the time affecting the top-down order all commands are fetched by. Facing off code duplication is quite recurring especially when the tasks to perform vary only in the input data, the case where a piece of code or subroutine, built once in the source, is invoked many times from various different places and returns back, as if the GOSUB
statement is substituted in-place by the subroutine's body without RETURN
during the control transferring, to shrink long codes and reduce the script overall size. In the last Trilogy chapter, a region of code can be marked as a nonnestable cutscene area wherein the rest of commands within SKIP_CUTSCENE_START..SKIP_CUTSCENE_END
is skipped to the pressure of some key/button at the next script tick. The flow of execution can also be broken up conditionally by means of:
- Decision-making structures (
IF
,IFNOT
,SWITCH
), which evaluate the result of one or more conditions and choose what path to follow based off the trueness or falseness of the check being tested. Been deemed the most basic tool of structured programming,IF
is a bidirectional statement that proceeds with the execution of the underneath code only if the test carried out evaluates to true otherwise it transfers the control next toENDIF
instantly, unless a preceding and optionalELSE
clause, establishing an alternative path, is specified. In the first Trilogy and both Stories chapters whereGOTO_IF_TRUE
is handled by game code, the barely usedIFNOT
can be deployed as a placeholder to easily invert the compare-flag, a boolean state which is set or cleared as a result of the bitwise conjunction or disjunction with the true/false state caught by a condition, applying the inversion according to the presence of the not-flag before accumulating. Logical operators make possible the connection among multiple conditions via theAND
conjunction andOR
disjunction giving the chance to verify if conditions are all true or if just one of them is satisfied bearing in mind that theNOT
negation, inverting the boolean state of a single condition, may be supplied. Connectivity information are held byANDOR
, whose argument depicts a value in the range[1,8)
or[21,28)
(end-inclusive in Stories) for logical conjunction and disjunction respectively, limiting the amount of total conditions to provide to a maximum of 8 per check (the prominent intervals discrepancy also suggestsNAND
andNOR
operators might have been a plan at some point). A value of 0 does nothing relevant functional-wise at runtime, what led developers to not compile said command in such a situation for Stories chapters and also make the argument one-based so that it effectively counts the number of commands used in a multi-condition check. The inability to create subexpressions enforces not to combineAND
withOR
in a check, plus evaluations are eager and therefore not short-circuited meaning all conditions are executed prior potentially branching throughGOTO_IF_FALSE
in the common case after the compare-flag gets processed.IF-GOTO
andIFNOT-GOTO
constructs are also viable to inline a bogus one-way control transferer, targeting an arbitrary location, nearby a one-condition check with no end-ing statement.
- Nesting lots of
IF-ELSE-ENDIF
structures of one-condition checks testing the equality of the same variable against a few integer literals or string constants can add a ridiculous code redundancy and performance overhead, sorted out in the last Trilogy chapter thanks to the introduction of theSWITCH
statement, a multiway statement either branching to the switch section labelled by fall-throughCASE
statements of which one passses a value that shall match the variable content to compare or optionally branching toDEFAULT
in the worst-case scenario, each ending with a nonmandatoryBREAK
statement goto-ing pastENDSWITCH
. On compilation, the implementation somehow mimics the pattern of a jump table sorting case label references by value to fulfil the runtime's binary search among at least 1 of 75 entries (default case aside);
- Looping structures (
WHILE
,WHILENOT
,REPEAT
), which repeatedly execute a block of code certain number of times or by constantly and successfully evaluating a check. The only condition-controlled loop statement featured is the widespreadWHILE
, a cyclicalIF
statement as well asIFNOT
is forWHILENOT
, repeating the embedded code over and over again if the verified check is true or till it becomes false when reachingENDWHILE
. Alongside well-known constructs the language supports a singular count-controlled structure,REPEAT-ENDREPEAT
, looping some code at least once by advancing an integer variable at each iteration until the times specified (literal-only). Despite considered harmful in the programming literature for high-level programming languages, an unconditional branch is the only way to go for breaking loops beforehand and enhance paradoxically the simplistic code logic or for creating infinite loops with a backwardGOTO
.
Control flows intersection is, arguably, trouble-free and it's up to the writer to not ruin the code integrity, but still substatements must match the closest opening statement they belong to. Optimization is not of compiler concern meaning control flows are encapsulated as-is with no code reduction even for empty blocks, resulting in goto-es branching right after or piled up in sequence.
Subroutine structure: GOSUB
GOSUB subroutine COMMAND GOTO somewhere subroutine: COMMAND RETURN
Cutscene area structure: SKIP_CUTSCENE_START and SKIP_CUTSCENE_END
Mission script | Script multifile | |
// Formerly thought as MARK_CUTSCENE_START. SKIP_CUTSCENE_START COMMAND WAIT 0 COMMAND // Formerly thought as MARK_CUTSCENE_END. SKIP_CUTSCENE_END |
// Formerly thought as CUTSCENE_SCROLL? SKIP_CUTSCENE_START_INTERNAL SPECIAL_LABEL_SKIP_CUTSCENE_STARTS_0 COMMAND WAIT 0 COMMAND SPECIAL_LABEL_SKIP_CUTSCENE_STARTS_0: SKIP_CUTSCENE_END |
Decision-making structures: IF and IFNOT
Mission script | Script multifile | |
IF COMMAND COMMAND ELSE COMMAND ENDIF |
ANDOR 0 COMMAND GOTO_IF_FALSE SPECIAL_LABEL_IFS_ELSE_0 COMMAND GOTO SPECIAL_LABEL_IFS_0 SPECIAL_LABEL_IFS_ELSE_0: COMMAND SPECIAL_LABEL_IFS_0: |
Mission script | Script multifile | |
IF COMMAND AND NOT COMMAND COMMAND ENDIF |
ANDOR 1 COMMAND NOT COMMAND GOTO_IF_FALSE SPECIAL_LABEL_IFS_1 COMMAND SPECIAL_LABEL_IFS_1: |
Mission script | Script multifile | |
IFNOT COMMAND OR NOT COMMAND COMMAND ENDIF |
ANDOR 21 COMMAND NOT COMMAND GOTO_IF_TRUE SPECIAL_LABEL_IFS_2 COMMAND SPECIAL_LABEL_IFS_2: |
Mission script | Script multifile | |
IF COMMAND GOTO somewhere |
ANDOR 0 COMMAND GOTO_IF_TRUE somewhere |
Mission script | Script multifile | |
IFNOT COMMAND GOTO somewhere |
ANDOR 0 COMMAND GOTO_IF_FALSE somewhere |
Decision-making structure: SWITCH
Mission script | Script multifile | |
VAR_INT check SWITCH check CASE 0 COMMAND BREAK CASE 1 CASE 3 COMMAND BREAK CASE 2 COMMAND BREAK CASE 4 CASE 6 CASE 5 CASE 7 COMMAND //BREAK ENDSWITCH |
SWITCH_START check 8 FALSE SPECIAL_LABEL_SWITCHES_0 0 SPECIAL_LABEL_SWITCHES_CASE_0_0 1 SPECIAL_LABEL_SWITCHES_CASE_1_0 2 SPECIAL_LABEL_SWITCHES_CASE_2_0 3 SPECIAL_LABEL_SWITCHES_CASE_1_0 4 SPECIAL_LABEL_SWITCHES_CASE_3_0 5 SPECIAL_LABEL_SWITCHES_CASE_3_0 6 SPECIAL_LABEL_SWITCHES_CASE_3_0 SWITCH_CONTINUED 7 SPECIAL_LABEL_SWITCHES_CASE_3_0 -1 SPECIAL_LABEL_SWITCHES_0 -1 SPECIAL_LABEL_SWITCHES_0 -1 SPECIAL_LABEL_SWITCHES_0 -1 SPECIAL_LABEL_SWITCHES_0 -1 SPECIAL_LABEL_SWITCHES_0 -1 SPECIAL_LABEL_SWITCHES_0 -1 SPECIAL_LABEL_SWITCHES_0 -1 SPECIAL_LABEL_SWITCHES_0 SPECIAL_LABEL_SWITCHES_CASE_0_0: COMMAND GOTO SPECIAL_LABEL_SWITCHES_0 SPECIAL_LABEL_SWITCHES_CASE_1_0: COMMAND GOTO SPECIAL_LABEL_SWITCHES_0 SPECIAL_LABEL_SWITCHES_CASE_2_0: COMMAND GOTO SPECIAL_LABEL_SWITCHES_0 SPECIAL_LABEL_SWITCHES_CASE_3_0: COMMAND //GOTO SPECIAL_LABEL_SWITCHES_0 SPECIAL_LABEL_SWITCHES_0: |
Mission script | Script multifile | |
{ LVAR_INT check SWITCH check CASE -2 CASE -1 COMMAND BREAK CASE 1 CASE 2 COMMAND BREAK CASE 0 DEFAULT COMMAND //BREAK ENDSWITCH } |
SWITCH_START check 5 TRUE SPECIAL_LABEL_SWITCHES_DEFAULT_1 -2 SPECIAL_LABEL_SWITCHES_CASE_0_1 -1 SPECIAL_LABEL_SWITCHES_CASE_0_1 0 SPECIAL_LABEL_SWITCHES_DEFAULT_1 1 SPECIAL_LABEL_SWITCHES_CASE_1_1 2 SPECIAL_LABEL_SWITCHES_CASE_1_1 -1 SPECIAL_LABEL_SWITCHES_1 -1 SPECIAL_LABEL_SWITCHES_1 SPECIAL_LABEL_SWITCHES_CASE_0_1: COMMAND GOTO SPECIAL_LABEL_SWITCHES_1 SPECIAL_LABEL_SWITCHES_CASE_1_1: COMMAND GOTO SPECIAL_LABEL_SWITCHES_1 SPECIAL_LABEL_SWITCHES_DEFAULT_1: COMMAND //GOTO SPECIAL_LABEL_SWITCHES_1 SPECIAL_LABEL_SWITCHES_1: |
Looping structures: WHILE and WHILENOT
Mission script | Script multifile | |
WHILE COMMAND COMMAND ENDWHILE |
SPECIAL_LABEL_WHILES_A_0: ANDOR 0 COMMAND GOTO_IF_FALSE SPECIAL_LABEL_WHILES_B_0 COMMAND GOTO SPECIAL_LABEL_WHILES_A_0 SPECIAL_LABEL_WHILES_B_0: |
Mission script | Script multifile | |
WHILE COMMAND AND NOT COMMAND COMMAND ENDWHILE |
SPECIAL_LABEL_WHILES_A_1: ANDOR 1 COMMAND NOT COMMAND GOTO_IF_FALSE SPECIAL_LABEL_WHILES_B_1 COMMAND GOTO SPECIAL_LABEL_WHILES_A_1 SPECIAL_LABEL_WHILES_B_1: |
Mission script | Script multifile | |
WHILENOT COMMAND OR NOT COMMAND COMMAND ENDWHILE |
SPECIAL_LABEL_WHILES_A_2: ANDOR 21 COMMAND NOT COMMAND GOTO_IF_TRUE SPECIAL_LABEL_WHILES_B_2 COMMAND GOTO SPECIAL_LABEL_WHILES_A_2 SPECIAL_LABEL_WHILES_B_2: |
Looping structure: REPEAT
Mission script | Script multifile | |
VAR_INT steps REPEAT 4 steps // 0 or lesser still implies 1 step. COMMAND ENDREPEAT |
SET_VAR_INT steps 0 SPECIAL_LABEL_REPEATS_0: COMMAND ADD_VAL_TO_INT_VAR steps 1 // Here ANDOR is accidentally missing in Trilogy. IS_INT_VAR_GREATER_OR_EQUAL_TO_NUMBER steps 4 GOTO_IF_FALSE SPECIAL_LABEL_REPEATS_0 |
Mission script | Script multifile | |
{ LVAR_INT steps REPEAT 8 steps COMMAND ENDREPEAT } |
SET_LVAR_INT steps 0 SPECIAL_LABEL_REPEATS_1: COMMAND ADD_VAL_TO_INT_LVAR steps 1 IS_INT_LVAR_GREATER_OR_EQUAL_TO_NUMBER steps 8 GOTO_IF_FALSE SPECIAL_LABEL_REPEATS_1 |
Infinite looping structure: backward GOTO
loopstart: WAIT 0 COMMAND GOTO loopstart
Multiscripts
The whole GTA series started as a world subdivided into several levels, each one per urban area spread across fewer cities, albeit 3D era titles has got a single-leveled design covering the entire game scene. Every level is shipped with a main script and a number of ancillary script files, simply called multiscripts, which are bundled inside a folder bearing the same name as the main script filename without extension. The robust scripting engine allows more scripts to cooperate simultaneously at runtime to let writing codes in a multithreading fashion but with no actual concurrency. A script is a unit of execution which, upon starting, is enqueued to a list of active scripts as long as an explicit termination, moving the script back to a list of idle scripts, occurs with TERMINATE_THIS_SCRIPT
while TERMINATE_ALL_SCRIPTS_NAMED
halts all instances of a script if the specified name, definitely unique to avert compiler complains, was ever set by SCRIPT_NAME
. Running scripts are processed sequentially in a non-prioritized order and are paused pending one of the next script ticks using WAIT
to delay the script execution of an instance some milliseconds ahead or at the earliest opportunity if 0.
This section is incomplete. You can help by fixing and expanding it.
Main script and Main extensions
This section is incomplete. You can help by fixing and expanding it.
Scripts and Streamed scripts
This section is incomplete. You can help by fixing and expanding it.
Subscripts and Mission scripts
This section is incomplete. You can help by fixing and expanding it.
Tools
GTAForums: SCRambl, first ever attempt for a now discontinued third-party compiler by Deji
GTAForums: GTA3script Toolchain, second and still work-in-progress attempt for an unofficial compiler by Link2012
External links
GTAForums: Learn GTA3script in Y minutes, tutorial for deep diving into the language in a short time by Link2012
GTA3script Language Specifications, community-based specifications of the language led and maintained by Link2012