Guild Wars 2

ChyrosNX.1834:

/*
 * MAGIC! DO NOT TOUCH!
 */
void cameraAttackInteractSoSmartYouWontTouchItFunction (...) {
   // insert super complex code here that nobody wants to touch it
}

_______________+88
_______________+880
_______________++880
_______________++880
________________+880
________________+8880
________________++880
________________++888_____+++88
________________++8888__+++8880++88
________________+++8888+++8880++8888
_________________++888++8888+++888888++8888
_________________++88++8888++8888888++888888
_________________++++++888888888888888888_+88
__________________++++++88888888888888888_++8
__________________++++++++000888888888888+88
___________________+++++++000088888888888_88
____________________+++++++00088888888888
_____________________+++++++088888888888
_____________________+++++++088888888888
______________________+++++++8888888888
______________________+++++++0088888888
______________________++++++0088888888
______________________++++++00888888


I just had to touch it.

Evan Lesh.3295:

The problem could also be solved by completely separating the different functionality of selection, auto-attacking, and camera movement. However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change.

Get to it. We’ve been complaining about this from day one.

Evan Lesh.3295:

My post wasn’t meant to be negative, but to shed more light on an issue that isn’t as simple as it appears. We anticipated an increase in usability problems from other game features which is why we’ve already begun to address the problem. The current implementation will see revisions.

Ah, I see. It appeared as if it wasn’t completely certain the issue would be addressed yet, if at all. I’m just happy so see someone actually cares and is putting his time and effort into fixing this, instead of leaving us in silence for another 6 months.

Kraag Deadsoul.2789:

Evan Lesh.3295:

Disabling right-click to attack/interact is certainly the safest first approach to this issue. There are two problems, though. Anytime you have camera-look and targeting on the same input, you will have conflicting behavior.

Solution = Do NOT bind two behaviors to the same input. At least not by default. If the end user chooses to bind their keys or mouse buttons that way, that’s their choice (though I can’t imagine why anyone would voluntarily choose to do so in this instance).

Would you program it so the H key opens both the player’s hero panel AND their inventory at the same time? Of course not! That would be ridiculous, right? Maybe now you begin to see just how ridiculous it is to bind camera movement AND target selection to the right mouse button.

Evan Lesh.3295:

There isn’t a bug that targets are randomly selected, but rather the game trying to be smart at recognizing clicks versus camera movement.

Solution = Do NOT bind two behaviors to the same input. Then the game doesn’t have to be “smart” about differentiating one from the other (which it’s failing miserably at, by the way).

Evan Lesh.3295:

Even when you think you’re perfectly clicking on a target, most of the time you’re also moving the camera a tiny, tiny bit.

This statement demonstrates the devs gross misunderstanding of the problem. We’re NOT trying to use the right mouse button to click targets; we’re trying to use the right mouse button to move the camera. The fact that it selects targets – to our great frustration and disappointment – is due to someone somewhere inside ArenaNet thinking it would be a good idea to bind two behaviors to the same input.

Solution = Do NOT bind two behaviors to the same input.

Evan Lesh.3295:

There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’.

Since this statement reinforces the previous one by demonstrating that the devs haven’t a clue what the real issue is, I’ll repeat myself.

We do NOT use the right mouse button to select targets; we want to use it to move the camera and NOTHING ELSE. In light of this, there is no need for thresholds or sitting on it for a while to see if it “feels right”. As long as target selection is bound to the right mouse button, it will always feel wrong no matter how you tweak the thresholds.

Evan Lesh.3295:

The problem could also be solved by completely separating the different functionality of selection, auto-attacking, and camera movement.

Now you’re talkin’. This should have been done from day one. The fact that ArenaNet chose to bind two functions to a single mouse button will be one of the great mysteries which – though it may never be solved – will become a cautionary tale to future game programming students when told by their instructors, “Don’t pull a GW2 by binding two behaviors to a single input!”

Evan Lesh.3295:

However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change.

Thanks for the honesty of this statement. However, we’re not asking that you split them up at this point. We recognize that the work involved to do so is beyond the resources of ArenaNet at present. All we’re asking for is a simple toggle that disables the ability of the right mouse button to select targets.

This post I can only agree with (+1).
Please do not bind two behaviors to the same input. I just want to be able to move my camera, without having to worry about whether or not I mouse over a turret, a friendly player or a critter in the process.

Evan Lesh.3295:

There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’.

That’s good because that’s the real source of the problem. But you have to concede that it feels very, very, very wrong right now. The situation right now is far worse than lowering that threshold too much. You can swing the camera several degrees right now and the game still thinks you’re trying to select something, so the threshold is way too high.

I appreciate that they are looking into the issue and posted a planned response. I think they are on the right track. If they fix the issue properly people that only use their right mouse for turning won’t notice target loss. People who do use it (my self for one) will still be able to benifit from the advantages of right click auto attacking vs left click.

Personally I prefer the right click functionality over the left click functionality for targeting. Right click will change target AND auto attack on a single click. Also, right click won’t drop your target when you click on something that isn’t a target.

Watch the following clip. I tried to explain what causes the bug it and what does not as well as some of the subtle differences between left and right clicking on the targeting system.

I’ve done this exact input before, and if I were to guess, the time delta for the mouse input isn’t being taken into account.

So you shouldn’t just check whether the mouse has moved N pixels, but rather looks for a velocity (along with a time maximum). So N pixels per second.

I’m basing this guess on the fact that not everyone sees this problem, and I’m wagering that they people who see it more often tend to have lower framerates. So you really need to move the mouse fast to get, say, 5 pixels in 0.02 seconds (50 fps), but not so much if you are getting 10fps (0.1 seconds). To put it another way, if you move the mouse at the same speed, since user input is usually polled in games, someone getting 50 fps might move mouse 4 pixels in that time, but the person getting 10 fps would seemingly move it 20 pixels.

