Mappy Continued

Mappy Continued

6.5k Downloads

More bugs 10.0 Beta/Retail

Voxxel opened this issue · 20 comments

commented

Hi there, Shushuda,

I'm getting some new bugs.

1st, the node blinking. When I set Mappy to use flashing gathering nodes, sometimes the whole icon overlay is blinking not only the nodes. Like this:

2022-10-30.22-20-33.mp4

This animation is from the current DF Beta build but this bug is exactly the same in 10.0 Retail too. It's quite inconsistent however, sometimes a simple reload or /mappy reload solves it, sometimes not. Sometimes it just works fluently by default, without blinking unrelated icons, sometimes not. I couldn't figure out any pattern.

2nd, "Flash gathering nodes" feature does not work. DF Beta only.
3rd, "Large gathering nodes" feature does not work, DF Beta only.
4th, "Classic-style gathering nodes" feature does not work. DF Beta only.
These setting were all turned on when I captured the video above.

I don't know if you have Beta access to test it there or not. Maybe they use different node icons in the DF Beta, I'm not sure. You can see the yellow gathering node icon on the animation in the southeast part of the minimap. It's a mining node in DF Beta.
However, this bug may be ignored as Beta is still in development and maybe the Beta development is actually behind of the retail version. The version numbers are:
Current Retail is 10.0.0.46366 / current DF Beta build is 10.0.2.46259

4th, can't move the minimap by the addon itself in both versions. The only way I found is to use WoW's Edit Mode which has many problems especially with clamping to the screen edge. It would be nice to allow us to move the minimap frame by Alt+click / Control+click / Shit+click / or even a tickable option to make the frame able to move.

commented

Oh dear. Thanks so much for the detailed bug report! You have no idea how much I appreciate exact build numbers and recordings!

I do have beta access, I will take a look at these.

1st - Curious about the animation bug, I didn't encounter it yet and I had my game on for over 8 hours each day, makes me worried about reproducing it. It sounds like an issue with loading the texture. The flickering looks like it matches the interval set for icon flashing, so it must be flashing on each texture reload. I'll try to leave the game going for a while and see if it happens on my side. Does it happen completely randomly or upon activating the option to flash icons? As in, is it happening right after clicking the option or does it "break" randomly after the game runs for a while?

2nd, 3rd, 4th - This sounds definitely like an issue with texture loading. You say that the animation is from the beta. Does it mean that these features don't blink the icons as they should on beta, but they work in retail, AND the flashing you've recorded happens on both regardless of whether the blinking is working?

So like this?

  • retail: flashing works, sometimes flickering issue
  • beta: flashing doesn't work, sometimes flickering issue

They use the same icons afaik, I've checked. There must be an issue with the loading itself, I will take a look. But it's weird that they flicker on retail as well, makes me worried both issues are unrelated, which will make the flickering a bitch to fix.

Beta is ahead, that I'm sure of. Even the second wave of the prepatch is ahead, I remember seeing a tweet about it from WeakAuras devs.

5th - This is intentional, as the original addon moving was bugging out because of the inclusion of the Edit Mode, so I just removed the function altogether. There's something weird going on with this, some elements can be moved just fine (mini bar moved by Bartender4), some bug out (extra button moved by Bartender4). I can try to add that in again, but it was wacky as hell. I'd rather wait with this one until they fix the UI, since the entire Edit Mode is very buggy atm. It might end up working fine with no need to implement the moving inside the addon itself. I'd also prefer to add an XY coordinate option in favor of drag as well, it's more precise and actually offers something that Edit Mode does not.

Oh dear, Blizz touched the forbidden spaghetti code of UI and it shows so much now... Bear with me, I'll try to get that sorted eventually lol

Also, I know I dump a lot of text on ya, sorry about that. That's just how I write comments in my tasks at work, I like to put my thoughts out while I think them.

commented

I will write here about researching these bugs, so sorry for the notification spam.

I've found an old thread for Carbonite with the exact same issue. I was right, it is an issue with loading the texture for the minimap blips, some catching problem perhaps. It also seems like there's no way around it, it's a game issue, even replacing the default Blizz texture with the exact same Blizz texture (using the same path, so it just reloads the same image) produces a flicker.

I can try to add a slider to the options to set the interval for the flashes (to be less annoying at the cost of being less noticeable), but I'm not sure if there's anything else I can do. I will try to research some more, maybe someone solved this issue after all. That thread was from 2011, that's a long time. We'll see, but so far I'm very pessimistic about this issue.

Will look into beta issues now.

