53 replies to this topic

[Deji]

SCRambl

 

Download Current BETA

 

View Project

 

Info

SCRambl is a high-level SCR language assembler with an advanced modular design which allows for a deep level of customisation. Compiled SCR scripts are often used by desktop and game software which read the file and execute the appropriate code internally, allowing an easy lower-level way of creating content. SCRambl supports both headered and headerless script compilations with a wide range of support for changing the way their code is generated. SCRambl also has many preprocessor features including macro support and preprocessor blocks which allow for improved code management and maintainability within large projects.

 

SCR

SCR is a conceptual language based on BASIC, which provides a fully featured scripting environment while maintaining a relatively low learning curve. This language is considered incomplete as many decisions have still not yet been made. SCRambl tries to allow for complete customisation of the SCR syntax through the use of definition files, enabling it to be easily updated, expanded or redone, so much as to allow SCRambl to be used for a wide range of coding styles, optimisation techniques and required usages.

 

Features

• Fast code parsing & compilation

• Advanced preprocessor

• High construct

• Easy syntax expansion & customisation

• Deeply customisable compilation

• Accurate default SCR syntax

• Fast hashing & lookups

• Syntax expandable from within scripts

• Macros, advanced preprocessor logic/integer expressions, preprocessor blocks

• Fully working string functionality including special character ability using escape sequences

• String escape sequences

• Error detection

• Useful warnings

• Variable scoping

• Configurable code optimisations

• Operators and command overloading

• Advanced configurable type matching and recognition system

• File including

Future Features

• Project support

• Internal scripting engine

• More customisability

• Performance optimisations

• Customisable header compilation

Examples

I started out by building up SCRambl to build a simple native script, debug.sc, which is found in SA's data folder. Once it got over compiling that, I started to make a dent on compiling some native GTA III scripts, which it got through quite well (though I had to remove III specific commands as I haven't built a catalogue of them yet) but I never finished parsing those fully. Eventually I started writing a short script which I am constantly adding and taking bits from to test individual features (test-script.txt) and decompiling them in Sanny Builder to verify the results.

 

Here are some of the more impressive abilities...

 

In-script Command Registering and Overloading

#register_command 0EEE MY_COMMAND(i,f,f)
MY_COMMAND(1, 0.5, 0.5)   // compiles 0EE command
#register_command 0FFF MY_COMMAND(f,f,f)
MY_COMMAND 3.0 1.2 3.2

SCRambl allows you to define new script-specific commands which is great if you do something like hacking in a new opcode using the script or have added new opcodes using another project-specific file which you don't want to keep globally or wish to share easily. Since the command is defined in the script, no one you give the script to will have to edit any of their configuration files in order to add new opcodes. The syntax of the preprocessor command "register_command" is much like the commands.ini syntax with a few restrictions such as not being able to define an unknown/NOP command.

 

You can then use a newly registered command after it has been defined or overload it. The first use of MY_COMMAND compiles the 0EEE opcode, because it uses an integer for the first parameter. The second use compiles the 0FFF opcode, because it has a float instead. SCRambl searches through command overloads to find the most fitting one for the job. If the 0EEE variation didn't exist, writing an integer as the first parameter would compile the 0FFF variation using an integer for the float. You can do the same if the 0FFF variation didn't exist. However, a warning will be produced saying that converting a float to int may result in a loss of data.

 

Native Control Structures

VAR_INT counter
 
REPEAT 5 counter
WAIT 0
ENDREPEAT

 

Decompiled in SB3:

:NONAME_7
WAIT 0 
$PLAYER_CHAR += 1 
  $PLAYER_CHAR > 5 
GOTO_IF_FALSE @NONAME_7

 

Script Constant Support + Local Variable Scope + Arrays + Enumerators + Long Math Lines (lol)

#const
flval FLOAT 4.0
#endconst
 
{
    LVAR_INT int_var int_arr[4] int_idx
    LVAR_FLOAT float_var
    int_arr[int_idx] = 69    // [email protected]([email protected],4i) = 69
    int_var = TRUE    // [email protected] = 1
    int_var += 5 + 4 + timera + 2 + 1   // >> /*
        [email protected] += 9
        005A: [email protected] += [email protected] // (int)
        [email protected] += 3
    */
    int_var -= timera    // 005A: [email protected] += [email protected] // (int)
    int_var -= PAD1    // usage of an enumerator as a value
    int_var = flval    // 0062: [email protected] -= [email protected] // (int) (causes float-to-int warning)
    float_var = flval    // [email protected] = 4.0
}

 

