v9.0.0 Causing buffs to move off screen
Rustyb0y opened this issue ยท 13 comments
With Addon Loaded
Without
This Addon needs a bit of love, lots of issues in general.
Right clicking to bring up the interface just brings up the Addon page
When assigning new borders, requires /reload or to save as a preset and then reload the preset again to see changes
Clock currently not working at all
It's a shame as it's prob the best Minimap addon outside of ElvUI.
I think it has something to do with a conflict between Bazooka and SexyMap. It's fine as long as either one of them isn't loading.
Bazooka probably has code to move the buffs depending on where you have the Bazooka bar placed.
It probably also has a clock plugin that is hiding the default minimap clock.
There's not enough information here to reproduce this issue.
The clock is also working fine.
Yes a plugin disables the clock, I forgot about that, sorry.
If I setup a default profile for Bazooka bar it anchors a bar to the top of the screen. When 'Adjust Frames' is enabled the buffs and the minimap get pushed down from their default positions so not to conflict with Bazooka Bar.
If I disable 'Adjust Frames' the buffs and minimap go back to there default position and overlap the Bazooka Bar. (I changed the strata on the bar so you could see the buffs and minimap are positioned in their default places.
If I then enable SexyMap the minimap goes to where you set it, however the buffs are now pushed right up to the top of the screen.
If I then enable 'Adjust Frames' in Bazooka Bar the buffs get moved down again.
In my profile I don't have a bar on the top so 'Adjust Frames' doesn't trigger because it thinks there is no bar at the top of the screen. Something in SexyMap, maybe a Library that hasn't been updated since pre-patch might be moving the buff frames.
Bazooka has a library called LibJostle which is supposed to rearrange Blizzard frames if they are affected by Bazooka bars.
I disabled the library from changing the MinimapCluster and BuffFrame to fix the issue. I suspect when SexyMap moves the MinimapCluster LibJostle gets confused and moves the BuffFrame away.
SexyMap doesn't move the cluster at all. It detaches the minimap from it precisely because other frames depend on the cluster.
The end result is the cluster hasn't moved at all and neither have the frames that depend on it.
Hmmm, well Bazooka doesn't even use LibJostle if you don't anchor any bars to the top/bottom of the screen. The Library hasn't been properly maintained for many years and has been patched using band aid fixes for the few addons that still use it, mainly Broker Bar addons. There's a similar issue going back to 2011. For my purposes I don't need it doing anything so disabling the library from affecting those frames is about the best result I can ask for. Thanks for your input.
There is no code in SexyMap for moving buffs, I'm going to close this as you've not reported anything I can resolve on my end.
In regards to your buffs, you can use a different "data bar" addon that doesn't have broken buff moving code, or you can use a buff moving addon such as BasicBuffs.
When SexyMap hides the MinimapBorderTop:Hide()
LibJostle sets an offset if frame == MinimapCluster and not MinimapBorderTop:IsShown()
Then its set the offset = offset + MinimapBorderTop:GetHeight() * 3/5
Then LibJostle does this frame:SetPoint(anchor, anchorFrame, anchorAlt or anchor, x, y + offset)
Which for some reason seems to be affecting the Buff Frame. There are so many different conditions that LibJostle is checking for to adjust the offset and the fact that LibJostle isn't maintained anymore. I'm just going to comment out the offset.
Re-opening this temporarily for visibility since others are having the problem.
When SexyMap hides the MinimapBorderTop:Hide()
But this isn't anything new and you seemed to describe this issue as being new to shadowlands?
On patch day I updated the backdrop code in Sexy Map and only reported the issue after updating to the latest version. Bazooka also required an update for the backdrop changes. LibJostle adjusts the offset of the MinimapCluster if it's relativePoint is set to "TOPRIGHT". Could something tied to the backdrop changes have caused this? I've also seen people reporting the same issue with Chinchilla Map.