CLEO Android support

[XMDS]

Android GTA is still very popular so far, so it is necessary for SannyBuilder to support CLEO writing for Android GTA.
Alexander Blade made the Android CLEO library.CLEO Android。
But unfortunately, although the project is very great, it has stopped updating. It may be an abandoned project. But it is still used in Android GTA, even if it is not updated, but the final version is very stable.

1. We need to create VCMobile and 3Mobile modes Mobile Modes for GTA3 and Vice City #6
2. We also need to solve the problem that the decompiled string hexadecimal is unreadable when 0DD0 and 0DD1 use the function name to obtain the function address in Android Special Hex String Construct for Mobile Label Addresses #33
3. In the Issues, we need to add the new OP (Android opcodes) of the Android CLEO library, and add the Android CLEO description in the SB tool help file (I have been writing it), and the Android CLEO library (LibCLEO.SO) should also be attached to SB tool (essentially this library might be helpful for reverse engineering?)

; Android opcodes
0DD0=2,%1d% = get_label_addr %2p% ; android
0DD1=2,%1d% = get_func_addr_by_cstr_name %2d% ; android
0DD2=1,context_call_func %1d% ; android
0DD3=2,context_set_reg %1d% value %2d% ; android
0DD4=2,%1d% = context_get_reg %2d% ; android
0DD6=1,%1d% = get_game_version ; android
0DD7=1,%1d% = get_image_base ; android
0DD8=4,%1d% = read_mem_addr %2d% size %3d% add_ib %4d% ; android
0DD9=5,write_mem_addr %1d% value %2d% size %3d% add_ib %4d% protect %5d% ; android
0DDC=2,set_mutex_var %1d% to %2d% ; android
0DDD=2,%1d% = get_mutex_var %2d% ; android
0DE0=3,%1d% = get_touch_point_state %2d% mintime %3d% ; android
0DE1=5,%1d% = get_touch_slide_state from %2d% to %3d% mintime %4d% maxtime %5d% ; android
0DE2=1,%1d% = get_menu_button_state ; read opcode info before using ; android
0DE3=2,%1d% = get_menu_button_pressed mintime %2d% ; read opcode info before using ; android

[XMDS]

Since there is currently a "Sanny Builder Discussions" area, I will also create a topic in the Discussions area to discuss some issues with Android CLEO. For example, some solutions and OP’s description and classes

[XMDS]

In addition, in the VCMobile mode, there are some new OPs brought by the mobile version of VC. The SB tool does not define them correctly, and there are some problems:

; VC mobile opcodes
0454=3,useless_store_debug_camera_position_to %1d% %2d% %3d%
0463=3,useless_store_debug_camera_target_point_to %1d% %2d% %3d%
05a9=1,get_debug_state_to %1d%
05aa=1,%1d%
05ab=0,unknown
05ac=1,%1d%

[XMDS]

ID:1452(05AC)
As the last OP of the VC mobile version, it should actually be correctly defined as:

05AC=1,get_mission_Replay %1d%
05AC: get_mission_Replay 0@

The OP actually returns a state value for the task to restart. Normally, this value is 0. When we kill the NPC character in the task, then the caption prompts that the task failed the value will become 3. If the player is arrested because of his own death, the value will become 7. In addition, after the Android version prompts the mission to fail, when we choose to continue the mission, the value is always 7 (maybe it represents the status of the mission being redone). Also, maybe there are more values, but I don’t have more tests

[XMDS]

ID:1451(05AB)
The OP was incorrectly defined parameters, which caused the code of the mian.scm file to be incorrectly decompiled:

05ab=0,unknown

:LAW1
03A4: script_name 'LAW1' 
05AB: (unknown) 
0404: increment_fires_extinguished

In fact, 0404 is a parameter, which is incorrectly compiled as OP. It is correctly compiled as:

:LAW1
03A4: script_name 'LAW1' 
05AB: set_SaveGame_for_pause 4

SCM:

05AB=1,set_SaveGame_for_pause %1d%
05AB: set_SaveGame_for_pause 4

