Jademalo.3724

When setting the "-fps" command line argument, the value set is only used during loading screens. For example, if I set "-fps 40" as my launch argument, the character select screen will run at ~110fps, the loading screen will run at 40fps, and ingame will run at ~45fps. I would expect all 3 of these to run at a limited 40fps, but clearly the only place the fps limiter is active is during the loading screen. This seems like a fairly simple fix, and would be extremely useful for limiting to 40fps on the Steam Deck to take advantage of the 40hz mode.

I've got a fairly decent knowledge of these systems, especially when it comes to the steam deck. The Gamescope compositor that the Deck uses actually has a built in VSync, so tearing isn't actually even possible on there. However this VSync implementation doesn't restrict the framerate of the game running beneath, so another method has to be used. A frame limiter absolutely does not result in stuttering. If the game takes longer to render a frame than the refresh rate cycles, then there will be stuttering. In addition, if the game is drawing substantially more frames, you end up with skipped frames which can sometimes reduce the smoothness. In fact, if there's enough of an overhead such that each frame can comfortably be drawn within each refresh cycle (in this case 40hz/25ms), it can reduce stuttering and improve overall frame pacing. While ingame VSync in GW2 does limit the framerate to the refresh of the display, it also introduces substantial input lag due to its buffer structure, whereas the ingame limiter does not. Since the compositor is already VSyncing, substantial gains in input latency can be made if the ingame limiter is used instead without any tearing issues. In addition, tearing is sometimes preferable to VSync when you're more concerned about input latency. VSync naturally means that after a frame is drawn by the game there's a period of wait before it gets displayed, which increases input lag. A frame limiter is not VSync, and there are benefits and tradeoffs for either method. For the steam deck, an ingame limiter is vastly preferrable to VSync. I have tested this myself at 60hz with the 30fps limiter vs VSync, though substantial gains could be made if you could limit to 40 instead, hence the suggestion. This is incorrect, and is possible to both test and feel, especially comparing to other games that have responsive cameras. This isn't just an issue with Linux or the Steam Deck, this is actually even more pronounced with just a basic mouse and keyboard on Windows. All 3 of your examples are absolutely not the cause, and doing exactly the same actions on windows results in exactly the same issues. The default setup for the deck also doesn't even have any native mouse acceleration, which if anything is an improvement on windows requiring it to be disabled manually. I'm also not describing acceleration here in terms of inconsistent movement ingame for a given distance of the mouse depending on the speed, I'm describing acceleration as the smoothing of the camera when it speeds up or slows down. This is exactly what I'm talking about, and absolutely does apply to action camera. Whip the mouse round 180 degrees and you can see just how many intermediate frames there are before the camera comes to a complete stop, even in action camera. It's slightly less pronounced in Action Camera, but it's undoubtedly still there. What I'm asking for is an option to remove that effect entirely, from both RMB hold camera and action camera. It's absolutely the number one culprit for the camera feeling sluggish, and should absolutely be an option to turn off.

