Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
My opinion is ( no evidence to back it up ) the client -> server - > client delay mostly applies to the tab you're focusing on - it would be a matter of mere milliseconds ( <1s ). The background tab, however, in modern browsers are being processed much slower then a regular tab because your browser makes the current tab you're on "focused" and "more important", making sure to spend it's resources on the tab you're on now rather then any other tab. MIHB explains that this didn't happen in pre-2011, and this is probably because this is a newer feature to make the CPU work on only the important stuff.
Offline
Not sure if it was already answered but I cba to read through the whole topic.
Games like EE rely on timeout functions to keep everything running at the right speed, these basically work by adding a function to a queue with a timestamp for when it needs to be run, which the browser checks every so often to see if it needs to do anything (usually every 15 ms as this is the fastest speed Windows can update the browser).
Usually this is used for things like drawing animations, and when you select another tab you can no longer see the old one so the browser puts it into a low power state where it checks this less often (so animations are drawn at 1fps instead of 60fps or whatever).
This is usually a good idea as this saves a lot of processing power that can be used for other tabs, but sometimes in things like multiplayer games it can cause the game to run slower, and EE has nothing to make sure that the physics ticks per second stay constant so the client's local physics just run slower than you would expect, so you fall slower etc.
You still see the client moving at normal speed on other tabs however. This is because each client calculates the physics of every other client internally to save bandwidth and reduce the effects of latency (as otherwise you would have to send hundreds of messages per second with the clients' updated locations), so you only send a message through the server when something important happens such as pressing an arrow or hitting a key.
This means that you will see the player in the background tab moving at normal speed as the client has no reason to think it isn't (similar to why people using hacked clients often jump around a lot on your screen, while they see themselves as flying or whatever), you only see the effects of the slower physics when the client hits a key, as even though you may have seen the client go through the key several seconds ago, the client is running slower so it still thinks its falling towards it.
To fix this you can do things like putting a while loop around the physics code that will keep ticking until it's caught up, which is what I do in my bot PlugIt (you can see that when you switch tabs it starts placing the blocks once or twice per second all at once instead of continuously). There might also be ways to tell the browser not to go into the low power state, but I haven't looked into / forgot about that.
Edit: Explained why you don't see other people moving slower, I forgot to mention this originally
thi is a though one as i play an idle game on kong and when i click behind th egame the game puts itself in backgroudnd mode wher eit just doesnt updat eghrapical elements and still runs at same speed (actulay faster) as when youre activve you see hundreds of thousand of things being cried over conveyors but in backgorun dmode you dont see em moving while you still get your $$ faster mode will go even faster (usnig nearly 200 ticks/sec insstea dof just some 20-100) for me i nbackgorudn mdoe when i used my faster mmode iin backgound mode i coudl go to max ticks/seck (200) until now so maby if thi sgame uses a backgournd mode where it just doesnt update ghrapical elemtns if ur not playing it coudl fix it
thanks hg for making this much better and ty for my avatar aswell
Offline
[ Started around 1732374719.8783 - Generated in 0.040 seconds, 12 queries executed - Memory usage: 1.39 MiB (Peak: 1.5 MiB) ]