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:

http://pages.infinit.net/darkbyte/filez/BanHappy.zip

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:

http://www.unrealadmin.org/modules.php?op=...+Service+by+Bry

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

http://arstechnica.infopop.net/OpenTopic/p...&m=41909953&p=4

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:

Suppress=DevNet

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:
http://www.theadminpage.com
for useful utilities, hints, tweaks, etc.

The site's forum is useful also:
http://forums.theadminpage.com/ultimate.cgi

==================================
Server Parameters

For a readable explanation of NetServerMaxTickRate and MaxClientRate see:

http://www.clanvikings.org/tnse/utstuff.html

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)

==================================
Cheaters:

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:

http://www.unrealadmin.org/modules.php?nam..._op=getit&lid=2

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: 24.148.0.0 to 24.148.100.100 and 24.148.100.102 to 24.148.255.255 will effectively ban the range 24.148.*.* without banning the IP address 24.148.100.101.

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:

http://www.midnightinteractive.com/forums/...?s=&postid=5525

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, assholes, 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.