Built-in Model Constants + Macro's

#define DEFAULT_WAIT_TIME (250 + 5)   // obviously DEFAULT_WAIT_TIME will be 255
#define INTERRUPT WAIT DEFAULT_WAIT_TIME   // now we can write "WAIT 255" using the macro "INTERRUPT"
 
#define SuperVar LVAR_STRING   // yes, SCRambl will be able to turn SuperVars into a full compiler extension
 
#if (defined(SuperVar)) + 2 == 3    // this returns true, so "WAIT 255" is produced instead of "WAIT 0"
INTERRUPT
#else
WAIT 0
#endif
 
INTERRUPT   // of course, there are much better ways to use macros...
 
SUPERVAR SVar    // guess what? we just declared a SuperVar! easy as 1, 10, 11... get it?
 
#define ADD_MALE_CHAR CREATE_CHAR DEFAULT_MALE_CHAR 0.0 0.0 0.0
CREATE_CHAR PEDTYPE_CIVMALE male01 0.0 0.0 0.0 male_char
ADD_MALE_CHAR male_char

 

Decompiled in SB3:

WAIT 255 
WAIT 255
CREATE_CHAR 4 #MALE01 0.0 0.0 0.0 $PLAYER_ACTOR 
CREATE_CHAR 4 #MALE01 0.0 0.0 0.0 $PLAYER_ACTOR

 

Pretty cool if I do say so myself...

 

 

The Manual

A manual is provided with each version of SCRambl, which documents the features in that version. The manual comes in HTML format, using JavaScript to make it easier to browse and read. This documentation has been tested working with the latest versions of Mozilla Firefox and Google Chrome.

 

An online copy of the documentation for latest version SCRambl can be found at: https://dl.dropboxus...3209/MANUAL.htm

 

 

Manual

View Project  (changes)

[Seemann]

Thanks for sharing. Wish you were more active on the projects like this one.

I've tried to test it and got an error:
http://imgur.com/UYBkgC6

I run it with the run.bat, the config.ini contains a proper path to the GTA sa folder.

[Deji]

QUOTE (Seemann @ Thursday, Jul 18 2013, 08:41)

Thanks for sharing. Wish you were more active on the projects like this one. I've tried to test it and got an error: http://imgur.com/UYBkgC6 I run it with the run.bat, the config.ini contains a proper path to the GTA sa folder.

My bad, run.bat has not been updated since early stages. I'd been using Visual Studio's Debugger to run the program post-build. The input file error is simply that it cannot locate the file from the path given in run.bat. I've updated a bunch of files so it is easier to work out of the box and fixed the release version, though if you want the juicy inner details of SCRambl's processing mechanisms (sounds so great when I say it like that), the Debug version is pretty sweet. Checkout the new revision and it should work fine.

[Seemann]

Is there a way to download all the sources in one time rather than dl-ing them one by one file?

[Deji]

QUOTE (Seemann @ Thursday, Jul 18 2013, 12:21)

Is there a way to download all the sources in one time rather than dl-ing them one by one file?

Yes, checkout the code with SVN: https://code.google....source/checkout

I use TortoiseSVN which has a GUI and context extension... Once installed, right click in any folder in explorer and click "SVN Checkout...". Use Google Code's svn trunk URL and all the files will be sent straight there. I sound like a pro but it took me hours to crack uploading it from scratch, but to be fair, it's pretty stupid that I had to checkout nothingness in order to update it...

I amended the first post with some show-off code examples and a features list.

[LINK/2012]

Good to see that a SCR compiler is finally 'out'.
I really wish to contribute to this project (and CLEO too, listen that Seeman!), but since day by day I walk way from modding that may not happen, but I really want and will try to involve myself into it...

[Deji]

I've started a TODO list on the Project Page. Will finish later and try to have CASE statement parsing complete.

EDIT: Done the TODO list. It's actually amazing, so little left to be done

[Deji]

Finished CASE statement implementation.

Anyone (Silent?) know how functions are made in VCS?

[Seemann]

Functions are supported in LCS too (opcodes 05AE, 05AF). They should work in the same way as the ones in CLEO 3 (0AB1).

[Deji]

QUOTE (Seemann @ Tuesday, Jul 23 2013, 05:31)

