Install directory optional and only used for Compile and Copy

[x87]

Game directory should not be mandatory (and sometimes is just missing -- Mobile games) and only required for Compile&Copy. All data files can be controlled via mode configuration.

[x87]

See #6

[XMDS]

In fact, I think the directory is really unnecessary or configure a minimal game data folder.
In fact, the mobile version is necessary. For example, VC and 3 mobile modes. I don’t know about GTA3, but some global variables of the VC Android version are slightly different. For example, the two variables representing the player are not ACTOR and CHAR.
In Android VC, it is $303 and $304. It is necessary to make a separate mobile mode for VC. Of course there are other differences.

[x87]

@XMDS I believe that is what @OrionSR had in mind in #6 If he would be kind enough to share his work I can include those new modes with the SB update.

[OrionSR]

I have a vc_arm edit mode setup for SB 3.3.3 built around a customvariable.ini with appropriate modifications and vc android data and text files. It shouldn't be too difficult to update the edit mode with the 3.4 features but my confidence is the quality is low because I seldom work with VC and haven't tested the mobile edit mode beyond decompiling a standard main.

@XMDS Would you be interested in testing a vc mobile edit mode to improve our confidence in the quality before publication?

[x87]

I think I need to re-purpose Game directory setting and separate it from the Compile&Copy feature. My thoughts:

Game Directory is optional and only used to resolve the @game: variable in games.xml. If the directory is not present you might not get extra information during decompilation (such model names, gxt texts, etc), but it highly depends on mode configuration. A mode could be self-contained starting from v3.5 and all files could be served from the local directory.

If not set: decompilation still works, but some files might not be loaded (if they use the game variable in the mode config).

Copy Directory - a new configuration. Also optional and only serves as a target directory where the compiler should copy the result. Could be any local directory or connected device. #11

If not set: compile&copy feature is not available.

[XMDS]

I have a vc_arm edit mode setup for SB 3.3.3 built around a customvariable.ini with appropriate modifications and vc android data and text files. It shouldn't be too difficult to update the edit mode with the 3.4 features but my confidence is the quality is low because I seldom work with VC and haven't tested the mobile edit mode beyond decompiling a standard main.

@XMDS Would you be interested in testing a vc mobile edit mode to improve our confidence in the quality before publication?

Yes. The reality is very busy recently and there is no reply to the message. I can help with the test in the last few days, but I don’t know what to test. Can I just use the VCM mode to edit the CLEO script to test? Or, we should change to a convenient social chat software.

[OrionSR]

Sure. If you can find me in a common Discord server (SP?) then send me a direct message. Or you could send me a PM on GTAForums with contact info on Discord.

But... I don't think I should try to take any shortcuts. I need to get Sanny 3.5 installed and start working with the edit modes again. I've got another project I think I can wrap up today, then I'll get started. (My main concern is getting my current edit modes properly archived so I can start working with a clean install.)

And where to work? My preference, as usual, is on GTAForums. Moving the discussion there would make it the first thing I check when I sit down at the computer. And for many of these edit modes I'd hope to recruit some more input from people that actually use them. I've got an old Edit Mode topic that could be revived, or perhaps a new topic would reduce confusion with issues in previous versions.

https://gtaforums.com/topic/824135-sanny-custom-edit-modes/

But GTAForums doesn't manage attached files, and hosting on Google Drive or Dropbox has been an awkward solution. Hopefully we can manage the files with Github. I had something setup on Github for various formats of CustomVaribles.ini but that way years ago and is in pretty poor shape. I doubt it's worth fixing. @x87 What strategy should we work towards.

Doesn't seem to work anymore: https://github.com/OrionSR/CustomVariables.ini

"Testing" could involve just actually using the edit mode to see if anything breaks. Converting or writing scripts that make heavy use of custom variable names is the primary focus. Decompiling with and without custom variable names can often highlight issues. Also, comparing decompiled main.scm files from each version can demonstrate consistency in variable names. Tough work though as many differences will always be present for the numbered variables.

How easy is it for you to compare IPL files for each version? I think I was using WinMerge to compare PC and mobile data files for SA and for the most part the only difference was that LOD distances changed for some objects. But as far as Sanny is concerned that shouldn't matter. I could conserve space by sharing the save data set.

[x87]

What strategy should we work towards.

