View Full Version : Tips and Tricks for UT Servers

12th November, 2003, 06:41 PM
Author: Elvis.

NT4 UT Server Operation

In my opinion, the best (cheap) way to connect a server to the internet is directly through the bridge or modem to the external connection, or first through a switched hub and then the bridge to allow use of more than one WAN IP address. To protect the server, use a software firewall (for example ZoneAlarm). A software firewall will also provide an IP ban list. The ban list in UT is limited to 50. With the IP ban list in ZoneAlarm, the players banned don't even know the server is up and you may have a much longer list. I reserve the UT ban list for players whom I want to ban temporarily. Using ZoneAlarm will cost you some cpu cycles, but it is worth it. Another alternative is described by clan1234, below in this topic, using IP packet filtering built into NT4 Server.

Also, along these same lines, try BanHappy as modified by Darkbyte. It adds 256 additional player IPs to the 50 allowed in the UT IPPolicy list:


I think it is inadvisable to run a UT server behind a router (unless it is a damn good one). Routers, used as buffers between the Internet and your internal LAN, may have problems with causing packet loss. The more players allowed and the higher the packet rate and size per player (MaxClientRate and NetServerMaxTickRate), the greater the potential problem. Placing a server in the DMZ of a gateway router makes the server vulnerable to hacking. You then need some additional form of server protection. Buy a second IP address for a second computer, use a software firewall, and forget the router.

Monitor the server cpu usage and bandwidth usage (particularly upload bandwidth) and keep both below 95% at all times. Also, monitor packet loss periodically. Packet loss from the server is noticable to the players. The fastest connection is useless with packet loss. To test this run pings to your primary DNS server. If some players see packet loss or high pings, have them run traceroute from their commandline to your primary DNS server when they have a problem.

The bandwidth you need for a server depends on the number of players plus spectators, the MaxClientRate, the NetServerMaxTickRate, and the mods you are running.

Upload bandwidth is almost always the limiting factor. UT typically needs 20-50% more server upload bandwidth than download. I found that, on an basic instagib server, each player needs around 60-70 kbs upload bandwidth at MaxClientRate=7000 and NetserverMaxTickRate=30. Probably weapons servers need more bandwidth. Additional mods like Matrix Moves, relics, etc. probably add further to the bandwidth requirements.

Make sure you have a Redirect Server for downloads of files such as custom maps, skins, etc. Players lag badly if others have to download from your server while they are playing. Don't know if this will give you a problem, but it would have with my server (PIII 900).

If you are bandwidth-limited, connect to your server through the LAN and not through the internet. In doing so, you will free up one internet connection's worth of bandwidth. If you connect through your LAN, you will avoid some "LAN envy" by increasing your ping to 40 - 70. Find the shortcut for UT, right click on it and choose properties. choose the shortcut tab. after the UnrealTournament.exe, type in (put a space after it) UnrealTournament.ini pktlag=90. The number can be changed to anything you want. The higher the number, the higher your ping.

Be aware that some mods like spawn protectors, anticamper programs, etc. may cause your server to be listed as a "Mod" server instead of LMS or CTF for example. Many players are sensitive to their rankings as LMS or CTF players and will play less on your server (or not at all) if they see that their LMS or CTF rankings are not changed by playing well on your server. After you make any changes in the serverpackages or serveractor or mutators, make sure that your server has not changed categories to "Mod" in the ngstats website. Keep an eye on this periodically anyway if you run any mods. Sometime the change to being a Mod server doesn't happen right away.

Some people think running UT as a service is preferrable. For instructions, see:


For a HUGE list of useful sites pertaining to NT4, see the third post on the page in the following link:


Also, running UT from the commandline has advantages and disadvantages to running the gui. See which you prefer.

Periodically reboot the server and reset your internet connection. See if this has an effect on pings and lag in general. If not, reboot the server periodically anyway to keep the serverlog from getting too large.

Another way to decrease your server.log filesize is to add the line:


to the [Core.System] section of the UT.ini file. This prevents the server from logging data that begin with this string. This data may be useful to someone, but I never found it informative and there were many lines in the server.log file that were eliminated by installing this line in the UT.ini file.

Keep at least two Ghost images of your server HD. The most current configuration and the previous configuration. Then if something happens, you can be back up and running fast by using the most recent trustworthy back-up.

MasterServer List:

