Guild Wars 2

Your projectiles and bouncing projectiles will take you out of stealth (and therefore apply revealed) if they are mid-flight and hit a target after you have entered stealth.

I understand the intent of the revealed mechanic. The goal is to take the thief out of stealth upon dealing direct damage from stealth. However, in practice, this is problematic because the damage of most projectile skills is delayed. The result is very often an unintentional and clunky stealth breaker due to ranged attacks. This makes most stealthing utility skills and traits very unappealing to use with ranged weapons, as ensuring that you have no mid-flight projectile adds a clunky, burdensome, task of tracking something that should not have to be tracked.

The solution is simple: Make it so that any attack performed before stealthing are unable to apply revealed to the thief. Dodgy builds are on the verge of a nerf, and our other defensive mechanic, stealth, needs to be as reliable as possible, and as such, for every thief. As of right now, ranged attacks make the use of certain traits and utility skills harder and more punishing than it should be.

I was going to make a video, but twitch is taking a dump.

they can do this by programming a trigger on all dmg skills after stealth is applied.

Travlane.5948:

they can do this by programming a trigger on all dmg skills after stealth is applied.

Absolutely. I’d do it for free!

Only damage from attacks launched while the thief is in stealth should reveal. Unfortunately, that’s not how it’s done.

stof.9341:

Only damage from attacks launched while the thief is in stealth should reveal. Unfortunately, that’s not how it’s done.

That’s what everyone wants. Anet will never respond to this in a lightyear. I’ll just repost over and over. At least, it’ll be a legitimate ban for a change, and they’ll have to read it.

+1, this can get crazy with max range cluster bomb, cause it takes forever to land.

Trancid.8514:

+1, this can get crazy with max range cluster bomb, cause it takes forever to land.

Cluster is the worst, but it’s predictable at least. Most other attacks are much harder to call.

Oxygen.5918:

Travlane.5948:

they can do this by programming a trigger on all dmg skills after stealth is applied.

Absolutely. I’d do it for free!

If you think about, that’s exactly what they have, a trigger. Unfortunately, it only triggers when damage is dealt, then it checks if you’re in stealth or not before it applies the debuff. If the debuff is triggered on all damage skills, then how do you check for skills that did not deals damage? Do you still want to get debuffed just because you used a damage skill even it didn’t deal any damage?

So the question is, when do you check for status? Before the damage, or after the damage? AnetNet chose the latter because the former would be lame.

Sir Vincent III.1286:

So the question is, when do you check for status? Before the damage, or after the damage? AnetNet chose the latter because the former would be lame.

You fail to make an argument as to why “the former would be lame”. If anything…

The current form is the lame one, for the thief because it sets an unpredictable and gameplay flow breaking aspect to any ranged play. However, fixing this wouldn’t necessarily make it harder to play against a thief. It’s a very quality of life change. I know when I see it affect a thief, and I cry for them, secretly, as it gives me 4 seconds of free play time. If you rely on revealed’s clunkiness to stand a chance versus theives at all, you are possibly bad.

With dodging being nerfed to the ground, stealth is to be our best form of defense. It already doesn’t cap points, and it prevents you from dealing any damage with the advantage of being able to do more with a special attack; when you become revealed for no good reason other than “better luck next time, your projectile is slow”, it makes me want to throw my thief away. And if I throw my thief away, I throw the game away. This clunkiness is not necessary.

Please don’t argue in favor of clunkiness. I will hunt you down. With a non-ranged weapon. Because I need my stealth.

I don’t disagree, but I hope they might just replace Revealed with a better mechanic.

Because frankly Revealed is the worst, most frikkle, buggy and frustrating “anti-stealth” mechanic I have ever witnessed.

Thnx for this post, i thougt it was just me and my pistols, now i see is not only me. This is a huge annoynce for me and my pistols when im using ricochet, i mean, i never know how many times a bulled will bounce (if any), so coordinate blinding powder with unload + ricochet is almost imposible at least you stop of shooting for a few seconds or use a stealth skill with casting time like HiS, which interrup all your rotation, is too lame that this issue is happening for so long time and devs are acctively doing nothig to adressed (or saying nothing if it is intended or not and why).

Dee Jay.2460:

I don’t disagree, but I hope they might just replace Revealed with a better mechanic.

Because frankly Revealed is the worst, most frikkle, buggy and frustrating “anti-stealth” mechanic I have ever witnessed.