Also, the resolution might not be taken into account. You really want to capture movement in degrees, not pixels, to get rid of the resolution of the display as a factor.

That means you really want the unit tested as degrees/second, maybe with a time threshold.

I would say there is definatly a time based evaluation in there, or separate processes and the video motion one processes first before the targeting one can filter the results. You can start a click on a target, hold it, then make a very slight mouse motion and it will not acquire a new target. However, if you make a fast click and large mouse motion it will both switch targets and move the camera.

Downstairs Eddie.8125:

Evan Lesh.3295:

There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’.

That’s good because that’s the real source of the problem. But you have to concede that it feels very, very, very wrong right now. The situation right now is far worse than lowering that threshold too much. You can swing the camera several degrees right now and the game still thinks you’re trying to select something, so the threshold is way too high.

Evan Lesh.3295:

Disabling right-click to attack/interact is certainly the safest first approach to this issue. There are two problems, though. Anytime you have camera-look and targeting on the same input, you will have conflicting behavior. There isn’t a bug that targets are randomly selected, but rather the game trying to be smart at recognizing clicks versus camera movement. Even when you think you’re perfectly clicking on a target, most of the time you’re also moving the camera a tiny, tiny bit. There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’. The problem could also be solved by completely separating the different functionality of selection, auto-attacking, and camera movement. However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it. Thank you again for all the feedback!

The primary goal should be to remove right selection altogether. There is no good reason why GuildWars 2 should be a special snowflake and try to overload the camera movement with selection – an action that for the past decades has been customary done by left clicking.

However, there also appears to be a bug in the way that the input handling code tries to differentiate between clicks and drags. You can see it by executing the following two tests:

1) stand in front of a (green) mob. Move the mouse cursor on top of the mob. Press the mouse button and move slowly left/right/up/down.

Observed behavior: at first the camera does not move and the mob is not selected. At some point the camera starts moving, namely when we cross the click – drag threshold. Releasing the mouse button as long as the camera hasn’t moved yet selects the mob. Releasing the mouse button once the camera has started moving does not select the mob.

All this is as expected.

2) Repeat test (1) but this time move the mouse very fast/flick it.

Observed behavior: there’s a 50% chance that the mob will be selected or not selected after the mouse up. If the mob is selected then the selection has occurred regardless whether the camera has moved or hasn’t moved.

This inconsistent behavior in the differentiation between clicks and drags is the most irritating part about this right-click “feature”.

To be fair, guys, there IS a distinction between the left-click targeting functionality and the right-click targeting functionality. It’s subtle, but I can see why it might be worth keeping…

…but at the bottom line, the best thing to do here is really to let the player decide. We’re given the opportunity to remap every other key in the game - why can’t we have some control over the mouseclick functionality?

Evan, you said that adding an option to disable right-click targeting entirely would be a ‘safe’ option. Then why not do it? Adjusting the behaviour of right-click targeting to make it more functional is still something that can be done after the option to turn it off has been removed, but the measure will significantly improve player experience in the meantime.

On that, player customisation may also be the answer to the question of how sensitive to make the code that distinguishes a right-click-to-target and a right-click-to-adjust-camera. Provide the player with a slider that lets them decide how sensitive to make it. Instead of having to extensively test a variety of sensitivity levels to find the best one-size-fits-all compromise, let each player decide for themself what works for them, whether that’s no right-click targeting, right-click targeting only with zero camera movement, or right-click targeting with small, medium, or large camera adjustments.

Dear Lesh,

I think we are approaching this from the wrong direction,
It seems to me that the players and the designers are not on the same page of the book.

The designers clearly intended for the game to be played with a certain control scheme where the right click targeting is a feature.

Some players using other schemes they are more comfortable with is running into this as a hindrance.

I think it’s easier to reach an agreeable implementation if we the players and the designers explain how we want the control scheme.

For me, my ideal would be mouse bound to stearing our character, w and s for forwards and backwards, a and d for side strafing, holding down right click for rotating the camera without stearing our characters, and left click to select targets and clicking on spells, the skills are also bound to keys like numbers for quick casting.
So for me, all I want from you is a setting to toggle mouse look, and the unintended right click targeting would be resolved for me.

This is just ridiculous. Why has it taken 8 months for this to be even addressed in the first place. Having targeting and camera movements on the same button was a bad move from day one, but knowing of the problem and persistently choosing to ignore it simply doesn’t make sense.

Like everyone is saying. Add a toggle and fix this issue. Stop beating around the bush saying, “Oh, we know this is a problem, so we may think of doing something someday.”

I run into this issue nearly every time I play the game. It pains me that Anet won’t put the resources into fixing this.

Wow, took 8 months for a Dev to finally admit that maybe, just maybe, right mouse targeting is silly, especially when you already have a perfectly good left mouse button doing the exact same function.

Marrt.2498:

Just add a stupid toggle… tweaking timing/mousemovement thresholds… how stubborn are you guys? The same kitten as with the FOV problematic. If it wasn’t for a third party FOV-tool to set my fov to 65(vert) i would have quit long ago.

You will just procrastinate and then say: no, we can’t because: look at all these reasons we imaginated

Don’t you get that this is a PC-game? Look at the Borderlands 2 Option menu:
http://www.youtube.com/watch?v=ak7Sqs_ituU

…the Fugg

Quoted for truth.

Could you pm me a link to the program that allows you to change your FOV? The current FOV gives me headaches/

Evan Lesh.3295:

Disabling right-click to attack/interact is certainly the safest first approach to this issue. There are two problems, though. Anytime you have camera-look and targeting on the same input, you will have conflicting behavior. There isn’t a bug that targets are randomly selected, but rather the game trying to be smart at recognizing clicks versus camera movement. Even when you think you’re perfectly clicking on a target, most of the time you’re also moving the camera a tiny, tiny bit. There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’. The problem could also be solved by completely separating the different functionality of selection, auto-attacking, and camera movement. However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it. Thank you again for all the feedback!

