[SUG][PLAYER] No space bar for advancing menu screens, please!

[WillLem]

I had no idea how much of a reflex it has become to end a level by holding down the space bar. In the past, not an issue, but now it races through the post and preview screens since they now take space bar as an input to advance.

Perhaps make it Enter rather than Space (i.e. to advance)? There's nothing quite like tapping the space bar to advance the level a few frames quickly so I'd really rather not reassign Hotkeys.

[Simon]

Perhaps make it Enter rather than Space (i.e. to advance)?

That would still bake assumptions about hotkey layouts into the design: That nobody will hit Enter much during play. Ideal would be a solution that works independently from the game keybindings.

The menu should require key tap, not key hold, to advance.

-- Simon

[namida]

Agree with what Simon is saying here - I'd actually consider it a bug that they automatically trigger it. This is easy enough to put into a V12.10.1 update, but not serious enough to justify such an update in and of itself - rather, if the need for one arises anyway, expect a fix for this to be included as part of it.

I will however note that the forward skips are not intended to be used as a pseudo-fast-forward, and that that itself could stop working at any time (instead becoming that the frameskip only responds to tapping). To be clear, I don't specifically intend to block it, but nor is any special effort being made to maintain it. If you find yourself regularly wanting to skip larger amounts of time, it may be worth setting up a custom hotkey that does so.

[Strato Incendus]

Thanks for bringing this up, WillLem! I'm glad I'm not the only one who was irritated by this.

I will however note that the forward skips are not intended to be used as a pseudo-fast-forward, and that that itself could stop working at any time (instead becoming that the frameskip only responds to tapping)

Well, why make that change if all it does is increase wear and tear on people's keyboards?

10 seconds is usually too large of a jump to be used while solving, except for Builders and Platformers, where it fits exactly (but only when done right at the beginning of building / platforming).

Most people will indeed use it to speed up the crowd moving to the exit at the end, i.e. like fast forward. Forcing the players to hit the space bar several times for that purpose just seems like an unnecessary hassle.

[WillLem]

The menu should require key tap, not key hold, to advance.

+1 for this. That would essentially solve the problem no matter what the hotkeys are.

This is easy enough to put into a V12.10.1 update... expect a fix for this to be included as part of it.

Thank you!

I will however note that the forward skips are not intended to be used as a pseudo-fast-forward, and that that itself could stop working at any time (instead becoming that the frameskip only responds to tapping)

Most people will indeed use it to speed up the crowd moving to the exit at the end, i.e. like fast forward. Forcing the players to hit the space bar several times for that purpose just seems like an unnecessary hassle.

+1 for this. If it's already expected (albeit unintendedly so) behaviour, it would be an unnecessary disruption to people's gameflow if it stops working for whatever reason.

Since namida has said that although he wouldn't stop the behaviour, it could break at any time (I'm guessing, unintentionally as part of a fix to another part of the game mechanics), I'd suggest that the ability to hold frameskips for fast-forward become a legitimate use of the feature which is maintained; this is a fairly diluted suggestion at present, since it currently works and there seems to be no intention to stop it from doing so.

EDIT: It may be worth noting that the only time I use the feature in this way is to speed up the end of the level once completed. Elsewhere, I do in fact use the feature as intended: i.e. by tapping to make incremental forward skips. This is evident in my LPs!

[Dullstar]

By this point, I think that the ability to hold a forward skip button for fast forward has been long-standing enough that it should be considered a feature and therefore should be restored if it ever breaks.

While there is a proper fast forward, it's not as fast and actually shows the frames. Thus, I generally use it if I want to speed things along a bit but intend to exert control shortly, whereas I use a skip if I don't care about anything that's expected to happen during the duration of the skip, and might choose to hold down a skip if I'm done issuing commands and want to fast forward to the end of the level. I suppose you could make an explicit hotkey for that, but that has two disadvantages: first, it disrupts existing workflow, and second, when holding the skip button, you can release it to see what's going on if it seems like it's taking longer than expected.

My expected results from holding down space would be as follows:
1) menus should only respond to the button being pressed
2) in game, the skip hotkey should trigger repeatedly when held based on the keyboard repeat rate.

