If client sends wrong serverId but is already active in the world
(CS_ACTIVE) don't resend initial gamestate for the map. This isn't a
valid situation. The player should be CS_CONNECTED or CS_PRIMED.
Resending gamestate to an active player will cause them to respawn
without dying or disconnecting. If the player had a CTF flag it gets
lost until the map is changed or restarted.
Reported by Ensiform at:
https://bugzilla.icculus.org/show_bug.cgi?id=6324
Running a server using the client engine would send server snapshots
to loopback and LAN clients each client frame (com_maxfps).
This causes excessive network traffic and likely does not provide new
information to the clients because SV_Frame() won't have run between
the extra snapshots.
This commit restores the original behavior of respecting local/LAN
client's snaps userinfo and sv_fps. The issue was introduced by the
following commit:
Commit ac30d86db0
From: Thilo Schulz
Date: Wed, 13 Jul 2011 17:11:30 +0000
Subject: - Improve snapshot rate and data rate control
Reported by Eugene C.
Resolve master server addresses every 24 hours instead of keeping
result forever. Don't clear sv_master[1-5] cvar if the address fails
to resolve; it might work later.
Server/client VoIP protocol is handled by adding new cvars
cl_voipProtocol and sv_voipProtocol, sv_voip and cl_voip
are used to auto set/clear them. All users need to touch
are cl/sv_voip as 0 or 1 just like before.
Old Speex VoIP packets in demos are skipped.
New VoIP packets are skipped in demos if sv_voipProtocol
doesn't match cl_voipProtocol.
Notable difference between usage of speex and opus codecs,
when using Speex client would be sent 80ms at a time.
Using Opus, 60ms is sent at a time. This was changed because
the Opus codec supports encoding up to 60ms at a time.
(Simpler to send only one codec frame in a packet.)
Send snapshot with each download block so that client updates reliable
acknowledge, otherwise client can error when asking for next block via
nextdl reliable command.
iostvoyHM 1.37 asks for protocol 25 and falls back to legacy protocol 24
when rejected with a specific message.
When the protocol was changed to 26, the message the client checks for
whether it should use legacy protocol was changed causing it to no
longer be able to join. So let's restore the message.
Revert last commit so that grapple sky check is compatible with BSPC
BotImport_Trace in (removed from repo) code/bspc/be_aas_bspq3.c.
Set bsp_trace_t::surface.flags instead of surface.value to trace_t::surfaceFlags.
surface.flags is only used for the sky check for grapple AAS reachability.
surface.value is not used at all.
bsp_trace_t is not part of the game VM API, so this does not affect VM compatibility.
BotAI_Trace in game was changed to match server. surface.value/flags are not used in game.
[17:58] <Jacker> hey, you might be interested in checking out this
4da5a397b5 (diff-acaedc9d8b492f9af8966ae68597392cR615)
[17:58] <Jacker> its related to the ddos protection code you wrote
[17:59] <Jacker> in continuation to:
ab9b08e584
[17:59] <Jacker> in a case if the client has in the past connected to
the server days/weeks earlier and time wraps the client wont be able to
connect
[18:00] <Jacker> since in that case if the bucket of that clients ip
still exists it wont get checked correctly