Check the beginning of your logfile (server console) periodically for error messages that warn you of outdated references to MasterServers. Both the connection verifications and error messages resulting from no connection to one of the MasterServers come right after the UTPure startup. Trying to connect to a defunct MasterServer will increase the time necessary to change levels.

The attempted connection to MasterServers are initiated by their designation as ServerActors in the UT.ini file. The ServerActor listing should be updated by adding a semicolon as the first character of a line whenever the serverlog indicates that you are not connecting to a MasterServer.

The default list of MasterServers in the UT.ini file under the [Engine.GameEngine] section of the file is:

ServerActors=IpServer.UdpServerUplink MasterServerAddress=unreal.epicgames.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master0.gamespy.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.mplayer.com MasterServerPort=27900

To the best of my knowledge, the current list of masterserver ServerActors in the UT.ini file should look like this:

ServerActors=IpServer.UdpServerUplink MasterServerAddress=unreal.epicgames.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master0.gamespy.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master.qtracker.com MasterServerPort=27900

The MasterServer mplayer.com is no longer online.

General References

Check out:
for useful utilities, hints, tweaks, etc.

The site's forum is useful also:

Server Parameters

For a readable explanation of NetServerMaxTickRate and MaxClientRate see:


Experiment with the NetServerMaxTickRate and MaxClientRate when the server is near capacity. I used NetServerMaxTickRate=30 and MaxClientRate=7000. Start there and play around. Do not use a higher value for these parameters than what gives you a noticeable improvement. I have heard that players in general on Instagib servers benefit from a higher than default value for the NetServerMaxTickRate setting (20), whereas, on weapons servers, modem players are penalized by increasing this setting above 20.

To test changes you make in these parameters, find one or two players with excellent connections (again, while the server is near capacity) and judge the server performance by their observations. For that matter, always judge the server and connection performance by the players with the best connections. If some players have poor quality connections, and a few have exellent connections at the same time, then the fault for the bad connections is not within the server or your connection. If the server or your connection has a problem, then usually everyone will have that same symptom and no one will have a great connection.

Invalid File Requests:

The most common cause for a "Received Invalid File Request" error is that the "correct" file doesnt exist on the redir server, and thus players who need it are unable to download it from there. UT on the client computer will then try to download the file from the game server, which I assume has downloads disabled or a maximum filesize enforced. The net effect of all these shenanigans is that the player cannot join.

The following are ways to minimize players not being able to download a file from the redir server and the log displaying a "Received Invalid File Request" error message:

Get rid of the line "serverpackage=de" from the [Engine.GameEngine] section of the UT.ini file. Many players will have a problem connecting to the server with this as a serverpackage. There are two common versions of this file. Players with one version in their system directory will get a "version mismatch" error when trying to connect to a server with the other version. I don't think it is necessary to have this file as a serverpackage in any event.

Make sure the files listed in your Unrealtournament directories are exactly the same as the ones listed on your re-direct site. CaSe SeNsiTivIty is critical for redirects. Some players will already have the needed file and will be able to connect without difficulty since the download was not necessary for them in the first place. Anyone who needs to download the file will not find an incorrectly-named file and will not be able to connect. To correct the problem, ask the player who has received the error message what file was named (exactly, including case and spelling) when he received his version of the error message (Server Refused to send ----). Don't be deceived by the name of the zip file containing the map and any other necessary files. Also, the name of the file as decompressed from the zip file may be wrong. The name of the zip file and the uncompressed file are meaningless. The required map, texture, sound, music, or system file name is determined by the name of the map on the server.

Use a minimum number of modified maps. Map version conflicts are becoming more common because there are so many versions of custom maps out there now. The slightest modification will cause a version conflict if the same file name is used. If you suspect this problem, re-name the file on the server and the re-direct site to a unique name, thereby forcing everyone to download it ...Or change the version you are running to the more popular version ..or ask the only client having the problem to delete or temp re-name the file in question.

If you forget to put a texture, sound, music, or system file that's associated with a map on the redir server, then anyone that already has that file will be able to connect to the server and anyone who doesn't will get an error message.

Also, load the compressed files of SkeletalChars.u, epiccustommodels.u, and any maps from the bonus packs you will use onto the redirect server. Alot of players don't load the bonus packs and this will permit them to play if you have them as ServerPackages. They will see the above error message if these files are not on the redir server.

(Thanks to Gaussian on the TheAdminPage Forum for the reminder about this topic)


