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.