We don’t care if the feature is ‘fixed’.

We don’t use the feature.

We don’t want to use the feature.

We won’t use the feature even if ‘fixed’.

We use the other methods of targeting and activation.

We want a toggle to disable the feature, so it stops getting in the way.

No amount of ‘adjusting’ will make it work for everyone, because there’s people that click, really, really, fast and people that move the camera really, really fast, and there’s people that clicks really, really slow, and people that move the camera really, really slow.
When you make the time window for detection of clicks small, those that click slow will move the camera when they want to click, and if you make the window big, those those that move the camera fast will get clicks.
When you get a “feel right” spot, that which is a “feel right” spot for some will be “feels bad” spot for a lot of other people.
You can’t even add some “click speed” slider, as there’s even people that clicks with variable speeds.
And they will not change that behavior, because they have developed that speed in other games in which this not happens, so it comes naturally to them to do that really, really fast, because it works anywhere but in here.
You can’t expect players to get used to this behavior, so you must change the game so this behavior can be avoided.

The only solution is letting people disabling right click targeting altogether, so they can disable a behavior they do not use, do not need, and do not want.

You were able to disable right click altogether, and then enabled it again for PvP.

This means you can disable it in some form.

Just make that a toggle. I can’t imagine – any anyone with the slightest idea of programming should agree with me – what kind of code would allow just disabling it altogether but not adding a toggle to let players choose between disabling right click targeting or not.
If you can make it stop doing something and can make it do something, then you can add a code to choose if that something is done or not.

Honestly ..Why we are stile talking about this is beyond my mind….

Options

[x] Disable right click targeting

This is very hard to do………

Evan Lesh.3295:

However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it.

It’s okay, everyone. While they’re not “prepared” to work on something extremely useful that was actually requested by tons of people, they are most definitely prepared to work on mounds of useless crap such as cute little Animal Hats or Burning Oil Mastery (that no one asked for).

Hooray for not listening to feedback from your player base!! Arrowcarts for everyone!

skinnyb.5920:

Evan Lesh.3295:

However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it.

It’s okay, everyone. While they’re not “prepared” to work on something extremely useful that was actually requested by tons of people, they are most definitely prepared to work on mounds of useless crap such as cute little Animal Hats or Burning Oil Mastery (that no one asked for).

Hooray!

See, although I agree with you that this issue should be addressed, and Anet has some pretty bad PR (in fact, one of the worst I’ve ever seen in a game company), your argument is pretty dumb since the people that work on fixing things like right-click targetting are not the people that design Animal Hats and the likes.

I do however feel left in the cold about the fact that their bug-fixing department is focusing on fixing non-issue exploits like the one in the Dredge fractal, but completely ignore actually game breaking bugs like party bugs, NPCs not respawning in the Ascalon fractal, NPCs running off into random groups, effectively getting themselves killed, etc. Not to mention the fact that half of the time, their exploit ‘fixes’ were obviously never tested by anyone beforehand, since they are usually all easily circumvented, which means they wasted time fixing stuff that didn’t need fixing, that could have been spent actually fixing game-breaking stuff.

Their priorities are completely misplaced in my opinion.

ChyrosNX.1834:

• MAGIC! DO NOT TOUCH!

I get the reference. Nicely done.

Evan Lesh.3295:

Disabling right-click to attack/interact is certainly the safest first approach to this issue. … However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it. Thank you again for all the feedback!

I think what he means is, “This could take anywhere from 5 minutes to 6 hours to code, and another 3 months or so to troubleshoot with the QA team. Before we decide to commit to a 3-month project, we have to hold a meeting or three so we can debate whether or not it’s worth the time and effort, try to think of a better way to do it, figure out which is our best option, etc.”

It seems simple to us, and it may very well be simple. But maybe it isn’t. Maybe this “smart camera” is so inextricably entwined with the UI coding thakittens removal would break the game in a literal sense. Maybe giving the option to “disable right click targeting” would actually disable all click targeting. Since the main difference between the right and left clicks seems to be the “execute default action” function (autoattack, F-key, etc.) and the main difference between the two click-and-drag cameras appears to be character rotation, maybe the hotly-debated target selection functionality is tied together for both mouse buttons. Perhaps disabling the one would disable the other. I clearly don’t know what happened with the sPvP bug codewise, and I didn’t even encounter it myself, but maybe it’s not so closely related as you would think.

Still, I agree that the “smart camera” was better in theory than in practice. Windows Vista has received enough criticism by now, so I’ll avoid that analogy…
Instead, it’s like trying to teach your 6-year-old to cook his own meals. If it works, maybe it could save you some hassle. If it doesn’t, you’ve got a big problem on your hands.
It’s probably best not to complicate things unnecessarily. Everyone here (as of this post) seems to agree that these functionalities should never have been bound to the same input. I can only assume it wasn’t a programmer who came up with (and approved) the idea, and the current implementation was written by someone who was just trying to impress the boss by tackling a complicated task. I don’t know why or how it originated, but it should be clear by now that this isn’t the shiny feature that it was intended to be. Instead, it’s like early implementations of User Account Controls— annoying to the user and not a real obstacle to a malware writer. We’re just asking for an option to disable it… Blast, I did it anyway! Sorry, Vista.

Korval.2197:

The primary goal should be to remove right selection altogether. There is no good reason why GuildWars 2 should be a special snowflake and try to overload the camera movement with selection – an action that for the past decades has been customary done by left clicking.

However, there also appears to be a bug in the way that the input handling code tries to differentiate between clicks and drags. You can see it by executing the following two tests:

1) stand in front of a (green) mob. Move the mouse cursor on top of the mob. Press the mouse button and move slowly left/right/up/down.

