Several "acknowledged" bugs (or surprise mechanics) from over a month ago in the first beta phase are still in the game

Hello, it’s me. You may know me from such rants as the Back to Bögenhafen thread, Twitch Mode Improvements thread, the popular “Can we get rid of +20% health and +33% curse resistance already?” thread, or my most recent “Let’s fix the crafting system to be kinda like Weaves” thread.

You may know me, unless you work at Fatshark, because I have very little evidence that they have read a single one of my many suggestions and bug reports.

  1. The Bounty Hunter talent ‘Just Reward’ does not play well with potions. This was reported as a bug with an alternative talent suggestion because it was a really poorly thought-out talent. I no longer have access to that beta thread because Fatshark deleted the beta forum. However, it was “acknowledged” by someone at Fatshark. Here are two videos (video 1 and video 2) showcasing the bug from 7/4/2019

  2. The Waystalker talent ‘Piercing Shot’ throws off your aim. Here’s a link to a post by /u/SmurfSnase. I cross-posted it to the beta forums, as you can see in the comment thread. It was acknowledged by Fatshark, since he did not have access to the beta forum. It makes a skillshot talent stupid because you have to compensate weirdly for the shot going down and to the right.

  3. The throwing axes do not play well with Trophy Hunter. I didn’t make a video about this because I’m already fuming about the other two. It previously granted no damage buff to the throwing axes. It does now, but “High Tally” somehow loops back and makes the damage lower, even if you have an extra 1 stack.

That’s all I have to say. These discoveries have completely disabused any notions of mine that time and care is taken to read and address feedback. This is the shortest post because it’s my last one of its kind. Fatshark doesn’t care about good ideas or your feedback, as far as I can tell. I won’t write another post like this, because it clearly doesn’t have any effect.

Thanks for reading, Fatshark.


Here’s a link to the reddit thread addressing these surprise mechanics:

I must stress that acknowledgement means the report has entered our database and has been assigned to a developer or QA; it does not necessarily promise change. It’s then up to the developer or QA to decide how to proceed.

I’ve looked up the reported issue with Bounty Hunter’s ‘Just Reward’ Talent in our database and can see that it was marked as working as intended. Whether this was an oversight or intentional, I do not know. I have however queried this with the developer and asked for reconsideration.

The issue with Waystalker’s ‘Piercing Shot’ Talent was marked as resolved. I’m making the assumption that the applied change has not worked as expected, which does happen, so I’ve re-opened the issue.

As for the Trophy Hunter/Throwing Axes conflict, I’ve raised this with development.


I feel as though this is a misuse of the word in this context, then.

Acknowledge, to me, means “accept or admit the existence or truth of” or “recognize the fact or importance or quality of”.

To me, “acknowledged” reads as a recognition and endorsement of the bug report as valid. It means that there is sufficient evidence of the issue to create a bug-fix ticket in Jira or whatever ticket management software is used.

In this context, it seems like it is being used as an “investigating” state where work and research is being done to resolve the issue and also as a resolution state for the ticket. This seems like a poor workflow where a ticket becomes lost into the ether with no apparent resolution to the customer.

I would suggest adding some states of some kind to communicate further on an issue.

  1. Open - We currently have this by virtue of being a ticket with no state assigned to it. We need an intermediate version of this state to indicate that work is not actively happening on the issue, if some blocker is found and the ticket gets shoved on to the backlog. An “OPEN” state might communicate this sufficiently. In a lot of ticketing systems, an alert is sent to relevant people (ie: product owners) if a ticket has been in an “OPEN” state for an unreasonably long time.

  2. Closed - A final state to reach resolution of an issue by any means. Maybe the user resolves their own issue or some agreement comes that it truly isn’t a bug.

  3. In Progress - A state to indicate that work is actively being done to address the issue. It is assigned to someone and it is currently within their current sprint’s goals (or a very near future sprint, if in between sprints)

  4. Resolved - Do NOT let a ticket become resolved without an explanation being attached to it. If you “do not know” why it was marked as a resolved issue, that is a major workflow error. You need to hold someone accountable for their work and they need to be able to point to it and say “yes, that is what happened”. Getting a bug report is kinda bad. Getting the same bug report one month later by the same customer who is livid about it is on a whole other level of bad, especially if it becomes apparent that it was dismissed as “not a bug” internally, but not communicated to the customer.

    • Mark it as “not doing” if the bug is not reproducible or it’s determined that it was some weird user situation that isn’t within scope like “my cat spilled coffee on my computer and two files got corrupted within the game randomly”

    • Mark it as “fixed in upcoming X.Y.Z patch” when it gets merged into the release branch. Communicate to the customer that the issue is resolved in an upcoming release and to expect final resolution on the ticket once it is released. I don’t think I need to see the inner states like “validating fixes in QA” or whatever leads up to something getting into a release.

  5. Reopening tickets - If a fix is determined in QA (or in live) to not have truly addressed the issue, it can be reopened so we have the full context of the issue visible still within the workflow.

If your developer wants to tell me it’s not a bug, they can be my guest. It should be communicated directly and openly on the ticket so that it has some visibility to the issue instead of just apparently being dismissed.

It may be the “intended” design, but if the user experience is poor, and it’s not immediately communicating its design well to me, that’s pretty much as bad as a bug anyway. “It’s not a bug, it’s an undocumented feature” is a fun and cool motto that I am well aware of.

Even despite the bug, the discussion on the original beta forums ticket was pointing out that the skill itself is not that great because it prevents a Bounty Hunter at level 30 (now 35…) from choosing an option that allows him to maintain the same behavior of his active ability at level 29/34. All of the options in the tree drastically change the behavior of the ult, there is no “safe option” for people to pick.

It’s a finicky issue because it acts consistently, but not in a way that is immediately obvious to the user. You will always have to compensate down and to the right, which may give some people issues because the animation seems a little too fast to notice the issue in the heat of combat or at close-enough ranges with target dummies. I’d contrast it with Bounty Hunter’s Double-Shotted, which seems almost perfectly accurate and hitscan.

Thank you. At least with this one, I know that some work was done to make it properly work with Trophy Hunter, but testing was not done with that other talent.

Try to understand that it seems that meaningful discussion was thrown to the wayside, not just with the bug reports but also the discussion forums themselves that had alternative suggestions for talents. The actual intent of everything is very much opaque to me and the rest of the community, especially when people at Fatshark are digging in their heels and apparently not respnding to feedback itself. There’s a lot of talents that are not even remotely “bugged”, but I still don’t understand how they got into this phase without being changed. That’s true for a lot of decisions in this patch, sadly.

I appreciate your ideas, but unfortunately we simply do not have the resource available to us, to be able to revisit reports made here and update accordingly. We’ve stated in our pinned posts that acknowledgement does not necessarily promise change, and at current it’s not something we’re intending to change.


That’s fair, at least it’s the first good idea that I’ve gotten rejected directly, instead of ignored. That’s showing progress on my part!

I apologize for not reading the documentation explaining the definition of “acknowledged” in this context.

Oh yeah, I forgot I had a third video to showcase this fantastic undocumented feature of the talent. I’m not going to bother to put in the effort to re-record it to validate the behavior hasn’t changed.

If you drink your concentration potion when your ult is full or almost full with the talent, it literally does nothing. It is a hilarious undocumented feature to be proud of, and I’m glad the unnamed developer stands by his decision.

Of course, you have already seen this showcased in the thread on the beta forum and of course have validated that this is acceptable behavior for a talent.

Of course.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.