46 · Evolution in operation

What Evolution 1.2.3c gives a server admin, and the two features worth stealing outright.

The preference surface

evo_prefs.cs declares 89 $Host::Evo* variables [mod-script]. It is explicitly a defaults file, not a config file, and the readme is blunt about the distinction:

“The evo_prefs file is like serverDefaults.cs in base/classic. Do not edit this file, it is only used to populate prefs/ServerPrefs.cs” [mod-script]

Roughly grouped:

The pattern in the first group is the important one. Evolution does not simply have an admin ban command — it has $Host::EvoAdminBan, a switch controlling whether ordinary admins may ban at all, separate from whether SuperAdmins may. Every admin capability is individually delegatable. That is the difference between a two-tier admin system and an actual permission model, and it is what made Evolution the choice for servers with more than a couple of trusted people.

The readme also warns about the interaction with Classic itself [mod-script]:

“Some Classic $Host:: values will have no effect as they are overridden by Evo values. Some Classic vote options will not exist.”

An override layer necessarily shadows some of what it overrides. Say so in your documentation, as Evolution does — a silently ignored pref is worse than a missing one.

Leased SuperAdmin

The standout feature, and one this handbook has not seen anywhere else: time-windowed admin grants, loadable over HTTP.

prefs/leasedSA.txt [mod-script]:

// This is the file specifying time-limited SA claims on the server, as they
// can be used for leasing out the machine for clanwars.
// Any file with the same syntax as this can be used, even obtained via HTTP.
// Anything standing behind a '//' is considered a comment.
//
// Each SA claim takes a separate line, in the format:
// <WonID> <StartingTime> <EndTime>
// Where <WonID> is the player's WonID that can be found via .whois or .wonid
// on the Evolution Chat console.
// The dates are formated like:
// <2 digit year><2 digit month><2 digit day><2 digit hour><2 digit minute>
//
// Examples would be:
// 0815 0301011800 0301012200 // January 1, 2003, 18:00-22:00, WonID 0815
// 4711 0304011930 0304020000 // April 1st, 2003, 19:30-midnight, WonID 4711
//
// Since version 1.1.0, a fourth argument can be given, to determine
// the admin level to be granted. 1 means Admin, 2 means SuperAdmin

Four whitespace-separated words per line: WonID, start, end, and an optional level. Parsed with getWord [mod-script]:

$EvoLeaseLevel[$EvoLeaseCount] = getWord(%line, 3);
…
$EvoLeaseLevel[$EvoLeaseCount] = $Host::EvoDefaultLeaseLevel;

— the fourth word if present, the configured default otherwise. Note the shape: a parallel-array record, $EvoLeaseLevel[%i] alongside the other per-lease fields, indexed by a counter. That is the V12 way to hold a table, and it is the same idiom the base scripts use for $TeamName[%team] (TorqueScript).

Why this matters

The problem it solves is real and still current. A clan rents a server for a match on Tuesday at 20:00. They need SuperAdmin for that window — to set the map, lock teams, run the tournament — and must not retain it afterwards. Without leasing you either hand out a permanent password and rotate it manually, or have an owner present at every match.

Evolution’s answer: a text file of time windows keyed to identity, fetched over HTTP so the file can live on the clan’s own website and be edited without touching the server. The booking system and the game server stay decoupled.

This generalises well beyond Tribes 2. If you are building anything with delegated administration: express grants as time-bounded records against a stable identity, keep them in a document the grantor controls, and let the server poll it. Evolution got there in 2003 with FileObject and a WON ID.

The parts that do not survive

WonID is gone. WON shut down in 2003 and the identity it keyed no longer exists. Under TribesNEXT, identity is the patch’s own account system; under RC2a, the RSA certificate. A modern equivalent must key leases to whatever the patch provides. See 07 · Community Patches.

HTTP fetch is unauthenticated. $Host::EvoHTTPProxy and $Host::EvoDebugHTTP imply plain HTTP with no signature over the document. Anyone able to intercept or spoof that fetch grants themselves SuperAdmin. In 2003 on a LAN-adjacent threat model that was tolerable; today, serve it over a channel you trust or keep the file local.

The chat console

Evolution exposes admin functions through chat commands rather than a HUD — .whois and .wonid are named in the lease documentation [mod-script], dispatched from scripts/evolution/parseCommands.cs (507 lines).

The reason is the one from section 38: a server-side mod cannot ship interface to clients. A player joining with a stock install has no Evolution HUD and never will, so the command surface has to travel over a channel that already exists — chat. Every admin mod in this handbook lands on the same answer; Construction’s chat-command dispatch is documented in Reusable mechanisms.

The design consequence is that your command parser is a security boundary. It reads attacker-supplied strings from anyone who can type in chat, and dispatches on them. Validate the caller’s admin level inside each handler, not once at the parse site.

Logging

Seven of the 89 prefs are logging switches, and the granularity tells you what admins actually needed: chat, canned chat (voice-menu spam), connections, admin actions, and teamkills, each independently toggleable, with daily rotation via EvoDailyLogs and EvoDailyHour.

Classic 1.5 had already moved connection logging to CSV “for easy import into databases”, crediting Aureole’s AurLogging [mod-script]. Evolution extends the same instinct. For a 2004 community running ladders and adjudicating disputes, the server log was the evidence base — which is exactly why the teamkill log’s correctness mattered, and why section 47 is about a single line in it.

Installing it

From the readme [mod-script], with the order preserved because it matters:

1. Clean 25034 install.
2. “Delete all dso files via your operating system and not via some script.”
3. Remove any other admin mod entirely — see below.
4. Unpack into GameData/classic (Linux: ~/.loki/tribes2/classic).
5. Edit classic/prefs/evo_mapRotation.cs.
6. Delete classic/scripts/evolution/evoPackage.cs if it exists (section 45).

Step 2’s parenthetical is pointed: Classic’s own .bat launchers delete .dso files by wildcard per directory (section 38), and that enumeration does not cover scripts/evolution/. The mod’s new subdirectory is invisible to the shipped cleanup, so the readme falls back to telling you to do it by hand. If you add a script directory, add it to the cleanup.

Step 3 is the constraint that shapes this whole family of mods:

“If you have been using other admin mods, make a backup of their files and remove them from your tribes installation. There might be severe problems combining different admin mods on a server, as they tend to alter the same game resources in an incompatible way.” [mod-script]

Two mods that both override DefaultGame::testTeamKill do not compose. Packages nest, so the second one activated wraps the first and both run — but neither author tested that, and the ordering depends on activation sequence. Admin mods are exclusive in practice.

Related

• 45 · Evolution Admin Mod — the .ovl architecture
• 47 · teratos’ evoClassic — fixing the teamkill log
• Text and messaging — the chat channel as an interface
• Hosting and testing — prefs versus defaults
• 58 · Reusable mechanisms — chat-command dispatch elsewhere