HackerN64/HackerSM64

Missing vanilla level checks stuff / workarounds

gheskett opened this issue · 3 comments

  • The endless staircase makes it impossible to get to BitS without a BLJ unless vanilla checks are enabled. This should be modified such that the endless staircase code is attached to the vanilla script instead so that it's removed by a level export rather than the define.
  • COURSE_BITDW and COURSE_BITFS success warp behavior is hardcoded in multiple locations when it instead could check for whether the last collected item was a key in each scenario.

should we add a tag for potential defers? I don't think this should wait for 3.0, but I don't think it should block 2.1 if we get the remaining issues completed. at this point I think any bugs/issues found should only be fixed in 2.1 if

  1. There is plenty of time, low complexity, high reward
  2. It is a new dev 2.1 bug (regression)
  3. Or if it is a critical bug already in master

The second item here I would consider a feature since it adds flexibility to where keys are. Very small and non critical, easy defer to 2.2 or 3.0.

And the first item here is more what I would consider a medium issue in Master since it could affect people's instant warps but since it isn't a regression in feature set, it doesn't need to be included in 2.1 though useful enough to potentially warrant a 2.2. More thought would have to be put into it because there is a non zero chance somebody creates a custom hub with an unlockable infinite loop.

At some point we need to cut off 2.1 for little things because even if they aren't being done by myself or others working on more critical issues, those people will likely have to spend time either reviewing or discussing implementations instead of working on Fast64 and dying inside

Agreed, the only way I personally think this should and could be addressed in 2.1 is a first build console message as well as important notes in the readme

Moving out of 2.1 scope