* 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.
When both "forward" and "backward" keys are pressed, now the action
matches the last pressed one. Now the keys work on the ladder exactly
as with regular movement.
Check printf-like functions like conoutf, if format strings and argument
lists match.
This commit also fixes a lot of code parts that actually had mismatching
argument lists - or did things, that this check does not like.
numtime() was rewritten in an ugly but very portable fashion (it's
recommended to stay away from "long long" format entries, because errors
usually only come up at runtime).
(some code was copied from sauer)
The commit increases very much speed of demo rewind and also prevents
AC freeze for gamespeed = 1000.
It may degrade physics for gamespeed = 1000 on very low end machines.
Attribute 7 of clip- and plclip-entities now allows four different shapes
for the clips:
0: basic rectangular (like in older AC versions)
1: tilted in direction of x-axis
2: tilted in direction of y-axis
3: rotated by 45 degrees
The shapes 1 and 2 use the value of attr6 as slope angle.
The player only can walk upwards a tilted clip, if the height (attr4) is
at least 0.6 cubes. Slopes steeper than 5.0 can not be walked up (same
maximum step size as for sloped map geometry).
Mappers, please keep in mind: especially tilted clips are more expensive
than regular clips, but they are much cheaper than stairs built from a
bunch of regular clips. Large and small clips cost exactly the same, so
try to combine clips to keep the total number down.
Interpret the values for entity yaw angles and clip entity sizes as
fifths or tenths of cubes or degree.
This makes some entity attributes appear as float values to the user.
The map file still only keeps integer values - but now they are
interpreted differently - for example, a health pack elevation value of 6
now means 0.6 cubes instead of 6.
Note: the scaling factors are hardcoded - use ENTSCALE5 or ENTSCALE10
whereever possible. For generic entity editing, the scaling values are
also stored in entscale[] - but that table can not be changed without
breaking the map format! This scaling is similar to the treatment of the
vdelta values of map cubes.
Interpret the waterlevel value as tenths of a cube.
This makes the waterlevel variable a float value to the user, while the
map file still stores an integer value - but now it is interpreted
differently - for example, a waterlevel value of 123 now means 12.3 cubes
instead of 123. Old map files are converted during loading.
Note: the values of waterlevel and hdr.waterlevel need to be in sync.
DOCREF waterlevel
drian