Rates Received

1

Quake / Re: Quadz, the Loquaciously Multiloquent Member

Rock On

How awful. I did not have the pleasure of meeting quadz in person the one time I attended QuakeCon, but I’ve “known” him for 15 years. When I was getting started with Quetoo, he was supportive, knowledgeable, and generous with both his time and resources; answering many of my stupid questions and offering hosting. I used to spend a lot of time on this forum, and I always admired how he moderated it and dealt with all of the bullshit fairly and with an even temper. I could never have done that. The community has lost a great one. I will certainly remember him.

2

Quake / Re: quake 2 Skill rater app

Funny

There is already an app that ranks Quake2 skill level. It's called Quake2. When you play against people who are better than you, their score is higher than yours. You should try it.

3

Quake / Re: Quake 2 netcode and tick rate

Demonstrates Exceptional Knowlege of the Game

Yea, I mean, it sounds like the connection you had to that server became saturated with the higher packet rate. A lousy connection would probably do better with fewer, fatter packets than with 4 times as many packets that are, individually, a little smaller. Might be interesting to fire up a Quake3 server (30Hz, I believe) to see how that performs over the same connection.

4

Quake / Re: reals new Red Pak!

Frag Hall of Fame

Hehe. Q2W is and will always be 100% free and open source. It's goal is to borrow some of the best aspects of the Quake series and meld them into a game that is, while better in many regards, still undeniably Quake2. We should chat sometime when your pak is complete, if you're still looking to work on that kind of stuff.

5

Quake / Re: Quake 2 Map question

Whoosh! You done missed the joke thar Cletus!

I started mapping with Qoole in 1999, and then learned QeRadiant in 2000. I guess, having learned it when I was still a teenager, I never appreciated how odd / unintuitive it is. I've never found the mechanics of mapping to be difficult (with the exception of bending pipes) -- just the creative part

6

Quake / Re: FFA Changes?

Well-Reasoned Argument and/or Conclusion

I like dm4, too. It actually scales up to 10+ players, where e.g. dm7 is a total mess.

7

Quake / Re: Carter glitch on q2dm1?

Informative

Possibly. I'm not actually aware of being able to strafe jump noticeably faster along walls, but the "overbounce" velocity I mentioned earlier might enable that. The other thing that likely helps there is the clip against an immediate wall doesn't cost any pmove time: your movements are each time-boxed like everything in Quake. But time and distance traveled are treated as one in the same in the pmove code, so if you don't actually travel any distance, you don't burn any time. Thus, clipping against an immediate wall and picking up that overbounce is essentially free. Here's what I'm talking about:

http://jdolan.dyndns.org/trac/browser/quake2/trunk/src/qcommon/pmove.c#L119

Notice how time_left is decreased only by distance traveled -- it is not impacted by changes in your velocity vector as a result of clipping.

-----------------

To break it down a little further:

When you run into a wall, pmove attempts to clip your velocity along that plane and scale it back up to your intended speed. Here's the code that calculates how to clip along edges and applies overbounce:

http://jdolan.dyndns.org/trac/browser/quake2/trunk/src/qcommon/pmove.c#L63

And here's where that clipping is invoked (PM_StepSlideMove, the heart of Quake physics):

http://jdolan.dyndns.org/trac/browser/quake2/trunk/src/qcommon/pmove.c#L162

It's this logic (the "go along the crease" bit) that likely enables what you're describing, but it's also what hangs you up when jumping up stairs sometimes. I spent literally weeks rewriting all of this logic to try to simplify clipping and produce more fluid interactions with stairs and crates and things. This is why double-jumping is incredibly easy in Quake2World. But I only had limited success in making stairs easier to jump up:

http://jdolan.dyndns.org/trac/browser/quake2world/trunk/src/pmove.c#L133

Someday I'll revisit that and get it totally right

8

Quake / Re: Carter glitch on q2dm1?

Informative

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.

 

9

Quake / Re: Carter glitch on q2dm1?

Demonstrates Exceptional Knowlege of the Game

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.

10

Quake / Re: Carter glitch on q2dm1?

Demonstrates Exceptional Knowlege of the Game

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