Jump to content

[SA] Multiple script but 1 purpose?


In45do

Recommended Posts

 

@Deji, any thoughts? :p

[long post]

 

Fair enough, you have to admit though it's relatively reliable :p

Link to comment
Share on other sites

Depends on what you're asking... I think we all lost track of an original question, heh :p

Link to comment
Share on other sites

@Silent Which mean multiple script but 1 purpose is possible through CLEO? :dontgetit:

 

Yeah, it's a confusing question. I mean, if you only have one purpose, you only need one script :p

 

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.

 

I assumed you meant that what you want to do is limited by the fact you have to do it only in one script, for which plenty of suggestions have been made to extend the abilities of that one script, instead of using multiple scripts which is less preferable anyway.

 

So you'll have to be a bit more clear on what you're trying to do and why one script isn't good enough... because one script is always good enough :p

 

I'm going to actually bookmark this thread since we've managed to cover one of the biggest problems in CLEO scripting in decent detail and I should be able to compile all the information down into tutorial or just link every person with similar problems to it.

Edited by Deji
Link to comment
Share on other sites

I guess my idea can't be done, isn't it? :bored:

I'll try alternative way through SuperVars like Deji suggest.

Link to comment
Share on other sites

I guess my idea can't be done, isn't it? :bored:

 

 

I think we're all struggling to know what your specific idea is...

Link to comment
Share on other sites

Midnightz

Hmm, I might know what he's/she's asking...

 

speedofiles.png

 

He/she maybe wants:

 

1. Multiple related threads to execute at the same time (or give the illusion of executing at the same time).

2. A base CS file that handles the initial checks for blah.

3. Additional CS files that will open/close based on the checks from within the base CS file. (or be read, as in the INI)

4. Possibly, these additional CS files to also communicate with (or manipulate vars in) the base CS file.

 

The above picture is of a speedometer mod with multiple on-screen gauges. It also includes a fuel mod that opens

gas stations. It is the best working example I've found that does many things at what "appears" to be, at once.

It's also the one mod that I can't completely customize to my liking. There's a var I just can't locate. :/

 

Anyway, this is what I think he's/she's aiming for in terms of file structure.

Edited by Midnightz
Link to comment
Share on other sites

4. Possibly, these additional CS files to also communicate with (or manipulate vars in) the base CS file.

That one. My English is bad, isn't it?

 

You can refer me as 'he'

Link to comment
Share on other sites

Again, that's what I explained in my posts. How to extend the script but have the base of the script still accessible by all parts. However, it's best to do this in the same file, rather than wasting so many script allocations on scripts with menial tasks.

Link to comment
Share on other sites

Midnightz

Memory-wise it may be ideal but if all is done within one file, you can not get multiple desired simultaneous effects - particularly if each requires its own set of conditions. For more complex threads or ones that are freaky busy, you have to use the file structure noted above. It may seem trivial to advanced coders, the whole sacrificing performance thing, but a lot of us are just trying to get the desired effect. Some of my mods, had to be multiple threads. :/

 

Link to a working code example of #4? :)

Link to comment
Share on other sites

A properly written single script is just as 'efficient' as multiple scripts, so you don't sacrifice anything.

Edited by Silent
Link to comment
Share on other sites

Midnightz

You're assuming something there. It is not possible for a single CS file to execute multiple tasks simultaneously - IF each of those tasks has their own set of conditions that are dependent on each other. I don't know how to explain it better, I just know it's a fact after presenting this problem to every advanced coder I know and having them all do the same thing: Rearrange the code in a way that breaks the intended goals of the thread, lol. I'm talking VERY busy threads here.

 

I would die of shock if anyone could get that speedometer mod in ONE CS file, WITHOUT sacrificing its behavior. Shock, I tell you. ;)

Edited by Midnightz
Link to comment
Share on other sites

It is not possible for a single CS file to execute multiple tasks simultaneously

So it's not possible for multiple CS files! They all execute one

after

another

.

Link to comment
Share on other sites

Midnightz

