Guild Wars 2

lorazcyk.8927:

I’m noticing a lot of players reacting too happily, as if by the next patch they’ll be able to have the right click only do camera control, never targeting.

Please people, don’t get too hyped up.

Looks to me as if the toggle will only let you choose between automatically attacking the new target, or only selecting that target without attacking it. You can choose to have the right click targeting behave the same as left click, or choose to have it attack immediately after you select a target. That’s all.

• I’m not really wanting a response here and I’m not criticizing you, as this could be the case but:

Why would he give us a toggle that would make the right-mouse function the same way as the left-mouse? That is just redundant and completely unnecessary and even more so than what we have now. At least as it stands: right-targeting targets, auto-attacks, and doesn’t deselect a target when clicking on the ground. Why would Evan even think to tell the right mouse button to just select a target? What would be the point of having the same function on two different mouse inputs that we can’t remap? shrug

If the new patch comes out and this is actually the case, I’m never touching GW2 or these forums again. This would just tell of the sheer incompetence of the team and would not be worth giving them detailed suggestions anymore or the constant aggravation with playing the game. I hope that this isn’t the case.

lorazcyk.8927:

I know it’s not a perfect solution, but it’s the lesser of two evils, and it’s much easier to rationalize in the player’s mind than the current behavior we have.

Seriously, just drop your solution. It’s not the direction to take on this issue. I’ve already explained why it sucks and you’ve conceded on a few points already but you just put a band-aid on those problems and in-turn, just created more. To sum them up:

1. Fast flicking will not be possible with your solution. That is a big problem.
2. Fast flicking will now cause the camera to not move at all. That is a bigger problem.
3. The player would have to rotate the camera slower and consciously think about. This takes away preference, instinctive reaction, and is just plain annoying.
4. It will force players into camera-mode when they may have been prolonging their mouse release for a reason because there is no pixel threshold. This takes away preference and control.

These are only 4 problems that I thought of in very little of time. I’m sure I could think of other unwanted consequences that your solution would bring if I thought on it a bit more. Your solution may sound fine by itself, but when you combine it with countless other factors and player preferences in practice, it doesn’t work very well or even at all.

Further, and truly, what is the difference between the consequences of your solution and the current system we have? In both cases, the player still has to be mindful of how they flick the camera. That’s the problem most players are complaining about here. Instead of the brokenness that is the right-mouse targeting, you’ve broken the camera control itself. Players shouldn’t have to be mindful of broken mechanics when flicking the camera.

Just say: “Hey, maybe this isn’t the best way to go about this problem” and call this argument over. You’re preaching a solution that: 1. sucks and 2. is more complicated than just removing right-mouse targeting. If ANet would somehow consider what you are suggesting, then they should ask themselves: “Why? To what overall avail?” Why should they waste their time coding and testing your suggestion if it only breaks something else that is similar in manner?

After all of this, I didn’t even think of a quite simple solution that kind of works for everyone:
1. Add toggle to turn off right-mouse targeting.
2. Fix as much as possible with the current system even if it still causes problems.
3. In key-binds, allow the player to re-map the function of right-mouse targeting to another input when toggled off.

Players would be able toggle off right-mouse targeting and then bind the function (selecting and auto-attacking) to another key. I would choose an unused mouse button that my thumb was readily on or possibly the middle-mouse button. People could still choose not to toggle and play how they have been, but they would be stuck with a broken system that they would just have to deal with.

So, next thread title: “Option to bind right-mouse targeting to another input when toggled off.”

Geotherma.2395:

Evan Lesh.3295:

This is why we’re adding a toggle for it in the next patch.

/end thread

lol

• I don’t even know why I’m quoting you, because I agree. Just ranting:

It may end this thread because that’s what the point of this thread was: request a toggle. Though, it won’t end the discussions of the problems.

It’s the perfect solution to people who don’t want to play with right-mouse targeting.
Though, it’s far from a solution for those who do.

I’m not sure that there even is a perfect solution for those people, as Evan eluded to in his most recent post. ANet can tweak and change code all they want, but I can’t see anything but problems existing and arising with right-mouse targeting.

The only solution that makes absolute sense for everything to function as expected is to remove right-mouse targeting altogether. Though, since a lot of players are used to the right-mouse targeting, this really isn’t an option at this point. So, these kinds of threads will still exist after a toggle is given and even after thresholds are changed.

Evan Lesh.3295:

Got an update for you guys! Thanks to everyone for dissecting the current state of targeting!

The current click timing threshold is 250ms. We are playing with a lower number internally to see if it causes problems like people perceiving clicks as not registering.

I figured it was somewhere between .2 and .3 seconds*. I chose to say .3 seconds because it was the most reliable number when I was checking. *If I am even talking about the same thing you are.

