TCP/UDP Port mapping - Quake using winded.exe to host

[Baker]

With FTE, I was getting horrible latency even locally. 180ms???

NOt sure what the deal is/was...

I've enabled the sv_listen_nq 1 switch, default port for FTE is 27500, so that's what it is currently using.

I connected with FTE 3343 to your server and everything was super-smooth.

[dhahlen]

Nice

I closed out the UDP ports and only have ports specific to quake open now.

Network was getting flooded with crap, haha.

[Baker]

NetQuake connectivity

In ProQuake I end up getting ...

Read error
Host_Error: CL_ReadFromServer: lost server connection

In Enhanced GLQuake I end up getting a "Network Error" when trying to connect.

This is more for Spike than anyone else.

[dhahlen]

I get the same error using pq 3.50 and 4.52

The map loaded on the server for about a second before crashing. The connection established, map loaded, then crashed with cl read error.

also note I loaded proquake using a batch file which specified -game bombsqd

[dhahlen]

Interesting, found some scripts that deal with the CL_ReadServerError, i don't know crap about programming. However, I've worked with some php and OOP, and the scripting looks very similar to Object Oriented Programming that I've used in php.

I'd be curious to see the solution when/if one is provided.

Also, what are you guys using to modify these scripts/code? And which files contain all the information?

[Spike]

What's the correct ip:port?

If its an FTE server, typing 'packet $IP:$PORT status' into any quakeworld engine should give some sort of result, regardless of listen values (so long as it has a port open). Did you take the server down?..

[dhahlen]

I did temporarily, should be back up now.

If I type that into the console, I get unknown command 'packet'

server is run like this

fteqwsv.exe -game bombsqd -dedicated 8 -noipx -ip 172.17.17.20 -condebug -heapsize 21768 -zone 1024 +map hstart

[Baker]

@Spike

dhahlen:27500

FTEQW connects fine. Didn't try ezQuake (no doubt it connects fine).

NQ clients issues, see above. Strange since I was able to connect to some Team Fortress server in late 2008 with FTE 3343 as the server with any version of ProQuake and no doubt dhahlen is using FTE 3343.

[Spike]

Some weirdness here. Other engines report illegible server message, while proquake is special in that it reports read error, which really doesn't help!

FTE is sending an over-sized UDP packet, as far as I can see (NQ typically permits only 1024 bytes per udp packet). This causes proquake to report 'read error'.
This is doubly bad in that it looks like its also using an internal buffer of only 1024 bytes too. This causes anything which supports larger packet sizes to report 'illegible server message' (including FTE clients using nqconnect).

3343 is over two and a half years old. Try a nightly build from Index of /moodles/unstable
'could've sworn that something about nq was fixed past 3343 for a similar issue...' - yup, there have been NQ fixes since 3343. I can't guaretee anything, but its worth a try.

[dhahlen]

swapped it with the build from the directory, give it a shot, let me know

[Baker]

I can connect now just fine with ProQuake.