[SA] Multiple script but 1 purpose?

[In45do]

Hello guys, this is probably stupid question. I'm not test it yet (because I don't know how). So, can I do multiple CLEO script and connect it each other?
For example :

// This is Test1.cs:Script_Testwait 0 ms009A: 0@ = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.00665: get_actor 0@ model_to 1@09C7: change_player $PLAYER_CHAR model_to 1@ // now $PLAYER_CHAR is #SPECIAL10wait 5 ms009B: destroy_actor 0@//This is Test2.cs:Actionwait 0 ms if and02F2:   actor $PLAYER_ACTOR model == #SPECIAL1000ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_footjf @Action017B: set_actor $PLAYER_ACTOR weapon 22 ammo_to 10

Note : They are in different .cs file. How to make them 'communicate' with each other?

[fastman92]

I have no to explain it, someone else might further my post, so I'll just you give few hints.

 

You probably meant including source files, not connecting two separate .cs

Sanny Builder supports including of source files:

 

{$INCLUDE functions/getLocalVarOffset.txt}{$INCLUDE general/Addresses.txt}{$INCLUDE functions/TestCheatString.txt}{$INCLUDE functions/ArrayGetValueByIndex.txt}{$INCLUDE functions/getAdditionalVarsLabelPointedIndex.txt}{$INCLUDE functions/GetCurrentResolution.txt}{$INCLUDE functions/ScreenScale.txt}

Included files become a part of currently compiled .cs file.

 

2. First way

Every script running in GTA game is defined by an object of type CRunningScript (size: 224 bytes in GTA SA)

 

 

0AAA: get_script_struct_named 'OTB' store_to 0@

This command returns a pointer to script's CRunningScript info with specified name by a command.

 

03A4: script_name 'MAIN'

A part of CRunningScript are local variables.

 

 

0000003C tls             ScriptVar 34 dup(?)

+0x3C is offset of local variable 0@

 

Likewise, +0x40 will be an offset to local variable 1@

 

3. CLEO shared vars

 

0AB3: set_cleo_shared_var 0 to 10

0AB4: get_shared_cleo_var 0 store_to 0@

You may load and store values from CLEO shared variables. You need to pass a slot ID that must be in range 0 to 99.

There are 100 slots.

[Shmoopy]

