Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Jay Dolan

Pages: [1] 2 3 4 5 6 7 8 9 10 11 ... 42
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.

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:

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. ;)

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.

Dafuq is q2dm9? You mean match1?  :???:

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.   :beer:

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:

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.

Quake / Re: QueToo/Quake2 2017 Steam Green Light!
« on: March 08, 2017, 04:37:57 AM »
Thanks for the support, guys!  :ilysign:

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.

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.

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:

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.

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.

Quake / Re: Why Q2Pro over R1Q2
« on: July 08, 2016, 02:33:34 AM »
No, that's what I was saying. You are free to download the R1Q2 source and modify it (e.g. fix a bug, add a wallhack, whatever you want). But you would not have Anti-cheat support. R1CH keeps the AC secret sauce under lock and key, which is unfortunately necessary for it to be worth anything.

Quake / Re: Why Q2Pro over R1Q2
« on: July 07, 2016, 12:20:46 PM »
I don't think he was accusing you of anything with juxtaposing those quotes, claire. I think he was just demonstrating the vast difference in opinion on open vs closed source clients. It's worth noting that anyone could add a trivial wall hack into R1Q2 and compile that, as well -- it just wouldn't have AC. The source is available for R1Q2, too, Muerte, and as it should be. A basic wall hack would involve 2 lines of code to toggle GL_DEPTH_TEST when drawing entities. Oops. Now the cheaters will win!

Quake / Re: Why Q2Pro over R1Q2
« on: July 04, 2016, 05:34:44 AM »
There's something to be said for maintained software. Even if R1Q2 had features or functionality over Q2Pro, which would be a hard case to make, I personally would still opt for the one that is actively maintained. Disclaimer: I don't use either :)

Pages: [1] 2 3 4 5 6 7 8 9 10 11 ... 42