Rates Given - quadz

Pages: [1] 2
Quake / New Anticheat Release
Nice Job / Good Work Nice Job / Good Work
on May 02, 2016, 11:36:18 PM to R1CH
Hello everyone!

I've just pushed an updated anticheat.dll to the server which I believe should resolve compatibility issues with Windows 10.

Unfortunately, this means the file has changed and many anti-virus programs will begin throwing up false positives due to the packed file. Please be sure to white list your quake 2 folder or the anticheat.dll in any anti-virus / firewall or other security software.

While the auto-update should work, due to anti-virus you may need to manually update by replacing anticheat.dll with the version from https://antiche.at/files/anticheat.zip. Also note that it still might crash on the first run as the problematic code is run before the DLL self-updates.


Community Events / Re: (Ra2) Rocket Arena Royal Rumble !! Every Tue night 8:30pm-2am pst (Ra2)
Funny Funny
on May 17, 2013, 06:32:14 AM to Armor
Pretty sure his actual forum name is one of the lesser names he uses while playing.  I usually see em playing as >Near or Xana.   As far as the smart ass comments go,  welcome to tastyspleen. 

 :welcome:   :fight: :fight:   :peace:
tastyspleen.net / 90's week
on May 01, 2013, 03:06:51 AM to peewee_RotA
So yeah. I thought I'd stop by the forum, and I think that Geocities threw up on the forum home page. And a little bit on the side bar.

Not enough hampsters dancing, IMO

Quake / Re: Does anyone have a pakfile to convert your q2 sounds to q3arena sounds?
Informative Informative
on April 22, 2013, 10:01:38 PM to VaeVictis

id has all their shit just on their site lol always has
Quake / Re: Carter glitch on q2dm1?
Informative Informative
on March 23, 2013, 02:26:40 PM to Jay Dolan
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:


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:


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


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:


Someday I'll revisit that and get it totally right ;)
Quake / Re: Carter glitch on q2dm1?
Informative Informative
on March 23, 2013, 02:20:45 PM to 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:

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.


Quake / Re: Carter glitch on q2dm1?
Demonstrates Exceptional Knowlege of the Game Demonstrates Exceptional Knowlege of the Game
on March 23, 2013, 02:18:27 PM to 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.
Quake / Re: Carter glitch on q2dm1?
Demonstrates Exceptional Knowlege of the Game Demonstrates Exceptional Knowlege of the Game
on March 23, 2013, 02:16:07 PM to 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:

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:
Quake / Re: q2ctf1 windown: how i return to it?
Factually Challenged Factually Challenged
on March 06, 2013, 02:51:53 PM to Reptile
changing fps is an exploit. it allows the user to evade attacks a bit easier. (similiarly like how a player can flood a server with packets to make a laggy effect.)  also access places normally that couldn't be accessed in that way. limiting the fps on servers should be implemented if possible.  set min_fps 60?
tastyspleen.net / Re: Ratings
on February 26, 2013, 01:26:06 AM to The Happy Friar
mostly it's supposed to be fun, not tooooo serious, but i'd still be annoyed if someone just starts clicking "racist ignoramus" on random posts, etc.

Thanks for the explanation.  Marked your post as spam.   :afro:
Pages: [1] 2