Instantly awaiting gamestate

With q3/ioq3, it normally takes 3 seconds for the “awaiting challenge” message to turn into awaiting gamestate. However, there are servers like (ctf.cromctf.com) where it instantly connects.

There’s also a fork of ioq3 called Quake3e which has it so its dedicated server connects clients instantly too.

I was wondering how to achieve this same effect. And by default, why does it take multiple seconds for the awaiting challenge process to take place and not instantly like these other servers?

1 Like

I actually figured this out on my own — sv_client.c

Inside of:

void SV_GetChallenge(netadr_t from)

change:

#ifndef STANDALONE

to:

#if !defined(STANDALONE) && defined (USE_AUTHORIZE)
1 Like

The guys at quake3e are rather receptive to sharing their code. They use MSVC
and might be willing to work with you… at least they offered to work with me. It is seems popular with some of the experienced crowd still playing.
Seems like you have things well in hand, but I thought I’d mention it just FYI.

Thanks for the research!

My findings

There is a comment in ioquake3 on SV_GetChallenge apparently saying that the challenge is disabled for IPv6 servers:

ioquake3: we added a possibility for clients to add a challenge
to their packets, to make it more difficult for malicious servers
to hi-jack client connections.
Also, the auth stuff is completely disabled for com_standalone games
as well as IPv6 connections, since there is no way to use the
v4-only auth server for these new types of connections.

ioquake3 added IPv6 support, so what could be tried is, as long as you can connect to the server with IPv6, set net_enabled 7 to enable IPv4, IPv6, and prefer IPv6 over IPv4. I, however, was not able to test this.

Local servers are apparently also exempt, which is confirmed by my experience, and this comment:

Drop also for addresses coming in on local LAN


I though that this delay could be related to sv_floodProtect, but testing shows that this is not the case.
I also tried using server password


So far I have not managed to get rid of this delay by changing config variables.

My use case

I was wondering about this constant delay in my project GitHub - WofWca/quake3.xdc: A webxdc (in-chat mini-app) version of Quake III Arena (for of GitHub - jdarpinian/ioq3: Emscripten support for ioquake3, the community fork of Quake III Arena), where all clients are basically trusted, so there is no need for any kind of authorization.