This OP is not used to save, it is actually a debugging OP. When saving the game, it will enter the save slot interface, and the game will pause for a moment (the game is paused). The OP is actually set to save the game save pause, the original version of mian.scm usually set the value to 4. After testing, after the OP is set to 0, the game will pause for 0.5 seconds and then move the time back 6 hours (used when saving). The other values did not change significantly.

[XMDS]

ID: 1450(05AA)
This is a very interesting OP:

We still can’t understand its meaning just through the disassembled characters, but it is related to the gun ammunition.
Button icon under normal game conditions:

Set the value to 1 after using this OP:

We found that after using this OP, the icon of the operated button changed. But this alone still cannot understand the actual use of the OP. I think if you understand the GTAVC game, then the word "Ammunation" actually represents the gun store in the picture:



That's right, this OP is exactly what the switch button icon uses when we enter the store to buy guns, so it should be correctly defined as:

05AA=1,set_is_in_Ammunation_Button_icon %1d%
05AA: set_is_in_Ammunation_Button_icon 0

[XMDS]

ID: 1449(05A9)
The OP gets the level of the task skipped, usually returns 0.

045c=0,fail_current_mission

In addition, 045C will set the status to 0 if the current task fails.

SCM:

05A9=1,get_Mission_Skip_Level %1d%
05A9: get_Mission_Skip_Level 0@

[XMDS]

@x87 While writing the Android CLEO document, I actually made a new definition of the OP unknown to mobile, and there may be some missing OP not included. Actually, I will study Android SA later. Because some OP's description of SA is wrong

[x87]

@XMDS Well done, thanks for sharing. You can open a pull request in data repo if you want those new descriptions to be added. Feel free to start a new discussion too.

[XMDS]

@XMDS Well done, thanks for sharing. You can open a pull request in data repo if you want those new descriptions to be added. Feel free to start a new discussion too.

yes. I plan to complete the mobile version of GTA OP around the Chinese New Year. I temporarily noticed that there are many OPs not included in the mobile version of VC and 3. I will submit the organized SCM.INI and OP.TXT to the data warehouse. In addition, it can cooperate with the mobile mode of #6 VC.

[XMDS]

@x87 A strange OP in VC (PC and mobile):
Mobile

PC![(ZKTL2XP}1E(7)ITLY)3)J.png

SA:

059C=2,enable_status_text %1d% flashing %2h% ; global_variable

The assemblyThe definition of the current version (3.6.2) is wrong. The code seems to have only one parameter, but it must be 2 in reality, otherwise the game crashes:

059c=0,  japanese_game

code looks like IP+3. I did a test, and it has no effect on the VC. It should look like this:

059c=2,NOP %1d% %2d%

[XMDS]

for all: sannybuilder/data#11

[XMDS]

@x87 CLEO ANDROID already updated。
After a lot of testing, the new version supports LCS for Android and VCS/LCS for PSP. Alexander Blade also adds some OPs. In addition, it supports CLEO4 similar plug-in functions, and adds IntOperations plug-in to support bit operation OP.
These OPs should be added and the CLEO ANDROID download package should be attached to the Tool folder of the SB tool.

In addition, I think there is no need to create a mobile mode of 3, because it has nothing unique, but the vacancy of LCS and VCS opcodes should be filled.

