ZEUStiger.3590

Great change, keep it this way. Patch notes are much more readable, and they are the only reason to visit the forums. I hate oversized fonts and thick UI with 90% empty screen real estate that have become so prevalent on the web in the last decade. If you have bad eyesight or fat fingers - zoom and DPI scaling are there for you. Pack as much info as possible on my screen, please.

There is an issue with the current "skills_by_palette" specific to Revenants, which is making it impossible to determine which utility skill corresponds to which skill palette.

Revenants are a unique beast in that they use the same skill palettes for every legend: 4572 for heal, 4614/4651/4564 for utilities, 4554 for elite. Healing skills of all legends belong to the same 4572 palette, for example. 27220 is Glint's heal, 26937 is Shiro's heal, 27372 is Jallis's heal, yet they all have the same palette entry - 4572. However, the way /professions/:id "skills_by_palette" field is designed, it only allows many(palettes)-to-one(skill) linkage (i.e. you can find cases like `[ 4492, 55029 ], [4570, 55029], [4592, 55029], [4643, 55029]`), but for this particular case we need one(palette)-to-many(skills) linkage which is currently not supported.

Without this it's impossible to create a full-fledged build template editor relying solely on data from the API. Currently only Kalla's skills have palettes assigned to them in /professions/:id.

I see two possible solutions.

1. Allow one-to-many scenarios in /professions/:id "skills_by_palette" field, e.g. something like `[ 4572, 26937, 27220, 27372, 28219, 28427, 45686 ]`. This way, by combining the data from this field with the data from /legends/:id, one could determine which legend the skill belong to, and which palette refers to it under that legend.

2. Add a similar many-to-one (although in practice in most cases it's one-to-one) "skills_by_palette" to /legends/:id endpoint, that will define which skills belong to which palettes for that specific legend alone, foregoing the need to have arrays with more than 2 elements.

Subject, nothing else to add. Skyscale chair cannot be used while in Hall of Chains or Mythwright Gambit, which typically allow the use of mounts and thus other chairs. Please flag it appropriately, and perhaps do a pass on all the other chairs to ensure all are flagged for use in raids.

Sigh, we really are going here, aren't we... But of course there will be blind deniers who would try to explain everything with something else. Why would I ever expect otherwise.

> @"Leablo.2651" said:

> That is not really an applied effect as much as it is the definition of motion blur. You have not isolated the blur in your screenshot as anything that is actually unique to that sequence. It is observable throughout the video.

I said

> That's the classic "we're going at a high speed!" kind of motion blur most commonly employed by racing games.

to differentiate it from other appearances of motion blur which in modern games are more often seen as a lateral blur caused by the rotation of camera:



I pointed that out specifically for the naysayers like you who would complain that the provided screenshot doesn't contain any blur that resembles the one seen in these two examples.

> @"Leablo.2651" said:

> Further inspection of the source video reveals that it is exceptionally blurry to start with. The stream was encoded at 1080p but the quality looks worse than 720. It's possible that this results from their production process and a pre-stream compression being applied to the game footage, or a lower resolution capture being fed to the stream encoder. Compare it with any other GW2 stream on Twitch, which are much higher quality. Oh yeah, and it's 30 fps. You are almost certainly mistaking compression artifacts for in-game effects.

That **is** a motion blur, not stream compression. Videos don't get compressed using polar coordinates, the blur you see on the screenshot is very obviously originating from a single point on the screen (or, rather, off the screen - judging from blur direction the point is somewhere above the image) and is being blurred outwards, the further away from the point - the more blurry it is. I drew arrows on the screenshot to specifically point that out. If you can't see it - I'm sorry, but you need to wipe your glasses or obtain a pair.

Moreover, neither the UI nor the stream overlay exhibits the same blurriness, and you can't see it being any less or more blurry near the intersections of game viewport and UI/overlay, which means that either blocks of pixels that get compressed happened to perfectly match the boundary of the UI and overlay (which is impossibly because it's not all rectangular in shape), or the blur is not an artifact of the compression but is in fact an in-game effect.

Also please do re-watch the segment of the video around the indicated timestamp. You can pause the video and use [,] and [.] keys to step through it frame by frame. You will notice that the blur kicks in instantly: one frame has none of motion blur, the next has it in full effect.

Here is the frame right before motion blur kicks in:


And here is the very next frame with motion blur in full strength:


Open them up in two tabs and switch back-and-forth if you **still** can't see it.

Furthermore, you can see a bug with the implementation: for whatever reason enemies remain not blurred, only the terrain is blurred. You can try to explain this by saying enemy models have more detail than the terrain and hence will be less compressed, but I want to point out this one artifact on the screenshots from above:

Frame before motion blur:


Frame after motion blur:


What's that? The crab gets a trail behind it! Video compression can't do that! It would require compression to distinguish between separate layers of rendered geometry and only compress the composited layer that the less-compressed crab model is then overlayed on top of. But it is something that can happen during rendering: if the motion blur shader was applied on the final composited image, then even non-blurred objects will bleed into blurred areas because there is no information about what's behind the non-blurred object, example:


> @"Dawdler.8521" said:

> For starters, motion blur is a scourge for gaming that deserves to be burned out with lots and lots of fire.

It sure is, I tend to disable it as soon as I first see it, but that doesn't negate the fact that the option is still present in the client and does nothing, hence - a bug.

When Joel on the video starts to descent on a griffon, you can see the screen getting increasingly blurred towards the edges. That's the classic "we're going at a high speed!" kind of motion blur most commonly employed by racing games.


I believe this is the only moment in the stream where someone moves fast enough for motion blur to kick in.

