[Deji]

The 34@+ variables had a lot of problems, mainly caused by what I believe to be coding restrictions.

Somehow, CLEO scripts seem to start up very differently every time. One time, thread memory would be very close to the 33@ variable, which is how the array could access it so easily. But other times the thread memory seems to start at a far distance (about 0x5000) away from the last local variable.

Unfortunately, SA seems to have a restriction on the indexes of local variable arrays. Allocated memory seems to be injected by CLEO 4 at a similar place to where the thread memory would be stored, so it has the same problem... sometimes the array could access the memory space, but other times, it's just too far away.

On the other hand, the memory may actually come BEFORE the variables.. and negative numbers don't seem to be supported by the arrays either. A lot of times, the same crash would occur when using these variables, so I no longer support using those methods.

These problems can be overcome by starting a new game, which is when CLEO would reload all scripts. Then it's about a 75% chance that the memory will be in the right place... We want 100%!

Additional Variables - Globals Method

I wouldn't suggest using the extra locals methods.. this way is much sweeter too!

SANNY

$2(31@,1i) = 7
0ACE: show_formatted_text_box "Lucky number %d!" $2(31@,1i)

We can still use the index, but instead of using 34@+ - we can use $1+


This also satisfies the desire to name variables (although we could simply use constants) using Sannys internal function:

SANNY

Alloc($MyVar, 40) - the variable $MyVar will be compiled as $40

I've not tested this, but it should work as long as you keep the array attached to the variable.

SANNY

0006: $2(31@,1i) = 2
Alloc($MyVar, 3)
0006: $MyVar(31@,1i) = 2

Note that Sanny will probably always decompile $2(31@,1i) as $PLAYER_CHAR(31@,1) etc. - but this doesn't matter as long as the array remains the same.


I'm not sure whether to use opcodes for locals or globals. I'm using local var ones since I've memorized just about every one of them, but it shouldn't matter either way.

These global variables work every time. The array index will never be negative, since the main.scm always comes before the allocated memory. And the array limit for global variables seems much higher.


Another great thing is support for passing extra variables to new scripts. Previously this has been impossible, since all vars were local, but now you can pass the index in order to access the same pool of data (careful, changing the data in one thread will apply to the other thread) since the index will be constant:

myscript.cs

SANNY

0006: $3(31@,1i) = 1337
0A92: create_custom_thread "script2.s" 31@

script2.s

SANNY

if
    0039:   $3(0@,1i) == 1337
then
    0ACA: show_text_box "The variable was passed successfully!"
end

Also note that if the index were to not pass properly, you would be using an actual global variable (player handle)... which is probably something to avoid.


New Code!

SANNY

0AC6: 31@ = label @Variables offset   // :Variables should, of course, contain blank data
000E: 31@ -= 0xA49984   // we'll be starting at $1, so lets take that off the amount of memory to skip
0016: 31@ /= 4   // share equally between vars.. lol

Thread space:

SANNY

0000: BUFFER
0000: BUFFER
:Variables
hex
    00 00 00 00  // 1 extra variable
    00 00 00 00  // 2 extra variables
    00 00 00 00  // 3 extra variables
    00 00 00 00  // etc.
    00 00 00 00
    00 00 00 00
end

Note Seemanns post here about safely keeping the variables from overwriting other stuff.

CLEO 3

SANNY

0A9F: 31@ = current_thread_pointer
000A: 31@ += 0x10
0A8D: 31@ = read_memory 31@ size 4 virtual_protect 0
000E: 31@ -= @Variables
000E: 31@ -= 0xA49984
0016: 31@ /= 4

I've not yet set up the code for Memory Allocation, I'll work on the SCM Function

[Silent]

Using locals method with hex...end memory allocation shouldn't be unstable to, IMO
Henrique also had problem with malloc vars, but hex...end vars worked perfectly.

This post has been edited by Silent: Oct 7 2010, 03:39 PM

[Deji]

That's what I thought, but somehow even thread memory can appear over 0x5000 bytes away from the last local, from my tests. I tested this on both versions of CLEO, too. It just takes restarting the game a few times to find an offset that either crashes the game or won't apply the value :/

[Alien]

The 34@+ variables had a lot of problems, mainly caused by what I believe to be coding restrictions.

Somehow, CLEO scripts seem to start up very differently every time. One time, thread memory would be very close to the 33@ variable, which is how the array could access it so easily. But other times the thread memory seems to start at a far distance (about 0x5000) away from the last local variable.

Unfortunately, SA seems to have a restriction on the indexes of local variable arrays. Allocated memory seems to be injected by CLEO 4 at a similar place to where the thread memory would be stored, so it has the same problem... sometimes the array could access the memory space, but other times, it's just too far away.

On the other hand, the memory may actually come BEFORE the variables.. and negative numbers don't seem to be supported by the arrays either. A lot of times, the same crash would occur when using these variables, so I no longer support using those methods.

These problems can be overcome by starting a new game, which is when CLEO would reload all scripts. Then it's about a 75% chance that the memory will be in the right place... We want 100%!

CLEO 4 cleans restriction on distinction between the valid address and the address received through DMA. For the first time the problem has been designated here and it has been solved. So in this sense the method must be absolutelly bug free.
And also in the malloc-method it is necessary to allocate on (sizeof(element) * 2) more bytes, than it is required by buffer (on a case if memory is allocated to the address, not multiple sizeof(element) though usually it is allocated to addresses, multiple 0x10). In the same way, as well as at thread-memory-method.

CODE

0006: $1(31@,1i) = 1337

The mistake is here. When you will compile and decompile this script, you'll see:

CODE

0006: $2(31@,1i) = 1337

SB uses $2 as a minimum global variable (or &<the main.scm offset> and it's called ADMA - advanced memory access).

[Deji]

Interesting.. The error I get is usually the same address all the time, but sometimes it's stuff like 0x465F70 - even though 0005 isn't used. I assumed that SA was reading part of one opcode as a new opcode. The 2 byte array limit might explain that.

My first thoughts towards using this method of memory access was to use & - but I wasn't sure where & started from for the calculation and continuing through the local variables seemed like a better idea. But I can never get the local var arrays to work 100% anymore.

Here's one of the indexes resulting in a negative:



I can't quite remember what error occured when I took this, but it was either that the default position was set, but moving the mouse resulted in a crash or that the mouse wouldn't move at all.. Which were the 2 problems I was having based on whether the index returned was negative or too high.