That's true BUT, with multiple files, you get the illusion of that which is sometimes needed. Example: drawing dashboard with gauges. If you tried to do that in one file, you can't monitor each gauge and change accordingly, at the same time. Individual CS files allow this.

Edited by Midnightz
Link to comment
Share on other sites

They can be pulled off with a single script aswell :p

Link to comment
Share on other sites

Midnightz

I've never seen anyone do it. :p In a few weeks, I will challenge you... ;)

Link to comment
Share on other sites

In a few weeks, I will challenge you... ;)

Sure thing.

Link to comment
Share on other sites

It is not possible for a single CS file to execute multiple tasks simultaneously

Multiple "CS files" aren't executed simultaneously. All scripts in the game are ran one-by-one in a queue. Therefore you'd be doing exactly the same thing by putting the code from them into one script, labeling them each and calling them one-by-one in a loop.

Link to comment
Share on other sites

Midnightz

I understand that but the tasks carried out seem instantaneous whereas in one file, there are delays IF you can even script it to do all. One file (no matter how structured) can't do all that's required of more complex threads. Imagine 25 tasks, each with their own loop and set of conditions, that need to occur simultaneously. This is especially true of mods that draw stuff on-screen. You're stuck in 1 loop before you can even run a different loop and THAT is the limit when using 1 CS file. Multiple files prevents this problem entirely and without any delays in execution. This has been my experience of it. I will gladly (in a few weeks) share some files to see if either of you can re-work them into 1 file WITHOUT losing the intended behavior of the mod. :)

Link to comment
Share on other sites

NO!

 

Yeah I'm going to get those files and rework just to prove our point :p

Edited by Silent
Link to comment
Share on other sites

I understand that but the tasks carried out seem instantaneous whereas in one file, there are delays IF you can even script it to do all. One file (no matter how structured) can't do all that's required of more complex threads. Imagine 25 tasks, each with their own loop and set of conditions, that need to occur simultaneously. This is especially true of mods that draw stuff on-screen. You're stuck in 1 loop before you can even run a different loop and THAT is the limit when using 1 CS file. Multiple files prevents this problem entirely and without any delays in execution. This has been my experience of it. I will gladly (in a few weeks) share some files to see if either of you can re-work them into 1 file WITHOUT losing the intended behavior of the mod. :)

"without any delays in execution"

 

Easily disprovable, even without taking in the fact that I recoded the CLEO 4 source for 4.3 and actually know how much extra code is running in-between scripts. You have this mis-conception that CLEO scripts run as their own thing, with CLEO just launching them. However, CLEO has to actually read, process and execute every command in your script via the games scripting engine, which will do XX other things each time.

 

See this...

 

fileA.cs:

 

 

0000: WHILE TRUE    WAIT 0    // do something #1END
fileC.cs:

 

 

 

 

 

0000: WHILE TRUE    WAIT 0    // do something #1END

It's identical to this:

fileZ.cs:

 

 

0000:WHILE TRUE    WAIT 0    // do something #1    // do something #2END

No code at all, really, however, fileZ will actually run faster. There's less overhead of CLEO and the scripting engine. If you look real closely you'll notice there's only one occurrence of WAIT, while using two scripts obviously ensues the use of two WAIT's. You assume "that's fine, because it's followed by a 0" *buzzer*, guess what! WAIT 0 doesn't actually wait for 0 milleseconds!

 

The WAIT command actually just sets a minimum amount of time to not execute that particular script for, and then returns to processing the rest of the game no matter what. WAIT 0 looks like an innocent little statement, but actually it's kind of a place-holder for PROCESS_THE_ENTIRE_GAME - horrible. You want as little of them as possible in your code. They should only occur once you've done everything you could possibly want to do. Once per loop? No, loops do not always require a WAIT, it simply depends on whether the lack of game processing would cause the loops logic to never break that loop. You only want a wait when you're literally waiting for something, otherwise it's like a monstrous plague causing your script to run very badly.

 

Imagine 25 tasks, each with their own loop and set of conditions

