Maintenance for the week of November 25:
• PC/Mac: NA and EU megaservers for maintenance – November 25, 4:00AM EST (9:00 UTC) - 7:00AM EST (12:00 UTC)
• Xbox: NA and EU megaservers for maintenance – November 27, 6:00AM EST (11:00 UTC) - 9:00AM EST (14:00 UTC)
• PlayStation®: NA and EU megaservers for maintenance – November 27, 6:00AM EST (11:00 UTC) - 9:00AM EST (14:00 UTC)
specifically a couple nights ago i was "trying" to pvp in grey host, when i was about to join a fight at ash i got booted back to login, then trying to re-log in the character in cyrodiil it failed giving me the lost lobby connection
didnt feel like continuing to mess with it so i just gave up that night
it definitely has been a lot less frequent since they resolved most of the post-U33 release issues, but still something that i never really experienced at all prior to U33
i have my main house (grand topal hideaway) listed in the housing tours, it has multiple target dummies, scribing altar, and grandmaster stations (in progress being filled out), as well as almost every antiquity furnishing on display to preview them
I get it a lot and I have a pretty good guess as to why it happens. Every zone in the game, including Cyrodiil is sharded into slices, and is what the error message refers to as a "lobby". These are spun up or down on demand depending on population. I also suspect that housing and dungeons all end up sharing their own "lobbies" that contain multiple instances of each. For example there was a housing issue at one point which was caused by too many people using a particular house. Also when you fail to load into a queued dungeon straight away (and have to travel to player), it's probably because it had to spin up a new lobby to support it.
The cases where this bug might happen would be
1. The lobby is full and the server needs to create a new one for you to go into. This timed out or failed for whatever reason. You get booted. This one happens all the time during a busy keep fight in Cyrodiil!
2. The lobby doesn't exist at all and the server needs to create a new one for you to go into. Most likely for some really obscure delve. This timed out or failed for whatever reason. You get booted.
I get it a lot and I have a pretty good guess as to why it happens.
All of this sounds plausible. Add a "lobby" for initial login as well.
It all boils down to chronic sensitivity to/intolerance of glitchy/slow/intermittently lossy communications infrastructure ("glitchy/slow/lossy" pretty much sums up the internet as a whole, in practice). Not the way to go with large-scale distributed applications (which is what I do for a living, in real life). In fact, actively harmful.
Application design and implementation (including timeout/recovery mechanisms) need to accommodate these environmental constraints, and get tested at scale, before inflicting them on the customer.
To begin troubleshooting this login issue, we recommend the steps found in the link below.
I would respectfully request some (any?) evidence that ***Zenimax*** is engaged in "troubleshooting this login issue". Pushing generic procedural boilerplate on the customer that consists of "workarounds" that are manifestly ineffective... characteristically bureaucratic, but also harmful.
Realistically, the pathologies of a (regularly failing) application need to be addressed first, in this case to accommodate the idiosyncrasies of the application's operating environment, before any external action on the part of the customer can be expected to affect the behavior.
By definition, the concept of a "workaround" consists of customer adaptation to defective application behavior, but in this case Zenimax apparently expects the customer to work around the fundamental nature of the operating environment, and the application's selective but equally fundamental incompatibility with it. The dog won't hunt.