- Fixed: TicSpecial::CheckSpace() never thought it ran out of space due to
unsigned math.
- Fixed: TicSpecial::GetMoreSpace() assumed only relatively small amounts
of data would be written at a time so made no effort to ensure it
actually got enough space. This assumption could be violated by writing
a very long string, which can happen when replicating a string cvar.
- Extratic changed to server var, that can be changed at any time
(net_extratic)
- Added net_extratic 2 which resends all unconfirmed tics
- Corrected bad variable typo in delay reporting
- Added delay times of all players to the scoreboard
- Removed balancing from packet-server (tried it, didn't work)
- Calculations remove an extra tic to account for possible bias
- Guests can now attempt to match latency with the arbitrator.
(net_loadbalance)
- Added althud feature to show arbitrator and local latency.
(hud_showlag 1 is on for netgames, 2 is always on)
Adapting during a dup frame caused jittery network performance
(especially when using high dup values).
The demoplayback check also didn't need to be there anyway.
- The waiting message is now always cleared, regardless if it needed to
be in the first place. It's a rather simple for-loop so I doubt it
matters.
- Nodes are also cleared from the list if they catch up while other
nodes are still behind.
- "lastglobalrecvtime" is now bumped after the waiting loop if a tic was
successful, rather then bumping it every time a packet was received. It
appears that you can receive a packet before the game knows it stalled,
thus stalling it anyway.
- Instead of comparing the nettics to the local node, all nodes are
tested against gametic+counts (the real reason why the game has
stopped).
- More then one node can be marked as late at any one time.
- In a packet-server game, the arbitrator is now assumed slow, rather
then testing it. There is no point, seeing as we already know the game
has stalled because of it.
defaults to 200. Setting it to 0 will restore the previous behavior of having no frame rate
limit. Note that vid_maxfps 35 is NOT the same as cl_capfps 1. cl_capfps caps the frame rate
by tying the video update directly to the game timer. With vid_maxfps 35, the video update and
game timer are running on separate timers, and results will not be as good as with cl_capfps 1,
which uses only one timer.
SVN r3872 (trunk)