Page 2 of 2

Posted: Mon Aug 23, 2010 3:42 pm
by mh
Well I'd be first to admit that there's something of a Cargo Cult element to what I did, yes. :lol:

Posted: Mon Feb 28, 2011 8:31 am
by r00k
Hate to dig up an old thread,

using the single

Code: Select all

	MSG_WriteByte (&cls.message, clc_nop);
Which seems to get lost sometimes

I've replaced it with

Code: Select all

CL_KeepaliveMessage();
which contains the same clc_nop but with better handling.

Some servers seemed to take almost 30 seconds to get to connection accepted previously, with that above change, it connects in less than 5... In some cases, the server lost the reply and just hung at accepted.

Re: NAT Fix -- Solves the "connection accepted" issue

Posted: Thu Apr 18, 2013 11:10 pm
by Baker
Here is the other part of the ProQuake client-side NAT fix in regards to connecting to a ProQuake server:

Add to qsocket_t in net.h

Code: Select all

	byte				proquake_connection;
In net_dgrm.c in _Datagram_Connect add the yellow ...
MSG_WriteLong(&net_message, 0);
MSG_WriteByte(&net_message, CCREQ_CONNECT);
MSG_WriteString(&net_message, "QUAKE");
MSG_WriteByte(&net_message, NET_PROTOCOL_VERSION);

// Tell the server we are ProQuake 3.70
// A normal Quake server only looks at the first 12 bytes of the message
// above, so only a ProQuake server reads these extra bytes.
MSG_WriteByte(&net_message, 1); // JPG - added this
MSG_WriteByte(&net_message, 37); // JPG 3.00 - added this
MSG_WriteByte(&net_message, 0); // JPG 3.00 - added this (flags)
MSG_WriteLong(&net_message, 0); // JPG 3.00 - password protected servers
Still in In net_dgrm.c in _Datagram_Connect add the yellow ...

int len = ret;

ret = MSG_ReadByte();
if (ret == CCREP_REJECT)
{
reason = MSG_ReadString();
Con_Printf("%s\n", reason);
q_strlcpy(m_return_reason, reason, sizeof(m_return_reason));
goto ErrorReturn;
}

if (ret == CCREP_ACCEPT)
{
Q_memcpy(&sock->addr, &sendaddr, sizeof(struct qsockaddr));
dfunc.SetSocketPort (&sock->addr, MSG_ReadLong());

Con_Printf ("Client port is %s\n", dfunc.AddrToString(&sock->addr));
// Client has received CCREP_ACCEPT meaning client may connect
// Now find out if this is a ProQuake server ...
sock->proquake_connection = (len > 9 && MSG_ReadByte () == 1) ? 1 : 0;
Finally in cl_input.c we need to make sure we write short angles when connected to a ProQuake server (0-65535 = 2 bytes = 16 bits) instead of byte angles (0-255 = 1 byte = 8 bits).

Except if we are playing a demo, we aren't "really" connected to a server. ProQuake server reads client angles from a ProQuake client as shorts for more precise aim.

cl_input.c in CL_SendMove, this is example is a FitzQuake example ...
for (i=0 ; i<3 ; i++)
//johnfitz -- 16-bit angles for PROTOCOL_FITZQUAKE

if (!cls.demoplayback && NET_QSocketIsProQuakeServer(cls.netcon))
MSG_WriteAngle16 (&buf, cl.viewangles);
else

if (cl.protocol == PROTOCOL_NETQUAKE)
MSG_WriteAngle (&buf, cl.viewangles);
else
MSG_WriteAngle16 (&buf, cl.viewangles);
//johnfitz
And in put this in net_main.c

Code: Select all

qboolean NET_QSocketIsProQuakeServer (qsocket_t *s)
{
	return s->proquake_connection;
}
This is tested and works and is the minimum client-side implementation.

Re: NAT Fix -- Solves the "connection accepted" issue

Posted: Fri Apr 19, 2013 1:08 am
by r00k
ya that sock->proquake onnection
i have 1defined as MOD_PROQUAKE

Re: NAT Fix -- Solves the "connection accepted" issue

Posted: Fri Apr 19, 2013 1:33 am
by Baker
r00k wrote:ya that sock->proquake onnection
i have 1defined as MOD_PROQUAKE
I was trying to test Mark V on a server and the "easier NAT fix" didn't cut it. Wish all this were known in the past. :D