Spring RTS Engine

I'm testing a new autohost program, called SPADS (Spring Perl Autohost for Dedicated Server).
I tried to ease the administration of dedicated servers, and enhance the player experience with autohosts. However, since people are really used to Springie, I had to implement wrappers for main Springie commands that had been replaced in Spads.

These wrapped commands aren't the best way to use Spads, but I understand one doesn't want to read through all the help messages just to start a game. That's why I wrote this very minimal list of tips:

• You shouldn't need to use "!balance", "!fixcolors" and "!autolock" commands with Spads (they are just here so that people don't think the autohost lacks these functionalities...). Instead, you just have to tell Spads what is the structure of the battle you want to play (only if it changed since last game). For instance if you want to play a 4v4v4 game, you can type:

  Code: Select all

  !set nbTeams 3
  !set teamSize 4

  Then, if configured so, Spads will automatically manage the battle for this structure: balance, fixcolors, autolock, autospec, even ring or pvMsg according to user's preferences (per-user configurable ring spam protection)...
• There is no !voteexit, !voteforce, !votekick... command in Spads, just a !callvote command that takes any command as parameter, so any command can be voted
• In the same way, there is no !listbans, !listmaps, !listpresets... command in Spads, just a !list command (for instance: !list maps, !list bans, !list users...)
• You don't need to use the !callvote command explicitly, you can call the requested command directly, and Spads will automatically call a vote if needed
• When you call a vote, you don't need to vote just after, Spads considers you already voted for the command since you started the vote
• Use "!list presets" for available presets, and "!list settings", "!list hSettings", and "!list bSettings" for various tunable parameters lists

And here are some additional information about Spads, for those who are interested:

Initially I planned to prevent changing the autolock number (i.e. "teamSize" parameter in Spads, when autolocking is activated) directly, forcing people to call a vote when they need to change it. The goal was to prevent people from unlocking a battle just because they have friends who want to join, thus transforming a ready-to-launch 5v5 game into a 8v8 mess on a small map... But I realized people were too much used to being able to change the autolock number as they want, so finally I kept Springie behavior by default...

I'm currently running 4 Spads hosts, they only differ by their default preset:
- Spads1 --> duel (1v1)
- Spads2 --> smallTeams (3v3 max)
- Spads3 --> mediumTeams (6v6 max)
- Spads4 --> trainingCamp (16 players max)
However you can apply the preset you want to any of these hosts (use "!list presets").
For instance, if you want to do a 1v1 and Spads1 is currently in use or offline, you can join Spads4, say "!preset duel", then "!rehost" (to apply the new hosting settings) and you have a "duel" autohost.

Initially, I started Spads development because there was no autohost for Linux. Now that Springie runs on Linux through Mono, there is less interest in Spads. However I think Spads offers more administration capabalities and automatic features. On the other hand, it doesn't use SpringDownloader at all and requires unitsync to retrieve mods and maps data from local files. Anyway, if some people are interested in running Spads autohosts (it only requires a linux box with Perl), drop me a PM. It's just to know if it worths making an installer and some documentation. I still plan to add some features and test some other mods before releasing anything anyway.

Hi,

I'm a pro speccer and I often can't join a battle which all its players (eg 12/12 locked). As you manage battle structure (eg 6v6), could you make the battle unlocked (even if full of players) to allow spec to join before it starts ?

If no, I'll be forced to !autolock that poor springie.

Masure wrote:I'm a pro speccer and I often can't join a battle which all its players (eg 12/12 locked). As you manage battle structure (eg 6v6), could you make the battle unlocked (even if full of players) to allow spec to join before it starts ?

If no, I'll be forced to !autolock that poor springie.

I had initially planned to deactivate autoLock by default on Spads autohosts and use autoSpecExtraPlayers instead. Which means that when there are already nbTeams * teamSize * nbPlayerById players in the battle lobby, the battle isn't locked but instead next users who join the battle are automatically spected. But once again, users expected to be able to autolock the battle and they thought the autohost was broken, so I reverted to Springie behaviour by default. The autoSpecExtraPlayers is still usefull and activated by default though, to prevent specs from unspecting when there is already the target number of players in the battle.

Anyway, actually I think it's not a good idea to keep a battle open when it's full from autohost's point of view (for instance there are 12 players in a 16 players max battle and autohost is configured for 6v6): players would keep joining thinking they can play whereas they would be forced to spec. It's a little like saying a battle is not ingame whereas it is, players feel cheated...

However, I can implement a !specJoin command that would unlock the battle and autorelock it as soon as the player join the battle or after 2 seconds if he doesn't join for instance. That way people who join would know that they could only spec the battle...

bibim wrote:

Masure wrote:I'm a pro speccer and I often can't join a battle which all its players (eg 12/12 locked). As you manage battle structure (eg 6v6), could you make the battle unlocked (even if full of players) to allow spec to join before it starts ?

