Mod options are considered by SPADS as battle settings (you can check this by trying "!list bSettings all" command), so they can be defined in battlePresets.conf in the same way as other settings.

For example, you can add a line "mo_coop:1" in your default battle preset so that coop mode will be enabled for mods which use this modoption. You could also use the "mo_coop:1|0" line instead, so that coop mode is enabled by default but can still be disabled by players...

See also allowModOptionsValues preset setting and resetmodoptions battle setting.

Could you please do something about this bot auto-accepting votes which nobody votes on?

At least 5 times I've been in a game where some random person joins and starts a !stop vote whilst everybody else is ingame, then nobody notices the vote and suddenly the game stops mid way because there's nobody who voted thus the vote is accepted.

It's ruined so many good games...

As said previously in this thread, the entire SPADS vote system is configurable by autohost admins AND users. In SPADS 0.9 I even added a minVoteParticipation setting to set the minimum percent of manual votes for a vote to be taken into account by SPADS (default: 33%).
I will switch standard SPADS stable release from 0.8 to 0.9 soon, so your problem shouldn't happen anymore with up to date autohosts... Actually, "testing" and "stable" SPADS releases should be the same soon, since I didn't code anything for SPADS for a long time...

for a two player battle, and spec are not allowed to vote, if one player is afk, the other one can't even vote spec the afk one

If he is flagged as "afk" in lobby, you should be able to use !specafk.
If spectators can't vote to force spec someone, then you can call a vote for kick instead. And if spectators can't vote for kick, then I guess you can complain to the autohost owner about vote rights configuration.

A global SPADS crash occured this morning, due to inconsistent commands sent by new lobby server (uberserver).

Most of SPADS code is server-bug proof to a certain extent, that's why since lobby server migration you can see a lot of non-blocking errors in logs such as (non exhaustive list):These errors are due to inconsistent commands sent by lobby server, and these bugs should be fixed in a near future I guess...

SPADS should operate normally anyway, however I found a part of SPADS code which wasn't totally server-bug proof and which is likely to be the cause of today's crash. This should be fixed in SPADS 0.9.2a, which has just been deployed on all SPADS releases.

Reminder:

Here is what you can do to upgade your autohost to new Spring version:

On Linux:
- recompile Spring and install it (actually you just need to compile unitsync and spring-dedicated, and generate "gamedata" (Spring base files)).
- update the paths in spads.conf for new Spring version if needed
- update your SPADS installer script so that it contains the latest changes which could be required to recompile the unitsync interface from latest Spring sources: "./update.pl <spadsRelease> -a"
- launch the PerlUnitSync module generation: "./spadsInstaller.pl -g"

On Windows:
- update the "springDataDir" setting in spads.conf if you installed the new Spring version in a different place
- restart SPADS



NOTE:
In this Spring release, the unitsync library no longer returns the ".smf" extension for map files. Consequently you have to remove these extensions from your map names in SPADS configuration (check your "map" preset setting in spads.conf and your map list declarations in mapLists.conf).

Thanks for all the work and fixes, bibim

You're welcome, unfortunately there are still some severe lobby server bugs which prevent using SPADS normally. For example when someone is kicked from a battle lobby, the battle becomes totally non functionnal, messages from the host are no longer transmitted in battle lobby, some players can't see and/or join the battle anymore, some clients host several battles at the same time etc.

Can I ask (and I think I asked before) will setting your autohost onto a higher priority in taskmanager make it lag any less when people play? Also, any other tips on how to reduce lag? and dont just say 'get better netz pl0x'. =D

Hey Bibim,

In the Official Server (lobby) I do not see any mod option changes reflected in the lobby client. But, in the old lobby client it works fine. I guess this could be to do with new beta lobby server.

Using latest stable spads.
Mod: BA Chicken Defense V2.11

When people play, they are connected to Spring dedicated server, which is independant from SPADS. I guess it will inherit SPADS priority, but I doubt it would reduce lag as it's likely due to your internet connection.

As seen with romulous in lobby, this is due to SPADS not limiting SETSCRIPTTAGS commands sizes, and new lobby server limiting commands length to 1024. It seems BA Chicken Defense V2.11 mod has enough modoptions to generate SETSCRIPTTAGS commands longer than 1024 characters. I will fix SPADS soon to prevent this to happen...

This also happens in CA Chickens 1.9 which I just tested. Log extract at: http://pastebin.com/Ly5SR9tM

It was corrected yesterday in testing and unstable. I just reported it in stable now.

I can confirm the mod options issue is fixed in stable. But there's another issue. Chicken bots don't spawn into the game. I've tried BA and CA chickens (latest versions).

infolog.txt from my local spring dir:
[ 0] ERROR: Unknown skirmish AI specified:
[ 0] Warning: No Chicken team available, add a Chicken bot
[ 0] (Assigning Chicken Team to Gaia - AI: Custom)
[ 29] Skirmish AI "Bot1", which controlled team 2 is now dead
[ 91] Game has ended

Chicken bots work with a relay host.

Dunno if it was already mentioned, but just for the records and cause it took me some time to find out:
The latest version of spads does not seem to support file extensions to map names any longer. So if you have in your config something like


you got to change it to


Otherwise you will get error messages like "Unable to get map hashes". No idea why I had the file extensions in the first place.

that is not spads, but engine related (since 0.82).
archives should be addressed by their names, not their archive file names. this is important for dependency checking and format independence (eg, if there is a features pack, not every map has to include it, but can depend on it -> smaller map archive and overall disc usage on the client, with many maps). it also allows BA.sdz to be compatible with BA in the pool format (rapid).
The only bad thing is, that the internal name is not always/necessarily the smf archive name with the .smf postfix stripped (especially true for mods, eg: "BA715.sdz" -> "BA" (shortName) or "Balanced Annihilation 7.15" (name).

For the next release, could we get an option to prevent users with certain levels of rights from being kicked from the battle lobby? If a user with the certain rights is away or needs to be removed from play ingame for whatever reason, that should be fine with a vote, but in the battle window it should change to !spec vote instead of a kick.

Really needs to be somewhere to display the !chrank of players, and it needs to be public. I think some admins make themselves lower ranks