[namida]

My expected results from holding down space would be as follows:
1) menus should only respond to the button being pressed
2) in game, the skip hotkey should trigger repeatedly when held based on the keyboard repeat rate.

As mentioned, I agree 100% re #1 and will correct this in the next update, be it 12.10.1 or 12.11.0.

I do not intend to fix this by breaking #2, but rather, by making the menu screens specifically check for hold vs press. However, I also think that considering this a feature is a bit kludgey - perhaps instead there should be a discussion around whether fast-forward should allow, at least to some extent, frameskipping (which could in turn strengthen the arguments in favor of "faster-forward" - previously more or less shot down on the grounds that regular FF is reaching the limits of most PC's power as it is, but frameskipping would make a HUGE difference here as it's mostly the rendering that caps the speed - or outright customizable speeds).

[WillLem]

However, I also think that considering this a feature is a bit kludgey - perhaps instead there should be a discussion around whether fast-forward should allow, at least to some extent, frameskipping (which could in turn strengthen the arguments in favor of "faster-forward" - previously more or less shot down on the grounds that regular FF is reaching the limits of most PC's power as it is, but frameskipping would make a HUGE difference here as it's mostly the rendering that caps the speed - or outright customizable speeds).

Perhaps it was shot down because it's already possible to make FF as fast as you want by using hold-frameskip as a workaround. What are the reasons for not wishing to keep this as expected behaviour?

[namida]

However, I also think that considering this a feature is a bit kludgey - perhaps instead there should be a discussion around whether fast-forward should allow, at least to some extent, frameskipping (which could in turn strengthen the arguments in favor of "faster-forward" - previously more or less shot down on the grounds that regular FF is reaching the limits of most PC's power as it is, but frameskipping would make a HUGE difference here as it's mostly the rendering that caps the speed - or outright customizable speeds).

Perhaps it was shot down because it's already possible to make FF as fast as you want by using hold-frameskip as a workaround. What are the reasons for not wishing to keep this as expected behaviour?

It's not "I will remove it", just "I'm not guaranteeing it remains working as-is". I have no intent to specifically go out of my way to prevent it working.

[WillLem]

It's not "I will remove it", just "I'm not guaranteeing it remains working as-is". I have no intent to specifically go out of my way to prevent it working.

Sure, I understand that and appreciate that you don't necessarily want to stop it from working. However, you've also said you wouldn't fix it if it breaks, so my question is more "why wouldn't you fix it if it breaks?"

[namida]

It's not "I will remove it", just "I'm not guaranteeing it remains working as-is". I have no intent to specifically go out of my way to prevent it working.

Sure, I understand that and appreciate that you don't necessarily want to stop it from working. However, you've also said you wouldn't fix it if it breaks, so my question is more "why wouldn't you fix it if it breaks?"

It's less about "why not?" and more about "why?". It isn't an official feature per se, so there's no reason for me to actively preserve it. I don't feel it would be right to make it one - "hold a forward time skip key" is very kludgy; if I were going to support an official "super fast forward" I would rather implement it as a proper fast-forward-with-frameskip that works similar to existing fast forward. At the same time, it doesn't cause any serious problems (I would not consider this topic's matter serious), so I have no reason to actively block it either. I'll simply let it do whatever the current code does - and while I don't expect it to break, if it does, it does.

[WillLem]

Cool, thanks for explaining.

Apologies for the mither btw - 12.10 is amazing, and this really is a very minor thing. Just thought it worth mentioning in case it was a bug or could be easily sorted.

[namida]

Cool, thanks for explaining.

Apologies for the mither btw - 12.10 is amazing, and this really is a very minor thing. Just thought it worth mentioning in case it was a bug or could be easily sorted.

That's absolutely fair enough - it never hurts to mention things! And indeed, there is a bug here, it's just not "space bar advances the menu" but rather "menu responds to a key that's held down rather than newly pressed".

[namida]

Respond-to-held-key bug fixed in commits 9c5c4c7 (master branch; ie: 12.11) and d17bfcb (12.10 branch).