I think I understand the whys of the change in behavior while zoning, but I'm having some issues with it. First of all, the new behavior is just plain counter-intuitive (I go to change windows and get no response at all).
Second, and I would consider this more of a bug than a feature: If I start zoning, and alt-tab to another window/program, then use alt-F4 to close that window. That window AND my EQ session both close. (Of course causing me to LD and 1018 out for several minutes)
Problems with the new EQ1 support
Moderators: Lavish Software Team, Moderators
It's actually "old" behavior, exactly the same as WinEQ 1.38. The "new" behavior introduced in WinEQ 2 (updating the window while loading/zoning) was intended to be more intuitive, which of course is why it is counter-intuitive to go back to the old behavior 
Unfortunately the new feature brought crashes for some people.
Interesting that both windows would close when pressing alt+f4. Only the foreground window receives the keyboard messages, so I'm not sure why that would happen.
As mentioned previously I plan to make updating on zoning optional. I'll see about patching this in today.
Unfortunately the new feature brought crashes for some people.Interesting that both windows would close when pressing alt+f4. Only the foreground window receives the keyboard messages, so I'm not sure why that would happen.
As mentioned previously I plan to make updating on zoning optional. I'll see about patching this in today.
When I go back to the threaded behavior I get the thing where keys get stuck, and when I use the new behavior I have this issue with anything I type (in another window) also being buffered and sent to the EQ window when I'm done zoning and it refreshes. If I had to guess I'd say it looks like windows itself doing the buffering rather than any part of EQ or MQ, but I'm sure you know far more than me about such things.Interesting that both windows would close when pressing alt+f4. Only the foreground window receives the keyboard messages, so I'm not sure why that would happen.
It only crops up if I try to swap to the window that's locked in the background.
ie:
2 EverQuest sessions, bound to ctrl-alt-1 and ctrl-alt-2. Both characters are in-game and active. I zone on the first character, and ctrl-alt-2 to the other window to screw around while he's zoning. I get bored and ctrl-alt-1 to see if I'm still zoning...no response, must be. So I type "/tell jimbob sorry jim I'm zoning slow today", wait a minute or so, and ctrl-alt-1 again. Now I'm done zoning, and the window comes to foreground, chances are high that I'll have something like "/tell jimb" queued up in my chat window.
It's a minor annoyance when it just queues up some text, but if it happens say while I'm loading into character select, then more often than not it will take a buffered "enter' keystroke and load in the wrong character when I tab back to that window, causing me to wait even longer while it logs in and then camps back out.
Huh.. I just checked my x-chat logs for every time you said WinEQ and not finding the key stuck issue I'm quite aware that sticky keys issues have been reported in the past, however that is distant past rather than recent past, and I assume that issues that havent been reported in a long time got cleared up... Also, given that I changed the session-switched routine to release all of the keys rather than re-press ones that are being held down in order to fix the issue, I would consider any current sticky keys issue to be a new issue...
I'm quite aware that sticky keys issues have been reported in the past, however that is distant past rather than recent past, and I assume that issues that havent been reported in a long time got cleared up... Also, given that I changed the session-switched routine to release all of the keys rather than re-press ones that are being held down in order to fix the issue, I would consider any current sticky keys issue to be a new issue...