Since this is by far the most requested feature, I might as well kick up some discussion on plans for the implementation.
For starters, and this isn't really related to the faster part, I think there needs to be a progress bar outside of the console, so people don't think the game just locked up at the "loading" screen.
Now, I know a lot of people have suggested HTTP downloads, but I don't think that will work very well. Here's why:
- As I discovered from the server list and later the login system, a number of people have weird proxy configurations that don't allow a basic HTTP connection.
- LAN servers may not have Internet access, and those are the types of servers that people should be downloading from the fastest.
- Who is going to foot the bill for the bandwidth?
- What if the map repository doesn't contain the map a server is running?
- What if the version of the map is different?
I think the most effective method is for the server hosting the game to transfer the files, too, using the same method of communication as game traffic (UDP). If you can connect to the server, you can download maps. This is the way map downloads are currently handled. It just needs to be beefed up a bit.
Currently the way file transfers work is this:
Client requests a download ->
<- Server checks if the file exists and responds accordingly
Client requests first 1k block of file ->
<- Server sends first 1k block of file
Client requests second 1k block of file ->
<- Server sends second 1k block of file
...
until the transfer is finished.
Two key problems with that. #1, the server runs at 10hz, so even under optimal conditions, the maximum file transfer rate is 10k/s. #2, the server waits for the client to request the next block to send it, and the client waits until it receives a block to request the next one. If the latency is high, it drastically impacts the overall throughput. In short, your download speed is determined by your ping + it's rounded up to the nearest 10th of a second, so if you have a ping of over 100ms, you'd probably be getting transfer rates of 5k/s.
Now, the new file transfer system I think should work something like this:
Client requests a download ->
<- Server checks if the file exists, and returns the filename of an appropriate file if it exists (this could be a pak file, if the file is part of a package, or perhaps an alternate image format, like jpg instead of wal)
Client OK's or denies the download of the file (won't overwrite existing files or files outside of the paintball2 directory) ->
<- Server sends first block of file
<- Server sends second block of file
<- Server sends third block of file
Client acknowledges first block of file ->
<- Server sends fourth block of file
Client acknowledges second block of file ->
...
If a client fails to acknowledge a block after a set period of time, the server will re-send that block and slow down the rate at which it sends data. If the client acknowledges all the blocks, the server will increase the rate at which it sends data.