You should create two threads like this ( pardon me if I'm doing it wrong cz its been a long time since i scripted something )

create_thread @Script_Testcreate_thread @Action// This is Test1.cs:Script_Testthread 'Script_Test'wait 0 ms009A: 0@ = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.00665: get_actor 0@ model_to 1@09C7: change_player $PLAYER_CHAR model_to 1@ // now $PLAYER_CHAR is #SPECIAL10wait 5 ms009B: destroy_actor 0@end_thread//This is Test2.cs:Actionthread 'Action'wait 0 ms if and02F2:   actor $PLAYER_ACTOR model == #SPECIAL1000ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_footjf @Action017B: set_actor $PLAYER_ACTOR weapon 22 ammo_to 10end_thread

Both scripts will execute simultaneously

 

 

But i prefer the fastman92's way cz it avoids clumsiness in the main script , but you should call the functions in order to execute the scripts ( i cant remember the opcode to call an external function )

[In45do]

@fastman92 That's too difficult for me to understand. But I will try it.

 

You mean both scripts compiled in the same thread in Sannybuilder?

[Shmoopy]

@fastman92 That's too difficult for me to understand. But I will try it.

 

You mean both scripts compiled in the same thread in Sannybuilder?

Yes , but you need to use global variables so that they can communicate with each other , for example if you create an actor with a local variable ( lets say 0@ ) in the first script, and you want to kill the actor in the second script , the second script wont work , because it cant communicate with the first thread cz you used local variables ( 0@ ) , instead you should use something like $Actor

Edited April 9, 2014 by Manfred Von Karma

[In45do]

By using opcode 008A? I'm afraid the global variables will causing bugs and crash.
And if I'm using global variables, what kind of names on the '$'? I mean you already give an example like $Actor.

[Shmoopy]

No need for the 008A opcode , are you making a mod ? if so i can provide you with a ready made MPACK , so that global variables wont cause any problems .

[In45do]

No need for the 008A opcode , are you making a mod ? if so i can provide you with a ready made MPACK , so that global variables wont cause any problems .

Yes, I am. If I making the mod with your MPACK, do I have to release the mod with your MPACK as well? (Sorry I'm to noob for MPACK things)

And btw, does anyone know how to detect if player is rebuilded? This opcode, 070D, are activated whenever player going to marker (interior) and wasted/busted.

[Shmoopy]

The MPACK is the mod itself

Rebuilding the player is only used when you want to change his clothes , the 3d model of cj gets updated , so if you want to check if the player changed clothes , you should use this :

08F7: get_player $PLAYER_CHAR bodypart 0 textureCRC_to 0@ modelCRC_to 1@ // Torso texture 0@ and model 1@

Here is the MPACK , place it in the GTA SA User files folder :

http://www28.zippyshare.com/v/10614159/file.html

[In45do]

The MPACK is the mod itself

Rebuilding the player is only used when you want to change his clothes , the 3d model of cj gets updated , so if you want to check if the player changed clothes , you should use this :

08F7: get_player $PLAYER_CHAR bodypart 0 textureCRC_to 0@ modelCRC_to 1@ // Torso texture 0@ and model 1@

Here is the MPACK , place it in the GTA SA User files folder :

http://www28.zippyshare.com/v/10614159/file.html

The MPACK crash the game.

And about 'player rebuild check' is not checking the player is rebuilded or not. It's store the current player clothes.

[Shmoopy]

I'll test it when i get home

[In45do]

I'll test it when i get home

So... have you test it?

And I have another question, why some of people that testing my CLEO modification can't perform this opcode 0391? Its function is to release the current texture. In my GTA SA it's perfectly work.

[Shmoopy]

http://www42.zippyshare.com/v/32313989/file.html

 

I dont have GTA SA right now so i didn't test it , but I'm sure that it will work

[Deji]

You should create two threads like this ( pardon me if I'm doing it wrong cz its been a long time since i scripted something )

No he shouldn't!

 

Both scripts will execute simultaneously

No they won't! The scripts will be executed one after another, depending on the order they're started.

 

 

3. CLEO shared vars

0AB3: set_cleo_shared_var 0 to 10

0AB4: get_shared_cleo_var 0 store_to 0@

You may load and store values from CLEO shared variables. You need to pass a slot ID that must be in range 0 to 99.

There are 100 slots.

 

There are 1024 They're still just as bad as global variables, though (except no SCM conflicts, just CLEO ones).

 

 

 

 

I don't recommend trying to execute a script twice. Especially the same script. You just don't know what's involved in creating each CLEO script, and there is no public definition. We presume that it's only a little more expensive than executing a normal SCM script, but it is not a guarantee. A future version may require scripts to use more memory per script and then your single script is using heaps of memory for no good reason.

 

I know, 31@ is a nasty looking limit, but CLEO already so far provides more use in those 32 variables than the original SA script engine. Those 32 variables can go a lot further than you think. However, you may have to get fancy. Use SCM functions to reduce the amount of variables you need to reserve for temporary operations. Try to only use the locals to store things that you actually need to keep for the duration of execution. Or, for an easy complete lack of limits, write things you need to use least often to an area of memory, such as XX amount of 'reserved space' in your script, e.g.:

 

:StaticMemoryHEX// space for 10 long-life variables00000000 00000000 00000000 00000000 0000000000000000 00000000 00000000 00000000 00000000END

Or ALLOCATE_MEMORY it.

 

 

Avoid tricks with arrays because they're simply not stable as they depend on things that can't be guaranteed to work.

 

 

 

Alternatively, use SuperVars: http://gtag.gtagaming.com/mods/111-supervars/

[Shmoopy]

^

Chillax amigo , you're taking this too much seriously like this will cause some sort of an explosion , its just a goddamn script , in45do got what he was looking for , he wanted to execute two scripts that are related with a global variable ( an actor ) so thats why i recommended him the Mpack instead of a cleo script , this thread should be /thread already .

[Silent]

^

Chillax amigo , you're taking this too much seriously like this will cause some sort of an explosion , its just a goddamn script , in45do got what he was looking for , he wanted to execute two scripts that are related with a global variable ( an actor ) so thats why i recommended him the Mpack instead of a cleo script , this thread should be /thread already .

This amigo provided a thorough under-the-hood explaination, what's wrong with it?

[Deji]

^

Chillax amigo , you're taking this too much seriously like this will cause some sort of an explosion , its just a goddamn script , in45do got what he was looking for , he wanted to execute two scripts that are related with a global variable ( an actor ) so thats why i recommended him the Mpack instead of a cleo script , this thread should be /thread already .

If everyone thought like you, CLEO wouldn't exist. I'll just leave it at that.

[Shmoopy]

If that so , then stop quoting my posts from now own Einstein

[Silent]

If that so , then stop quoting my posts from now own Einstein

Being sarcastic to an expert coder who's currently in charge of developing the plugin in question is definitely a great idea.

Edited April 23, 2014 by Silent

[Deji]

Instead, I liked your post and I will not quote it. I hope that's better for you

[In45do]

Actually your MPACK cannot be played.
And my purpose from the beginning was connecting 2 different CLEO script (or more). But you provide a way through MPACK.

 

@Deji How to use SuperVars? I've seen the example but I can't understand it. And what is 'array'?

[Deji]

@Deji How to use SuperVars? I've seen the example but I can't understand it. And what is 'array'?

 

*clears throat*...

 

Arrays are a way to access equal portions of memory in a larger memory space. Those portions can be used as variables. The GTA scripting environments already support arrays which access the local variables memory space:

1@ = 2 // assign index0@(1@,5i) = 3 // change the memory 8 bytes (4*index) from the address of 0@// 2@ now contains the value '3'

The 'array' is: 0@(1@,5i)

 

Where 0@ is the 'base variable offset' (whose address is used as the beginning of the array), 1@ is the index (determining how far into the array to access), '5' refers to the total size of the array (actually completely unused - any value works just the same) and 'i' specifies you're accessing the array indexes as 4 byte integers. Hence the formula is something like 'offset + sizeof(type) * index'.

 

SuperVars modifies their behaviour in order to make it more useful. Now, instead of only accessing local variable memory, you can access any memory using a similar syntax and many other tricks...

 

0@ = 0x100  // imaginary memory address0006: 0@(-2@,4s) = 0xDEADBEEF

Now, the 4 bytes at the memory address '0x108' contains the value '0xDEADBEEF'.

 

Here, everything works a bit differently...

 

0@(-2@,4s) - 0@ is now read, instead of it being turned into an address itself - the value it reads is instead treated as the start of the array

 

0@(-2@,4s) - Now, negative local variable indexes are treated as plain positive integer index (in this case '2') - which specifies that we're accessing the 3rd (as it starts from 0) array index.

 

0@(-2@,4s) - Now, the '4' refers to the size of the type we're trying to access. It was unused before, so now it has a legitimate purpose. In this case 4 means each index takes 4 bytes, and that is multiplied by the index to find the address to access. Most times this should be 4, because that's the only size the SCM script engine is capable of accessing using it's default operators.

 

0@(-2@,4s) - Finally, 's' is simply to specify it as a "SuperVar", making all this functionality work in the first place. Note, that this is usually used for string arrays. And in thinking that, Sanny Builder will try to compile it with string opcodes, unless you specify the correct opcodes to use. However, you can also go back to using regular arrays with 'i', 'f', or 'v' (for strings), but 's' can be used for all of those uses, anyway.

 

 

There are one or two slightly weird situations to get used to, however:

GET_VAR_POINTER 30@ STORE_TO 30@   // get memory address of 30@ - CLEO 4 opcode0007: 30@(30@,4s) = 0.00006: 30@(-1@,4s) = 5

Here, we're accessing 30@ and 31@. To access the '0 index' you need to use the same variable as an index as the one you used for an offset. Because -0@ would be the same as 0@ and then it would attempt to read 0@ for the index, instead.

 

Here's a more practical example. SuperVars will automatically convert labels to full addresses when used as base addresses so you can easily set up a label with usable memory following it and access it for more variables. Alternatively, you could use CLEO 4's ALLOCATE_MEMORY and use the resulting memory (which is more optimal 75% of the time)...

1@ = @VARIABLES0085: 2@ = 1@(1@,4s)   // reads '0xDEADBEEF' to 2@0085: 3@ = 1@(-1@,4s)   // reads '0xCAFEBABE' to 3@0085: 4@ = 1@(-2@,4s)   // reads '0x8BADF00D' to 4@0085: 5@ = 1@(-2@,4s)   // reads '0x00BAC0DE' to 5@TERMINATE_THIS_CUSTOM_SCRIPT:VARIABLESHEXEFBEADDE // index 0 "1@(1@,4s)"BEBAFECA // index 1 "1@(-1@,4s)"0DF0AD8B // index 2 "1@(-2@,4s)"DEC0BA00 // index 3, etc..END

[Trivial]

 

When I say "more optimal 75% of the time", I'm referring to how the start of :VARIABLES could be mis-aligned (not starting at a multiple of 4 bytes) and therefore would be slower for our computers to access. You could instead get the full address of @VARIABLES and round it down (don't forget to add at least 3 bytes of blank space before :VARIABLES, in that case) or use ALLOCATE_MEMORY, which is pretty much guaranteed to return an optimal base address for the computer running it.

 

[/Trivial]

 

 

There are some nicely written examples as part of the SuperVars archive and a more complete guide to its many uses. The examples include a flawless save system demonstrating a way to write SuperVar variables to a save-dependent file (since enable_thread_saving won't do that) and load it again when the script starts in a loaded game.

 

The examples also show you how to make it look easier to read...

GET_CHAR_HEALTH $PLAYER_ACTOR SVar[PlayerHealth]

 

// All this code is hurting my head...

000E: SVar[PlayerHealth] -= 10

SET_CHAR_HEALTH $PLAYER_ACTOR SVar[PlayerHealth]

 

And SuperVars also allows you to do crazy things like emulate C-like library for a basic object oriented language feel.

 

Note that SuperVars.asi will have to be installed on the users computer for it to work, but permission is given to distribute it with whatever you create. It's current version only supports 1.0 (badly need to update it). It's not the neatest solution, but the most stable way to access external memory directly, without memory reading and writing to and from variables every time you need to do something

 

 

 

Oh, yeah... one more thing. The limit of an index is -32768@, which can access memory as far as 4161536 bytes from the base address, I believe

Edited April 26, 2014 by Deji

[Silent]

OH what a lengthy post, EINSTEIN.

[J16D]

ahm this became more complex than should be xD

 

@fastman92 already gave you the solution

 

try this;

/// multiple thread in one .cs   /// give thanks to ZAZ for this{$CLEO}if0@ == 0jf @thread20000:while true if  Player.Defined($PLAYER_CHAR)then    if 0ADC: test_cheat "threads"    then        0ACA: show_text_box "on"        {        Load models        }        // This is Test1.cs        :Script_Test        wait 0 ms        009A: 5@ = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.0        0665: get_actor 5@ model_to 6@        09C7: change_player $PLAYER_CHAR model_to 6@ // now $PLAYER_CHAR is #SPECIAL10        wait 5 ms        009B: destroy_actor 5@        0A92: create_custom_thread "multi_thread.cs" 1 6@    /// 1 => 0@ /// 6@ => 1@ now this variable contain the model        wait 3000    endend wait 0end:thread2if0@ == 1jf @end_thread0000:0085: 6@ = 1@ // (int)   ///1@   contain the model//This is Test2.cs:Actionwait 0 03F0: enable_text_draw 1 045A: draw_text_1number 200.0 150.0 GXT 'NUMTXT' number 6@  // ALL RACES WON!~n~~w~$~1~if and02F2:   actor $PLAYER_ACTOR model == 6@00ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_footjf @Action017B: set_actor $PLAYER_ACTOR weapon 22 ammo_to 1003F0: enable_text_draw 0 :end_thread0A93: end_custom_thread

this should work, but if you still want separated .cs files;

///Main thread{$CLEO}0000:while true if  Player.Defined($PLAYER_CHAR)then    if 0ADC: test_cheat "threads"    then        0ACA: show_text_box "on"        {        Load models        }        // This is Test1.cs        :Script_Test        wait 0 ms        009A: 5@ = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.0        0665: get_actor 5@ model_to 6@        09C7: change_player $PLAYER_CHAR model_to 6@ // now $PLAYER_CHAR is #SPECIAL10        wait 5 ms        009B: destroy_actor 5@        0A92: create_custom_thread "thread1.cs" 6@  /// 6@ => 1@ now this variable contain the model        wait 50                while 10@ == 1  // thread1 running            0AAA: 10@ = thread 'thread1' pointer         wait 0        end                // thread1 is not running            endend wait 0end

/// thread 1/// the name of the file must be;  thread1.cs:thread2thread 'thread1'0085: 6@ = 1@ // (int)   ///1@   contain the model:Actionwait 0 03F0: enable_text_draw 1 045A: draw_text_1number 200.0 150.0 GXT 'NUMTXT' number 6@  // ALL RACES WON!~n~~w~$~1~if and02F2:   actor $PLAYER_ACTOR model == 6@00ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_footjf @Action017B: set_actor $PLAYER_ACTOR weapon 22 ammo_to 1003F0: enable_text_draw 0 :end_thread0A93: end_custom_thread

Edited April 27, 2014 by jayd00

[Deji]

 

ahm this became more complex than should be xD

 

@fastman92 already gave you the solution

 

try this;

<bad>

 

"Multiple scripts in one .cs" is bad for the reasons I already explained, read the entire thread.

 

Simply put, CLEO script files are not made to be ran as more than one script. There is no support for it and methods that work for the SCM will fail. Using tricks doesn't change the fact it's not meant to be done, and will cause heavy problems for the people who have to update CLEO to provide such features

 

But you only have to look at both CLEO and Sanny Builder documentations which have existed for years: One file - one script. CLEO only supports one script per file.

See 1) on "How do I write my own CLEO script?": http://cleo.li/scripts

 

If you want to start a totally different script in a totally different file, that is acceptable. But use it sparingly, because for each script you run, a large amount of memory has to be allocated to read that script file (which is why it's especially useless to launch the same script, wasting memory you're not going to use) whilst the game is running. This is in contrast to how the main.scm is mostly loaded at once during the loading screen and therefore creating a new script is much more inexpensive.

 

The only thing you get, is 'extra' temporary variable space. It's not like actually having extra variable space, because you can't use the other scripts variables from the current... you could emulate that yourself pretty easily and use wayy less memory:

ALLOCATE_MEMORY 120 31@     // 3 scripts * 10 vars * 4 bytes// note: you may want to NULLify the memory returned by ALLOCATE_MEMORY, as it may contain random pre-set values - or just initialise each variable (0@-9@) in each script before you use it. :MainLoopWAIT 00085: 30@ = 31@   // reset the, uh, 'stack'-like thing GOSUB @LoadSomeVariables    // load 10 vars for Script1GOSUB @Script1GOSUB @SaveSomeVariables    // save 10 of Script1's variables (0@-9@) GOSUB @LoadSomeVariables     // load 10 vars for Script2...GOSUB @Script2GOSUB @SaveSomeVariables    // save 10 of Script2's vars... GOSUB @LoadSomeVariablesGOSUB @Script3GOSUB @SaveSomeVariables GOTO MainLoop :SaveSomeVariables// push 10 variables to a memory space so we can load them again laterFOR 29@ = 0 TO 10    // [superVars Method]//  0085: 30@(29@,4s) = 20@(29@,4i)   // note: the second is not a SuperVar    // [/superVars Method]     // [slower Method]    WRITE_MEMORY 30@ 4 0@(29@,10i) FALSE    30@ += 4    // [/slower Method]ENDRETURN :LoadSomeVariables// read 10 variables from the current stack pointer // [if_using_slow_method]30@ += 40   // 10 vars * 4 bytes// [/if_using_slow_method] FOR 29@ = 10 TO 0    // [superVars Method]//  0085: 20@(29@,4i) = 30@(29@,4s)    // note: the first is not a SuperVar    // [/superVars Method]     // [slower Method]    30@ -= 4    READ_MEMORY 30@ 4 20@(29@,10i) FALSE    // [/slower Method]ENDRETURN

Forgive any coding mistakes as this is just a rough idea I wrote up in the post editor. Also it's 1AM...

 

For The Black Market Mod, a huge 5000+ line script, which was all packed into one script and I never have to worry about vars, I used many coding tricks (probably too many) to automate this process. It CALL'd each "script" when I added its label to a hex structure, and allowed me to write how many vars I needed for the routine actually in that script, so each script had however many extra vars (11@-24@ constant'd to VAR_1-VAR_14) I needed for it and no more. It also heavily used SuperVars which optimised the processes greatly. Direct moving of one memory location to another was also much easier, though more cryptic, than READ/WRITE_MEMORY and saved temporary variables. I also added some simple code to take care of timers, so each one could use it's own uniquely. I'd treat 0@-10@ as temporaries. And guess what? 24@-30@ weren't ever even used. I had my "global" variables as a memory allocation accessed via a SuperVar (address stored in 0@) which was capable of storing 64 vars that never changed use (only used 32 of those). Then I had another SuperVar (31@) which I stored all the things which should be saved to a file when the game was saved, with a capacity of 128 vars with only 78 in use (though there were some gaps as some were used as stat arrays for integer and float stats in the menu). Incredible things can be done when you stop over-valuing what the built-in variables actually are. A measly 4 bytes each, which are just easily accessible. That's all SuperVars does, really. Makes memory in different places more easily accessible. Still, you can do it the manual way nearly as well.

 

I'm sure that with some thought on this, everyone would be able to write their own self-managed scripts which store data it won't use for a while somewhere it can be accessed later. It's a simple idea, really. Not only do you get to save a range of variables and restore them later, you also still get access to any special variables you might want to access in all of the scripts (which seems to be more along the lines of what the OP actually requested) without much fuss.

Edited April 28, 2014 by Deji

[CharlesVercetti]

@fastman92 That's too difficult for me to understand. But I will try it.

His example was something near to including a header file on the c/cpp script.(You won't still understand.)

[In45do]

 

@fastman92 That's too difficult for me to understand. But I will try it.

His example was something near to including a header file on the c/cpp script.(You won't still understand.)

 

Do you?

[Silent]

Just recalled some old trick by @Deji to have multiple scripts in one .cs file without using START_NEW_CUSTOM_SCRIPT, so they actually share BaseIP (that is, the file doesn't get loaded in memory twice):

 

 

:TheScripts__StartNewScript{\__(void)__[nLabel, nParams, ...]__}0A9F: 32@ = current_thread_pointer32@ += 0x100A8D: 32@ = read_memory 32@ size 4 virtual_protect 00062: 32@ -= 0@0AA7: call_function 0x464C20 num_params 1 pop 1 32@ 33@005A: 32@ += 0@33@ += 0x100A8C: write_memory 33@ size 4 value 32@ virtual_protect 033@ += 0xB70A8C: write_memory 33@ size 1 value 0x1 virtual_protect 033@ += 0x20A8C: write_memory 33@ size 1 value 0x1 virtual_protect 033@ -= 0x8Dfor 32@ = 0 to 30    0A8C: write_memory 33@ size 4 value 1@(32@,1i) virtual_protect 0    33@ += 0x4end0AB2: ret 0

You call it with

 

 

0AB1: call_scm_func @TheScripts__StartNewScript 1 script @LABEL_TO_START_FROM

or, you can pass parameters just like with 'regular' opcodes:

 

 

0AB1: call_scm_func @TheScripts__StartNewScript 4 script @LABEL_TO_START_FROM params 20@ 5.0 6

@Deji, any thoughts?

[Deji]

@Deji, any thoughts?

Eiighh... it's fine conceptually. However, not only is it 1.0 EXE-dependent, unlike the method of basically setting up your own mini-script execution loop using purely SCM code and CLEO 4 opcodes, but you also have to remember the launched script is a SCM script and not a CLEO script...

 

You'll be very restricted by that fact:

1) You'll have to terminate it with 004E

2) The pool index of opcodes 0AE1, 0AE2 and 0AE3 aren't guaranteed to be saved after a WAIT, as for SCM scripts, the pool indexes are stored globally and not per-script (so in case another SCM script is using it, you need to be careful not to WAIT inside the loop or your search will get messed up)

3) No "thread saving", obviously

4) CLEO 4.3's new "script dependent drawing" will not work (it will share the same drawing space as the main.scm + script.img scripts)

5) No CLEO 3 compatibility mode!

6) 0A99 (chdir) will go back to affecting the entire game, not just the current script (so you MUST change the path back once you're finished)

*7) These are still limited to the maximum of 96 running scripts, of which many are already occupied by SCM scripts, unlike CLEO scripts which are theoretically unlimited

 

To put it simply, CCustomScript !== CRunningScript Every hack has consequences!

 

EDIT: *

Edited April 30, 2014 by Deji

[Deji]

 

@fastman92 That's too difficult for me to understand. But I will try it.

Do you?

 

 

Source file inclusion is pretty simple...

 

FileA.txt

 

WAIT 1{$I FileB.txt}  // or {$INCLUDE FileB.txt}WAIT 3

FileB.txt

 

WAIT 2

 

When you compile FileA.txt, the resulting compilation will of course decompile to...

 

WAIT 1WAIT 2WAIT 3

It just says "put the contents of this file into the source, right HERE". No funny business.

 

 

EDIT: FFS, I was editing my previous post, the quote should have gone into that!

Edited April 30, 2014 by Deji