Niche but important control detail: Right-click camera look and pop-up menus

[SkyeVeran]

So, we all have different ways of using the camera in MMOs, and for most of us this may not be a problem. For me, I like to use RMB almost exclusively. RMB, Forward, Back, and Strafe are my entire movement options; I don't use the keyboard to move the camera at all.

 

Unfortunately, RMB is also the context pop-up menu button, and this function can't be rebound. This wouldn't be a problem, except that the interval for clicking RMB and getting a menu is way too long, and, more importantly, is not interrupted by mouse movement between pressing and releasing the button.

 

This means that moving the camera for a very short period of time using RMB will cause a pop-up menu to appear, if RMB is released while hovering over an entity. This will make your next key press do either: nothing, removing the context menu, or whatever hotkey you've accidentally pressed within the menu. As a Mastermind, I'm constantly setting one pet to Aggressive or Defensive instead of strafing after making a small camera adjustment. It's extremely aggravating to have these constant control hiccups as I'm playing the game.

 

Shortening the interval itself could solve this problem, but probably a much better option is just to make sure that mouse movement interrupts the ability for a context menu to appear after clicking down RMB. I'm hoping that would be an easy adjustment in the code, but god only knows. Possibly an easier fix would be the ability to rebind the context menus to another button. In the meantime, I have to bind camera look to mousewheel click, which is kind of an uncomfy stopgap. Would love to see this fixed!

[JasperStone]

Yes, to this.

But...

I will have to test in the game later.

I use RMB to move the camera... and I don't think I have this issue.

 

[SkyeVeran]

 

9 minutes ago, JasperStone said:

Yes, to this.

But...

I will have to test in the game later.

I use RMB to move the camera... and I don't think I have this issue.

 

It's possible that I'm just making uncommonly small camera movements.

[ninja surprise]

 

I just posted this in another thread: I use right mouse button for all my navigation and looking around. I hate it when my teammates are super close together (like in hallways or caves) and I accidentally send Trade invites because I released the mouse button on top of a teammate 🫣.

 

It's super annoying.

[Fade]

I definitely have this problem too - usually I accidentally set an ally as my map waypoint (W). Luckily setting a map waypoint is not the end of the world, but it is definitely annoying. I think once or twice I may have nearly removed someone from my friends list (R) or global friends list (E). Removing from the global friends list asks for a confirmation, but removing from the character-based friends list doesn't!

 

I think the proposed solutions are good ideas. Another possibility could be that the right click context menu should only come up if you right click on your target, instead of right clicking on any random thing.

 

[Shenanigunner]

22 hours ago, JasperStone said:

I use RMB to move the camera... and I don't think I have this issue.

 

This. I've never had a collision between holding down RBUTTON for free-look, and context menus.

 

At a guess, this is a player issue involving a collision of frequent switching from free-look to pointer, especially while accessing various clicky-points in the UI. If such users can't train themselves away from combining the two actions so closely, there are alternatives to mapping the free-look action.

 

(I've just been reminded/refreshed in that there are players who continually switch between the look modes; I think most, including myself, tend to hold down RBUTTON more or less continuously unless stopped and accessing the UI.)

 

There's another discussion active right now about camera control alternatives. One is to change RBUTTON from a hold button to a toggle for free look. Another is to move it to a key like LSHIFT or LCTRL, although I dislike mapping those as controls.

 

Edited February 26 by Shenanigunner

[SkyeVeran]

 

I got a nice example of the issue here. As far as I'm concerned, these menus should not even be appearing at all. Admittedly in the case of the last one, it appeared due to a static right-click in an attempt to close the previous menu which was photobombed by my bot leaping into frame, but it is hilarious that I managed to unintentionally hit a hotkey to set it to aggressive instead of strafing while specifically trying to show off the menu popups.

 

58 minutes ago, Shenanigunner said:

 

At a guess, this is a player issue involving a collision of frequent switching from free-look to pointer, especially while accessing various clicky-points in the UI.

 

 

Fully understandable that many players don't experience this issue, but in this case "clicky-points in the UI" is actually "any clickable entity in the game" so that specificity doesn't really apply.

Edited February 26 by SkyeVeran

[Shenanigunner]

16 minutes ago, SkyeVeran said:

Fully understandable that many players don't experience this issue, but in this case "clicky-points in the UI" is actually "any clickable entity in the game" so that specificity doesn't really apply.

 

We're talking about slightly different things here. Some of us — what I would hazard are the majority — don't switch between look-around and UI mode as frequently as you're doing. I'm in lookaround mode about 95% of the active play time, and in UI mode pretty much only when stopped and not in combat. So there's very little window for collision of things in the way you're experiencing. Not everything in the window is "clicky"; only the menus and active elements like characters/foes. So it should be possible to keep from mixing the inputs, but I fully understand how it happens.

 

This is, IMVHO, one of the faults with the click-everything playstyle, that of the macro-mania crowd. It's just wearying to me to consider trying to both play, as such, and control everything at the same time, using basically one input device. (Even console games with a controller have a dozen basic inputs and generally don't mix their functions.) This is why I am a champion of binds over macros; it spreads the effort out across two general realms of input and reduces all kinds of conflicts and effort. (And even I use macros... but not for rapid-access, combat functions.)

 

