Conflicts with Using SA_Mobile Mode with PS2 Versions

[OrionSR]

American.gxt from either version of SA for PS2 (or PC) doesn't work right when using sa_mobile mode.
I would prefer to use the PS2 GXT, but the PS3 GXT appears to be reasonably compatible.

[OrionSR]

Local variables 40@ and 41@ get decompiled to timera and timerb. Changing constants.txt has no effect. There doesn't seem to be any way to stop this behavior.

[OrionSR]

BIN files are another potential conflict. I don't understand these files well enough to check. Are PC bin files appropriate for PS2?

[x87]

SA_Mobile is intended to use only for Android/iOS versions of GTA SA as they have some extra opcodes. For PS2/PS3 the ordinary GTA SA mode should've been used (or a new mode?)

BIN files contain chunks of main.scm for a few debug opcodes (05B6, 0a66, 0a67, 0a68, etc). The disassembler replaces raw byte date with an index to the particular chunk in the bin file and the compiler then uses this index to put the data back. Normally this data is just a garbage and even there is some discrepancy between version it won't make much difference.

40@ and 41@ get decompiled into timer constants since 3.3.0 and this is an intended behavior for SA Mobile mode where these variables have special meaning. In other versions of GTA SA they are not timers and as I said before another mode should be used to decompile them.

[OrionSR]

PS3 and Xbox360 would need to use SA_mobile mode for the unicode GXT and local timers. And their command set is basically 3 opcodes added to the mobile commands, but commands can be independent of mode.

SA_mobile mode was working for PS2 with an alternate GXT until the timers were forced into the script. I can't find an option to disable this behavior.

Can GXT unicode or ansi detection be made independently of mode?

My current thinking is that new edit modes might be more appropriate. An "external"(?) mode intended for PS2, PC games that aren't currently installed, and mobile versions of III and VC. These modes would be similar to sa_mobile in that they are pre-configured with references to all needed support files - no need to set an install directory or Compile and Copy to a program folder.

If GXT was auto-detected and Timers set within the edit mode then this mode could replace the sa_mobile mode. But it's getting hard to fit things within the existing framework of the game definitions.

[x87]

@OrionSR

Can GXT unicode or ansi detection be made independently of mode?

this was implemented in 3.4.0. Anything else for this issue, or I close it?

[OrionSR]

The basic conflict still exists, due to the Timer aliases, but the problem now is more about getting a PS2 edit mode to work with the PC setting. I'll need to play around with the new modifications to see how things work. If there is still a problem it can be a new and PS2 specific issue; this one can be closed.

[x87]

mode="sa" assumes 32 local variables + 2 timers in a script and mode="sa_mobile" assumes 40 + 2. How many local variables PS2/PS3/XBox versions have?

[OrionSR]

"sa" assumes the game is installed an an appropriate destination for Compile & Copy. "sa_mobile" has a flexible custom.dat configuration. However, the conflicts with local timers, and probably inappropriate range checking, suggests that sa_mobile will only be appropriate for Mobile and Remastered versions of SA - iOS, Android, WinStore, Xbox 360/One, and PS3.

I want to retool my edit modes for the update before commenting too much on why "sa" or "vc" modes for PC might be inappropriate for PS2 or VC mobile, but I suspect it's mostly Compile & Copy adding scripts to the edit mode or "base" folder.

Another thought on Compile & Copy. It might be nice if mobile mode could copy to a cloud folder or removable device so it could serve the same purpose of activating the script. This is something that could be tested with a VC mobile edit mode.

[x87]

Another thought on Compile & Copy. It might be nice if mobile mode could copy to a cloud folder or removable device so it could serve the same purpose of activating the script. This is something that could be tested with a VC mobile edit mode.

Yeah, we have a ticket for this #48 (comment)

Given that IDE files configuration becomes available via modes.xml starting from v3.5 (#47) I believe we could close this ticket.