Difference between revisions of "Conditional Out of Bounds (kHacker35000vr)"
(v1.1) |
m (oops) |
||
Line 73: | Line 73: | ||
60000000 00000000 | 60000000 00000000 | ||
</pre></spoiler> | </pre></spoiler> | ||
− | <spoiler text="Conditional OoB, NTSC-J"> | + | <spoiler text="Conditional OoB v1.1, NTSC-J"> |
<pre> | <pre> | ||
− | Conditional OoB | + | Conditional OoB, NTSC-J [KHacker35000vr] |
c25163dc 00000016 | c25163dc 00000016 | ||
2c030000 4d800020 | 2c030000 4d800020 |
Revision as of 12:52, 13 July 2020
This is a cheat code created by kHacker35000vr. This makes it easier for track authors to implement intersections without having to worry about unintended fall boundaries being triggered when someone on the lower part of the track gets too much air. It makes use of the unused AREA type 10, which will serve as the conditional out of bounds.
Track authors can implement a conditional out of bounds by changing setting 1 of the AREA to either 0 or 1. Value 0 will only enable the AREA if the condition is met, while value 1 will disable the AREA if the condition is met. Setting 2 of the AREA defines a key checkpoint region. If a player is currently inside the given key checkpoint region, the condition is true. Due to how it is recommended to never place key checkpoints on intersections, as this may cause Position Jump Bugs, the code does not require specific checkpoint setups to work properly and authors can freely alter checkpoints without having to worry too much.
The code has to be activated by changing the route setting of AREAs to 1. Other values disable the code completely.
C code
The following code snippet demonstrates how the current key checkpoint and the AREA settings determine if a fall boundary is active.
if (area->setting1 == 0 && playerInfo->currentKcp == area->setting2) //Activator return areaId; else if (area->setting1 == 1 && playerInfo->currentKcp != area->setting2) //Deactivator return areaId; else return -1;