I just want to ask: why is this timing threshold even there after you move the cursor into camera-mode? Without it, it seems like the flicking issue would be gone. The strafing issues would still be there, but it would at be a vast improvement. I’m just not seeing what else it’s used for. It doesn’t seem to be there to prevent camera-mode because that’s what 4 pixel threshold does.

lorazcyk.8927:

Yes, I’m aware of that and was waiting for you to bring it up. In that case, you can decrease the rotation speed so that you won’t flick too fast for it to trigger as a click.

I’m also leaving for the day, see you

*Edited this a bit. It’s hard to explain something like this.
You keep piling junk on top of this solution. Argg. This would make super fast and small flicks still impossible. Regardless of how far the camera would have gone if there was a pixel threshold, it’s not going anywhere at all with a 0 pixel threshold and you flicking faster that .2 seconds. It doesn’t matter what your rotation speed is. That’s a slightly different function that I shouldn’t even need to address here. Though, I will:

This would also require the player to make farther strides and hold the mouse button down longer to get the camera to the desired location. This takes time away from actual combat because you’re working with a slow camera movement speed. It won’t feel natural. Go set your camera rotation speed to the lowest setting. Now, isn’t flicking the camera a pretty darn chore now? I just tried it and it practically takes me about 5 small flicks before the camera turns even 180 degrees. What you’re suggesting may not be as drastic but it still takes control and preference away from the player.

The player would be forced to turn the camera slower than they wanted. Even then, as I explained in the first paragraph, you would still not be able to move the camera 30% of the time if you flicked too fast, regardless of your camera rotation speed.

lorazcyk.8927:

It could also be:

If on button press the game goes immediately into camera mode, but they use a pixel threshold to “cancel” the camera (make it wait), and have it register whatever is under the mouse button as a target on button release.

This would mean they don’t even have code for a click, they only have code for camera, the code tells the game to go into camera mode immediately after press down.
So the only way they could let us click a target is by telling the camera to wait, and select whatever is under the pointer on button release if the pointer didn’t go past the pixel threshold.

