Really Interesting Key/Timing Discovery

BEE · 2015-03-24 03:52:39

So MIHB showed me something that I thought was really odd, and it's totally frustrating for people that actually play minigames.

The key/timing mechanism changes depending on factors.

For one, when MIHB put a smiley in a key activation loop in another tab on his browser, and I did the same in another tab on my browser, my unselected-smiley took about twice as long to go through the loop as his did!

The weirdest part was that it SHOWED the smileys as going at the same rate, but if you WATCHED the blocks actually activate, they were WAY off!

It also works if you do it by yourself. Put the following into your own world, then open your word again in a new tab. Put one of your smileys into one thing, and the other into the one next to it. Start them both off at the same time by activating a block until everyone is at the start. Then release and watch how the smiley with the active-tab is going normally, and the not active tab APPEARS to be going normally, but actually is triggering the key WAY behind the other one!

Can anyone replicate this? Any idea why it happens?

I have come to the conclusion that THIS is why I am so terrible at EE. Haha, just kidding.

Can anyone figure out exactly how much of a difference there is? Or whether it is different for different computers?

Is there any way to fix it? This must be terrible for minigames that require precise timing.

Different55, Nickolai, Kangxp, Minimania, goeyfun, xen90, Xfrogman43, Onjit, gkaby, Hashy, Anch, sthegreat, Raphe9000, Andymakeer

Xfrogman43 · 2015-03-24 04:55:49

I've seen this before. A long time ago I was trying to have another tab hit a key while people played but it did the same thing. >Looked like it hit key but didn't so it was kinda delayed.

Abelysk · 2015-03-24 05:01:09

This happened with me when I had an alt run my New Keyland world.

rubixguy · 2015-03-24 05:11:32

I believe this is just the expected client->server->client delay. Each of your tabs is connected as a separate client to the server. When the selected tab client hits one key, you see its effect immediately because that client knows that it hit the key at that moment, but that info has to get sent to the server, where the server has to broadcast it to the rest of the connected clients, which includes your unselected tab. The unselected tab will get a delay in "seeing" the key get activated. And vice-versa, the unselected tab will see its own key get activated immediately, but the selected tab will have to wait for the server to broadcast it before it knows that it is activated.

The delay does not apply to seeing other players' smileys react to game physics. The selected client just assumes that the player will fall when the key is deactivated. It will not wait for server confirmation. In fact, you usually won't get server confirmation of this.

This does have unwanted behavior in some instances, such as the one you have described. The timing of key activation/deactivation relies on timing of when "show" and "hide" messages are sent and received, but if you yourself touch a key, your client does not even wait for a "show" message to activate the key, while others' clients will have to wait. This means that there is almost certainly going to be differences in the timing.

EDIT: I just realized that there is probably another bigger factor involved as well. I believe that the browser puts unselected tabs at a low priority for processing things happening in that tab. So, it could take some time for the client to process falling into the key below him, causing it to happen much later than it would in an active tab.

Zumza, SirJosh3917

Dazz · 2015-03-24 07:21:32

I've been dealing with this just yesterday while testing something with an alt but this was always like this, it simply takes time for data to travel back after each action you make but it doesn't mean that the game is desynchronized with your live actions nor anyone else, this is not happening just on EE btw

BEE · 2015-03-24 11:32:51

I believe this is just the expected client->server->client delay. Each of your tabs is connected as a separate client to the server. When the selected tab client hits one key, you see its effect immediately because that client knows that it hit the key at that moment, but that info has to get sent to the server, where the server has to broadcast it to the rest of the connected clients, which includes your unselected tab. The unselected tab will get a delay in "seeing" the key get activated. And vice-versa, the unselected tab will see its own key get activated immediately, but the selected tab will have to wait for the server to broadcast it before it knows that it is activated.

Now I'm no computer expert, but if his were true, it means that it should still be a problem with unselected windows as well. But when I try to duplicate the problem with a duo window in the background instead of a duo tab, there is no problem at all and they run the same!

