## Running UTeamFix / Settings

A few things have changed since version 9b. Most important of all, UTeamFix no longer uses its own configuration file, all server settings are stored in the specified ini (whichever it is) - there may be some exceptions someday at some points.

This was a major issue for some admins who wanted to run several servers out of the same system directory with different settings. This is no longer a problem :-)

Also, the settings have moved and are split up now. In 9b everything was in `Advanced options - Game Settings - [game mode]`. I think you will find the new order more practical.

| All options can now be found directly under `Advanced options`. You will find several categories there. See picture left :-) You will notice a lot of settings are now SYSTEMWIDE effective rather than in a particular game mode! This is a major difference after 9b.

Authentication (SYSTEMWIDE) The game type dependent passwords are past! PASSWORDS ARE CASE-SENSITIVE!!
Setting | Effect | Default
--- | --- | ---
AdminPassword | The master administration password. Formerly, every game mode had its own password setting. Now, passwording is system wide and valid for ALL UTeamFix game modes. | boss
bAnnounceAdmins | If true, admins logging in will be announced to all players so they know an admin is present. | False
GamePassWord | If this is not blank, people can only enter your server if they have this password. This password applies to ALL UTeamFix game modes. |
IndividualAdmins | This adds the possibility to register individual admins by username and password. If you don't want to give out your master administration password but yet want to give other people admin rights, just give them an individual "account". Individual admins have all the same privileges as normal admins, however all accesses are logged, so if an admin screws up your server you will see in the log who it was! |

Debugging Options (SYSTEMWIDE) Any debug option may add cpu load and (unlikely) lag
Setting | Effect | Default
--- | --- | ---
bDebugKills | Will log debugging information for every kill which takes place in game. That includes a breakdown of the type of kill (e.g. suicide). | False
bDebugMain | Miscellanious debug logging in the main code (currently meaningless) | False
bDebugMutator | Logs stuff like replacment events of the internal mutator of UTeamFix - actually every CheckReplace() call is logged, regardless if an actual replacement is executed. Careful: This can fill your log up in no time! | False
bDebugReduceDamage | Absolutely -EVERY- event that causes damage to a pawn (usually weapon fire, but can be hazards or other causes too) will be logged with the amount of (initial) damage, damage type, instigator and recipient. If the damage value was modifed, the outcome will also be logged. Modified here does not necessarily mean the damage value changed, it only means it made it through some checks so a modification would theoretically be possible. In addition, every player in-game will get a message per hit it dishes out. So if you really ever wanted to see how much something hurts, turn this on. But the values do NOT include damage factor calculations (such as amplifiers, personal different damagescaling etc) and may be unreliable. The value after "from" indicates the total health the target had the moment it was it. Don't be surprised if you hit someone and see something like `135 of 50` and the target didn't die. It means the target had quite some armor or belt! | False
bUseOldMutator | UTeamFix brings its own Mutator base along, with a ton of new features which are all unavailable to normal mutators. However, the new mutator class takes a LOT of extra function calls so it is ONE POSSIBLE source of lag (theoretically). If you set this option to True, the new mutator will be destroyed and the original will be used. This may cause errors though. Also needless to say, all new mutator features are disabled then and you can't use any other UTeamFix mutators (you can still use old ones). | False

