Guild Wars 2

I just didn’t want to get my hopes up thinking “Yay! I found a like-minded group, it’s going to be fun!” and looking forward to doing some dungeons, but then the group “skips” the boss by stacking where the boss can’t hit us. (To me, doing this is akin to skipping mobs), so I wanted to make sure what your stance was on it before I asked for a guild invite.

But if you think I’m a troublemaker, I suppose I’m not welcome anyway. Interesting you think I consider myself better than others, my IRL health condition doesn’t allow me to consider myself better than others even if I wanted to.

But even so I’m surprised you think that, as I’ve said in other threads I’m 100% OK with other people doing speed runs (skipping) and glitching the boss if they want to get it over with and just make money. I just don’t find it fun myself.

Hope you all have fun though.

/me scratches head

That’s why I’m asking. I want to join so I can team up with people who like to complete content instead of skipping it.

Just as I don’t like to skip content (skipping mobs), I also don’t like to cheese through bosses, I like to fight bosses as Anet intended, just as they intended for us to kill monsters instead of skipping them.
If the guild takes the same stance on that, I’d like to join.
.

Not very friendly, I see. Banned me before I even joined.
Enjoy.

Will using cheap tricks be allowed? I mean, like balling up on a hill where you can auto attack the boss to death without the boss being able to kill you.
Will players have to fight properly?

https://dviw3bl0enbyw.cloudfront.net/uploads/forum_attachment/file/62198/gw091.jpg

This one. He also has a younger voice. I love it.

MithranArkanere.8957:

I have two female charr.

A blood legion warrior that supposedly should look like a tiger, and an ash legion thief who should look as close as possible to a Siamese cat (everyone knows Siamese cats are the swat, black ops, ninjas and spies of the animal kingdom).

They use the same armors with little variation and have many faces you wouldn’t see on males, so for many combinations you just have to make a female.

I play female but I don’t like it, I’d prefer playing a male.

But the male voice is so deep, I can’t understand what he’s saying.
All male charr look like grandfathers, I want to play a teenage or young adult charr.
I also want to be as short and skinny as the shortest female.

I wanted to play this face
https://dviw3bl0enbyw.cloudfront.net/uploads/forum_attachment/file/62198/gw091.jpg
And he has a really cute voice too, I wanted it

So long as the “difficulty” mechanic is agony, I don’t give a skritt..
If it were fun and had real skill challenge, I would do it, even it had zero loot or rewards.

Suggestions for real difficulty have been made in several threads.

I know you’ve increased the FOV in game a few months ago, and it completely fixed my issues with migraines and nausea (feeling like I’m spinning and like I’ll vomit). Thank you.

But underwater the FOV is still so low that those things still happen to me.

I doubt this is possible, but…

Let us use inventory, hero panel, trading post, etc, during loading screens. Now I can salvage stuff, organize inventory, swap traits, buy skills, while I wait.

Never understood why there isn’t one Trainer and one Bank in each map. Just one.

It stinks that you can’t aim a ground targeted skill on the event UI (and the enemy UI).
If you ground target to show the green ring, then move the mouse to the event area and try to ground target, it says “out of range” and doesn’t let you use the skill.

You know, all the UI clutter goes away when you get Downed, so Anet already has the code to make it go away based on certain conditions (such as when you get Downed). If Anet gave us a toggle in options to hide it in combat, then the game could check if you’re in combat, then hide the UI clutter.

They could hide the same exact stuff they currently hide when you get Downed.