Also, if you let it run for a bit then select on the tab that was running, the unselected-tab-smiley seems to zoom backwards or teleport... going to where it was running in the background rather than staying caught up with the other active-tab smiley.

This means that if I were to play minigames that rely on keys and timing, I wouldn't be able to know the exact timing that the key will be triggered?

Pingohits · 2015-03-24 12:13:11

yes theeditor made a longg marathon world and I let it afk in another tab

2 people people in behind of me passed me

also works if you are afk in a world that needs to you to make 99 deaths to wn

tentacleTherapist · 2015-03-24 18:12:27

This has been around for a while, it is the same thing you can sometimes use to cheat in ex shift as it doesn't seem to count the "alt" as doing anything until you switch to its tab.

BEE · 2015-03-24 23:04:50

Well if it's been a problem for so long, why hasn't it been fixed?

Pingohits · 2015-03-24 23:06:00

Bee wrote:

Well if it's been a problem for so long, why hasn't it been fixed?

no one knows why that happens

mrjawapa · 2015-03-24 23:09:05

This is a client glitch. Your client shows the gate is closed, while their client shows it's open. This usually causes some glitches with coin gates and death doors too.

BEE · 2015-03-24 23:11:03

JaWapa wrote:

This is a client glitch. Your client shows the gate is closed, while their client shows it's open. This usually causes some glitches with coin gates and death doors too.

But is it fixable? It's frustrating to say the least.

Anch · 2015-03-24 23:15:01

Yeah I've had troubles with this when I was creating a key-based world with me as the person to get the keys but in my other tab it didn't show that I got it.

AsurcH · 2015-03-25 00:04:48

I believe so eedd has a whole level dedicated to this problem.

Kyle97 · 2015-03-25 12:27:23

This is nothing new, I remember having this problem like 3 years ago in one of my levels. You can get around it with some clever design and alot of thought and planning.

kubapolish · 2015-03-25 18:27:49

Fix:
Open new window instead of new tab.
When you like to change to your client, DO NOT MINIMALIZE. Just create not maximalize but minimize (lol my english craps) Just hide the "bot" window with not minimize (eh.... this image.)

skullz17 · 2015-03-25 19:27:31

Don't MIHB's key worlds use this? I've played worlds like quickman like this, and it seems to work how it's supposed to. I think he built them around this bug.

BEE · 2015-03-26 00:13:55

There are some workarounds but it still limits the various level types drastically.

It needs to be fixed, especially if it has been a problem for so long.

MIHB_casts_confuseplayer · 2015-03-26 01:42:44

skullz17 wrote:

Don't MIHB's key worlds use this? I've played worlds like quickman like this, and it seems to work how it's supposed to. I think he built them around this bug.

Timers can be made fairly stable if they use a basic 5-second rotation, in that any key strike, or groups of key strikes, happen in 5 second intervals. This is because they can be built using timed doors to stabilize any randomness; any deviations will go back to the regular 5-second interval.

Any pattern that times that aren't multiples of 5, runs into all sorts of stability problems.

rubixguy wrote:

I believe this is just the expected client->server->client delay. Each of your tabs is connected as a separate client to the server. When the selected tab client hits one key, you see its effect immediately because that client knows that it hit the key at that moment, but that info has to get sent to the server, where the server has to broadcast it to the rest of the connected clients, which includes your unselected tab. The unselected tab will get a delay in "seeing" the key get activated. And vice-versa, the unselected tab will see its own key get activated immediately, but the selected tab will have to wait for the server to broadcast it before it knows that it is activated.

Nah, this should impact a player seeing another player hitting keys, but the impact should be the same if somebody sees two other smileys belonging to the same player hitting keys; the two smileys should have identical delay. This isn't the case; active tab smileys experience little to no delay, background tab smileys experience a lot of delay. Furthermore, the effect would be a step function, not a linear function as it happens to be.

The idea of differing CPU focus on different tabs is an interesting idea which may play a small or large part. However, to my knowledge, this difference in speeds was never a problem prior to an EE update around January of (2011 I think). Prior to that, keys worked exactly as expected, regardless of browser use, tab use, player, and so forth. Key timer levels were actually relatively common back then due to the ease in making a reliable key timer, but right now almost nobody makes key-timer based levels because of the difficulties involved.