Observed behavior: at first the camera does not move and the mob is not selected. At some point the camera starts moving, namely when we cross the click – drag threshold. Releasing the mouse button as long as the camera hasn’t moved yet selects the mob. Releasing the mouse button once the camera has started moving does not select the mob.

All this is as expected.

2) Repeat test (1) but this time move the mouse very fast/flick it.

Observed behavior: there’s a 50% chance that the mob will be selected or not selected after the mouse up. If the mob is selected then the selection has occurred regardless whether the camera has moved or hasn’t moved.

This inconsistent behavior in the differentiation between clicks and drags is the most irritating part about this right-click “feature”.

Perfect example of why it’s not always a good idea to complicate things in order to make them “do more.” The more complicated the feature, the more bugs it will have. (That’s probably a quote from a textbook somewhere…)

TL;DR: When you have the big meetings in which you discuss this issue, please brainstorm some ways to “completely split” those functions, as we all seem to think it would be worthwhile. We would rejoice with much rejoicing and… um… rejoiciation.

Despite the dev posts, I fail to see why this is such a big issue to change. Then again, maybe I’m just lacking the programming knowledge.

However, as a “gamer” (or, to avoid negative connotations, someone who is currently playing GW2), I can say this: Why do I need to select AND begin attacking an enemy simultaneously using right click? It might just be my playstyle, but most of my encounters start off using a skill that isn’t auto-attack anyway (meaning, I select my target using LEFT mouse-button or TAB and then attack). And if not, I can still press 1 on my keyboard.

Am I fundamentally misunderstanding something here? Because I’m starting to think I am.

Evan Lesh.3295:

There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’. The problem could also be solved by completely separating the different functionality of selection, auto-attacking, and camera movement. However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it. Thank you again for all the feedback!

Since separating the functionality appears non-trivial, can you instead implement slider in settings for that threshold and just give the players choice and control over it? I can almost guarantee you’ll get a much happier player base that way.

I know I for one would set the slider to the extreme so that it never used right-click to target, and would be completely happy, but it sounds like there’s some use for right-click targeting in sPvP?

Just implement a way to give us the choice, even if it feels to you like a kluge. At this point I promise we won’t care, just want this issue crossed off our list of pain points by any means necessary.

kurtosis.9526:

Since separating the functionality appears non-trivial, can you instead implement slider in settings for that threshold and just give the players choice and control over it? I can almost guarantee you’ll get a much happier player base that way.

I know I for one would set the slider to the extreme so that it never used right-click to target, and would be completely happy, but it sounds like there’s some use for right-click targeting in sPvP?

Just implement a way to give us the choice, even if it feels to you like a kluge. At this point I promise we won’t care, just want this issue crossed off our list of pain points by any means necessary.

I think this is a very reasonable compromise if indeed they can code it so the slider – when placed at an extreme end – turns OFF right-click targeting. I don’t care how they achieve it, just make it so this “feature” can be turned off somehow. All I want the right mouse button to do is turn my character when I press and hold it down; nothing else.

Not that it makes any difference to this discussion, but out of curiosity I’d really like to know what thought process went into making the decision to bind these two behaviors to a single input. Not to then criticize, but simply to know for the sake of knowing. It’s just such a mystery.

The only thing I can think of that isn’t related to a technical issue is they wanted to make combat more dynamic, more visceral, more realistic. So maybe the thought process was something like this:

If a player uses the right-mouse button to turn their character, they may no longer be facing their original target. To reinforce the fact that the player has potentially lost their target from view, we’ll code it so the right mouse button also performs target selection. This way, anytime a player rotates away from their intended target, they risk selecting a new target that the mouse cursor comes to rest on at the end of their character’s rotation.

As ridiculous as that sounds, I for the life-of-me can’t think of any other rationale reason for binding these two behaviors to a single input. Oh, wait, one more does come to mind. Maybe someone inside ArenaNet thought they may port GW2 to console someday.

Given the fewer input options available on a gamepad as compared to a mouse and keyboard, they sought to combine behaviors into a smaller number of inputs in anticipation of a console version of GW2. Because such a port would be a closely guarded secret, we’ll never have confirmation nor denial of this conspiracy theory, of course. Still, it makes one wonder. Even if correct, that’s still no reason to continue combining character turn and target selection on the PC.

Or maybe it’s just as simple as they ran out of time and didn’t have the opportunity prior to release to assign these two behaviors to discreet inputs.

Back on topic, please come up with a solution that gives players the option to turn off right-click target selection. Thank you.

Bright.9160:

the people that work on fixing things like right-click targetting are not the people that design Animal Hats and the likes.

I just find this to be an extremely poor counter argument. Those people working on the useless stuff can very easily be reallocated to more useful projects.

Put Animal Hats and Karka Queens on hold. Stop with the new stuff and go back and polish existing content. What happened to the “massive” dungeon revamp that only managed to graze Ascalonian Catacombs? What about a functioning guild panel? A LFG tool? 10 months in and this game still has massive holes.

From Evan’s responses Arena Net seems to consider this a minor, low priority issue. IT IS NOT. It is currently the most disruptive, CONSTANTLY annoying aspect of game play for me and my wife (both Rangers). She has stopped playing altogether. Your recent changes have actually made it worse for me, although I don’t know why except that now I end up getting pulled off target and targeting friendlies as well as enemies far away sometimes. It’s ridiculous

The problem isn’t only losing your current target, it’s that you start attacking your “new” one. I can’t count how many times I started attacking a random doe or some destructible environmental object just because I adjusted my camera.

I would have thought the devs would be more aware of the importance of avoiding this, since timely targeting/pulling was one of the cornerstones of GW1 PVE.

Kraag Deadsoul.2789:

Not that it makes any difference to this discussion, but out of curiosity I’d really like to know what thought process went into making the decision to bind these two behaviors to a single input. Not to then criticize, but simply to know for the sake of knowing. It’s just such a mystery.

