Guild Wars 2

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.

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.

Post a video showing your options. sounds to me like you are confusing the mouse targeting glitch with some of the auto targeting features that are in the game. I have never seen a delayed target switch. It either does it when you click or it dosen’t. I can only cause the target loss with camera motion on a fast click <1s.

Kraag Deadsoul.2789:

(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.

Evan,

I’ve logged into Lord of the Rings Online today and done some experiments with the camera there to see to see how it behaves differently from the GuildWars 2 camera. The most noticeable difference is that the click – drag threshold in Lotro is much, much lower compared to GW 2. In Lotro it looks like as if the threshold would be < 10 pixels and it might be as low as five pixels – it is at most 25% of the threshold that you use in GW2.

I’ve been playing Lotro since 2008 and I’ve never it had it happen that I would have selected something when I wanted to turn the camera or that the camera would have turned when I wanted to select something. I’ve also never seen anyone complain on the Lotro boards about this kind of problem. In GW2 on the other side I ran into this click vs drag problem right in beta weekend 1.

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.

Faux Play.6104:

Post a video showing your options. sounds to me like you are confusing the mouse targeting glitch with some of the auto targeting features that are in the game. I have never seen a delayed target switch. It either does it when you click or it dosen’t. I can only cause the target loss with camera motion on a fast click <1s.

The options you’re talking about only apply to left click. Right click automatically attacks the target. You yourself spoke of this button behavior difference in your other thread.
If you watch my videos, you’ll see a “delayed target switch”. A purple ping shows a right click (and I hold the button down after I press it).
Check the syvlari videos and the bunny/grawl video.
.

A pity that banditcam doesn’t show that I’m holding the button down, it only pings when I first press down, it should show the purple ping the whole time I hold the button down.

!&#^@ KITTEN!!!#@#&!!!

This is also bugged on button release, not just on button press!

So long as the right mouse button is pressed or released where there’s something targetable, it WILL target and attack that thing!

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

• In the first scene, I press and hold the right-mouse button on blank space, strafe all the way left until the pointer is on blank space, and release the button. Nothing is targeted.

• In the second scene, I press and hold the right-mouse button on the Light Target Golem and strafe left until the pointer is on blank space, and release the button. The light target golem is targeted and my character attacks it.

• In the third scene, the light target golem is still targeted. 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!

The correct behavior is that NONE of these things would target. Doing all of these things shouldn’t target anything. The only want something should be targeted is if you click it, that is “press the button on it and release the button immediately”.

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!

Thank you for responding to this thread Evan. Hopefully this means we’ll actually see this option soon. Could you clarify what you mean by “There are two problems (with an option do disable right click targeting)”. Those of us posting here never want to use right click to do anything besides manipulate our camera angle. Making this a toggle option would mean we’d have no problem and people who already have no problem still have no problem. It’s a win win. If an attempt to address this is made by changing the threshold for when a right click is changed from targeting to not targeting, we will all see it as spite or even disrespect at players’ ability to make great suggestions. This isn’t a case of disgruntled farmers complaining about loot and asking for more stuff. We are players who’s gaming experience is suffering from a feature with effects that draw parallels to a legitimate bug. Again I’m really happy you posted because that means someone is actually looking at this. I don’t see any other option for this though. Completely removing right click target hurts those who use it, and changing the target threshold does nothing for the people who don’t want it at all.

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.

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.

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 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?

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.

ThirdSeason.6295:

I really wouldn’t call this a bug anymore

There IS a bug.
The game isn’t told what to do if the player doesn’t release the button and doesn’t move the mouse, so it gets stuck waiting for one of those to happen.

It’s only missing that, once anet fixes the bug you won’t accidentally target things anymore unless you truly did a “click” (pressing the button and releasing it immediately)
But if you honestly were trying to move the camera, you won’t accidentally target things anymore.

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?

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.

But right now you can press and hold the button over a target however long you want (I think the max I tried was 5 minutes), and when you release the button, it will target that thing. It will also target if there was nothing on that spot when you first pressed the mouse, but then something else (like your friend’s turret) was there when you released the button.

I know why they added a pixel threshold, if you’re running around and click something to target it, because you’re running the camera will get dragged a few pixels when you press down the mouse, so the game wants to make sure you’ll target that something.
But instead of a pixel threshold, it needs a time threshold. However long a “click” leaves the button pressed down. If the player doesn’t release the button in that time, then it goes into camera mode.

Bug gone, no more accidentally targeting something.

Once the cursor has gone transparent there’s no longer an issue with accidentally targeting things.
The problem is that if you don’t release the button and don’t move the mouse, the code Anet wrote didn’t tell the game what to do in that situation. So the game waits… and waits…
Eventually the player will eventually drag the mouse, or release the button.
If he drags the mouse, it goes into camera mode.
If he releases the button instead of dragging the mouse, it clicks whatever was under the pointer.

But there’s a bug in the code where the game doesn’t now what to do when the button is held down but the player doesn’t move the mouse. When that happens, the cursor doesn’t go transparent, it doesn’t go into camera mode. It’s stuck “waiting” for the player to tell it what to do.

It’s like putting a blanket over broken glass on the floor, sure, it will sort of work, but it’s not the correct thing to do.

Anet needs to remove the pixel threshold so that on button press, the player goes straight into camera mode (transparent cursor) if the player didn’t release the button immediately after pressing it. Then things will no longer be selected accidentally (YAY!!!), but people who like to use the mouse to target will still be able to do so, they just have to let go of the button immediately (as I’m sure everyone does anyway).

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.

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.

ThirdSeason.6295:

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.

Wow, interesting, I never thought of testing after it goes into camera mode, I figured that by that point, the game has already decided what to do (camera or target)

It’s weird that they have the time threshold start counting after it goes into camera mode, not before.
The time threshold needs to start counting on button press, not on initiation of camera mode.

I was going to say to test: press the mouse button down, wait 10 seconds, move 4 pixels to initiate camera movement, then release the button. But if the time threshold only starts counting after the mouse goes into camera mode, I guess it doesn’t matter.

This algorithm really boggles my mind.

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

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.

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:

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.

ThirdSeason.6295:

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.

I hope in the near future they can add something in options to disable it or change it’s function. Realistically disabling it or allowing for it isn’t a big coding change, but it’d probably make a lot of us happy to have the option. I rarely right click for anything, I find it a huge nuisance.

Whatever team worked on this obviously had some clue as to what they were doing or nothing would work at all.

… obviously. They just didn’t realize this problem would happen. Hence the bug O_O

The stored target on mouse-down and acquired target on mouse-up seems to me like an intentional design

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

There is NO stored target WHATSOEVER!

Read the post and watch the videos!

Otherwise, I feel that this wouldn’t have even gone past testing or even beta.

Sure, it could, it definitely could have. You just have to look at Microsoft for that, LOL!

Developer:
“Ok, let’s make some mighty fine code! Best in the world!”

6 months later:
“Hmm the alpha testers are complaining of accidental target changes, lemme see, lemme see this code….”
“Ah, I know, I need to add a a time threshold to the camera! When the camera starts, it will have a threshold to decide if it should click the target.”

This person just added a band aid, not a solution.

1 year later, a different developer is told he needs to fix this problem because players are complaining.
New developer looks at the code, and doesn’t realize the other person already added a camera threshold for this same reason.
“Ha ha, I know! I’ll add a pixel threshold before the mouse will go into camera mode!”

This person just added another band aid, not a solution.

So despite the band aids, the problem is still there and will always be until they fix the core problem: the missing check in the algorithm.

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:

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.

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.

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.

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

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. 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)?