This change leads me to think that the problem is with an EE bug, rather than something fundamental with how computers work. Possibly EE itself tells the CPU to process it differently now if in a background tab, I don't know. But I think its very likely the issues are due in some way to EE itself, and are not fundamental to all computers or games of this type.

Jawapa wrote:

This is a client glitch. Your client shows the gate is closed, while their client shows it's open. This usually causes some glitches with coin gates and death doors too.

Nah. The evidence is extremely clear that there is a linear impact on how the smiley behaves in a background tab, with all activities slowing down by 70% or more with some variance from moment to moment, but still happening in the exact pattern they should.

Kubapolish wrote:

Fix:
Open new window instead of new tab.
When you like to change to your client, DO NOT MINIMALIZE.

Although this does work at the moment, two big problems:

1. This hasn't always worked

This one I can't say for certain, but I'm pretty sure I tested this workaround back when the problem first came up, and it didn't help. If its different now, that suggests that it could go back to not working in the future. And few people want to spend time making complex levels that could stop working at any time for no apparent reason.

2. You have to *know* this

If you want to make a level with a timer where any player can run the keys (meaning you don't have to constantly be around any time the level is open), the player running the keys has to know this. If they don't know, and run it with a background tab, the level will play incorrectly and probably be broken as long as that smiley is in the timer.

skullz17

BEE · 2015-03-26 01:48:33

*nods*

ugotpwned, skullz17, gkaby, Xfrogman43

N1KF · 2018-05-30 05:08:37

MIHB_casts_confuseplayer wrote:

This one I can't say for certain, but I'm pretty sure I tested this workaround back when the problem first came up, and it didn't help. If its different now, that suggests that it could go back to not working in the future. And few people want to spend time making complex levels that could stop working at any time for no apparent reason.

This intrigues me. Do any of the developers know why this is? If keys could work well again, that would be great.

Minimania · 2018-05-30 05:36:22

N1KF wrote:

MIHB_casts_confuseplayer wrote:
This one I can't say for certain, but I'm pretty sure I tested this workaround back when the problem first came up, and it didn't help. If its different now, that suggests that it could go back to not working in the future. And few people want to spend time making complex levels that could stop working at any time for no apparent reason.
This intrigues me. Do any of the developers know why this is? If keys could work well again, that would be great.

Perhaps after three years the developers could have a better chance at knowing.

N1KF

LukeM · 2018-05-30 08:36:40

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

Zumza · 2018-05-30 10:55:51

This is a good explanation in my opinion:

rubixguy wrote:

I believe this is just the expected client->server->client delay. Each of your tabs is connected as a separate client to the server. When the selected tab client hits one key, you see its effect immediately because that client knows that it hit the key at that moment, but that info has to get sent to the server, where the server has to broadcast it to the rest of the connected clients, which includes your unselected tab. The unselected tab will get a delay in "seeing" the key get activated. And vice-versa, the unselected tab will see its own key get activated immediately, but the selected tab will have to wait for the server to broadcast it before it knows that it is activated.
The delay does not apply to seeing other players' smileys react to game physics. The selected client just assumes that the player will fall when the key is deactivated. It will not wait for server confirmation. In fact, you usually won't get server confirmation of this.
This does have unwanted behavior in some instances, such as the one you have described. The timing of key activation/deactivation relies on timing of when "show" and "hide" messages are sent and received, but if you yourself touch a key, your client does not even wait for a "show" message to activate the key, while others' clients will have to wait. This means that there is almost certainly going to be differences in the timing.
EDIT: I just realized that there is probably another bigger factor involved as well. I believe that the browser puts unselected tabs at a low priority for processing things happening in that tab. So, it could take some time for the client to process falling into the key below him, causing it to happen much later than it would in an active tab.

LukeM · 2018-05-30 11:00:57

Zumza wrote:

This is a good explanation in my opinion:
▼rubixguy wrote:
I believe this is just the expected client->server->client delay. Each of your tabs is connected as a separate client to the server. When the selected tab client hits one key, you see its effect immediately because that client knows that it hit the key at that moment, but that info has to get sent to the server, where the server has to broadcast it to the rest of the connected clients, which includes your unselected tab. The unselected tab will get a delay in "seeing" the key get activated. And vice-versa, the unselected tab will see its own key get activated immediately, but the selected tab will have to wait for the server to broadcast it before it knows that it is activated.
The delay does not apply to seeing other players' smileys react to game physics. The selected client just assumes that the player will fall when the key is deactivated. It will not wait for server confirmation. In fact, you usually won't get server confirmation of this.
This does have unwanted behavior in some instances, such as the one you have described. The timing of key activation/deactivation relies on timing of when "show" and "hide" messages are sent and received, but if you yourself touch a key, your client does not even wait for a "show" message to activate the key, while others' clients will have to wait. This means that there is almost certainly going to be differences in the timing.
EDIT: I just realized that there is probably another bigger factor involved as well. I believe that the browser puts unselected tabs at a low priority for processing things happening in that tab. So, it could take some time for the client to process falling into the key below him, causing it to happen much later than it would in an active tab.

I'm pretty sure the edit is the correct explanation, the client -> server -> client delay would be a matter of milliseconds while this is delayed by seconds. The explanation as to why the delay doesn't apply to the apparent physics is correct though, I guess I forgot to explain that in mine.

Official Everybody Edits Forums

#1 2015-03-24 03:52:39, last edited by BEE (2015-03-24 04:04:37)

Really Interesting Key/Timing Discovery

#2 2015-03-24 04:55:49

Re: Really Interesting Key/Timing Discovery

#3 2015-03-24 05:01:09

Re: Really Interesting Key/Timing Discovery

#4 2015-03-24 05:11:32, last edited by rubixguy (2015-03-24 05:15:36)

Re: Really Interesting Key/Timing Discovery

#5 2015-03-24 07:21:32

Re: Really Interesting Key/Timing Discovery

#6 2015-03-24 11:32:51

Re: Really Interesting Key/Timing Discovery

#7 2015-03-24 12:13:11

Re: Really Interesting Key/Timing Discovery

#8 2015-03-24 18:12:27

Re: Really Interesting Key/Timing Discovery

#9 2015-03-24 23:04:50

Re: Really Interesting Key/Timing Discovery

#10 2015-03-24 23:06:00

Re: Really Interesting Key/Timing Discovery

#11 2015-03-24 23:09:05

Re: Really Interesting Key/Timing Discovery

#12 2015-03-24 23:11:03

Re: Really Interesting Key/Timing Discovery

#13 2015-03-24 23:15:01

Re: Really Interesting Key/Timing Discovery

#14 2015-03-25 00:04:48

Re: Really Interesting Key/Timing Discovery

#15 2015-03-25 12:27:23

Re: Really Interesting Key/Timing Discovery

#16 2015-03-25 18:27:49

Re: Really Interesting Key/Timing Discovery

#17 2015-03-25 19:27:31

Re: Really Interesting Key/Timing Discovery

#18 2015-03-26 00:13:55

Re: Really Interesting Key/Timing Discovery

#19 2015-03-26 01:42:44, last edited by MIHB_casts_confuseplayer (2015-03-26 01:48:28)

Re: Really Interesting Key/Timing Discovery

#20 2015-03-26 01:48:33

Re: Really Interesting Key/Timing Discovery

#21 2018-05-30 05:08:37

Re: Really Interesting Key/Timing Discovery

#22 2018-05-30 05:36:22

Re: Really Interesting Key/Timing Discovery

#23 2018-05-30 08:36:40, last edited by LukeM (2018-05-30 11:16:58)

Re: Really Interesting Key/Timing Discovery

#24 2018-05-30 10:55:51

Re: Really Interesting Key/Timing Discovery

#25 2018-05-30 11:00:57, last edited by LukeM (2018-05-30 11:17:40)

Re: Really Interesting Key/Timing Discovery

Board footer