Quantcast

Jump to content

» «
Photo

[SA] Multiple script but 1 purpose?

63 replies to this topic
In45do
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#1

Posted 06 April 2014 - 12:51 PM

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_Test
wait 0 ms
009A: 0@ = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.0
0665: get_actor 0@ model_to 1@
09C7: change_player $PLAYER_CHAR model_to 1@ // now $PLAYER_CHAR is #SPECIAL10
wait 5 ms
009B: destroy_actor 0@

//This is Test2.cs
:Action
wait 0 ms 
if and
02F2:   actor $PLAYER_ACTOR model == #SPECIAL10
00ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_foot
jf @Action
017B: 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
  • fastman92

    фастман92 | ف

  • Members
  • Joined: 28 Jul 2009
  • None
  • Contribution Award [Mods]

#2

Posted 06 April 2014 - 01:30 PM

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.
  • In45do likes this

Shmoopy
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#3

Posted 06 April 2014 - 07:21 PM

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_Test
create_thread @Action

// This is Test1.cs
:Script_Test
thread 'Script_Test'
wait 0 ms
009A: 0@ = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.0
0665: get_actor 0@ model_to 1@
09C7: change_player $PLAYER_CHAR model_to 1@ // now $PLAYER_CHAR is #SPECIAL10
wait 5 ms
009B: destroy_actor 0@
end_thread

//This is Test2.cs
:Action
thread 'Action'
wait 0 ms 
if and
02F2:   actor $PLAYER_ACTOR model == #SPECIAL10
00ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_foot
jf @Action
017B: set_actor $PLAYER_ACTOR weapon 22 ammo_to 10
end_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 likes this

In45do
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#4

Posted 09 April 2014 - 07:13 AM

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

 

Manfred Von Karma You mean both scripts compiled in the same thread in Sannybuilder?


Shmoopy
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#5

Posted 09 April 2014 - 12:12 PM Edited by Manfred Von Karma, 09 April 2014 - 12:13 PM.

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

 

Manfred Von Karma 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


In45do
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#6

Posted 09 April 2014 - 12:37 PM

Manfred Von Karma 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
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#7

Posted 09 April 2014 - 04:29 PM

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
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#8

Posted 10 April 2014 - 11:59 AM

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.  :dontgetit:


Shmoopy
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#9

Posted 10 April 2014 - 04:39 PM

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.zippysh...14159/file.html


In45do
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#10

Posted 11 April 2014 - 12:01 PM

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.zippysh...14159/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
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#11

Posted 11 April 2014 - 08:00 PM

I'll test it when i get home


In45do
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#12

Posted 13 April 2014 - 02:09 PM

I'll test it when i get home

So... have you test it?  :dontgetit: 
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
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#13

Posted 14 April 2014 - 10:26 AM

http://www42.zippysh...13989/file.html

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

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci
  • Joined: 24 Dec 2007
  • None
  • Contribution Award [Mods]

#14

Posted 22 April 2014 - 03:17 PM

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.:
:StaticMemory
HEX
// space for 10 long-life variables
00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000
END
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.gtagamin.../111-supervars/

Shmoopy
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#15

Posted 22 April 2014 - 03:47 PM

^

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
  • Silent

    Chief Fixing Officer

  • GTA Mods Staff
  • Joined: 01 Feb 2010
  • Poland
  • Contribution Award [Mods]
    Best Script/Plugin 2014 [SilentPatch]
    Most Respected 2014
    Most Helpful [Mods] 2014
    Most Helpful [GTA] 2013
    Most Helpful [Mods] 2013
    Most Talented [Modding] 2013
    Best Map 2013 [ViceCityStories PC Edition]
    Best Vehicle 2013 [III Aircraft]
    Most Helpful [Mods] 2012
    Modder of the Year 2012

#16

Posted 22 April 2014 - 07:57 PM

^
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?
  • In45do and Concavax like this

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci
  • Joined: 24 Dec 2007
  • None
  • Contribution Award [Mods]

#17

