Possible Issue with losing keybinds on login/swap characters - Wrath Classic + Classic Era
boktai1000 opened this issue · 18 comments
I posted the issue here on Curseforge, but felt it might make sense to open an official bug report / investigation on this and perhaps others can chime in as well or help.
https://legacy.curseforge.com/wow/addons/itemrack-classic?comment=718
I wanted to give this issue a shoutout / callout just in case, as there has been a bug with keybinds reverting to default on login occasionally when swapping Alts across both Wrath Classic and Classic Era (Hardcore+SoD). I've seen some mention that folks have narrowed it down to ItemRack (albeit without proof) and anecdotedly, I've also experienced the issue once ItemRack was installed.
It's a bit hard to reproduce as it doesn't happen every time, but usually it comes when swapping between several alts and toons at least when I happen to notice it, but that might just because it increases the frequency of happening. Currently when it does happen, you can ALT+F4 or force close the game so it does not save the defaulted keybinds.
A few mentions with ItemRack being the issue can be found here:
https://www.reddit.com/r/classicwow/comments/188bjgj/keybinds_resetting_every_2nd_relog_sod/
https://www.reddit.com/r/classicwow/comments/16bal4z/constant_keybind_resets/
https://www.reddit.com/r/classicwow/comments/16atfex/keybindings_resetting_again/
If possible, you can check / confirm that ItemRack cannot interact in this manner or to make sure that there are safeguards in place that would be greatly appreciated! Thank you for the great addon.
Bumping this issue. My gf had a problem with her keybinds consistently resetting since launch and she doesn't use ItemRack. However, I installed ItemRack on SoD for the first time yesterday, and today I lost all my keybindings (bars and interface panels/movement keys too) for the very first time (been playing for over 2 weeks with no problems until I installed ItemRack). I use ElvUI, for what it's worth. I'll run Bugsack/Buggrabber and see if I can get anything.
I had this happen to my group every time we logged out in Deadmine using the cannon skip.
- Enable ItemRack in Addons
- Go to into the Deadmines
- Get to the cannon prior to the docks (we blew the door open, but don't think it matters)
- Logout on the tip of the cannon while being ontop.
- Log back in after 1 second, you will be at the start of the dungeon with your keybindings reset.
After disabling ItemRack , we continued to use this method of resetting our instance without our keybinds being reset.
Thanks for the anecdote and steps to reproduce the issue! The more comments and information I think, the better we can identify the root cause, get traction, and hopefully get the issue resolved.
Both me and my fiance have ItemRack disabled on SoD and ever since, have not run into the keybind issue since then, around the time of me making this issue post.
A year or so ago, I had begun experiencing issues with losing keybinds and at the time I thought the issue was possibly related to GRM, but wasn't able to dedicate enough time to investigate and was a bit inconclusive.
I had used an addon called Key Bindings Log "to create a log file of all API calls made by addons which are changing the key bindings." as stated by the addon author. https://legacy.curseforge.com/wow/addons/keybindingslog
In the keybinding logs created, there are several instances of ItemRack appearing or making changes. These logs are from August 2022, but still might prove useful in debugging so I am attaching them here. You may see other addons referenced as well, and as stated - these are older and not exactly refined to only show ItemRack, but include references and for sake of pushing the investigation forward or that someone smarter than myself can look into it, hopefully it helps. I will include these as attachments to my post, and the files can be opened in a text editor of your choice to review.
KeyBindingsLog_2_after_logout_summary.txt
KeyBindingsLog (4).txt
KeyBindingsLog (3).txt
KeyBindingsLog (2).txt
KeyBindingsLog (1).txt
KeyBindingsLog.txt
Some additional anecdotes can be read here, and I will update my original post to reference them:
https://www.reddit.com/r/classicwow/comments/16atfex/keybindings_resetting_again/
Additional user report here on the addons Curseforge page:
https://legacy.curseforge.com/wow/addons/itemrack-classic?comment=725
Has a solution for the keybind loss problem been identified? I heavily rely on ItemRack and have recently reactivated the addon after disabling it due to this issue (which was resolved by disabling the addon). Playing with this bug is currently quite inconvenient.
You can give this thing a try if you have a clear repro case see if it happens.
https://github.com/Road-block/ItemRack/releases/latest
@Road-block I can merge it if it works and you provide a pull request.
I'll give it a shot and have my fiance test as well - if anyone else posted here or sees this and could give it a test too that would be great! Thanks @Road-block and @Rottenbeer !!
As a follow up, I was swapping between characters tonight both me and my finace testing the version Road-block posted on SoD.
We swapped probably ~10 times and had an extended play session without issue. But afterwards, I decided to try to force the issue to pop up and I did get the issue to occur with the Road-block version.
Screenshots might not mean much, but lets just say the action buttons shouldnt be defaults.
Edit/Update: I got it to happen twice actually, and both times it happened while logging into my level 1. I've got a lot of lowbie toons on SoD that just exist or are bank toons. Might just be a coincidence, but noting that. I'm pretty confident thinking back that it happened to a variety of levels and that didn't matter (such as my max level rogue) - just noting that I've had it happen more than once in testing.
Ok just to note that logout skips (especially with alt-f4) are not "normal play". I don't mean it in an actionable kind of way, maybe Blizzard is happy to consider it "clever use" and let it slide.
What I mean is that when you alt-f4 it's the same as disconnecting, the game will not save state properly. So all bets are off in that situation.
When you do a logout skip it is the same but instead of that happening on game exit it happens on game load.
You are causing a server desync intentionally (game can't find your map location while loading so it spawns you at the nearest map cell).
If you have ever used the unstuck service you'll notice it forcibly logs you out to "save game state" then moves your character to bind location properly while you are offline.
When you do a logout skip that goes out the window.
So what I figure is happening (and will not be specific to ItemRack) is that SaveBindings is called at a time when the game hasn't yet loaded per character / per account binding information from the server (GetCurrentBindingSet() does a server roundtrip) so it instead calls it with SaveBindings(Enum.BindingSet.Default) (0) which ends up overwriting your keybinds with defaults (it's the same as doing a "reset to defaults" from the keybind options).
Now the reason why some people experience this and others not, probably has to do with whether your user option for where to save keybinds matches the fallback. If they match, np, if they do not they get overwritten.
I do not believe there is a way to keep using SaveBindings and cover both desync situations at the same time.
- Call it on
PLAYER_LOGOUTinstead ofPLAYER_LOGIN/PLAYER_ENTERING_WORLDand it will not save them when you Alt-F4 - Call it on
PLAYER_LOGIN/PLAYER_ENTERING_WORLDand you likely overwrite when the game starts in "limbo" if you logout skip.
Maybe it is preferable to call it on logout and have just ItemRack keybinds not saving / resetting instead of everything but it's a pick your poison situation.
The only other option is to arbitrarily delay the SaveBindings call so it doesn't happen immediately on game load.
TL;DR: Any addon (not just ItemRack) that calls SaveBindings around game load time will have a chance to cause this.
I will push another commit where it's called on load with an arbitrary delay and also on exit, see if that works better.
The "good scenario" in this situation is that you at worse lose any unsaved changes (no normal logout has happened) to your ItemRack binds, not to the rest of the game.
New package, same place: https://github.com/Road-block/ItemRack/releases/latest
I'll open a pull request too. The way to know if the problem happened is if you notice your keybinding option flip on its own.
You had per character checked and it's now after entering the game, unchecked or vice versa.
Regarding the logout skips and ALT+F4ing, I did want to note that all of my logouts are done through the Blizzard Menu in-game either resulting in an immediate logout due to being in a rested zone, or waiting the full 20 seconds - never using an ALT+F4 or launching a second game client, just to clear that up.
When I personally first noticed this issue, it wasn't really doing anything "quickly" or out of the ordinary per say. I could go an entire game session without an issue, and then swap to a bank character at the end of the day and lose my keybinds, or an alt to mail something over.
Just wanted to mention it because of how prevalent it is, I think that even people doing nothing out of the ordinary with however it was coded or due the nature of Lua, whatever it may be, seemed possible to encounter this issue (and perhaps some folks like yourself just never do, for some reason! lucky!)
I'll give the new release a whirl and see how it goes for me though! Thanks again for giving us hope with this!
Adding further research here.
GetCurrentBindingSet() only returns 0 on very first character login. Calling SaveBindings(0) is not even possible and will error. When keybinds are lost it's due to GetCurrentBindingSet() switching between Account and Character. This happens sometimes after relogging (/camp and clicking Enter World). What specifically causes it I don't know.