BUG: svn r571 breaks pushable block behavior

[acme_pjz]

I tested it, found that the bugs regarding squashing and moving a block through scripting is not fixed but it breaks pushable block behavior. Bug occurs when you move when standing on pushable block

[Edward_Lii]

Hello acme_pjz,

I tested it, found that the bugs regarding squashing and moving a block through scripting is not fixed but it breaks pushable block behavior. Bug occurs when you move when standing on pushable block

I found the source of the bug, basically I tried to generalize the getBox method, but it didn't end up that well.
Anyway, it the pushable blocks should work properly again in svn rev. 573.

You also mention that the bugs regarding squashing and moving a block through scripting isn't fixed, could you give a test case for this.
Every block should now go through the same "squash" detection, so if a case doesn't work with scripting it shouldn't work in the same block layout without scripting.

Also when debugging the collision system it seemed that pushing a pushable block to the left will result in the player standing with a 1px gap from the block, but pushing to the right to a 2px gap.
Not sure what is causing this and if this has been the case since the start of pushable blocks...

[acme_pjz]

I mean the squashing is correct, but walking on script-controlled block is (still) incorrect, here is an example:

{l Code}: {l Select All Code}

name="Script Test"
size=800,600
tile(Block,0,100)
tile(Block,50,100)
tile(Block,200,100){
   id=block1
   script(onCreate){
      script="
      block1=block.getBlockById('block1')
      print('onCreate, test result: ',(block1==block.getBlockById('block1')))
      "
   }
}
tile(Button,100,100){
   behaviour=toggle
   id=0
   script(playerIsOn){
      script="
      local x,y=block1:getLocation()
      y=y-1
      if y>=0 then block1:setLocation(x,y) end
      "
   }
}
tile(Button,150,100){
   behaviour=toggle
   id=1
   script(playerIsOn){
      script="
      local x,y=block1:getLocation()
      y=y+1
      if y<=550 then block1:setLocation(x,y) end
      "
   }
}


When the block is moving up, walking on the block is incorrect I think we should look at the code of movable blocks and copy some code from it, maybe write some common subroutine/game logic...

[acme_pjz]

I found another bad squash bug See the attached video

[Edward_Lii]

Hello acme_pjz,

When the block is moving up, walking on the block is incorrect I think we should look at the code of movable blocks and copy some code from it, maybe write some common subroutine/game logic...

I think I know what is causing this problem and I'm afraid it's quite tricky to fix.
The velocity of a moving block is determined by it's delta movement since the last frame.
I did the same for every other block, which made squashing work and standing on it, but when the block stops the delta (and therefore the velocity) is still pointing upwards.

IMHO the best solution would be to use dx/dy for the delta box and xVel/yVel for the velocity box.
Each block has its responsibility for making sure these values are correct in the move method.
The default behaviour for non-moveable blocks should work when moving through scripting.

If all works out as planned the collision system should work in all cases regardless of the block type.

[Sauer2]

How about something like moveBlock(block1, x, y, speed) which is a reference to a C++ routine, which adds the block to a blocks-to-move list in the C++ code and have a the blocks in the list moved on the common update process?

EDIT: Forgot speed.

[Edward_Lii]

Hello Sauer2,

How about something like moveBlock(block1, x, y, speed) which is a reference to a C++ routine, which adds the block to a blocks-to-move list in the C++ code and have a the blocks in the list moved on the common update process?

Well this is an idea, but I like to have the collision routine work in all cases independent of the block types.
Basically there should be no block type checks in the collision detection part of the move method.
All collision handling should be based on the requested box types (Current, Delta, Velocity) and all blocks need to make sure they set the corresponding variables correct each frame.

[acme_pjz]

I think I know what is causing this problem and I'm afraid it's quite tricky to fix.
The velocity of a moving block is determined by it's delta movement since the last frame.
I did the same for every other block, which made squashing work and standing on it, but when the block stops the delta (and therefore the velocity) is still pointing upwards.

Yes, I also found that, and tried reset dx/dy every frame in 'Block::move()' function, but it didn't work

[Edward_Lii]

Hello acme_pjz,

Yes, I also found that, and tried reset dx/dy every frame in 'Block::move()' function, but it didn't work

The problem was that the script was executed in the move method of the player/shadow.
So the delta variables weren't reset in time.

This should be fixed in the new collision system: http://forum.freegamedev.net/viewtopic.php?f=48&t=4182
The pushable blocks on the other hand are broken...