Posted 22 April 2014 - 08:01 PM

^
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.
  • Silent and Concavax like this

Shmoopy
  • Shmoopy

    Thug (͡ ͜ʖ ͡)

  • Members
  • Joined: 16 Jun 2009
  • None

#18

Posted 23 April 2014 - 10:34 AM

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

  • Deji likes this

Silent
  • Silent

    Chief Fixing Officer

  • GTA Mods Staff
  • Joined: 01 Feb 2010
  • Poland
  • Contribution Award [Mods]
    Best Script/Plugin 2014 [SilentPatch]
    Most Respected 2014
    Most Helpful [Mods] 2014
    Most Helpful [GTA] 2013
    Most Helpful [Mods] 2013
    Most Talented [Modding] 2013
    Best Map 2013 [ViceCityStories PC Edition]
    Best Vehicle 2013 [III Aircraft]
    Most Helpful [Mods] 2012
    Modder of the Year 2012

#19

Posted 23 April 2014 - 03:05 PM Edited by Silent, 23 April 2014 - 03:06 PM.

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.
  • aStiffSausage and Concavax like this

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci
  • Joined: 24 Dec 2007
  • None
  • Contribution Award [Mods]

#20

Posted 23 April 2014 - 07:24 PM

Instead, I liked your post and I will not quote it. I hope that's better for you :)
  • Concavax likes this

In45do
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#21

Posted 26 April 2014 - 03:29 AM

Manfred Von Karma 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'?  :dontgetit:


Deji
  • Deji

    Coding like a Rockstar!

  • Feroci
  • Joined: 24 Dec 2007
  • None
  • Contribution Award [Mods]

#22

Posted 26 April 2014 - 10:36 AM Edited by Deji, 26 April 2014 - 10:01 PM.

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

 

*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 index
0@(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 address
0006: 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 opcode
0007: 30@(30@,4s) = 0.0
0006: 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@ = @VARIABLES
0085: 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

:VARIABLES
HEX
EFBEADDE // index 0 "1@(1@,4s)"
BEBAFECA // index 1 "1@(-1@,4s)"
0DF0AD8B // index 2 "1@(-2@,4s)"
DEC0BA00 // index 3, etc..
END

[Trivial]

Spoiler

[/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 :p

  • fastman92, Silent and In45do like this

Silent
  • Silent

    Chief Fixing Officer

  • GTA Mods Staff
  • Joined: 01 Feb 2010
  • Poland
  • Contribution Award [Mods]
    Best Script/Plugin 2014 [SilentPatch]
    Most Respected 2014
    Most Helpful [Mods] 2014
    Most Helpful [GTA] 2013
    Most Helpful [Mods] 2013
    Most Talented [Modding] 2013
    Best Map 2013 [ViceCityStories PC Edition]
    Best Vehicle 2013 [III Aircraft]
    Most Helpful [Mods] 2012
    Modder of the Year 2012

#23

Posted 26 April 2014 - 06:40 PM

OH what a lengthy post, EINSTEIN.

jayd00
  • jayd00

    Rat

  • Members
  • Joined: 24 May 2008

#24

Posted 27 April 2014 - 10:35 PM Edited by jayd00, 27 April 2014 - 10:37 PM.

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}
if
0@ == 0
jf @thread2
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 "multi_thread.cs" 1 6@    /// 1 => 0@ /// 6@ => 1@ now this variable contain the model
        wait 3000
    end
end
 wait 0
end

:thread2
if
0@ == 1
jf @end_thread
0000:

0085: 6@ = 1@ // (int)   ///1@   contain the model
//This is Test2.cs
:Action
wait 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 and
02F2:   actor $PLAYER_ACTOR model == 6@
00ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_foot
jf @Action
017B: set_actor $PLAYER_ACTOR weapon 22 ammo_to 10
03F0: enable_text_draw 0 

:end_thread
0A93: 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
        
    end
end
 wait 0
end
/// thread 1
/// the name of the file must be;  thread1.cs
:thread2
thread 'thread1'

0085: 6@ = 1@ // (int)   ///1@   contain the model

:Action
wait 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 and
02F2:   actor $PLAYER_ACTOR model == 6@
00ED:   actor $PLAYER_ACTOR sphere 0 near_point 2043.68 -1635.73 radius 4.0 4.0 on_foot
jf @Action
017B: set_actor $PLAYER_ACTOR weapon 22 ammo_to 10
03F0: enable_text_draw 0 

:end_thread
0A93: end_custom_thread

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci
  • Joined: 24 Dec 2007
  • None
  • Contribution Award [Mods]

#25

Posted 28 April 2014 - 12:01 AM Edited by Deji, 28 April 2014 - 12:42 AM.

 

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 :p

 

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.
 
:MainLoop
WAIT 0
0085: 30@ = 31@   // reset the, uh, 'stack'-like thing
 
GOSUB @LoadSomeVariables    // load 10 vars for Script1
GOSUB @Script1
GOSUB @SaveSomeVariables    // save 10 of Script1's variables (0@-9@)
 
GOSUB @LoadSomeVariables     // load 10 vars for Script2...
GOSUB @Script2
GOSUB @SaveSomeVariables    // save 10 of Script2's vars...

 
GOSUB @LoadSomeVariables
GOSUB @Script3
GOSUB @SaveSomeVariables

 
GOTO MainLoop
 
:SaveSomeVariables
// push 10 variables to a memory space so we can load them again later
FOR 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]
END
RETURN
 