I've been playing a lot of the game on the Steam Deck since I got mine, and honestly it's a pretty great experience as is. However, there are a few small tweaks that could be made that would substantially improve the experience hopefully without too much effort. tl;dr - - Add an option to the frame limiter to limit to Monitor Refresh Rate like Guild Wars 1 - Add two more keybinds to discretely Enable and Disable the Action Camera - Add an option to remove the forced smoothing of camera motion in both regular and Action Camera Frame Limiting The first is to do with frame limiting. Guild Wars 1 had three options; 30, 60, and Monitor Refresh Rate. However, Guild Wars 2 doesn't have the third option, and instead only has 30 and 60. One of the best features of the Steam Deck is the ability to limit the refresh rate of the display from anywhere between 40Hz and 60Hz, allowing for a much smoother experience in terms of frametime if you can't quite hit the 60fps target. Guild Wars 2 feels best to play at 40Hz since it's hard to maintain a stable 60fps on the deck but fairly easy to maintain a stable 40fps. However, since the ingame frame limiter can only be set to 30 or 60, there's no way to lock it at 40 without incurring a huge amount of input latency through either VSync or the Steam Deck's built in frame limiter. This means that the game is rendering a lot of frames it doesn't need to, wasting battery life and resulting in an inconsistent frame pacing and a less smooth experience. Considering modern monitors also have a huge variety of different refresh rates, this option would be extremely useful generally. The weirdest thing to me is that it clearly existed in Guild Wars 1, and due to that GW1 runs extremely well on the deck. I'm surprised it's not an option for GW2! Action Camera Keybinds Currently, there are two keybinds for the action camera; Toggle Action Camera, and Disable Action Camera. The first swaps the state between standard and Action Camera, and the second is a hold toggle that disables action camera temporarily while it's being held, which means it has a slightly misleading name. Hold Disable Action Camera is probably clearer. It would be much easier to create keybinding sets based around Action Camera if there were keybinds available specifically to Enable and Disable Action Camera regardless of the current state. As it is now, it's not possible for the binding setup to be sure which state you're actually in, since all it can do is toggle. If a bind didn't go through due to a loading screen or something similar, the state of the keybind set can become desynced from the actual current action camera state, and toggling would continue to have things be desynced. Having discrete keybinds to enable and disable the action camera would allow for bindings to never desync, since the keybind set could always make sure to return the game state to the correct mode. Camera Acceleration and Deceleration This suggestion is probably a lot more work than the above two, but I feel it's worth mentioning as this could also have huge benefits in terms of game feel to Desktop users, not just deck users. Currently, the camera in game does not move 1:1 with the movement and speed of the mouse. When you start to move the mouse there is a small period of acceleration, and when you stop there is a small period of deceleration. This makes the camera input look smoother, but results in the camera feeling "floaty", unresponsive, and sluggish, especially at lower framerates. This is noticeable in action camera, since it makes precise aiming quite difficult due to the camera and crosshair not responding exactly to your mouse movements, and It's especially noticeable if you whip the camera around quickly. It's also extremely appearent when using gyro aiming, as the micro movements of the gyro get smoothed out and feel very disconnected from your actual input. Ideally, I would like to see an option to disable this behavior, and have the camera move 1:1 with the movement and speed of the mouse. This would make aiming with Action Camera much easier, and also generally make the camera feel a lot more responsive for the player should they choose, especially at lower framerates. This is one thing I've noticed about GW2's camera compared to a lot of other games, and is the main reason the game can sometimes feel a bit sluggish, regardless of framerate. EDIT: For some clarification here - I'm not talking about acceleration in the sense of mouse acceleration where faster movements will move the camera further, I'm talking about acceleration of the camera movement such that it smooths out your inputs by slowly ramping up and down the camera speed. Hopefully these aren't too huge asks, as they would really be great improvements not just to players on the deck, but also controller users generally. The third suggestion would also be a huge benefit to desktop players, especially those using Action Camera. Hopefully this gets seen by someone, ty!

Good to hear these changes - As someone who's vocally been against the current nature of the tail, it's good to see that feedback is being heard and at least partially addressed. I'm all for hard content, but it's imperative that difficulty is fair. The boss I fight and the challenge I'm presented should be the same as the boss any other player in the game fights, and the difference between winning and losing should be entirely down to player ability and coordination. The irony is, most structured bosses have been designed this way from the start, with consistency being a core part of them. It's difficult to truly learn and improve if what's required of you changes from attempt to attempt. I'd personally still like to see at the very least the tail and breakbar be consistent from fight to fight, without any randomness at all. One tail per phase with two on the final phase would be a good place to start imo, potentially with the breakbar being a direct response to destroying the tail. That seems thematically appropriate, and would also reward quick and coordinated movement back to the boss after killing the tail. I'm not saying to reduce the difficulty here and it should be tweaked accordingly, but a loss should be down to dps and coordination 100% of the time.