If it’s this, then I can see how clicking and moving the camera is tied together :-(
Taking away the threshold would make the mouse go into camera mode instantly, both for left click and right click :-(
That means they don’t want to remove the threshold, because players would no longer be able to target with the left click either.

---

But they used the wrong work around… They used pixel distance traveled threshold, instead of time pressed threshold. They need to:

• Remove pixel threshold
• Add time threshold (if there isn’t one currently) before it will go into camera mode (anything before the threshold will register as a click
• Make the game not select a target if the button was pressed down longer than the " average click" trigger threshold.

Right now anything from zero to four (?) pixels will make the target become selected even if the button was held down a veeeeeeery long time.

But to prevent accidental targeting, I stioill believe a time threshold would be better than a pixel threshold.
Specially if the above is the case… :-(

Before I go, I just want you to understand that there absolutely has to be a pixel threshold for mouse targeting to work decently with camera controls. I will give a specific example this time:
- Let’s say the pixel threshold is 0: Does not exist.
- Let’s say that after mouse-down, there is a timer of .2 seconds that will initiate camera-mode.
- Let’s say that I’m a fast flicker.
- Let’s say that 70% of the time, I flick the camera and let go of the mouse-button .3 seconds or slower.
- Let’s say that 30% of the time, I flick the camera and let go of the mouse-button at around .1 second.

The result: 70% of the time, things will work out fine. The other 30% of the time, the camera will not move at all because the code has no way of knowing that I moved the cursor to initiate camera mode (0 pixel threshold).

Understand now?

Alright, lorazcyk.8927. I’m done with this whole issue. Neither you or me have the code sitting in front of us to look at. There may be bugs or everything may be intentional. There may be other factors we are not seeing or there may not. Your solution may partially-work, work, or it may not. It may create more problems or it may not. People may or may not be able to adapt to it.

We don’t know exactly how this is coded and if any pieces of code are being called (reused), that makes changing things a pain for ANet. There may be a simple solution (removing right-mouse targeting) or there may not be. They may have to resort to something you said but that is just a band-aide fix as well because I guarantee that problems would still arise from such a system of having two functions on the same input.

No one needs to right-mouse target anything. It’s just not necessary for the game to function correctly. Though, some players may have a preference for it. Namely, weird PvP players that boast skill but don’t see the irony of the situation. Just use the skill yourself to initiate combat, like you would have to if you imitated combat with ANY OTHER SKILL.

This is just turning into player preferences and an if, and, maybe, or but situation. I will still PM you when the forum lets me (said I needed to wait because of spamming.)

lorazcyk.8927:

The time threshold will prevent it from going into camera mode right away, as I’ve said.
If you click (press and release the button), it will target.
If you press and hold past the time threshold it will go into camera mode, as it should.

I don’t know how I can explain any different so you understand.
With this, there will be no more accidental targeting but players are still able to target something when they want to.

The game knows EXACTLY what to do because it does EXACTLY what it’s told. It’s not by happenstance that these things occur. The code is absolutely there to prevent the the game from going into camera-mode until the player moves the cursor 4 pixels after mouse-downing.

THAT code is there, yes, but it’s only a bandaid bug “fix’” code that is only a band aid. Yes, Anet put the code to make sure the camera moves after 4 pixels.
That’s a band-aid to the real problem, that their algorithm is missing a THE CODE for what to do when the player doesn’t release the mouse button and doesn’t drag the mouse.

/scratches head

http://www.dcs-media.com/Archive/the-band-aid-mentality-of-fixing-bugs-OU

What you’re saying is that it’s OK to just put a blanket over broken glass instead of sweeping up the broken glass, because someone put a blanket over it, there’s no problem anymore. Of course there is, the broken glass is still there.

---

If Anet had truly intended to do as you say, they wouldn’t have also added a time threshold AFTER the mouse goes into camera mode (if indeed there is a time threshold, as you say), because by their code, if it is as you say, it has already decided to go into camera mode after the player dragged the mouse 4 pixels.

Maybe I’m not explaining it right. There has to be threshold there. What if a player wants to activate the camera mode before your time limit is up? You know, flick the camera super fast? They need to mouse-down and move the cursor past a set threshold for this to happen. This is already in the game. You don’t need to add in some timer. The problem occurs when the .3second delay and right-mouse targeting come in.

EDIT: To clarify. If there was no threshold whatsoever for the player to initiate camera mode manually, then they would always have to wait the allotted time (no matter how long or short that is) before camera mode takes effect. This effectively makes flicking the camera practically impossible.

The more I think about it, the more I am to concede that there may be a bug here. Removing the bug still won’t fix the issue totally. It would only fix the flicking issue and not the strafing issue.

That bug may be: You have to wait .3seconds after you go into camera-mode, before letting go of the mouse button or it will still select the temporary, stored in-memory, target that was acquired on mouse-down (or selected on mouse up if you didn’t acquire a target.)

I thought that there was a reason for this delay to occur and there may as well be a use for it but I’m just not seeing it. Maybe the code just isn’t fast enough to process going from targeting mode to camera on the fly like intended. Maybe it takes the code around .3seconds to actually accomplish this, and this is where the bug occurs.

Even still, the only way to truly fix everything would be to just remove right-mouse targeting.

**Continued. Please read above post first.

lorazcyk.8927:

Yes, I was.

The reason it behaves like that is because they didn’t code it in, that’s WHY it’s a bug. It’s a bug from having overlooked a certain condition check.
It’s the kind of bug you’d expect a first year CS student to make.

There is no bug here. This does not cause any problems by itself, regardless if someone uses this or not. Remove right-mouse targeting, and no one would even know that this exists. It would be pointless to remove this and not change how the stored targeting works when mousing-down on the enemy. Again, that isn’t the main problem either. Changing the way that works would, as I explained in my previous post, make left-targeting harder and less reliable. BOTH left and right mouse buttons behave the same when storing and acquiring a target. Try it, in-game. Flick the camera or strafe while holding down the left-mouse button. The same targeting woes will still occur. Also, notice the pixel threshold is the same to activate left-mouse camera mode too. They act exactly the same.

lorazcyk.8927:

The game doesn’t know what to do when neither of those things happen, because it wasn’t told what to do so it gets stuck, that’s what the bug is, that’s why we are accidentally targeting something when we meant to go into camera mode.

The game knows EXACTLY what to do because it does EXACTLY what it’s told. It’s not by happenstance that these things occur. The code is absolutely there to prevent the the game from going into camera-mode until the player moves the cursor 4 pixels after mouse-downing. That code there is not only the 4 pixel code, but also the stored target code on mouse-down. Both of these, in-conjunction, allow the player to decide. It does not get stuck.

lorazcyk.8927:

Anet needs to tell the game that even if the mouse didn’t move at all, once pressed, the game needs to go into camera mode if the player didn’t release the button after a certain time (average click speed, Anet seems to think it’s 0.3 seconds), and they need to remove the pixel threshold because that stupid band-aid “solution” won’t be necessary after they fix this bug.

I already went over this above. The pixel threshold has to be there, regardless of whether they add in some timer that forces the game into camera-mode. If it wasn’t there, then the game would go instantly into camera mode and not give the player time to right-mouse target anything at all. Thus, that would be the best solution. Go instantly in to camera-mode. That would also mean, no right-mouse targeting. It WOULD NOT be possible to right-mouse target if the threshold were set to 0.

EDIT:
Sum-all: If I were using the right-mouse button to target/auto-attack, I wouldn’t want the game to force me into camera mode at a time that I did not specifically want it to. As it stands now, other than the .3 second delay that (for some reason) occurs when flicking the camera, the game does exactly what I tell it to, but in an odd way. The only way to remove the oddness would be to remove the source of it: right-mouse targeting on the same input as camera movement. The source of that oddness is not the 4 pixel threshold.

lorazcyk.8927:

Third season, I never said the time threshold would be so short that only the fastest clickers would be able to target. It could be long enough to acocmodate ever slower clickers. So long as that slow clicker isn’t keeping the button pressed down on purpose, if he is, he will learn not to.

You don’t seem to understand one thing: The pixel threshold WILL still have to be there if even if they add in some .1, .3, .5. 2, 10, or 20 second forced camera code. We would be in the a different boat but with similar problems because people are flicking faster than .3 seconds. The pixel threshold HAS to be there, so that it DOESN’T instantly go into camera mode and gives time for the player to decide (regardless of how long). The problems only arise when the .3 second delay and the nature of the stored target come in to play. I think you missed my whole bit that I repeated countless times: These things are not problems by themselves. Removing right-clicking from the equation makes none of those things a problem on the right-mouse button.

lorazcyk.8927:

I’m a fast clicker, my husband is a slow clicker, I realize it would have to accommodate his speed. But no one tasks 2 seconds to click, and I doubt anyone keeps the mouse pressed even half a second before releasing the mouse.

I would argue that some people do take 2+ seconds to click. If I were using the right mouse button to select and auto-attack, I would be carefully thinking about whether I should let go or not on most likely a stationary target. If I waited too long to decided if this is a good idea, the game would then force me into camera mode and I would then have to let go and then click fast again.

lorazcyk.8927:

As for “the enemy wouldn’t be there” anymore when you release the button, it doesn’t matter when you release, it should only matter if you pressed and released the button. It will target when you press, if you release the button. If you don’t release the button, it should go into camera mode without targeting. It doesn’t matter if the targt is there or not on button release.

I really think you need to think about this more. This goes further than the target no longer being there. It plays more to other things running in front of your target, like I explained in my last post.

lorazcyk.8927:

And if the player had released the button immediately after pressing, it would have selected that target even when moving, so long as Anet gives a decent time threshold. Decent, not infinite.

Define a “decent time” and then ask someone else to define it. You’re not going to get the same answer. This is futile.

lorazcyk.8927:

Your point doesn’t address the “4 pixel threshold” because we are talking about when the mouse moved zero pixels, even when straffing. That’s the one point of the bug.

What point is this exactly? I have many points and many of them require not to address the 4 pixel threshold because it’s not the main problem. Fixing the 4 pixel threshold to initiate camera by placing a timer would only alleviate half of the issue and arguably, create more. The other issue is the flicking. Removing the right-mouse button to target would alleviate all of the problems without having to change a single other thing.

**Will continue in next post because I went over the limit. Please read as one full post.

Okay, to just share a few last things that I have on the issue:

1. If they remove this .3 second delay after going into camera mode and not right-mouse targeting altogether, the flicking issues would be fixed but the strafing/WASD issues would not. Read above and you’ll understand why. People will still accidentally change targets when moving with the WASD keys while holding down the right-mouse button but not actually moving the cursor. Why? Because the game didn’t go into camera mode and is still waiting for you to either move the cursor 4 pixels to initiate camera-mode or mouse-up to select the target. This would be a half-solution. Though, I don’t know what consequences would arise from removing this .3second delay. I’m not entirely sure why it’s even there to begin with.

2. If they remove the 4 pixel threshold that is required to go into camera-mode, and instead add some kind of timer that forces the game into camera-mode after, say: .1 seconds, then slow and/or careful clickers would be forced to rotate the camera if they didn’t let go of their mouse-button in that .1 second window. Also, if you mouse-down and start strafing, you will be forced into camera mode, even though you may actually want to target that enemy but you waited just a tad too long to release the button. Something like this is what lorazcyk.8927 was suggesting but this shouldn’t even be on the table. Everyone’s reaction times are different and this would just create more problems and is worse than ANets “4 pixel to initiate camera” solution that allows right-clicking on the same input.

3. The only way that I see for them to fix this issue is to remove right-mouse targeting altogether or give us a toggle: let players choose between a perfectly functioning system or an unfix-able one that has consequences while moving with the WASD keys and flicking the camera.

lorazcyk.8927:

(edit: nevermind, I understand what you mean, even if it’s not how I would describe it).

This is how I initially described it in my long post:

ThirdSeason.6295:

1) After mouse-down (holding, not releasing), the mouse cursor must be moved 4 pixels in any direction away from the source mouse-down before camera mode takes effect.
2) After mouse-down, one must meet the condition of #1, AND THEN wait about 300 milliseconds (.3 seconds) before releasing or the game WILL select the target that was or is under the cursor.
3) A target is stored (put in memory; not seen) on mouse-down and is selected upon release if the conditions of #1 AND #2 have not been met.
4) If a target was not stored on mouse-down, then whatever is under the cursor upon release will be selected if the conditions of #1 AND #2 have not been met.