I have my “hide interface” set to the ` (grave) key, in American keyboards it’s to the left of the 1 key. So it’s pretty handy to turn off the UI when I go into combat. I’d still like to see my skill bar and the enemy bar, though.

«You are too serious of your skills & opinions judging that you just started doing dungeons a couple weeks lately »

The kitten?! ’ve been playing since beta and doing dungeons shortly after launch. I stopped playing, started playing again, and have been doing dungeons since.

And I agree that monsters could give nicer loot, it’s annoying getting nothing or gray items. I understand why Anet doesn’t give a lot of money/loot before you finish the dungeon though, they want you to finish the dungeon instead of farming the trash mobs.

I don’t know what kind of loot the monsters could give without leading to players farming monsters at the beginning of the dungeon then leaving without finishing.

Anet doesn’t want players to farm the easy guys, they want them to finish the dungeon.
Personally I don’t have a problem with people doing that, but it’s Anet’s game, not mine.

Me Kill You.9035:

Sure the first time you do a dungeon, it’s totally understandable to want to see all there is to see in it, all the mobs, bosses and their mechanics etc. Heck maybe you want to do it that way a few more times after that.

If your intentions are for the gear or loot ($$) alone, which if you’re playing a dungeon many times I can only assume that is your intention, why would you feel you need to go through every mind numbing trash mob and obstacle that offer little to no reward?

There is no logical reason I can think of. Now I’m not saying people who want to play 100% of the dungeon are wrong in any way, it was all put there to be played. But I have to repeat what others are saying that is YOUR choice and If you do not agree with how other do it, stop qqing on the forums (you will not find sympathy here for trying to make others conform to your ways) and form groups of other like minded people.

Who knows, maybe after running arah for the 20th time to get those armor/weapons you really want you’ll start to see it from a new angle..

Whether for gear or for loot, I still want to play a dungeon for the reason I first tried the dungeon: for fun.

If I weren’t doing it for fun, I wouldn’t do it at all, if I weren’t having fun, I would just not bother getting the armor or loot.

That’s why I don’t skip or use gimmicks, I fight honorably.

Right now I’m doing dungeons for armor and loot (SE and CM), and I’ll always fight honorably.

I was the same in Gw1 for seven YEARS, so no, thwt’s why I know I’ll never resort to speed run cheap gimmicks like you say I will.

Hey there
I’d like to play with other people like me.

Even though I’ve hit max level more than 6 months ago, I still like playing all over the world doing events. I wish I could re-do hearts too!
I like playing with other people regardless of level or where they’re playing. To me the fun is in playing together..

I’m not into farming or grinding, specially dailies or world bosses.
I like to take my time and enjoy dungeons, instead of rushing through them. I don’t want to clear them with cheap tricks either, I’d rather fight honorably. I use my skills for the benefit of my party, instead of being selfish.

I don’t play WvW a lot, but I like it in small teams (4 or 5 players).

Lately I’ve been focusing in doing Caduceus Manor and Sorrow’s Embrace dungeons because I want some of the armor and runes, but I’m always up for anything.

Usually online either 1-3 pm or 8-11 pm EST, except Wednesday and Sunday.

On top of all this is still player preference. Not everyone wants a single right-click to perform default actions. This is why we’re adding a toggle for it in the next patch.

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.
That means that we will probably still accidentally target something, but at least your character will keep auto attacking the old target. Using a targeted skill other than auto attack will still switch targets.
.

@Evan, definitely consider letting us call targets when playing alone, this way we can call a target every time we choose to attack a monster, and then if we accidentally change targets, we can just press T to take our old target back.

There is certainly a bug with prolonged mouse-presses and not moving the cursor. I am fixing this. However, this is certainly an extreme case and fixing this will not solve all issues players are experiencing.
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 know it’s none of my business, but I’m curious why you don’t place the timing threshold on “button press” instead of “after player moves 4 pixels”. Even if you kept the pixel threshold.
It doesn’t seem to me like the answer would be reducing the threshold, either pixel or time.

And I assume that by “There is certainly a bug with prolonged mouse-presses and not moving the cursor”, you mean “not moving the cursor more than 4 pixels”. Because it will target if you don’t move more than 4 pixels.

And by “the current click timing threshold is 250ms” you mean "the current timing after the player moves past the 4 pixel threshold ", because it certainly isn’t after the player presses down the mouse.

I’ll leave you alone so you can work
:-P

@Evan, this is kind of off-topic, but can you do something about the fact that Call Target (Ctrl-space) doesn’t let us call a target when we’re playing solo? It only works if we are in a party.

If I could call targets when playing solo I wouldn’t mind accidentally targeting something accidentally so much (if at all, really), because I could always just press Take Target (T) to bring my old target back.

@Thirdseason, I understand what you’re saying, believe me, I do, but to get the same effect as your current fast flick with a slower rotation speed, you’d have to hold the mouse button a lot longer, meaning that it wouldn’t click a target anymore.
You would no longer do a fast click, because with a lower rotation speed, the camera would hardly turn at all if you did that.
If you still accidentally target something, turn the rotation speed even lower.
.

I understand that players could still accidentally target, but that player would quickly learn “Oh, I see! Releasing the button quickly makes the game target something!”, and “I can see that pressing the button longer makes the camera turn”, because the behavior is easy to recognize and easy to predict, which the current behavior isn’t. With that in mind, the player can notice and adjust his behavior to prevent the problem.

But, the current behavior took 9+ months and we still had no clue exactly what was going on. A lot of players who have been playing since beta noticed that they lost their targets very often, but even in June 2013 they still couldn’t tell what made it happen, so they couldn’t adjust their behavior to prevent it!
.

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.

This change would make it easier for the player to understand, and in turn, the player would realize he simply has to hold the button longer when he wants to turn the camera.

I understand how difficult the problem is, after I realized that the game probably only has camera mode code, so the Devs had kind of had to “hack” the camera code to make it possible to click targets. It’s a clunky hack, but sadly I now understand why it’s so difficult to get this thing done right.
.

Anyway, before we get more into this discussion, I want to 1) see the new right click targeting on the next patch, and 2) see if Evan can fix the bug he mentioned and see what changes it might bring.

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

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.

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.

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

Eh, I see it could also be this

:-(

Player “ThirdSeason” says that after the game triggers camera mode, there’s about a 0.3 second delay where it will still target something.

I’m not sure if that’s true or not, but if it is, you need to make that delay go before the game triggers camera mode, not after.

No! Wrong!

…………

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.

After what Evan Lesh said here,
https://forum-en.gw2archive.eu/forum/game/suggestions/An-option-to-disable-right-click-targeting/page/13#post2122506
I decided to do some testing.

More information and videos here:
https://forum-en.gw2archive.eu/forum/game/suggestions/An-option-to-disable-right-click-targeting/page/14#post2132488
(the videos are Facebook links)

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

• Did the player release the button? Then select the target under the mouse pointer
• Did the player drag the mouse? Then rotate the camera

But the game doesn’t know what to do when the player pressed the mouse but didn’t do any of those two things, so it gets stuck waiting!

Instead of checking for that condition, you added a sloppy band aid: you made it so unless the player drags the mouse more than four (?) pixels, it will always select a target, even if the button is held down for five minutes…!

If the player presses he mouse button over something targetable, even if that thing isn’t there anymore after five minutes when the players releases the button, it will still target that thing!

And even if there’s nothing targetable when the player first pressed the button, if after five minutes there’s something targetable there, it will target that thing!

This bug has led to a lot of players accidentally targeting something with the right mouse button and losing their previous target, when what they meant to do was go into camera mode.

This is true even if the player moved those 2 or 3 pixels (not triggering camera mode).

You need to get rip out the 4 pixel threshold band-aid, and instead use a time threshold. Collect some metrics to see how long the average click makes the button stay pressed down, to find how long the time threshold should be. If the player releases the button before the time threshold (meaning the play did a “click”), the game chooses a target. If the player holds it past the time threshold, the game goes into camera mode, and does NOT select a target.

When selecting a target, it doesn’t matter if the player moved the mouse “a tiny, tiny bit” between button press and button release,so long as he relsesed the button immediately after pressing it, which is what a click is.

Evan Lesh owes me 5 total makeover kits kits if I’m right
:-P

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.

Why do people need the story thrown in their face to see it?
There is actually quite a bit of story in the updates, but you actually have to actively speak/listen to NPCs in order to get it. Just like in the real world.

I don’t want the story thrown in my face to see it, but I don’t want to read the story, I want to experience the story from the perspective of my character.

Galen Grey.4709:

The story isn’t disjointed at all. It is just not presented in your face. The trick is to talk to the NPCs and I don’t mean the ones clearly marked but all the NPCs. A lot of them will tell you whats happening to them and in so doing they’re painting a bigger picture.

I don’t want to read the story, I want to experience the story.
It’s a game, not a book.

In Gw1 I didn’t mind reading because I was reading it as I experienced it. In Gw2, you’re TOLD what’s going on, you don’t experience what’s going on.

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

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

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.

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.

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.

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:

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

Lindelle.3718:

There is also a human hairstyle with curly pulled back hair that did not make it, and a sylvari one that was similar to the asuran mini mouse style. Clipping issues maybe? But seriously, its about time we had some more customization..

:(

Need moar curlz!!!

Okay, I see, thanks.
I didn’t fight anyone in WvW so I was surprised. (I only go there to change my traits then I leave)

!&#^@ 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”.

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.

Yup!

Make all sylvari hairstyles unisex!

https://forum-en.gw2archive.eu/forum/races/sylvari/Make-all-current-sylvari-hairstyles-unisex/first#post2103022

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

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

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

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

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

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

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

Another example that fits. This player
says:

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

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

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

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

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

It fits. It all fits.

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

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

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

So all this stuff…

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

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

… has no relevance whatsoever to fixing this bug.

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

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

Good for you, but it doesn’t help me one bit?

Not WvW, just cities to cities.

Make a separate short path around the L.A. gate in the city, that path has the gates.

Iruwen.3164:

lorazcyk.8927:

Since Anet won’t make effects simple, then I want to disable them so I can become a good player and fight skillfully.

Disabling effects doesn’t make you a better player. Keeping an overview of what’s happening no matter if there’s a lot of effects going on makes you a good player.

That would be true if the effects didn’t cover the entire screen. It’s impossible to keep an overview of what’s happening because the effects cover the whole screen. It’s like being blindfolded. Not even exaggerating.

Disabling effects would allow me to be able to see what’s going on and keep an overview of what’s happening. This would allow players to actually see what’s going on, and react to what they see, thus giving them the opportunity to become a better player.

It doesn’t even AUTOMATICALLY make you a better player, the player is the one who has to realize they have to react to what’s happening.

However:
They don’t have the opportunity to become a better player if they can’t see what’s going on,
if they can’t see what’s going on they can’t keep an overview of what’s happening,
if they can’t keep an overview of what’s happening, they can’t attempt to react to something that happened,
if they don’t have the opportunity to react to something that happened because they can’t see what happened with all the effects covering up the screen, they can’t become a better player.
They don’t have the opportunity to become a better player if they can’t see what’s going on…

The gray needs to be a bit brighter, right now, unless I point the camera up at the sky when it’s daytime, I can’t read NPC chatter.

Also, when we select in chat preferences NOT to see world chat bubbles, PLEASE don’t show NPC chat bubbles!

I wanted to go to WvW and queued up for it.

I was fighting at wayfarer foothills at nearly full health.

A pop up came up saying that WvW was ready for me, so I clicked to go there.
When I zoned in WvW, I was alive.
I was alive the whole time. I fought a Raptor, killed them, but was at nearly full health (my health never got lower than 75%)

I logged out and logged in to come back to PvE, and I was dead in Wayfarer foothills.

At about 23:45 EDT if you want to check into it.

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

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

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

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

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

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

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

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

Check this video I made earlier

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

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

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

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

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

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

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

Edit (June 2):

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

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

( Edit, after having more information: )

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

Give every city asura gates to every city.

That way we don’t have to port to lions arch first.

You’re not supposed to give different players didn’t roles.
You don’t say “you go healer, you go tank, the rest of you go DPS”.

That’s not how it works.
Everyone is primarily DPS. But every different class have different kinds of support and control skills. And different builds have different kinds.

Everyone is the trinity at all times.
You mostly DPS, but you also need to be careful with how you use your support and control skills, coordinating them with other players.

eisberg.2379:

lorazcyk.8927:

They can practice by playing the dungeon. Duh. Like you gget better at roller skating by rollerskating. But you don’t “win” at rollerskattig right at first, you practice.

Practicing on the easy mobs to the boss isn’t going to prepare you for the boss. Fighting the boss itself is where the practice needs to be at. Fighting the trash mobs for practice is like fighting a 10 year old to practice for a heavy weight boxing match.

Or to your analogy, what you want would be same as telling someone who is practicing at roll skating that they need to go back to learning crawling after they fall down a few times when practicing roller skating.

What’s wrong with that? When they get to the boss they can learn the boss.

Or Anet could make easy enemies have boss tactics, as you get to the end the enemies have more and more of the boss mechanics. For example, from the first waypoint to the next, you get 1 mechanic. From that wayponit to the next, you get 2 mechanics, and so on. By the time you get to the boss you already learned the mechanics.

I honestly don’t think that’s needed, players don’t need to be given everything in a silver spoon, but I wouldn’t be opposed to it.