That, and the sheer stupidity of selecting a target even if the mouse was held for a whole minute, would suggest that all these behaviors are not intended, but are a bug (the person coding it forgot to add a check for it)

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:

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.

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

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:

(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.

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.

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.

Winner Winner Chicken Dinner

One input I’d like to give on the matter of separating functionality:
We already have targetting on LMB.

And right now, I’d wager to say that 99%++ of players do not actually know you can target with a RMB click. It’s completely unintuitive because every other game so far does it different. And the two buttons are right next to each other, so why shouldn’t they? LMB targets, RMB pans the camera or triggers auto-actions on right clicking a target (targetting not being one of these).

Everyone is used to this. One reason we struggle so much with GW2’s model is because it differs from anything we know, and not in a good way.

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.

Right now no mater how slow you are (even if it takes you 5 minutes to release the button), the game will always target.

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. But that’s a matters of collecting metrics.

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.

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.

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.

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.

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.

The way they fix it is immediately start the TIME hreshold counter whenever the mouse is pressed down, NOT when it’s moved, and remove the pixel threshold.

The game checks for two things:

• Did the player click and release the mouse? if so, select the target.
• Did the player click and drag the mouse? If so, move the camera.

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.

I don’t know how more clear I can make this.

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 neccessary after they fix this bug.

After that, it will be extremely rare to accidentally select a target, and if it happens it will be because of user error, not a bug, the players will just need to learn “clicking selects a target”, “holding the button goes into camera mode” which is standard behavior in games so I can’t imagine it will be too difficult to learn. In fact, this is why we accidentally target, we expect (correctly, I might add) that holding the mouse button would trigger camera mode, not target selection. The accidental targeting happens because the game wasn’t told to what to do if the player presses the button, doesn’t move the mouse, but doesn’t release the button either. It’s a bug — missing logic check — once Anet adds this check, removes pixel threshold, and keeps the time threshold (I admit I don’t know if 0.3 seconds is enough, I haven’t tested), people won’t accidentally target anymore, but those who want to click to target will be able to so long as Anet gives a reasonable time 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.

**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.

The time threshold will prevent it from going into camera mode right away, as I’ve said. The game will ONLY go into camera mode if you don’ release the button under the threshold time.

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.

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.

No! Wrong!

…………

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.

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.)

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, and they had to use a workaround/bandaid for us to be able to target something with the mouse.

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… :-(

Went go Gw1 and tried to hold the left button, then strafe left.
If I start with the cursor on a target, it selects that target immediately, it doesn’t wait for mouse up.
If I start with the cursor on blank space and release the button when the pointer is over a target, it doesn’t select that target.

If the time threshold doesn’t work either, they would have to disable targeting for the right click and only allow it for the left click like Gw1, make left click target on button press, not button release.

Then they could reword the “Double click to interact” option to make it instantly interact that target with a single click if the option is disabled, with double clicks if the option is enabled.
Then the option “Stop auto attacking on target change” would only apply to single click when “double click to interact is disabled”

Which was the original solution I had thought of, but… :-(
I actually prefer the right click targeting behavior than the left click, if Anet did this, I would put it on the left click.

Thank you Evan! I’m going to cry of happiness! (Okay, just kidding, but I teared up for a second)

Good luck working on this thresholds!

I’ve always liked the right click behavior, I just didn’t like that it made me select targets accidentally. If I had the option to give the right click behavior to the LEFT click, I would love it.

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?

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

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.