[ATP]

Hey,
if I use this:

SANNY

0004: $INDEX = 0
06D1: v$GXT_NAME[0] = "BLUBGXT"
0ADF: add_dynamic_GXT_entry $GXT_NAME($INDEX,50v) text "This is my great new GXT entry, it is just awesome."

It works fine.

But if I use this:

SANNY

0004: $INDEX = 0
06D1: v$GXT_NAME[0] = "BLUBGXT"
06D1: v$GXT_CONTENT[0] = "This is my great new GXT entry, it is just awesome."
0ADF: add_dynamic_GXT_entry $GXT_NAME($INDEX,50v) text $GXT_CONTENT($INDEX,50v)

The text appears clipped ingame.

Any idea? Maybe wrong usage of the data type?

[Wesser]

s$/@s refers to a 8-byte string, that is 2 variables are used (both have 4 bytes). On the other side, v$/@v writes 16 bytes only to the variable buffer, that is 4 variables of 4 bytes keep overwrited. That issue regards the limited data type a scm variable can have.

This post has been edited by Wesser: Jan 7 2012, 04:55 PM

[ATP]

Ok, so there is no way to get longer data types?

[Wesser]

Not yet. Use labels instead.

[Silent]

Not yet. Use labels instead.

Well, PARTIALLY you can do it:

SANNY

0AC8: 0@ = allocate_memory_size 260
0AD3: 0@ = format "Hello world, it's a long entry, which gets saved in this malloc!"
0ADF: add_dynamic_GXT_entry "ENTRY" text 0@
0AC9: free_allocated_memory 0@

[Wesser]

Does 0ADF accepts pointers? I'm not friendly with CLEO4.

[Silent]

Yeah, this code is perfectly valid.

[Deji]

Does 0ADF accepts pointers? I'm not friendly with CLEO4.

Maybe you could fix it? The source was made available, I just find the compiler requirements demanding. It's also written in a style of C++ I'm not acquainted with and uses AT&T ASM

Or we just wait for CLEO 5...

[fastman92]

CLEO4 string opcodes require string variable or int variable
If it`s int variable e.g 4@ then CLEO4 opcode will use value on memory address taken from 4@
If it`s 4@s or 4@v - store string in usual way.
However INT variables as pointers instead of string variables don`t work in CLEO3.

[ATP]

thx for all answers