Yeah this would be great to hear Evan, might go some way to making people less annoyed/impatient about this issue if there was an explanation of how we ended up at this point. The small functional distinction (target vs target+default action) doesn’t really seem like much of a feature, or something worth the amount of extra hassle this creates.

skinnyb.5920:

Bright.9160:

the people that work on fixing things like right-click targetting are not the people that design Animal Hats and the likes.

I just find this to be an extremely poor counter argument. Those people working on the useless stuff can very easily be reallocated to more useful projects.

Put Animal Hats and Karka Queens on hold. Stop with the new stuff and go back and polish existing content. What happened to the “massive” dungeon revamp that only managed to graze Ascalonian Catacombs? What about a functioning guild panel? A LFG tool? 10 months in and this game still has massive holes.

Yes have the surgeons go flip the burgers, swap the burger flippers with surgeons. But don’t stop there, grab the guy who maintains air traffic control and swap him with a NYC taxi driver… Game may have holes, but so does your understanding of how programming and teams work.

Geotherma.2395:

skinnyb.5920:

Bright.9160:

the people that work on fixing things like right-click targetting are not the people that design Animal Hats and the likes.

I just find this to be an extremely poor counter argument. Those people working on the useless stuff can very easily be reallocated to more useful projects.

Put Animal Hats and Karka Queens on hold. Stop with the new stuff and go back and polish existing content. What happened to the “massive” dungeon revamp that only managed to graze Ascalonian Catacombs? What about a functioning guild panel? A LFG tool? 10 months in and this game still has massive holes.

Yes have the surgeons go flip the burgers, swap the burger flippers with surgeons. But don’t stop there, grab the guy who maintains air traffic control and swap him with a NYC taxi driver… Game may have holes, but so does your understanding of how programming and teams work.

So between the artists and the programmers, which would you say are the ‘burger flippers’?

+1 for toggle option.

Evan Lesh.3295:

Anytime you have camera-look and targeting on the same input, you will have conflicting behavior.

Glad to see we all agree on that point.

So the obvious move would be to fix the problem by not having both options on the same input…wouldn’t it?

…

Ace.1726:

Could you pm me a link to the program that allows you to change your FOV? The current FOV gives me headaches/

Why PM? share the fun:

http://www.wsgf.org/forums/viewtopic.php?f=63&t=24764&sid=484674e6e9e63f561fff8ed926fd3142

i use version 1.0 because it still works without a problem

@Evan,
this is a bug. I’ll tell you what it is, and I’ll tell you how to fix it.

If my post solves the bug, would ArenaNet please consider rewarding my account with 5 Total Makeover Kits as a “thank you”? Because it’s pretty disgusting that your players need to do your job for you, don’t you think? Give me a little reward for doing your job, please

Right now, when a player presses the mouse button, the game asks:

• did the player release the button? If so, that’s a click.
• did the player drag the mouse? If so, that’s a camera drag.

But the game doesn’t know what to do when the player didn’t release the button and *didn’t drag the mouse either.

Your algorithm is missing a condition check for what to do when neither of those two things happen after presing the mouse button. Because of that, the game doesn’t know what to do except wait.

But a click isn’t something that should take 5 minutes between press and release, a click is something that’s released immediately after a press.
So the only choice the game should make in this situation is “the player wants camera control, he doesn’t want to select a target; go into camera mode”.
.
.

When I press the button down and don’t release it, it’s because I want to get my mouse ready to drag when I need it to. IF I wanted to click, I would have released the mouse button immediately. I wouldn’t have held the mouse button down!

Check this video I made earlier

As you watch the video, look at the target bar at the top of the screen, and look when something is clicked. In this video I use blue ping for left click, and purple ping for right click. I hold down the right click after I press it, and release it after a few seconds.
.

So, I select a rabbit with a single left click. Let’s pretend this rabbit is a Champion rabbit boss I’m fighting, or a low-health target I want to kill when Downed so I can rally.
Let’s pretend that Grawl is just a NPC walking around. Or a turret. Or a ranger pet. Or a mesmer clone. Something I don’t want to attack.
.

Then let’s pretend I want to hold down the right button in case I decide I need to rotate the camera. Now my mouse button is held down.
Without thinking about it, it so happened that when I pressed the button down, there was a Grawl under the pointer. Not something you notice when the screen is cluttered with a thousand skill particle effects and tons of players/turrets/minions in the screen. In fact it would be pretty impossible for the pointer not to be on anything, when the screen is so full of clutter
Anyway, no big deal, right? The Grawl doesn’t get selected when you press the mouse down anyway, right? So I’m still fighting my champion rabbit, or my low-health target I want to kill to rally.
Everything’s great so far!
.

I pretend to kite around, dodge, kite around, dodge again… as I would in a fight.
Then after a few seconds let’s pretend I release the mouse button because I realized I don’t need to turn the camera, or I want to turn the camera with the pointer starting from a different place in the screen.
So I release the mouse button.
The Grawl gets selected when I release the mouse button and my character starts attacking him!, even though the Grawl is now at the other side of the screen, not under my mouse pointer!

If the rabbit were a low-health enemy I’m trying to kill so I can rally, and the game makes me accidentally target a NPC when I’m fighting, I’m going to DIE, because I’m wasting my skills on a NPC instead of the enemy!
.

And this happens nearly every time I fight, and also nearly every time I get downed.
Don’t you see how game breaking this bug is?

Also check these two videos:
https://www.facebook.com/photo.php?v=107880442755454&set=vb.100006004953348&type=3
https://www.facebook.com/photo.php?v=107845376092294&set=vb.100006004953348&type=3

Edit (June 2):

Even if the player pressed down the mouse in a area where there wasn’t anything, if when the player releases it, it will target whatever is there on button release!

Added another video to illustrate this. Please watch this video and read the comments I included on that page.
https://www.facebook.com/photo.php?v=109344942609004&l=2226879100695707837

( Edit, after having more information: )

