Mission Scripting (Overview)

From Grand Theft Wiki
Jump to navigation Jump to search


This article deals with the general overview on the mission scripting in GTA 3D series. Mission scripting is the process of writing scripts: small codes that control many aspects of gameplay. Although most of the game features are hardcoded, still much things could be done via scripting. In fact, every single mission in Grand Theft Auto series comes from the scripts. That is, knowing the format of scripts and having a proper tool, it is possible to change the mission details and even create an absoletely new story plot (although it's considered to be the most complex area in GTA modding, so most often the scripting results in small scripts adding new features in gameplay).


The original mission script probably looked something like this (taken from Vice City debug.sc file):

AND flag_create_car = 1
AND button_press_flag = 0
	IF IS_CAR_DEAD magic_car
		DELETE_CAR magic_car
		IF NOT IS_PLAYER_IN_CAR player magic_car
			DELETE_CAR magic_car
	flag_create_car = 0
	initial_car_selected = 0
	button_press_flag = 1

Easy to read and understand, it is fairly basic so anyone with an idea of basic coding (or maybe even English) can understand it. However, very little code came with the game like that. The majority of the mission script comes in a file called main.scm (although in San Andreas there are alternate mains and external scripts, but they all follow the same basic format - hex codes). Example, for the code:

IF IS_CAR_DEAD magic_car
	DELETE_CAR magic_car

The equivalent in the main.scm would look something like this:

D6 00 04 00 19 01 02 45 0E 4D 00 01 FE 3D 87 02 A6 00 02 45 0E

This is how the beginning of the San Andreas mission script looks like:

Byte data Decompiled data Decompiled data with description
A4 03   09   4D 41 49 4E 00 00 00 00 03A4: 'MAIN' 03A4: name_thread 'MAIN'
6A 01   04   00   04   00 016A: 0 0 016A: fade 0 time 0
2C 04   05   93 00 042C: 147 042C: set_total_missions_to 147
0D 03   05   BB 00 030D: 187 030D: set_max_progress 187

Script instructions

A SCM file itself is a bytecode containing instructions telling to the game what to do. An instruction consist of an opcode and its parameters (if there are any). Sometimes the whole script instruction is called opcode.


Template:This Each script instruction is represented by a number called operation code which is implemented using an 16 bit unsigned integer. By this number the game engine identifies an action to perform. Say, opcode 0001 tells to wait for amount of time, 0003 shakes the camera, 0053 creates a player, etc.

This is how an opcode 0001 looks in a scm file:

0100 04 00
  • First part is the opcode number in a little-endian format.
  • Second part is the data type
  • Third part is a parameter value

When a mission script is disassembled, opcodes are written in a human-readable format. The example above will look something like this:

wait 0

This is made for the end-user convenience only. The game does not know what the word wait means, but it knows what the opcode 0001 is, so when a mission script is assembled the commands are written back in raw byte form.

As it has been said, an opcode is UINT16 number. It means the minimum opcode is 0000 and maximum opcode is 0xFFFF. However due to a specific of the SCM language, any numbers above 0x7FFF denote negative conditional opcodes. More on this read there. The original unmodded game supports a way smaller amount of opcodes (maximum 0A4E for San Andreas), but there are tools adding new ones, most notably CLEO library.

After an opcode number the data types and parameter values follow[*].

Data types

Data type is a single byte written before any parameter[*]. The purpose of it is to tell to the game how much bytes to read next and what kind of data it is.

Data type Parameter Length
Game Description
00 0 GTA III GTA Vice City GTA San Andreas end of argument list (004F, 0913 and similar)[*]
01 4 GTA III GTA Vice City GTA San Andreas immediate 32 bit signed int
02 2 GTA III GTA Vice City GTA San Andreas global int/float var
03 2 GTA III GTA Vice City GTA San Andreas local int/float var
04 1 GTA III GTA Vice City GTA San Andreas immediate 8 bit signed int
05 2 GTA III GTA Vice City GTA San Andreas immediate 16 bit signed int
06 4 GTA III GTA Vice City GTA San Andreas immediate 32 bit float
07 6 GTA San Andreas global int/float var array[*]
08 6 GTA San Andreas local int/float var array[*]
09 8 GTA San Andreas immediate 8 byte string[*]
10 2 GTA San Andreas global 8 byte string var
11 2 GTA San Andreas local 8 byte string var
12 6 GTA San Andreas global 8 byte string var array[*]
13 6 GTA San Andreas local 8 byte string var array[*]
14 1+x GTA San Andreas immediate varlen string - first you read 1 byte which gives you length of the rest which is text[*]
15 16 GTA San Andreas immediate 16 byte string[*]
16 2 GTA San Andreas global varlen string var
17 2 GTA San Andreas local varlen string var
18 6 GTA San Andreas global varlen string var array[*]
19 6 GTA San Andreas local varlen string var array[*]
>31 8 GTA III GTA Vice City immediate 8 byte string[*]

As it might be seen from the table two bytes 02 00 could have 3 different meanings as a parameter: if it's preceeded by a data type of 2 it is a global variable ($2), data type of 3 – local variable (2@), data type of 5 - 16-bit number (2), so only the data type allows the game to determine the correct parameter meaning.

Data types for Liberty City Stories and Vice City Stories are much different. First of all, many data types itself denote an immediate value. For example, data type 01 is a value of 0, data type 02 - 0.0, etc. The floating-point values are packed (1, 2 or 3 bytes of length instead of common 4). Some data types itself are the names of variables.

Data type Parameter Length
Game Description
00 0 GTA Liberty City Stories GTA Vice City Stories end of argument list[*]
01 0 GTA Liberty City Stories GTA Vice City Stories 0
02 0 GTA Liberty City Stories GTA Vice City Stories 0.0
03 1 GTA Liberty City Stories GTA Vice City Stories packed float[*]
04 2 GTA Liberty City Stories GTA Vice City Stories packed float[*]
05 3 GTA Liberty City Stories GTA Vice City Stories packed float[*]
06 4 GTA Liberty City Stories GTA Vice City Stories immediate 32 bit signed int
To get the value of a packed float, read the needed amount of bytes (1, 2 or 3) from a scm to a byte[4] array starting from the 3rd, 2nd or 1st element of it respectively. 0 byte of the array is always empty. Then cast this array as a float and that's it.


The game engine knows amount of parameters for each opcode (1 for 0001, 2 for 0004, 13 for 014B, etc). If the script contains another number of parameter it causes a crash.

The parameters could be one of following kinds:


Strings are the sequences of symbols. Those including letters, numbers, some other chars like underscore or at-sign. GTA has no limits on what symbols could or could not be used in the strings. Also, no matter with what symbol a string begins. It could be any, even a space.

There are two kinds of the strings used.

Short string. This is the most common type of a string, that is used in every game since GTA III. The term short means that this string is strongly limited to its length. Maximum symbols it could contain is 7 and the last one (8th) is a null terminator byte. When compiled such strings occupy 8 bytes of a SCM file no matter if the string is actually shorter (the rest of bytes is filled with zero bytes). 
SA scripting engine also has data type 15 that denotes the short string containing up to 15 symbols. This kind of strings is only supported by Sanny Builder. They are handled in a same manner as 8-bytes strings, but occupy 16 bytes of a SCM file.
String Equivalent in SCM
'MAIN' 09   4D 41 49 4E 00 00 00 00
'MODDING' 09   4D F4 44 49 4E 47 00
'SAVE_YOUR_SOULS!' 0F   53 41 56 45 5F 4F 55 52 5F 53 4F 55 4C 53 21 00
Long string. This type was first introduced in San Andreas. Maximum length depends on the opcode[*]. 


Native arrays support was introduced in GTA SA, however there were different implementations of arrays in Vice City. In SA SCM arrays are assembled as 2 UINT16s and 2 bytes:
2b - UINT16 - array offset[*]
2b - UINT16 - array index[*]
1b - BYTE   - array size
1b - BYTE   - flags[*]
An array offset basically is a variable number. If it's a global array, the offset is a global variable index from which the array begins. For example, if the global array offset is 150 (96 00) it means that the first element of the array is $150, the second one is $151, etc. Same valid for the local arrays (offset is a local variable index). 
An array index is a variable number (global or local one) that holds the value of array index. For example, if array index is 3 (03 00), the game will read either global variable $3 or local variable 3@ depending on the flags. This variable holds the number which is array element ID to work with. For example, if the array index is $3, and $3 holds number 5, the game will read 5th element of the array.
0x0 - integer array with local variable as index 0x80 - integer array with global variable as index
0x1 - float array with local variable as index 0x81 - float array with global variable as index
0x2 - short string array with local variable as index 0x82 - short string array with global variable as index
0x3 - long string array with local variable as index 0x83 - long string array with global variable as index
Array Equivalent in SCM
$150(3@,6f) 07   96 00 03 00 06 01
10@(9@,5s) 0D   0A 00 09 00 05 02


In GTA III and GTA Vice City short strings (8 bytes) have no data type preceeding it. If the byte does not fit data type range (0..6 for GTA III and GTA Vice City), it's recognized as a beginning of a string and next 8 bytes are read.
Some opcodes have variable amount of parameters. Most known opcode is 004F that creates a new thread and passes arguments to it. The number of such parameters could vary, so the special data type denotes the end of parameters.

The maximum amount of parameters for any opcode is 16 for GTA III and GTA Vice City, 32 for GTA San Andreas.

GTA San Andreas Opcode 05B6 is a special opcode that  defines a table. Immediately after opcode number the stream of data (128 bytes) follow, without a data type.

Cracking the SCM

As has been said, very little of the code was supplied with the game in a decompiled state (only two small files, both test scripts), so how, as asked, do we create our own scripts based on the original? With a decompiler - but how do these work (no decompilers have been provided by Rockstar).

The original SCM format was cracked shortly after the release of GTA III (the first game to use this mission coding method), with people having to first figure out what all the sections did (there are 5 segments is an SCM - memory, objects, mission defines, MAIN and missions (GTA San Andreas has more, but only one of these (global variables) has had its use determined), where they started/ended etc, figuring out how many parameters each OpCode had and a lot more. Once this was done, they knew where each OpCode began and ended, so they could split them up to make it more readable, but the data on what each one does was lost in the compiling, so they still only had something that looked like this:

0001: 0?
00D6: 0?
0256: 4??
004D: ££label67B3A7

That doesn't still doesn't mean a lot though, so people had to try figure out what the different OpCodes meant.

(Note: this code is in early Mission Builder format:

:labelxxxxxx means this code was originally at this offset in the mission script (the 'label' is added in by the decompiler)
x? means a one byte number
x?? means a variable stored at this offset from the start
££labelxxxxxx is a reference to a label (i.e. for if we wanted to 'jump' to a label))

Some were easy, the very first line of a decompiled script (besides decompiler headers) looks something like:

0002: ££label0034B2

The only parameter this command has is a reference to a label, so this is most likely (and in fact is) a jump statement, so we know all 0002s are jumps. Of course, finding what OpCodes do (and in fact finding the original number of parameters took a while to confirm) takes time, you have to have an idea first and then have to test your theory - many OpCodes have still not been named, but with the amount of OpCodes discovered so far, we have a general idea on what the mission script does.

Once the mission script had been cracked, people could write programs to read through it and output it in a form we could understand (based on a format of opcodes, text to say what they do and a list of parameter values - nothing like the original - the opcodes are needed to determine which opcode it is, the describing text is completely ignored). Originally there were two main decompilers, BWME (User:Barton Waterduck's Mission Editor) and User:CyQ's disassembler, each with their own compilers (to compile the decompiled code back into an SCM file). BWME quickly became the most commonly used, especially among newer coders, probably due to the fact that the parameters were inter-mixed with the code, so you had something like:

<source lang="scm">00B1: is_car $car in_cube $lowerx $lowery $lowerz $upperx $uppery $upperz 0</source>

As opposed to the gtaMa/DisAsm format:

<source lang="scm">is_car_in_cube $car, $lowerx, $lowery, $lowerz, $upperx, $uppery, $upperz, 0</source>

(also note the lack of OpCode in the second example, this builder uses a lookup to find the opcode (if the function is known) instead of just quoting it)

Although you can't see much difference with that example, it can make a lot of difference. Since Barton left the modding community, User:Seemann created an even more versatile decompiler, the Sanny Builder. It has become the most popular mission builder.

The Tools

There are three main builders for GTA III, GTA Vice City, and GTA San Andreas, and one for GTA Liberty City Stories and GTA Vice City Stories.

Mission Builder

(BWME - note: although BWME was a slightly different tool, I shall be referring to this as that):

This tool uses only OpCodes to compile the code, all the text on the line is ignored. Traditionally, it decompiles to a file called main.scm.txt, which is just a big text file with all the code in it, expanded to be readable. This tool is used by the vast majority of mission coders as it is the most abundant and as most source code online is written for it, most people use it, the more people use it, the more code there is for it, so the more people use it.

Code format

Early builders used data type identifiers on all numbers, these were

? - small int (data type 04)
& - medium int (data type 05)
&& - big int (data type 01)
££ - global jump (data type 01)
£ - mission jump (data type 01 - negative addressing)
! - integer (data type 06)
$ - global variable (data type 02)
@ - local variable (data type 03)
?? - DMA global variable (like a global variable, only its memory position is its name, not assigned to it - data type 02)
: - label (text directly after used to reference this label in jumps)
"" - string (no data type, first 8 bytes after opcode when compiled)
# - model identifier (means you can enter the id name of a model rather than the number - data type 05 for the compiled number)

Later versions of the builder got rid of number type definitions, assigning types based on the size of the number. Integers were made integers by being not a whole number (e.g. 10.5 or 10.0 if you want a whole number defined as an integer). They also replaced DMA variables with global variables where the name was the hex address in decimal divided by 4 (each variable uses 4 bytes of memory).

Widely used.
Commands related to the parameters.
Macros and program execution facilities inbuilt.
Creator retired (no future updates / bug fixes).
Decompilation bugs (especially in certain advanced jumps).
Many unofficially usable SCM features uncatered for (although these are mostly advanced problems never experienced by the average coder).
Inconvenient syntax.
Other notes
Compiler inbuilt.


This is still very much in the development stages, it is the first user made high-level scripting tool (in fact, first high-level at all, even Rockstar's compiler is only an advanced parser) made for coding GTA. Originally developed for VC/III, this tool has been expanded to work for all three 3D games. One major disadvantage to this is that the file headers it writes, while readable by the game, are unrecognized by any line by line decompilers. So once a file has been compiled in Point, it cannot be decompiled again by another tool to see the exact generated code.

Sanny Builder

Another new tool by User:Seemann. This is being developed for SA initially (although porting to other games may be an option) and is loosely based on BWME code. It was originally created using the SAscm.ini file from BWME 0.33 GTA San Andreas but has since been expanded to include many different features, some taken from Gtama, some new (such as a basic class system and direct HEX input (as requested by Y_Less)). This tool is still being developed and has now introduced a basic class system so you can do things such as "player.health += 5", this system is also being adapted for point.

The code format is based on a combination of both Gtama and BWME formats, although you can't force data types as you could in early Mission Builders (e.g. 0004: $var = 0&& which would normally be assigned one byte, not four).

Code format (note these are for SA, not VC as the others listed are)
$ - global variable
s$ - global string variable
v$ - global long string variable
@ - label (text directly AFTER used to reference this label in jumps)
@ - local variable (number BEFORE denotes variable)
@s - local string variable (number BEFORE denotes variable)
@v - local long string variable (number BEFORE denotes variable)
'...' - string (first 8 bytes after opcode when compiled)
"..." - debug string text
# - model identifier (means you can enter the id name of a model rather than the number)


(GTA Mission Assembler - gtaMa, Vice City Disassembler - DisAsm):

These tools use one word commands, although they may consist of multiple words concatenated by an underscore ("_"), e.g. is_player_defined. They still compile each line as-is (i.e. no interpretation or code generation) so the game will execute exactly the commands you enter. This is similar to programming in ASM mnemonics, whereas BWME is more similar to machine code. The decompiled file is split up into a number of .gsr files, each one containing the code to one mission. This reduces file sizes considerably as BWME generated files are huge (around 6 MB .txt files), containing the whole code. The code is in the format of a command, followed by a list of parameters, separated by spaces - this can make named variables easy to distinguish from commands.

The disassembler (DisAsm) is written by CyQ and the assembler (gtaMa) is written by Dan Strandberg. These two tools work together to de- and re-compile the code.

Code format
$ - global variable (data type 02)
! - local variable (data type 03)
@ - label (text directly after used to reference this label in jumps)
"" - string (no data type, first 8 bytes after opcode when compiled)
% - model identifier (means you can enter the id name of a model rather than the number - data type 05 for the compiled number)
Small files sizes.
Clearer code - data and commands separated.
Active creator (although no longer developing).
More support for advanced features (supports memory hacking methods not widely used).
Open source.
Online updateable ini.
Format used on custom error handler for VC.
Not widely used.
Code spread across multiple files - harder for searching.
Data not easily related to code.
Other notes
Command line based.

This page is licensed under the GNU Free Documentation Licence. This page has a separate license to the CC-BY-SA that applies to most of Grand Theft Wiki.

The full text of the GNU FDL v1.2 is here. Click the "History" button to see the full list of authors. See Grand Theft Wiki:Copyright for more detail on our copyright policy.

GNU Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
See Grand Theft Wiki:Copyright for more information.