Functions are supported in LCS too (opcodes 05AE, 05AF). They should work in the same way as the ones in CLEO 3 (0AB1).

I mean natively though... As far as I know, the CALL commands do not have any parameters aside from the label of the function. I guess the function has to be declared so that the compiler can check number of parameters etc. I was planning to extend this to functions using CLEO too, but with native syntax (and maybe a few extra features too).

I think it should be declared something like:
FUNCTION [name] (params in/out? they must need separation by a word or something)
[code=auto:0]
ENDFUNCTION

Not sure, though.

[Seemann]

CODE

FUNCTION SQR LVAR_INT A RET A * A ENDFUNCTION LVAR_INT foo foo = SQR 5

just an idea

[Wesser]

We should get the cue from other native statements. In my opinion, no construct is used to declare the beginning or the end of a function. It does work like a script, a mission or a trigger, that is it starts by a label. I believe, R* programmers set another type of local for input and output variables, let's call them IVAR and OVAR, whose difference is visibile only to the compiler. Other locals declared with LVAR prefix are interpreted as script variables. Indeed, a problem may arise when parsing them, because you must check for all declared variables as you need to order them by preceding the input values before the returning variables and the script locals, which forces you to make more parses during the compilation (oh well, not necessarily). Anyway, this might be a faithful reproduction of the original function-script:

Decompiled			Compiled
CODE CALLA function [{anyvalue0|varname0} ... {anyvalueN|varnameN}] CALLB function [{anyvalue0|varname0} ... {anyvalueN|varnameN}] [...] function: {    [{IVAR|OVAR|LVAR}_{vartype} {varname0}[,] [... {varnameN}]]    [...]    //RETURN_TRUE    //RETURN_FALSE    RETURN }	CODE {05AE} {05AF} [....]  ---- [....] {00C5} {00C6} {0051}	CODE {037A} {037B} [....]  ---- [....] {00C5} {00C6} {0051}	CODE CALLA function {inputargs} {outputvars} {parentvars} [{anyvalue0|varname0} ... {anyvalueN|varnameN}] CALLB function {inputargs} {outputvars} {parentvars} [{anyvalue0|varname0} ... {anyvalueN|varnameN}] [...] function: [...] //RETURN_TRUE //RETURN_FALSE RETURN

However, the difference between CALLA and CALLB (ofcourse, they are likely definitions) is still unknown. If someone is quite familiar with MIPS assembly may point out the riddle.

[Silent]

QUOTE (Wesser @ Tuesday, Jul 23 2013, 15:00)

However, the difference between CALLA and CALLB (ofcourse, they are likely definitions) is still unknown. If someone is quite familiar with MIPS assembly may point out the riddle.

Ur lying

In VCS, 037A calls a function with NOT flag set (return_true/return_false is inverted). 037B is a call without a flag. I believe it applies to LCS 05AE and 05AF aswell. Therefore, I think 037B/05AF was just CALL or CALL_FUNCTION, while 037A/05AE may have been compiled from something like NOT CALL or NOT CALL_FUNCTION. Ot they were just different functions, who knows. They probably were separate, seeing how easy proper NOT flag for calls can be implemented (took me several minutes in VCSPC).

The only unknown thing with calls is the 3rd param yet - I would assume it can be ignored though. I've been testing it with VCS and haven't noticed anything interesting.

[Deji]

Thanks Wesser. That actually reminds me very much of something... I think I recall seeing somewhere where a similar thing was written (god knows where.. maybe it was a dream). Also it makes me realise that "external scripts" are probably written in a similar way. The first couple of LVAR's are usually reserved for particular purposes: trigger entity handles, trigger types.

Unfortunately, I didn't build my mind palace until recently, so I will have to bang my head with some books to see if the memory of the code falls out...

[Wesser]

QUOTE (SilentPL @ Tuesday, Jul 23 2013, 14:29)

In VCS, 037A calls a function with NOT flag set (return_true/return_false is inverted). 037B is a call without a flag. I believe it applies to LCS 05AE and 05AF aswell. Therefore, I think 037B/05AF was just CALL or CALL_FUNCTION, while 037A/05AE may have been compiled from something like NOT CALL or NOT CALL_FUNCTION. Ot they were just different functions, who knows. They probably were separate, seeing how easy proper NOT flag for calls can be implemented (took me several minutes in VCSPC).

As far as I remember, both commands are used as conditions, but 05AF doesn't as procedure in LCS. I probably misunderstand what you are saying, but they might differ according to the truthfulness of the NOT flag. In this regard, a plausible definition of each command would be respectively CALL and CALLNOT. I'm still quite unsure, because in III we have IF/IFNOT and WHILE/WHILENOT which affect the constitution of the whole construct by swapping GOTO_IF_FALSE with GOTO_IF_TRUE.

QUOTE (SilentPL @ Tuesday, Jul 23 2013, 14:29)

The only unknown thing with calls is the 3rd param yet - I would assume it can be ignored though. I've been testing it with VCS and haven't noticed anything interesting.

The third argument helps the game knowing how many locals of the parent script it should save, those which get restored after returning back to the caller.

QUOTE (Deji @ Tuesday, Jul 23 2013, 15:26)

It makes me realise that "external scripts" are probably written in a similar way. The first couple of LVAR's are usually reserved for particular purposes: trigger entity handles, trigger types.

Yeah, we can try to move even closer to the truth by getting rid of IVAR type and overwriting OVAR with CVAR or rather RVAR (in this way LVAR and RVAR locals would also acquire the meaning of left and right variables). Doing so, we are able to distinguish every local simply by assuming which couple of them is reserved for the output variables.

[Ss4gogeta0]

I know a code monkey that would be interested in experimenting with this... I myself am not much of a coder (I use the DM Language for most of the projects i work on so other than that I am left in the dark...) hmmm maybe i can get off my ass and learn scr...

-Inane babble sent from my Ipad....

[Deji]

QUOTE (Ss4gogeta0 @ Tuesday, Jul 23 2013, 17:09)

I know a code monkey that would be interested in experimenting with this... I myself am not much of a coder (I use the DM Language for most of the projects i work on so other than that I am left in the dark...) hmmm maybe i can get off my ass and learn scr... -Inane babble sent from my Ipad....

I've been working on "The SCR Manual" for quite a while. It aims to be a tutorial as well as a complete reference of everything SCR.


In other news, I have implemented the #hex..#endhex construct. Not only does it allow inputting RAW HEX, it supports macros, variables, labels, commands... well, just see for yourself:
SCRambl Code

CODE

#const DT_DWORD   INT 1 DT_LVAR    INT 3 DT_BYTE    INT 4 DT_WORD    INT 5 DT_TEXTLABEL  INT 9 DT_VARLEN_STRING INT 14 #endconst { LVAR_INT scr_lvar #hex SCRIPT_NAME DT_TEXTLABEL 4D41494E00000000 /* 'MAIN' */ DO_FADE DT_BYTE 00 DT_BYTE 00 2C04 DT_WORD 9300 0D03 DT_WORD BB00 GOTO DT_DWORD hex_label 0600 DT_LVAR scr_lvar DT_DWORD hex_label hex_label: PRINTSTRING DT_VARLEN_STRING 08 "SCRambl" 00 #endhex }

Since HEX constructs are not part of native syntax, # is used. This symbol is used to identify compiler specific directives and constructs.
SCRIPT_NAME is replaced with the 2-byte opcode.
DT_TEXTLABEL is a constant which is already defined as 9, so it takes up 1 byte (unlike some of the things you can have in the HEX construct, its size isn't fixed and depends on the data size).
Then proceeds some actual raw HEX input. The preprocessor would reject it if it had an odd number of characters.
Further down, we have a GOTO command with hex_label as the label pointer. It will be replaced with an absolute 4 byte label pointer as usual (in the ASM construct I plan to make label pointers relative).
On the next line, a scr_lvar is used. As you may guess, the replacement will be the 2-byte variable index.
After that is a label. Labels can be written in the HEX struct the same way they can be written in normal code.
Finally, "SCRambl" is a raw character sequence. Strings must be enclosed in quotes in HEX constructs, unlike elsewhere in scripts. No terminator or size specifier is automatically added for these.

Note that data types are not included automatically. Same principles you may be used to in Sanny Builder apply in most cases.

Decompiled in SB3 (opcodes added for comparison)

CODE

03A4: SCRIPT_NAME 'MAIN' 016A: DO_FADE 0 0 042C: SET_TOTAL_NUMBER_OF_MISSIONS 147 030D: SET_MAX_PROGRESS 187 0002: GOTO @MAIN_44 0006: [email protected] = -44 :MAIN_44 0662: PRINTSTRING "SCRambl"

The only restrictions are that operators cant be used in HEX constructs and overloaded commands won't work as there are no params for the preparser to choose a specific command.

So, a very successful new feature implemented. May I point out that now SCRambl has pretty much everything you need to write full-functioning CLEO scripts for San Andreas? I mean, I can't think of anything that's missing yet... yell at me if you find something missing.

[Ss4gogeta0]

QUOTE (Deji @ Tuesday, Jul 23 2013, 18:01)

May I point out that now SCRambl has pretty much everything you need to write full-functioning CLEO scripts for San Andreas? I mean, I can't think of anything that's missing yet... yell at me if you find something missing.

Hmmm... Is there anyway to impliment some kind of mission builder support?

[Deji]

QUOTE (Ss4gogeta0 @ Tuesday, Jul 23 2013, 18:17)

QUOTE (Deji @ Tuesday, Jul 23 2013, 18:01) May I point out that now SCRambl has pretty much everything you need to write full-functioning CLEO scripts for San Andreas? I mean, I can't think of anything that's missing yet... yell at me if you find something missing. Hmmm... Is there anyway to impliment some kind of mission builder support?

That's the main aim. SCRambl can now compile CLEO scripts which are just headerless scripts like those found in script.img... All we need to do is add support for headered scripts and we'll be able to build SCM files from scratch (not with script.img support though). Then we've just got subscript abilities to add for a higher level of scripting which will result in a fully native experience. After that, I'm thinking of making SCRambl start handling project files, so one file will combine all the scripts you're working on, define the specifics of the project and allow you to combine multiple separate files into full mission scripts including those in script.img.

[Ss4gogeta0]

QUOTE (Deji @ Tuesday, Jul 23 2013, 18:30)

QUOTE (Ss4gogeta0 @ Tuesday, Jul 23 2013, 18:17) QUOTE (Deji @ Tuesday, Jul 23 2013, 18:01) May I point out that now SCRambl has pretty much everything you need to write full-functioning CLEO scripts for San Andreas? I mean, I can't think of anything that's missing yet... yell at me if you find something missing. Hmmm... Is there anyway to impliment some kind of mission builder support? That's the main aim. SCRambl can now compile CLEO scripts which are just headerless scripts like those found in script.img... All we need to do is add support for headered scripts and we'll be able to build SCM files from scratch (not with script.img support though). Then we've just got subscript abilities to add for a higher level of scripting which will result in a fully native experience. After that, I'm thinking of making SCRambl start handling project files, so one file will combine all the scripts you're working on, define the specifics of the project and allow you to combine multiple separate files into full mission scripts including those in script.img.

This would be the perfect tool for Total Conversions... who knows, maybe a number of them will actually come back from development hell...

Keep up the good work Deji

oh also, think you could take a look at this topic? since you have a fairly decent knowledge of the coding used in San Andreas.
Parallel Execution of GTA

[lucky cthulhu]

pretty good！

[juarez]

I've tried to compile a test-script.txt but I go an error:
http://imageshack.us...ges/9/lzoz.jpg/

Ok, my bad, I forgot to add a gta sa path to config.ini file xD.

[Deji]

Okay, this has me really stumped. From the GTA 3 source we see that scripts have their own file and started by START_NEW_SCRIPT. These .sc files must be compiled to the .scm file in a particular order, but I can't figure out which. I collected this data:

CODE

(In order of reference) COMMAND - OFFSET - SCRIPT NAME START_NEW_SCRIPT - 81837 - ODDVEH START_NEW_SCRIPT - 76402 - R3 START_NEW_SCRIPT - 75338 - GYM START_NEW_SCRIPT - 75007 - SHOOT START_NEW_SCRIPT - 80584 - BLOODR START_NEW_SCRIPT - 80727 - HOTR START_NEW_SCRIPT - 80933 - KICKS START_NEW_SCRIPT - 87487 - PSAVE1 START_NEW_SCRIPT - 95290 - FLOW START_NEW_SCRIPT - 92234 - HELP START_NEW_SCRIPT - 85611 - COLLS START_NEW_SCRIPT - 98759 - CRANES START_NEW_SCRIPT - 83417 - BUY_PRO START_NEW_SCRIPT - 84314 - VALET_L START_NEW_SCRIPT - 84640 - ADPLANE START_NEW_SCRIPT - 84518 - TRAINSL START_NEW_SCRIPT - 83601 - IMPND_L START_NEW_SCRIPT - 99724 - OPENUP START_NEW_SCRIPT - 81211 - TRI (these are in order, however...) LAUNCH_MISSION - 101930 - (noname 1) LAUNCH_MISSION - 103838 - (noname 2) LAUNCH_MISSION - 106476 - (noname 3) LAUNCH_MISSION - 117407 - (noname 4) LAUNCH_MISSION - 118248 - (noname 5) LAUNCH_MISSION - 120466 - (noname 6) LAUNCH_MISSION - 135692 - APCHECK LAUNCH_MISSION - 139805 - GFINIT LAUNCH_MISSION - 154860 - (noname 7) LAUNCH_MISSION - 158295 - (noname 8) LAUNCH_MISSION - 159718 - HJ LAUNCH_MISSION - 162112 - CELLFON

Scripts aren't ordered alphabetical, nor in order of reference.

So I don't get how the compiler knows when to compile these scripts. Missions are obviously compiled in the order which they are started in, but the scripts are in a seemingly random order...

Luckily, I can assume that this:

CODE

{58215} 0914: NOP 0 {58219} 0914: NOP 1 {58223} 0914: NOP 2 {58227} 0914: NOP 3 {58231} 0914: NOP 4 {58235} 0914: NOP 5 {58239} 0914: NOP 6 {58243} 0914: NOP 7 {58247} 0914: NOP 8 {58251} 0914: NOP 9 {58255} 0914: NOP 10 {58259} 0914: NOP 11 {58263} 0914: NOP 12 ...

Would be written something like:

CODE

DECLARE_STREAMED_SCRIPT plchute.scc DECLARE_STREAMED_SCRIPT parach.scc DECLARE_STREAMED_SCRIPT cokec.scc

Otherwise they would be in random order too. I assume the .scc format as miss2 decides between that and .scm format and I reckon they are non-headered (singlefile) scripts. Not used in III/VC but not an idea completely new to SA.

[Wesser]

I really don't see where's the problem, Deji. Scripts are compiled in the order they are put.

This is how the SCM is structured internally (after being compiled).

[Deji]

QUOTE (Wesser @ Saturday, Jul 27 2013, 09:57)

I really don't see where's the problem, Deji. Scripts are compiled in the order they are put. This is how the SCM is structured internally (after being compiled).

Well, first of all, that wiki section makes no mention of scripts (which should come between main and foreign gosub), although it has subscripts, which aren't started by START_NEW_SCRIPT (and are treated as submissions). I already know the structure of the main.scm, I documented that ages ago. But order of the individual files within that structure is a different thing.

The scripts which I posted above are not in order, as you can clearly see:

START_NEW_SCRIPT - 81837 - ODDVEH - started first
START_NEW_SCRIPT - 76402 - R3 - started second. offset shows it is before ODDVEH
START_NEW_SCRIPT - 75338 - GYM - started third, offset shows it is before R3
START_NEW_SCRIPT - 75007 - SHOOT - started fourth, offset shows it is before SHOOT
START_NEW_SCRIPT - 80584 - BLOODR - started fifth, offset shows it is before ODDVEH

Unless all those listed scripts are actually written within the main.sc file which would be weird because 'R3' is on it's own in the III mobile source, there's no straight forward explanation for this.

[Wesser]

I was referring to those scripts which are within a file, it was implied ofcourse. They do not follow any order when compiling (the wiki doesn't mention them for a purpose). For instance, R3 script is placed before ODDVEH but it is started afterwards. However, these are main.sc scripts.

QUOTE (Deji @ Saturday, Jul 27 2013, 11:12)

Unless all those listed scripts are actually written within the main.sc file which would be weird because 'R3' is on it's own in the III mobile source, there's no straight forward explanation for this.

Are you sure? If a remember correctly, main.sc is the only missing file and because of this we cannot have access to R3 script (which is unnamed, though).

[Deji]

QUOTE (Wesser @ Saturday, Jul 27 2013, 10:58)

I was referring to those scripts which are within a file, it was implied ofcourse. They do not follow any order when compiling (the wiki doesn't mention them for a purpose). For instance, R3 script is placed before ODDVEH but it is started afterwards. However, these are main.sc scripts. QUOTE (Deji @ Saturday, Jul 27 2013, 11:12) Unless all those listed scripts are actually written within the main.sc file which would be weird because 'R3' is on it's own in the III mobile source, there's no straight forward explanation for this. Are you sure? If a remember correctly, main.sc is the only missing file and because of this we cannot have access to R3 script (which is unnamed, though).

Ohh my bad, I was getting HJ and R3 purposes mixed up I'm not able to decompile the III main.scm on this computer. I've already downloaded SA + IDA + a tonne more modding stuff and I have to try and keep the presence of this stuff unknown to the laptop owner

So I guess the main.sc file includes quite a huge portion of game code. I think I have all the knowledge needed to start working on complete MAIN compilation after I'm done trying to implement the assembler feature now

I might also try to write up a main.sc file for GTAIII based on the III main.scm if I can decompile it.

[Wesser]

I would suggest you to integrate NASM for ASM...ENDASM construct to assembly or disassebly ASM codes. Also, you should create a new section in the header (the game will skip it at the time it parses the GOTO) to store all the labels of ASM and HEX statements to make decompilation possible when these have been present in the source.

By the way, coding a self-made assembler and disassembler would be ideal, eh.

[Deji]

QUOTE (Wesser @ Saturday, Jul 27 2013, 11:32)

I would suggest you to integrate NASM for ASM...ENDASM construct to assembly or disassebly ASM codes. Also, you should create a new section in the header (the game will skip it at the time it parses the GOTO) to store all the labels of ASM and HEX statements to make decompilation possible when these have been present in the source. By the way, coding a self-made assembler and disassembler would be ideal, eh.

Creating an assembler would be awesome, but I figure it's harder than it might first seem. Especially to make it fast. I was going to use FASM but I'll have a look at NASM. FASM uses some really strange way of encoding assembly which I'm still having trouble figuring out. With NASM I'm more confused because my tiny windows based brain cant figure out why I've got so many errors/warnings compiling this

[Deji]

Tried creating an assembler, kinda started to doubt my ability when I notice that EVERY BIT in EVERY BYTE can be changed to produce loads of instructions more than just the opcode byte. After I get other things done, I might continue some work towards a custom assembler for SCRambl, but for now I think it's better to just hand the code over to the precompiled nasm.exe file.

CODE

GOTO skip_asm LVAR_INT instruction_ptr, var_ptr, func_ptr #ASM val2change: MOV eax, DWORD 0x0              ; the 0 value will be 4 bytes long - will be replaced by script var base address MOV ecx, func_ptr                ; will be replaced by 2, the func_ptr LVAR index MOV eax, [eax+ecx*4]            ; get the pointer to the func_ptr LVAR and read to eax CALL eax                        ; call the value stored in func_ptr #ENDASM skip_asm: GET_LABEL_POINTER val2change instruction_ptr instruction_ptr++ GET_THIS_SCRIPT_STRUCT var_ptr var_ptr += 0x3C WRITE_MEMORY instruction_ptr 4 var_ptr FALSE   // write this scripts local var base address to the ASM code

And that's been done. Now SCRambl has support for #asm..#endasm structs, where assembly code can be written. Labels declared with in the ASM struct are accessible from outside of it as well, however you unfortunately can't reference external labels as-of-yet. I may find a good way to do this in the future, but it requires a tonne of hacky code which may reduce compilation effeciency greatly. Also, unlike all other code in SCRambl, ASM code is not all converted to upper-case by the preprocessor meaning it is case-sensitive. This means that any external references such as variables (which are translated into their respective var indexes) and macros (which I've actually not tested yet, but the chances of them not working are very slim since they are 'fed' through the preprocessor at a very low level). The example code calls the param-less function stored in func_ptr. Not a very useful snippet, but it shows off some features. SCRambl uses The Netwide Assembler for its assembling, so if you have questions about anything from #asm to #endasm, that site is probably where you'll find the answer. SCRambl can Assembl!

Now I'm about to do a code cleanup and add some extra quick features (including C-style function-like macros, which WILL be awesome). After that, I want to aim towards releasing a BETA of SCRambl as an SA CLEO script compiler. Lots of testing will need to be done and I hope these features will inspire people to come up with some creative ways to write some technologically advanced scripts, because I've thought of quite a few myself


EDIT: Sorry guys, will probably be inactive again for a while now. I've put up the latest revisions of the source so in the slight chance anyone's up to trying to understand my code and do some stuff, it's all yours!