Quantcast
Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
    1. Welcome to GTAForums!

    1. Red Dead Redemption 2

      1. Gameplay
      2. Missions
      3. Help & Support
    2. Red Dead Online

      1. Gameplay
      2. Find Lobbies & Outlaws
      3. Help & Support
    1. Crews & Posses

      1. Recruitment
    2. Events

    1. GTA Online

      1. Arena War
      2. After Hours
      3. Find Lobbies & Players
      4. Guides & Strategies
      5. Vehicles
      6. Content Creator
      7. Help & Support
    2. Grand Theft Auto Series

    3. GTA Next

    4. GTA V

      1. PC
      2. Guides & Strategies
      3. Help & Support
    5. GTA IV

      1. Episodes from Liberty City
      2. Multiplayer
      3. Guides & Strategies
      4. Help & Support
      5. GTA Mods
    6. GTA Chinatown Wars

    7. GTA Vice City Stories

    8. GTA Liberty City Stories

    9. GTA San Andreas

      1. Guides & Strategies
      2. Help & Support
      3. GTA Mods
    10. GTA Vice City

      1. Guides & Strategies
      2. Help & Support
      3. GTA Mods
    11. GTA III

      1. Guides & Strategies
      2. Help & Support
      3. GTA Mods
    12. Top Down Games

      1. GTA Advance
      2. GTA 2
      3. GTA
    13. Wiki

      1. Merchandising
    1. GTA Modding

      1. GTA V
      2. GTA IV
      3. GTA III, VC & SA
      4. Tutorials
    2. Mod Showroom

      1. Scripts & Plugins
      2. Maps
      3. Total Conversions
      4. Vehicles
      5. Textures
      6. Characters
      7. Tools
      8. Other
      9. Workshop
    3. Featured Mods

      1. DYOM
      2. OpenIV
      3. GTA: Underground
      4. GTA: Liberty City
      5. GTA: State of Liberty
    1. Red Dead Redemption

    2. Rockstar Games

    1. Off-Topic

      1. General Chat
      2. Gaming
      3. Technology
      4. Programming
      5. Movies & TV
      6. Music
      7. Sports
      8. Vehicles
    2. Expression

      1. Graphics / Visual Arts
      2. GFX Requests & Tutorials
      3. Writers' Discussion
      4. Debates & Discussion
    1. News

    2. Forum Support

    3. Site Suggestions

In45do

[SA] Multiple script but 1 purpose?

Recommended Posts

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: [email protected] = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.00665: get_actor [email protected] model_to [email protected]: change_player $PLAYER_CHAR model_to [email protected] // now $PLAYER_CHAR is #SPECIAL10wait 5 ms009B: destroy_actor [email protected]//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?

Share this post


Link to post
Share on other sites
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 [email protected]
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 [email protected]

 

Likewise, +0x40 will be an offset to local variable [email protected]

 

3. CLEO shared vars

 

0AB3: set_cleo_shared_var 0 to 10
0AB4: get_shared_cleo_var 0 store_to [email protected]
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.

Share this post


Link to post
Share on other sites
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: [email protected] = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.00665: get_actor [email protected] model_to [email protected]: change_player $PLAYER_CHAR model_to [email protected] // now $PLAYER_CHAR is #SPECIAL10wait 5 ms009B: destroy_actor [email protected]_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 )

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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 [email protected] ) 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 ( [email protected] ) , instead you should use something like $Actor

Edited by Manfred Von Karma

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 .

Share this post


Link to post
Share on other sites
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. :dontgetit:

Share this post


Link to post
Share on other sites
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 [email protected] modelCRC_to [email protected] // Torso texture [email protected] and model [email protected]

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

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

Share this post


Link to post
Share on other sites
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 [email protected] modelCRC_to [email protected] // Torso texture [email protected] and model [email protected]

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.

Share this post


Link to post
Share on other sites
Shmoopy

I'll test it when i get home

Share this post


Link to post
Share on other sites
In45do

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.

Share this post


Link to post
Share on other sites
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 [email protected]
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, [email protected] 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/

Share this post


Link to post
Share on other sites
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 .

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Shmoopy

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

Share this post


Link to post
Share on other sites
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 by Silent

Share this post


Link to post
Share on other sites
Deji

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

Share this post


Link to post
Share on other sites
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'? :dontgetit:

Share this post


Link to post
Share on other sites
Deji

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

[email protected] = 2 // assign [email protected]([email protected],5i) = 3 // change the memory 8 bytes (4*index) from the address of [email protected]// [email protected] now contains the value '3'

The 'array' is: [email protected]([email protected],5i)

 

Where [email protected] is the 'base variable offset' (whose address is used as the beginning of the array), [email protected] 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...

 

[email protected] = 0x100  // imaginary memory address0006: [email protected]([email protected],4s) = 0xDEADBEEF

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

 

Here, everything works a bit differently...

 

[email protected]([email protected],4s) - [email protected] 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

 