I would much rather see active anti-stealth counterplay then the Revealed mechanic, but I feel like that is highly unlikely.

Imagi.4561:

Dee Jay.2460:

I don’t disagree, but I hope they might just replace Revealed with a better mechanic.

Because frankly Revealed is the worst, most frikkle, buggy and frustrating “anti-stealth” mechanic I have ever witnessed.

I would much rather see active anti-stealth counterplay then the Revealed mechanic, but I feel like that is highly unlikely.

They’re already starting. Sic’em’s going to reveal. That’ll be 4 things to reveal theives; actual revealed mechanic, ranged attacks (and last refuge, plus instinctual response as a bonus), sic’em and leaving shadow refuge.

Oxygen.5918:

Imagi.4561:

Dee Jay.2460:

I don’t disagree, but I hope they might just replace Revealed with a better mechanic.

Because frankly Revealed is the worst, most frikkle, buggy and frustrating “anti-stealth” mechanic I have ever witnessed.

I would much rather see active anti-stealth counterplay then the Revealed mechanic, but I feel like that is highly unlikely.

They’re already starting. Sic’em’s going to reveal. That’ll be 4 things to reveal theives; actual revealed mechanic, ranged attacks (and last refuge, plus instinctual response as a bonus), sic’em and leaving shadow refuge.

Yes, but those are simply piled on to the existing Revealed mechanic. The additional anti-steath options they are currently instituting make the entire system look and feel patchwork, like no one’s sure exactly how they want stealth to work.

I would prefer they simply remove the Revealed mechanic and rework stealth, but again, that seems unlikely.

Oxygen.5918:

Sir Vincent III.1286:

So the question is, when do you check for status? Before the damage, or after the damage? AnetNet chose the latter because the former would be lame.

You fail to make an argument as to why “the former would be lame”. If anything…

“Do you still want to get debuffed just because you used a damage skill even it didn’t deal any damage?”

Did you answer “yes” to that question?
If you answer “no”, then you agree that it is lame.

The current form is the lame one, for the thief because it sets an unpredictable and gameplay flow breaking aspect to any ranged play. However, fixing this wouldn’t necessarily make it harder to play against a thief. It’s a very quality of life change. I know when I see it affect a thief, and I cry for them, secretly, as it gives me 4 seconds of free play time. If you rely on revealed’s clunkiness to stand a chance versus theives at all, you are possibly bad.

Spare me the patronage. I rather take Revealed when I dealt damage than when I don’t — and that’s what we have now. What? So a blocked or missed backstab will apply revealed? Don’t be ridiculous.

With dodging being nerfed to the ground, stealth is to be our best form of defense. It already doesn’t cap points, and it prevents you from dealing any damage with the advantage of being able to do more with a special attack; when you become revealed for no good reason other than “better luck next time, your projectile is slow”, it makes me want to throw my thief away. And if I throw my thief away, I throw the game away. This clunkiness is not necessary.

The problem is the pathetic shortbow for being crappy — all projectile based skills for that matter. Because of the fact that you can simply strafe to manually dodge the projectile is the problem here. If the projectile skill is released on an obvious hit, that projectile should hit even if they move in the last minute. This way, the projectile can check status on the release rather than waiting if the projectile will hit or not.

The Revealed is working just fine, your solution would only make it worst.

They should fix the projectile’s status check routine instead and fix only that.

Please don’t argue in favor of clunkiness. I will hunt you down. With a non-ranged weapon. Because I need my stealth.

Word.

Sir Vincent III.1286:

Spare me the patronage. I rather take Revealed when I dealt damage than when I don’t — and that’s what we have now. What? So a blocked or missed backstab will apply revealed? Don’t be ridiculous.

This isn’t what I want. * I want attacks made out of stealth to be unable to apply revealed to you, ever, under any circumstance.* This solves the projectile issues, as well as those related to certain traits I won’t name.

Trancid.8514:

+1, this can get crazy with max range cluster bomb, cause it takes forever to land.

This is the exact reason they shouldn’t change how it works. Last thing we need are thieves cbombing while invis. That’d be the new meta. Cbomb+invis+IA, rinse, repeat.

Redscope.6215:

Trancid.8514:

+1, this can get crazy with max range cluster bomb, cause it takes forever to land.

This is the exact reason they shouldn’t change how it works. Last thing we need are thieves cbombing while invis. That’d be the new meta. Cbomb+invis+IA, rinse, repeat.

