Hosting Custom Maps & Mods: Faster Downloads via http Redirect
If your server is running custom campaigns, custom maps or modifications then players will need to have these files in order to play there. If player's have not already obtained and installed the necessary files, they can autodownload them directly from the game server if the server has set sv_allowdownload to 1 (which is default, and you will almost certainly want it so).
sv_dl_maxrate sets the speed clients can download from the server at, in bytes per second. The actual speed player's can download from the server at is capped by the lower of sv_dl_maxrate, the overall engine cap of 25kps, and by client's own 'rate' setting (and of course, by their actual connection speed). In practice, for whatever reason, the fastest clients seem to be able to download is about 13KB/s. The setting was supposed to go to about 42KB/s when it was added via patch for RTCW, but for whatever reason it doesnt in ET.
13KB/s is adequate for small files, but far too slow for large files such as big custom maps or mods. Of course, it also takes bandwidth (and some cpu) from the gameserver, maybe none of which you have going spare - or perhaps you have faster and cheaper from a filehost. If you have a busy server running brand new custom maps, file downloads can be a LOT of bandwidth!
This is where the web-download feature comes in. If you have a web server that can host files for download, you can set the game server to redirect the autodownload files to be sent from the web/file server instead, at the max rate the web server allows! This feature is highly recommended for servers running custom files of several megabytes.
set sv_wwwDownload "1"
set sv_wwwBaseURL "http://www.yoursite.com/files"
set sv_wwwCheckPath ""
set sv_wwwDLDisconnected "0"
set sv_wwwFallbackURL ""
|
In the example above the .pk3 files should be at the following address: "http://www.yoursite.com/files/etmain/file.pk3"
These must be the exact same .pk3 files as in use on the server, do not zip them or anything. Note also the BaseURL does not finish with a backslash!
Note the "etmain" subfolder that is in the URL for where the actual file is found, but is NOT specified in wwwBaseURL; ET will automatically add this folder to the seek path, but if you are running a modification, it is not always going to be etmain! Consider where the files are kept on the server - they will either be somewhere within "etmain" subfolder or within the subfolder of a mod like ETPro. If the files are kept in etmain, then the url would be:
http://www.yoursite.com/files/etmain/file.pk3
However, if they are kept somewhere within the mod's folder, for example etpro, then the url would be:
http://www.yoursite.com/files/etpro/file.pk3
By the way, I beleive it will sometimes work ok even if you put files that are supposed to go into etpro folder into the etmain one instead (but not vice-versa), but this would not be good practice and is definately not recomended. Another caveat is that on the server, folders like etmain and etpro should really all be kept in lowercase, as should be the respective folders on the http fileserver. If the server does not use folder names that are all lowercase, you may need to have the folder names on the file server be in exactly the same case.
Do not point the url to the actual ET install you're running from (e.g. because you're running a FTP server on the server host machine anyway), or to a complete copy of it - it would be possible for people to download all files in there that way, including the configuration files that contain passwords.
There are also three further settings related to download redirect:
set sv_wwwCheckPath ""
I beleive when left blank this will make the server look in the default folder for the .pk3 files to send to clients when downloading with the www method. The default folder is "etmain". When there is e.g. "serverfiles" here, the server will look for them in "serverfiles" subfolder, instead of "etmain". I suggest leaving this blank.
set sv_wwwDlDisconnected "0"
When set to 1 player's will download the necessary files before being fully connected to the server - the benefits is that they do not take up a player slot on the server while downloading (which also means it's easier to maintain team number balance), and it appears downloading player's dont have problems when the map changes on the server. The downside for the player is they might spend ages downloading files, only to complete them and end up facing "server full" and having to queue! This might be even more annoying if the player had to queue even before starting the downloads. Because of this I suggest enabling disconnected downloads when there are large files, and disabling it when it's just a few smallish files that won't take long to download.
set sv_wwwFallbackURL ""
You can put in the URL to a webpage here, and if the download redirect fails then it will exit ET and open the webpage. The idea is you can have a simple page giving alternative locations to download the files from the web in the usual way. If you leave FallbackURL blank it will default back to downloading from the server instead (thanks Sphere).
Example: set sv_wwwFallbackURL "http://www.rtcw.jolt.co.uk/server"
Which opens this.
As a final note, bear in mind that using urls for http redirect without permission makes you a bandwidth-theiving scumbag, and puts you at the mercy of the filehost owner finding out and doing nastly things for payback. Since the ET update to 2.60, clients trying to download via redirect now send a referrer (ET://server.IP.address:port) of the gameserver, so it is possible to trace use - and skilled network admins can actually prevent or reroute downloads from gameservers that are not their own.
Re-Direct Settings Reccomendations
Let's assume you have a http or ftp filehost. That does not mean that it is definately better to use the download redirect however. This is something open to opinion - here's a few examples to illustrate mine:
- Server running a stock campaign of stock maps, no mods, no custom files at all
No need for any download system, though might aswell leave sv_allowdownloads at 1.
- Server running a custom campaign of stock maps, no mods
Here the only file clients should need to download is going to be a couple of KB, there is no point with a redirect, it is only going to leave open more possibilities for problems.
- Server running a custom campaign of stock maps, latest official ETPro mod
Here you're clients are highly likely to already have the sizeable files, since ETPro is very popular. They wont have the custom campaign, but it's a trivial download anyway. I suggest either sticking with just the server download system, or use the http redirect but leave sv_wwwFallbackURL empty so players can default back to downloading from the server.
- Server running a custom campaign of stock maps, a brand-new or beta ETPro - version (or some relatively unpopular client-side mod of ~2-5mb)
Several players are likely to need to download a couple of megs, so the redirect download is worth it, but the download isnt really huge so leave sv_wwwFallbackURL empty so players can default back to downloading from the server, espeically so if you change the campaign file.
- Server running custom maps, or some large modification
Several players are very likely to need to download quite large files. Go with the redirected downloads, and set up a html page for the sv_wwwFallbackURL.
Problems with Download Re-Direct
Since the 2.60 update, Enemy Territory's http download redirect has become much improved with respect to it's stability. You can still have problems though, but they're probably "your own fault" so to speak:
when transmitting .pk3 files via FTP to the filehost, make sure they transmit as binary/application and NOT as ASCII/text/plain/whatever.
if using a FTP server to serve the files, make sure you set it up properly! some arent as straightforward as they could be. Test it out by removing a file from your client that is needed on your gameserver and then join it. If files are downloaded over and over, ensure it is set up to transmit the .pk3 files as binary/application and not ASCII or whatever.
Aviod having any excess .pk3 files on the gameserver, and beware of older custom maps that may include campaign files (all campaign files are loaded when a server is run, and all maps referenced in them will be required for clients to have). Best practice is to remove any non-official files if they are not intended for use on the gameserver.
When using custom maps/campaigns please have consideration of the .PK3 Count Bug.
Admins using versions of ET prior to ET 2.60
The following section is now obsolite and only applies to admins using older versions of ET, i.e. 1.0, 1.01 or 1.02:
Problem with the HTTP download: it's buggy. Clients will sometimes crash if the game cant find the files where it thinks they should be, and it's a pain for players even if it doesnt crash if their web browser suddenly pops up and gives some 404 "cannot be found" message. Also, if the files get corrupted on the filehost or during download, the client is very likely to crash - or continuously redownload the files. Make sure the file host is set to send the pk3 files as application, binary or octet-stream, and NOT as text or plain, which will corrupt the file and end up with the continuously re-downloading issue. Sometimes the clients continuously download the same files over and over for no apparent reason.
In short, ET's redirect system isn't very stable for clients, and it seems worst if the redirect points to an FTP server (especially for Linux users). I would still reccomend use of redirected downloads for any reasonably large file however: it is at least a practical method to get larger files (and the slow server download really isn't), it works most of the time and any crashing is of ET itself - I've not heard of any sort of damage to anything.
(Extra thanks Moron + others for assistance here.)
There is also an issue that affects any method of autodownload. Copy & paste of the explanation given by Rippin Kitten in the Splashdamage forums details the issue well:
" Under a pure server, all game elements in use on the server need to be on the client as well. Since most custom maps bundle a campaign file in with the map pk3 the server loads this campaign file (and all campaign files while under campaign mode) on startup. So even though a small 2kb campaign script is being used by the server, it will require that all clients have the big massive pk3 its located in.
Two things you can do.
One, deal with it. Hopefully all of your clients are willing to sit through the painfully slow download process and get every missing pk3. You can set up the http redirect which is a much faster transfer system, and if you can host it on a seperate connection you don't tank the server with file requests. You can also post them on your website so your players can get them that way. Finally, pulling pk3s out of the etmain directory when you don't plan on using them will help as well.
Second, you can run the server as unpure. This does introduce the possibility of clients running models, sounds, or voice mods that not everyone is running, potentially "unbalancing" the game. When the custom map gets called clients will download it then. So deciding to lose all your players from the get-go or weeding them out when the custom map finally comes up is a decision you need to make. "
However, please note that the quote comes from early days in ET, where mappers were including campaign files inside the map's .pk3 - a practice since stopped, by 99% of mappers anyway (and if the other 1% pay so little attention to this major problem, their maps are probably not worth playing anyway). It is still good practice to remove any maps not being used on the server though. If you wish to run multiple servers, then run any server that uses the problem maps from their own ET install.
Another possibility might be to open up the .pk3 and remove any campaign files, but this would mean all players (wether they have the original or not) would have to download your modified version of the .pk3, and conflicts with the "official" version are likely. Further this would probably fall foul of the author's terms of use.
When using custom maps/campaigns please have consideration of the .PK3 Count Bug.
|