## Box physics problems

### Box physics problems

The box physics are still pretty weird in 0.5.1 Alpha:

1) If a box is on a moving block and is pushed right into another block, the box will either just move through these solid blocks like a ghost or it will fall down, through solid blocks. You can force boxes to go through walls this way.
2) The Stonehenge Bug: If you build boxes like Stonehenge and push first the left box a bit, then the right box, the upper box behaves differently. One time, it stands still, the other time, it moves with the box.
Like so:
{l Code}: {l Select All Code}
`AAAAAAA B   C B   C B   C(3 boxes total, each letter is a box)`

3) If you build two conveyor belts horizontally next to each other, the left one with speed -5, the right one with speed 5, and put a 2×1 box right on the middle, the box will move right. Set the speed of the left conveyor belt to -20, the box will still move to the right. The “force” of the left conveyor belt is completely ignored

Suggestions for fixes (Note none of this has been tested):
1) Crush and destroy boxes when they end up in anything solid, like players
2) The upper box should not move in both cases since it still has the other box to rest on
3) Basically, take the average speed of all conveyor belts on which the box is on. Set X=0 and N=0. For each pixel of the bottom of a box, check if it's directly on a conveyor belt. If yes, add the speed of that pixel to X and add 1 to N. The final speed of the box is X divided by N. To prevent the speed becoming 0 due to rounding errors, force the minimum speed to be 1 (or -1, depending on direction) if X does not equal 0.

Example: For the box in the example above in 3) (speed -5 left, speed +5 right), this would be a box speed of exactly 0 because (50 pixels*-5 + 50 pixels *5) / 100 pixels = 0
Example 2: With the conveyor belt speeds -20 left and +5 right, the calculation will be (50 pixels * -20 + 50 pixels * 5) / 100 = -7.5

Please post other problems with box physics here.
Last edited by Wuzzy on 16 Nov 2019, 23:40, edited 1 time in total.
Bitcoin contributions welcome: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)

Wuzzy

Posts: 908
Joined: 28 May 2012, 23:13

### Re: Box physics problems

The box physics is indeed a nasty part in game.

Suggestions for fixes (Note none of this has been tested):
1) Crush and destroy boxes when they end up in anything solid, like players

I don't think it is a good idea, since you can make use of it to bypass box obstacles.

2) The upper box should not move in both cases since it still has the other box to rest on

But what if the two lower boxes are pushed by player and shadow simultaneously? In same direction or in opposite directions?

3) Basically, take the average speed of all conveyor belts on which the box is on. Set X=0 and N=0. For each pixel of the bottom of a box, check if it's directly on a conveyor belt. If yes, add the speed of that pixel to X and add 1 to N. The final speed of the box is X divided by N. To prevent the speed becoming 0 due to rounding errors, force the minimum speed to be 1 (or -1, depending on direction) if X does not equal 0.

I think this is doable.
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

For 1)
I think this is up to the level designer to consider this. We only have 2 levels with moving blocks and boxes so far, and neither would break. In fact, they would get fixed. Level designers needs to make sure that box crushing is simply not possible when it's not desired, or make it so that it cannot be used to proceed, or make it part of the puzzle when it's actually desired.

The only levels with boxes and moving blocks atm are Prison Break and Bridge Over Troubled Waters from Cooperation and in these levels you can stack boxes in such a way they get pushed into other blocks. But in neither level you could use box crushing to bypass anything, actually. Actually, the player wants to prevent boxes from getting crushed here. Therefore, I think this is totally sensible behaviour. And in fact, in Prison Break, you can currently glitch through some boxes through moving blocks by clever stacking, which allows some kind of cheat.

The other logical solution would be to block movement of moving blocks when they try to push boxes into invalid positions. But that would be insonsistent behaviour when compared with what happens to players and also sounds kind of tricky.

For 2)
Revised box speed rules:
2a) When box rests on any solid surface: Ignore all box surfaces, only take the solid surfaces into account. On normal blocks, this means no movement. For conveyor belts, we have rule 3)
2b) When box rests on 1 box: Move box simultanously with lower box
2c) When box rests on 2 or more boxes: Take average movement speed of all lower boxes, in a similar fashion to conveyor belts, but including boxes with 0 speed as well
Bitcoin contributions welcome: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)