This takes into account the main mechanics of this issue and pretty much sums up what is happening when an accidental target is acquired by the current control scheme. I was just elaborating in my further posts by giving examples but I feel that this hits nail and puts the targeting system in to perspective. It combines what you and Faux Play.6104 described in your multiple, detailed posts. Both of what you guys were talking about was a piece of the same issue but you both were missing how the other person’s piece fit to complete the puzzle.

lorazcyk.8927:

But even if it made sense for a target to be selected on button press, even when he’s not under the pointer anymore on pointer release, it doesn’t make sense that a button release on something that wasn’t there when pressed gets targeted.

**I’m just going to use “enemy” as referring to anything that is target-able. Also, this is going to be convoluted because I have a few reasons why I think this exists.

For this, I think the idea was to give the players time and more importantly: control. Keeping the moused-down, to-be, target in memory gives the player all the time they need and it gives them control over when the target is selected. The consequence of this is that if players don’t move the mouse after holding down the right-mouse button, it selects that target.

Let’s say they changed this and it doesn’t select the enemy if the cursor was or isn’t over an enemy. Let’s say that as soon as your cursor moves away from the hitbox, it removes that enemy from the variable in memory. Guess what this does? It makes the enemy harder to target because of skills like Ride the Lightning, Leap of Faith, etc. One moment the enemy is there, the next they are gone. You click on that enemy but don’t have enough time to release: You didn’t select the target and now they are clear across screen, jumping around and you have to resort to Tab-targeting. Clicking would be just unreliable in fast combat where the enemy and camera will be moving constantly.