The only good solution, since I wouldn't begin to suggest you change your play style, is to move mouselook to another key or mode. As noted, I know some players prefer it to be a left-hand shift key, and some have taken to making it a toggle as well. Either solution would combine with your playstyle, with a little adaptation time (that is, staying out of big teams and boss fights until the training wheels come off 🙂 ).

 

But as long as your focal point is zipping all over the screen and switching rapidly between look and click, on that one input device... I can't think of another solution. It's not a game or technical fault that can be corrected, per se.

[SkyeVeran]

44 minutes ago, Shenanigunner said:

 

But as long as your focal point is zipping all over the screen and switching rapidly between look and click, on that one input device... I can't think of another solution. It's not a game or technical fault that can be corrected, per se.

 

Super legit points, but I feel that this actually is correctable, as long as the code allows it (which, again, depends largely on what they're working with.) There's a duration between RMB-press and RMB-release which triggers a context menu; simply, during this time, cancel the appearance of a context menu if the camera (or more specifically, the mouse) is moved during this duration. Problem fully solved. You could argue that this is fail-proofing some accidental camera movement while people are trying to right-click entities, but I would expect it to be much more likely that people trying to right-click something are not moving their mouse while doing so.

[Shenanigunner]

7 minutes ago, SkyeVeran said:

 

Super legit points, but I feel that this actually is correctable, as long as the code allows it (which, again, depends largely on what they're working with.) There's a duration between RMB-press and RMB-release which triggers a context menu; simply, during this time, cancel the appearance of a context menu if the camera (or more specifically, the mouse) is moved during this duration. Problem fully solved. You could argue that this is fail-proofing some accidental camera movement while people are trying to right-click entities, but I would expect it to be much more likely that people trying to right-click something are not moving their mouse while doing so.

 

I've no doubt something like that could be corrected.

 

As I've heard, to date, in ~15 years, one (1) report with a "me too" 🙂 ... I'd suggest looking into a few band-aid fixes on your end while you're waiting.

 

It's an old-school play/interface style and I can see how anyone more (recently) used to modern games with a more integrated interface might be catching on these snags.

[SkyeVeran]

Out of curiosity, Shenanigunner, how do you handle targeting teammates? I use binds for mooost things but I still need to click teammates in the team window to heal them.

[Shenanigunner]

That's what the numpad is for. Put your heals and buffs on the 1-8 keys; with shifts, you have four options for each player. No targeting required.

 

Make NUMPAD0 the targeted one, for a backup.

 

That's the basic idea for MM pet buffs etc. but it takes a little more setup since pets aren't inherently numbered in the window.

 

 

/bind NUMPAD1 "unselect$$teamselect 1$$powexec Heal Other"
...
/bind NUMPAD8 "unselect$$teamselect 8$$powexec Heal Other"

...etc,

 

Edited February 26 by Shenanigunner

[SkyeVeran]

Oof, that's next level. I'm not currently willing to put in the effort to learn that system but I am impressed, lol.

[Shenanigunner]

What's to learn? TeamMate 6 in the window is dropping, hit '6.' Repeat.

 

The only "learning" is which buff you put on which shift key, and for the most part, there are only two. AoE heals can go on 9 or 0 or ENTER.

 

All under one hand, a pigeon could do it. 🙂

[JasperStone]

Thank you for posting the video. It helps.

I tested last night with no issues, even with quick press and release.

 

 

[Shenanigunner]

7 minutes ago, JasperStone said:

I tested last night with no issues, even with quick press and release.

 

As noted, I can't remember any prior discussion of this issue. I think — with all due good humor and respect to the OP — that it's a very small dot at the center of a Venn diagram of CamLook | R-Click | PlayStyle | and just perhaps ThatSystem (as in, maybe jittery key debounce in that mouse or mouse driver?)

 

If some tiny adjustment can be made to right-click response time — that is, if there's already a debounce/hysteresis delay in the code — bumping it a little couldn't hurt and might solve this problem for however few users who run into it.

 

Edited February 26 by Shenanigunner