* remove roll
* optimise for size
* new protocol data type: unsigned integer with known size
* highres yaw encoding
* double resolution for pitch angles -30°..30°
* half resolution for pitch angles -90°..-30° and 30°..90°
* proper rounding for pitch and yaw values
* same resolution for yaw and pitch for both pos packet types
* restore transmission of the velocity vector
break up shiftgametime() time jumps into 5-second jumps and five 1-second
jumps for the last five seconds
rename respawnoffset to lastdeath (because that's what it is)
rename clientside nextmillis to skipmillis (because that's what it does)
- remove sensitivity training (should be rewritten in cubescript, if
actually required)
- more documentation on mouse sensitivity parameters
- some renaming
DOCREF findsens
- split into strafe roll (maxroll) and damage roll (maxrolleffect)
- locally recompute remote players roll (can be removed from pos pkt)
- fix maxrollremote
DOCREF maxroll maxrolleffect maxrollremote
It fixes the problem, that during spectating in 1st person view,
when spectated player collided (for example with wall) and crouched,
then his crouches weren't visible for player1.
The condition appeared on 32-bit g++ builds with -O3. Apparently, due to
optimisations, the player1 location vector was kept in FPU registers
during collision checks - and the written-to-memory float values gave
different results in the next round.
The fix forces a write to memory and a readback before the collision
checks. An alternative fix would be, to compile physics.cpp with the
switch -ffloat-store, but that would cause a bigger performance hit.
* sort colored lights behind white ones to avoid a light bug
* sort all clipped entities to the end of the list to speed up physics
* sort all pickups and playerstarts to use smaller index numbers to
use less bandwidth
backpedal 1/42 of a microstep to get out of the way of rounding errors
(clip ents are not supposed to have seams, but at least GCC builds
with -O3 seem to also require a little here - so, 1/333 for clips)
instead of using a constant (and always wrong) speed, use the same part
of the movement vector that x- and y- slides use
(sadly, this fix seems to raise problems with the previous "fix sliding
along corners" commit, which seems to have liked the constant speed...)
* properly rotate the player hitbox
* add "corner bounce" (doesn't work flawlessly - but it's probably as
good as possible with this kind of physics engine)
new physics for tagclipped corner cubes:
* corners between non-solids: tagclips extend the corner
(visualisation does not reflect that, yet)
* corners between solids: fully clipped (like before)
* fix the old check for different jump start heights as requirement
for doublejumps
* better handle multiple binds for the "jump" command
* delay relaxed floorclamping for crouching
* remove some redundant code
Instead of applying 25% bonus speed with every executed doublejump (with
potentially unlimited top speed), limit the reachable max speed to 125%
of regular full speed.
This limits regular gameplay only marginally but removes a lot of cheat
potential.
kai
Bukz