You need to remove the pixel threshold, and start counting the time threshold as soon as the mouse button is pressed. If the players doesn’t release the house button before the threshold limit, the mouse will go into camera mode even if the house wasn’t dragged at all.

Here’s a temporary workaround that might be useful. Why not add support for targeting outside the party, or adding some sort of personal targeting, that way you can always switch back to your target if you lose it.

Evan Lesh.3295:

My post wasn’t meant to be negative, but to shed more light on an issue that isn’t as simple as it appears. We anticipated an increase in usability problems from other game features which is why we’ve already begun to address the problem. The current implementation will see revisions.

Evan, first let me thank you for all the time you have taken to respond to our concerns, and for explaining things in great detail for all of us following along in this thread.

Since you are working with the camera/targeting issue, and I feel that this particular issue causes some frustration, I’d like to discuss another similar topic which causes an almost equal amount of frustration.

Let me ask you….
How often do you find yourself pushing ‘F’ To loot bodies and end up accidentally striking up conversation with a nearby npc, rezzing a dead body, or interacting with an object unintentionally?

If the fix for camera rotation is complicated because you do not want to separate the right click functionality into separate binds, how complicated would it be to allow players to bind different keys to the ‘Interact’ and ‘Loot’ functions?

They did mention a function was gonig to be implemented, to stop you chatting to the idiotic/annoying npcs nearby, whilst in combat.
It was mentioned because of dungeons, but it should be game wide.

This was said months ago though…..

<twiddles claws>

Mr. Lesh has in no way, shape or form explained things in detail. He refuses to answer the most fundamental question regarding this issue. Why is a toggle to completely disable right-click targeting for those who choose to do so not a viable option? We’ve heard nothing but double-speak from Mr. Lesh. Adjusting sensitivity until it “feels right” is more double-speak, likely a delay tactic, and an incomplete solution to the problem.

I, and twelve friends in game, have vowed never to buy a single gem again until an option toggle to completely disable right-click targeting is implemented, assuming we all continue to play. Of course, NCsoft/Anet already has our money, so I suspect whether or not we play is of little concern to them. Regardless, this inexplicable resistance to resolving a problem that should have disappeared over the beta weekends will ultimately erode the player base.

I have discouraged several people from purchasing the game and will continue to do so until an option toggle to completely disable right-click targeting is implemented.

I purchased the game for three family members. Two have stopped playing over this issue. My time is my own, but I am embarrassed that two members of my family now feel they wasted their time playing a game with such a glaring design flaw.

This glaring design flaw can only be corrected by implementing an option toggle to completely disable right-click targeting.

Dexlmentia.7391:

Mr. Lesh has in no way, shape or form explained things in detail. He refuses to answer the most fundamental question regarding this issue. Why is a toggle to completely disable right-click targeting for those who choose to do so not a viable option? We’ve heard nothing but double-speak from Mr. Lesh. Adjusting sensitivity until it “feels right” is more double-speak, likely a delay tactic, and an incomplete solution to the problem.

I, and twelve friends in game, have vowed never to buy a single gem again until an option toggle to completely disable right-click targeting is implemented, assuming we all continue to play. Of course, NCsoft/Anet already has our money, so I suspect whether or not we play is of little concern to them. Regardless, this inexplicable resistance to resolving a problem that should have disappeared over the beta weekends will ultimately erode the player base.

I have discouraged several people from purchasing the game and will continue to do so until an option toggle to completely disable right-click targeting is implemented.

I purchased the game for three family members. Two have stopped playing over this issue. My time is my own, but I am embarrassed that two members of my family now feel they wasted their time playing a game with such a glaring design flaw.

This glaring design flaw can only be corrected by implementing an option toggle to completely disable right-click targeting.

12 friends. Dude, the alliance that came to GW2 with me was roughly 600 people. Of those, only 5 still play. A large segment (over 200, at least) left explicitly because the targeting controls are so bad.

In the microcosm of people I know, that’s a massive chunk. Lord only knows how many people game wide have made the same decision.

If it is actually not possible for them to simply add an option to disable right-click targeting, then I’m really curious what their engine’s code looks like. It must be a complete mess.

Dexlmentia,
With the way I described the bug, there is absolutely no way Anet could beat around the bush anymore, I even told them how to fix it. Someone would have to not have a brain not to see that the bug I described is a bug and it exists.

I’m fondly awaiting my 5 total makeover kits! Can’t wait! Hurry up Anet, I want to change my engineer’s appearance!

It’s a complete joke, even in the last wvw video anet streamed you can see the dev is not even bothering targeting and just randomly attack. A pvp game using targeting without a decent targeting system ??? This makes the game feels like it’s still in beta…
It’s sad to see a dev trying to explain why and how their choice to do nothing is better than simply giving people more configuration options…

Kraag Deadsoul.2789:

Would you program it so the H key opens both the player’s hero panel AND their inventory at the same time? Of course not! That would be ridiculous, right?

Eh, uh… (embarrassed squirming) … well, not really. First thing I did was program a mouse key to toggle both my Hero Panel and my Inventory simultaneously because I was used to having all that info on the screen at once in GW1. But at least it was under my control to do if I wanted to. We aren’t given a choice on how we target; one of the most important functions of the game.

OPTIONS! Everyone is different. Give us the OPTION to disable right-click targeting. That’s all we are asking. Then the devs can continue using it and the players can turn it off.

Evan Lesh.3295:

Disabling right-click to attack/interact is certainly the safest first approach to this issue. There are two problems, though. Anytime you have camera-look and targeting on the same input, you will have conflicting behavior. There isn’t a bug that targets are randomly selected, but rather the game trying to be smart at recognizing clicks versus camera movement. Even when you think you’re perfectly clicking on a target, most of the time you’re also moving the camera a tiny, tiny bit. There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’. The problem could also be solved by completely separating the different functionality of selection, auto-attacking, and camera movement. However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it. Thank you again for all the feedback!

