Carter glitch on q2dm1?

[Electfried]

I've seen some crater glitchs on q2dm1 and this one was farby one of the weridest ones I encounterd. I did a jump and landed on the lamp post as shown in the picture and I didn't realize I could'nt move and I tried to get out when I reconized I was stuck, I jumped 5 times and move and I hit the floor really fast and cratered. Is it possible that I discovered a retarded crater glitch on the map edge other than the SSG one and the side one near upper RL? The circled red part is the jump area I did and the black circled is the lamp I had got stuck on.

[[BTF] Reflex]

I'd say chances are good you did..

There is another spot, where the wall curves away behind the armor crate.
You can use the wall there to fake a double jump sound.

[VaeVictis]

i always love messing with those spots it fucks people up sound wise lol

[ex]

There's some pretty funny ones on dm3 too (under rail/slime area).

[fdrjk]

It's even funnier doing it on forkjumping in Poland. 

[Electfried]

I woder how they're done, not long ago fader you have a bug on one map where you crated on a bbox

[Jay Dolan]

Bugs like this are all a consequence of floating point math done at 32 bit precision and / or large time intervals. The way that Quake works, basically everything from physics interactions to determining visible surfaces relies on calculating plane-sidedness (dot-product of origin or view vector against plane / surface normal vector, offset by plane distance).

Physics interactions in Quake happen once every client-packet for players (variable, generally 8-30ms) or, for AI and items, once every server-packet (100ms fixed). That's plenty of time for collisions to fall through the cracks, so to speak, particularly for fast-moving objects (ever shoot a rocket through a really thin wall?) On top of that, 32 bit floats provide plenty of precision loss for near-misses to be counted as collisions and vise versa.

Where something should have hit and slid along the wall or maybe exploded, it instead passes [partially] through the wall. For rockets, this is generally harmless unless the wall is very thin. For grenades, they might stick to the floor in unusual ways. In the case of your player model, passing only partially through the wall results in you being stuck inside the wall at the very next frame.

The player movement code doesn't cope with these conditions, and continues to build up bounce-off velocity (which, under normal circumstances is what keeps you running at normal speed when you intentionally run along walls). When that bounce-off velocity finally builds to a high enough value to again trigger a missed collision with the wall you're stuck in, you shoot out of the wall at a ridiculously high velocity and instantly crater

Math is fun.

[haunted]

Are you referring to the actual ORIGIN on the map, as in if it were a 3 dimensional graph? Or are you referring to the POV vector(straight in front of you, horizontal vector component to djing, etc.) as being synonymous to the origin?

and I guess there's plenty of normal forces/vectors in q2 to counteract the simulated gravity......but......IS there a simulated vector/force to counteract the "pull" the origin has on your model?

that's not too related with the aim of your post, but if you could, clarify the dot product usage for me and elaborate on the last paragraph when you are bored.

[Jay Dolan]

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#L142

The 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

[haunted]

The origin does have a pull though I'm pretty sure.

http://forum.tastyspleen.net/quake/index.php?topic=16869.0

[Jay Dolan]

Right, well, there you have it. His post asserts some force without an explanation, and I just explained it :>

Higher framerates means more client frames and thus more pmove() calls for your player. Each pmove() in turn results in one or more calls to Pm_SnapPosition(), and therefore more "nudges" per second, or a stronger "pull" towards the origin.

What's funny is that id never anticipated that code having any curious effects on movement. I mean, in '96-7, when everyone ran at 30fps or less, it didn't really. It didn't dawn on me until you mentioned it, either.

PS- They didn't even get the coordinate system right in that post 

[fdrjk]

nerds

[|iR|Focalor]

Re: Carter glitch on q2dm1?

Yes, I agree. The Carter administration was such a huge fuck up that it's horrendous effects were felt 20 years later in video games. I certainly didn't vote for him. But I would definitely elect him to be fried. I know that's a serious alligation.

[Electfried]

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#L142

The 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.

[Jay Dolan]

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.

Snap position is called after every single pmove, both server-side for your authoritative movement, and client-side for prediction. The purpose of Pm_SnapPosition is to reduce the precision of your coordinates to 16 bit integers so that they may be transferred over the network in half the space. In 1997, saving 6 bytes per packet was worthwhile.

Since simply rounding your coordinates to the nearest integer might place you inside the world model (or other solid), PM_SnapPosition tries several "nudges" to push you into a safe space. These nudges favor moving your player towards the origin rather than away from it.

By applying gravity as constant acceleration in negative Z, I just mean that your Z velocity is constantly receiving gravity as a function of time when you are not categorized as being on the ground:
http://jdolan.dyndns.org/trac/browser/quake2world/trunk/src/pmove.c#L878

By inverted plane distances, I just mean that Carmack chose to use negative plane distances. Other engines don't. He also chose to use clockwise plane windings -- most other engines use counter. But it really doesn't matter; in the case of Quake, you subtract the plane distance instead of adding it when determining sidedness. As LordHavoc once told me:

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