SannyBuilder.com Forums

Replace to

05F5=-1,call_scm_func %1p%
05F6=-1,ret

in Sanny Builder\vc\VICESCM.INI

Then compile your project again, it will work.

http://www.gtagarage.com/mods/show.php?id=16944
Done
http://www.mediafire.com/?dz8ybmydy593fll

@Link2012
0A99 opcode works only for CLEO file opcodes like 0A9A=3,%3d% = openfile %1s% mode %2d% ; IF and SET
it works probably for INI opcodes.
It is not for GTA SA standard texture opcodes.

0390: load_txd_dictionary 'LD_BEAT'

Texture dictionary LD_BEAT.txd must exist in models\txd

Another annoying bug in CLEO4 (probably in CLEO3 too).

There is set of bytes in script below which could be used to store data.
31@ contains proper move between 0@ from current thread and script content, label @AdditionalVariables in memory.
It works perfectly, reading/writing 4-byte data to this array using standard GTA SA opcodes.

0@(31@,1i) = 0x90807060      // It is GTA SA standard opcode, it doesn`t crash, works

And value appears on memory adress of @AdditionalVariables.
But trying to WRITE (not read) in CLEO to this array ends with a crash:

0AD2: 0@(31@,1i) = player $PLAYER_CHAR targeted_actor //IF and SET          // It crashes, CLEO writing function is buggy and works for 0@ to 33@ in thread only, i think

or

0A8E: 0@(31@,1i) = 3 + 2 // int

There were only 2 examples, writing function in CLEO4 is broken. I hope it will get fixed.

{$CLEO}
0662: NOP "Crash when opcode created using CLEO is trying to write into an array which points to somewhere else than 0 - 33 local var"
0662: NOP "Array index is good, problem is CLEO writing function"
0662: NOP "It is out of thread 224 bytes and in CLEO it crashes :("

0AB1: call_scm_func @getAdditionall_4byte_VariablesLabelIndex 1 label @AddtionalVariables store_index_to 31@

:CLEO_SDK 
wait 0
if
0AB0: key_pressed 48
else_jump @CLEO_SDK
0AC6: 1@ = label @AddtionalVariables offset

// 0@(31@,1i) = 0x90807060      // It is GTA SA standard opcode, it doesn`t crash, works

0AD2: 0@(31@,1i) = player $PLAYER_CHAR targeted_actor //IF and SET          // It crashes, CLEO writing function is buggy and works for 0@ to 33@ in thread only, i think

// 0AD2: 2@ = player $PLAYER_CHAR targeted_actor //IF and SET   // It works, but it is not an array out of thread.

0AD1: show_formatted_text_highpriority "Crashed, no 0AD1 executed. value: %X close memory offset of value: %X" time 2000 0@(31@,1i) 1@ 
wait 250
jump @CLEO_SDK 

:AddtionalVariables
hex                                                                                        0
00 00 00 00  // space
00 00 00 00  // 0@
00 00 00 00  // 1@
end

:getAdditionall_4byte_VariablesLabelIndex
{
 Description:	 
    Reads given number of chars from memory and returns into variable.
 Type: SET 
    
 Parameters:
   Passed:
    0@ - label
          
   Result:
     4@ - index, movement
    
 Example:
  0AB1: call_scm_func @getAdditionall_4byte_VariablesLabelIndex 1 label @AddtionalVariables store_index_to 31@
  
  :AddtionalVariables
   hex
   00 00 00 00  // space
   00 00 00 00  // 0@
   00 00 00 00  // 1@
   end
   
   Usage in code:
   0@(31@,1i); 1@(31@,1i) and so on
}
0A9F: 2@ = current_thread_pointer
2@ += 60

0AC6: 3@ = label 0@ offset

0A8F: 4@ = 3@ - 2@ // int

4@ /= 4
4@ += 1

0AB2: ret 1 4@

Thanks Alien, it works.

Now bug with 0ADE opcode and 0AC8: 0@ = allocate_memory_size   opcode
Somehow after reading GXT content of specified entry  to the pointer of allocated variable,  then i do free_allocated_memory, this GXT entry gets damaged.

Example:

{
Don`t forget to create  test.fxt with such a content:
BOATS Boats
}
 
{$CLEO}
0000: "It`s a bug"
 
:TEST
wait 0
00BC: show_text_highpriority GXT 'BOATS' time 1000 flag 1
if
0AB0: key_pressed 48    // 0
jf @TEST
0AC8: 0@ = allocate_memory_size 260
 
0ADE: 0@ = text_by_GXT_entry 'BOATS'
0AD1: show_formatted_text_highpriority "test: %s" time 3000 0@
 
0AC9: free_allocated_memory 0@
wait 3000
jump @TEST

Create  test.fxt with such a content:
BOATS Boats
Run the game with this script.  Boats will be displayed. Well.  Now press 0 and BOATS entry gets damaged.

This problem is related to free_allocated_memory and 0ADE opcode. If i read to  entry to normal memory adress (e.g sample label data in memory), problem doesn`t appear. Strange.