"1.000000001 shouldn't affect much" they thought

I think the devs made enters/exits location using floats or doubles for division, which does lead to floating point error and when rounded to an int, breaks The crash most likely comes from an index out of bounds (since it search for a value of -1 or 5 which is impossible) The game WANT to insert into that box since it's possible, it can find a place to place you! But then when it calculate the placement it shifts because of rounding error This is def patchable, but would require a lot of the core game code to be modified

4:00 The numbers denote the block width of the pieces

And here I thought the level select shenanigans were as cursed as it gets

I didn’t know the limit was so low, I knew there must be a limit but it’s not very many boxes

The box doesnt enter because it tries to enter a wall instead of the hole in the box due to a rounding error

10:29 You probably entered some level of epsilon here.

here’s my idea of like how this works (just a theory tho) so like basically in like this game the positions inside boxes are recorded using decimals, like for example a 3x3 has the first tile range from decimal 0 to 0.3333333…, the second being 0.333.. to 0.666.. you get the point. now, the reason why we enter the second or “middle tile” is because when entering the game checks for a place where you can enter at decimal 0.5. The range 1/3 to 2/3 contains this, so the game goes into that tile. However the catch is that to make it easier the game rounds these to 0.33 and 0.67, since otherwise they would be infinite. Or this is natural for the unity engine. either way, if we put another box inside there, we have a box in 0.33 to 0.66, and the only enterable place there is the middle, but to check the bounds we must consider a 9x9 area since it is a 3x3 inside a 3x3. So we have 0 to 1/9, 1/9 to 2/9, and etc.. the area we are looking for is 4/9 to 5/9. Rounding this gives 0.44 and 0.56. Putting another box in gives 13/27 and 14/27. Which rounds to 0.48 and 0.52. continuing we get 0.49 and 0.51, or 40/81 and 41/81. then we get 0.5 and 0.5…. these appear to be bounds you can normally be able to enter, and as you go on they stay the same… so what’s wrong? Well, I think that instead of being close bounded like [0,1], where 0 and 1 are included, they are actually closed bounded, so (0,1) implies 0 and 1 are not included. This means our box-ception has bounds (0.5,0.5) which is nothing since 0.5 is not included. so that means the box is unenterable. Of course this demonstration happens way faster than in the actual game since it only uses 2 decimal points. Parabox likely uses 3 or more. So that’s it. I cant seem to find out why eating is normal, so if anyone could help with that thank you. Of course, it could just be that my whole theory is wrong but whatever. This was just a guess anyways.

maybe entering the clone when its full has some different behavior at that point?

...Oh god don't let the creator of squishcraft make a PP level pack...

This is why you use fractions instead of floats

👀 me waiting for N other N Cryption (yes I have patience)

10:39 hmm thats odd, the game didn't freeze when I did that

3:42 it is a pity that we cannot see what happens in 99

10:38 f̥̘̥̥̥̘̥̘̘̥̘̥̘̘̘̥̘̘̘̘̈̈̃̃̃̈̃̃̈̈̈̈̈ʟø̬̬̬̬̬̬̬̬̬̬̬̬̬̬̬̘̘̯̯̘̘̘̬̪̪̪̈̈̈̈̈̈̈̈̈̈̈̈̈̃̃̃̃̚̚̚ɑ̘ẗ̘̘̘̬̬̬̬̬̬̬̬̬̘̘̘̘̟̟̟̟̹̯̯̯̯̈̈̈̈̈̈̈̈̈̈̈̈̈̈̈̈̈̈̈̃̃̃̃̃̃̃̃̃̃̃̃̃̃̃ f̘̘̘̘̘̘̘̘̥̥̥̥̥̥̥̥̬̬̬̬̬̬̬̘̟̟̟̹̯̯̯̹̝̝̹̹̹̟̟̘̚̚̚̚̚̚̚̚ɽɛɛʂe

no stop

0.1 + 0.2 = 0.30000000001

WHAT

1.00000000000000000000001 10:00

1.00000000000001

1.000000000000001

33.0000001th comment