it can be easy fixed. Just make a default !bset waterdamage 0 as a default setting, so maps with water and without map options will not have this problem.

Same with maphardness map inverted etc all map option bsettings that affect specially water, terrain also elevation, i dunno if wind or metal its also affected, never tryed it out

how i switch?

actually I have included it in "testing" now, so you don't have to switch to test it

Just a small bugfix/feature request...

When there are 10+ players or so involved in a vote (e.g. kick, spec, etc) SPADS often counts a vote which might end 5-0 as undecided, and then it all has to be redone and lots of waiting ensues.

I don't know what the current formulas are for whether a vote passes/fails, but I think any vote which gets more than, say, a four person majority should automatically pass, regardless of the total number of votes.

Could you improve your voting system ?

notAlobby parses messages from autohost and shows/updates/hides the Voting UI.
You can download notAlobby 3.0 Beta 2 for testing

Could you make it like Springie autohosts ?

And one more thing, if the user starts the Poll, then don't set YES for that player, cause we also show how players have voted.

Sure I could try, what exactly do you have in mind?

Tbh I don't really know Springie voting system, can you be more specific?

I don't understand. If it's just to show who has voted and what, can't you just show that the player who started the vote voted yes? Also, votes can be performed in private messages to the autohost, so anyway you can't show them in this case.

However, I'm all for improving current vote system, and add some dedicated interface to SPADS (through special private messages for instance) which would provide all the info you need in a much easier way than parsing human-targetted messages.

Hardcode Zangeeph's permissions straight into the core of SPADS.

I mean, make it easier to understand by lobbies.

if there is a Poll then:
every message from Autohost should contains the word "Poll:" (or somethnig else)
after the word "Poll:" we have a title of poll: "Force start the game ?"
then we have a statistic "[!y=0/5, !n=0/5]" or "[0/5|0/5]" or something similar.
if the Poll ended successfully instead of statistic we have: "[END:SUCCESS]" otherwise: "[END:FAILED]"

all that messages we can ignore (not to show in the chat)

of course, the ideal case is to implement it in server-lobby protocol. But no one wants to do that I think.

Oh, then it's not really improving vote system, just formatting output in a more understandable way for lobby clients.

Well currently, every time someone starts a vote, SPADS prints a message starting with "<userName> called a vote ...". And every time someone votes, SPADS reports vote state with a message starting with "Vote in progress: ...". If I understand you correctly, you would like me to replace this by "Poll: " because it's easier for you to parse?

In SPADS every command can be voted. Currently SPADS simply prints the command that is being voted in its vote reports. Honestly I won't spend time giving titles to every SPADS command just for vote messages.

SPADS already prints this in following format:
"[y=<currentNumberOfYesVote>/<requiredYesVotes1>(<requiredYesVotes2), n=<currentNumberOfNoVote>/<requiredNoVotes1>(<requiredNoVotes2)]"
- requiredVotes1 is the number of required votes considering all "away-voters" (refer to voteMode SPADS preference) will vote blank.
- requiredVotes2 is the number of required votes considering all "away-voters" will actually vote

Currently SPADS prints 'Vote for command "<command>" failed.' or 'Vote for command "<command>" passed.'.
To be honest I don't think starting to put some tags in autohost outputs in the battleroom is the correct way to implement things. Battleroom messages are supposed to be human-targeted, and they can even change if we decide to improve the vote system... For example, tasclient has already implemented an autohost interface which handles these messages, so if I change them it won't work anymore I guess...

I had specified a way to really improve vote automation in lobbies just by using some unused bits of client battle status, but it was discarded since a new "SAYDATA" command was supposed to be implemented in lobby server and would have allowed the same thing that I had in mind. However, imo even using normal private messages with specific prefix to indicate it's data exchanged between autohost and lobby client would be better than starting to put tags in autohost human outputs, and it doesn't require any server lobby changes.

Thank you "bibim" for detailed answer. Vote UI for SPADS is done.

You're welcome, and thanks for implementing this interface in your client.

Fix issue ?


I mean, Where is Failed ?

Because of that Vote UI is open and doesn't work properly for SPADS

There are 2 special cases where votes are automatically cancelled by SPADS:

1) When the game is launched before the end of the vote: in this case SPADS prints: (this is because 99% of the votes called before a game start aren't useful once the game has started)

2) When the vote is a "forceStart" vote and the game actually starts before the end of the vote (so there is no need to "forceStart" anyway, as seen in your example). Depending on the game start reason, SPADS can print 3 different messages in this case:

You can treat these "auto-cancelled" polls as failed polls.

What a mess Thanks, Done
Too complex

I don't think it's too complex. The messages are easily understandable by players, which is the target of these messages, not programs
And it's useful: no need to have a forceStart poll with messages polluting console whereas the game has already started for example.

You made a good work.
But your work for voting is overabundant.
From voting we need What, How many votes and the Result ( Accepted, Declined )

Thanks for your opinion.

New major SPADS version (0.10.*) should now be available in "testing" release. As I didn't release major SPADS version since quite a long time now (more than 2 years I think), here is a small explanation:
Major version means it requires updating config files manually (mainly to add new settings), so SPADS doesn't update automatically. Instead, it logs a message explaining how to proceed and point you to this manual update documentation, so that you can do it when you have some time.

SPADS 0.10 comes with new functionnalities, for example:
- mid-game join as new player
- full spring-headless compatibility for automatic server-side AI bots management
- easy integration of external programs for demo files management (*)
- balance algorithm more customizable for TeamFFA
- team statistics management (end-game awards...)

Detailed changelog for each SPADS component is available here.

(*) Thanks to Dansan who developped a replay upload script in Python, it is now very easy to upload replays automatically from SPADS. Here is the short version of his "howto":

If you want more information about how to use this script, full documentation is available here. If you still have questions concerning this script or the Spring replays site, I guess you can contact Dansan.

I encourage to use this script on your SPADS autohosts for automatic replay upload so that we provide content to the Spring replays site.

Hi,

Can I get some svn/git urls to your project?
I am really interested to play a little bit with the code and maybe implement some new features. But I can't find any repository.
Do you use any svn|git|csv|hg at all?

Thanks a lot
p.s. great work!