Special Handling when Decompiling Random GarGens

[OrionSR]

Sanny will decompile the model of the random car generators in Angle Pine (SA) as #INFO instead of the expected -1 setting for a random model cargen. I understand this occurs due to object definitions in main.scm but it's still a surprising and confusion result for a cargen.

[OrionSR]

How about %1m% for any data where random models might be expected.

[x87]

A new parameter type looks like a solution. Do you think %r% should provide a special treatment to the value of -1 and consider any other negative values as references to the object list, OR it should treat ANY negative numbers as arbitrary values and do not try to replace with a model name?

[OrionSR]

In the case of cargens - when viewed in the save a negative cargen value "remembers" the last model generated as -#model but that shouldn't be an issue in SCM.

I will be reviewing how model tags are used in SCM.ini anyway so I'll start to keep notes on how each code manages these values. It could be that pickups are the exceptions to the rule.

Something to consider, what would happen in a custom main with a different object definitions?

[OrionSR]

I found another exception in GTA3's main.scm:
01F9: init_rampage 'PAGE_00' 8 120000 $rampage_02_kills #FAKETARGET #PLAYERSDOOR #PLAYERSDOOR #PLAYERSDOOR 0 // .
In III, #PLAYERSDOOR is defined as -1 and #FAKETARGET is -2
From the opcode database 01F9:

The models can be set to -1 for any ped and -2 for any vehicle.

So -1 is used for random cars in cargens and -2 for cars in rampages. Kinda messes up the idea of #RANDCAR and #RANDPED.

The general rule, so far, seems to be that peds and cars can be random. Maybe weapons and car parts? These exceptions should never be linked to the defined objects in an SCM header.

Maybe m% would better distinguish models from %o objects.

[OrionSR]

I've been reviewing historical documents on opcodes and came across this reference from PLPynton's Unified Opcode Database: PLPyntons_UnifiedOpcodesDatabase_Reloaded.zip

; p% = pointer
; t% = reference to '.ide' object models only
; o% = object models all types
; g% = gxt reference 8-byte strings
; x% = external script
; m% = statistics
; b:truestring/falsestring% = replace with truestring if nonzero,  replace with falsestring if zero

Based on how t% is used in this SASCM.ini, it looks like %t was originally intended to serve the purpose I had suggested for m%, and that m% was being used for stats, not sure how. I have considered enumerating the stats as constants though.

Looks like there was a plan for bool too.

[x87]

Custom parameter types (such as statistics or boolean flags) can be useful given an easy way to map onto the constants list (e.g. statistics names). Current INI syntax is hardly capable of helping there.

[OrionSR]

Well, I enumerated the stats anyway. Added them to the spreadsheet but haven't been updating the constants.txt.

Who gets to decide the current INI syntax? Let's get together and see if we can't come up with a consensus on a strategy to map constants. This new feature is seriously complicating my efforts to manage opcode.txt through Sanny's decompiler. Love it though. I keep making more lists.

Something else to keep in mind; h% is currently being used to denote handle in the traditional SASCM.INIs, and when they ported it to SCR the letters didn't get moved with the argument order so it's all out of wack. It's probably best to keep %h as a reserved unformatted data type.

[x87]

@OrionSR adding support for %m params. I need your assist on changing opcodes appropriately. So far I updated these:
sannybuilder/data@12261a1

Let me know the remaining opcodes for SA and other games.

[OrionSR]

Well... I stopped taking notes on this issue when I came across this document.

PLPyntons_UnifiedOpcodesDatabase_Reloaded.zip

In this SASCM.ini t% is consistently used to denote models, o% for objects, and to confuse the issue, m% was used for stats.

Should the function of t% be changed from the same function as o% to the same as the new m%?

A lot of the heavy lifting can be managed by searching for t% in this document as a first pass for SA, and much of that should cover VC and III as well.

More than likely this old document is missing opcodes that have been more recently defined.

[x87]

Updated all INIs with the new m% parameter
https://github.com/sannybuilder/data/pull/6/files

[OrionSR]

Oh joy! Now I need to propagate these changes to my PS2 edit modes, and mobile modes for III and VC.

Any chance fastman92 will implement these changes in his Script Command Definitions?

Opcode.txt will need to be updated with the new INIs, something I can't do properly using v3.5.1. But there are larger issues with opcode.txt anyway. Mainly, they are always incomplete when generated from main.scm - cleo opcodes are often missing. I was planning to create special main.scm files that includes every opcode, but it starts with fastman92's more complete opcode.txt. Hence my previous question.

[x87]

Hence my previous question.

what is it?

[OrionSR]

Any chance fastman92 will implement these changes in his Script Command Definitions?

[x87]

That I don't know. Worth asking in https://gtaforums.com/topic/943982-fastman92-script-command-definitions

[OrionSR]

It don't think it wise to interrupt his important work with such trivial concerns. I'll just make the changes I like as I update the datasets in opcode.txt.

Custom parameter types (such as statistics or boolean flags) can be useful given an easy way to map onto the constants list

B is for Boolean: True or False - And only True or False as defined in keywords.ini. Change the descriptors so the desired value can be set without documentation. Currently I'm using $True and $False as placeholders that can be fixed later with search and replace.