Having this same issue too. Works absolutely fine under DX9, but the UI isn't constrained on DX11.

https://i.redd.it/yyhudwzuozk81.png The metallic parts on this character's armour should all be shiny white, but they're clearly pretty red/orange. If you look very carefully on some pieces of the armour, you can see a mountain and sun reflecting. I've got a feeling this is the reflection map and lighting from the old login screen, which is why characters with certain reflective materials look out of place.

The issue isn't raw DPS, it's that some runs can have an abundance of tail phases or side swaps where you literally cannot damage her. If this happens a lot, the numbers in arc will naturally be lower. You could easily kill the boss with ~8k dps to her face if she didn't constantly swap sides or require multiple tail kills.

I am extremely disappointed to see these as the proposed changes. I've run the meta in the high double digits now, 4 times with fully meta groups communicating over discord, and 6 other times without mechanical or execution issues within the group. The reason we failed those attempts had nothing to do with a lack of coordination or damage, and has absolutely not been addressed with the proposed changes. The core issue is the massive amount of variance between attack patterns she can give. The issue isn't the dps players are contributing, the issue is the time you have available where you can actively damage her to make progress on the fight. If she decides to spam swaps or tails, no matter how good your dps is you're still not going to have enough active dps time to actually kill her. I've had runs with 9+ total tails without a single breakbar, and multiple where the breakbar has come so late she phases before it can be used. With the proposed changes, a breakbar is a guaranteed instant phase. Instead of lowering the rng elements of the fight and promoting coordination and skill, we've now got a situation where it's even swingier - where you can get lucky with an early phase breakbar and basically just skip a phase. If you watch MightyTeapot's kill video which many cite as evidence she isn't that bad, you can see that they had 3 breakbars, 5 swaps, and one tail phase that was so late into a damage phase it could be ignored. This isn't average luck, this is exceptional luck. The changes to the green phase are at least a step in the right direction, but since raw dps really isn't the issue, giving everyone a temporary dps buff solves a problem that doesn't really exist. There needs to be a more consistent rhythm to the abilities. It doesn't matter if that's achieved with tail phases being set to specific health breakpoints or if there are internal cooldowns on certain fight lengthening abilities, the fact that you can either have it handed on a silver platter with breakbars early or have it be borderline unwinnable with a chain of back to back swaps and tail phases isn't fun design that promotes coordination and good play.

Hmm, simply moving the shortcuts to the start menu folder didn't work for me. Changing the target did though, that's a good tip. Thanks for that. Also I've realised that my old solution is different to your suggestion in your other post, that's definitely a more elegant way of doing it. I appreciate the info! (Though it still would be nice to have a built in arg to do this) EDIT: Also for future reference for anyone else reading this, there's a slight mistake here - the shortcut has to be (cmd.exe /c "Gw2-64.bat" -1). The argument needs to be outside the quotes

This is what I'm currently doing, however it has a few downsides. Pointing a shortcut to a bat file causes some weird interactions with windows, such as not being able to pin it to the start menu or the taskbar. In addition, If the pc crashes or loses power, the original local.dat isn't correctly restored which can potentially cause issues. It would be much nicer to have a proper, functional, directly supported method to do this rather than using hacky workarounds.

I have multiple accounts, and switching between them is fairly inconvenient. In the past there were command line arguments to switch accounts using a shortcut, but this was deprecated for security reasons, understandably as plaintext emails and passwords would be in the shortcut. My current approach for alt accounts is a batch script that backs up and replaces the Local.dat before launching the game, and then restores my primary account's Local.dat. This works, but is a rather inelegant solution. Would it be possible to get a "-local" argument that allows you to specify the location of Local.dat in a similar manner to the current "-dat" flag? This would allow for a folder of different profile files for each different login that could be accessed quickly with shortcuts, without the issues of the batch file method and without the security problems of the old launcher arguments. Thanks!