This still doesn’t account for any enemy that is actually on screen that your mouse could be over if you mouse-down or mouse-up. So, changing this would do practically nothing to solve the issue of changing targets, as people don’t usually pay attention to where their cursor is on screen when moving the camera. It would only create more issues. Hence, why I think it’s there. There is no real reason to change this because it’s not really the main issue. It’s just that this mechanic, coupled with the main issue of right-mouse targeting, results in a very poor control scheme that just can’t function right without removing the stupid, right-mouse targeting feature.

EDIT:
I may have misunderstood what you meant there. You may have been refering to #4 on my list of factors: Mouse-down on nothing (ground), strafe cursor on top of enemy without moving camera, mouse-up. The result would select that enemy. If so, I really don’t have a reason for why they would have coded this in. It seems beyond pointless and isn’t required for #1, #2, or #3 to work.

lorazcyk.8927:

And if for some reason one would argue it makes sense, then why doesn’t a second target get selected on button release when a different target was selected on button press? Wouldn’t the new “click” also change targets (to the new one)?

This one is easier to answer: When there are a bunch of enemies on screen, you want to select the one you press-down on, not one that could get targeted on mouse-up. Otherwise, you would constantly be selecting things that jump in front of your intended target just as you release the mouse button. Also, it still doesn’t fix the problem of the right-mouse targeting, so it’s not really worth changing. It would just add problems.

So, to close, the whole target under the cursor thing isn’t really a problem by itself but when when coupled with the 4 pixel movent and the .3seconds required delay after entering camera mode, it becomes a problem.

lorazcyk.8927:

I reworded my post while you were writing yours, check it again

I’ll try to respond to that. I have slight reasoning for why things are like the way the are but I’ve not developed the idea enough.

lorazcyk.8927:

By stored, you mean “the game remembers”, right?

I’m not confused, there’s no target being stored in memory/variable, it just targets whatever was clicked on or whatever was unclicked from.

What makes you think a target is being stored (before it shows on the top of the screen)?
And what makes you think it’s relevant to this bug?

I’m not sure exactly what to say. Did you even try those tests? You should understand if you did. There IS a temporary, to-be, target being stored in a variable. Otherwise, it wouldn’t be able to target the enemy/NPC when you release away from the target. That’s just how coding works. Things don’t just happen.

I already explained why this is an issue but to give a specific example:
Let’s say that there is a monster behind you, off to the right of your character, and on screen. Let’s say that this is where your mouse cursor is at the moment: right-on top of that enemy. Now, to strafe, one usually holds down the right-mouse button because they anticipate that they are going to have to turn the camera at some point. Now, you right-click and hold. The mouse was over that enemy. You strafe away without changing the camera because you didn’t actually need to that time. Your mouse cursor is no longer on that enemy, but on the ground. You release the button and it targets that enemy now regardless of where it is and where your cursor is.

In the heat of battle, one does not usually have to time to consciously think about whether they moved the camera or not. So, you’re selecting things that you don’t want to select because a poorly thought out targeting system that stems from ANets vision that right-clicking should target and auto-attack something PLUS move the camera.

This example is just one side of why right-clicking shouldn’t target. The other side is the flicking issue. Both are equally important and are things that nearly everyone does, even if they don’t realize.

