Full IDE Support in Cleo Scripts

[OrionSR]

Can the decompilation process for cleo scripts be modified so that any object ID that can be compiled can also be decompiled to the same ID rather than the object number.

In SCM the object IDs are defined by the SCM header and decompile as expected. IIRC, used to be that only some IDs could be used in cleo scripts, but somewhere along the line Sanny was able to work with an extended IDE set. This extended support is missing from the sa_mobile mode which only includes 4 basic IDE files. I figure that these are the files with model IDs that always compile to their ID number and decompile as expected in cleo scripts.

I'm trying to define a clear distinction between models and objects as it relates to special handling for cargens, but I'm also trying to confirm that my edit modes are configured with full support; I'm a bit confused about what's really supposed to happen.

Added: Here we go. sa_mobile mode with extended IDE files will decompile any object ID I throw at it. But sa, vc and gta3 modes do not.

[x87]

If you set the game directory with IDE files in it Sanny tries to load them in order to provide model names instead of numbers. This is intended behavior. If you with to see plain numbers instead you can clear game directory before decompiling.

[OrionSR]

I want to see model names and object names. I have control of my IDE files.

In cleo scripts of GTA3, VC, and SA modes Sannny will only decompile model names. Object names seem to work as expect in SCM scripts with proper headers.

By default, sa_mobile mode can only compile and decompile model names because only default.ide, peds,ide, vehicle.ide and veh_mods.ide are included in custom.dat. But if custom.dat is expanded to include all IDE files from default.dat and gta3.dat then Sanny will compile and decompile object names too.

How do I decompile object names in non-mobile cleo scripts? Should I be concerned about sa_mobile not compiling defined object numbers in SCM?

[OrionSR]

I've been experimenting with the new edit mode features available with v3.5.1, in particular VC as I was adapting an edit mode for VC mobile. This example script was made to help test how model IDs are compiled and decompiled:

{$CLEO .cs}

//-------------MAIN---------------
0000: NOP 
0249: release_model #WMYCR 
0249: release_model #FAGGIO 
0249: release_model #PYTHON 
0249: release_model #GUNBOX 
0249: release_model #AP_TOWER 
0249: release_model #AP_TERMINALB1 
0249: release_model #BANK_TABLE1 
0249: release_model #ROOSBRIDGE_DT 
0249: release_model #CI_ISLANDWEST 
0249: release_model #CLUBCEILINGDOME 
0249: release_model #CONCERTH29 
0249: release_model #DK_DOCKROADS01 
0249: release_model #DOONTOON03 
0249: release_model #ROAD_DOWNTOWN08 
0249: release_model #GF_TREE1_01 
0249: release_model #LITTLEHACOAST05 
0249: release_model #SJMCOAST 
0249: release_model #HOT_ROOM317 
0249: release_model #ISLANDLODMAINLAND 
0249: release_model #LW_ROOM_MAIN
0249: release_model #MIAMILAND037 
0249: release_model #MLMIAMILAND056 
0249: release_model #MNA_TABLE_SCRFCE 
0249: release_model #NBMIAMILAND048 
0249: release_model #NBECLAND01 
0249: release_model #NBEACHROADS01 
0249: release_model #ODNROAD05OD 
0249: release_model #PLANTS01 
0249: release_model #KICKSTART 
0249: release_model #STGLUE 
0249: release_model #STRIPLIGHTS 
0249: release_model #WASHBUILD005 
0249: release_model #WSHBUILDWS02 
0249: release_model #LODMAIN_BODY 
004E: end_thread 

Out of the v3.5.1 box and with a game directory configured, the script will compile as expected - which means Sanny must be searching for DATs and IDEs in the game folder. However, only the first three model IDs, the IDs defined in default.ide, will decompile back to model IDs, The others decompile to model numbers.

Adding this entry to the VC section of modes.xml will enable the "full IDE support" that previously wasn't available - all objects decompile to model IDs. <ide base="@game:\">@game:\data\gta_vc.dat</ide>

I find it curious that without this entry Sanny can compile but won't decompile the model IDs. Is this intended? Should all edit modes be configured in a similar fashion?

[x87]

I find it curious that without this entry Sanny can compile but won't decompile the model IDs. Is this intended? Should all edit modes be configured in a similar fashion?

Yes, currently compiler and disassembler behave differently. Disassembler only uses IDE files given via the edit mode configuration (default.ide), while the compiler tries to resolve the model name by scanning the entire game directory using GetObjectID library. The same code in main.scm would make the compiler add those models to the object list in the header.

[OrionSR]

So by adding gta_vc.dat to the edit mode I break the SCM header?

An edit mode strategy:

• VC - SCM; default.ide only
• VC - Cleo; added support for gta_vc.dat

But for VC Mobile - SCM; the game directory would need to be set to the mode directory in order to compile object IDs. I was really hoping to use the game directory only for a Compile and Copy destination for mobile, and have everything needed configured in modes.xml.

And to complicate things further, object IDs are defined in the VC mobile SCM header but encoded using actual object numbers - not the negative values of defined objects. Perhaps it makes no difference, but there doesn't appear to be any path towards creating a mobile SCM that matches the original - ie, with objects defined in the header but with object numbers in the script.

My notes suggest that SA mobile encodes IDE object numbers instead of define object numbers in main.scm too.

Added: On second thought, since object IDs in mobile's main.scm are decompiled as numbers they should compile the same way. It's new definitions in a custom main that are liable to cause trouble.

[x87]

So by adding gta_vc.dat to the edit mode I break the SCM header?

doing that makes the compiler aware of any model ID available and it would use those ID instead of negative indexes in the object list. I'm not sure how this would impact the game.

[OrionSR]

Okay, I think I understand the problem better. I'll keep experimenting to see what I can come up with. Thanks for the input.

I'm not sure why I thought SA mobile was encoding model numbers instead of defined object numbers. I'm not seeing it in these scripts. Remastered maybe? I'll keep looking.

And for VC mobile, other than object 0, the defined objects are missing from the header, so no direct conflicts are expected in this mode.

However, I'm starting to think of this as an optimization exploit. If defined objects aren't used in the header that will free up 24 bytes of ScriptSpace for each entry. That's almost 5000 bytes for VC, and over 9000 bytes for SA.

[x87]

However, I'm starting to think of this as an optimization exploit. If defined objects aren't used in the header that will free up 24 bytes of ScriptSpace for each entry. That's almost 5000 bytes for VC, and over 9000 bytes for SA.

this is a known trick. You may delete the defined objects list and Sanny compiles another one based on the models that are actually used in the script. Even in the original main.scm a few objects are never used.