Tyrian Mollusk.1563

I enjoyed Fire for Effect, because I enjoy getting and using the stolen skills much more than the longer malice stacking. It's so wrong to just completely gut the stolen skills system if we take that one trait-- a trait that isn't even the quickness GM trait! We should be safe from quickness ruining other things, but instead there are not just two of thee traits dedicated to quickness but FFE reaches into the entire stolen skill system and rips away anything else. Not to mention ruining One in the Chamber the same way until that bug gets fixed. I don't want to be quickness provider on my deadeye, and that option should not come by just ruining things the rest of us enjoy. If this has to be done, obviously put it where it belongs in the quickness GM trait. That's for the quickness people. Don't only TAKE AWAY from non-quickness people.

I hate it because I don't want to be gutted into a quickness provider and the price of quickness came out of fire for effect, which I was enjoying like I enjoy using my VARIOUS stolen skills. They also managed to ruin one in the chamber, at least until it gets fixed (it always gets Time even without FFE). I should be safe from quickness by not taking Be Quick or Be Killed, the GM trait already dedicated to quickness. I used both FFE and OitC. Pretty much ruined what I was enjoying doing.

Jeez, as if absolutely murdering Fire For Effect for the rest of us wasn't enough, you ruined One in the Chamber too?

Why, Anet? Why? This innocuous trait is just consolation to allow us to enjoy making burning part of a few tragically burnless weapons like hammers and shields. Useless to many, but lynchpin to some, because it brought in weapon options and let us enjoy them. There should be more things like this, to let us actually use weapons we enjoy with our builds instead of always forcing us into a very few weapons. Now it's just another generic, boring boon source with nothing firebrand about it. This feels like it negatively targets exactly the people who enjoyed the trait as it was, for no gain, and a knife in the back to something that had no need to be punished. I can't believe those of us with hammers and shields were needing to be held down and get our builds gutted like this. Let us burn.

Throwing four things in is a "recipe", inasmuch as the forge has recipes. You're welcome to try more combinations, but it doesn't look like mystic forge counts as "crafting".

People with crafting professions can just craft something and unlock the next volume, even though the game brokenly doesn't count their existing profession (why ever that's a thing...). The issue here is characters that are NOT crafters being forced to take a crafting profession they will never actually use and should not actually use, just because the vol 2 guide has three crafting achievements instead of the two it should have. Accounts don't need or want more than one crafter of each profession, and extras just clutter things and make it harder to find the real crafter. Guide volumes 3-6 should not just be locked to characters unless they take a craft profession they don't want.

That wouldn't be a terrible solution, but no, I did try that, and it doesn't count as crafting.

You can advance past the Character Adventure Guide volumes without needing two of the achievements, but volume 2 includes THREE entries requiring crafting. This leaves non-crafting characters locked out of higher volumes unless they permanently take a false crafting profession that they should not have. It's wrong to lock characters out of guide progress unless they craft, because most characters should NOT be crafting, and we should not have to clutter and confuse our displays with false, useless crafting disciplines we can never get rid of. The guide should not lead new players to mistakenly take crafting they have no cause to take or advance, making it harder to find the "real" crafters when they want them. Please remove one of the three achievements, or better yet, let us remove, switch off, or hide crafting disciplines for a character. Having the guide achievements force us to craft or get locked out of most of the guide just draws attention to your strange refusal to let us remove a crafting contract we don't want on a character. Especially since you already have the ability to retain our crafting level for inactive crafting disciplines. Why keep refusing us this simple option people have requested for years, and even make it worse by now forcing non-crafting characters to show up as crafters, or lose access to the Guide bonus? Either way, non-crafters should not be locked out of the guide and players should not be pushed to select crafting professions on non-crafters. There's no need for three crafting achievements in V.2, and it's clearly redundant to have selecting a profession on top of crafting something and leveling crafting, which both require selecting a crafting profession already.

What I'm talking about is an easy task. This is just a Steam setup issue for what it uses when someone tries a controller. If a dev doesn't bother to set things, Steam uses a default config that's semi-broken. Better to set the default to something that won't look like it is supposed to work (the gamepad template, for example, would make controller simply ignored), pick a functional community config, or just have Steam grab the highest rated community shared profile. None of these require Anet to understand or work on controller support, which I don't expect they'll do. Anet not supporting controllers is their intention, not a bug, but letting Steam substitute a half-broken configuration because it isn't set up correctly is a bug.

