:
Destination Time
:
Present Time
:
Last Time Departed
Sign in to follow this  
knightprowl

CLEO for VC and III O_O

Recommended Posts

It can't be dead, it just has to mature, that's all.... Its like children, give it time to grow...

Share this post


Link to post
Share on other sites
oh, theres no 0ab1 codes?

Nope, only the 05xx ones and there's no CLEO global var or similar.

A.K.A Attach_object_to_car, and accurate sparks?

Oh, I hope this added by the VC CLEO guys, but at all...

By the way, does that mean that the cheats will be re-enabled again?

...it's not even decided if we use that at all :D.

Share this post


Link to post
Share on other sites

the attach object thing is more of a graphical engine thing, so no, it won't be added. And since it doesn't change limits or how particles work, sparks won't be better either.

All CLEO really did in the first place was provide an easy way of memory hacking using scm coding. A lot of the less complicated codes can be accomplished using mem hacks.

Share this post


Link to post
Share on other sites

We're leaving it scm based for now.

Keep in mind VC cleo is a new product, it's going to take some time to mature. We will be keeping an eye on it, but as of this point in time, it is not suitable for the mod.

Share this post


Link to post
Share on other sites
Write opcodes

This option turns the decompiling output from high-level to low-level and vice versa. If this option is unchecked, the decompiler uses available classes and keywords instead of opcodes. In addition, there are no opcodes for simple math expressions. If option checked, all opcodes are present in the output file.

Lets say you write a simple .cs script that creates a car (don't bother running it, it'll crash. Its simplified to make things a bit easier.

{$VERSION 3.1.0027}

{$CLEO .cs}



thread 'SPAWN'

:Spawn

if 

   Player.Defined($PLAYER_CHAR)

jf @Spawn 

0@ = Car.Create(#BULLET, 1@, 2@, 3@)

Car.RemoveReferences(0@)   

0A93: end_custom_thread
Then you compile it. The Write opcode works when decompiling. When its unchecked, the decompiled code looks like this.
// This file was decompiled using sascm.ini published by Seemann (http://sannybuilder.com/files/SASCM.rar) on 13.10.2007



{$VERSION 3.1.0027}

{$CLEO .cs}



//-------------MAIN---------------

thread 'SPAWN' 



:SPAWN_11

if 

   Player.Defined($PLAYER_CHAR)

jf @SPAWN_11 

0@ = Car.Create($BULLET, 1@, 2@, 3@)

Car.RemoveReferences(0@)

0A93: end_custom_thread
Not much difference. But when you check write opcode, it'll look like this
// This file was decompiled using sascm.ini published by Seemann (http://sannybuilder.com/files/SASCM.rar) on 13.10.2007



{$VERSION 3.1.0027}

{$CLEO .cs}



//-------------MAIN---------------

03A4: name_thread 'SPAWN' 



:SPAWN_11

00D6: if 

0256:   player $PLAYER_CHAR defined 

004D: jump_if_false @SPAWN_11 

00A5: 0@ = create_car #BULLET at 1@ 2@ 3@ 

01C3: remove_references_to_car 0@ // Like turning a car into any random car 

0A93: end_custom_thread

Notice that all the keywords get replaced by the opcode that represents if (Car.create to 00A5), hence write opcode

Or in other words, RTFM.

Share this post


Link to post
Share on other sites
RTFM
heißt "lies das verfi**te Handbuch", falls noch nicht bekannt ;).

(The above is just a translation of the English long form of that acronym)

Since we already talk about general stuff, why couldn't/shouldn't we use global variables in CLEO threads? I always thought it had something to do with memory addresses (when compiled, the variable names aren't there anymore but pointers to their memory addresses), but I lately got confused when I could check and change globals from a *.cs in the main.scm. Anyone around here has an explanation for me :D?

Share this post


Link to post
Share on other sites
heißt "lies das verfi**te Handbuch", falls noch nicht bekannt ;).

(The above is just a translation of the English long form of that acronym)

Since we already talk about general stuff, why couldn't/shouldn't we use global variables in CLEO threads? I always thought it had something to do with memory addresses (when compiled, the variable names aren't there anymore but pointers to their memory addresses), but I lately got confused when I could check and change globals from a *.cs in the main.scm. Anyone around here has an explanation for me :D?

CLEO doesn't know what global variables are in use in the main.scm, and even though it has a name, internally, its given a number like $1539 which represents which are in memory it has, but since CLEO doesn't know which parts of memory are in use, it can easily change one in use by main.scm and sometimes its a critical one that will crash the game. Like saving a number to a variable that represents an object.

Share this post


Link to post
Share on other sites

Ah, so what I tried worked because I used a numeric global?

Share this post


Link to post
Share on other sites

Well, in my case I changed $410 (I guess) from CLEO (the original obiviosly already is used in the main.scm) and it worked.

So that means if I want to do a CLEO addon for a stock VC main.scm, I only need to decompile the scm without letting it assigning the names (I think there was an option in SB) check which are in use and I'm good to use unused?

Share this post


Link to post
Share on other sites
Sign in to follow this