(WIP) make per-level segment loading not suck

[someone2639]

(NEEDS TESTING)

• Fast64 seems to just do its own thing and overwrites the custom macros
  • (Does Fast64 obsolete this PR entirely?)
  • Current implementation adds macros on top of existing ones, but can we replace those without breaking things?
  • LOAD_GROUPA and LOAD_GROUPB seem unused, would like to hear from users of these macros if they exist

Example Usage would look something like this (only have to write that one command instead of 3)

[gheskett]

I wouldn't call it completely 100% obsolete given the use cases of custom level scripts and the fact that idk if fast64 really even touches that stuff. I'm admittedly not huge on those scripts.h defines btw but I don't have a great alternative suggestion.

[someone2639]

the scripts.h changes are necessary otherwise fast64 would actually cause compilation errors lol

[gheskett]

Figured that might be the case...unforch.

[gheskett]

In that case, I'd just ditch the A and B macros tbh

[someone2639]

macros are consolidated except for LOAD_COMMON0 and LOAD_COMMON0_FULL because floombas break if you load every model from common0 for some reason

[gheskett]

That sounds like a bug, how is that even possible

[someone2639]

it does a jump to null and crashes, I think it's because the scripts segment is not loaded yet so you can't jump to the data formerly known as script_func_global_1

[someone2639]

I think there's water in my theory from above, as copying the contents of common0_load_geolayouts into the intro script works fine but the jump link doesnt

[gheskett]

Also just a forewarning, there's a strong chance a new fast64 version will handle placing geo loads for you. In other words, common1 and group0 are probably not going to work with jump scripts.

[gheskett]

Gonna close this for now; i don't see a good way to do this cleanly (and safely) that's worth the change atm, especially when fast64 might handle object banks in the future and/or we ditch object banks completely.