When you start a Steam game that has no controller support, Steam automatically applies a Steam Input configuration if it finds a connected controller. If the developer does not set a recommended configuration, Steam uses a very simple default template made for some common FPS games, and this will give users a poor impression, because it usually does something but it doesn't actually work. For GW2, it will let someone walk around, move the moue, click with left trigger, interact with Y, use 1-4 from the dpad, jump with A, and basically just not make much sense and play awfully. Many Steam users don't even realize this is how Steam handles games without controller support. I know you choose to leave the controller market ignored and are against supporting controllers, but there are some good controller configurations for playing GW2 (I know, I have hundreds of hours playing GW2 on controller--and just a 360 controller, not a fancy touchpad or gyro controller). I'm not asking you to support controllers, but if you simply set Steam to use something reasonable as the recommended default, someone using one when they try the game will have a better experience. It's how Steam Input is meant to be used by developers who don't want to spend effort supporting controllers: let players do the work, and you just set a default that makes sense and keep on doing your non-controller thing. Basically, the current default is broken, and there's no downside to setting Steam to use a better one. You could even just set Steam to use the standard 'gamepad' template instead of the 'WASD+Mouse' template, which will make it so a controller does nothing by default. At least 'nothing' is working as expected, instead of a broken half-config.

And just a bizarre and cruel way to even consider addressing the problem. So there are special cases where its multiplier gets "too big"... You limit the multiplier to address the special case, not just gut the base so it's way worse in every case.

Many players don't realize how different things are for new players. Before you're optimized and geared, it's very easy to find that the time it takes killing enemies is practically enough for the enemies you started fighting to respawn on you. It's not like you clear a mob and then it waits and respawns the mob. As far as enemies just on the map (rather than driven by some event), you remove enemies one by one and every one is ticking away towards respawn. Take longer on something, and everything is that much closer to respawn. Basically, never stand where there were enemies. Fight, then leave. If there were (or are) enemies, it's not safe to do anything unless you want to be back in combat. Find an enemy-free spot and do your things there. Also, higher level areas tend to have a lot less enemy-free space to hang about, and events can easily flip safe space (even waypoints) to sudden conflict. As far as aggro, I'm glad enemies aggro more loosely. The "trinity" has always been a ridiculously absurd gaming crutch that should never have been foisted on gamers. If you're in a fight with an enemy, you may have to deal with that enemy. Don't try to shoehorn some gimmicky nonsense to protect you from that, and just deal with it. Active defense is a key aspect of the game, and hiding from aggro isn't needed and doesn't belong.

I don't know how add-ons work, but Steam Input just fakes keyboard and mouse inputs. It doesn't know anything about the program it's sending them to or expect the program to know anything about it. I wouldn't think add-ons would matter there, unless they do something that interferes with the Steam overlay, since I think Steam Input needs that functioning for some reason. If add-ons use a similar mechanism to put radial menus in front of the game (if that's even what it does--I just know Steam Input uses the overlay to do radial menus), they might conflict. You should be able to just try it with some random Steam Input config, and see if they interfere with each other. You don't need to be able to to do the whole game and match all the keybinds just to see if they work together, after all. A little walking and camera/aiming, interspersed with trying your add-ons and whatnot should make that obvious. You can also pick a button and have Steam Input's configuration tool set it to whatever brings up your mount menu, and see if they directly work together, if you hope to control your add-ons while on controller (you can also set Steam Input to do its own radial menus for things, although don't hope you can run emotes from that, since they require complicated action sequences to finesse out of Steam Input's janky typing handling).

Why ever would that be an issue? 1 button 1 input is exactly how it works. Shift-ctrl-z is one input. People have already been playing on controller for years this way, since it's the only way that makes sense. I could recode my config to use a keymapping where there were no key combinations and it would work and play exactly the same as it does now. All that would do is inconvenience people by making them set a bunch of weird keybindings just to try it, and not be able to switch back and forth with kbm.

Like I said, there's zero reason you would need to remap anything back and forth. You just take your existing GW2 keybinds and edit the controller configuration you want to use so your existing keybinds are what it sends to the game. No, you don't have the right model for how it works. The controller does not just map one button to one key. I mean, of course it could do that, but that would play awfully for most any nontrivial game. You map one input action to whatever set of keys you want, and an input action can be a simple button press or various other things (eg, a double tap or a press held for a certain duration). Just like a keyboard, you can do much more using button combinations and shift sets. My configuration, for example, uses two shift sets for main play (which makes for three button-to-key-combo mappings, counting the unshifted buttons), another set for popping open various panels (eg, map, inventory, etc), and a fourth for mousing (I rarely use that because we are trackball users anyway, and those are easy to use on the couch, but it works fine). All those are while-held shifts, but that isn't the only option. So for example, if I want to hop on my raptor, I hold LT and tap right on the dpad. If I hold dpad-right, it'll pop the beetle instead. I have each of those input actions set to send the key combinations configured in GW2's settings (here, shift-x and shift-ctrl-x). Someone who wanted different keyboard mappings than I use could just go into Steam Input's controller configuration and change the outputs so that it sends whatever they use for raptor and beetle, while not needing to mess with the structure of the configuration.