Problem with 0AB1 in Cleo 4.3

[goodidea82]

The opcode 0AB1 calls an scm script. In Cleo 4.3 it has been "fixed", but I think it's broken now. Since, this is related to the cleo update, I have posted the issue here:

http://gtaforums.com/topic/674029-sarel-cleo-43/?p=1067445516

Because of this issue all my mods are broken now.

 

(I'm writing this thread because in one hour it will be impossible to find it in the scripting section due to the number of gta5 topics over there)

[Silent]

Already reported this to Deji since for me this has been causing crashes. Dunno when will be fixed, though.

[goodidea82]

Finally I have tested 4.3.18 and it has exactly the same bug as described here: http://gtaforums.com...3/?p=1067445516

 

(double posting so this will not get lost in the other subforum)

[goodidea82]

Until the bug gets fixed I recommend you guys put this in your CLEO code.

At the beginning for your CM-script and CS-script write

gosub @Test0AB1and0AB2

Be aware that the variables [email protected]@ have to be initilized after this call.

Since the first variables may hold parameters, alternatively use:

gosub @Test0AB1and0AB2_BackupParams

In this case [email protected]@ have to be inizilized again after this call.

 

At the end of your script paste the following:

 

 

 

//###########################################################################//###########################################################################//###########################################################################const  V0 =  [email protected]     V1 =  [email protected]  V2 =  [email protected]  V3 =  [email protected]  V20 = [email protected]  V21 = [email protected]  V22 = [email protected]  V23 = [email protected]  V0 : Integer  V1 : Integer  V2 : Integer  V3 : Integer  V20 : Integer  V21 : Integer  V22 : Integer  V23 : Integerend//-------------------------------------------------------------------------//This function must be called via gosub//Warning: this function overwrites the variables [email protected]@. Reinitialise them after this call.:Test0AB1and0AB2_BackupParams    V20 = V0        V21 = V1        V22 = V2        V23 = V3    gosub @Test0AB1and0AB2    V0 = V20        V1 = V21        V2 = V22        V3 = V23        return//-------------------------------------------------------------------------//This function must be called via gosub//Warning: this function overwrites the variables [email protected]@. Reinitialise them after this call.:Test0AB1and0AB2    V0=300    V1=301    V2=302    V3=0        0AB1: call_scm_func @Test0AB1and0AB2_scm_func1 3 441 442 443  V3        if or        not V0==300        not V1==301        not V2==302        not V3==666    then        if or            not V0==300            not V1==301            not V2==302        then            0662: write_debug_message "ERROR 3" //In case 0AD1 does not work                   0AD1: show_formatted_text_highpriority "CLEO ERROR 3: 0AB2 memory not restored. This CLEO version has a bug. Install a different CLEO version." time 10000            wait 10000                        end           if            not V3==666        then            0662: write_debug_message "ERROR 4" //In case 0AD1 does not work                   0AD1: show_formatted_text_highpriority "CLEO ERROR 4: 0AB2 incorrect return value. This CLEO version has a bug. Install a different CLEO version." time 10000            wait 10000                        end        059A:  return_false        return    end    // Now repleat the same test. There is an error where the test behaves differently when being executed again!        V0=300    V1=301    V2=302    V3=0        0AB1: call_scm_func @Test0AB1and0AB2_scm_func1 3 441 442 443  V3        if or        not V0==300        not V1==301        not V2==302        not V3==666    then        if or            not V0==300            not V1==301            not V2==302        then            0662: write_debug_message "ERROR 5" //In case 0AD1 does not work                           0AD1: show_formatted_text_highpriority "CLEO ERROR 5: 0AB2 memory not restored. This CLEO version has a bug. Install a different CLEO version." time 10000            wait 10000                        end           if            not V3==666        then            0662: write_debug_message "ERROR 6" //In case 0AD1 does not work                            0AD1: show_formatted_text_highpriority "CLEO ERROR 6: 0AB2 incorrect return value. This CLEO version has a bug. Install a different CLEO version." time 10000            wait 10000                        end        059A:  return_false        return    end        0485:  return_true    //reset values    V0=0        V1=0        V2=0        V3=0    return//-------------------------------------------------------------------------:Test0AB1and0AB2_scm_func1    if or        not V0==441        not V1==442        not V2==443    then        0662: write_debug_message "ERROR 1" //In case 0AD1 does not work                            0AD1: show_formatted_text_highpriority "CLEO ERROR 1: 0AB1 parameters not passed. This CLEO version has a bug. Install a different CLEO version." time 10000        wait 10000    end        V0=555    V1=555    V2=555    0AB2: ret 1 666      0662: write_debug_message "ERROR 2" //In case 0AD1 does not work                    0AD1: show_formatted_text_highpriority "CLEO ERROR 2: 0AB2 does not return. This CLEO version has a bug. Install a different CLEO version." time 10000    wait 10000    return  

 

 

Edited September 20, 2015 by goodidea82

[Deji]

Nice, though it'd probably be nicer to write a simple CLEO plugin to address the issue.

 

But to be frank, I can't see how this bug which only affects CLEO mission SCM funcs, which are relatively pointless and inefficient compared to GOSUB's given a CLEO missions huge variable range (just use [email protected]@ as working variables for the CALL or GOSUB and as per convention use [email protected]+ as mission variables, which you can read from the SCM func), is less favourable than the tonne's of bugs and bad execution in CLEO 4.1 for writing scripts... which will also force you to write code which will require compatibility mode in future versions of CLEO and is basically invalid. If your users have the choice of tonne's of bugs and way fewer working mods or not using your new mod which could have easily just been written a little different, what do you think they will choose?

 

Considering you gave me a suggestion for micro-optimising a small part of 4.2, I'd have thought you would have seen how calling a SCM function, which may require allocating memory to temporarily store the current variables, then copying memory both ways and creating a new script which runs for a very short period of time, is much less optimal than a simple GOSUB which is simply a GOTO that saves an already allocated stack and is able to access mission variables via static memory, which are simple read/write ops that don't do more than you write - whereas with CALL's you're doing operations with memory you're not even going to use. It's simple stuff, man!

Edited September 25, 2015 by Deji

[goodidea82]

I use SCM calls for vector transformations and these functions are called frequently in my scripts. The transformation functions have sets of built-in matrices (for different locations) hence these are not standard functions as offered by some cleo-plugins. I use SCM calls for the following reasons. (1) In CS scripts I don't have enough variables so I can't use GOSUB for these functions (that's also the reason why the matrices are built-in (I only pass the index which one I need in a call). My CM scripts also require the same functions, hence, I use the same functions in CM as in CS. (2) Of course I also though about dublicating the functions in CM based on GOSUB. However, passing parameters and reading return values via assingments is a problem because these calls appear very often and the code becomes hard to manage and understand. However, your suggestion is helpful, because I can solve the second problem (in CM only) by using macros to hide the code that would surround the GOSUB.

 

>Nice, though it'd probably be nicer to write a simple CLEO plugin to address the issue.

Indeed that's a possibility. The only disadvantage would be that it cannot be as easily ported to mobile.and there is the small risk that two plugins may use the same opcode numbers for different purpose. Another possibility is also to use DKs SDK instad of cleo which would lead to much better code but sacraficing portability and the possibility that users can decompile the code.

[Deji]

I use SCM calls for the following reasons. (1) In CS scripts I don't have enough variables so I can't use GOSUB for these functions (that's also the reason why the matrices are built-in (I only pass the index which one I need in a call).

Wrong. 8 variables would be plenty for a CS script, 32 is overkill

 

As with anyone who complains about lack of variables in scripts, you simply need to look into smarter ways to handle memory, such as dynamically allocated data and treating memory as objects instead of just using every variable to store every individual value in a dedicated way. CLEO 4 provides so many things for this which barely anyone even uses (I mean c'mon ALLOCATE_MEMORY alone basically solves every single problem with memory limits you could think of), yet will use many other nasty tricks to get around the problem in the most direct way possible.

 

I guess I'm lucky I learned programming well enough to understand the concepts of creating applications rather than 'scripts', but if you've already learned enough about scripting to want more power, then you're ready to be learning how to provide it for yourself. This issue reminds me of some similar things in PHP development - where basically, users have to be forced to do things right and given a kick in the right direction - they won't learn until they're forced to, so we have to take the easier options away from them so they'll bother to do that learning.

 

There are solutions for this already, such as SuperVars and it's 'Objective-SCM' companion which allows memory to be treated as strongly typed objects. But really they're just more convenient and optimal solutions to solutions that already existed on some level.

 

I'd recommend treating SCM Functions as tools for extra convenience rather than the only tools for the job.

 

Additionally... SCM Functions are working normally in CS scripts in 4.3, right?

 

My CM scripts also require the same functions, hence, I use the same functions in CM as in CS.

So basically you just want to copy and paste a mass of code more lazily?

 

Still doesn't seem to weigh up against the problems I explained about using the very versions of CLEO 4 that were more hated than even CLEO 3 until CLEO 4.3 fixed the CLEO 3 compatibility issues.

 

And please, oh please, tell me you're only using CM's for actual missions, right?

 

I mean, one's that are actually structured and behave like missions, rather than abusing them for their extended variable range. Personally, I'm often reluctant to even put missions in CM's. Most of CLEO was built around finding direct solutions to problems because there wasn't much choice, but I feel the possibilities are much greater these days. The point is that even though I've always loved CLEO as much as anyone, I approach it's features with a healthy level skepticism as I've had the reality check that most the cool stuff we do to GTA isn't even done 'right', and that doing things based on things that aren't done right are going to be redundant or simply wrong when they eventually are made right, such as the bugs caused in CLEO 3 scripts by CLEO 4 - many of them could actually be blamed on CLEO 3, or the CLEO 3 scripts themselves, and CLEO 4 actually did stuff with more convention, overlooking the lack of convention set up by more the primitive modding days. So having the least amount of dependencies as possible seems the most logical choice, which is why I totally just gave up writing for CLEO and SB when I decided to attempt to introduce more modern all-encompassing solutions to those old problems. The time will begin to come eventually, we just need to push for it and think large scale.

 

(2) Of course I also though about dublicating the functions in CM based on GOSUB. However, passing parameters and reading return values via assingments is a problem because these calls appear very often and the code becomes hard to manage and understand.

 

However, your suggestion is helpful, because I can solve the second problem (in CM only) by using macros to hide the code that would surround the GOSUB.

Better than using an outdated and unstable CLEO version I'd say, plus while it's more typing for you, the computer actually has less to do

 

The Black Market Mod, which was the last thing I ever worked on in Sanny Builder, used SuperVar's what disassembled looks like a complete headf*ck... but was very easy to manage and use once everything was set up. It even had it's own weird methods for calling functions and handling a stack, and a set of variables that saved with the game. If you check out this demo you'll see that you can pass a SuperVar to a SCM function or simply use a GOSUB and a specific var range since var space isn't an issue, and it can do anything with the data in the SuperVar - so you can return things through it.

 

The best way to do it is to use SuperVars as "important things to save" and normal variables for working with. Or simply ask "do I still need this after the WAIT 0 / on the next iteration of the script loop?". There will be lots of things, and very few variables you need temporarily, so having 32 is a complete luxury. And at the end of the day, this is just a convenient abstraction over allocating memory and WRITE_MEMORY'ing it - there are a number of ways to abstract it with CLEO itself.

 

Indeed that's a possibility. The only disadvantage would be that it cannot be as easily ported to mobile.

But no problem exists with SCM Functions on CLEO mobile, does it? I'm not saying create a new opcode, I'm saying attempt to hotfix the problem (I'm just surprised no one has done it yet people still seem really irritated by the issue, to be honest ). If I had the code I could fix it in seconds, it can't be that much harder to hack it like many other CLEO plugins have done for worse reasons in the past.

 

and there is the small risk that two plugins may use the same opcode numbers for different purpose.

No opcodes required.

 

Another possibility is also to use DKs SDK instad of cleo which would lead to much better code but sacraficing portability and the possibility that users can decompile the code.

I generally think the way CLEO for Android was (or 'had to be') made already makes it useless enough for being 'portable'. Not too many complex mods would really fit right on mobile anyway, would they?

 

But portability is exactly what we're aiming to improve with CLEO in future, except it's real portability - not "how hard it is for me to re-write this script to support this other thing" but simply "this script will work on anything running this CLEO".

 

I understand the need for people to "make do", but I think it's important to remember to aim forward and find better solutions ratjer than just using what's easiest.

Edited September 26, 2015 by Deji

[goodidea82]

Thanks for the insights, Deji.
Some time ago I wanted to try SuperVars but I couldn't compile the provided examples using SannyBuilder. For example "SET_BIT_L [email protected] 8" could not be compiled. Then I wrote my own example based on the explanation, but SuperVars was not activated (bit 9 was not set). Would be great if you could provide a new example:

/////////////////////////////////////// SuperVars Example Source File/////////////////////////////////////// Language:// SCR for Sanny Builder//// Description:// This example demonstrates many tricks and uses possible// with SuperVars and CLEO 4.//// Level:// Ini-termediate//// Compiled Script Checksum (CRC-32):// 31ECE027//{$CLEO}03A4: name_thread 'svtest'CONSTSuperVar = string // SB exploitNUM_VARS = 8 // lets have 8 varsDriftData = [email protected]// For our DriftData array:Score = DriftData // zero-index must use the same var the memory is stored inTopSpeed = [email protected] = [email protected] array 4 of SuperVarENDWAIT 1000WHILE 016B: fadingWAIT 0END// Activate SuperVars for this script//SET_BIT_L [email protected] 8//Trying different set commands08BA: set [email protected] bit 808BB: set [email protected] bit 808BC: set [email protected] bit 808BD: set [email protected] bit 808BE: set [email protected] bit 808BF: set [email protected] bit 8// Verify SuperVars installation...IF //NOT IS_BIT_SET_L [email protected] 9gosub @SVInstalledTHEN0662: write_debug_message "SuperVars is running"ELSE0662: write_debug_message "SuperVars is not installed"0A93: end_custom_threadEND// Get the memory space for our vars (can also be a real pointer to a label or allocated memory)DriftData = @VARIABLE_MEMORY0AD0: show_formatted_text_lowpriority "SuperVar value= %.4X" time 2000 DriftData[TopSpeed]:SVInstalledif or08B4: test [email protected] bit 908B5: test [email protected] bit 908B6: test [email protected] bit 908B7: test [email protected] bit 908B8: test [email protected] bit 908B9: test [email protected] bit 9then0485: return_trueelse059A: return_falseendreturn:VARIABLE_MEMORYHEX00 00 00 00 // SVar Index 000 00 00 00 // SVar Index 100 00 00 00 // SVar Index 200 00 00 00 // SVar Index 300 00 00 00 // SVar Index 400 00 00 00 // SVar Index 500 00 00 00 // SVar Index 600 00 00 00 // SVar Index 700 00 00 00 // SVar Index 800 00 00 00 // SVar Index 9END

 

 

I use SCM calls for the following reasons. (1) In CS scripts I don't have enough variables so I can't use GOSUB for these functions (that's also the reason why the matrices are built-in (I only pass the index which one I need in a call).

Wrong. 8 variables would be plenty for a CS script, 32 is overkill

As with anyone who complains about lack of variables in scripts, you simply need to look into smarter ways to handle memory, such as dynamically allocated data and treating memory as objects instead of just using every variable to store every individual value in a dedicated way. CLEO 4 provides so many things for this which barely anyone even uses (I mean c'mon ALLOCATE_MEMORY alone basically solves every single problem with memory limits you could think of), yet will use many other nasty tricks to get around the problem in the most direct way possible.

 

Allocating memory is what I did in Soccer TeamPlay. But this made the code very hard to read since I had to permanently copy values between cleo variable and the allocated memory using 0A8D and 0A8C. It was a nightmare. If you have something else in mind or know how to hide the complexity, then let me know.

 

There are solutions for this already, such as SuperVars and it's 'Objective-SCM' companion which allows memory to be treated as strongly typed objects. But really they're just more convenient and optimal solutions to solutions that already existed on some level.

I'd recommend treating SCM Functions as tools for extra convenience rather than the only tools for the job.

Additionally... SCM Functions are working normally in CS scripts in 4.3, right?

- Yes, SCM Function work in CS scripts. My test script checks them nevertheless, because I haven't tested all cleo versions and who knows what happens in the future. Tests for other cleo-opcodes that have different behaviors in different versions would be great.

 

My CM scripts also require the same functions, hence, I use the same functions in CM as in CS.

So basically you just want to copy and paste a mass of code more lazily?

 

Yes, to keep the code consistent since I had to update it frequently during development.

Still doesn't seem to weigh up against the problems I explained about using the very versions of CLEO 4 that were more hated than even CLEO 3 until CLEO 4.3 fixed the CLEO 3 compatibility issues.

And please, oh please, tell me you're only using CM's for actual missions, right?

Yes, of course.

So DYOM missions works with CLEO 4.3?

(gtaforums has a limit on the number of quotes. I can't quote the rest)

 

Please keep in mind that there is a huge amout of legacy cleo mods. Even if you work on something new (I suppose a lua binding), I hope that you will fix the known issues of cleo and continue support for it. Thanks for what you have contributed.

Edited September 27, 2015 by goodidea82