Finally figured out why players were so special in gimping the wallwalk code. Turns out the server sends player positions snapped to whole integers. The bandwidth-saving effects of doing this are dubious as players tend to move continuously and thus new positions will be sent out every frame anyway. The real effect of this is that the client will mispredict whenever it comes into contact with another player. Also, as part of the tinkering I removed some code from the wallwalking function that should have stayed put, I have added it back in. This commit also fixes the "jittery bouncing while sitting on top of another player" glitch.

1 files changed, 9 insertions, 1 deletions

diff --git a/src/qcommon/q_shared.h b/src/qcommon/q_shared.h
index e23f8725..667fba73 100644
--- a/src/qcommon/q_shared.h
+++ b/src/qcommon/q_shared.h
@@ -452,7 +452,15 @@ typedef struct {
 #define Vector4Copy(a,b)		((b)[0]=(a)[0],(b)[1]=(a)[1],(b)[2]=(a)[2],(b)[3]=(a)[3])
 #define Vector4Add(a,b,c)    ((c)[0]=(a)[0]+(b)[0],(c)[1]=(a)[1]+(b)[1],(c)[2]=(a)[2]+(b)[2],(c)[3]=(a)[3]+(b)[3])
 
-#define	SnapVector(v) {v[0]=((int)(v[0]));v[1]=((int)(v[1]));v[2]=((int)(v[2]));}
+// DO NOT USE: Snaps differently depending on whether number is positive or 
+// negative! -0.5 and 0.5 both snapped to zero!
+//#define	SnapVector(v) {v[0]=((int)(v[0]));v[1]=((int)(v[1]));v[2]=((int)(v[2]));}
+
+// Snaps the vector to the floor value always, ignoring any weirdness from
+// snapping negative versus positive numbers
+#define Floor(f) ( (f) >= 0.f ? (int)(f) : -(int)(-(f)) )
+#define SnapVector(v) {(v)[0]=Floor((v)[0]);(v)[1]=Floor((v)[1]);(v)[2]=Floor((v)[2]);}
+
 // just in case you do't want to use the macros
 vec_t _DotProduct( const vec3_t v1, const vec3_t v2 );
 void _VectorSubtract( const vec3_t veca, const vec3_t vecb, vec3_t out );