| Age | Commit message (Collapse) | Author |
|---|
|
|
|
receiving, our frames
|
|
style
|
|
|
|
transferred file are the same file and not different ones
|
|
lagging because of connection trouble or lagging because the client is just slow
|
|
|
|
when receiving some packets and don't send some when the clients aren't ready for them
|
|
|
|
into 3 separate packets
|
|
|
|
player leaving the game
|
|
so they're documented in the "same" place as UDP, content and admin packets (dihedral)
|
|
(dihedral)
|
|
|
|
|
|
specific intervals (dihedral)
|
|
reusable
|
|
|
|
|
|
sockets
|
|
|
|
|
|
like UDP/content packet handling
|
|
NetworkClientSocket for server and client side
|
|
static in that file.
|
|
|
|
(from clients and the server)
|
|
meaningful names
|
|
|
|
O(1) instead of O(n)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static const variables
|
|
that way
|
|
|
|
|
|
|
|
to spectators
|
|
a client starts joining, i.e. save the game state. This can happen in two ways: with frame_freq > 1 a command received in a previous frame might not be executed yet or when a command is received in the same frame as the join but before the savegame is made. In both cases the joining client would not get all commands to get in-sync with the server (and the other clients).
|
|
to spectators before he finishes joining
|
|
|
|
password was cleared meanwhile
|
|
|
|
unify the formatting
|
