DBT bugs

[Zidras]

Describe the bug

I have compiled some visual bugs that happen with DBT.

Do you have an error log of what happened?

NA

To Reproduce
See below for each case scenario.

Screenshots

• 1. In Classic animation, AnimateEnlarge does not update its anchor Points to the bars latest position, causing the bars to teleport to their final destination once animation is finished.

(2 vids, one expandUpwards, other not): https://imgur.com/a/codsYVk

• 2. In Classic animation, MoveToNextPosition was not reimplemented and therefore it is not working.

(2 vids, one with 2021 animation, other current): https://imgur.com/a/NHpR0Q3

• 3. In Simple animation, If Fill up and Huge Bars are disabled, Enlarge will make the small bar reset its progress and maximum value.

Wow_PrqN2SKb2w.mp4

Did you try having DeadlyBossMods as the only enabled addon and everything else (especially something like ElvUI) disabled?
Yes.

Which version of DeadlyBossMods are you using?
9.2.21 alpha (20222/07/01 20:33:14)

Was it working in a previous version? If yes, which was the last good one?
Before DBT rewrite, from 2021: DeadlyBossMods/DeadlyBossMods@0d607c7#diff-379aeb92b9b0fea6bbf3d7326c06cc3ea4142a1ab4ea74a64ba49f0e269a138d

Additional context
I have already relayed 1 and 2 to Artemis, but since I am finding more issues with DBT, I thought it'd be best to aggregate them in one place. I will be updating this report if I detect more cases, same as I've been doing with GUI bugs report.

[emmericp]

yeah, looks like the animations are a bit janky, specifically MoveToNextPosition() is implemented but never called. enlarge animation seems to target the wrong "spot"

[Zidras]

For 3. , as mentioned by @MysticalOS , the commit DeadlyBossMods/DeadlyBossMods@d8b1bc3 addressed the issue.

However, it created another one, which I want to run by you whether you consider it a regression, or now intended behaviour.

Every time the small bar enlarges into huge bar, previous behaviour made the bar progress from initial position. Now it keeps the progress.

Previous behaviour:

(huge bar starts at the beginning)

Discord_FGNtCICktP.mp4

Current behaviour:

(huge bar starts wherever small bar left off)

Discord_3drukZnJvN.mp4

[MysticalOS]

i don't think there was any way to fix issues without introducing this behavior.

[Zidras]

i don't think there was any way to fix issues without introducing this behavior.

So I can consider this to now be the desired behavior, and not waste time in trying to fix this?

[MysticalOS]

if you think you can fix it without regression. i won't be opposed, but I won't go out of my way to try and fix it myself because original problem was worse

plus I know some users actually prefer the bar to restart, that's the bigwigs behavior. so it'd even be nice if it was an option to "restart large bars" vs continuing them.

[Zidras]

if you think you can fix it without regression. i won't be opposed, but I won't go out of my way to try and fix it myself because original problem was worse

plus I know some users actually prefer the bar to restart, that's the bigwigs behavior. so it'd even be nice if it was an option to "restart large bars" vs continuing them.

I'll see what I can do.

As for bw behaviour option, that only makes sense on large bars enabled, not small bars, correct?

[MysticalOS]

correct, if not using large bars the bar should never restart

[Zidras]

and only on noAnim (Simple) option, I assume. Classic animated option would look janky to suddenly restart bar once it reaches large anchor