ProQuake Dedicated V2

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

ProQuake Dedicated V2

Post by Baker »

ProQuake Dedicated Server V2: Windows Binary + Source Download 389kb

For anyone interested or just to read some features, I'm mostly releasing this in the event that R00k is interested and for anyone with interest in seeing the changelog. And doing a release means I know the last known state of the project. :D

Version 2: No client code at all. 184 KB. Just 25 c source code files. Windows. Unless R00k has a crazy server .exe experiment, this server inclusive of all known stock NetQuake server enhancements + some (except does not include R00k's cl_mute modification).

Classic ProQuake features: rcon, NAT fixed server, iplog, pq_teamscores, several ProQuake fixes against server attacks (0 sized packets, flooding, etc). R00k/Baker additions: connectmute (require a client to be connected 3 seconds before talking), RQuake server (sv_rquake 1), sv_ipmasking, FTE's anti-wallhack (sv_cullentities 1, clock fix).
V1 new features: wrote:sv_ipmasking settings level
0 = normal (66.77.88.99)
1 = mask (66.77.88.*)
2 = masked to connected clients, private to queries (other players: 66.77.88.* External query: "private" )
3 = "private" to all
4 = EXTERNALLY ANONYMOUS. Non-connected clients doing test query = names are not shown. You must be connected to see who is playing.

Bad word filter. Sure you can evade it, but you know it is there and evading it requires a conscious choice. Plus it is hard to evade and will make you look like a fool for trying ---> jerks are very self-conscious and socially concerned and getting embarrassed by others thinking they are saying stupid things will bite them socially.

RCON blackout. Try to guess rcon password 3 times and fail = for 15 minutes that ip is not allow to try again. Plus it logs offending ip to server log.

sv_frags_to_talk. Defaults to 0. Set to 1 or 2 to require 1 or 2 frags to talk to prevent players who are not really playing from being able to chat.

pq_logbinds 1 will record the ip address of all talking to file.
Could be part of a starting point for ip6, server downloads, some sort of multi-view demo support, maybe Fitz 666 support if I can determine if it can perform halfway decently over the internet.

Or maybe I do none of those things. Hard to say.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ProQuake Dedicated V2

Post by Baker »

One issue in FitzQuake 0.85 is that it can't really do standard Quake protocol 15 over a network, which means if I want to add this to ProQuake server I'll need to rework it to fix that.

The reason it can't is that it will do messages larger than 7998 or 8000 or MAX_MSGLEN especially during signon.

I see that in Fitz 0.85, it is using MAX_DATAGRAM 32000.

My understanding of the Quake network code ... which I believe to be accurate ...
MAX_DATAGRAM is only used by net_dgrm.c which is a connected client.
A local game (client = server = single player) will be using LoopBack (fake/virtual network message queue).
So I think this 32000 is wrong for a max datagram size. Now FitzQuake tries to override this with ...

Code: Select all

qboolean SV_SendClientDatagram (client_t *client)
{
		byte		buf[MAX_DATAGRAM];
		sizebuf_t	msg;
		msg.maxsize = sizeof(buf);

		//johnfitz -- if client is nonlocal, use smaller max size so packets aren't fragmented
		if (Q_strcmp (NET_QSocketGetAddressString(client->netconnection), "LOCAL") != 0)
			msg.maxsize = DATAGRAM_MTU;  // Baker note: This 1400
		//johnfitz
But I think this override is unnecessary because net_dgrm.c is going to make the decisions for a connected client. And net_loop.c will make the decisions for a single player client or game host.

Also MAX_DATAGRAM (32000) is what is being used in net_dgrm.c to decide whether to chop the message into multiple packets, using 32000 as the packet length, which isn't the intended number of DATAGRAM_MTU (1400).

Code: Select all

	if (sock->sendMessageLength <= MAX_DATAGRAM)
	{
		dataLen = sock->sendMessageLength;
		eom = NETFLAG_EOM;
	}
	else
	{
		dataLen = MAX_DATAGRAM;
		eom = 0;
	}
	packetLen = NET_HEADERSIZE + dataLen;

	packetBuffer.length = BigLong(packetLen | (NETFLAG_DATA | eom));
	packetBuffer.sequence = BigLong(sock->sendSequence++);
	Q_memcpy (packetBuffer.data, sock->sendMessage, dataLen);

	sock->sendNext = false;

	if (sfunc.Write (sock->socket, (byte *)&packetBuffer, packetLen, &sock->addr) == -1)
I'm not Mr. Networks but I wonder if this is why LAN coop clients get lag with Fitz 666 with tons of entities but the listen server client (the host client) doesn't? Because even in a LAN game the router settings should apply.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ProQuake Dedicated V2

Post by Baker »

Current:

Code: Select all

typedef enum
{
//    FitzQuake limit                     // Standard limit (WinQuake)
    MAX_EDICTS_PROTOCOL_666         = 32000,  MAX_EDICTS_PROTOCOL_15        =  8192,
    MAX_FITZQUAKE_SANE_DEF_EDICTS   = (cvar), MAX_WINQUAKE_SANE_DEF_EDICTS  =   600,

    MAX_FITZQUAKE_MSGLEN            = 32000,  MAX_WINQUAKE_MSGLEN           =  8000,
    MAX_FITZQUAKE_DATAGRAM          = 32000,  MAX_WINQUAKE_DATAGRAM         =  1024,

// per-level limits
    MAX_FITZQUAKE_BEAMS             =    32,  MAX_WINQUAKE_BEAMS            =    24,
    MAX_FITZQUAKE_EFRAGS            =  2048,  MAX_WINQUAKE_EFRAGS           =   600,
    MAX_FITZQUAKE_DLIGHTS           =    64,  MAX_WINQUAKE_DLIGHTS          =    32,
    MAX_FITZQUAKE_STATIC_ENTITIES   =   512,  MAX_WINQUAKE_STATIC_ENTITIES  =   128,
    MAX_FITZQUAKE_TEMP_ENTITIES     =   256,  MAX_WINQUAKE_TEMP_ENTITIES    =    64,
    MAX_FITZQUAKE_VISEDICTS         =  1024,  MAX_WINQUAKE_VISEDICTS        =   256,

    MAX_FITZQUAKE_LIGHTMAPS         =   256,  MAX_WINQUAKE_LIGHTMAPS        =    64,

    MAX_FITZQUAKE_MAX_EDICTS        = 32000,  MAX_WINQUAKE_EDICTS           =   600,
    MAX_FITZQUAKE_MODELS            =  2048,  MAX_WINQUAKE_MODELS           =   256,
    MAX_FITZQUAKE_SOUNDS            =  2048,  MAX_WINQUAKE_SOUNDS           =   256
} engine_limits;
Probably fixes?

Code: Select all

typedef enum
{
//    FitzQuake limit                     // Standard limit (WinQuake)
...
    MAX_FITZQUAKE_MSGLEN            = 32000,  MAX_WINQUAKE_MSGLEN           =  8000,
    MAX_FITZQUAKE_DATAGRAM          = 1400,   MAX_WINQUAKE_DATAGRAM         =  1024,

    MAX_FITZQUAKE_DLIGHTS           =  128,  MAX_WINQUAKE_DLIGHTS          =    32,
...
} engine_limits;
Note the DLIGHTS increase from 64 to 128 isn't really related to client/server .. FitzQuake 0.85 as it currently is doesn't really support 64 dlights, just 32 (before MH fix, and after MH fix does 128 fine.)
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ProQuake Dedicated V2

Post by Baker »

Just changing the MAX_DATAGRAM does appear to work and should in theory be optimal. (Adjusting it per protocol.)
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ProQuake Dedicated V2

Post by Baker »

Host_Error Versus Sys_Error

Host_Error is anything that can safely be solved by dropping to console during a Host_Frame (disconnecting client + shutting down server).

This means:
1. QuakeC errors. All of them!
2. Server errors. All of them.
3. Client game errors. All of them.

Except: If some action can't be rolled back. An example would be any use of malloc followed by an error (never gets freed) or opening a file (never gets closed).

Some things are not obvious:

Sound errors can't drop to console because the menu has sound and using the menu does not require a map be loaded.

I think the original Quakeworld source code had this far better in the source code than NetQuake.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
r00k
Posts: 1111
Joined: Sat Nov 13, 2004 10:39 pm

Re: ProQuake Dedicated V2

Post by r00k »

nice minimalist server exe
once i added protocol 666 i can not host a dedicated server yet qrack isnt a dedicated server engine
which sux as it has in the past been able to host a server
maybe some day ill fix this but pq works(required) for my mods so im not in a hurry. to fix qrack for that

im currently mimicing crmod and creating a rank command and saving match stats over level change if need be engine side ill provide sources
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ProQuake Dedicated V2

Post by Baker »

r00k wrote:nice minimalist server exe
once i added protocol 666 i can not host a dedicated server yet qrack isnt a dedicated server engine
which sux as it has in the past been able to host a server
maybe some day ill fix this but pq works(required) for my mods so im not in a hurry. to fix qrack for that
I modelled what I was doing a bit after Quakeworld, FTE, FuhQuake and Quakespasm. I'm about to add Fitz 666 to it.

I managed to "fix" FitzQuake 0.85's ability to host protocol 15 games. It was a bit of work getting it 100% "by the book". metlslime's work in protocol 666 was A+, and by solving this mystery, I've levelled up a bit more in the network stuff.
im currently mimicing crmod and creating a rank command and saving match stats over level change if need be engine side ill provide sources
Ah some rivalry renewed with your arch-rival, JPG :D Looks like it motivated you. :lol:

re: Fitz 666 .... I need to give a test on a 600 monster map on LAN in coop and see if it can still lag (shouldn't happen on a LAN) after fixing up the network code. I'd like to believe it won't lag on LAN with high monster counts now, but until I know for sure .... Like if it lags on LAN, it sure won't be any better on the internet.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: ProQuake Dedicated V2

Post by Spike »

Baker, if you want a solution to datagram size limitations, you'll need something like:
http://sourceforge.net/p/fteqw/code/432 ... deltas.txt
Note that its not fantastically different from how DPP5+ sends entities.
That doc *should* give enough info to implement the extension, and will work fine as an upgrade over either protocol 15 or 666 (you may still want 666 as the underlying protocol to provide the svc_clientdata stat changes).
Note that nq support for this protocol is still fairly new in fte, so if you want to test it with an existing implementation be sure to use the current test build of fte.

Anyway, point is that retaining entity state from one frame to the next, resending only when something has changed (which 666 does not do - entities are resent from baseline even when they're idle) will save you both bandwidth and fragmentation-induced packetloss.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: ProQuake Dedicated V2

Post by Baker »

Spike wrote:Baker, if you want a solution to datagram size limitations, you'll need something like:
http://sourceforge.net/p/fteqw/code/432 ... deltas.txt
Note that its not fantastically different from how DPP5+ sends entities.
That doc *should* give enough info to implement the extension, and will work fine as an upgrade over either protocol 15 or 666 (you may still want 666 as the underlying protocol to provide the svc_clientdata stat changes).
Note that nq support for this protocol is still fairly new in fte, so if you want to test it with an existing implementation be sure to use the current test build of fte.

Anyway, point is that retaining entity state from one frame to the next, resending only when something has changed (which 666 does not do - entities are resent from baseline even when they're idle) will save you both bandwidth and fragmentation-induced packetloss.
I probably should do as you suggest. Thanks!

Note: My solution to the above was extremely close, but no cigar. I can and have fixed the NetQuake support, but correctly fixing how Fitz 666 sends the packets = no. It's too intertwined to do so in a timely manner. :(
Baker wrote:Now FitzQuake tries to override this with ...

Code: Select all

qboolean SV_SendClientDatagram (client_t *client)
{
		byte		buf[MAX_DATAGRAM];
		sizebuf_t	msg;
		msg.maxsize = sizeof(buf);

		//johnfitz -- if client is nonlocal, use smaller max size so packets aren't fragmented
		if (Q_strcmp (NET_QSocketGetAddressString(client->netconnection), "LOCAL") != 0)
			msg.maxsize = DATAGRAM_MTU;  // Baker note: This 1400
		//johnfitz
I now understand what this unused code in Fitz 0.85 was trying to address. Haha :)
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Post Reply