Keep your server up to date with the latest UTPure.

Note that the UT ban list holds a maximum of 50 players' IP addresses. Once you have entered the 50 IP addresses, any players you try to ban will not be banned, but only kicked. In order to ban another player, you must first delete one IP address from the ban list. Then add the new IP afterwards.

I like to make the UTBrowser, UBrowser, UTMenu, UWindow, and UMenu serverpackages to confuse the cheaters as much as possible. To do this, you have to make the packageflag for these files serversideonly no. This makes it difficult to play with modified files (like cheaters generally have). Use the following command line for this on each file individually:

c:UnrealTournamentSystem ucc packageflag UTMenu.u UTMenu2.u -ServerSideOnly

Then backup the original files and rename UTMenu2.u to UTMenu. Do this for each file.

Then, for each of the above files, put "ServerPackage=UTMenu" lines into the Engine.GameEngine section of the UT.ini file.

The above modification will prevent some (mac and linux) legitimate players from playing on your server, but it does confuse alot of the cheaters.

There are other ways of confusing cheaters posted in the "admin-only" forum and elsewhere that you may try. Most of them involve modifications to UTPure or CSHP.

Another thought, for what it's worth...
When one or two players start claiming that someone is using an aimbot, most of the time they are wrong. Don't ban someone for using an aimbot unless you (or a trusted admin) are able to witness them obviously using one (in "Behindview 0"), or they admit it in some way (e.g., their name is ElfTester or something like that). Banning an excellent player because of talent is always a bad idea.

If you are in doubt about this, let him play and silence the complainer. See how he plays over time. The skill of an excellent player is obvious. If you don't definitely know that the accused is using an aimbot, DEFEND HIM. Don't let players drive away anyone out of jealousy or frustration. I think it is very difficult to tell that a player is using an aimbot while you are fighting them. As an admin, assume players are not using an aimbot unless you (or a trusted admin) personally judge that they are.

Along the same lines, I recommend that you don't use kickvote, anticamper or a similar programs that take responsibility away from the admins (unless there are temporary extenuating circumstances).

In the case of kickvote, I feel it is unwise to delegate responsibility for kicking or banning to the whims of players. The founder of a server needs to take the responsibility and recruit sufficient admins and take the time himself, when necessary, to keep the players honest.

Camping in LMS

In the case of using an anticamper mod for LMS, there is no programing substitute for the judgement call of an experienced admin. The anticamper programs I have seen all detect camping by a player through his time spent in a pre-determined radius. I feel using a program of this simplicity is unwise, since players easily get around this by moving some while camping. Also, fighting from a fixed position should not be a problem. Stupid or lazy perhaps, but not against the rules.

In my opinion, whether or not a player is camping in LMS should be decided by his defensive vs offensive stance, a judgement call by the admin. A program can not do this. LMS is a tough game to admin since it is a balance between offense and defense. The defense may easily overcome the offense, when allowed to do so, and the game will then become a long-term survival contest. This is a boring game and thus playing a defensive game by hiding (camping) has to be forbidden.

As a generalization pertaining to defensive stance, a player must remain vulnerable during LMS and be killable. When asked to generalize about camping policy, I have always told players that if they feel safe, then they are probably camping.

If a player is killing players from a position or area that is unapproachable from the rear, his defensive position is too strong and he is camping. Another example of a too strong of a defensive stance would be an area where he is able to cover his rear approach and is watching for players to come that way to prevent his being killed. There are other more obvious examples, but these two are the ones that are not easily seen by an anticamper program.

Another type of unacceptable defensive tactic is running to avoid contact or consistently breaking off contact while fighting. While not camping, IMHO, these are both a form of cheating in LMS. A player must seek out contact and not consistently run from a one-on-one fight. A player may break off a 2 (or more) on 1 fight, but only if he then actively seeks a new fight.

IP Banning Issues:

I recommend that you use PlayerJoinDump. This program runs as a ServerPackage and puts players' IP address in the serverlog so you can find cheaters IP addresses and names after the fact if they are reported by admins or other players.

Download PlayerJoinDump here:


PlayerJoinDump will give you alot of useful information. Many times banning an undesirable player (cheater, whatever) will require you to ban a range of IP addresses. Doing this may result in banning of some of your regular players (not good). To prevent this, and help you make judgements on the number of times a player is on your server, save each server.log file (or whatever the file name is) and extract all player names and their IP addresses saved by PlayerJoinDump. That will be all the players, not spectators. Make a spreadsheet with all the names and IP addresses so that you can sort the information by name and search by IP address or partial IP address. Then if you need to ban the range 24.148.*.* (for example), then you can go to your spreadsheet and search for all players within that IP range by finding the string "24.148.". If you find one or two players who have only played once or twice on your server, you can make a decision whether or not to ban that range. This will keep you from banning regular players by seeing how many times someone plays.

If you have to ban a range of IP addresses and you have a regular player (with a static IP addresses) within that range, you can still ban the undesirable player without banning the regular by banning two ranges, one on either side of the regular player and not including the static IP address of the regular player. For example, banning two ranges: to and to will effectively ban the range 24.148.*.* without banning the IP address

The list generated from the PlayerJoinDump output is also useful for detecting identities of players using aliases, and IP ranges of players with dynamic IP addresses (see previous discussions). As a note, I had a player tell me he wanted to admin for me and he claimed he was a regular player on my server. A check of my player listing showed he had only played on my server 4 or 5 times since I started keeping the player listing (3 or 4 months). He was amazed I could tell him that...

Along those lines, keep a listing of cheaters you have banned and why they were banned in a spreadsheet also. If you are diligent in banning players, you will soon loose track of why they were banned and be unable to make an informed decision whether to let them back in or not.

An alternative to banning: If things are getting out of hand and numerous players are ragging on each other and you need to do something to calm the situation, consider warning the players first and then if the situation doesn't improve, shutting the server down for an hour or so. This clears the server of the newbies who probably won't come back, as well as calms down tempers of players who are the hot heads. Many times the threat of shutting down the server will get the more experienced players to get everyone else to calm down.

Admin Responsibilities:

If you delegate admin responsibilities (which you should, IMO), make sure it is to mature players you can trust. For admins, I believe it is better to get one player (preferably a clan leader) from as many clans that frequent your server as possible, with as few duplicates as possible from each clan. Independent (non-clan) players may be fine also, as long as they are experienced in the game type you host.

A useful tool for delegating admin authority is SemiAdmin created by Darkbyte. He has just released an updated version and I highly recommend it. Download it here:


It allows delegating different levels of responsibility and power to various admins so that you can feel more comfortable about handing out some admin responsibility without selling the farm, so to speak.

I have always insisted that my server admins use aliases without clan tags when performing admin functions. Also, they were instructed to keep their identities a secret from anyone, including their own clan. This way, other players would not think they were biased against other clans or biased for players in their own clan. Not informing their own clan was only successful on a case-by-case basis, but I was always on the watch for clanmates who took advantage of their admin clanmates status on the server. Never saw that happen when I was around (which was frequently).

Before you give anyone the admin responsibilities, I suggest you spell out precisely the server policies and rules - particularly for judgement calls and kicking/banning procedures. The other admins must reflect your policies and not have conflicting policies or rules.

Have your admins send you an e-mail or something with the names and IP addresses of anyone they ban. This gives you the opportunity to add the banned player to your spreadsheet list and, if you wish, to your firewall.

If a player comes back to you and says another admin unjustly banned him, foreward the message to the admin who did that with the message that they should try to work it out with the player who was banned. Generally, anyone who I banned and was willing to talk to me intelligently about their behavior was allowed back on the server. Any appeals from someone banned, who disagreed with me about server rules was rejected if it was because they interpreted rules differently than I did on judgement calls. Be consistent and don't change rules without a good reason. If you change the rules, inform all the admins and be clear about the changes you are imposing.

I allowed admins to use my server for their clan matches and practices pretty much whenever they wanted. Sort of a perk for their being an admin. Before admins use your server and change parameters, map order, passwords, etc. make a copy of your UT.ini file and overwrite the UT.ini file after they are done using it. Gets you back online as soon as possible.

Establish and maintain contact with other admins of other servers that host games similar to yours. This network may share IP addresses of cheaters and other undesireable players. I think most players, including cheaters and other undesirables frequent mostly one specific game type. You may also share information about new observed and rumored cheats. Cheating clans (XLC or Elf clans for instance) fall under the "Ban on Sight" category. IP addresses from members of these clans may be shared between admins as soon as they are detected. These other admins are also useful for helping you troubleshoot problems with your server since they are undoubtedly more experienced than your are if you are just starting out with your first UT server.