[email protected]([email protected],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.

 

[email protected]([email protected],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.

 

[email protected]([email protected],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 [email protected] STORE_TO [email protected]   // get memory address of [email protected] - CLEO 4 opcode0007: [email protected]([email protected],4s) = 0.00006: [email protected]([email protected],4s) = 5

Here, we're accessing [email protected] and [email protected] To access the '0 index' you need to use the same variable as an index as the one you used for an offset. Because [email protected] would be the same as [email protected] and then it would attempt to read [email protected] 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)...

[email protected] = @VARIABLES0085: [email protected] = [email protected]([email protected],4s)   // reads '0xDEADBEEF' to [email protected]: [email protected] = [email protected]([email protected],4s)   // reads '0xCAFEBABE' to [email protected]: [email protected] = [email protected]([email protected],4s)   // reads '0x8BADF00D' to [email protected]: [email protected] = [email protected]([email protected],4s)   // reads '0x00BAC0DE' to [email protected]_THIS_CUSTOM_SCRIPT:VARIABLESHEXEFBEADDE // index 0 "[email protected]([email protected],4s)"BEBAFECA // index 1 "[email protected]([email protected],4s)"0DF0AD8B // index 2 "[email protected]([email protected],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 [email protected], which can access memory as far as 4161536 bytes from the base address, I believe :p

Edited by Deji

Share this post


Link to post
Share on other sites
Silent

OH what a lengthy post, EINSTEIN.

Share this post


Link to post
Share on other sites
jayd00

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}[email protected] == 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: [email protected] = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.0        0665: get_actor [email protected] model_to [email protected]        09C7: change_player $PLAYER_CHAR model_to [email protected] // now $PLAYER_CHAR is #SPECIAL10        wait 5 ms        009B: destroy_actor [email protected]        0A92: create_custom_thread "multi_thread.cs" 1 [email protected]    /// 1 => [email protected] /// [email protected] => [email protected] now this variable contain the model        wait 3000    endend wait 0end:[email protected] == 1jf @end_thread0000:0085: [email protected] = [email protected] // (int)   ///[email protected]   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 [email protected]  // ALL RACES WON!~n~~w~$~1~if and02F2:   actor $PLAYER_ACTOR model == [email protected]:   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: [email protected] = create_actor_pedtype 4 model #SPECIAL10 at 0.0 0.0 0.0        0665: get_actor [email protected] model_to [email protected]        09C7: change_player $PLAYER_CHAR model_to [email protected] // now $PLAYER_CHAR is #SPECIAL10        wait 5 ms        009B: destroy_actor [email protected]        0A92: create_custom_thread "thread1.cs" [email protected]  /// [email protected] => [email protected] now this variable contain the model        wait 50                while [email protected] == 1  // thread1 running            0AAA: [email protected] = 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: [email protected] = [email protected] // (int)   ///[email protected]   contain the model:Actionwait 0 03F0: enable_text_draw 1 045A: draw_text_1number 200.0 150.0 GXT 'NUMTXT' number [email protected]  // ALL RACES WON!~n~~w~$~1~if and02F2:   actor $PLAYER_ACTOR model == [email protected]:   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 by jayd00

Share this post


Link to post
Share on other sites
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 :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 [email protected]     // 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 ([email protected]@) in each script before you use it. :MainLoopWAIT 00085: [email protected] = [email protected]   // reset the, uh, 'stack'-like thing GOSUB @LoadSomeVariables    // load 10 vars for Script1GOSUB @Script1GOSUB @SaveSomeVariables    // save 10 of Script1's variables ([email protected]@) 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 [email protected] = 0 TO 10    // [superVars Method]//  0085: [email protected]([email protected],4s) = [email protected]([email protected],4i)   // note: the second is not a SuperVar    // [/superVars Method]     // [slower Method]    WRITE_MEMORY [email protected] 4 [email protected]([email protected],10i) FALSE    [email protected] += 4    // [/slower Method]ENDRETURN :LoadSomeVariables// read 10 variables from the current stack pointer // [if_using_slow_method][email protected] += 40   // 10 vars * 4 bytes// [/if_using_slow_method] FOR [email protected] = 10 TO 0    // [superVars Method]//  0085: [email protected]([email protected],4i) = [email protected]([email protected],4s)    // note: the first is not a SuperVar    // [/superVars Method]     // [slower Method]    [email protected] -= 4    READ_MEMORY [email protected] 4 [email protected]([email protected],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 ([email protected]@ 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 [email protected]@ as temporaries. And guess what? [email protected]@ weren't ever even used. I had my "global" variables as a memory allocation accessed via a SuperVar (address stored in [email protected]) which was capable of storing 64 vars that never changed use (only used 32 of those). Then I had another SuperVar ([email protected]) 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 by Deji

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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: [email protected] = [email protected] += 0x100A8D: [email protected] = read_memory [email protected] size 4 virtual_protect 00062: [email protected] -= [email protected]: call_function 0x464C20 num_params 1 pop 1 [email protected] [email protected]: [email protected] += [email protected]@ += 0x100A8C: write_memory [email protected] size 4 value [email protected] virtual_protect [email protected] += 0xB70A8C: write_memory [email protected] size 1 value 0x1 virtual_protect [email protected] += 0x20A8C: write_memory [email protected] size 1 value 0x1 virtual_protect [email protected] -= 0x8Dfor [email protected] = 0 to 30    0A8C: write_memory [email protected] size 4 value [email protected]([email protected],1i) virtual_protect 0    [email protected] += 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 [email protected] 5.0 6

@Deji, any thoughts? :p

Share this post


Link to post
Share on other sites
Deji

@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: *

Edited by Deji

Share this post


Link to post
Share on other sites
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! :p

Edited by Deji

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • 1 User Currently Viewing
    0 Members, 0 Anonymous, 1 Guest

×

Important Information

By using GTAForums.com, you agree to our Terms of Use and Privacy Policy.