Stutter

[justinnoah]

As the player falls, bravo likes to complain about bogus positions and moves the player up to a position it likes. This shouldn't happen. Bravo should understand how fast a player falls.

[justinnoah]

Once this is done, let's push 2.0 and get started on the 2.1 bugs.

[justinnoah]

Looking into this I have found:

In world.py bravo is setting the spawn position at (0,0,0) which then causes the player to fall into the void. level = Level(...)

Then, bravo notices through clamp testing that the player is out of bounds and place the player at a y of 32 (comment out the "def located(none)" stuff in protocol.py, you'll be placed at y=32)

Then in protocol.py at def located(none) within send_initial_chunk_location sends the player to the top of the world which sets the player up to stutter when falling

In protocol.py: any(abs(d) >= 64 for d in (dx, dy, dz)) only allows a player to fall at a speed of 64 (unknown unit/unit). If a player is dropped from the top of the world, they will indeed go faster than 64 unit/unit and that is how the stuttering happens. When the 64 unit/unti speed is broken, bravo 'corrects' it and puts the player in the position it thinks is correct causing the stutter.

Increasing the allowable fall speed to 256 seems to do the job, but another way of handling initial player position should be figured out and simply changing the allowable fall rate to a larger number is not a good way to handle this.

[justinnoah]

With level = Level(..., spawn=(0,0,0)w ...)

The player starts at 0,0,0 as shown here: http://i.imgur.com/CTfGE.png

[MostAwesomeDude]

I fixed ascend(), which is really why this entire thing is a problem. The actual speed of falling more than a few blocks could also be fixed, but I'm not really excited about fixing it without some sort of collision detection to keep people from falling into the void.