VaeVictis:i find it funny that you even consider grammar a sign of intelligence, that itself is a very uneducated claim

Re: Carter glitch on q2dm1?

Okay, a couple key concepts for understanding Quake:Quake uses a right-hand coordinate system where positive X is "north" positive Y is "west" and positive Z is "up".Quake BSP is a partitioning of 3D space by two volumes, recursively, until every volume is convex. The barriers that describe these volumes are planes.Planes in BSP are described by a normal vector (direction in 3D space) and a distance (offset from origin, or the negated center of the "surface", if it helps to visualize it that way).So an axially-aligned (read: flat, non-sloped) floor surface that's at -128 units would have a plane definition of (0, 0, 1) @ 128. That's a normal vector of positive Z and a distance of 128 units. Quake planes use inverted distances for some reason.The dot-product of any two vectors essentially determines if they face each other, and how much. Vectors with a dot-product less than 0.0 face one another (read: collide), while those with dot-products greater than 0.0 would never intersect. But that's assuming the vectors start at the origin (0, 0, 0). So each plane's distance from the origin must be factored into the equation to determine sidedness correctly (consider two surfaces where one faces east and the other west, but they are "behind" each other -- e.g. the outward facing surfaces of your average column or pillar or door).You can find this "dot-product minus distance" test throughout the Quake code base, in everything from pmove to the BSP compiler to the renderer:http://jdolan.dyndns.org/trac/browser/quake2world/trunk/src/client/renderer/r_bsp.c#L142The origin has no "pull" on your player's position in pmove. There is intentional precision loss (conversion of 32 bit floating point to 16 bit integer) to save network bandwidth. And gravity in Quake's pmove is nothing more than a constant acceleration applied in negative Z (which is probably the least crude approximation in all of pmove.c ).Hope this helps!Edit: So, after I wrote this, I thought for a moment about the intentional precision loss in pmove (converting to 16 bit ints), and re-checked the code. It does in fact favor rounding your coordinates towards the origin. I don't think this could be considered significant, but there is not a measure in place to counter it:http://jdolan.dyndns.org/trac/browser/quake2world/trunk/src/pmove.c#L993

Useful information, I didn't know that the X Y Z cordinates had any affect on a snap postion. I thought snap postion was only caused when a played did a noclip through a wall and disabled noclip. And you say that pmove is a consistent acceleration applied on negative Z which I don't know what that is. I honsely thought of -x -y -z when you said Negative Z. And how does Quake 2 use inverted plane distances? And you're saying quake which I'm sure you're perfering too quake 2 instead of quake. I honsetly ask alot of questions.

The key to a correctly working game engine is to have an even number of sign errors.