ThirdSeason.6295:

lorazcyk.8927:

Could you test what happens when moving 5 and 6 pixels instead of 4?

I will try that now. I assume that the higher I make that number, the smaller the time of .3 seconds will become until it no longer selects the target. This is because the program will be closing the gab on that .3seconds the farther it has to go past 4 pixels.

Alright, I just tried a few different numbers. Honestly it doesn’t really matter. 4 pixels is what it needs to move to regardless and any further testing is kind of pointless as those tests would just speak of the time it takes the program to do something and not the game itself. I will PM you the information because I don’t want to put useless info here that would just confuse even more people for no reason at all.

lorazcyk.8927:

ThirdSeason.6295:

I am quite confused. Not at the subject at hand, but with you. You seem to be contradicting exactly what you said and explained in your videos. I thought that you clearly understood that there was stored target.

I thought it remembered the target the mouse was first pressed on, but then I realized that it also targets when there was no target under the mouse pointer

When I realized this I made a new post to add that information, and also added it to my old post as an edit.

https://www.facebook.com/photo.php?v=109344942609004&l=2226879100695707837

That video has 3 scenes, look at the last one.

I have the light golem targeted, and then I press and hold the right-botton on blank space, strafe left past the targeted light golem, until the cursor is on the Heavy target golem. I release the button. The Heavy target golem is targeted and my character starts attacking it.

Yes, and that is what I just said. Why are you telling me that there is no stored target when you know that there is? That’s why I’m confused with you.

EDIT:
To clarify, there is a stored target when you mouse-down on an enemy/NPC. The game also selects a target when you mouse-up on an enemy/NPC IF you did not mouse-down on one.

Both of these things can happen. Maybe that is why you are confused. The code is nested in an if/else statement that allows both of these things to happen and not contradict each other.

lorazcyk.8927:

You don’t understand what’s going on AT ALL.

There is NO stored target WHATSOEVER!

Read the post and watch the videos!

I am quite confused. Not at the subject at hand, but with you. You seem to be contradicting exactly what you said and explained in your videos. I thought that you clearly understood that there is a stored target. There is in fact a location in the code that stores a target that you mouse-down on. This is easy to test:

Test 1:
1. Mouse-down on an enemy/NPC.
2. Don’t move the mouse cursor at all during the next step (You actually can but not past three pixels.)
3. Strafe away from the target and release the mouse button when your cursor is on top of nothing but the ground.
4. Result: It will target the enemy/NPC that you moused-down on and not nothing like you would expect.

Test 2:
1. Click and target an enemy/NPC.
2. Don’t move the mouse cursor at all during the next step. (You actually can but not past three pixels.)
3. Strafe away from the target but this time get the cursor over different NPC/enemy and then release the mouse button on that enemy.
4. Result: The target will not change because you moused-down on the enemy/NPC that you already had selected.

Test 3:
1. Click and target an enemy/NPC.
2. Mouse-down on another enemy/NPC.
3. Don’t move the mouse cursor at all during the next step. (You actually can but not past three pixels.)
3. Now strafe away from the enemy/NPC that you moused-down on and get the cursor back over the target you originally selected. Release the button on this target.
4. Result: The target will change over to the enemy/NPC that you moused-down on and not the one that you let the mouse off on.

Now, go back up and read my “4 factors.” All of behaviors of these three tests are represented by #3. If you need me to go into detail about #4, then I will. It will still hold true.

lorazcyk.8927:

Could you test what happens when moving 5 and 6 pixels instead of 4?

I will try that now. I assume that the higher I make that number, the smaller the time of .3 seconds will become until it no longer selects the target. This is because the program will be closing the gab on that .3seconds the farther it has to go past 4 pixels.

lorazcyk.8927:

ThirdSeason.6295:

This is where we differ. I wouldn’t call it a bug because I think that the game IS being told to act this way ON PURPOSE. ANet tried to find a happy medium between right-click targeting and camera movement.

Are you honestly saying the game is behaving as intended when there was NOTHING under the cursor when you pressed down the button, held it for 10 seconds, then a NPC comes running to where your cursor is, and when you release the button it targets that NPC?

You can’t be serious. That targeting behavior doesn’t make sense by any stretch of the imagination.

These consequences were the result of such a system. The programmers obviously knew what they were doing to achieve both things working together. They just didn’t anticipate the drastic consequences of such coding OR they shrugged it off and still are shrugging it off.

That’s the exact description of a bug, LOL! Unintended consequences.

This is exactly what I’m saying. Whatever team worked on this obviously had some clue as to what they were doing or nothing would work at all. The stored target on mouse-down and acquired target on mouse-up seems to me like an intentional design: The main purpose of which was to bind two functions to one input. They put in a bunch of code to try to make both work together but no matter what, I don’t see this ever working with any amount of tweaking or fixing. The only options are to give us a toggle or completely disabling right-mouse targeting.