Wuzzy

Posts: 908
Joined: 28 May 2012, 23:13

### Re: Box physics problems

I think now we need the box crushing sound and animation. I plan to find the sound on OpenGameArt. As for the animation, currently I use fragile block breaking animation as a placeholder.

[EDIT] The box crushing experiment is on git master branch. It's extremely buggy due to the limitation of current box physics logic, for example, the stacked boxes on a moving-up moving block will crush automatically.
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

Wuzzy {l Wrote}:Suggestions for fixes (Note none of this has been tested):
1) Crush and destroy boxes when they end up in anything solid, like players

Please check the latest version in git master branch. I think all other bugs regarding box crushing were fixed, except for this one:

The left one will erroneously crush due to wrong processing order (currently the boxes are sorted by their y-coordinates, then x).
Currently I can't find a way to fix it.

Please test if there are other types of bugs.

Wuzzy {l Wrote}:2) The upper box should not move in both cases since it still has the other box to rest on
3) Basically, take the average speed of all conveyor belts on which the box is on. Set X=0 and N=0. For each pixel of the bottom of a box, check if it's directly on a conveyor belt. If yes, add the speed of that pixel to X and add 1 to N. The final speed of the box is X divided by N. To prevent the speed becoming 0 due to rounding errors, force the minimum speed to be 1 (or -1, depending on direction) if X does not equal 0.

Not implemented yet.
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

I found a new bug:

The moving block will move left and right, pushing the bottom box away. As soon the stack of boxes falls, the top box will be destroyed.

20cc163f6e0084b6409876cb406e8fb469c86e30
Bitcoin contributions welcome: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)

Wuzzy

Posts: 908
Joined: 28 May 2012, 23:13

### Re: Box physics problems

Wuzzy {l Wrote}:I found a new bug:

The moving block will move left and right, pushing the bottom box away. As soon the stack of boxes falls, the top box will be destroyed.

20cc163f6e0084b6409876cb406e8fb469c86e30

I think it's fixed in 97f5782. However I prefer rewrite the collision resolving code for pushable blocks completely
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

Finally I think I fixed all of the bugs regarding box squashing, by implementing topological sort. Please test that if there still are any bugs or regressions about it.
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

I am unable to find any other crushing-related bugs. But TBH, the box crushing effect looks odd. Does MnMS still use the same GFX as for fragile blocks?

The other problems remain (Stonehenge, conveyor belt; see 1st post).
Bitcoin contributions welcome: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)

Wuzzy

Posts: 908
Joined: 28 May 2012, 23:13

### Re: Box physics problems

Wuzzy {l Wrote}:But TBH, the box crushing effect looks odd. Does MnMS still use the same GFX as for fragile blocks?

Yes. I remembered that you had provided an alternative crushing animation here. However IMO it doesn't look good either.

Can you compare these two animations and give a feedback? BTW here I provide a modified version:

{l Code}: {l Select All Code}
`diff --git a/data/themes/Cloudscape/theme.mnmstheme b/data/themes/Cloudscape/theme.mnmsthemeindex 3d2dcc6..51bda9f 100644--- a/data/themes/Cloudscape/theme.mnmstheme+++ b/data/themes/Cloudscape/theme.mnmstheme@@ -768,22 +768,12 @@ block(Pushable){    }    transitionState(default,broken){       oneTimeAnimation=6,broken-      # FIXME: use fragile block broken animation for placeholder       object{          positioning(repeat,repeat)          animation=6,0-         pictureAnimation(tiles/tiles.png){-            point(150,50,50,50,1,2)-            point(250,50,50,50,2,2)-         }-      }-      object{-         offset(0,50,0,-50)-         positioning(repeat,repeat)-         animation=6,0-         pictureAnimation(tiles/tiles.png){-            point(150,100,50,50,1,2)-            point(250,100,50,50,2,2)+         pictureAnimation(tiles/boxcrush.png){+            point(0,0,50,50,1,2)+            point(100,0,50,50,2,2)          }       }    }@@ -856,22 +846,12 @@ block(ShadowPushable){    }    transitionState(default,broken){       oneTimeAnimation=6,broken-      # FIXME: use fragile block broken animation for placeholder       object{          positioning(repeat,repeat)          animation=6,0-         pictureAnimation(tiles/tiles.png){-            point(150,50,50,50,1,2)-            point(250,50,50,50,2,2)-         }-      }-      object{-         offset(0,50,0,-50)-         positioning(repeat,repeat)-         animation=6,0-         pictureAnimation(tiles/tiles.png){-            point(150,100,50,50,1,2)-            point(250,100,50,50,2,2)+         pictureAnimation(tiles/boxcrush.png){+            point(0,50,50,50,1,2)+            point(100,50,50,50,2,2)          }       }    }`

