Replies: 7 comments
-
VariablesI'm working towards a more descriptive set of commands that are independent of the specific main.scm files. The current goal is to create a compiled example.scm that includes all opcodes so the the make_opcode tool can generate a complete list of examples with an updated command set. The compiled data can be disassembled using INI files with any parameter order. I'm trying to avoid local variables since they aren't descriptive, and not using arrays since they clutter the examples unnecessarily. True/False - Since Sanny doesn't support a Boolean data type I'll remove the $ from $True and $False to denote the nature of the setting. Descriptors for the data should imply the proper value without additional reference. For example, $Enum - Actual data would be preferred but I want to keep track of where additional documentation is needed. Descriptors for enums include a trailing underscore because that currently works well for auto-completing constants. Integers
Floats
Handles
Updating as I progress, but that's it for now. |
Beta Was this translation helpful? Give feedback.
-
EnumerationsAs I've been working my way through the scripts I've been marking descriptors of fields that might be appropriate for enums with a trailing underscore. Often I'll find documentation that could be adapted to enums, but then losing track of the link I plan to use this post to update the enums I've identified with links to the documentation. This should help also help with Sanny's overall documentation. It is not always clear of the values given are appropriate for GTA3. 'AUDIO' gtamods pedtype_ gtamods |
Beta Was this translation helpful? Give feedback.
-
Opcode OverhaulI have finished my first pass through the example codes (opcode.txt) and starting the process of updating the opcode definitions (SCM.ini). The process should help shake out more errors and typos in the manual updates of the examples. My current goal is to simply get the examples to compile - adding missing opcodes, and resolving issues with parameter count in the examples. Once compiled I can decompile, compare the output, and make adjustments until everything matches. I need to write this next bit down as reference as I work. SB's Opcode Parameters Like d%, other parameter types have no special formatting. I'm using several for Informational reference of specific data types. i% = integer - informational Keyword Updates: |
Beta Was this translation helpful? Give feedback.
-
@OrionSR I'm thinking of using In a next version I'd fill this placeholder with enum names so that Sanny becomes aware of which enum type to use to replace numbers with during disassemble and do the opposite conversion during compilation. E.g.:
this would make changes to INI files two-way compatible with any Sanny version. Old INI files with Let me know what do you think? Does it make sense or just update INI altogether and force people using correct Sanny version with correct INI file? |
Beta Was this translation helpful? Give feedback.
-
Before I forget, the precision of the decompiled floating-point values is terrible - not hard to adjust for the next run through. I'm assuming that GTA3 is using 16-bit "short floats" but I'm having a hard confirming this with available documentation. In general, I'm not comfortable with the b-for-enums solution. But I suspect that's because I've been thinking along different lines. I will reconsider as I continue to work. (Slept on it; ideas are starting resolve.) First of all, this is a critical discussion that will have a large impact on how the command overhaul proceeds. I'm having a hard time visualizing what the final product will look like as the examples progress from RockStyle-SCR to RockStyle-SB with classes without breaking anything. My lack of experience using classes is major problem. Please post a few examples of how enums and bools might appear when used within classes. I think it would be pretty cool if So far I've identified about 45 data types that are appropriate for enumeration. Everything I could resolve as boolean was skipped. Including enum declarations and documentation of the uncounted boolean data types would significantly increase the complexity of the enumeration process. Boolean descriptors are freeform; they can be tweaked for clarification without needing to fix something somewhere else. Compatibility Between Sanny Versions: In general, I would hope that legacy formats for opcodes (SCM.ini) to be forward compatible with newer versions of SB. I would not expect newer command sets to be backward compatible. However. I think backwards compatibility is a worthy goal if it can be accomplished without too much difficulty. I haven't seen e% used elsewhere, yet, and as a generic data type the fields should resolve to the same values as before... Unless I do something weird like try to define an enum key like the legacy bools, or, maybe, connect the descriptor key directly to e% with a dot separator. How about, e% for enumeration, and the key is the preceding descriptor. Perhaps require a trailing dot for identification. Currently I'm using trailing underscores so I can simulate enums with constants, but in the examples below I've worked in the dot. I'm just playing around here, trying to get a feel for what things might look like:
|
Beta Was this translation helpful? Give feedback.
-
this is correct. GTA3 uses 16-bit integers to represent decimal values
yes, I can do that, but in general I'd avoid duplicating things in updated INIs (i.e. INI file should use only %t or only %m).
I feel it makes heavy impact on the code decompiled with older Sanny versions and new INI and adds unnecessary ambigous syntax to opcode descriptors. Nowadays words between parameters are just another form of comments and I would like to keep it, not making them part of the syntax. If using
which decompiles to
or
with classes enabled I'm not too worried about new syntax being incompatible with older Sanny version as it would encourage people migrate to newer Sanny sooner to benefit from the updated opcode definitions.
Examples using updates classes from #62
note that classes do not have a notion of enums so old "extended" params still appear (CivMale). In the future the last command should decompile as
|
Beta Was this translation helpful? Give feedback.
-
Added new enums to classes.db to replace old "extended" params I chose camelCase naming convention over R* SCREAMING_SNAKE_CASE to better match existing Sanny syntax. |
Beta Was this translation helpful? Give feedback.
-
GTA3CommandOverhaul - Google Sheet (wip)
After several long days I've only managed to work my way through a third of the GTA3 opcode examples, but I've made enough progress to give a good impression of what I'm trying to create. I was hoping that starting with fastman92's script command definitions would give me a better head start because I've already worked through the common SA commands, but the GTA3 definitions are still pretty messed up. This is going to take a while.
Please comment on the conventions being used. Issues with keyword inconsistencies and formatting will likely work themselves out as the file is reprocessed through an updated SCM.ini. Is it worth continuing in this direction?
Please keep in mind that this version is not intended to be the final product. Many of the conventions are in place to help me reprocess consistent keywords (True/False), INI updates (handles for classes), and enum documentation.
I need to formalize my conventions as I continue to work so I'll add more specific info shortly.
Beta Was this translation helpful? Give feedback.
All reactions