; CLEO ANDROID
0DD0=2,%1d% = get_label_addr %2p%
0DD1=2,%1d% = get_func_addr_by_cstr_name %2d%
0DD2=1,context_call_func %1d% ; deprecated, use 0DDE instead
0DD3=2,context_set_reg %1d% value %2d% ; deprecated, use 0DDE instead
0DD4=2,%1d% = context_get_reg %2d% ; deprecated, use 0DDE instead
0DD5=1,%1d% = get_platform
0DD6=1,%1d% = get_game_version
0DD7=1,%1d% = get_image_base
0DD8=4,%1d% = read_mem_addr %2d% size %3d% add_ib %4d%
0DD9=5,write_mem_addr %1d% value %2d% size %3d% add_ib %4d% protect %5d%
0DDA=3,%1d% = get_pattern_addr_cstr %2d% index %3d%
0DDB=3,get_game_ver_ex name_hash %1d% ver_hash %2d% ver_code %3d%
0DDC=2,set_mutex_var %1d% to %2d%
0DDD=2,%1d% = get_mutex_var %2d%
0DDE=-1, call_func %1d% add_ib %2d%
0DE0=3,%1d% = get_touch_point_state %2d% mintime %3d%
0DE1=5,%1d% = get_touch_slide_state from %2d% to %3d% mintime %4d% maxtime %5d%
0DE2=1,%1d% = get_menu_button_state
0DE3=2,%1d% = get_menu_button_pressed mintime %2d%
0DE4=2,%1d% = psp_get_control_state %2d%
0DE5=3,%1d% = psp_get_control_pressed %2d% mintime %3d%
0DF2=2,create_menu %1d% items %2d% 
0DF3=0,delete_menu
0DF4=2,%1d% = get_menu_touched_item_index maxtime %2d%
0DF5=1,set_menu_active_item_index %1d%
0DF6=1,%1d% = get_menu_active_item_index
1000=-1, opcode_func

The above OP supports Android version SA.VC.3.LCS and PSP version LCS.VCS (PPSSPP emulator can be used on mobile PPSSPP emulator )
The installation of the PSP version needs to be in the main directory of the emulator (it still supports mobile devices, not the PC version PSP)

[XMDS]

@x87 Some special features:
Android bit operation OP plug-in (IntOperations.cleo), the plug-in name on Android is "libopcodes.so", and the psp name is "opcodes.prx"
It is an open source plug-in, but the new bit operation OP it implements is different from the structure of the existing OP:

1000=-1, opcode_func

It is implemented by an OP 1000, which is an infinitely expandable OP, without limiting the number of parameters and functions (for developers), as follows:

This example plugin implements IntOperations opcodes and also provides functions which do the same.

	Opcodes and functions internally does not correspond to each other in any way, meaning this is up
	to a plugin developer whether to provide opcodes, functions or both, here we do both using single
	code base.

	Opcode function call, opcode 1000:
	* III, VC, SA -> uses long strings for function names, e.g. "createWeaponForPed"
	* LCS, VCS    -> uses 8byte strings with trailing parentheses, e.g. 'create' 'Weapon' 'For' 'Ped()'

	======================================================================================================

	IntOperations from CLEO PC	 ->  param/result mapping	  ->  IntOperations funcs in CLEO ANDROID

	0B10=3,%3d% = %1d% AND %2d%	 ->  intops__i32_i32_resi32	  ->  1000: "Intops::And" i32 _& i32 to resi32
	0B11=3,%3d% = %1d% OR %2d%	 ->  intops__i32_i32_resi32	  ->  1000: "Intops::Or" i32 | i32 to resi32
	0B12=3,%3d% = %1d% XOR %2d%	 ->  intops__i32_i32_resi32	  ->  1000: "Intops::Xor" i32 ^ i32 to resi32
	0B13=2,%2d% = NOT %1d%		 ->  intops__i32_resi32		  ->  1000: "Intops::Not" i32 to resi32
	0B14=3,%3d% = %1d% MOD %2d%	 ->  intops__i32_i32_resi32	  ->  1000: "Intops::Mod" i32 % i32 to resi32
	0B15=3,%3d% = %1d% SHR %2d%	 ->  intops__i32_i32_resi32	  ->  1000: "Intops::Shr" i32 >> i32 to resi32
	0B16=3,%3d% = %1d% SHL %2d%	 ->  intops__i32_i32_resi32	  ->  1000: "Intops::Shl" i32 << i32 to resi32
	0B17=2,%1d% _&= %2d%		 ->  intops__resi32_i32		  ->  1000: "Intops::&=" resi32 with i32
	0B18=2,%1d% |= %2d%			 ->  intops__resi32_i32		  ->  1000: "Intops::|=" resi32 with i32
	0B19=2,%1d% ^= %2d%			 ->  intops__resi32_i32		  ->  1000: "Intops::^=" resi32 with i32
	0B1A=1,~ %1d%				 ->  intops__resi32			  ->  1000: "Intops::~" resi32
	0B1B=2,%1d% %= %2d%			 ->  intops__resi32_i32		  ->  1000: "Intops::%=" resi32 with i32
	0B1C=2,%1d% >>= %2d%		 ->  intops__resi32_i32		  ->  1000: "Intops::>>=" resi32 with i32
	0B1D=2,%1d% <<= %2d%		 ->  intops__resi32_i32		  ->  1000: "Intops::<<=" resi32 with i32