commented

Actually, one question. What's your PC specs? Especially CPU, RAM and whether you run the system and the game from an SSD.

I have an absolute monster rig and I don't know if this could affect the flickering or if the game just works wonky in that aspect regardless of the specs.

commented

The combat might be connected to the protected state. Certain Mappy updates are skipped during combat since they infringe on combat's protected state (it's coded in to bail when protected, otherwise there'd be errors in-game). I need to study these parts of the code, I haven't looked at how exactly Mappy is reacting to combat yet. Maybe it refreshes the flashing schedule or something.

commented

Thanks for replying in this.

Ok, I found a pattern about blinking in Retail finally. So keeping all 3 settings ticked, my herbal druid produced this in Zereth Mortis:
Logging on to my Druid -> all the minimap icons are instantly blinking. -> Then I fly to an enemy and get in combat -> icons are still blinking -> then I get out of (drop) combat -> the icons are suddenly stop blinking at the same moment of dropping combat. Only the nodes are still flashing, so everything is as intended. -> However if I reload the game now, all is starting over, all icons start to blink again. So somehow the combat stance is involved and dropping it can temporarily "fixes" the issue everytime.

Also, it's pretty strange but with 3 options ticked my non-gatherer (BS/Engi) warrior also follow the same pattern above while in Zereth Mortis but for example while he sits in Elysian Hold, the icons are not blinking on every log-in.

commented

What's your PC specs? Especially CPU, RAM and whether you run the system and the game from an SSD.

It's a i3-8350K with 16GB ram and an Asus 3050 RTX video card. SSD of course. Using 1920x1080 resolution @ 100Hz

commented

Okay, I've copied my Mappy profile over to the beta and... the flashing and large nodes are working perfectly fine. No issues. Could you copy your profile over from retail to beta and check if it's working? Maybe some data is corrupted on new installs but works fine with the already populated database. Preferably copy both the data and the addon (in case something got corrupted). I will check on my end as well.

The file in question should be here: WTF -> Account -> your-account-id (if you have more than 1 account then you need to find the correct one manually) -> SavedVariables -> Mappy.lua

