sannybuilder / dev

Sanny Builder Bug Tracker and Roadmap development
https://sannybuilder.com
49 stars 0 forks source link

Legacy Support and Compatibility #34

Open OrionSR opened 4 years ago

OrionSR commented 4 years ago

"existing keywords and classes must be preserved in order to keep backward compatibility"

Priority of Keywords: I thought I mentioned this issue in another context but now I can't find it. Keyword.txt can support multiple keywords for the same opcode, but the sort order, iirc, is to use the alphabetically last example.

I'm not sure how Classes are managed in this context. Can Sanny support more than one class definition and what is the priority for decompiling?

"it may well be that some descriptions in opcodes and higher-level instructions do not match"

I'm pretty sure that I read somewhere that SCM.ini can support multiple opcode definitions, and the last example encountered is the priority for decompiling. But I'm not sure if that matters for the INIs; just documenting the options.

Keywords for math operations are ugly and awkward. Better to keep those things working the same way.

CustomVariables.ini should have no trouble supporting the traditional names and an updated naming convention based on the official GTA3 variable names. I forget the priority for decompiling. I believe some of the current variable names are way off the mark.

OrionSR commented 4 years ago

Could keyword be defined in scripts?

Many of my scripts are developed on PC before porting to PS2 or Android. The PS2 ports are usually fairly straight forward, but for Android, especially when cleo opcodes are involved, there's an awful lot of comment toggling required to convert the script to the other version.

An example of the problem,

0A8D: $HandleArray(handleIndex,175i) = read_memory readAddress size 2 virtual_protect 0 //{PC}
//  0DD8: $HandleArray(handleIndex,175i) = read_memory readAddress size 2 add_ib 0 // {Android}

In this case the commands are similar enough that I could define keywords in each edit mode and avoid a lot of changes. But the purpose for the last parameter is not the same. This wouldn't be a good permanent keyword in all cases; this is a hacky idea that just happens to work well in this particular script.

More to the point, the script wouldn't be useful to other users without modifying their keywords too, so a way to define keywords within the script might be helpful. Maybe. The proposal of in-script class definitions. along with in-script definitions for most other other... elements(?), I figured the idea might be worth considering.

A more flexible and less hacky solution to the basic problem of script conversion would be more helpful in this particular situation though. I have an idea on that, but will post in other topic; I figured keyword definitions might be an idea worth considering on it's own.

x87 commented 1 year ago

249

x87 commented 9 months ago

305