Extended Constants.txt

[OrionSR]

I investigated how constants are assigned by 04AF: in San Andreas and used this information to add about 170 entries to constants.txt. I've grouped the constants under the following headings as an example of how the constants might be organized. Of these categories, 3 have potential for decompiling to specific opcodes, bool, sprites and bodyparts.

[GENERAL] - just the timers
[BOOL]=b - added yes and no, enabled and disabled
[SPRITE]=i - radar icons tend to get modded a lot
[BODYPART]=y - where to hang your hat
[TOWN] - town numbers
[RACE] - Race Index
[TOURNAMENT] where the races start
[CARMODS] bodyparts for cars
[PROPERTY] Buy Property Index
[SOUND] easy audio events that play without loading

sa_constants.txt

https://docs.google.com/spreadsheets/d/1ageNMPHWOFhVa7JgQ5-1aDuUKMgRPRFrMjvhJtZGKec/edit?usp=sharing

[OrionSR]

I was considering adding a set of interior constants but there isn't really a common reference for their names. Historically, Heaven A and Heaven B, etc, I ended up using the name of the first or most dominant interior name associated with that particular heaven in my 010 templates. Either way, reference remains necessary, and is already included with Sanny Help.

Added: Better plan. Enumerate each interior with the appropriate heaven number. These don't need to be resolved so there won't be any conflicts.

[OrionSR]

I added constants for Interiors, Weather, ZoneType and PedType to the spreadsheet linked above but decided to stick with constants as defined by 04AF: in the current example.

The use of constants would benefit from features like autocomplete, conversions and syntax highlighting.

Syntax Highlighting: I keep running into missing parameter errors as I update my constants. Perhaps, blue like a variable, and bold like a keyword, would help distinguish constants from descriptors.

[x87]

Syntax highlighting for constants had been proposed in #28

[x87]

I'm thinking about adding a proper support for enums: https://en.wikipedia.org/wiki/Enumerated_type In this case it will be a group of constants logically grouped around a single domain.

Possible syntax:

enum Bodypart
  Torso                           // starts from 0
  Head                            // increments by 1 on each line
  Legs                            // 2
  Glasses = 15                    // counter advances to 15
  Hats                            // 16
end

usage:

087B: set_player $PLAYER_CHAR texture "VEST" model "VEST" body_part Bodypart.Torso

[OrionSR]

I like this idea. My constants Sheet can easily be adapted to this format except... currently the period is an illegal character, so I can't switch yet. I think most of the enums from the 010 save template have already been converted.

If enums can be decompiled then I love this idea.

A related issue, do the descriptors, the words in a command that provide context for the data, need to be updated? My impression is that the descriptors haven't really changed much since they were initially used and may not be specific enough in a modern context. For example, 087B uses "body_part" where similar commands use "bodypart."

Also, I've been trying to match my constants with the descriptor in a way that the descriptor can be converted directly into a constant or enum, hopefully with a little help from auto-complete. For example,

087B: set_player $PLAYER_CHAR texture "VEST" model "VEST" Bodypart 0  // updated descriptor
087B: set_player $PLAYER_CHAR texture "VEST" model "VEST" Bodypart.Torso // as suggested
087B: set_player $PLAYER_CHAR texture "VEST" model "VEST" Bodypart Bodypart.Torso // decompiled

Not sure how to resolve the consistent use of caps, but that's the general idea.

[x87]

If enums can be decompiled then I love this idea.

this is where typed parameters in the INI file would shine sannybuilder/data#1

If I can add a proper support for custom letters/words in the INI, we could go through the list and tag parameters with the enum name. The decompiler would then be able to display the enum instead of a number.

[x87]

A related issue, do the descriptors, the words in a command that provide context for the data, need to be updated? My impression is that the descriptors haven't really changed much since they were initially used and may not be specific enough in a modern context. For example, 087B uses "body_part" where similar commands use "bodypart."

feel free to update as needed. I'm all for consistent naming across all games/platforms. As long as parameters order remains unchanged I'm good.

[x87]

Excellent reference for Rockstar's constants/enums: https://gtamods.com/wiki/SCM_language_III/VC_definitions#Constants

[OrionSR]

An excellent source for mining enums is DK22Packs Plug-in SDK, like this example from Radar:
https://github.com/DK22Pac/plugin-sdk/blob/master/plugin_sa/game_sa/CRadar.h

I frequently use this source for enums and other info, and have adapted the naming conventions extensively in my save templates and other references. Since this is a very common reference for GTA in general it would add clarity to the information if the the same general conventions were used.

[x87]

I'm thinking about adding a proper support for enums: https://en.wikipedia.org/wiki/Enumerated_type In this case it will be a group of constants logically grouped around a single domain.

Possible syntax:

enum Bodypart
  Torso                           // starts from 0
  Head                            // increments by 1 on each line
  Legs                            // 2
  Glasses = 15                    // counter advances to 15
  Hats                            // 16
end

usage:

087B: set_player $PLAYER_CHAR texture "VEST" model "VEST" body_part Bodypart.Torso

this syntax has been implemented in v3.6
sannybuilder/data@ba3a4ed

enums.txt (as defined with the new <enums> entry in the classes.db) now holds the list of enumerated types that are being used for classes parameter types. in the future it 's planned to add the enum support for raw opcodes (see #75).

[x87]

Added as enums.txt
https://docs.sannybuilder.com/edit-modes/enums.txt