Zenimax have failed on loadscreens

kenjiblaster25

Load screens in pvp are lasting over 5 min. What happened to the promise that at 2min you’d be freed? Is it too hard to keep that working? Asking for a friend

SluggoV2

a "friend", right...

Nerouyn

In PVE I've been experiencing the dreaded load-screens-of-death recently. Hadn't for years.

Server might be struggling to cope with all the little extra event bunnies hopping about.

kenjiblaster25

Oh well, sorry for being sarcastic

SluggoV2 wrote: »

a "friend", right...

rabidmyers

yeah they're slower than the word slow

Brrrofski

I fully accept at this point in time they're here to stay.

So can we at least get down new ones??? Something fresh for our eyes at least!

kenjiblaster25

Brrrofski wrote: »

I fully accept at this point in time they're here to stay.

So can we at least get down new ones??? Something fresh for our eyes at least!

Point is ZeniMax said it had a two minute cap at which point you’d be exited. Well that’s crap now because they’ve failed to keep that coding alive. Maybe it was replaced - or they spilled coffee on it - but infinite load screens are back and it’s pathetic they can’t keep on top of this.

Edziu

kenjiblaster25 wrote: »

Load screens in pvp are lasting over 5 min. What happened to the promise that at 2min you’d be freed? Is it too hard to keep that working? Asking for a friend

you must be new here...let me explain

this is just pretty old feature now

mairwen85

There's 2 parts to what's going on behind the load screen.

1st part is the loading of assets locally, and the pre-rendering, and pre-caching of those
2nd part is the client-server request-response comms

The 1st part is controlled more or less by your hardware and the game engine. If local resources can't be assigned to the seek and load tasks on the hardware, the job will get queued until priority/resource is assigned to it.

The 2nd part is network dependent. If the comms drop, or cut out/time out without graceful or meaningful error, the conversation is terminated which can result in an infinite wait for response = infinite load screen.

Ideally this will be an asynchronous action, that means to say the request is started and while ongoing the local job executes as a parallel process. This can be controlled in under the 2 minute window with the intended weight of the job being client side, and only if the expected response time is also under 2 minutes (which it should be in this day an age -- we're just sending data upstream to inform the server of change) can it remain unaffected by network issues like server-pressure, load-balance, traffic volume and latency.

If the servers are under so much pressure that the 2 minute window can't be satisfied, then the servers and their infrastructure really need some TLC as that's unacceptable.

If the engine is such a resource hog that it jams itself in a conflict with client side devices for resource, or the engine is inefficient enough that it runs default on low priority, someone need to get cracking on it asap -- again, unacceptable for a product that is 5 years into its life cycle.

kypranb14_ESO

On PC/NA and don't get these long loading screens at all.