Example of a more exaggerated effect so you know what to look for in the image above if you **still** can't see it:


"Motion Blur" slider has been present in Graphics options for what will soon be 2 years, and yet it has never worked during all that time.

Here at 50:46 mark we finally saw it working for the first time, on what I presume are dev clients.

Perhaps it's time to finally push it to live clients as well? Or remove the slider altogether to stop misinforming players and causing placebo effects.

Here's a more-or-less reliable way to reproduce the bug (and a display of one of the exploits it allows):

1. Find an almost-vertical surface (not completely vertical, but sloped enough for you to slide down off it, but not horizontal enough to stand on it).

2. Start somewhat above it, so you don't immediately touch the ground after dodging.

3. Start holding W and keep holding it throughout.

4. Dodge into the surface.

5. Spam 1

Better yet, you can dodge even when you're outright DEAD. You can get inside enemy spawns without getting teleported out this way. This is just wonderful. :lol:

Hope this gets fixed within a reasonable timeframe. For now the only sure way to get rid of the bug is to leave the map, which, as one can imagine, is rather undesirable due to long queues. And playing with the bug, while technically possible, might get you reported for cheating due to all these dodges that to other players most certainly look as if you're teleporting around.

A similar bug has been happening all the way since PoF release (probably beta too), but the other way around: player remains with mount skills while not visually mounted, most likely due to desync issues in "content functions" aka clientside scripting toolset (the higher the latency, the higher the chance to encounter the bug, hence the suspicion of desynching). That bug, however, tends to autocorrect itself after a few seconds, removing the mounted skills from you if you remain dismounted. Perhaps something similar can be done to rectify the consequences of this bug as well.

The bug can happen in PvE as well, I can tell you that for a fact, but I can't figure out how to reproduce it reliably. It has something to do with spamming [1] while dodging (i.e. using warclaw's dash ability). You don't need to hit an enemy for it to happen.

With the Halloween patch, Mursaat Overseer started behaving much better, although still not perfect, but the issue can more-or-less be considered resolved for that particular boss.

But it's still happening to the full extent with Soldiers on that very encounter (Soldiers are Scouts that reached the end of their path) - unless the entire raid comes to meet them on the tile they're in, they will waltz all around the middle, lighting up all 4 central tiles, as they walk on them one by one. The raid might be stacked on them for a long time already, but they will still pick odd positions to go to, making a circle around the middle.

And the issue is still present at Vale Guardian, as depicted in my previous post.

Two more examples. Sadly I couldn't capture the exact situation described in my first post, because the last phase of the encounter was very messy for us today.

The tank has a "Call Target" mark above her head. Instead of running directly to the tank, the boss decides to take a short walk in a tangental direction.

A video depicting an example of the issue. Open it on YouTube, there are timestamps in the description with (almost) every moment the weirdness occurs.

This happens during literally every attempt at the boss.

Also, I cannot stress this enough, this happens to ALMOST ALL the bosses, even regular creatures. This is not an isolated case.

Ever since Living World Season 3 Episode 6 release (more precisely, I believe, after this hotfix: https://forum-en.guildwars2.com/forum/info/updates/Game-Update-Notes-July-25-2017/6659115 (it even mentions "Fixed several pathing issues.")) many if not all creatures have been exhibiting horrible pathfinding issues. Two distinct problems can be identified:

- Creatures tend to run away from their tank, walk for a bit and then return to the tank. The problem is best reproducible on flat terrain. If I were to assume that GW2's pathfinding uses **navmeshes**, I would hazard a guess that pathfinding **now prefers polygon corners** almost exclusively over finding the shortest possible path across polygon edges.

- Creatures shift in place a lot when their tank attempt to circle around them when very close in melee range, as if they are trying to **predict his movements** and react beforehand, but immediately give up and stop, slightly away from where they were before. This sometimes results in them visible running away from you in the direction you want to circle them around, and sometimes causes them to straight up teleport in that direction 1 ft at a time. This problem was somewhat present even before the update, but with the update has become more common.

The problem is most noticeable in raids, but can occur fairly frequently in open world as well:

- W1 Vale Guardian, when kited around the middle of the platform (not too far from the middle), tends to return to the exact center of the platform each time when we want him to move to a different segment (i.e. red, green, blue thirds of the platform).

- W2 Slothasor can often take weird turns and scenic routes when following the fixated target.

- W4 Mursaat Overseer can decide to walk almost half the playing field away before returning back to tank. Pretty much every attempt we make the boss moves half a tile away from us (towards scouts' spawn positions) and then returns back. Over the course of the encounter he might walk one tile right (towards the entrance) and back, or 1-1.5 tiles backwards (away from the scouts' spawn positions) and return back to tank.

Needless to say these issues are infuriating. They were introduced along with a vague "Fixed several pathing issues" change, and that change ended up wrecking more than it managed to fix (what was it even attempting to fix? I don't recall any pathing issues in the new map at that time). This is NOT a toughness issue, there are **no** players around the spots bosses decide to visit every once in a while. They just pick that spot as a mid-point of their path while following the tank, instead of just taking one step towards the tank, which would've been enough to stay in melee range.

I haven't reported this earlier, thinking that it would be fixed with PoF release, seeing how this issue is very obvious and impactful on the gameplay, and it surprises me that nobody has reported it before. Please reexamine the changes that were part of that hotfix and take appropriate measures, full revert would even be better than the semi-broken pathing we currently have.

I can attempt to record a video depicting these issues, if you will be unable to reproduce them yourselves.

_Apologies for a, perhaps, convoluted and messy post, I'm very tired, but decided to finally report this before I forget._