Okay, so on to the bug part. I guess I feel that this isn’t a bug because there is nothing to fix. It’s working as intended. The only course of action is to completely change or disable (add a toggle) the code that does this. I guess that’s my reasoning.

I think I may need to go up and edit my long post. I don’t think I exactly worded .3 seconds after camera mode up part right.

lorazcyk.8927:

It doesn’t matter, if you’ve gone past the PIXEL threshold, the cursor goes invisible and it goes into camera mode, and nothing will be targeted. There is NO time threshold whatsoever. If there was a time threshold, it wouldn’t need a pixel threshold.

There IS a time threshold. I used a program to mouse-down, move the cursor 4 pixels to initiate camera mode, and THEN wait .2 seconds to mouse up. At .2 seconds, it would ALWAYS select the target after it went into camera mode and moused-up. Not until .3 seconds, did it effectively not do this.

lorazcyk.8927:

The games is NOT told what to do if the player presses the button, doesn’t let go right away, and doesn’t drag the mouse. That’s the bug, the code isn’t told what to do in this scenario, so it only waits, when it should go immediately into camera mode if the player didn’t release the button.

This is where we differ. I wouldn’t call it a bug because I think that the game IS being told to act this way ON PURPOSE. ANet tried to find a happy medium between right-click targeting and camera movement. These consequences were the result of such a system. The programmers obviously knew what they were doing to achieve both things working together. They just didn’t anticipate the drastic consequences of such coding OR they shrugged it off and still are shrugging it off.

RoyHarmon.5398:

So what happens if, having targeted an enemy (“Enemy A”), you press right-click with the cursor over another enemy (“Enemy B”), then quickly (<0.3 seconds elapsed) move the camera so that Enemy B is no longer on the screen, and release the mouse button while the cursor (now invisible, of course) is not on an enemy? Do you lose target on Enemy A?

I didn’t really take into consideration whether the enemy was on screen or not in my previous post. Now testing it, I’ve found that it doesn’t matter. You can test this without flicking. Just select (“Enemy A”), then right-mouse down on (“Enemy B”). Don’t move the cursor at all and then strafe so that the (“Enemy B”) is out-of-view. (“Enemy B”) will still be targeted upon mouse-release. I’m almost positive the exact same thing would occur even if initiate camera mode AND THEN you flick the camera faster than .3 seconds, because you’re not meeting the conditions of what I described in #1 AND #2, regardless of whether you don’t flick or flick faster than .3 seconds after camera-mode has been initiated.

DarkSider.1079:

This post is over 6 months old, why hasn’t something as simple as this been created yet? If you’re using WASD plus your right click for movement (camera) why would right click be a selectable option anyways? I can’t tell you the amount of times I accidently select allies during larger group events or world events, it’s quite annoying.

The reason is, is that ANet apparently wanted people to be able to auto-attack a target with the right-mouse button (seemingly to make combat faster) and this is the solution that they came up with. Why anyone actually needs to initiate auto-attack as soon as they click is beyond me. Even in PvP, you have to MANUALLY use all of your other skills anyway, so I don’t see the problem with players having to initiate their first attack manually too. It’s barely any efficiency loss and ridding right-click targeting issues would also keep WvW zergers from accidentally selecting wrong enemies and allies. It’s one of the main reasons I won’t touch WvW much other than world completion.

So, I’m going to try to compile a list of things that each mouse button does, their targeting mechanics, and the results of such. The recent information presented by lorazcyk.8927 and Faux Play.6104k paints a perfect picture as to how the targeting system is coded and the problems that arise from it. I really wouldn’t call this a bug anymore, but more of just a crappy code job with massive consequences that I’m sure ANet is aware of and doesn’t care to change. Honestly, how could they not realize the abhorrent problems caused when things are plainly coded as such?:

Basic mechanics:
LEFT MOUSE BUTTON
- Selects target and does not auto-attack it.
- Deselects target when clicked on ground (ie. something that isn’t target-able.)
- When held down, allows rotation of the camera without forcing the camera to stay behind character.

RIGHT MOUSE BUTTON
- Selects target, faces your character towards it, and starts auto-attacking it if auto-attack is enabled for one of your skills (ie. Ctrl + Mouse 2 is enabled on that skill).
- Does not deselect target when clicked on ground (ie. something that isn’t target-able).
- When held down, allows rotation of the camera and forces it to to stay behind character unless not moving.

4 main factors seem to be the cause of pretty much all of the problems in this thread. These all go hand-in-hand and effectively result in the massive cluster**** that is the GW2 targeting system:

