Reset Binds

Ark_

There has been dissussion recently around how reset binds should be handled in two separate areas, what exactly is resettable, and and the actual binds themselves. The first I think is a discussion for another time, but the second is much more concrete.

Currently, momentum has 3 separate bindable teleport commands, mom_restart, mom_restart_stage, and mom_saveloc_current. The behavior of these three is mostly exactly what the command says, restart will restart the map, stage will bring you to the last stage start zone you were in assuming one exists, and saveloc_current brings you to your last active saveloc. There is some subtlety I am leaving out but that is outside of the current scope.

The problem with this current setup as I see it is that we simultaneously have too many commands and not enough commands. We don't have enough because if you are playing a bonus or a mode without "stages" like rj, there isn't a clear correct command that does exactly what you are looking for. There are too many commands firstly because restart_stage and saveloc_current actually do the exact same thing, just in separate and non-overlapping contexts.

What I would propose is to rescope and rename restart_stage as a generalized "last resettable location", which would bring it more inline with the behavior of sm_tp and sm_stuck that people are already used to from servers, and also would work as saveloc_current so people who prefer to have a dedicated bind don't need to use an swap alias with there current reset button or bind an extra button.

There was also talk about reverting the change to restart_stage to also restart map on maps with no stages game#1579, I think it makes sense to keep the functionality as is as i pointed out there.

rio

Ark_ What I would propose is to rescope and rename restart_stage as a generalized "last resettable location"

I agree it should function as an all-inclusive way to go back one location, whether that's to the beginning of the stage or the very beginning if its a linear map, and it should work on bonuses too. As was mentioned in that GitHub issue, we can just rely on safeguards to keep players from mistakenly losing more progress than was intended.

Also, if players want a context-aware command for loading the current saveloc, there still needs to be a command that goes back to the last resettable location and doesn't load a saveloc. I guess the context that would make a sm_tp-like command load a saveloc is if the player is in practice mode right? Since the player might actually want to go back to the beginning of the stage even in practice mode, there needs to be a way to explicitly do that. We could have one command that always goes back one location, and another that contextually either goes back one location or loads the current saveloc. It's kind of hard to name these commands, so sticking with mom_restart_stage and mom_tp/mom_back might not be a bad idea, especially since those names are familiar.

Paddy

Ark_ I agree with having a generalized bind for resetting the current zone (stage, map, bonus). I don't know why you're including savelocs in this, I use savelocs for PRACTICE ONLY and the saveloc command takes into account the time you made it. It is an entirely seperate system that works well. Keep stage resetting and savelocs apart. You would never teleport using a saveloc command in a run because the game simply doesn't allow it.

Ark_

Paddy That's exactly my point, using a saveloc and resetting during a run are two entirely separate contexts but are actually the same action. I hate using on screen menus like with savelocs and bind every command directly that i can, I currently have a whole dedicated saveloc config setup that swaps out my normal stage reset for saveloc reset. I think this is a very reasonable setup and think that other people would also find it to be so as well.

fingerprince

Yeah I don't see how savelocs are relevant, there is a question of safeguarding savelocs being pressed (currently you can use a saveloc mid run I believe but there's a safeguard for it) but that's another question.

To address the arguments in your Github comment Ark:

First point, "why would someone want two binds that do the same thing" - in your second point you acknowledge (???) reasons why someone might want this: it's possible for people to have their restart map bind on a less commonly used part of their keyboard, or they just use a chat bind (personally I can see myself doing the former)
Second point, "you don't want a bind that resets linears" - I don't know where you're getting this from, the problem that is proposal is trying to solve isn't about avoiding resetting linears, that's what safeguards are for. I think you're complicating the discussing here by bringing up safeguard stuff that isn't relevant. The reasons this is being proposed is to not have two keys doing similar things on the same part of your keyboard, to have a bind that will do the common kind of reset on each map type on the same key (reset map on linear, reset stage on staged).
The third point, the hybrid bind would act the same as the linear bind on a linear map, right? Obviously you don't want it to have the staged safeguard. I'm really confused by this frankly, we're not proposing to add a whole new set of safeguard options for this bind, just have it perform the linear safeguard when it's going to reset a linear, and staged if it's going to reset a stage. The only complication is first stage of a staged map, yeah, probably fine to apply the staged safeguard in that case?

So yeah I don't think any of your arguments against the request in hex's issue hold up at all and we should go ahead with hex's proposal.

Ark_

fingerprince First point, "why would someone want two binds that do the same thing" - in your second point you acknowledge (???) reasons why someone might want this: it's possible for people to have their restart map bind on a less commonly used part of their keyboard, or they just use a chat bind (personally I can see myself doing the former)

When you have both bound, you tend to use the stage reset a lot and map reset almost never when going for completions, and the map reset a lot and stage reset almost never when going for runs. This means that people tend to put the stage reset in an easy to reach place, and map in a harder to reach place, and this makes accidentally resetting on linears more likely. Safeguards do help with this, so this isn't as big a problem as it is in other games, but not entirely moot.

Second point, "you don't want a bind that resets linears" - I don't know where you're getting this from, the problem that is proposal is trying to solve isn't about avoiding resetting linears, that's what safeguards are for.
I think you're complicating the discussing here by bringing up safeguard stuff that isn't relevant. The reasons this is being proposed is to not have two keys doing similar things on the same part of your keyboard, to have a bind that will do the common kind of reset on each map type on the same key (reset map on linear, reset stage on staged).

Stage restart is supposed to restart the stage, stage restart restarting the whole map sometimes is weird and confusing, this is really about people being used to it working that way without really thinking about if it makes sense or not. I think its reasonable to want a button that does work that way, but it shouldn't be called stage restart in that case.

The third point, the hybrid bind would act the same as the linear bind on a linear map, right? Obviously you don't want it to have the staged safeguard. I'm really confused by this frankly, we're not proposing to add a whole new set of safeguard options for this bind, just have it perform the linear safeguard when it's going to reset a linear, and staged if it's going to reset a stage. The only complication is first stage of a staged map, yeah, probably fine to apply the staged safeguard in that case?

We need to change how safeguards work for this to be true, right now we are applying safeguards depending on the command itself, and not on the action, and I don't think this change has been proposed anywhere, at least not publicly. It might be a totally reasonable change to make, but I do think it ends up with more edge cases that you have to explicitly handle than the current solution of just not having it do things.

fingerprince

Yeah safeguards would need to be changed so they do have the linear behaviour if the staged bind is used on a linear map, that's definitely something for us to keep in mind if we make the change.

wrt them being confusing - it's how it's worked on some servers before and I doubt it's going to leave people completely flabbergasted. Plus hex's idea of showing a Panorama prompt should make it clear to people