Silent Posted April 30, 2014 Share Posted April 30, 2014 @Deji, any thoughts? [long post] Fair enough, you have to admit though it's relatively reliable Link to comment Share on other sites More sharing options...
In45do Posted May 1, 2014 Author Share Posted May 1, 2014 @Silent Which mean multiple script but 1 purpose is possible through CLEO? Link to comment Share on other sites More sharing options...
Silent Posted May 1, 2014 Share Posted May 1, 2014 Depends on what you're asking... I think we all lost track of an original question, heh Link to comment Share on other sites More sharing options...
Deji Posted May 1, 2014 Share Posted May 1, 2014 (edited) @Silent Which mean multiple script but 1 purpose is possible through CLEO? Yeah, it's a confusing question. I mean, if you only have one purpose, you only need one script 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 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 May 1, 2014 by Deji Link to comment Share on other sites More sharing options...
In45do Posted May 3, 2014 Author Share Posted May 3, 2014 I guess my idea can't be done, isn't it? I'll try alternative way through SuperVars like Deji suggest. Link to comment Share on other sites More sharing options...
Deji Posted May 3, 2014 Share Posted May 3, 2014 I guess my idea can't be done, isn't it? I think we're all struggling to know what your specific idea is... Link to comment Share on other sites More sharing options...
Midnightz Posted May 3, 2014 Share Posted May 3, 2014 (edited) Hmm, I might know what he's/she's asking... 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 May 3, 2014 by Midnightz Link to comment Share on other sites More sharing options...
In45do Posted May 6, 2014 Author Share Posted May 6, 2014 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 More sharing options...
Deji Posted May 6, 2014 Share Posted May 6, 2014 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. In45do 1 Link to comment Share on other sites More sharing options...
Midnightz Posted May 6, 2014 Share Posted May 6, 2014 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 More sharing options...
Silent Posted May 6, 2014 Share Posted May 6, 2014 (edited) A properly written single script is just as 'efficient' as multiple scripts, so you don't sacrifice anything. Edited May 6, 2014 by Silent Link to comment Share on other sites More sharing options...
Midnightz Posted May 6, 2014 Share Posted May 6, 2014 (edited) 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 May 6, 2014 by Midnightz Link to comment Share on other sites More sharing options...
Silent Posted May 6, 2014 Share Posted May 6, 2014 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 More sharing options...
Midnightz Posted May 6, 2014 Share Posted May 6, 2014 (edited) 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 May 6, 2014 by Midnightz Link to comment Share on other sites More sharing options...
Silent Posted May 6, 2014 Share Posted May 6, 2014 They can be pulled off with a single script aswell Link to comment Share on other sites More sharing options...
Midnightz Posted May 6, 2014 Share Posted May 6, 2014 I've never seen anyone do it. In a few weeks, I will challenge you... Silent 1 Link to comment Share on other sites More sharing options...
Silent Posted May 6, 2014 Share Posted May 6, 2014 In a few weeks, I will challenge you... Sure thing. Midnightz 1 Link to comment Share on other sites More sharing options...
Deji Posted May 9, 2014 Share Posted May 9, 2014 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 More sharing options...
Midnightz Posted May 9, 2014 Share Posted May 9, 2014 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 More sharing options...
Silent Posted May 9, 2014 Share Posted May 9, 2014 (edited) NO! Yeah I'm going to get those files and rework just to prove our point Edited May 9, 2014 by Silent Link to comment Share on other sites More sharing options...
Midnightz Posted May 9, 2014 Share Posted May 9, 2014 Link to comment Share on other sites More sharing options...
Deji Posted May 9, 2014 Share Posted May 9, 2014 (edited) 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 May 10, 2014 by Silent Link2012, Seemann, savidge and 1 other 4 Link to comment Share on other sites More sharing options...
Link2012 Posted May 10, 2014 Share Posted May 10, 2014 (edited) 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 May 10, 2014 by LINK/2012 Link to comment Share on other sites More sharing options...
Midnightz Posted May 10, 2014 Share Posted May 10, 2014 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 More sharing options...
fastman92 Posted May 10, 2014 Share Posted May 10, 2014 (edited) 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 May 10, 2014 by fastman92 Link to comment Share on other sites More sharing options...
Silent Posted May 10, 2014 Share Posted May 10, 2014 (edited) 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 May 10, 2014 by Silent Link to comment Share on other sites More sharing options...
In45do Posted June 21, 2014 Author Share Posted June 21, 2014 I'm learning fastman92 technique at first post. And I'm still testing. (I'm too slow to learn new things )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 More sharing options...
Naruko Posted June 21, 2014 Share Posted June 21, 2014 (edited) Try to learn from connected cleo files like the one in final pimp my car by ZAZ it's a great mod. Edited June 21, 2014 by Naruko Link to comment Share on other sites More sharing options...
OrionSR Posted June 21, 2014 Share Posted June 21, 2014 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 More sharing options...
In45do Posted June 21, 2014 Author Share Posted June 21, 2014 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now