As usual I would suggest using GTAMods.com for collaborative editing, even though this site gained questionable reputation for instability. I think most if not all involved people have an account there. Thats the easiest way.

Github could be an alternative (e.g. this repo: https://github.com/sannybuilder/data) but it requires extra familiarity with git.

[OrionSR]

Edit Mode for VC Mobile - vc_mobile.zip

Issue: Defined objects in the VC mobile main.scm are not decompiling as expected. I suspect the problem is that the values were encoded with their IDE numbers instead of the negative values used to define the objects in the SCM header. This might have a larger influence of how scm files should be compiled for vc mobile.

This is a bare bones edit mode because I wanted to post something in order to get feedback on why generic..ide seemed to work for VC but not vc_mobile. I now suspect the problem is related to how the main script was compiled. I'm going to continue working to get, at the least, generic.ide working for compiling, and hopefully compile support from the full set of standard map files.

At this point I'm not expecting Sanny to decompile hashed model IDs for anything not defined in the header or default.ide. SA has as few more "default" IDE files, and usually I can get SA mobile to decompile... all IDEs by way of references in custom.dat, iirc.

Update: Never mind. Generic.ide is now decompiling properly for vc_mobile. I just had to dig a little deeper into the new mode updates. But it's not working for the VC mode.

Files:

• classes.db - no changes
• constants.txt - no changes
• CustomVariables.ini - updated for VC Mobile
• keywords.txt - no changes
• missions.txt - no changes
• opcodes.txt - updated with mobile and CleoA (incomplete) command descriptions
• templates.txt - using file from sa_mobile, unsure of multiscripts in this context
• VCSCM.INI - updated with mobile and CleoA commands
• modes - Original.xml - for backup
• modes.xml - copy to @sb:\data to enable new edit mode
• data\default.ide - from installed files on Android
• TEXT\american.gxt - from installed files on Android

Installation:

• Copy vc_mobile.zip to Sanny's data folder and extract all files
• Replace @sb:\data\modes.xml with the updated file in the vc_mobile folder
• (Re)start Sanny and switch to the vc mobile edit mode
• For now, set the game directory to an appropriate destination for Compile and Copy

[OrionSR]

VC Mobile Edit Mode with full IDE support - compile and decompile - vc_mobile.zip

This edit mode takes better advantage of the new edit mode features:

• unmodified support files are inherited using "extends" and removed from the folder
• opcode.txt examples is specified in mode.xml, but were working before anyway
• gta_vc.dat is referenced and will load generic.ide and all other ide files under maps
• relevant DAT and IDE files were added to the data folder
• game directory is still required by Sanny for a Copy and Copy destination but isn't needed for the edit mode

This script is being used to test the IDE support. The first 4 entries are from the end of the PHIL_1 mission, peds, vehicles and weapons from default.ide, #gunbox from generic.ide, and the rest were taken from the first obj entry of each IDE file in the maps subfolders.

{$CLEO .csa}

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 

Issue: Sometimes the model ID is corrupted by 2dfx entries.
Original:

0249: release_model 4780 // lw_room_main 
0249: release_model 1210 // miamiland037 

Expected:

0249: release_model #lw_room_main 
0249: release_model #miamiland037

Corrupted by 2dfx

0249: release_model #2.10084 
0249: release_model #-53.9467 

From lawyers.ide

objs
4780, lw_room_main, hi_cutlaw2, 1, 100, 32
{...}
2dfx
4780, -2.52195, 2.5576, 2.06855, 208, 200, 178, 200, 0, "coronastar", "shad_exp", 100, 2, 0.3, 0, 40, 0, 0, 0, 0
4780, 2.09849, -0.547936, 2.06855, 208, 200, 178, 200, 0, "coronastar", "shad_exp", 100, 2, 0.3, 0, 40, 0, 0, 0, 0
4780, 2.10084, 2.05608, 2.06855, 208, 200, 178, 200, 0, "coronastar", "shad_exp", 100, 2, 0.3, 0, 40, 0, 0, 0, 0

[x87]

Issue: Sometimes the model ID is corrupted by 2dfx entries.

Interesting find. Must be an issue with GetObjectID. I will create a ticket for record.

[x87]

Related to #6

[OrionSR]

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.

[x87]

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.

[OrionSR]

-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?

[x87]

@OrionSR moved the end of discussion to a more relevant topic #6