Messages

1

Quake / Re: Quadz, the Loquaciously Multiloquent Member

« on: July 11, 2021, 07:16:42 PM »

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: NEW dm/ffa/ctf map DUST 2 from counterstrike

« on: January 11, 2021, 12:48:47 PM »

Pretty cool! Did you make this?

3

Quake / Re: R1Q2 Mac Os X and Linux

« on: November 12, 2019, 09:27:16 AM »

No, you can still run OpenGL apps just fine on macOS. But it looks like (to me) that build is not correctly setup to support macOS. It's looking for opengl32.so, which it will not find anywhere on Mac. It should be looking for libOpenGL.so.

Why not run a Quake2 build that is actually maintained for macOS, like Q2Pro or Yamagi?

4

Quake / Re: quake 2 Skill rater app

« on: April 02, 2018, 05:35:14 PM »

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.

5

Quake / Re: Is it possible to intentionally lag your client?

« on: April 02, 2018, 05:33:37 PM »

It's entirely possible to write a lag bot that would suspend outgoing packets with a bind. I think a poor man's approach to this years ago was just to `cl_maxfps 0` every few seconds. The client would temporarily freeze in place because no packets would be sent to the server until the frame cap was restored to a reasonable value.

I actually added something like this to Quetoo for simulating network latency on localhost, which is helpful when changing the network protocol, packet rate, etc. This intentionally adds configurable lag and drift to the loopback packet buffer (localhost only), but it'd be pretty straightforward to do this with the actual net socket as well:

https://github.com/jdolan/quetoo/blob/master/src/net/net_udp.c#L74

6

Quake / Re: Focalor's SS Wehrmacht Pak V2

« on: April 02, 2018, 05:24:40 PM »

Nice clip art, you tiki-torch-wielding alt-right fuck.

The models are actually pretty good.

7

Quake / Re: Quake 2 netcode and tick rate

« on: December 08, 2017, 12:00:59 PM »

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.

8

Community Events / Re: Regular Quake 2 DeathMatch no Mods. Maps Q2dm1-Q2dm9

« on: October 09, 2017, 12:38:47 PM »

Dafuq is q2dm9? You mean match1? 

9

Quake / Re: Quake 2 netcode and tick rate

« on: July 17, 2017, 09:39:14 AM »

You know what? I just checked the Quake2 source code, and Q2 at least handled entity events (footsteps, falling sounds, respawn, etc) correctly by dispatching CL_FireEntityEvents at the end of CL_ParseFrame. I must have moved that call to somewhere downstream over years of refactoring. Probably had something to do with introducing a client-game module (ala Quake3), or attempting to multithread the client.

 

There may be other instances that do still affect vanilla Quake2 as described above. I guess my only advice is to make sure your client correctly deals with ALL server frames, and not just the last one to arrive at any given client frame.   

10

Quake / Re: Quake 2 netcode and tick rate

« on: June 04, 2017, 06:54:00 AM »

The client has some issues with increasing the framerate as well. Namely:

 * Simulation time is hard-coded to 100ms frame interval, which influences model animations, particle trails, etc..
 * Stair prediction (interpolation) is also hard-coded to 100ms interval
 
Lastly, and probably the most harmful thing that I noticed in refactoring Quetoo to run at 40Hz, is that while the client will correctly parse all pending server packets at each client frame, it actually only _processes_ the most recently received server frame. At 10Hz, it's rare to receive multiple server frames in a single client frame, because most clients are running at 6x or 12.5x the server frame interval. It would only happen on choppy, poor-quality connections, which already yield a lossy experience anyway.

But at, say, 40Hz, with a 60Hz v-sync client, it happens all the time: a client frame will read two or more server frames from the network. What Quake2's client would do in this case, is basically drop the first server frame to the floor, doing nothing with it, and interpolating only the last received frame. This would result in missed animations, missed sounds, missed effects, etc.. It was actually really problematic, and took me a while to understand.

