Circle menus are death traps for (new) users

[ghost]

The evolve menu, the armoury menu and the beacon menu will take over input from the mouse and the direction keys. The armoury menu is not that deadly, as it only works at a few places. Accidentally pressing a circle menu key will prevent the user from further movements until closed. These accidents are more common while under pressure. This is why accidentally opening a circle menu will often lead to being killed quickly.

Many regular users do not use these menus, and some are even known to unbind the corresponding keys. This gives them some advantage over new users.

I have not yet added a bot command menu for this reason.

The chat input has the same problem, but this is only remotely related.

[DolceTriade]

tbf, chat makes sense...

But I'm not sure what a good solution to this is.

• Disabling opening menus while in combat would give these players a disadvantage where other people might use binds to buy stuff while being attacked
• We could move the default binds away from the WASD keys to make it less likely to be pressed?
• I don't think changing the code so that you can move and shoot while you buy stuff is a good experience...
• Providing default binds for buying stuff isn't very discoverable by new players and there is no way we can have binds for everything

Of these ideas maybe changing the default key is the best option?

[RedSkyByte]

I think the immediate solution is quite obvious: add additional ways to panic-quit these menus.
My suggestions what should close these overlays:

1. right and/or middle clicking,
2. pressing (panic spamming) Q (default bind),
3. left clicking outside of the wheel,
4. distinct exit position on the wheel as a spoke instead of the hub (and no hub!).

The last one might be counterintuitive, but I use UI and honestly I'm not a big fan of "Cancel" button in the middle; I almost never use it, I'd rather go for Esc on keyboard for quick (and sure) alternative. I think hub undermines usefulness of circle menu as a means of rapid choice when it's most important. For user who in panic tries to push forward with his decision moving mouse across ~5% of the screen to make a sure selection isn't THAT rapid. It's definitely a problem with evolving. Nothing is more unfairly frustrating then evolving from dretch to a goon milliseconds too late. Just having been shot you stand there, big fat mountain of half-dead meat in crosshairs, about to donate credits to opposite team at your own heavy cost.

Which brings me to another issue. Deadliness of this menu is also linked with the fact that it freezes you in place, making game ignore any movement input. I've seen (and played) quite a few FPS'es that have popup UI which allows for movement while locking the view. In these games clicking outside the window closes it and returns you to freeview. Honestly it's a pattern almost as ancient as mouse freeview itself.

[illwieckz]

If I'm right there also has been suggestions about those menus only appearing while the key is pressed, meaning releasing the key would close the menu, one problem with that is that new user may not understand why the menu don't open when they click the key (press with immediate release).

popup UI which allows for movement while locking the view.

This would also fix push-to-wallwalk mode as granger when building, when opening the menu make you fall because you don't anymore press the wallwalk key. The default wallwalk mode is toggled so it doesn't suffer from the menu taking over the input but non-toggled wallalk suffers from it.

[VReaperV]

What if we add a sort of "fade" for the circle menu? So that if you just press it once, you'll see it for like 100ms or whatever.

[illwieckz]

Actually what I want for a toggled menu is that the same key cycles the menus:

Key → Open menu
Key → Open next tab (if exists)
Key → Close menu

I don't get why we need 3 keys to operate the menu.

I agree we must add as much possible options to escape the menus, for example right mouse click, this would be especially useful as builder to escape a misclick.

We may have both behaviour, the toggled single-key clycled menu, and a push-to-use one.

What if we add a sort of "fade" for the circle menu? So that if you just press it once, you'll see it for like 100ms or whatever.

I don't know how easy it would be to implement it, but the idea is not bad.

[RedSkyByte]

What if we add a sort of "fade" for the circle menu? So that if you just press it once, you'll see it for like 100ms or whatever.

I was thinking the exactly same thing. This shouldn't be too hard to do since RmlUi comes with animation support out of the box (though I haven't tested it yet).
Well tuned select-on-release feels soo good and may be as rapid as custom bind. Asking user to learn something that is an objectively better way of doing things is much more reasonable and not as frustrating.

An example of this done right is Mode Switch with Pie Menus for Blender 3D. Pie Menus used to be the default way of selecting one value out of multiple options (for example selecting shading). It has been sidelined since then, but is still available as built-in plugin that you have to enable. Please try it, it's a very polished UX.
What's more they also found another way of solving the very same newbie problem:

• single key press + still mouse brings up the menu freezing it which allows you to use click/numbers to select
• hold key + move mouse selects highlighted on release

Though exact rules when to freeze and when not to should be worked out in case by case. I can tell you for example that repeatedly bringing up menus to buy/sell each peace of equipment is NO FUN.

Key → Open menu
Key → Open next tab (if exists)
Key → Close menu

How about putting these alternative menus as fixed positions on the wheel?
Devil is in the details though, to really work out UX we need prototyping.

[DolceTriade]

I think this is reasonable...

The way we handle "focus" in Unv is that if you have any menus open, the menus have focus:

Unvanquished/src/cgame/rocket/rocketFocusManager.h

Line 67 in 70d7fcd

CG_SetKeyCatcher( rocketInfo.keyCatcher | KEYCATCH_UI );

However, we can add a special attribute to the circle menus to "share" focus if you will. This might be confusing, but its worth a try?

In the hold/release mechanism above, do the menus still hold keyboard/mouse focus?

[slipher]

#2900 enables movement in circle menus other than the armory menu.