| Age | Commit message (Collapse) | Author |
|---|
|
packet for longer company names (in bytes), by truncating the names if needed
|
|
|
|
savegames to send to the client asynchroniously. This will reduce the lag of the other clients to the time it takes to make the memory dump and it will speed up downloading the map as the download starts earlier (possibly with a slightly lower bandwidth due to slow compression). This should also fix the lag message people get when the savegame compression takes more than a few seconds.
|
|
client, don't write it to disk but create the packets immediately
|
|
later in the download process
|
|
|
|
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).
|