: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]
END
RETURN

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.

  • In45do likes this

CharlesVercetti
  • CharlesVercetti

    a.k.a TommyCJFaann

  • Members
  • Joined: 08 Dec 2013
  • India

#26

Posted 29 April 2014 - 11:07 AM

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
  • In45do

    Mack Pimp

  • Members
  • Joined: 15 Jan 2012
  • Indonesia

#27

Posted 30 April 2014 - 10:15 AM

 

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
  • Silent

    Chief Fixing Officer

  • GTA Mods Staff
  • Joined: 01 Feb 2010
  • Poland
  • Contribution Award [Mods]
    Best Script/Plugin 2014 [SilentPatch]
    Most Respected 2014
    Most Helpful [Mods] 2014
    Most Helpful [GTA] 2013
    Most Helpful [Mods] 2013
    Most Talented [Modding] 2013
    Best Map 2013 [ViceCityStories PC Edition]
    Best Vehicle 2013 [III Aircraft]
    Most Helpful [Mods] 2012
    Modder of the Year 2012

#28

Posted 30 April 2014 - 10:29 AM

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_pointer
32@ += 0x10
0A8D: 32@ = read_memory 32@ size 4 virtual_protect 0
0062: 32@ -= 0@

0AA7: call_function 0x464C20 num_params 1 pop 1 32@ 33@
005A: 32@ += 0@
33@ += 0x10
0A8C: write_memory 33@ size 4 value 32@ virtual_protect 0

33@ += 0xB7
0A8C: write_memory 33@ size 1 value 0x1 virtual_protect 0

33@ += 0x2
0A8C: write_memory 33@ size 1 value 0x1 virtual_protect 0
33@ -= 0x8D

for 32@ = 0 to 30
    0A8C: write_memory 33@ size 4 value 1@(32@,1i) virtual_protect 0
    33@ += 0x4
end

0AB2: 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? :p

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci
  • Joined: 24 Dec 2007
  • None
  • Contribution Award [Mods]

#29

Posted 30 April 2014 - 01:16 PM Edited by Deji, 30 April 2014 - 02:12 PM.

Deji, any thoughts? :p

 
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 :p Every hack has consequences!

EDIT: *

Deji
  • Deji

    Coding like a Rockstar!

  • Feroci
  • Joined: 24 Dec 2007
  • None
  • Contribution Award [Mods]

#30

Posted 30 April 2014 - 01:22 PM Edited by Deji, 30 April 2014 - 01:24 PM.

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 1
WAIT 2
WAIT 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! :p




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users