1) After mouse-down (holding, not releasing), the mouse cursor must be moved 4 pixels in any direction away from the source mouse-down before camera mode takes effect.
2) After mouse-down, one must meet the contion of #1, AND THEN wait about 300 milliseconds (.3 seconds) before releasing or the game WILL select the target that was or is under the cursor.
3) A target is stored (put in memory; not seen) on mouse-down and is selected upon release if the conditions of #1 AND #2 have not been met.
4) If a target was not stored on mouse-down, then whatever is under the cursor upon release will be selected if the conditions of #1 AND #2 have not been met.

**These hold true for both right and left mouse buttons and seemingly, the only distinction between the two buttons and their functions are what I explained at the top.

So, if you look over those 4 factors, you will see that these are some of the problems that arise from such a convoluted mess :
- When you mouse-down, flick the mouse, and release before .3 seconds is up, you will select whatever is or was under the cursor, regardless of whether you went into camera mode or not.
- If you mouse-down on top of a target (stores in memory), strafe away from it so that the cursor is no longer on top of that target, and don’t move the cursor 4 pixels AND THEN don’t wait .3 seconds, the target that was stored (in memory) will be selected upon release.
- If you mouse-down on the ground (targeting nothing), strafe so that the cursor is on top of something that is target-able, and you don’t move the cursor 4 pixels AND THEN don’t wait .3seconds, you will select whatever is under the mouse cursor upon release.

So, giving us an option to turn off right-mouse button targeting would fix the issue for the most part, but these problems would still persist on the left-mouse button. Of course, since no one really strafes with the left-mouse button down or selects targets while flicking the camera with the left-mouse button, the issues wouldn’t be as apparent and game-breaking as they are now.

Faux Play.6104:

Moving the mouse x pixels will not work. Hooking the right mouse up event and delaying it would solve the problem, but that is really just a kludge fix.

Selection triggers after the following sequence of events: mouse down, then mouse up. It needs both a mouse down and a mouse up event. Between the mosue down and mouse up event there is a filter that looks at both time and motion. If you make a slow click + motion >1s you will never select a target. However if you make a fast click < 1s and start and end your click on a target you will both move the camera and acquire the target. I have linked a video that shows mouse highlights to show the click events in the follwoing bug report.

https://forum-en.gw2archive.eu/forum/support/bugs/Camera-motion-and-target-selection-w-1-click/1943672

ThirdSeason.6295:

Alright, I’m to the point that I’m about to quit the game because of this. I’ve run CoF path 1 probably 200+ times and every single time, without fail, I select the wrong target at Slave Driver and The Searing Effigy because of this issue. It makes the run an absolute pain with my staff Elementalist, because it takes so long to start re-attacking the correct target with the Fire 1 skill and my god-knows-where, elemental summon.

I’ve thought of a workaround but it would require a third-party program and I’m not exactly sure if one exists to accomplish what I want. Though, it seems like a rather simple “solution” and there probably is a program but it’ll take some searching.

SO:
After pressing and holding the right-mouse button, there is a small threshold that you have to move the cursor before the camera control will take over. It looks like about 3 pixels in any direction from the origin mouse press.

What I’m thinking is to find a program that will move the mouse cursor those 3(?) pixels (in whatever direction specified) as soon as I press the right-mouse button. This would ensure that when I press and hold the right-mouse button, that it will instantly go into camera mode. The game would then not be stuck in some limbo state of wanting to know what to do next, as explained by lorazcyk.8927.

Yeah, I just encountered this. Got it to move the cursor over (was 4 pixels) but if I clicked too fast, it would still select whatever was under the cursor. >.< Also, it just created another problem when I manually moved the camera at the same time the program was shifting the cursor. Seems that the game doesn’t like the cursor being moved in two different directions at the same time.

Edit:
After messing with this a bit more, I’ve found that after you right-mouse down, you have to move the cursor 4 pixels AND THEN wait about 300 milliseconds (.3 seconds) before you mouse up, so that it won’t select the target that was/is under the cursor.

Alright, I’m to the point that I’m about to quit the game because of this. I’ve run CoF path 1 probably 200+ times and every single time, without fail, I select the wrong target at Slave Driver and The Searing Effigy because of this issue. It makes the run an absolute pain with my staff Elementalist, because it takes so long to start re-attacking the correct target with the Fire 1 skill and my god-knows-where, elemental summon.

I’ve thought of a workaround but it would require a third-party program and I’m not exactly sure if one exists to accomplish what I want. Though, it seems like a rather simple “solution” and there probably is a program but it’ll take some searching.

SO:
After pressing and holding the right-mouse button, there is a small threshold that you have to move the cursor before the camera control will take over. It looks like about 3 pixels in any direction from the origin mouse press.

What I’m thinking is to find a program that will move the mouse cursor those 3(?) pixels (in whatever direction specified) as soon as I press the right-mouse button. This would ensure that when I press and hold the right-mouse button, that it will instantly go into camera mode. The game would then not be stuck in some limbo state of wanting to know what to do next, as explained by lorazcyk.8927.