Added a define for use in overworld triggers where the goal is to run the provided script in the immediate script context instead of the global one like normal. This is used in triggers in the desert, on faraway island, and a couple other places to do weather effects quickly and on the same frame. Suggestions for a better define name are welcome.
Some things I figured out while working on my hack.
- The Subsprite tables do not use `DISPLAY_WIDTH`, but rather use -16, since they are signed bytes. The negative numbers better illustrate what the tables are doing.
- Figured out the as-of-yet undocumented data in SpriteCB_FlygonSilhouette
If there are not externs on these forward declarations, it's entirely possible for the program to link and missing data to be assigned to someplace presumed in IWRAM or something.
- Determined how the various script contexts were used and renamed accordingly.
- ScriptContext2_Enable/Disable => Lock/UnlockPlayerFieldControls - The sole purpose of the flag is to make sure the player can't move around in the overworld. It has nothing to do with script contexts.
- ScriptContext1 => ScriptContext - It is the global script context used to set up scripts which run over many frames.
- ScriptContext2_RunNewScript => RunScriptImmediately - ScriptContext2's sole purpose was to run scripts immediately and in a separate context, usually while the global context is waiting for things like map loads or screen changes.
- Renamed members and added comments in the TrHillDisplay struct.
- Formatted the trainer hill data to better match the metatile layout its representing.
- Documented the function which uses this data.
Changed the trainer hill data for trainer locations, directions, and ranges from vague unusable numbers into readable data via use of preprocessor macros.
- This makes it easier for future hack makers to rearrange, add, or delete graphic object ids without having to count indexes or keep them in order.
- Porymap will have to be updated, but I have some code for this already in a fork.
Since we already have the KUN placeholder, there's no need for this {STRING 5} stuff.
Also, it makes it easier to delete all the {KUN}s in hacks later on if desired.
This descrepency was causing a lot of annoyance when using porymap, because porymap generated the ids in map_groups.h from the name, and mapjson was generating map_groups.h from the id in the json files. So just name them the same already like every other map in the repo.
The contest scripts actually use addvar to add a -1 to a variable instead of using subvar to subtract a positive number. This is fine in vanilla, where addvar script command does NOT support adding the value of a variable to another variable (like subvar supports), but should anyone want to change it, contests will be inexplicably broken.
The nops are essential to the hidemoneybox and updatemoneybox commands when using vanilla versions of those commands. Even though they're not actually used parameters in the command implementation, they are still consumed, which means if someone were to get rid of the nops (as I did in TriHard) it causes the commands to consume bytecode that are not theirs, resulting in undefined behavior usually leading to softlocks. Folding the extra bytes into the macros means there's no chance of the extra bytes getting losts in scripts.
Renaming the command to something that makes more sense as to what the command actually does. The command copies the current xy of the instantiated object back to its template, so that the object remains in the same place if the player walks away and despawns the object, and then comes back. "moveobjectoffscreen" implies that it might be taking the object and moving it physically to an off-screen location somehow.
Most of these are referenced via offsets, like the HP bar, which uses [0 pixels] + (number of pixels) to reference which chunk to draw. Each corresponds to a 16x16 pixel in the graphic named. Up to you guys if you want to rename the constants.
tustin2121