Install directory optional and only used for Compile and Copy #48
In fact, I think the directory is really unnecessary or configure a minimal game data folder.
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?
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
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© feature is not available.
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.
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.
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.
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.
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.
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:
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.
Issue: Sometimes the model ID is corrupted by 2dfx entries.
Corrupted by 2dfx
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.
Ok, let's break it down.
I need more concrete examples for this. What's the behavior for disassembler/compiler/IDE autocomplete?
I don't get this one. Isn't it like what's implemented now? By "child modes" I understand ones having the "extends" attribute.
-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
-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?