Mobile Modes for GTA3 and Vice City

[OrionSR]

Mobile mode for GTA3 and VC would make Android and PS2 configurations much more flexible.

[x87]

How different would these modes be from the existing ones?

[OrionSR]

These modes would have similar functionality to sa_mobile without unicode gxt and mobile Timers.

• Pre-configured install directory via custom*.dat
• Install directory optional and only used for Compile and Copy
• Assumes a few enhancements to sa_mobile mode's configurations in games.xml

The goal is to support PS2, Mobile for III and VC, and uninstalled versions from PC.

[x87]

Install directory optional and only used for Compile and Copy

this sounds reasonable. Sanny no longer requires particular files to be present in the game directory (.exe, default.ide, etc) so making this directory totally optional makes sense.

[x87]

VC Mobile mode - #48 (comment)

[OrionSR]

CustomEditModes_200

Two sets (Community and RockStyle) of 17 Edit Modes supporting III through VCS on multiple platforms.

The new edit mode features are working out very well. Issues:

• Defined objects in SCM are broken by the GTA*.DAT references
• Can't tell which root mode is active. A root title would be nice to have
• User tools don't seem to support @sb: as a proper path
• Sanny doesn't remember the last root mode used.

[x87]

We probably should re-evaluate this approach after #74 (comment)

[x87]

Progress on my custom edit modes has been slow. Social distancing has lead to more socializing a home, so I'm having a hard time finding large blocks of time alone when I can focus properly on the problem. But given the issues of the current release plan ( #61 ), I wanted to mention a new idea.