The solution I came up with for this is to ensure that every server frame is interpolated, even if its result doesn't make it to the screen. When parsing a new server frame, I check if the previously parsed frame has been interpolated. If it has not, I force a "lazy lerp" on it. This ensures that animation changes, entity events (landing sounds, footsteps, etc), ..never fall through the cracks:


https://github.com/jdolan/quetoo/blob/master/src/client/cl_entity.c#L242

Anyway, yea, there's really no way to change Quake2's tick rate without some serious surgery, and willingness to cut compatibility with binary-only mods.

11

Quake / Re: QueToo/Quake2 2017 Steam Green Light!

« on: March 08, 2017, 04:37:57 AM »

Thanks for the support, guys! 

12

Quake / Re: Any pre made server packages out there?

« on: September 19, 2016, 07:57:21 AM »

I get the impression that he's looking for a Windows GUI where he can drag and drop maps into a rotating list, choose a mod from a dropdown, etc. As far as I know, nothing like that exists from the last decade or so. You might be able to find a very, very old Q2 server frontend. But in general, if you want to run a server with a handful of custom maps and a couple of mods, it's really not difficult to do this "manually" as Qwazy describes.

13

Quake / Re: Focalor's Quake1 Pak for Quake2

« on: August 05, 2016, 06:23:59 PM »

Another thing... I think I've seen clients out there packaged in zips or rars or exe installers that contain the shareware files which make it possible to play Q2 multiplayer without a complete version of the game. If the shareware files are bundled along side the client in the same container, and they aren't in their original standalone form, that's kinda ALSO against the license in the shareware, right? That's as bad or worse than what I've done, and I don't see id Software going after those people.

Yea, older versions of my Quake2 builds for Mac did just this. The internal layout of an OS X .app bundle is pretty foreign, maybe even intimidating to your average user. And so rather than force the ~200 people who download the thing to fumble through a command line for the first time in their lives, I decided to include the shareware .pak files for convenience. I know that this technically violates the Quake2 EULA, but sometimes, you just gotta do what's right

I've since moved to an rsync distribution channel, with a client script that prompts users to accept the Quake2 shareware license before it downloads any data.

14

Quake / Re: Why Q2Pro over R1Q2

« on: July 11, 2016, 08:03:01 AM »

All conventional Quake engines are implicitly limited to 1000fps, because the resolution for frame duration is in milliseconds. That is, until 1ms has elapsed, the main loop will not dispatch another frame:

https://github.com/jdolan/quetoo/blob/master/src/main/main.c#L285

As for eeking slightly higher jumps out of Q2Pro than R1Q2, that would have to do with your packet (outgoing command) rate, not your video framerate. Packet rates of 125hz have been mathematically verified to yield the most favorable player movement (i.e. rounding errors). This will be the same in any engine, because it's a function of the server. So as long as your system is able to maintain 125fps in a given Quake2 engine, all of the same movements are possible.

I feel like we're beating a dead horse, here.. but I'd like to keep the discussion based in observable data rather than anecdotes and subjective impressions. If you have a great game in Q2Pro or AprQ2, that doesn't mean the client helped you win. The quality of your connection to the server at that particular moment could have a very real affect on your perception of the quality of the experience. I think that's a much stronger factor than the client you happen to be running.

15

Quake / Re: Why Q2Pro over R1Q2

« on: July 10, 2016, 07:27:11 PM »

The way that different engines handle asynchronous framing (cl_async 1 on R1Q2, similar cvars on others) can change the way that the client "feels" in terms of latency, but in general, you're right. By capping your framerate and tweaking input vars (sensitivity, m_filter, ..), you can make any of the popular clients "feel" identical.

Side note, if anyone wants to try Q2Pro on OS X, please give this a whirl. It requires that you have pak0.pak and friends installed in ~/.quake2/baseq2.

http://quetoo.org/files/Q2Pro.dmg