First of all, thank you for this message. I think most of us can understand that with the current code there is a threshold that determines if a tiny movement is intended to be camera movement or a selection. Instead of trying to determine what this value should be, I would suggest giving us a slider to tweak this because there is no way you can figure out what value ‘feels right’ for everyone, just like there is no way you figure out what mouse speed will work for everyone. You might also let the slider go all the way to zero which would effectively turn off selection and be camera movement only. I honestly think this would be the most elegant approach with the least amount of code change that everyone can adjust to the way they like.

Ripple.8597:

Evan Lesh.3295:

Disabling right-click to attack/interact is certainly the safest first approach to this issue. There are two problems, though. Anytime you have camera-look and targeting on the same input, you will have conflicting behavior. There isn’t a bug that targets are randomly selected, but rather the game trying to be smart at recognizing clicks versus camera movement. Even when you think you’re perfectly clicking on a target, most of the time you’re also moving the camera a tiny, tiny bit. There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’. The problem could also be solved by completely separating the different functionality of selection, auto-attacking, and camera movement. However, completely splitting those is not something we’re prepared to work on at the moment as it is a much broader-reaching change. I hope this helps clear up what’s happening and what steps we’ll take to change it. Thank you again for all the feedback!

First of all, thank you for this message. I think most of us can understand that with the current code there is a threshold that determines if a tiny movement is intended to be camera movement or a selection. Instead of trying to determine what this value should be, I would suggest giving us a slider to tweak this because there is no way you can figure out what value ‘feels right’ for everyone, just like there is no way you figure out what mouse speed will work for everyone. You might also let the slider go all the way to zero which would effectively turn off selection and be camera movement only. I honestly think this would be the most elegant approach with the least amount of code change that everyone can adjust to the way they like.

Slider. Absolutely. Everyone wins. Please implement as quickly as you jumped on the Consortium Sickle issue. Or is this on the back burner because you can’t figure out how to charge us 800 gems for it? (Sorry. Is my frustration showing?)

This is a bug, not a slider/threshold issue. Watch the videos I linked
It affects both mouse buttons and it affects anything that can be targeted.

Regardless of how long the button is pressed down and regardless of how much the camera moves, so long as the pointer location is the same at button press and at button release, this bug will always, every single time, select the target that was under the pointer at the time of the button press regardless if that target is still under the pointer at button release or not

If your character moves up, down, left, right, turns left, turns right, it doesn’t matter, if you move the character but the pointer was at the same location at button press and release, it will always change target (left click) and auto attack (right click) the target that was under the pointer at the time you pressed down the button, even if it’s no longer there when you release the button.

So all this stuff…

Evan Lesh.3295:
There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’.

That’s good because that’s the real source of the problem. But you have to concede that it feels very, very, very wrong right now. The situation right now is far worse than lowering that threshold too much. You can swing the camera several degrees right now and the game still thinks you’re trying to select something, so the threshold is way too high.

… has no relevance whatsoever to fixing this bug.

Hamfast.8719:

Kraag Deadsoul.2789:

Would you program it so the H key opens both the player’s hero panel AND their inventory at the same time? Of course not! That would be ridiculous, right?

Eh, uh… (embarrassed squirming) … well, not really. First thing I did was program a mouse key to toggle both my Hero Panel and my Inventory simultaneously because I was used to having all that info on the screen at once in GW1. But at least it was under my control to do if I wanted to. We aren’t given a choice on how we target; one of the most important functions of the game.

OPTIONS! Everyone is different. Give us the OPTION to disable right-click targeting. That’s all we are asking. Then the devs can continue using it and the players can turn it off.

Exactly my point. I’m in agreement with you that this should be left to each player’s discretion how they wish to set up their control scheme. At no point should a developer force a scheme onto the players or – if they do – give the players the option to change it in the options panel.

I think what I was trying to illustrate with my example was the concept that the developer shouldn’t tie multiple behaviors to a single input by default or, at the very least, give players the option to disable one of those multiple behaviors so they aren’t both being controlled by the same input (with my preference being to disable targeting with the right mouse button).

lorazcyk.8927:

This is a bug, not a slider/threshold issue. Watch the videos I linked
It affects both mouse buttons and it affects anything that can be targeted.

Regardless of how long the button is pressed down and regardless of how much the camera moves, so long as the pointer location is the same at button press and at button release, this bug will always, every single time, select the target that was under the pointer at the time of the button press regardless if that target is still under the pointer at button release or not

If your character moves up, down, left, right, turns left, turns right, it doesn’t matter, if you move the character but the pointer was at the same location at button press and release, it will always change target (left click) and auto attack (right click) the target that was under the pointer at the time you pressed down the button, even if it’s no longer there when you release the button.

So all this stuff…

Evan Lesh.3295:
There is a small threshold that determines whether your tiny movement should actually be a target selection. Lowering this threshold will reduce the chances of this happening, but is one of those numbers where we need to sit on it for a while to see if it ‘feels right’.

That’s good because that’s the real source of the problem. But you have to concede that it feels very, very, very wrong right now. The situation right now is far worse than lowering that threshold too much. You can swing the camera several degrees right now and the game still thinks you’re trying to select something, so the threshold is way too high.

… has no relevance whatsoever to fixing this bug.

Thank you, lorazcyk, for testing, recording, posting, and describing the problem. On reflection, this describes exactly the behavior I’m experiencing. I use a trackball rather than a mouse. I’m wheeling around, dancing, pirouetteing, rotating, whirling my character like a madman during combat with my mouse sensitivity set very, very high to be able to accomplish rapid turns during a fight. Despite multiple camera rotations and direction changes in combat, I oftentimes inexplicably wind up with a target selected that wasn’t under my mouse cursor or even necessarily in view on the screen on button release.