That's a bad way to imagine any code. This is a computer we're dealing with. It doesn't measure in tasks, see loops or get fatigued thinking "gee, this script is huge, I'm having a tough time with this". CLEO certainly isn't programmed to think like that. The only way your script might struggle with 25 tasks is if you struggle to write a script handling 25 tasks.

 

You're thinking inside the box, as a lot of CLEO scripters who don't have a decent understanding of programming concepts do. You seem to think there's only a limited number of ways to do things. Even I've recently discovered new programming concepts applicable to SCR, because it's a pretty decent language.

 

I imagine this is an ideal script scenario in your mind:

 

 

0000: :loop1WAIT 0if    00DF:   is_char_in_any_car $PLAYER_ACTORjf @loop2// do in-car stuffgoto @loop1 :loop2WAIT 0    // kill it! what are we actually waiting for?!if    80DF:   not is_char_in_any_car $PLAYER_ACTORjf @loop1// the WAIT would be better here, but it'd be way easier to only use one loop, one wait and do everything in-between on your own time// do not-in-car stuffgoto @loop2 :loop3WAIT 0   // ugh// another totally separate loop for some menugoto @loop3 :loop4WAIT 0   // this will probably be constantly processing the game in-between code that doesnt need to wait, which can cause 'laggy' script// another totally separate loop for a confirmation screen for the menugoto @loop4

I see that too often. People seem to prefer little "manageable" loops which end up doing ridiculous amounts of jumping around. Addiction to loops deserves a serious convention, because even R* preferred one loop per-script and instead using sub-routines and variables to keep track of what needed to be done next.

 

Take loading a model. So many people do something like this:

 

 

// [\code to draw a speedometer] // stupid BB code parser did something weird with this 0247: request_model #TAXIWHILE 8248:   not has_model_loaded #TAXI    WAIT 0END.

Then later on, they encounter a problem. They wanted to draw something constantly on screen (a speedometer, for example), yet every time that model has to load, the script enters an un-necessary extra loop which keeps the rest of the script from running. This is where your argument would appear valid, as WAIT 0 would (as well as processing the entire rest of the game for no reason) process a different script while that model is loading - but you don't need to use another script, the problem is that you're keeping the rest of the current script from running, so instead of working around that problem by adding another script, you think, think, think and think, and eventually you might unknowingly come up with some of the most basic programming concepts of all time, and write something like this:

 

0000:0@ = 0    // taxi_creation_stage = initial WHILE TRUE    WAIT 0    // [draw speedometer]     IF 0@ == 0   // taxi_creation_stage == initial    THEN        // or think - we could even assume a model ID to load was stored in 2@ and use that for all the code below - allowing us to re-use this        // code for ANY model loading - which is way more efficient than setting up multiple loops!        LOAD_MODEL #TAXI        0@ = 1   // taxi_creation_stage = loading_model    END    IF 0@ == 1   // taxi_creation_stage == loading_model    THEN         IF HAS_MODEL_LOADED #TAXI         THEN             // you probably want to create it now, or something - by the way, the speedometer code hasn't been delayed once during this process!             0@ = 2   // taxi_creation_stage = created         ELSE             // this is a nice way to check if your code is running consistently, by the way             // if the text stutters, it's because the PRINT_STRING command isn't being run on every frame, because you're using too many WAITs!             PRINT_STRING "Loading..." time 1         END    END    IF 0@ == 2   // taxi_creation_stage == created        IF IS_CAR_DEAD 1@            0@ = 3   // taxi_creation_stage = unload        ELSE             // this is where you put code to only execute while the vehicle exists             // get what we're doing? we're splitting code down into "states" using nested constructs (an alien concept to some)             // all our code gets an equal time running and is only executed when needed - which is the best thing you can ask for        END    END    IF 0@ == 3   // taxi_creation_stage == unload        // we need to put everything back the way it was when 0@ was 0 - this is essentially a gradual loop - yet, we only needed one WAIT!        DELETE_CAR 1@        RELEASE_MODEL #TAXI        0@ = 0    // see, see! this is like jumping back to an "initial" loop - yet there are actually no loops because they're unnecessary!    ENDEND