As fun and destructive as it is to CBombard everyone, I might as well be invisible for all the attention I get while doing it. People are much more keen to focus on the opponents in front of them.

Redscope.6215:

Trancid.8514:

+1, this can get crazy with max range cluster bomb, cause it takes forever to land.

This is the exact reason they shouldn’t change how it works. Last thing we need are thieves cbombing while invis. That’d be the new meta. Cbomb+invis+IA, rinse, repeat.

You’d be right if you didn’t pull the “invis” part out of thin air. Unfortunately for your theory of using 9 initiative’s worth to deal less damage than a single chain of dagger-1 and breaking the rules of “COOLDOWNS”, the game doesn’t work like you think it does.

Oxygen.5918:

Sir Vincent III.1286:

Spare me the patronage. I rather take Revealed when I dealt damage than when I don’t — and that’s what we have now. What? So a blocked or missed backstab will apply revealed? Don’t be ridiculous.

This isn’t what I want. * I want attacks made out of stealth to be unable to apply revealed to you, ever, under any circumstance.* This solves the projectile issues, as well as those related to certain traits I won’t name.

It seems the simply concept of status checking is beyond your comprehension. Yes, that is what you want but how do you implement something like that concerning projectiles?

You will have to create a duplicate of each and every skills (yes, including non-Thieves) and place a switch that swaps a skill when the player is in stealth. To the player, it’s looks like the same skill, but under the hood, there will be a skill without stealth flag and skill with stealth flag. Logically, having two types of every skills is the only way to ensure that Reveal doesn’t trigger on skills with stealth flags.

You only post on what you want, but you have not posted the logic on how it can be implemented.

If you know the solution, then feel free to walk everyone through it using a logical flow.

Sir Vincent III.1286:

It seems the simply concept of status checking is beyond your comprehension. Yes, that is what you want but how do you implement something like that concerning projectiles?

By just doing it.

Sir Vincent III.1286:

You will have to create a duplicate of each and every skills (yes, including non-Thieves) and place a switch that swaps a skill when the player is in stealth. To the player, it’s looks like the same skill, but under the hood, there will be a skill without stealth flag and skill with stealth flag. Logically, having two types of every skills is the only way to ensure that Reveal doesn’t trigger on skills with stealth flags.

Whaaaaat? Guys this is a perfect example on why you should never ask non coders counsel on how to code stuff.

They could also, you know, add code like :

if attacker.IsInStealthed:
projectile.ApplyRevealOnDamage = true

to be frank this is the least of our problem with anet ^^

stof.9341:

Sir Vincent III.1286:

It seems the simply concept of status checking is beyond your comprehension. Yes, that is what you want but how do you implement something like that concerning projectiles?

By just doing it.

Sir Vincent III.1286:

You will have to create a duplicate of each and every skills (yes, including non-Thieves) and place a switch that swaps a skill when the player is in stealth. To the player, it’s looks like the same skill, but under the hood, there will be a skill without stealth flag and skill with stealth flag. Logically, having two types of every skills is the only way to ensure that Reveal doesn’t trigger on skills with stealth flags.

Whaaaaat? Guys this is a perfect example on why you should never ask non coders counsel on how to code stuff.

They could also, you know, add code like :

if attacker.IsInStealthed:
projectile.ApplyRevealOnDamage = true

Non-coder? Your post indeed proved that you are not. You’re “solution” is speaks for how inexperience you are.

Explain to me the logic between the relation of your class “attacker” and “projectile”? The two are not related, the attacker is not the one in flight, the projectile is. The status check happens if the projectile is in stealth, not the attacker, thus a status flag needs to be in place. The cause and effect of your “logic” is flawed because you associate “ApplyRevealedOnDamage” to your projectile, thus your logic suggest that the projectile will be revealed — sigh.

More like;
if projectileStatus.fromStealth = True AND projectileStatus.IsDealtDamage = True:
attacker.IsRevealed = True;

The status check needs to happen on the projectile and the attacker being revealed is just the effect.

Now, Mr. coder, how do you check for projectile status?

Sir Vincent III.1286:

Now, Mr. coder, how do you check for projectile status?

Easy.

Trigger 1:

Event: Attack is launched.

Condition 1: Attack is ranged.
Condition 2: Attack was made out of stealth.
Condition 3: Attacker is stealthed.
Condition 4: Attack meets “hit” conditions. (not blocked, stray, invulnerable… etc.)

Action: Disable trigger 2 for 1 second.

Trigger 2:

Event: Attack is launched.