I want to configure Full IDE Support ( #23 ) without needing separate edit modes for cleo and define objects in SCM headers. If optimization options are introduced ( #44 ) then perhaps an option to include defined objects in SCM headers can also be included as an option.

There currently isn't a method to pass settings.ini info from modes.xml. How can a custom vc_mobile edit mode be configured to have Emit Defined Objects in SCM disabled by default.

A consequence of using the extends feature in a mode entry is that I should probably keep each of SB's parent modes in every modes.xml file to make it easier to copy mode elements between modes files. The parent modes would share the same setting.ini info. I'm trying to work with this, but...

I want to configure my edit modes to work out-of-the-box, even if the games aren't actually installed, by including all required DAT and IDE files in the proper directory tree so SB's searches can find what it needs and DAT file references work without modification.

Tying this all together; the new idea/issue/suggestion is a strategy for SB to use the files it finds in the user configured game directory if it can, and if not then fall back on the configuration in the edit mode. Also, the mode configuration should(?) be inherited by any child modes.

Originally posted by @OrionSR in #48 (comment)

Ok, let's break it down.

1. You propose a new debug option: Emit Defined Objects in SCM that controls whether the compiler should convert model names to numeric IDs, and add them in the header if it can't resolve the name (the default behavior for SCM as of now), OR always resolve the name to id and throw an error if it can't. (default behavior for headerless scripts as of now). By disabling this option we apply the second behavior to SCM files too. Correct?

2. You want an ability to provide default settings via the mode configuration. Note: currently debug options aren't persistent and only work in the current session. Do we want to change this behavior? Would we want for mode to control any configuration (e.g. Decompiler::AlwaysWriteOpcodes) or only debug options?

3. the new idea/issue/suggestion is a strategy for SB to use the files it finds in the user configured game directory if it can, and if not then fall back on the configuration in the edit mode.

I need more concrete examples for this. What's the behavior for disassembler/compiler/IDE autocomplete?

4. Also, the mode configuration should(?) be inherited by any child modes.

I don't get this one. Isn't it like what's implemented now? By "child modes" I understand ones having the "extends" attribute.

Originally posted by @x87 in #48 (comment)

-4 Okay, easy one first. I would expect the current behavior of inheriting settings from the xml file to be the best option. The other side if the coin is, the mode should inherit the game directory from from the parent. Emit Defined Objects should eliminate the need to have separate modes for SCM and Cleo in order to maximize IDE support.

-4 The other modes that should inherit the game directory would be SCR versions of each game mode. But I think this is better supported using separate modes.xml files for SB and SCR formats that share game IDs. So, if the game folder is set for SAv1 in SB's modes.xml then it doesn't need to be configured again for SCR. Any user settings propagate to the SCR modes as well.

-3 A PC edit mode is pre-configured to work using resources in SB:\data\modes. The game folder is then configured by the user and Sanny will use those, possibly modified, data files instead. This would be a seamless transition, requiring no changes to the mode files or settings, and the decompiler, editor and compiler would maintain the same level of IDE support.

-3 A PS2 edit mode is configured to use mode resources. but the user has modified files for use with an emulator stored in a local folder.

-3 A mobile edit mode is configured with mode resources, and the user sets a game directory in the user folder for the destination of compile and copy. The user folder doesn't have the required DAT files so SB falls back to the mode resources. Or, the game folder is set to a connected device but the device currently isn't connected.

-3 The primary goal of this idea is to allow a single edit mode to work for installed or uninstalled games. Basically, as long as Sanny's support files (SCM.ini, opcode.txt, etc) are the same then a separate edit mode isn't needed. The user wouldn't need to add an edit mode that inherits everything from a parent unless they had multiple installations of a game. For example; SA v1, SA Vanilla, SA v2 Downgraded. Or anything else that depends on different settings in settings.ini. Ideally, the behavior of the modules should be the same either way.

-2 Actually, I hadn't considered debug options like CODE_OFFSETS. Um... Not really sure but worth considering.

-2 I was thinking of EmitDefinedObjects as persistent in setting.ini like AlwaysWriteOpcodes. If a new edit mode is encountered the setting would be enabled by default, but for vc_mobile EmitDefinedObjects should be disabled. The edit mode entry would only be used to set the initial value.

-1 I'm trying to work something out so object ID are more consistent. When I first started using Sanny Builder it worked well for SCM, but when I started to learn cleo I was frustrated that I had to use object numbers to compile simple stuff like armor pickups. Later a routine was added that allowed Sanny to find object number for IDs in cleo scripts, but these object decompile to object numbers. The editor can't convert between IDs and numbers, or offer hint text. I can configure an edit mode so the hints, conversions and decompiling works the way I hoped, but this breaks defined objects in SCM.

And... I'm too tired and rambling but want to comment before I lose what I've got, so I'll probably clean this up in the morning, but...

I'm looking for a way to un-break define objects in SCM. Something like; IDE=default.dat and DAT=gta3.dat. DAT would function the same as IDE (base, IDE or DAT) but Sanny could tell the difference between models in IDE and objects in DAT when it needs to define objects in SCM.

Added: Cleaned up the grammar a bit but I'm not sure what else to clarify other than; The specific suggestions were included as examples but perhaps there are better solutions to the problems.

Okay, time to buckle down and get these edit modes working as best I can with the current version of SB. Now that the holiday is over I'll tell my work-at-home son to bug off and leave me alone so I can concentrate on the task at hand.

@XMDS Any luck getting that vc_mobile mode working?

Originally posted by @OrionSR in #48 (comment)

[XMDS]

@x87 I tested the configuration file of the VCM mode released by OrionSR, and it can actually be released as a basic mode. There are only minor problems, such as the model name is not properly decompiled:

029B: $1019 = init_object #-0.839783 at -375.499 -1322.31 9.81124

I think you can add VCM mode after 3.7.0

[XMDS]

In addition, in my opinion, after SB does not need the game directory at present, it seems that it is not so necessary for the game data file. Is the model name of the IDE file really necessary?

[x87]

There are only minor problems, such as the model name is not properly decompiled:

029B: $1019 = init_object #-0.839783 at -375.499 -1322.31 9.81124

Is this still an issue? I thought I fixed this in Sanny Builder 3.6.1

[XMDS]

There are only minor problems, such as the model name is not properly decompiled:

029B: $1019 = init_object #-0.839783 at -375.499 -1322.31 9.81124

Is this still an issue? I thought I fixed this in Sanny Builder 3.6.1

Yes. I use the latest 3.6.2, and it still has this problem（But not all）:

029B: $1018 = init_object #YT_MAIN_BODY at -375.499 -1322.31 9.81124 
029B: $1019 = init_object #-0.839783 at -375.499 -1322.31 9.81124 //   YT_MAIN_BODY2
029B: $1021 = init_object #YT_DOORS14 at -375.499 -1322.31 9.81124 
029B: $1022 = init_object #YT_TMP_BOAT at -375.499 -1322.31 9.81124 
029B: $1023 = init_object #LODMAIN_BODY at -375.499 -1322.31 9.81124

objs
2585, lodmain_body, yacht_lod, 1, 2000, 0
2586, yt_main_body2, yacht, 1, 70, 0
2587, yt_gangplnk_tmp, yacht_kb, 1, 200, 0
2588, yt_doors14, yacht, 1, 20, 0
2589, big_poly_tings, yachttings, 1, 30, 4
2590, yt_main_body, yacht, 1, 70, 0

2dfx
2586, 0.825104, -3.57983, 9.65795, 18, 77, 28, 200, 0, "coronastar", "shad_exp", 30, 0, 0.8, 0, 40, 1, 0, 0, 0
2586, -0.839783, -3.57983, 9.65795, 77, 18, 18, 200, 0, "coronastar", "shad_exp", 30, 0, 0.8, 0, 40, 1, 0, 0, 0

YT_MAIN_BODY2 Model ID 2586. Seems to read the coordinates of the second 2dfx? Why not the first one?

In addition, the same at the beginning of mian:

DEFINE OBJECT DTN_STADDOORA            // Object number -1
DEFINE OBJECT DTN_STADDOORB            // Object number -2
DEFINE OBJECT DTHOTRING_A              // Object number -3
DEFINE OBJECT BRIBE                    // Object number -4
DEFINE OBJECT CI_GATESCLOSED           // Object number -5
DEFINE OBJECT CI_BACKGATECLOSE         // Object number -6
DEFINE OBJECT INFO                     // Object number -7
DEFINE OBJECT YT_MAIN_BODY             // Object number -8
DEFINE OBJECT -0.839783                // Object number -9
.........
DEFINE OBJECT -4.58395                 // Object number -59
DEFINE OBJECT -4.38837                 // Object number -60
.........

[x87]

@XMDS I see the issue now. Actually disassembler does not use GetObjectID that had a bug which I fixed. Instead it reads IDE configuration and makes its own map of model names and ids that suffers from the same problem when the id is duplicated in a 2dfx section. I need to investigate what's needed to fix it.