SPADS (Spring Perl Autohost for Dedicated Server) is a Perl autohost program for Spring, released under GPL v3 license. It has been designed from start for headless servers without any graphic interface, and is heavily customizable through various configuration levels.
Unfortunately, I haven't had time to write a real operating guide yet, but you should still be able to install it by following the instructions in the INSTALL file of the installation package. You should also be able to configure it quite easily by editing the various configuration files (I tried to give meaningfull names to settings, and all settings are described here).

It'a beta version, so if you have any question/problem, feel free to contact me in the lobby or forum.



Requirements for Linux/UNIX:

• Spring must be installed with at least 1 mod
• Perl, Swig, g++ and wget must be available (Swig and g++ are used to generate the Perl unitsync interface only, and wget is used for the install/update functionnality)

Requirements for Windows:

• Spring must be installed with at least 1 mod
• ActivePerl "Windows (x86)" must be installed and the Perl bin directory must be in your PATH environement variable
• wget must be installed and the wget bin directory must be in your PATH environement variable

Overview of the functionnalities implemented in the beta version:

• Persistent lobby connection: lobby disconnections don't affect running games (for example it auto-reconnects as "in-game" after network problems if a game is currently running)
• Linux-type file structure (binaries and configuration files can be shared between multiple instances)
• Dynamic configuration (configuration files can import other files, can contain macros, can be reloaded while running)
• Auto-update (debian-like update system: stable/testing/unstable, can wait for empty battle and/or game-end before restarting)
• All events/chats can be logged (each interface has its own log level)
• Fully customizable rank-limits (upper rank-limits, lower rank-limits, auto-spec/auto-kick...)
• Advanced commands right system (can be changed on-the-fly, any information available in lobby protocol can be used as command requirement: rank, admin-flag, cpu...)
• Clear separation of SPADS settings (gathered in "presets"), Spring lobby settings (gathered in "hosting presets"), and Spring MOD options (gathered in "battle presets")
• Allowed values for each SPADS/lobby/MOD setting can be restrained separately
• Generic and automatic vote system (any command can be voted, and a vote is called automatically when you don't have sufficient rights to execute a command directly)
• Each user can define his own autohost preferences (minRingDelay for example is the minimum delay before you can be rung another time by the autohost)
• Lobby channel management (kick, ban...)
• Output flood protection (no bot flag required, SPADS restrains itself from flooding according to server thresholds)
• Input flood protection (battle lobby flooders are auto-kicked, command spammers are auto-ignored temporarily, recidivers are auto-banned temporarily...)
• Multiple ban lists management with multiple levels of bans: auto-spec, battle auto-kick, channel auto-kick (any information available in lobby protocol can be used as ban filters, regexp can be used...)
• Join/kick flood protection through random password system (non banned users can request the password with command !pass)
• Advanced automatic rotation (maps or presets can be rotated automatically, when battle is empty and/or after each game...)
• Several map lists can be defined and applied on-the-fly, with include/exclude regexp filters
• By-user vote-modes are detected automatically to speed up votes (auto-vote blank for away players)
• Deep battle structure auto-management (SPADS can auto-manage any type of battle: 1v1, 4v4v4v4, 3x3 v 3x3 v 3x3 ...)
• AutoSpecExtraPlayers can be used to prevent spectators from unspecting when battle is full from autohost point of view, or advanced autoLock mode can be used to auto unlock the battle when this happens...
• Optionnal auto-block teams/id/colors feature when teams are balanced/fixed
• Map boxes auto-learning (different sets of start boxes can be saved for each map, according to the number of teams)
• Can print detailed information about the current running game with the !status command (usefull to guess if the current running game will end soon)
• Unlock-for-spectators functionnality
• Ready for on-demand autohost service with temporary operators and auto-close when battle is empty

Hey Bibim,

Thanks alot for the beta release, I just have to show my appreciation here. It's a job very well done! Works amazing and is nice and clean.

upper rank-limits == win

# Input flood protection (battle lobby flooders are auto-kicked, command spammers are auto-ignored temporarily, recidivers are auto-banned temporarily...)


# Join/kick flood protection through random password system (non banned users can request the password with command !pass)


# Unlock-for-spectators functionnality

cool peas.

Windows support is now available, still in beta version though (first post updated). You must select "testing" release during installation for Windows support.

Lots of new features have been added since original post, among them:

• Windows support with optional automatic binary updates for future spring versions (nothing to do to stay up to date)
• Presets can be loaded automatically on map change (map-presets)
• Intelligent automatic preset/map rotation (adapted to the number of players currently in battle)
• Auto-force start when only unsynced or already in-game spectators are missing
• Alert system for AutoHost administrators through lobby private messages
• Detailed help for all modoptions is available through !help command
• Spring archives can be reloaded automatically when new maps or mods are detected in the data directory
• Regular expressions can be used for mod names, so that battles are automatically rehosted when a new version of current mod is available in data directory
• Separate commands for balancing / rebalancing (!balance will always balance the same way until the game starts or !rebalance is used)
• Ability to host a map without having the map archive locally on the server (ghost map hosting)
• Maps can be learned automatically for ghost map hosting, by spying other battles dynamically, with optional host/map name filters
• Autohost level authentication (usefull when lobby server is running in LAN mode)

Detailed changelog for each SPADS component is available here

Hi. I m trying to install spads on a debian 5.0 (lenny) server.
I ve got a user acces and I succesfully compiled spring project (0.78.2.1), but as I ve not the rightsd to preform the "make install", I just copy/pasted absolute path to libunitsync.so and spring-dedicated files.
However, whatever I choose stable/testing or even unstable version, spadsInstaller give an
"ERROR - [SpadsInstaller] Unable to initialize UnitSync library"

Do you have any idea of the problem ?

1/12 - Which SPADS release do you want to install (stable,testing,unstable) [testing] ? testing
INFO - [SpadsUpdater] Updating package "getDefaultModOptions.pl" to "getDefaultModOptions_0.2a.pl"
INFO - [SpadsUpdater] Updating package "help.dat" to "help_0.8.1.dat"
INFO - [SpadsUpdater] Updating package "PerlAutoHostInterface.pm" to "PerlAutoHostInterface_0.5a.pm"
INFO - [SpadsUpdater] Updating package "PerlLobbyInterface.pm" to "PerlLobbyInterface_0.8.pm"
INFO - [SpadsUpdater] Updating package "SimpleLog.pm" to "SimpleLog_0.3.pm"
INFO - [SpadsUpdater] Updating package "spads.pl" to "spads_0.7.2a.pl"
INFO - [SpadsUpdater] Updating package "SpadsConf.pm" to "SpadsConf_0.7.0.pm"
INFO - [SpadsUpdater] Updating package "spadsInstaller.pl" to "spadsInstaller_0.7a.pl"
INFO - [SpadsUpdater] Updating package "SpadsUpdater.pm" to "SpadsUpdater_0.3.pm"
INFO - [SpadsUpdater] Updating package "update.pl" to "update_0.2.pl"
NOTICE - [SpadsUpdater] 10 package(s) updated
NOTICE - [SpadsInstaller] Restarting installer after update...
NOTICE - [SpadsInstaller] Components are up to date, proceeding with installation...
2/12 - Please enter the absolute path of the unitsync library (libunitsync.so,unitsync.so) [] ? /home/old/servsodalis/spring/spring_0.78.2.1/tools/unitsync/libunitsync.so
NOTICE - [SpadsInstaller] Generating Perl Unitsync interface module
3/12 - Please enter the absolute path of the spring dedicated server (spring-dedicated) [] ? /home/old/servsodalis/spring/spring_0.78.2.1/tools/DedicatedServer/spring-dedicated
4/12 - Please enter the absolute path of the spring data directory (for maps, mods...) [] ? /home/old/servsodalis/spring
NOTICE - [SpadsInstaller] Checking Perl Unitsync interface module
ERROR - [SpadsInstaller] Unable to initialize UnitSync library

If it's just a problem with access rights on system directories, you can add "-DCMAKE_INSTALL_PREFIX=/some/install/path" to your cmake command so that it will install into this directory.

It seems the unitsync library doesn't work, can you check your unitsync.log file for any error ?

You were right : I missed a proper installation with the "-DCMAKE_INSTALL_PREFIX=/some/install/path" option. Now everything s fine.
thx u

Hey, thank you for making the autohosts. They're really cool.

I would like to make a feature request that may or may not be easy to do. TheFatController has just about finished implementing CoOp mode for Balanced Annihilation, and we'd like to be able to play it on the autohosts.

It would be really great if players could voluntarily opt in to cooping with eachother. All the autohost has to do is recognize who these players are, put them on the same ally team, and even though they're comm sharing count them as separate members.

I think the most reasonable way to make a first implementation of this is to make it opt-in by a manual command. So if I say "!coop 1", for instance, then I'm telling the autohost to please put me on the first coop team. TheFatController could then say "!coop 1" and the autohost would then know we want to be together. For balancing purposes we could be considered a two person clan. We could then have different, smaller coop teams joined together in one big ally team - a 5 man team could be composed of two players on !coop 1, two players on !coop 2, and one player who didn't opt in to coop, for instance.

That would be enough to play, although we could go further if needed.

For instance, if I don't want to coop on a specific team but would like to coop with whomever I end up with, I could do a command like !coop any - then anyone who had !coop any and was on my same allyteam would be cooped with me as well. So if x and y had !coop 1 and !coop any, I could join their team by doing !coop any.

Anyway, whatever ends up happening, thanks in advance! Also, play multiplayer coop with us some time

Thank you, happy to see you enjoy it.

Concerning the !coop <nb> command which lets you choose the ID you want to be in, I think it would be too open to abuse: how would you prevent people you don't want to be with from doing !coop with the same ID number as yours for example ? If you can trust players concerning this, then it may be simpler to just do "!balance" and then adjust your ID (not your ally team) yourself if you want to share ID (just ensure "autoBalance" is set to "off" and "autoBlockbalance" to "0"). That way you will use SPADS auto-balance for ally teams, but you will still be able to change your ID because autoBalance and autoBlockBalance are disabled. And this should already work in current SPADS version (however you will have to use !forceStart to launch the game if there aren't the same number of IDs in each ally team, because SPADS will think teams aren't fair).

If you want to avoid this manual ID selection part (though I'm not sure it's a big deal, because only players who want to coop would need to do it), you can still configure SPADS to auto-balance for comshare, and use clan tags to select players you want to coop with: you just have to set the "nbPlayerById" setting to a value greater than 1 and reduce the "teamSize" setting so that SPADS will have to use shared IDs to comply with the target battle structure (SPADS first tries to fill the ally teams with one player by ID until "teamSize" is reached, then it adds remaining players in the existing IDs if "nbPlayerById" is greater than 1). IDs use the same balancing rules as ally teams: if "balanceMode" is set to "clan" or "clan;rank", SPADS will try to put players of same clan in same ID. So you have some control about which players are sharing their units through clan tags. It's not as flexible as the solution you explained because you have to use clan tags, but it should work in current SPADS version and I think it's less open to abuse.

Finally, I think the manual ID selection command could lead to somple complex cases regarding auto-balancing: for instance, when 2 players do "!coop 1" they must be in the same ally team. But if they have different clan tags then all the players of both clans should be in the same ally team. What if teams aren't big enough to contain the 2 clans ? Should we break the coop or one of the clans ? We would have to add some sort of priorities on all these constraints which could become quite confusing for players... Moreover, it would become even easier for players to trigger totally unbalanced games: currently they have to use clan tags to be sure to be in the same team, and usually players don't rename between each battle just because they saw a good player they want to be with. But with a !coop command all they would have to do is choose the same coop id. I think there would be even more aguing in battle lobby about players totally breaking the balance by using !coop command, and it could take quite long to start a game...

I was originally going to suggest naming your friends but figured this was simpler. As you point out it may be necessary.

So I type: !coop TheFatController, and he types !coop YokoZar, and then we're together. One of us (but not both) types !coop bibim, and you type !coop YokoZar, and then all three of us are together.

That pretty much solves it. I think keeping it to "one person on the team's permission is enough" is ok - If we require every player to type every other player it quickly gets hard.

Hmm, seeing as it's hard enough to stop people from spamming !cbalance a million times even before the game has enough players, I don't think this is workable unless support for coop is coded in.


You could, of course, just treat the !coop id's not as separate clans but instead on a per-team basis. That way if everyone in 6 person clan foo types !coop 1 then there will be two separate coops on the different teams when it's a 4v4. So here you'd balance normally and only afterwards look at the !coop requests. I think that works pretty well, other than the possible "I don't want him in my coop" problem above.

when player is kicked/votekicked, automatically apply a 5-10 minutes ban (otherwise they just reconnect)

And with current lobby design, is it possible to have IP bans at all?

From what I understand, the !coop <name> command would then add a player to the list of players who can share ID with you (transitively). But then, wouldn't we also need a !uncoop command to remove a player from this list ? What would you do if you change your mind and finally decide to coop with someone else ? Maybe !coop without any parameter would reset the list ?

Yep, this method only works if you can trust players, which doesn't happen very often unfortunately...

Ok so basically you would wait for the battle to be full and balanced, and then you would enter the !coop <nb> commands ? The problem is that usually when the battle is full and balanced, there are still players leaving and joining it, and thus the battle is rebalanced. So I think we would end up with lots of !coop commands each time the battle is rebalanced, with players taking the same numbers by mistake etc...

Personnaly, instead of a !coop command, I'd go for adding a shareId SPADS preference (= by-user setting) and an idShareMode SPADS setting:
When the idShareMode setting is set to auto, current behaviour is used. SPADS tries to respect target battle structure (nbTeams / teamSize / nbPlayerById) as much as possible, regardless of the shareId user preferences.
When the idShareMode setting is set to manual, SPADS ignores the nbPlayerById setting and it only makes players of the same team share ID if their shareId preference contains the same string. So basically, the shareId preference would be like an identifier for the ID, which must be known by the other players if they want to share ID with you.

Players would be able to set their shareId preference like any other SPADS preference: !pSet shareId <value>.
If a player wants anyone to be able to share ID with him, he can say the !pSet command publicly in the battle lobby (or can simply give the current value of his shareId setting in the battle lobby).
If a player wants only some other players to share ID with him, he can say the !pSet command in private to the AutoHost and then give his shareId preference value to selected players.

If you want to ban a player, you have to use the !ban command, why would the !kick command ban at the same time ? For instance !kick can be usefull to kick afk players, but you don't want them to be banned at the same time...
I think what you're asking for is a way for an unprivilegied user to call a vote for a temporary ban. Currently AutoHost admins can choose to allow players to vote for ban, but then they can't limit the ban duration so usually they don't do it. Maybe an additional !tmpBan command would be usefull for this indeed, I will think about it...

First, strictly speaking we can't ban from battle lobby, all we can do is auto-kick.
And the lobby server doesn't give the routable IP of players who join a battle, so we can't auto-kick by IP.
However, there are still other ways to guess user IPs (communicating with other bots that have admin access, maintaining an IP cache of all players who hosted a battle in the lobby or played at least once on the AutoHost etc...).

Too complicated to maintain such thing and in anyway you can just make a new account for every time you ruin a game. I guess there is no way, unless the battlelobby will tell the hosts the user's IP.

Or, on the other hand, IP-bans can still be used, but as a matter of prevention (so a player can join the battle, start it, but once he connect to spring, he will be immediately kicked, causing a nusance, but at least not ruining the game)

You can use trick springie is using to get IP, use NAT traversal and it will get IP

Yeah, this too.
However, isn't there a risk that some players with specific network configuration wouldn't be able to join the server anymore due to unnecessary NAT traversal usage ?

I'm not aware of that doing anything to affect spring itself. Does it?

One kind of NAT traversal (possibly in combination with other factors) breaks my ability to connect to the particular host using it.

Never figured out which kind tho, or whether the NAT traversal is really the cause, or just not enough solution, for me.

So you don't know if you could have connected with NAT traversal off?

Well, concerning hole punching method for example clients have to send some UDP packets to a third party server to acquire their nated ports, the host has to send some hole punching UDP packets to the clients nated ports to effectively open UDP "sessions" before launching the game, and then clients must try to connect to the host NAT-ed port instead of the broadcasted port in lobby. Clients must force Spring (through startscript settings) to use the sourcePort and hostPort acquired during hole punching. And I guess this whole process could fail sometimes...