Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace all instances of "key checkpoint" with sector terminology #181

Open
vabold opened this issue Nov 30, 2024 · 1 comment
Open

Replace all instances of "key checkpoint" with sector terminology #181

vabold opened this issue Nov 30, 2024 · 1 comment
Labels
engine Code involving engine (C++) P4 Priority: Trivial quality Code quality improvements

Comments

@vabold
Copy link
Owner

vabold commented Nov 30, 2024

The term "key checkpoints" were used to describe the literal effect of certain checkpoints' check area being values other than 0 (to signal the finish line), and 255 (to signal a normal checkpoint). However, we now have a much better model for understanding how checkpoints are searched, and referring to "key checkpoints" actively makes game code harder to dissect and understand.

Sectors are, very simply, groups of checkpoints. Consider the following example, assuming the value 255 signals that the checkpoint is "normal" (and thus, a continuation of the current sector):

ID Sector
0 0
1 255
2 255
3 255
4 1
5 255
6 255
7 255
... ...
20 5
21 255
22 255
23 255

We can infer from this snippet that the known sectors formed look like this:

Sector List of IDs
0 0, 1, 2, 3
1 4, 5, 6, 7
5 20, 21, 22, 23

When we search for the player's current checkpoint, we search the current, the next, and the previous sectors in their entirety. The sectors determine the boundaries of the search. Because sector 5 is the highest observable sector ID, when we search for the player last seen in sector 0, sectors 5, 0, and 1 will be included in the search (due to those sectors being the previous, current, and next sectors, respectively).

Consider what we currently refer to in MapdataCheckPoint as m_lastKcpType, which takes the highest possible value of every checkArea in the KMP. However, knowing what we know now, this can be more elegantly labeled as m_highestSector (or some other label that communicates its relationship with the finish line). We can use this to grasp that moving from sector 0 (which houses the finish line checkpoint) into this highest sector from the finish line checkpoint will result in a lap decrement. The opposite is also true - moving from this highest sector into the finish line checkpoint will result in a lap increment.

@vabold vabold added engine Code involving engine (C++) P3 Priority: Low quality Code quality improvements labels Nov 30, 2024
@vabold
Copy link
Owner Author

vabold commented Nov 30, 2024

Nintendo mistakenly trusts that normal checkpoints cannot be entered without passing through either boundary. This leads to the game knowing where you are (in certain cases), but not updating the sector. This is notably why you are required to hit the sector boundary for ultra shortcuts - otherwise, the game would never recognize you've exited sector 0. This is fixable as a mod to the base game by recursing the previous checkpoint to find its corresponding sector ID, but we cannot implement it here without introducing desyncs.

@vabold vabold added P4 Priority: Trivial and removed P3 Priority: Low labels Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engine Code involving engine (C++) P4 Priority: Trivial quality Code quality improvements
Projects
None yet
Development

No branches or pull requests

1 participant