Please don't shut off the breaker, /u/gordopotato
Please don't shut off the breaker, /u/gordopotato
Stay tuned!
It's in your walls
Correct, also you start at ~50% life
K I’ll make sure it’s on the dev tracker
/u/moxjet200 can you guys put this on the roadmap somewhere? Offline play is a big selling point for the game and it would be nice to have complete functional parity between the two.
In offline potions aren’t reset to full?
Hi, is there any update for these totem related bugs fixing? It has been some time with a few small patch updates released but none of those bugs fixed mentioned in patch notes do cover these totem related bugs I have brought up. Appreciate if you can reply me.
It got stuck a bit in the pipeline due to it being lower severity than some of the other things that needed to go first. I just got it approved today and it is moving again. I don't know when it will make its way in but I'm hopeful for next week.
Following
Please post your log files https://support.lastepoch.com/hc/en-us/articles/1260805192629-The-Game-s-Log-File
Are you playing offline?
While I agree those were stupidly strong and needed to be nerfed, calling the smoke/dive bomb thing a bug is stretching it. Abuse of overpowered ability combo sure, but not really a bug.
It did exactly what the tooltip said it would do: Extend the duration of smoke bomb per falcon landing there.
I don't think it's fair to shame players who used that as "bug abusers".
This is where the line becomes a little blurry. It didn't do what the design documents say it should do. It also didn't do what I was telling people pre-patch. I got this question a lot actually. So we designed it to only work once, we told people it would only work once but then in game, it worked many times.
So it's kinda, how much do you trust that it was supposed to be only once? I don't think the design docs keep a history of when individual pieces were added but I just went to check the original version and it says:
Cloud Gatherer If the Falcon lands within the area of your Smoke Bomb, the Smoke Bomb gains 40% increased total duration. This effect can occur once per Smoke Bomb. (0/1)
But then on the other hand, plenty of things get changed intentionally between the design document and final release.
Now, I do actually know what happened with this one because I'm the idiot that let it happen in the first place. It was ...
Read moreSorry, are you saying you believe making changes/bug-fixes which result in a buff mid-cycle would be controversial and should be surveyed?
(this wasn’t covered in the survey because as mentioned, our stance is to continue making changes/bug-fixes mid-cycle which result in a buff, and we didn’t think that would have much opposition)
Yes this is an unexpected result from another change. You can still do this encounter but it currently requires that you do the other quest echoes first. We’re deploying a hotfix momentarily that alleviates this.
We will continue to make changes and bug-fixes which result in a buff.
Because we don’t like promising things we haven’t started to look into yet so don’t know enough to say if it may even be possible.
Without as strong of words, I don’t really disagree. If we didn’t agree to at least some extent, there would be no reason for us to look at filters in the future!
As it does what it says it’s supposed to, even being overpowered, it’s then not a bug and something we would look to change at the start of a cycle rather than mid-cycle.
Somewhat - The information will be there for anyone to ignore entries they want to ignore. We aren’t able to scope in to 1.1 filter and backend service coding for changing what results get returned to the leaderboards for a better supported UX for those players.
As answered above, we don’t have the space in the scope to fit it in for 1.1, but it’s definitely something we’ll be looking at.
The reason we felt both questions were answered by the one system change was that we feel that having the information with the entries works in both situations. While it is correct that the majority of responses indicated that they wanted a partial reset, we felt that with the system of being able to track when an entry occurred, that would not be the case. So the results are different, the system change / extra information carries over as it supports groups from both questions. I apologize that it felt like we were saying the distribution of responses was the same.
Is it doing what it says it should? If not, it’s a bug. DuckWho beat me to it, but confirming from us as well