If no, I'll be forced to !autolock that poor springie.

I had initially planned to deactivate autoLock by default on Spads autohosts and use autoSpecExtraPlayers instead. Which means that when there are already nbTeams * teamSize * nbPlayerById players in the battle lobby, the battle isn't locked but instead next users who join the battle are automatically spected. But once again, users expected to be able to autolock the battle and they thought the autohost was broken, so I reverted to Springie behaviour by default. The autoSpecExtraPlayers is still usefull and activated by default though, to prevent specs from unspecting when there is already the target number of players in the battle.

Anyway, actually I think it's not a good idea to keep a battle open when it's full from autohost's point of view (for instance there are 12 players in a 16 players max battle and autohost is configured for 6v6): players would keep joining thinking they can play whereas they would be forced to spec. It's a little like saying a battle is not ingame whereas it is, players feel cheated...

I understand that point

bibim wrote:However, I can implement a !specJoin command that would unlock the battle and autorelock it as soon as the player join the battle or after 2 seconds if he doesn't join for instance. That way people who join would know that they could only spec the battle...

And that would be great !

I'd like to try and help testing Spads. I sent you a private message as you asked above.

I do like the idea of using perl instead of mono and I love the idea to run an autohost without X.

Thanks for your effort!

For anyone reading that does not know, springie does have a !manage command; people just tend to not use it at all.

lurker wrote:For anyone reading that does not know, springie does have a !manage command; people just tend to not use it at all.

Actually I've seen people using it. But I think the problem with the way Springie handles it is that as soon as someone else enter !autolock 12 for instance, it deactivates the auto-managing feature... That's why I separated clearly in Spads each automatic feature and the target battle structure. !autolock is just wrapper to update teamSize and autoLock settings, but other settings aren't updated by this command (autoSpecExtraPlayers, autoBalance, autoFixColors ...).

lurker wrote:For anyone reading that does not know, springie does have a !manage command; people just tend to not use it at all.

Yes.. it has. And it uses "!balance" instead of "!cbalance" -> useless?

!balance is better in CA-land

So? It would be nice if it could be configured.. But that way? useless for most other mods?

Useless? ...if you say so.

Chojin, you dont need X for springie, run with -nogui

Masure wrote:

bibim wrote:However, I can implement a !specJoin command that would unlock the battle and autorelock it as soon as the player join the battle or after 2 seconds if he doesn't join for instance. That way people who join would know that they could only spec the battle...

And that would be great !

I implemented it. Finally I named it !unlockSpec. It only works when the battle is autolocked (not when it's locked manually).

bibim wrote:

Masure wrote:

bibim wrote:However, I can implement a !specJoin command that would unlock the battle and autorelock it as soon as the player join the battle or after 2 seconds if he doesn't join for instance. That way people who join would know that they could only spec the battle...

And that would be great !

I implemented it. Finally I named it !unlockSpec. It only works when the battle is autolocked (not when it's locked manually).

I like that, cool

Perhaps don't lock the game but auto-spec new players that join after the maximum player number is reached? That's the way i solved it on our Free-For-All host so it will never be locked but spec all that are "too much".
you could improve this like saying "i wan't max. 5 specs in this game" so the bot will lock the game as soon as there is the maximum playernumer and 5 specs in the game.

Seconded, great idea!

andre wrote:Perhaps don't lock the game but auto-spec new players that join after the maximum player number is reached? That's the way i solved it on our Free-For-All host so it will never be locked but spec all that are "too much".
you could improve this like saying "i wan't max. 5 specs in this game" so the bot will lock the game as soon as there is the maximum playernumer and 5 specs in the game.

Hum, unless I didn't understand what you meant, all this is already implemented in Spads:

bibim wrote:I had initially planned to deactivate autoLock by default on Spads autohosts and use autoSpecExtraPlayers instead. Which means that when there are already nbTeams * teamSize * nbPlayerById players in the battle lobby, the battle isn't locked but instead next users who join the battle are automatically spected. But once again, users expected to be able to autolock the battle and they thought the autohost was broken, so I reverted to Springie behaviour by default. The autoSpecExtraPlayers is still usefull and activated by default though, to prevent specs from unspecting when there is already the target number of players in the battle.

Anyway, actually I think it's not a good idea to keep a battle open when it's full from autohost's point of view (for instance there are 12 players in a 16 players max battle and autohost is configured for 6v6): players would keep joining thinking they can play whereas they would be forced to spec. It's a little like saying a battle is not ingame whereas it is, players feel cheated...

Then we need a LobbyServer, that supports a dynamic Value for Max-Players...

Hi,

I'm very interested in the autohost idea as I'd like to host some games for spring to gather statistics. Can I get a copy? :D