Explain the Unexplainable (@LukeM)

Kirby · 2018-06-19 21:10:32

Pingohits and Alesmile have a world called Octo's fun lab, which is probably the most complete collection of various EE glitches I've ever seen. These are color coded, and one of the categories is "Unexplainable". The other ones can be sorta explained, but these we have basically no idea.

Lets see if you guys know! (or LukeM could just answer them all that works too)

---------------------------------------------------------------

#1

To perform this glitch, start below the GREEN gate and hold left and up. You will be "stuck" on the bottom of the bottom row of dots for a couple seconds prior to falling (provided that you keep holding up). this does NOT work under the red gate. Why?

Alesmile and Pingohits say that their explanation for this is that "vertical speed affects horizontal", but there's more to be explained on that concept. I THINK I have an explanation of my own, but you guys could probably put it into words better than I could.

---------------------------------------------------------------

#2

This one is pretty simple, and should be pretty easy to recreate in a world of your own. Basically, if you jump into a left arrow, the smiley goes down a couple pixels before autoaligning itself, instead of making it a quick hold-space track. This does not happen when the amount of bricks between the jump and the arrow is increased to 2. Why does the smiley go down a couple pixels (or to the left a couple pixels, if jumping from the left arrow).

---------------------------------------------------------------

#3

If you jump at just the right time from the checkpoint, it's possible to do a 1x1 hook that only pops the smiley up a couple of pixels, meaning that they dont hit the spikes, but can still clear the gap.

---------------------------------------------------------------

#4

For some reason, this tightfit is really weird. Even though the smiley does not appear to move at all, when they are perfectly aligned in the center it takes a LONG time for them to be able to jump. Simply align your smiley in the middle, don't touch the arrow keys, and mash space. It's weird.

---------------------------------------------------------------

#5

Now for the ones that they deemed as unexplainable. I'm PRETTY sure it can be explained easily, but I'll put it here anyway. To do this glitch, the player must hold up, right, and space. They will first do the 1.5x1 hook, then jump 4 blocks high instead of 3. (Note - the smiley jumping 4 blocks is unrelated to the hookjump, it's just because of the boost location - that's why holding up matters.) Good luck!

---------------------------------------------------------------

#6

Portals lead to each other. Getting from the nograv effect to the empty block works just fine, but if you hold down and left from the empty block and continue holding after you enter the portal, something strange happens. Recreate this in a level and see for yourself.

---------------------------------------------------------------

#7

This glitch can be demonstrated pretty clearly in the last minigame of the pyramid section in my team's Design Contest submission, but I'll go through how to perform it anyway. The player starts at the checkpoint, and goes to the one ways. They jump and go to the left. Instead of being able to reach the spike/jumping through the gray one way, the smiley will instead fall through the green one ways. This glitch is not possible without the yellow one ways. It also will not happen at the red area if the player enters through the orange area. Also not shown in the screenshot, it does not work if there is not a block above the top row of one ways.

This might not have been a great explanation but it's pretty easy to recreate this basic concept in your world and see how it works.

---------------------------------------------------------------

#8

NOTE - THIS ONE IS THE HARDEST TO EXPLAIN. NO ONE HAS ANY IDEA ON WHY IT WORKS

The glitch is simple. The left side hits the spikes. The right side doesn't. Help.

---------------------------------------------------------------

#9

This one is a behemoth, so I'll try to explain this best I can. Alternatively you could go to the level I linked at the top and try it for yourself.

Basically, the player can start on any of the backgrounds, and hold either up and left, or just left. Different things happen depending on the block that you start on. Occasionally, the smiley will barely clip the arrow but not enter it somehow (that should be explained as well). Occasionally, they'll miss it entirely and get to the red brick BG, and occasionally they'll end up on the orange block.

The top row of switches details how many times the player barely clips on the block and bounces back up until they end up at the red background. When holding only left, the player will not end up on the orange block.

The bottom row of switches displays how many times the player barely clips on the block and bounces back up until they end up on EITHER the red background or the orange block, when holding up AND left. Orange switches represent that they land on the orange block, the others mean that they end up on the red background.

Yeah, it's a lot. Have fun.

---------------------------------------------------------------

so yea

rat, Alesmile, Raphe9000, some woman, Loganyoshi, mutantdevle, N1KF, LukeM, Pingohits, rgl32, SirJosh3917, Weirdoverse, TaskManager, PTU, Dencc, GravityDonut, St1ckS4m(EE), Minimania, Hans, Jedpogi

LukeM · 2018-06-19 22:45:23

I'll give them a go in a week or so once I've finished my last few exams

rgl32 · 2018-06-19 23:18:08

I like these things so I'm going to go over them.

Kirby wrote:

This actually works if you are free falling without touching any blocks, not dependent on speed of going off the edge. If you remove the top left blocks and run from any distance, making sure not to hit any edge when falling, the same thing will happen. I don't know how EE handles much on collision, but I believe it calculates new velocities on collision, so the y velocity could potentially be rounded up when hitting something that stops your horizontal movement (ex. yVel = 2.0005 == 2.01) which would then change the y velocity enough to not stop at the end of the dots. If might be able to do the same thing horizontally, assuming you aren't touching any blocks, I don't know how to set that up though.

Kirby wrote:

This has something to do with collision detection, speed, and how EE handles jumping. You actually jump inside 1x1 spaces, you can try holding space while toggling god-mode and you can actually jump out of your position.
So if you add enough speed inside a 1x1 and jump, your position might think you are outside the block and propel you upward, but the collision detection sees you are still hitting a block. I don't know how EE's code is structured, but if the collision detection is on a fixed update or any other interval than the jump function then that explains why it doesn't properly detect on that iteration.

Kirby wrote:

I actually found something interesting with portals before this. so If you hold down and left vs just holding left, you won't end up in the same spot. I thought it had something to do with the arrows and portals, but it might just be portals acting weird. You might be moving slowly because the portal is actually placing you one pixel under where you are supposed to be, and the one ways are preventing you from being pushed upward to fix itself. I think it only works that way because of the portal directions? Not sure but try the opposite way and see if it will do it with the one way blocks above.

Kirby wrote:

So this actually works with every potentially activated action block (timed doors, team doors, switch blocks, etc.) and I believe it has something to do with ice having to detect an object above it (hence slidey physics). It is potentially skipping a few jump frames (or at least not applying proper velocity) while inside the action block. Possibly could be the ice block taking precedence over detecting both objects and that somehow changes the height of the jump. Not really sure why it is acting like that though.

Most of these are just theories and could be completely wrong but they are fun to think about nonetheless.

I want to look at all of these eventually, I just don't have time right now, maybe a few every couple days.

Pingohits, Kirby, N1KF, Loganyoshi, Schlog, Xfrogman43, mutantdevle, TaskManager, Dencc, Weirdoverse, GravityDonut, Yonanoke

Gosha · 2018-06-20 06:33:51

most of the glitches occur because ee calculates vertical movement before horizontal, but not both at the same time

This was okay for old ee, when there weren't any rotating one-ways, gravity effects (this is the main reason it wasn't added much earlier, it was very buggy and it still is)

Easy example of ee physics directional inconsistency:
it's easy to get this coin

But it's impossible to get this one (without using jump)

rgl32, mutantdevle, Kirby, Pingohits, Dencc, Weirdoverse, Enurp, GravityDonut, Mait, SirJosh3917, Minimania

rgl32 · 2018-06-20 11:48:56

I'm going to make an assumption that the gravity effects only change orientation and not how ee handles physics so I tested most of them except #5,#6, and #9.

#1 is possible to do, but just more inconsistent, you have to move slowly off the edge. #2, #3, and #8 work the same. #4 gets fixed, which is strange to me because I would think it would be able to work better on vertical movement.

#7 though is where things get weird and I don't remember anyone talking about it, I'm sure someone ran into it.

You actually can't enter inside these one ways, which you should be able to since your smiley will "jump" inside 1x1 spaces. You can't use dots, boosts or anything to actually move your smiley inside of it. If you remove the block circled in red you jump on the one-way instead of through it like you would going downward. I thought I had an idea why it works but it works fine when you are facing upward you can both enter it inside a 1x1 space and stay on the top row, so I'm not sure if it still makes sense or not.

#7 and #4 are the only ones that you can't replicate because of orientation.

Kirby

Gosha · 2018-06-20 12:11:47

Rotating one-ways don't work the same. I tried adjusting them to ee physcis so they would be more consistent, but i failed

peace · 2018-06-20 12:35:07

Gosha wrote:

most of the glitches occur because ee calculates vertical movement before horizontal, but not both at the same time
This was okay for old ee, when there weren't any rotating one-ways, gravity effects (this is the main reason it wasn't added much earlier, it was very buggy and it still is)
Easy example of ee physics directional inconsistency:
it's easy to get this coin
https://i.imgur.com/ZYfEGQe.png
https://i.imgur.com/SiwXUHI.png
But it's impossible to get this one (without using jump)
https://i.imgur.com/0yFhfiq.png

mby it time to just calculate both movements at same time then?

John · 2018-06-20 22:26:24

peace wrote:

mby it time to just calculate both movements at same time then?

Probably wont happen as it would break worlds.

GravityDonut · 2018-06-21 15:56:07

Gosha wrote:

most of the glitches occur because ee calculates vertical movement before horizontal, but not both at the same time
This was okay for old ee, when there weren't any rotating one-ways, gravity effects (this is the main reason it wasn't added much earlier, it was very buggy and it still is)
Easy example of ee physics directional inconsistency:
it's easy to get this coin
https://i.imgur.com/ZYfEGQe.png
https://i.imgur.com/SiwXUHI.png
But it's impossible to get this one (without using jump)
https://i.imgur.com/0yFhfiq.png

So that’s how hovers work. Interesting. Now explain how 1x1 hookjumps work. I couldn’t do one of those to save my life.

Alesmile · 2018-06-21 16:17:51

GravityDonut wrote:

Gosha wrote:
most of the glitches occur because ee calculates vertical movement before horizontal, but not both at the same time
This was okay for old ee, when there weren't any rotating one-ways, gravity effects (this is the main reason it wasn't added much earlier, it was very buggy and it still is)
Easy example of ee physics directional inconsistency:
it's easy to get this coin
https://i.imgur.com/ZYfEGQe.png
https://i.imgur.com/SiwXUHI.png
But it's impossible to get this one (without using jump)
https://i.imgur.com/0yFhfiq.png
So that’s how hovers work. Interesting. Now explain how 1x1 hookjumps work. I couldn’t do one of those to save my life.

1x1s are just precise ledgejumps

Kirby · 2018-06-21 16:27:09

Alesmile wrote:

GravityDonut wrote:
Gosha wrote:
most of the glitches occur because ee calculates vertical movement before horizontal, but not both at the same time
This was okay for old ee, when there weren't any rotating one-ways, gravity effects (this is the main reason it wasn't added much earlier, it was very buggy and it still is)
Easy example of ee physics directional inconsistency:
it's easy to get this coin
https://i.imgur.com/ZYfEGQe.png
https://i.imgur.com/SiwXUHI.png
But it's impossible to get this one (without using jump)
https://i.imgur.com/0yFhfiq.png
So that’s how hovers work. Interesting. Now explain how 1x1 hookjumps work. I couldn’t do one of those to save my life.
1x1s are just precise ledgejumps

hey ALESMILE that isnt an EXPLANATION

Bimps, Alesmile, Slabdrill

LukeM · 2018-07-12 13:53:52

Just remembered that I was going to try and explain these... Better late than never I guess

▼1

No idea why this happens (I'm off to a good start XD)

▼2

EE has this weird thing where the physics of blocks are delayed by 2 (iirc) ticks, so briefly after you enter the left gravity block you still act as if you are in down gravity. This means that if you hit the top of the block fast enough, you have a tick or two of downwards gravity which pushes you down a pixel or two (this is why holding either arrow key will stop this from happening rather than just the direction you are pressing, holding right when you jump up will mean you move slightly into the next block, so don't fall down)

▼3

No idea why this would happen...

▼4

I'm guessing this is just because it takes longer to slow down on ice, and the auto align thing only changes your position, not your velocity, so even though you look like you have stopped, this is only because you are still moving right then being auto aligned back, so you aren't quite aligned perfectly.

▼5

This one is just two bugs put together, firstly the hook jump is possible because x position is processed before y position, so if you jump at the exact right time, you jump while you are still on the block, increasing your y velocity, then you move right first (out of the way of the ledge), then you continue the jump as normal, even though you are no longer standing on a block. The second part is that boosts move you so fast that the delayed physics bug would be obvious, so boost physics act in real time, meaning that two ticks later there is a gap (as the boost has already been processed), which happens to mean that that tick follows dot physics, allowing you to hold up and get a slight increase in upwards velocity.

▼6

▼7

I have no idea why these happen as I haven't looked into how one ways work before

▼8

I have to admit, I did cheat a little on this one, although I didn't use my new dev powers (I used FFDec to look through the physics code)

Turns out that slippery surfaces are done a bit weirdly, once you leave a slippery block, there is a short period where slippery physics still act as long as you are not on a solid block. This wouldn't be a problem, but the blocks 'solidness' is calculated lazily, only the block type is checked, so even though its a gate, its thought of as solid (so slippery physics are removed). This still wouldn't be a problem, but it turns out that slippery physics act on your y velocity as well as your x velocity, so you slow down slightly less, meaning you jump slightly higher.

▼9

I don't think this is anything complicated, its just that the physics is applied in ticks, so depending on how close to the boost you are and how fast you are moving on the last tick before you enter it, you move different distances into it, and even though this is maybe only a fractions of a pixel, I guess it is enough to determine whether you go up, clip the block, or end on the orange block. Saying that, I have no idea how the block clipping works... So I guess I can't explain this one fully, only the inconsistancy in numbers of tries.

4 and a half explained, exactly 50% XD

TaskManager, Kirby, Jorc, hummerz5, Slabdrill, Alesmile, Prodigy, Jersa, Minimania, Pingohits, Zumza

Official Everybody Edits Forums

#1 2018-06-19 21:10:32, last edited by Kirby (2018-06-20 12:25:58)