Fairplay Enforcement (SYSTEMWIDE) Formerly game-type dependent, now global.
Setting | Effect | Default
--- | --- | ---
AddAutoMag | You can add an extra gun to the inventory of every player right from spawntime if you wish, since the DispersionPistol is relatively weak (I personally think it's totally useless in multiplayer). If you choose to "AddOneAkimboMag" you enable the Dual-Automag in the game and give one to each player (like in UT :rolleyes:) and when you pick up a 2nd Automag you will yield 2 at once! | off
AllowSpawnKills | If False, players will be protected from being killed right away. The details of how long the protection lasts etc are defined by other settings on this page. The protection is also known as the orientation phase in the game which is indicated to every player via red messages in the center of the screen. | True
AllowTypeKills | If False, players who are killed while they are typing will not increase their death-count or give the killer a point for the frag. In teamgames, this setting has no effect because typing is part of team-game strategies (communication). | True
DestroyAmplifier | Destroys all Amplifiers on maps. | False
DestroyInvisibility | Hmm... hard to guess what this does eh?! | False
GunExpireDelay | The time in seconds between the moment you touch an item and your spawn-protection wears off. This was introduced so people could really get a gun. If someone is comboed or head-shot the moment he touches a gun, that's still a spawnkill. On the downside, if this setting is too high, people might start firing without retaliation. But then again, if some punk follows you around until you pick up a gun just to nail you the instant you do, I think he deserves being shot by an invulnerable enemy :-P | 1
MaxDPShots | This is the number of shots you are allowed to fire with WITHOUT losing the spawn protection. Having a value above zero is necessary because you will likely fire a shot or 2 accidently right after spawning as you were killed in battle (where you fired) so the moment you get killed you will likely still be holding fire, causing you to respawn and fire a shot immediately. | 2
MaxTimeOrientation | The absolute MAXIMUM time in seconds the spawn protection stays on! This should not be set too high, otherwise people can walk over the entire map invulnerable to get to their most favorite gun. Set it too low and people can't get a gun... | 10
PickupAmmoOrientation | If True, players are allowed to pick up ammo without losing spawn protection. | False
SpawnerVisibleEffect | This setting determines how the invulnerability is displayed to other players in game so they know shooting a spawner is just a waste of ammo. No_Effect means.. well.. guess... Glow emits a yellow-ish/green glow around spawners (some people say it looks silly). FireTexturing creates a shieldbelt similar effect around spawners. As a matter of fact, the shieldbelt effect used looks a lot different than a regular shieldbelt, however on low resolution and low-detail clients it may look too similar to distinguish from a normal belt. | FireTexturing

Organisation and Tech (SYSTEMWIDE) Miscellanious crap :-/
Setting | Effect | Default
--- | --- | ---
bAllowHudEnhancements | Some new HUD features can be switched on and off clientside. If you set this True you enable these features, otherwise they cannot be used. (FUTURE FEATURE - there currently are no client side HUD plugins) | False
CountSpecsAsPlayers | This will have spectators counted as normal players. This is only useful if you need to really restrict bandwidth on a total client basis. | False
DisplayAwards | If True, players will see headshots, killing sprees etc on their HUD. | False
DisplayKillnotify | If True, players will see whom they killed in battle (or who killed them) by a message in the upper area of the HUD. | True
Fonts ScoreboardDesign | (effective in teamgame only) The DEFAULT scoreboard has all stats, but some people did not understand everything so a simplified version can be forced (which does not show Teamkills and Frags) | Default
Fonts ShowTeamColorBoxes | (effective in teamgame only) If True, a colored background is drawn on the team scoreboard. | False
Fonts YouAreNotReady | Personally a useless detail. You can have either a small or big font on the start screen which tells you that you can fly around and explore the map... | big
IdlePlayers | If you can't stand idlers on your server, you can have them auto-kicked. The CheckInterval in seconds determines in which time intervals player positions are checked. If KickIdlePlayers is True, idlers who are found will be removed from the server. The lenience setting determines how often a player may be in the same position in consecutive checks (see CheckInterval). Administrators and Spectators are unaffected! | 60 False 3
LIELite | LIE stands for Local Internet Effects and originally a standalone mod. The goal of LIE was, to make internet games look more like local matches, e.g. botmatches. For example, if you look through a portal (e.g. Radikus at the SuperHealth), you do see what's going on at the other side if you play locally (you see items and players through the portal) but not so in network games. Replication is the reason for this! In network play, the server decides what data to send to a client after a set of rules. One such replication rule states that everything which is in a player's direct line of sight has to be replicated. Since a portal is effectively a teleporter the stuff behind the portal when tracing is... just a WALL! The stuff on the other side of the portal is NOT in your line of sight (by tracing means) so the server will not send you data about it - thus, you don't see any items or people behind on the other side. LIE overrides some of these rules and forces the server to send the data anyway. Whichever item you mark as "True" will have its replication rules overriden in game and will thus be visible around corners, through teleporters or transparent walls - just as it should be! NOTE that some extra lag might be induced by enabling LIE. | All items False
Llamas | Don't we love 'em, those idiots who do crap on a server, mass suiciding, teamkilling and all that crap... people like that can be autobanned if you like :-) MassSuiciding is handled by these 2 settings: SuicideBanTime is the time in map-changes a player will be banned who suicides too often SuicideMax is the maximum number of allowed suicides - a value of zero allows infinite suicides TeamKillers can also be auto-banned temporarily, naturally these settings have no effect in non-team oriented games... TeamKillBanTime is the time in map-changes an exzessive teamkiller gets banned TeamKillExceedKills is the number of teamkills a player has to exceed in comparison to his normal kills in order to get banned | 2 map bans after 6 suicides 2 map bans after 4 teamkills
MuteSpectators | If True, Specs can't talk (and disturb the players with their rants) | False
Network AddWaitTimeMapChange | With all the extra infos or many people on the scoreboard, you may want to take a screenshot or just study it and take your time. Normally in Unreal the server will wait as many seconds as "ServerTravelPause" is set to, but setting that value too high causes clients to lose connection. So here it is, an added delay which takes effect when game ends. Enter any number (seconds) to additionally wait at game end before the server starts the map-switch process. | 15
Network FastTimeOut | This is a convenience setting for lazy admins :-D If you want to know what this does in detail check the advanced docs | Falst
Network Interfaces | See the advanced docs for an explanation. You can basically enable/disable communication interfaces individually. | All False
MinTimeBetweenLogins | To avoid lag and fun-rejoiners a player can only login again after some time has passed. The minimum setting is 10 seconds anything below is invalid and will be overriden for the server's own safety. This is the MINIMUM time in seconds that has to pass before a player can login AGAIN after he already had a login. On stable servers, I suggest values of 30 to 60 seconds. If players crash often on your server, lower it, otherwise a high value will piss off lamers you keep kicking, because it takes their time to rejoin just to be kicked again :-D | 10

