|
|
(22 intermediate revisions by 3 users not shown) |
Line 1: |
Line 1: |
− | {{This|This article handles the scripting technology and background for the [[GTA 3]] game series (including [[GTA LCS]] and [[GTA VCS]]). It does not cover [[GTA IV]].<br> | + | {{This|This article deals with the general overview on the mission scripting in GTA 3D series (including [[GTA LCS]] and [[GTA VCS]]). It does not cover [[GTA IV]].<br> |
| For more information about the GTA IV script read the article about the [[SCO|SCO format]].}} | | For more information about the GTA IV script read the article about the [[SCO|SCO format]].}} |
− | {{Cleanup-rewrite}}{{TocRight}}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 [[Mission Scripting Tools|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). | + | {{Cleanup-rewrite}} |
| | | |
| + | '''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 [[Mission Scripting Tools|proper tool]], it is possible to change the original missions or even create an absoletely new story plot (although scripts is [[Design Your Own Mission|not the only option]] for the latter). |
| + | __TOC__ |
| == Introduction == | | == Introduction == |
| The original mission script is looked like this{{ref|src|[*]}} (taken from Vice City debug.sc file): | | The original mission script is looked like this{{ref|src|[*]}} (taken from Vice City debug.sc file): |
Line 33: |
Line 35: |
| | | |
| This is how the beginning of the [[SA SCM|San Andreas mission script]] looks like: | | This is how the beginning of the [[SA SCM|San Andreas mission script]] looks like: |
− | {| | + | {| class="wikitable" |
| !width="250px"|Byte data | | !width="250px"|Byte data |
| !width="250px"|Decompiled data | | !width="250px"|Decompiled data |
| !width="250px"|Decompiled data with description | | !width="250px"|Decompiled data with description |
| |- | | |- |
− | | {{Hint|A4 03|opcode}} {{hint|09|data type}} {{hint|4D 41 49 4E 00 00 00 00|parameter value}}||03A4: 'MAIN'||[[03A4]]: name_thread 'MAIN' | + | | {{hint|A4 03|opcode}} {{hint|09|Data type}} {{hint|4D 41 49 4E 00 00 00 00|Parameter value}}||03A4: 'MAIN'||[[03A4]]: name_thread 'MAIN' |
| |- | | |- |
− | | {{Hint|6A 01|opcode}} {{hint|04|data type}} {{hint|00|parameter value}} {{hint|04|data type}} {{hint|00|parameter value}}||016A: 0 0||[[016A]]: fade 0 time 0 | + | | {{hint|6A 01|opcode}} {{hint|04|Data type}} {{hint|00|Parameter value}} {{hint|04|Data type}} {{hint|00|Parameter value}}||016A: 0 0||[[016A]]: fade 0 time 0 |
| |- | | |- |
− | | {{Hint|2C 04|opcode}} {{hint|05|data type}} {{hint|93 00|parameter value}}||042C: 147||[[042C]]: set_total_missions_to 147 | + | | {{hint|2C 04|opcode}} {{hint|05|Data type}} {{hint|93 00|Parameter value}}||042C: 147||[[042C]]: set_total_missions_to 147 |
| |- | | |- |
− | | {{Hint|0D 03|opcode}} {{hint|05|data type}} {{hint|BB 00|parameter value}}||030D: 187||[[030D]]: set_max_progress 187 | + | | {{hint|0D 03|opcode}} {{hint|05|Data type}} {{hint|BB 00|Parameter value}}||030D: 187||[[030D]]: set_max_progress 187 |
| |} | | |} |
− |
| |
− | == Script instructions ==
| |
− | A [[SCM]] file itself is a [[Wikipedia:Bytecode|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.
| |
− |
| |
− | === Opcode ===
| |
− | {{This|This section deals with the technical information on the opcode format. For the opcodes documentation see [[:Category:OpCodes|Opcodes]]}}
| |
− | Each script instruction is represented by a number called [[Wikipedia:Opcode|operation code]] which is implemented using an [[Wikipedia:UINT16|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:
| |
− | {{Hint|0100|opcode}} {{hint|04|data type}} {{hint|00|parameter value}}
| |
− |
| |
− | * First part is the opcode number in a [[Wikipedia:Endianness|little-endian]] format.
| |
− | * Second part is the [[#Data types|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 [[Conditional statement|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|CLEO library]].
| |
− |
| |
− | After an opcode number the data types and parameter values follow{{Ref|05B6|[*]}}.
| |
− |
| |
− | === Data types ===
| |
− | Data type is a single byte written before any parameter{{ref|vcstr|[*]}}. The purpose of it is to tell to the game how much bytes to read next and what kind of data it is.
| |
− | {|{{Prettytable}} class=collapsible
| |
− | !Data type (hex)
| |
− | !Arg.<br/>length
| |
− | !colspan=3|Game
| |
− | !Description
| |
− | |-
| |
− | !colspan=6|Typified
| |
− | |-valign=top
| |
− | |00||0||{{icon|3}}||{{icon|vc}}||{{icon|sa}}||End of argument list (EOAL, [[004F]] or [[0913]] and similar){{ref|partype0|[*]}}
| |
− | |-valign=top
| |
− | |01||4||{{icon|3}}||{{icon|vc}}||{{icon|sa}}||<div class="NavFrame collapsed"><div class="NavHead">Immediate 32-bit signed int
| |
− | </div><div class="NavContent"><source lang="c">union UType { char m_cByte; short m_sWord; int m_iDWord; float m_fFloat; char m_szShort[8]; char m_szLong[16]; m_szVarlen[256]; } unValue;</source></div></div>
| |
− | <source lang="c">unValue.m_iDWord = *(int *)&paucScriptBuffer[iIp];
| |
− | iIp += 4;</source>
| |
− | |-valign=top
| |
− | |02||2||{{icon|3}}||{{icon|vc}}||{{icon|sa}}||Global integer/floating-point variable
| |
− | <source lang="c">usGlobalOffset = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |03||2||{{icon|3}}||{{icon|vc}}||{{icon|sa}}||Local integer/floating-point variable
| |
− | <source lang="c">usLocalId = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |04||1||{{icon|3}}||{{icon|vc}}||{{icon|sa}}||Immediate 8-bit signed int
| |
− | <source lang="c">unValue.m_cByte = paucScriptBuffer[iIp++];</source>
| |
− | |-valign=top
| |
− | |05||2||{{icon|3}}||{{icon|vc}}||{{icon|sa}}||Immediate 16-bit signed int
| |
− | <source lang="c">unValue.m_sWord = *(short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |06||4||||{{icon|vc}}||{{icon|sa}}||Immediate 32-bit floating-point
| |
− | <source lang="c">unValue.m_fFloat = *(float *)&paucScriptBuffer[iIp];
| |
− | iIp += 4;</source>
| |
− | |-valign=top
| |
− | |06||2||{{icon|3}}||||||Immediate 16-bit fixed-point
| |
− | <source lang="c">unValue.m_fFloat = (float)(*(unsigned short *)&paucScriptBuffer[iIp]) / 16.0f;
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |07||6||||||{{icon|sa}}||Global integer/floating-point array{{ref|varray|[*]}}
| |
− | <source lang="c">usArrayGlobalOffset = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | usArrayIndex = *(unsigned short *)&paucScriptBuffer[iIp + 2];
| |
− | usArraySize = paucScriptBuffer[iIp + 3];
| |
− | usArrayFlag = paucScriptBuffer[iIp + 4];
| |
− | iIp += 6;</source>
| |
− | |-valign=top
| |
− | |08||6||||||{{icon|sa}}||Local integer/floating-point array{{ref|varray|[*]}}
| |
− | <source lang="c">usArrayLocalId = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | usArrayIndex = *(unsigned short *)&paucScriptBuffer[iIp + 2];
| |
− | usArraySize = paucScriptBuffer[iIp + 3];
| |
− | usArrayFlag = paucScriptBuffer[iIp + 4];
| |
− | iIp += 6;</source>
| |
− | |-valign=top
| |
− | |09||8||||||{{icon|sa}}||Immediate 8-byte string{{ref|str8|[*]}}
| |
− | <source lang="c">strcpy(unValue.m_szShort, &paucScriptBuffer[iIp]);
| |
− | iIp += 8;</source>
| |
− | |-valign=top
| |
− | |0A||2||||||{{icon|sa}}||Global 8-byte string variable
| |
− | <source lang="c">usGlobalOffset = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |0B||2||||||{{icon|sa}}||Local 8-byte string variable
| |
− | <source lang="c">usLocalId = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |0C||6||||||{{icon|sa}}||Global 8-byte string array{{ref|varray|[*]}}
| |
− | <source lang="c">usArrayGlobalOffset = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | usArrayIndex = *(unsigned short *)&paucScriptBuffer[iIp + 2];
| |
− | usArraySize = paucScriptBuffer[iIp + 3];
| |
− | usArrayFlag = paucScriptBuffer[iIp + 4];
| |
− | iIp += 6;</source>
| |
− | |-valign=top
| |
− | |0D||6||||||{{icon|sa}}||Local 8-byte string array{{ref|varray|[*]}}
| |
− | <source lang="c">usArrayLocalId = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | usArrayIndex = *(unsigned short *)&paucScriptBuffer[iIp + 2];
| |
− | usArraySize = paucScriptBuffer[iIp + 3];
| |
− | usArrayFlag = paucScriptBuffer[iIp + 4];
| |
− | iIp += 6;</source>
| |
− | |-valign=top
| |
− | |0E||1+x||||||{{icon|sa}}||Immediate variable-length string{{ref|str16|[*]}}
| |
− | <source lang="c">iLength = paucScriptBuffer[iIp++];
| |
− | strncpy(unValue.m_szVarlen, &paucScriptBuffer[iIp], iLength);
| |
− | iIp += iLength;</source>
| |
− | |-valign=top
| |
− | |0F||16||||||{{icon|sa}}||Immediate 16-byte string{{ref|sa16|[*]}}
| |
− | <source lang="c">strcpy(unValue.m_szLong, &paucScriptBuffer[iIp]);
| |
− | iIp += 16;</source>
| |
− | |-valign=top
| |
− | |10||2||||||{{icon|sa}}||Global 16-byte string variable
| |
− | <source lang="c">usGlobalOffset = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |11||2||||||{{icon|sa}}||Local 16-byte string variable
| |
− | <source lang="c">usLocalId = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |12||6||||||{{icon|sa}}||Global 16-byte string array{{ref|varray|[*]}}
| |
− | <source lang="c">usArrayGlobalOffset = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | usArrayIndex = *(unsigned short *)&paucScriptBuffer[iIp + 2];
| |
− | usArraySize = paucScriptBuffer[iIp + 3];
| |
− | usArrayFlag = paucScriptBuffer[iIp + 4];
| |
− | iIp += 6;</source>
| |
− | |-valign=top
| |
− | |13||6||||||{{icon|sa}}||Local 16-byte string array{{ref|varray|[*]}}
| |
− | <source lang="c">usArrayLocalId = *(unsigned short *)&paucScriptBuffer[iIp];
| |
− | usArrayIndex = *(unsigned short *)&paucScriptBuffer[iIp + 2];
| |
− | usArraySize = paucScriptBuffer[iIp + 3];
| |
− | usArrayFlag = paucScriptBuffer[iIp + 4];
| |
− | iIp += 6;</source>
| |
− | |-
| |
− | !colspan=6|Untypified
| |
− | |-valign=top
| |
− | |N/A||8||{{icon|3}}||{{icon|vc}}||||Immediate 8-byte string{{ref|vcstr|[*]}}
| |
− | <source lang="c">strcpy(unValue.m_szShort, &paucScriptBuffer[iIp]);
| |
− | iIp += 8;</source>
| |
− | |}
| |
− |
| |
− | As it might be seen from the table two bytes <code>{{hint|02 00|little-endian format}}</code> could have 3 different meanings as a parameter: if it's preceeded by a data type of 02 it is a global variable (<span style="color:blue">$2</span>), data type of 03 - local variable (<span style="color:blue">2@</span>), data type of 05 - 16-bit number (<span style="color:maroon">2</span>), 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 the value 0.0, etc. Floating-point values are packed (1, 2 or 3 bytes of length instead of the [[Wikipedia:IEEE_754-1985#Single-precision_32-bit|common 4]]). Some data types itself are somewhat the identifier of a variable.
| |
− |
| |
− | {|{{Prettytable}} class=collapsible
| |
− | !Data type (hex)
| |
− | !Arg.<br/>length
| |
− | !colspan=2|Game
| |
− | !Description
| |
− | |-
| |
− | !colspan=5|Typified
| |
− | |-valign=top
| |
− | |00||0||{{icon|lcs}}||{{icon|vcs}}||End of argument list (EOAL)
| |
− | |-valign=top
| |
− | |01||0||{{icon|lcs}}||{{icon|vcs}}||<div class="NavFrame collapsed"><div class="NavHead">Immediate 8-bit signed integer constant 0 </div><div class="NavContent"><source lang="c">union UType { char m_cByte; short m_sWord; int m_iDWord; float m_fFloat; char m_szString[8] } unValue;</source></div></div>
| |
− | <source lang="c">unValue.m_cByte = 0;</source>
| |
− | |-valign=top
| |
− | |02||0||{{icon|lcs}}||{{icon|vcs}}||Immediate 8-bit floating-point constant 0.0
| |
− | <source lang="c">unValue.m_fFloat = 0.0;</source>
| |
− | |-valign=top
| |
− | |03||1||{{icon|lcs}}||{{icon|vcs}}||Immediate 8-bit packed floating-point
| |
− | <source lang="c">unValue.m_iDWord = paucScriptBuffer[iIp++] << 24;</source>
| |
− | |-valign=top
| |
− | |04||2||{{icon|lcs}}||{{icon|vcs}}||Immediate 16-bit packed floating-point
| |
− | <source lang="c">unValue.m_iDWord = *(unsigned short *)&paucScriptBuffer[iIp] << 16;
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |05||3||{{icon|lcs}}||{{icon|vcs}}||Immediate 24-bit packed floating-point
| |
− | <source lang="c">unValue.m_iDWord = (*(unsigned short *)&paucScriptBuffer[iIp] << 16) | (paucScriptBuffer[iIp + 2] << 8);
| |
− | iIp += 3;</source>
| |
− | |-valign=top
| |
− | |06||4||{{icon|lcs}}||{{icon|vcs}}||Immediate 32-bit signed integer
| |
− | <source lang="c">unValue.m_iDWord = *(int *)&paucScriptBuffer[iIp];
| |
− | iIp += 4;</source>
| |
− | |-valign=top
| |
− | |07||1||{{icon|lcs}}||{{icon|vcs}}||Immediate 8-bit signed integer
| |
− | <source lang="c">unValue.m_cByte = paucScriptBuffer[iIp++];</source>
| |
− | |-valign=top
| |
− | |08||2||{{icon|lcs}}||{{icon|vcs}}||Immediate 16-bit signed integer
| |
− | <source lang="c">unValue.m_sWord = *(short *)&paucScriptBuffer[iIp];
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |09||4||{{icon|lcs}}||{{icon|vcs}}||Immediate 32-bit floating-point
| |
− | <source lang="c">unValue.m_fFloat = *(float *)&paucScriptBuffer[iIp];
| |
− | iIp += 4;</source>
| |
− | |-valign=top
| |
− | |0A||until x=0 +1||||{{icon|vcs}}||Immediate null-terminated string{{ref|strvcs|[*]}}
| |
− | <source lang="c">pszString = &paucScriptBuffer[iIp];
| |
− | strcpy(unValue.m_szString, pszString);
| |
− | iIp += strlen(pszString) + 1;</source>
| |
− | |-
| |
− | !colspan=5|Untypified
| |
− | |-valign=top
| |
− | |T<0C||1||{{icon|lcs}}||||Local timer
| |
− | <source lang="c">ucTimerLocalId = paucScriptBuffer[iIp++] + 0x5E;</source>
| |
− | |-valign=top
| |
− | |T<0D||1||||{{icon|vcs}}||Local timer
| |
− | <source lang="c">ucTimerLocalId = paucScriptBuffer[iIp++] + 0x5D;</source>
| |
− | |-valign=top
| |
− | |T<6C||1||{{icon|lcs}}||||Local integer/floating-point variable
| |
− | <source lang="c">ucLocalId = paucScriptBuffer[iIp++] - 0x0C;</source>
| |
− | |-valign=top
| |
− | |T<6D||1||||{{icon|vcs}}||Local integer/floating-point variable
| |
− | <source lang="c">ucLocalId = paucScriptBuffer[iIp++] - 0x0D;</source>
| |
− | |-valign=top
| |
− | |T<CC||3||{{icon|lcs}}||||Local integer/floating-point array
| |
− | <source lang="c">ucArrayLocalId = paucScriptBuffer[iIp] - 0x6C;
| |
− | ucIndexLocalId = paucScriptBuffer[iIp + 1];
| |
− | ucArraySize = paucScriptBuffer[iIp + 2];
| |
− | iIp += 3;</source>
| |
− | |-valign=top
| |
− | |T<CD||3||||{{icon|vcs}}||Local integer/floating-point array
| |
− | <source lang="c">ucArrayLocalId = paucScriptBuffer[iIp] - 0x6D;
| |
− | ucIndexLocalId = paucScriptBuffer[iIp + 1];
| |
− | ucArraySize = paucScriptBuffer[iIp + 2];
| |
− | iIp += 3;</source>
| |
− | |-valign=top
| |
− | |T<E6||2||{{icon|lcs}}||{{icon|vcs}}||Global integer/floating-point variable
| |
− | <source lang="c">usGlobalId = (*(short *)&paucScriptBuffer[iIp] - (isGameLcs() ? 0x00CC : 0x00CD)) << 8;
| |
− | iIp += 2;</source>
| |
− | |-valign=top
| |
− | |T>=E6||4||{{icon|lcs}}||{{icon|vcs}}||Global integer/floating-point array
| |
− | <source lang="c">usArrayGlobalId = (*(short *)&paucScriptBuffer[iIp] - 0x00E6) << 8;
| |
− | ucIndexLocalId = paucScriptBuffer[iIp + 2];
| |
− | ucArraySize = paucScriptBuffer[iIp + 3];
| |
− | iIp += 4;</source>
| |
− | |-valign=top
| |
− | |N/A||8||{{icon|lcs}}||||Immediate 8-byte string
| |
− | <source lang="c">strcpy(unValue.m_szString, &paucScriptBuffer[iIp]);
| |
− | iIp += 8;</source>
| |
− | |}
| |
− | {{note|strvcs}} This type was implemented in VCS due to the presence of string variables.
| |
− |
| |
− | All the data types above haven't been tested in a decompiling process yet.
| |
− |
| |
− | {{Incomplete}}
| |
− |
| |
− | === Parameters ===
| |
− | 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:
| |
− | * Immediate values
| |
− | ** integer numbers
| |
− | ** floating-point numbers
| |
− | ** [[#Strings|short strings]]
| |
− | ** {{icon|sa}} [[#Strings|long strings]]
| |
− | * Variables
| |
− | ** global variables
| |
− | ** local variables
| |
− | * {{icon|sa}} {{icon|lcs}} {{icon|vcs}} [[#Arrays|Arrays]]
| |
− | {{Incomplete}}
| |
− |
| |
− | ==== Strings ====
| |
− | ''Strings'' are the sequences of symbols. Those including {{hint|letters|A..Z}}, {{hint|numbers|0..9}}, some other chars like {{hint|underscore|_}} or {{hint|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.
| |
− |
| |
− | {{note|str8}} '''Short string'''. This is the most common type of a string, that is used in every game since [[GTA 3]]. 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 [[Wikipedia:null terminator|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).
| |
− |
| |
− | {{note|sa16}} 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 always occupy 16 bytes of a SCM file.
| |
− | {|
| |
− | !width="250px" align="left"|String
| |
− | !width="250px" align="left"|Equivalent in SCM
| |
− | |-
| |
− | | <span style="color:red">'MAIN'</span>||{{Hint|09|data type}} {{hint|4D 41 49 4E 00 00 00 00|string}}
| |
− | |-
| |
− | | <span style="color:red">'MODDING'</span>||{{Hint|09|data type}} {{hint|4D F4 44 49 4E 47 00|string}}
| |
− | |-
| |
− | | <span style="color:red">'SAVE_YOUR_SOULS!'</span>||{{Hint|0F|data type}} {{hint|53 41 56 45 5F 4F 55 52 5F 53 4F 55 4C 53 21 00|string}}
| |
− | |}
| |
− | {{note|str16}} '''Long string'''. This type was first introduced in San Andreas. Maximum length depends on the opcode{{Ref|longstringslimits|[*]}}.
| |
− |
| |
− | {{Incomplete}}
| |
− |
| |
− | ==== Arrays ====
| |
− | {{note|varray}} Native ''[[Wikipedia:Array|arrays]]'' support was introduced in GTA SA, however there were different implementations of [[VC_Arrays|arrays in Vice City]]. In SA SCM arrays are assembled as 2 UINT16s and 2 bytes:
| |
− | 2b - UINT16 - array offset{{ref|arrayoffset|[*]}}
| |
− | 2b - UINT16 - array index{{ref|arrayindex|[*]}}
| |
− | 1b - BYTE - array size
| |
− | 1b - BYTE - flags{{ref|arrayflags|[*]}}
| |
− |
| |
− | {{note|arrayoffset}} 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 (<code>{{hint|96 00|little-endian}}</code>) it means that the first element of the array is <span style="color:blue">$150</span>, the second one is <span style="color:blue">$151</span>, etc. Same valid for the local arrays (offset is a local variable index). <!-- global variables are multiplied by 4-->
| |
− |
| |
− | {{note|arrayindex}} 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 (<code>{{hint|03 00|little-endian}}</code>), the game will read either global variable <span style="color:blue">$3</span> or local variable <span style="color:blue">3@</span> depending on the array flag (see below). This variable holds the number which is array element ID to work with. For example, if the array index is <span style="color:blue">$3</span>, and <span style="color:blue">$3</span> holds number <span style="color:maroon">5</span>, the game will read 5th element of the array.
| |
− |
| |
− | {{note|arrayflags}} Flags
| |
− | {|{{Prettytable}}
| |
− | |-
| |
− | |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
| |
− | |}
| |
− | {|
| |
− | !width="250px" align="left"|Array
| |
− | !width="250px" align="left"|Equivalent in SCM
| |
− | |-
| |
− | | <span style="color:blue">{{hint|$150(3@,6f)|Sanny Builder syntax}}</span>||{{hint|07|data type}} {{hint|96 00|array offset}} {{hint|03 00|array index}} {{hint|06|size}} {{hint|01|flag}}
| |
− | |-
| |
− | | <span style="color:blue">{{hint|10@(9@,5s)|Sanny Builder syntax}}</span>||{{hint|0D|data type}} {{hint|0A 00|array offset}} {{hint|09 00|array index}} {{hint|05|size}} {{hint|02|flag}}
| |
− | |}
| |
− |
| |
− | === Notes ===
| |
− | {{note|vcstr}} In [[GTA 3]], [[Vice City]] and [[Liberty City Stories]] short strings (8 bytes) have no data type preceeding it. If the byte does not fit data type range (00-06 for GTA 3 and VC), it's recognized as a beginning of a string and next 8 bytes are read.
| |
− |
| |
− | {{note|partype0}} 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 3 and VC, 32 for SA, LCS and VCS. However, those that admit an undefined amount of arguments can pass 18 parameters for GTA 3 and VC, 34 for SA, 106 for LCS and VCS (this information still needs confirmation).
| |
− |
| |
− | {{note|05B6}} {{Icon|SA}} Opcode [[05B6]] is a special opcode that defines a table. Immediately after opcode number the stream of data (128 bytes) follows, without a data type.
| |
− |
| |
− | {{note|longstringslimits}} {{GTAF|post|261006|3940262|Post by Seemann describing limits for the long strings in SA}}
| |
| | | |
| == Cracking the SCM == | | == 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 3 (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 SA has more), 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: |
− | | |
− | The original [[SCM]] format was cracked shortly after the release of [[GTA 3]] (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 SA]] 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: | |
− | | |
− | :label035F78
| |
− | 0001: 0?
| |
− | 00D6: 0?
| |
− | 0256: 4??
| |
− |
| |
− | | |
− | 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)
| + | <source lang="scm">0001: 0 |
− | x? means a one byte number
| + | 00D6: 0 |
− | x?? means a variable stored at this offset from the start
| + | 0256: 4 |
− |
| + | 004D: 52000</source> |
| | | |
− | Some were easy, the very first line of a decompiled script (besides decompiler headers) looks something like: | + | So the next step was to find out what each opcode does. Some were easy, the very first line of a decompiled script (besides decompiler headers) looks something like: |
| | | |
− | 0002:
| + | <source lang="scm">0002: @label0034B2</source> |
| | | |
− | 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 [[0002]]s 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. | + | The only parameter this command has is an offset within the file, so this is most likely (and in fact is) a GOTO statement, so we know all [[0002]]s are GOTOs. With trials and errors people discovered meanings of many opcodes. With the release of the mobile version of GTA San Andreas, the complete [[list of opcodes]] names became available. |
| | | |
| 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, [[Mission Builder|BWME]] ({{U|Barton Waterduck}}'s Mission Editor) and {{U|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: | | 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, [[Mission Builder|BWME]] ({{U|Barton Waterduck}}'s Mission Editor) and {{U|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: |
Line 397: |
Line 71: |
| <source lang="scm">is_car_in_cube $car, $lowerx, $lowery, $lowerz, $upperx, $uppery, $upperz, 0</source> | | <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) | + | (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, {{U|Seemann}} created an even more versatile decompiler, the [[Sanny Builder]]. It has become the most popular mission builder.
| |
− | | |
− | == The Tools ==
| |
− | ''Main article: [[Mission Scripting Tools]]''
| |
− | | |
− | There are three main builders for GTA 3, VC, and SA, and one for LCS and VCS.
| |
− | | |
− | === Mission Builder ===
| |
− | ''Main article: [[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 used to be the most popular MB until Sanny Builder was released. This project is abandoned and the creator retired.
| |
− | | |
− | ;Code format:
| |
− | | |
− | Early builders used data type identifiers on all numbers, these were
| |
− | | |
− |
| |
− | | |
− | 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).
| |
− | | |
− | ;Advantages: Commands related to the parameters.<br>Macros and program execution facilities inbuilt.
| |
− | | |
− | ;Disadvantages: Not widely used anymore<br>Creator retired (no future updates / bug fixes).<br>Decompilation bugs (especially in certain advanced jumps).<br>Many unofficially usable SCM features uncatered for (although these are mostly advanced problems never experienced by the average coder).<br>Inconvenient syntax.
| |
− | | |
− | ;Other notes: GUI.<br>Compiler inbuilt.
| |
− | | |
− | === Point ===
| |
− | ''Main article: [[Point]]''
| |
− | | |
− | It is a scripting tool developed by Jon Caruana.This is still very much in the development stages, but it was abandoned in 2006. It was 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 III Era GTAs. Originally developed for VC/III, this tool has been expanded to work for all three 3D games(III, VC, SA). 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 ===
| |
− | ''Main article: [[Sanny Builder]]''
| |
− | | |
− | Sanny Builder is made and produced by {{U|Seemann}}. Sanny Builder is the fastest and the most powerful tool. Moreover, it is widely used by the modding community. It includes a compiler and a decompiler. Furthermore, it supports CLEO library which extends the coding possibilities in all III Era Games by adding a lot of new and useful opcodes and allowing to run the scripts without modifying the main.scm file. It includes many useful features, as well as detailed help including description and solutions for all run-time error messages. Initially, it was developed for GTA:SA and based on MB code but since then it has been expanded and includes many different features, some of them taken from Gtama and most of them are new (such as a basic class system and direct HEX input (as requested by Y_Less)).
| |
− | | |
− | The code format is based on a combination of both Gtama and MB 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). However, it supports high-level statements.
| |
− | | |
− | ;Data Types:
| |
− | | |
− | ;: $ - global variable<br>s$ - global string variable<br>v$ - global long string variable<br>@ - label (text directly AFTER used to reference this label in jumps)<br>@ - local variable (number BEFORE denotes variable)<br>@s - local string variable (number BEFORE denotes variable)<br>@v - local long string variable (number BEFORE denotes variable)<br><nowiki>'...'</nowiki> - string (first 8 bytes after opcode when compiled)<br>"..." - debug string text<br># - model identifier (means you can enter the id name of a model rather than the number)<br>0x - Hexadecimal number<br>& - ADMA (Advanced Direct Memory Access)
| |
− | | |
− | ;Advantages: It is the fastest<br>Supports CLEO library<br>It has many language translations<br>It is very well documented and it includes useful information and detailed help including description and solutions for all run-time error messages<br>It has useful tools such as Coords Manager, Opcode search , MB > SB syntax converter and many others<br>Supports all III era games (Can decompile from GTA III, GTA VC, GTA SA, GTA LCS, GTA VCS and Can compile in GTA III, GTA VC, GTA SA)<br>It uses color code highlighter<br>Supports high-level constructions<br>It has a coding method with classes<br>Online updateable ini.
| |
− | | |
− | === Disassembler/Assembler ===
| |
− | ''Main article: [[gtama]]''
| |
− | ''(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. <code>is_player_defined</code>. 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 <code>.gsr</code> files, each one containing the code to one mission. This reduces file sizes considerably as BWME generated files are huge (around 6 MB <code>.txt</code> 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 [[User:CyQ|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)<br>! - local variable (data type 03)<br>@ - label (text directly after used to reference this label in jumps)<br>"" - string (no data type, first 8 bytes after opcode when compiled)<br>% - model identifier (means you can enter the id name of a model rather than the number - data type 05 for the compiled number)
| |
| | | |
− | ;Advantages: Small files sizes.<br>Clearer code - data and commands separated.<br>Active creator (although no longer developing).<br>More support for advanced features (supports memory hacking methods not widely used).<br>Open source.<br>Online updateable ini.<br>Format used on custom error handler for VC.
| + | Although you can't see much difference with that example, it can make a lot of difference. Since Barton left the modding community, {{U|Seemann}} created an even more versatile decompiler, [[Sanny Builder]]. It has become the most popular scripting tool. |
− | | |
− | ;Disadvantages: Not widely used.<br>Code spread across multiple files - harder for searching.<br>Data not easily related to code.
| |
− | | |
− | ;Other notes: Command line based.
| |
| | | |
| ==See also== | | ==See also== |
− | * [[SCM_language|SCM Language]] | + | * [[Opcode]] |
| + | * [[SCM language]] |
| + | * [[SCM language III/VC definitions]] |
| + | * [[Mission Scripting Tools]] |
| + | * [[List of opcodes]] |
| * {{Icon|SA}} [[Design Your Own Mission]] | | * {{Icon|SA}} [[Design Your Own Mission]] |
| | | |
| == External links == | | == External links == |
− | * {{GTAF|section|49|Mission Coding Forum}} | + | * {{Icon|trilogy}} {{GTAF|section|317|Coding Forum}} |
− | * {{GTAF|section|65|Mission Mods Showroom}} | + | * {{GTAF|section|326|Mission Mods Showroom}} |
− | {{note|src}} [http://gtamodding.ru/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%98%D1%81%D1%85%D0%BE%D0%B4%D0%BD%D0%B8%D0%BA%D0%B8 Sources of the GTA 3 missions at GTAModding.ru] | + | * {{note|src}} [http://gtamodding.ru/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%98%D1%81%D1%85%D0%BE%D0%B4%D0%BD%D0%B8%D0%BA%D0%B8 Sources of the GTA 3 missions at GTAModding.ru] |
− | * [http://alexander.sannybuilder.com/Files/stuff/gta3scmsrc.zip GTA 3 Script (scm) Rockstar's original sources found in the iPad version] | + | * [http://public.sannybuilder.com/sources/gta3scmsrc.zip GTA 3 Script (scm) Rockstar's original sources found in the iPad version] |
| + | |
| {{N|SA|VC|3}} | | {{N|SA|VC|3}} |
| + | |
| [[Category:Mission Scripting]] | | [[Category:Mission Scripting]] |