Wuzzy {l Wrote}:The other problems remain (Stonehenge, conveyor belt; see 1st post).

Coming Soon™.
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

The animation tweak is bit better than before but the color's still off, I believe.
Bitcoin contributions welcome: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)

Wuzzy

Posts: 908
Joined: 28 May 2012, 23:13

### Re: Box physics problems

Hi Wuzzy,

the (2) and (3) are also implemented, but I only implemented (3) by taking all blocks (both normal blocks and pushable blocks) into consideration, because I believe that the 2a) is too weird.

Can you check that if there are any bugs introduced by this implementation?
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

It seems to work good now. I don't think things have broken because Land of Boxes is still functional.

I found a minor thing:

If you place boxes like this:
{l Code}: {l Select All Code}
`123333`

3 boxes, each with number 1-3. Each number is 1 tile. The boxes 1 and 2 are touching.
Push box 3 to the right, and box 1 will be repelled by about 2 pixels from box 2. This is a bit strange, but doesn't seem to be serious as it's only a tiny offset. But I still mention it, just in case.

By the way: I see you added achievements. Please don't forget to update Weblate.
Bitcoin contributions welcome: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)

Wuzzy

Posts: 908
Joined: 28 May 2012, 23:13

### Re: Box physics problems

Wuzzy {l Wrote}:I found a minor thing:

If you place boxes like this:
{l Code}: {l Select All Code}
`123333`

3 boxes, each with number 1-3. Each number is 1 tile. The boxes 1 and 2 are touching.
Push box 3 to the right, and box 1 will be repelled by about 2 pixels from box 2.

Oh, this sounds not good. Can you check that if it already occurred in previous versions (e.g. one or two git commits earlier) ?

Wuzzy {l Wrote}:By the way: I see you added achievements. Please don't forget to update Weblate.

Yesterday Hosted Weblate had some quirks. I'll update pot files when they are fixed and before the next alpha (or beta) version.
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Re: Box physics problems

I tested again, and it also occurs in dadea5643ad2ae3a3a732351822724007af25491.
Bitcoin contributions welcome: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH :-)

Wuzzy

Posts: 908
Joined: 28 May 2012, 23:13

### Re: Box physics problems

Wuzzy {l Wrote}:I found a minor thing:

If you place boxes like this:

12
3333

3 boxes, each with number 1-3. Each number is 1 tile. The boxes 1 and 2 are touching.
Push box 3 to the right, and box 1 will be repelled by about 2 pixels from box 2.

...

I tested again, and it also occurs in dadea5643ad2ae3a3a732351822724007af25491.

I think I can't fix it in an easy way. There is no such bug if the player push the box to the left. If you use the moving block to push the box, then the same bug occurs, no matter if you push it to the left or right.

Also, this bug can be abused to push multiple boxes at a time, for example:
{l Code}: {l Select All Code}
`  1234P 5555 <-M->`

P is player and M is moving block, if you keep pushing block 5 and 1 to the right, you can push all the boxes 1,2,3,4 down to the ground
Some of my open source games on GitHub

acme_pjz

Posts: 663
Joined: 10 Dec 2009, 15:32
Location: PeeKing, China

### Who is online

Users browsing this forum: No registered users and 1 guest