The 14 functions of bit operation share one ID, all of which are realized by 1000, and if someone writes a new OP plug-in, 1000 can still be used. It recognizes different functions through the first parameter (character). The following usage examples:

SA VC 3:
1000: "Intops::And" 2 _& 2 to 0@
1000: "Intops::Or"  2 | 2 to 0@
1000: "Intops::Xor" 2 ^ 2 to 0@
1000: "Intops::Not" 2 to 0@
1000: "Intops::Mod" 2 % 2 to 0@
1000: "Intops::Shr" 2 >> 2 to 0@
1000: "Intops::Shl" 2 << 2 to 0@
1000: "Intops::&=" 0@ with 2
1000: "Intops::|=" 0@ with 2
1000: "Intops::^=" 0@ with 2
1000: "Intops::~" 0@
1000: "Intops::%=" 0@ with 2
1000: "Intops::>>=" 0@ with 2
1000: "Intops::<<=" 0@ with 2

LCS\VCS(8byte):
1000: 'Intops' '::' 'And' '()' 2 _& 2 to 0@
1000: 'Intops' '::' 'Or' '()' 2 | 2 to 0@
1000: 'Intops' '::' 'Xor' '()' 2 ^ 2 to 0@
1000: 'Intops' '::' 'Not' '()' 2 to 0@
1000: 'Intops' '::' 'Mod' '()' 2 % 2 to 0@
1000: 'Intops' '::' 'Shr' '()' 2 >> 2 to 0@
1000: 'Intops' '::' 'Shl' '()' 2 << 2 to 0@
1000: 'Intops' '::' '&=' '()' 0@ with 2
1000: 'Intops' '::' '|=' '()' 0@ with 2
1000: 'Intops' '::' '^=' '()' 0@ with 2
1000: 'Intops' '::' '~' '()' 0@
1000: 'Intops' '::' '%=' '()' 0@ with 2
1000: 'Intops' '::' '>>=' '()' 0@ with 2
1000: 'Intops' '::' '<<=' '()' 0@ with 2

You can group chars into 8byte strings in various ways, for example:
1000: 'Intops' '::And()' 2 _& 2 to 0@
1000: 'Intops' '::' '>>=()' 0@ with 2

ues:

2 xor 4 = 6

1000: "Intops::xor" 2 ^ 4 to 0@
01E5: show_text_1number_highpriority GXT 'NUMBER' number 0@ time 10000 flag 1

0@ = 2
1000: "Intops::^=" 0@ with 4
01E5: show_text_1number_highpriority GXT 'NUMBER' number 0@ time 10000 flag 1

LCS/VCS:
1000: 'Intops' '::' 'Xor' '()' 2 ^ 4 to 0@
011F: print_with_number_now 'NUMBER' number 0@ time 10000 flag 1  // Number: ~1~

0@ = 2
1000: 'Intops' '::' '^=' '()' 0@ with 2
011F: print_with_number_now 'NUMBER' number 0@ time 10000 flag 1  // Number: ~1~

@x87 This special situation greatly changes the independence of the current CLEO function, that is, the ID of 1000 can be used to program unlimited new functions. Different functions are recognized only by character strings. I noticed that your previous bit operation abbreviation syntax may need to be reimplemented in mobile mode.

[XMDS]

In addition, regarding the expansion of the OP of 1000, we should default to CLEO or bitwiswe. I am not sure

[x87]

Good news! Finally got some documentation as well. We have to port opcode descriptions to https://library.sannybuilder.com/#/ Would you like to participate, @XMDS ?

See #136