Copy that Mappy.lua over to beta directory, same path (ofc different account id, but you're gonna have only one here). This will copy your addon database with all your Mappy settings.

Hmm... I've managed to reproduce the flickering, but differently than you. When the flashing is ticked on, any changes to the texture (enable/disable large, enable/disable dots) trigger flickering. It stops when I disable and re-enable flashing and starts flickering again if I change the texture again.

There's an issue with texture loading when the path is getting replaced while the flashing scheduled task is ongoing. This I can fix, I think, I need to look at the flashing code and maybe reload the scheduled task on texture changes.

Also, your specs are very fine, so at least I don't think its rig related.

commented

Yea, my spec aren't the greatest but I think it's still in the mid or mid-low bracket.

-I copied the Mappy addon folder from Retail to Beta to make sure I use the same version.
-I deleted the Mappy config files (mappy.lua and .bak) from Beta's WTF folder to check if a fresh start will work out. Nope, the 3 options does not have any effect, still. (outside of the mining node icon that started to flicker after toying with the settings for a while)
-I then copied over the mappy.lua from retail WTF to Beta WTF. Now it's all the same. Result: Same as above. On a Serevite deposit none of the 3 options are worked. Bo old style, no enlarge, no flashing (dual-color), only flickering yellow.

IT would help a lot to actually know what version I am using because you didn't include the version number to file name and from the Curse app it's just a guessing via upload date and sorting then.
Untitled

It's better to include version numbers to eliminate the confusion, and to make it easier to refer, similar to other addons:

Untitled2

commented

I've fixed the flickering.

I feel like a bloody genius, I tell ya.

It was a caching issue. There's basically a cache variable for holding the currently set texture paths. Then a scheduler is started that uses this variable to constantly replace the textures between the flashing and normal. This is happening when the option to flash is clicked.

But when you click another node option that replaces the texture, a refresh of all Mappy options is done. This also happens when you log in. There's code that sets proper texture paths to a variable that's then used to set the cache variable. There's also code to start the scheduler. The scheduler part is BEFORE the texture paths, so they're essentially modified during a scheduler run. And WoW apparently doesn't like that, so it flickers. Lol, this is so stupid, I love coding.

I will upload this fix today, should be approved tomorrow on CF. I've also found and fixed an unrelated issue with textures and flashing - if you turn flashing off when the icon is blue, it will turn blue when you change the texture to dot/large/small. It will be yellow again only after enabling and disabling the flashing. This will also be fixed in the newest release.

As for the files, shit, that's true, you're right. I will start adding the version number to the zip name, sorry about that.
It's still strange that it works for you on retail, but the same stuff is not working on beta, when it's working on my side. I'm trying to reproduce this, could you send me your Mappy.lua config file? The entire Mappy folder would also be great, you can zip it and upload here.

commented

I've tried deleting the addon and the config file, then downloading the addon directly from GitHub and starting the beta with this fresh clean slate. And I still cannot reproduce this issue, every option works just fine.

Could you try the current code? I'll attach it to this comment as a zip file.
Mappy.zip

commented

Also, are you using any other addons?

commented

Actually, I think I know what might have happened... Give me a while, I will check and if I'm right, upload a fix today.

commented

image

See this? Blizz put the mining icon in a totally different spot than the rest. So I thought the hammer is the mining node, instead of that rock up above... Let me guess, the hammer is the blacksmithing station instead?

Sigh... I will update the textures and upload the fix as version 4.2.4 today...

EDIT:
It's crafting orders icon, ahahah!

commented

Fixed.

As for dragging the minimap via addon settings, without the Edit Mode... I will wait for Blizz to fix Edit Mode for now, to see how they handle this code and how it could affect Mappy.

If they do a good job next week (second phase of prepatch) and the addon will work with Edit Mode natively, then there would no longer be a need for the in-addon drag.

If they don't solve the problems or the addon stops working with Edit Mode (stops saving position etc), then I will implement in-addon drag to mitigate this.

In both cases I will probably add XY coordination movement of the addon, because pixel perfection is worth everything.

What do you think about this? Actually, is the Edit Mode dragging working for Mappy? Does it save the position? Because if not, then I will implement this regardless, obviously.

commented

Hey, I've got an update for you that will make you happy.

Moving via Edit Mode is so shitty in Beta (and doesn't save settings) that I've added back in-addon movement with a "Lock/Unlock" button in the options. I might revert this once they fix Edit Mode, but for now - you were right, it's too shitty to use for Mappy.

I will also work on those XY coords for moving the minimap. Not sure when, but it's gonna be miles better than Edit Mode.

commented

Great, thank you for the great work!
I just woke up for a new, fresh Mappy release, yay! :D
I tested it with the retail and it looks damn freakin' perfect for now. I wasn't able to reproduce the flickering bug so far. To be honest I feared the most about drastic FPS drops related to node flashing feature but it's not the case fortunately I can't see any FPS changes so far. I'll test this new version in the Beta soon.
Thank you for this wonderful work!

commented

Cheers, have a good one! Thanks for all the bug testing!

commented

So just checked the current version in the Beta too and everything went fine and great. Can't find any problem so far. <3

commented

@Voxxel
Bad news, there's apparently a taint now when exiting the Edit Mode, which further taints the entire Edit Mode, resulting in those annoying popups about blocked addon actions.

The issue is because Mappy is overwriting a few Minimap and MinimapCluster functions. These functions are called by Edit Mode, but because they were tainted by insecure code (addon code), they throw errors.

I've tried reapplying these functions upon entering Edit Mode, but it still deems them tainted, because they were changed once.

I'm forced to remove in-addon movement and allow Edit Mode to play with the movement however it likes. So Mappy would have to be moved via Edit Mode only now.

There's probably a way to overcome this, but I have no idea how. I've tried a few different ways and only one was working, but was messy. It allowed movement of the map, locking and unlocking, but entering Edit Mode would revert these changes to the Blizz layout. I could try to add an event register that would reapply Mappy's saved position after Edit Mode is closed (I need to check if it's possible at all), but it'd save two positions in different places (Edit Mode vs Addon) and be confusing.

I could add that as a separate option, as in use Edit Mode by default, but allow the user to enable Mappy-saved positioning, which would do the method I've just described.

commented

Somewhat fixed, but took me almost 4 hours to research this, a lot of new Edit Mode functions are broken or protected so I had to improvise a lot. But it works great now.

I've managed to fix addon movement to not cause Edit Mode errors. I've also added full Edit Mode compatibility as a toggle button. Users can now pick if they prefer to use Mappy's saved positioning and skip Edit Mode entirely or if they prefer to use Edit Mode only to move Mappy. Both options save their settings separately, so users can switch between them seamlessly and retain their settings with each mode.

This should satisfy everyone. Remember to go into settings and check "Use addon positioning" option to apply your old position settings, I've set the default value to False to not confuse new users.