(It looks much like many scripts in the main.scm do before they're compiled.)

 

Ah, but now you may be thinking "but that used an extra variable!" - if so, go back to my previous posts where I pointed out there are in fact more than enough variables to do everything with the help of CLEO opcodes or SuperVars. But even without those, you always have enough variables to do at least 31 'tasks' which don't require more than one shared variable overall or 30 'tasks' that use 2 shared variables, etc. However, since the limit on variables is so easily gotten past with CLEO or SuperVars or both, it's easy to run an indefinite number of scripts with an indefinite number of variables. You can pretty it up or make it more efficient with sub-routines or jump tables. You can automate certain sections. You can easily add code which runs while "0@ == init OR 0@ == loading". You can use CALL (0AB1) to pass certain params, do calculations which would use temporary variables and generally re-use the same code for many different purposes.

 

What CLEO provides is simple, but what you can do with it is infinite (as in infinite monkey).

Edited by Silent
Link to comment
Share on other sites

To spice the topic, 99% of the native code (gta_sa.exe) runs in a single thread, in a huge loop divided in sub routines (what you'd call tasks), the exceptions are the resources loading and radio streaming

Edited by LINK/2012
Link to comment
Share on other sites

To spice the topic, 99% of the native code (gta_sa.exe) runs in a single thread, in a huge loop divided in sub routines (what you'd call tasks), the exceptions are the resources loading and radio streaming

 

I'm aware of that and of pretty much everything he just said above your post. This is not my first barbecue folks. After finals, I will provide more info.

Link to comment
Share on other sites

To spice the topic, 99% of the native code (gta_sa.exe) runs in a single thread, in a huge loop divided in sub routines (what you'd call tasks), the exceptions are the resources loading and radio streaming

Which is why radio will still play if your script enters this loop:

 

 

:loopgoto @loop
Edited by fastman92
Link to comment
Share on other sites

No code at all, really, however, fileZ will actually run faster.

And another positive aspect of this is, you can actually control the order in which stuff's executed, whereas I wouldn't EVER make any assumptions about the order different CLEO scripts are executed.

 

 

 

This is not my first barbecue folks. After finals, I will provide more info.

I guess everyone in the thread knows this, that's why people provide explainations instead of We're right, you're wrong - get over it. approach.

Edited by Silent
Link to comment
Share on other sites

  • 1 month later...

I'm learning fastman92 technique at first post. And I'm still testing. (I'm too slow to learn new things :bored: )
This time I'm using opcode 0AB3 and 0AB4. Is this script do exactly what I want? I'm sorry to bring this topic back up.

{$CLEO .cs}:Script1cs03A4: name_thread "Script1":Spawnwait 0 msif0256:   player $PLAYER_CHAR definedjf @Spawn023C: load_special_actor 'TENPEN' as 1 // models 290-299:Checkwait 0 msif023D:   special_actor 1 loadedjf @Check009A: 0@ = create_actor_pedtype 8 model #SPECIAL01 at 213.493 374.339 26.2397  // random coords0223: set_actor 0@ health_to 25000006: 1@ = 0@0AB3: var 455 = 1@0A93: end_custom_thread----------------------------------------------------------------------------{$CLEO .cs}:Script2cs03A4: name_thread "Script2":Put_Actorwait 0 ms0AB4: 1@ = var 455if056D:   actor 1@ definedjf @Put_Actor00A1: put_actor 1@ at 345.5621 306.2212 998.44840A93: end_custom_thread
Link to comment
Share on other sites

Try to learn from connected cleo files like the one in final pimp my car by ZAZ it's a great mod.

Edited by Naruko
Link to comment
Share on other sites

I'm way too tired, so maybe I'm missing something obvious here, but...

 

Doesn't Test1 communicate with Test2 by changing the model? Test1 "writes" the model and Test2 reads the model.; communication complete.

Link to comment
Share on other sites

Try to learn from connected cleo files like the one in final pimp my car by ZAZ it's a great mod.

I don't like to see other people script.

 

Test1 "writes" the model and Test2 reads the model.; communication complete.

And how does it works? I had test it but it didn't work.

Link to comment
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

×
×
  • Create New...

Important Information

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