Mutators: These menues are described here.

UTeam Game Modes (individual game settings) Mentioned settings here will work on a per game basis, so you have to configure them for each game-type individually...
Setting | Effect | Default
--- | --- | ---
AirControl | Air Control is the amount of control a player has to move in flight in comparison to when it is on the ground. By default, the Unreal Air Control is five percent (0.05) which is very little Air Control, so you fly mostly in the direction you jump with little to no possibility to correct your course in flight To set the Air Control to a different standard, just change the AirControl_Player setting to one of the predefined values (Unreal_Default = 0.05 -- UT_Default = 0.35 -- U_Gold_Default = 0.40) If you want a free to choose individual setting, set it to Custom and enter the exact value you want into Custom_Air_Control. | Unreal_Default
bChangeLevels | Original Unreal setting - If False, the same map will be repeated over and over, True will cycle through the given maplist. | True
bClassicDeathmessages | Original Unreal Setting... go bug someone else... | False
bCoopWeaponMode | Original Unreal Setting - Weapon Stay in other words. | True
bHardCoreDamage | If True, all damages will be multiplied with the factor 1.5 In orginal Unreal, hardcore damage was tied to hard core mode (see below). | True False in TeamGames
bHardCoreMode | If True, players move a little faster and can jump a little higher. Originally bHardCoreMode also increased the damage in non-TeamGames but the 2 settings are separate in all UTeamFix games so you can combine or set them individually at will. | True
bHumansOnly | Allow or disallow non-human players (Skaarj, Nali...). Clan matches should be fought with this setting at True. | False
bMegaSpeed | Original Unreal Setting - VERY fast player movement | False
bMultiPlayerBots | Original Unreal Setting: whether or not to allow bots in network play. A totally useless feature in my opinion - you can always set the number of bots to zero anyway if you don't want bots... | True
bNoMonsters | Original Unreal Settings: Whether or not to allow monsters to be present in the game. Monsters could quite mess up a game in original Unreal, especially team games - but that's mostly fixed in UTeamFix :-) | False
bNoTeamChanges | Original Unreal Setting (teamgames only): Allow or Disallow team changes during game. | False
bSpawnInTeamArea | Original Unreal Setting - teamgames only: is this feature working at all??? | False
ForceRespawnSeconds | Time in seconds after which a dead player is FORCED to respawn if it wants or not. Good to enforce some faster paced games. Setting this to 0 disables forced respawn. | 0 (disabled)
Fraglimit | Number of kills to score to end the game. In teamgame, the value represents the number of kills a TEAM has to score as a whole, not the individual player. Zero (0) means no limit. | 25
FriendlyFireScale | Original Unreal Setting - teamgames only: If players shoot their teammates they will take a percentage of the damage as given here. Actually this is just a damage modifier for your team, 0 meaning your team cannot harm teammembers, 1 meaning teammembers take normal damage. 0.5 would be 50%, so teammates would take half the damage form shots from their teammates compared to shots from enemies. Original Unreal usually plays without friendly fire, but personally I find this boring as it encourages a lot of people to blindly spam wide areas with rockets and combos. If you can actually kill your teammates it is a greater challange IMO as you have to watch where those bullets go... | 0.00 No FF
IllegalStringResolve | A technical setting which has unfortunately to be in the game type settings. If key/value pairs cannot be properly resolved, this string will be the result. This avoids crashes and a number of value-related bugs. | <<ILLEGAL>>
InitialBots | Original Unreal Setting: Number of bots that join the game automatically. | 0
MaxTeams | Original Unreal Setting - teamgames only: number of possible teams, values allowed are 2 to 4, some game modes may enforce a value of 2 | 4
MaxTeamSize | Original Unreal Setting - teamgames only: Number of players that can join a team at maximum. | 6
TeamBalance | If True, the preferred team player chose when joining the server will be ignored if teams are of different size. This will try to keep teams balanced. This setting MUST be turned off in clan matches. | False
TimeLimit | Original Unreal Setting: number of minutes a game lasts at maximum. | 10
TournamentMinPlayers | If you use the Tournament Mode Tournament, this is the minimum number of people that are required to start the game at all. | 1
TournamentMinWaitTime | If you use a Tournament Mode of Tournamant or UT_Style, this is the number of seconds the game start will be delayed under all circumstances, giving all players some time to join the map before the fragging starts. | 30
TournamentMode | In normal Unreal you would enter the game and immediately start to frag - or just DIE the instant you spawn, since you don't have control over your player for a fraction of time which most players use to get a cheap point on you if they get the chance. off is the original Unreal setting. Simple has players go into a flying state in which they can explore the map without being killed. Pressing fire once is enough to join the game. Tournament is the REAL Tournament mode which I do strongly recommend for clan matches, but strongly advise against on public servers. In this mode, all joining players have to signal that they are ready before the match starts. UT_Style waits for one player to join, the delays match start just a bit to give other players a chance to join before match starts. However, no ready-signals will be waited for, a short time after the first player arrives, the match WILL commence. | Simple