Post clear rules and policies in the F2 display. Also, remind players who need it that there is not enough room in that display to post all the rules. If possible, post an extensive set of rules and explanations of server policies on a separate website that is referenced in the F2 display.

Last, but not least, the more you or other admins monitor your server to keep it free of cheaters, spammers, *******s, racists, and anti-everything players, the better quality and the greater number of serious players you will attract.

Please see the following post by me for further amendments.

12th November, 2003, 06:41 PM

Thank you, I will continue to update the original post, both in the original post and in this post, as I think of additional information or need to correct misinformation.



Don't use maps that are difficult to play with an average video card/computer cpu. If you do, your server will become an elitist server and very few players will come. Many of the better players don't have alot of money to spend on computers and so are stuck with older video cards and slower computers. In this regard, more than one or two problem maps will chase players away. Some maps are simply unplayable - they are either too large or too many polygons to be playable. Not all map designers are good at it. Just because a map is beautiful, doesn't mean that people will enjoy it. Playability is much more important than beauty. Both are nice, but only use playable maps.

In addition to some websites that have maps available for downloading, many times I will find new maps by going to other servers and spectating. While I am downloading the level from a server, I take note of the file names that are downloaded with the map, such as necessary sound, music, or texture files.

All files (including maps and their related files) that are downloaded from another server are stored in the


folder for 30 days and then deleted (unless you change the PurgeCacheDays default in the [Core.System] section of the UT.ini file). If I liked the map (for example DM-Axon), I now have it downloaded into my cache folder, and an entry for it is added to the cache.ini file. for example:


Note that this is a cross-reference to a file named


that is identical with the DM-Axon.unr file, except for the filename. To retrieve this map and use it in my own server, I will go into the cache.ini file in the c:UnrealTournamentCache folder and find all the enties in the cache.ini file like:


that correspond to the files I need to run the map (those I have just downloaded). I then write down the file names that are associated with the files I just downloaded. These are hexadecimal names such as (in the above example):


that have the same filename on the right side of the line as I have downloaded. The name on the left is the filename (minus the uxx extension) that is identical with the filename on the right side. To retrieve the DM-Axon.unr file and use it, all I have to do is find the file:


and rename it to DM-Axon.unr and copy that renamed file into the


folder. Do the same thing with all the other files that were downloaded with the map file.

Texture files have .utx extensions and go in the Textures folder.
Music files have a .umx extension and go in the Music folder.
Sound files have a .uax extension and go in the Sounds folder.
System files have a .u extension and go in the System folder.

If you delete any files from the cache folder after you have copied it, delete all the corresponding entries from the cache.ini file and save the modified cache.ini file.

The more players you will host, the larger your maps should be on average (DOH). If you are only hosting 4 players, then keep all the maps small. Games should be about 15 minutes long. If a full server takes longer than this, it probably means the map is too large or everyone is talking.

If you are hosting 6-10 players, mix it up and have some maps that are medium and some that are fairly large, but not huge. Again, 15 minutes is a good target game length.

If you want to host more that 16 players, you will have touble finding maps that are both fun and playable on an average pc. To change the number of players to more than 16, you have to change the MaxPlayers entry in the [Engine.GameInfo] section of the UnrealTournament.ini file to the number of players that you want. UT will not allow you to change the MaxPlayers to more than 16 in the server GUI interface. You actually can, but no change will be entered in the UT.ini file and no effect will be seen.

In the map rotation, don't throw alot of similar maps together. Have maps with different texture colors and different layouts close together. Keep maps with the same basic layouts or colors far apart as possible to provide diversity.

Start the map rotation with smaller maps. This is so the server starts up with smaller maps and the maps get larger as the server is online longer and more players can join. Don't make the first players start playing with only one other player on a large map. They will go play somewhere else. Have the largest maps in the middle to end of the rotation. If you like, you can make the maps smaller at the end to transition to the beginning of the rotation more easily.

Hint: In my opinion, a great map to start a rotation with is DM-Hydride. It is open and plays 2 - 6 players easily. Also, it is a nice looking map. Another map that is not too large and is IMO a really great map is DM-Compulsive. DM-Tempest and DM-Liandri from Epic are also great maps for the first part of a map rotation.

DM and LMS Map Recommendations:

Small Maps:
DM-Veltor ][

Intermediate Maps

Large Maps:

Every mod needs maps with different characteristics. Here are some observations:

This and CTF are the two types of games I am familiar with that are critically dependent on map design.

For LMS, after you start using a new map, watch the play and see if there are problems, such as invulnerable camping spots or spawn points that are way out of the playing area. These invite cheating (camping). After a while, you can spot such maps without putting them in the rotation. LMS maps need to have every place accessible so that players cannot hide. If you let them, they will hide (at least some of the players will...).

Set a maximum game time (such as 30 min). Some times you get players that don't want to kill. Since no server is monitored 24/7, this makes the map rotation keep going. Many times, they are just using map features to their advantage and changing the map will cause them to fight or leave.

Use maps that are fairly wide open and not too many corridors. Some maps are nothing but corridors and makes finding other players difficult.

With this gametype, run a spawn protector program like EavySpawnProtector or something similar.


DM is most forgiving of the game types for map design. Players hunt others out, for the most part, so hiding is not a significant issue as it is in LMS.

Consider hosting a team DM server instead of an single-player DM server. There are thousands of single-player DM servers. Team DM is much more common for leagues and I would prefer to play against a team and get used to color recognition with fewer targets (Just my opinion).

Maps on DM can be smaller than those used for LMS. Players need room in LMS. On DM, less room for each player is necessary. Don't overdo it though.

Don't run a one-map server. Make your rotation with 5-10 great maps rather than many maps of varying quality. Maps that I like include:


There are many other great maps, but I am not that familiar with CTF maps.

If you run custom maps, make sure you have a redirect server. Downloading maps and textures from the server will kill your gameplay quality.

Epic DoS Update

Replace the IpDrv.dll file in the C:UnrealTournamentsystem directory with the Epic replacement IpDrv.dll file available at the following url:

http://unreal.epicgames.com/files/U...pDrv-070902.zip (74KB)

This fix causes the UT server to correctly process ICMP port unreachable messages, and disconnect any connection it receives one for. Replacing the above file reportedly solves the Windows 2000 creeping ping problem and keeps your server from being used by an outside party for a Denial of Service attack. See the following article:



In general, the number of spectators need to be controlled since they also use bandwidth and cpu resources from the server.

Obviously, the number of spectators to be allowed is more important for some games than for others. For DM and CTF, the number of spectators doesn't need to be more than a few to accomodate the admins and a few visitors or prospective players. In these games, players are able to join at any time before the number of players reaches the maximum allowed on the server, and therefore, they don't need to occupy spectator slots to join in the next game. No controls need to be in force since they are able to join late and are penalized by joining late.

I have been told that Epic does not allow new players to join a LMS game after 15% of the total lives available have been lost. I am not aware of any other exclusion criteria.

In a LMS server, the number of spectators is critical for a number of reasons. Most importantly, the number of spectators provides a means of keeping a LMS server full. Only permiting sufficient spectator slots for admins will prevent players from joining since they are unable to judge the time frame during which they may join. As spectators, they are able to keep in the game and join immediately upon starting the next level.

In LMS, new players are not allowed to join a game that is in progress after a certain point. If players join at any time after a game has begun, the late joiners have an advantage in that they start with the maximum allowable number of lives, while the other players have lost some and are therefore at a disadvantage. Also, players that drop out of a LMS game in-progress (after the 15% limit) are not replaced in that game by other players, as is the case for DM and CTF. However, their player slots are able to be occupied by spectators.

The number of spectators should be set with a number of factors in mind. Most importantly, the server and internet connection must not be overloaded by the additional cpu cycles and bandwidth needed by spectators. Also, in a LMS game, it is desirable to have a sufficient number of spectators to keep the server full or near capacity in the evening, particularly Friday and weekend nights.

In addition, spectators contribute to the both the entertainment quality of the server (positive), and the unecessary BS posted on the screen (negative). The relative contributions by these two factors are dependent on the mood and quality of the spectators at any particular time.

I believe that spectators should not be allowed to harass the active players without some control. This is particularly true of the obviously female players. I suggest that admins not allow sexual harassment of any player, nor permit extensive conversations of a personal nature between male and female players. This is a tough judgement call, but I think it is particularly important to protect the younger female players who may not realize the danger of providing personal information to people they don't know. Don't forget that many of the players are ages 10-16 who are a little too adventurous and incautious in general. I treated the console chat as I would a UT chat room. Off-topic discussion was discouraged after a certain point. I guess everyone will have a different level of tolerance in this regard.

Be aware that UT sometimes permits more total players plus spectators than has been entered into the UT.ini file. I have no explanation for this. In some cases, the actual number of MaxSpectators allowed in the UT.ini file has increased, and in other cases, the number of spectators allowed has not been changed, but the number of spectators + players were greater than the total number set in the UT.ini file. In this case, I found no other recourse than to reset the server after the level was completed. Since I ran my server near 80% cpu usage (including UT and the software filewall), additional spectators on a full server could cause big time lag for the players and I had to monitor for this. I also told my admins to watch out for this problem and to reset the spectators allowed when needed using the Webadmin function.

On my LMS server, I reset the level once (and only once) if anyone joined the game as a player after any of the other players had lost 4 lives out of 20. This was also done if any of the players quit and then rejoined after this point. This tactic both made the ensuing game more even scorewise (resetting everyone's lives to 20), and filled the server by allowing more players to join (gave a larger time window for joining). Both positive things from my perspective. The fact that this was a server policy was clearly posted in the F2 display. I think most players liked this policy, even though it clearly confused players who hadn't previously played on my server. Rejoining a game by current players was also discouraged with a rule posted in the F2 display. Players were kicked and warned about being banned if they repeatedly continued to rejoin after a game had started. I don't remember ever having to ban anyone for rejoining.


Try to minimize the number of ServerPackages in the [Engine.GameEngine] section of your UT.ini file. You may reach a point at which you will have too many Serverpackages and you will loose track of them.

Here is an example of a ServerPackages list I found on another forum (the example that started me on this topic in the first place). The poster was having trouble with skins and needed help troubleshooting the UT.ini file.

ServerActors=IpServer.UdpServerUplink MasterServerAddress=unreal.epicgames.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master0.gamespy.com MasterServerPort=27900
ServerActors=IpServer.UdpServerUplink MasterServerAddress=master0.ilangame.com MasterServerPort=28900

For example, the following lines are incompatible:


You cannot have any BP handlers and VA running simultaneously. He needs to delete one or the other.

If you are running VAHandler, you don't need to have any serverpackages that refer to skins. In this case, delete them or start the line with a semicolon to make it a comment that is not executed. One of the most useful functions of VA is to allow servers to get rid of skin serverpackages. If the server is running VA, anyone with any of these skins installed will see anyone using them and no serverpackages for skins are needed on the server, only VAHandler. The players may download the skins they want to use or see and the server is freed from forcing everyone to download these packages.

Also, as in the above example, it is easy to have things like


listed and forget about it. This version is incompatible with UTPureRC51. Dump it if you are not running ZPPure or change the file to version 51 if you want to run ZP.

Note also that in addition to the above comments, he has duplicate entries for


Make sure all the serverpackages are installed on your redir server. If you don't have a redir server, you are in trouble. Everyone will lag constantly from other players downloading a long list of serverpackages. Limit yourself to a minimum number of standard serverpackages unless you have a redir server.

This admin is limiting the number of players he will get to play on his server to almost no one. All these serverpackages (except the few in the Bonus packs) have to be downloaded by players at least once a month (depending on what their cache clear rate is set to). No player would have the patience to download all these packages if they wanted to play on his server, even if they had a relatively fast connection, and would play elsewhere. Some of them are probably large and would be impossible for modem players to download.


8th September, 2006, 07:14 PM
Hi there,

Anyone who can shine a light on a mysterious thing.
I run a dedicated UT2004 server on my P3-1ghz with 512Mb memory based Windows 2003 Enterprise server.
Even with a firewall/router people played along with me i find that if i add maps etc, I dl the maps from my LAN server with the lowest speed ever.....
It takes ages to download even 3Mb.
I toyed with the MaxClientRate and the MaxInternetClientRate but with 20000, or even 200 million did not do the fast lighting speed my LAN network has (100Mbit) Even other players complained that it takes about two hours to dl the map they want to play.
Connecting an external FTP is not possible because that port is occupied by a.... right, my FTP server. Should i do that i have to make a user anonymous without a password and gain all the map files..... Well, that i find not an option.
We talk about a flaw in the software (Windows or UT)
Anyone with usefull tactics?

8th September, 2006, 07:42 PM
Wrong forum. This is the UTPure forum (for the original UT). Try the 2004 forums: http://www.unrealadmin.org/forums/forumdisplay.php?f=96

8th September, 2006, 08:57 PM
and start a new thread, dont resurrect one 3 years old