It appears this issue is even more severe than when first described. In the middle of a frenzied battle against multiple opponents, I just assumed my active targets kept changing because the mouse cursor was hovering over one at the moment I pressed and released the right mouse button.

As your videos demonstrate, this isn’t the case. Target assignment (let’s not call it target selection because the target isn’t actually the active target…yet) occurs at the point when the button is pressed; not when the button is pressed and released. Coupled with character rotation via the right mouse button, this explains why I’m sometimes winding up with targets that aren’t even in my field of view on releasing the right mouse button.

It goes something like this:

1) Press and hold the right mouse button.

2) An enemy other than one that is the current active target is under the mouse cursor at the time of right mouse button click.

3) Continue applying pressure to the right mouse button in order to rapidly rotate the player’s character during combat.

4) The player’s character has rotated away from the enemy that was under the mouse cursor in step #2. This could even be a 180 degree difference such that the enemy is actually behind the character.

5) Player releases pressure on the right mouse button. The enemy the mouse cursor was hovering over in step #2 when the right mouse button was first pressed now becomes the actively selected target on right mouse button release. This happens even when the mouse cursor is no longer hovering over that opponent and is most certainly NOT the target the player wishes to attack!

(continued)

In essence, what is happening is – on right mouse button click – the enemy under the mouse cursor is not immediately selected as the active target but IS being stored in “memory” (likely assigned to a variable). When the right mouse button is released, that enemy is retrieved from “memory” and made the player’s active target regardless of how much time has passed between the right mouse button press and release and regardless of whether or not the mouse cursor is hovering over that enemy on right mouse button release. No wonder there’s so much ghost targeting going on in this game.

This also explains why players who don’t rely too heavily on holding down the right mouse button to rotate their character don’t experience this issue. For those of us who do use the right mouse button for character rotation, this is an even more serious problem than simply selecting a new target that was under the mouse cursor when the right mouse button is released. This, I think, was the assumed undesireable behavior.

It’s now evident that assumption was incorrect and the actual behavior is even more problematic; we’re being assigned targets we may have clicked on a few seconds ago and which may no longer even be in our field of view or beneath the mouse cursor when they become our selected target! In essence, this is favoring game mechanics over the user experience. In other words, with the current right mouse button behavior, the game is saying:

“It doesn’t matter that you – the player – have rotated your character to face another opponent. Because of how our functions are coded in the game, the enemy you clicked on when initiating your character’s rotation is the enemy you will target when that rotation comes to an end; even though that’s not the opponent you wish to attack and even if you already have another enemy selected as your active target.

This will happen no matter how far you have moved the mouse cursor from that enemy or how much time has elapsed between your right mouse button press and release. You will be forced to target and attack the opponent you clicked on X seconds ago / Y degrees ago even though that’s not the target your eyes and brain are focused on in the main game window."

So much for the whole “we want players to focus on what’s going on in the game world” mantra. All the more reason to give us the option to disable this ASAP.

Yes, you explained it way better that I could, Kraag. I have difficulty explaining things.
.

Though I don’t think your “assigns a value to it” is correct, I think it’s more that the game doesn’t recognize the click as a click until the player releases the button, so the game only changes target and attacks it when the button is released.
.

The game is confused, it expects either a mouse click or a mouse drag, but when you press and hold the button without moving it at all (zero pixels), the game doesn’t see that as a drag (because the player didn’t move the mouse) and the game doesn’t see that as a click (because the player didn’t release the button), so it doesn’t know what to do.

So the only choice it has is to wait and see what you’ll do next. If you drag the mouse, then it accepts it as camera movement and doesn’t select a target. But if you don’t drag the mouse, the only choice left is to interpret it as a click once you release the button…. even if that’s 5 minutes later.

What Anet needs to do is tell the game what to do when the mouse is held down, not immediately released and not dragged either. They need to tell it that in that situation it should “wait for a camera drag” because the button is held down. If the player wanted a click, they WOULD have released the button immediately, they wouldn’t hold it down!!

This will remove accidental right-clicks. You either clicked or you didn’t. No need for thresholds.

Anet is making things overly complicated with these “thresholds”, which led to these game-breaking accidental right clicks.

Another example that fits. This player
says:

So today I was in WvW fighting 1v1 with an enemy Guardian in Stonemist Castle, on top of one of the outer walls. Every couple seconds, my target would change to “Fortified Wall” because every time I used mouse controls to move the camera, the game for some reason would think I wanted to target the wall instead of the enemy player. This made it completely 100% impossible for me to fight the Guardian without standing still, which is impossible as I am a mesmer. I literally had to jump off the wall and get out of the fight because 80% of my skills were missing, due to spontaneously targeting the wall instead of the player.

My bet, based on what I found with my videos, is that while he’s fighting, he held down the right mouse button while the cursor was over the keep wall (for those you don’t know, keep walls can be attacked).

He was probably thinking “I need to rotate the camera a lot while I fight, as I strafe, and I turn, and I dodge, as I try to change what I can see, etc”.
It that player is anything like me, he pressed and held the right mouse button down thinking that “sooner or later I’ll need to turn the camera anyway, so I might as well press down the button now”.
.

But in fact, to use the camera for what he needed, that player probably needed to release the mouse button, change where the pointer is, then drag to turn the way he wants.
That’s because if he’s anything like me, he probably uses a different place for his cursor depending on which direction he’s turning the camera to.
Now, we do this sort of stuff without thinking about it, it’s all muscle memory, it’s unconscious. So it’s no wonder that we were confused but couldn’t understand why our targets changed! Specially since it only depends on where the mouse was when you pressed it, not when you released it!
.

What probably happened, is that when he released the button to change where the cursor would be for his next camera drag, that button release finally completed the “click” and it targeted the wall, even if his pointer wasn’t on the wall anymore.
.

It fits. It all fits.

I don’t know if it’s a bug but right now i can’t select targets anymore with either left or right-click only right would have been enough but this is so nice to never lose my target I hope it stay like this.