Condition 1: Attacker is stealthed.
Condition 2: Attack meets “hit” conditions.

Action: Apply revealed to attacker.

Oxygen.5918:

Sir Vincent III.1286:

Now, Mr. coder, how do you check for projectile status?

Easy.

Trigger 1:

Event: Attack is launched.

Condition 1: Attack is ranged.
Condition 2: Attack was made out of stealth.
Condition 3: Attacker is stealthed.
Condition 4: Attack meets “hit” conditions. (not blocked, stray, invulnerable… etc.)

Action: Disable trigger 2 for 1 second.

Trigger 2:

Event: Attack is launched.

Condition 1: Attacker is stealthed.
Condition 2: Attack meets “hit” conditions.

Action: Apply revealed to attacker.

Don’t look now, but your logic just described the current state of the stealth mechanics.

You failed to check for the status of the attacker BEFORE your “event”. Instead, you check for the status AFTER the attack is already made…sounds familiar?

Good job describing the current logic of the stealth mechanics.

Sir Vincent III.1286:

Oxygen.5918:

Sir Vincent III.1286:

Now, Mr. coder, how do you check for projectile status?

Easy.

Trigger 1:

Event: Attack is launched.

Condition 1: Attack is ranged.
Condition 2: Attack was made out of stealth.
Condition 3: Attacker is stealthed.
Condition 4: Attack meets “hit” conditions. (not blocked, stray, invulnerable… etc.)

Action: Disable trigger 2 for 1 second.

Trigger 2:

Event: Attack is launched.

Condition 1: Attacker is stealthed.
Condition 2: Attack meets “hit” conditions.

Action: Apply revealed to attacker.

Don’t look now, but your logic just described the current state of the stealth mechanics.

You failed to check for the status of the attacker BEFORE your “event”. Instead, you check for the status AFTER the attack is already made…sounds familiar?

Good job describing the current logic of the stealth mechanics.

My second trigger describes stealth, yes. The first trigger’s goal is to disable trigger #2 for ranged attacks. I included it for clarity.

>Condition 2: Attack was made out of stealth.

This is my “before” condition. Before stealth. Because unstealthed is the neutral strance, it always comes “before”.

Oxygen.5918:

Sir Vincent III.1286:

Oxygen.5918:

Sir Vincent III.1286:

Now, Mr. coder, how do you check for projectile status?

Easy.

Trigger 1:

Event: Attack is launched.

Condition 1: Attack is ranged.
Condition 2: Attack was made out of stealth.
Condition 3: Attacker is stealthed.
Condition 4: Attack meets “hit” conditions. (not blocked, stray, invulnerable… etc.)

Action: Disable trigger 2 for 1 second.

Trigger 2:

Event: Attack is launched.

Condition 1: Attacker is stealthed.
Condition 2: Attack meets “hit” conditions.

Action: Apply revealed to attacker.

Don’t look now, but your logic just described the current state of the stealth mechanics.

You failed to check for the status of the attacker BEFORE your “event”. Instead, you check for the status AFTER the attack is already made…sounds familiar?

Good job describing the current logic of the stealth mechanics.

My second trigger describes stealth, yes. The first trigger’s goal is to disable trigger #2 for ranged attacks. I included it for clarity.

No, it’s not clear at all since you have the same event (“attack is launched”) triggering both.

You need to check for status of the attacker – stealth or not.
You need to check for status of the attack – ranged or not.

Only then you can have your event of “attack is launched” trigger — meaning you need to set the flags up on your status check before you make the attack. Because when you make a ranged attack, the projectile don’t need to check for the status of the attacker because it’s already flagged and the trigger will use the skill based on the attacker’s flag.

>Condition 2: Attack was made out of stealth.

This is my “before” condition. Before stealth. Because unstealthed is the neutral strance, it always comes “before”.

Sigh. If “unstealthed” is the “neutral stance” (a.k.a. “default” stance, from those who knows programming calls it) then why do you have to check for it? All attack is assumed from out of stealth unless the status flag of the attacker shows that the attacker is in stealth is true. Logically, you only check for the stealth status to be True and not the “out of stealth” status.

Also, it seems that you are not understanding how the logic works. You think it’s simple but you’re not making any sense.

>No, it’s not clear at all since you have the same event (“attack is launched”) triggering both.

You can have one event triggering different actions due to different conditions. How is this hard to understand? Just think of “conditions” as variables that, when not met, lead to the action not occuring.

Sir Vincent III.1286:

Sigh. If “unstealthed” is the “neutral stance” … then why do you have to check for it?

Because attacks made out of stealth are the ones that reveal you undesirably. You therefore need to check for this. Just stop posting in my thread now.

Oxygen.5918:

>No, it’s not clear at all since you have the same event (“attack is launched”) triggering both.

You can have one event triggering different actions due to different conditions. How is this hard to understand? Just think of “conditions” as variables that, when not met, lead to the action not occuring.

Your use of terminology like “conditions as variables” is what making your claim lose credibility.

You can’t even post a comprehensive logical solution and you act as if you know the answer.

Sir Vincent III.1286:

Sigh. If “unstealthed” is the “neutral stance” … then why do you have to check for it?

Because attacks made out of stealth are the ones that reveal you undesirably. You therefore need to check for this.

Having “out of stealth” as the “default” status requires no checking because you know…it’s the default status.

Just stop posting in my thread now.

Gladly.

You claim you have the solution but when it comes down to it, you can’t even make a single logical flow.

Sir Vincent III.1286:

Oxygen.5918:

>No, it’s not clear at all since you have the same event (“attack is launched”) triggering both.

You can have one event triggering different actions due to different conditions. How is this hard to understand? Just think of “conditions” as variables that, when not met, lead to the action not occuring.

Your use of terminology like “conditions as variables” is what making your claim lose credibility.

You can’t even post a comprehensive logical solution and you act as if you know the answer.

You got called out earlier by another poster as a non-coder. I believed it, now I know it. Event/condition/action is a super simple way of explaining triggering: When an event occurs (such as attacking) and conditions are met (such as not being stealthed, and entering stealth within a certain timespan between two more events such as casting and hitting) an action happens (such as disabling another trigger).

Sir Vincent III.1286:

Gladly.

You claim you have the solution but when it comes down to it, you can’t even make a single logical flow.

You are the kind of unenlightened, trolling filth that makes these forums unbearable and ineffective for both anet and actual players. I’ve pooped on every single pathetic attempt at arguments you’ve made and yet you persist on coming back like a beaten wife and opening your dumb facehole when you shouldn’t ever again. YOU DON’T KNOW WHAT YOU’RE TALKING ABOUT AND YOU ARGUE BACK? STOP IT ALREADY.

Here’s a a trigger to help you out the next time you’d like to post:

Event: You post on forums.

Condition: You are “Sir Vincent III”
Condition: You don’t know anything.

Action: Delete your posts.

Oxygen.5918:

Sir Vincent III.1286:

Oxygen.5918:

>No, it’s not clear at all since you have the same event (“attack is launched”) triggering both.

You can have one event triggering different actions due to different conditions. How is this hard to understand? Just think of “conditions” as variables that, when not met, lead to the action not occuring.

Your use of terminology like “conditions as variables” is what making your claim lose credibility.

You can’t even post a comprehensive logical solution and you act as if you know the answer.

You got called out earlier by another poster as a non-coder. I believed it, now I know it. Event/condition/action is a super simple way of explaining triggering: When an event occurs (such as attacking) and conditions are met (such as not being stealthed, and entering stealth within a certain timespan between two more events such as casting and hitting) an action happens (such as disabling another trigger).

Ah yes, check for conditions after the event, which exactly how ArenaNet have their logic is setup. Good job making sense of your solution.

Fixing your logic should appear like this (using your method for your benefit);

Event: player.Stealth = True
Action: projectileStatus.fromStealth = True

Event: player.AttackLaunched = True
Condition: projectileStatus.fromStealth = True
Condition: projectileStatus.IsDealtDamage = True
Action: player.IsRevealed = True

Your trigger solution did not make any sense at all.

You are the kind of unenlightened, trolling filth that makes these forums unbearable and ineffective for both anet and actual players. I’ve pooped on every single pathetic attempt at arguments you’ve made and yet you persist on coming back like a beaten wife and opening your dumb facehole when you shouldn’t ever again. YOU DON’T KNOW WHAT YOU’RE TALKING ABOUT AND YOU ARGUE BACK? STOP IT ALREADY.

Here’s a a trigger to help you out the next time you’d like to post:

Event: You post on forums.

Condition: You are “Sir Vincent III”
Condition: You don’t know anything.

Action: Delete your posts.

That’s all you got? Typical.

There sure are a lot of people here who’ve apparently never had to maintain someone else’s spaghetti kludges. And by a lot, I mean one.