Fixes for Assholes

[Frans]

in spring, there has been lately a bunch of assholes, people who just don't know when to stop. i'm purposing the following changes be made, to lessen the effect they have.

firstly, joinspaming. i've just been pissed of by one, who really went and overdid this.

whenever a user is auto kicked, because of a specification not met, such a rank, or they were banned, or autospeckicking is on, and a game is full, some players don't just get it into their peanut shells for heads, that they'll keep on getting kicked. some of them are real smart too.
in auto host, they might know how to unlock, and lock a game, to cause a even greater annoyance.

my suggestion, stop joinspams, by creating a timelimit to rejoin a game. this time of not being able to rejoin would keep on increasing, for each kick a user recieves. so, if their banned from a game, and they get kicked a few times, they'll find themselves at first have to wait a few seconds to rejoin, to a full minute, or even 5 - 10 minutes.

also, ingame, some players would be real assholes, by waiting for someone to press ready, then place their marker next to theirs, and pressing ready. the end result being that two players start next to each other, and blowing each other up good, with their dguns.

i suggest that a player can un-ready, and also that when a player places their marker, a circle could appear, with stuff such as radius based on what the host has defined for a setting, and within that circle, no other players may place their markers in it. that way, players have to travel a bit, to dgun, and that is enough time, to run away, and to tell the host to kick.

also, this suggestion is for the guy(s) makeing the autohosts.
i'd like to see that when commands are being pmed to the autohost, that the person who sent the command will have their name stated.
for eaxmple, lets say, i did a ring, and the autohost rings player a, and b. the autohost would ring alright, but would display " * Autohost ringing a, b, on behalf of Fransc".
this would stop players from spamming an autohost, and then blaming it on someone else.

also, seeing players get privileges revoked temporally, or permanently for heavily spamming an autohost's commands would also be nice.

there were a few more ideas that i wrote down somewhere, but i lost them, and the others i remember, i realized isn't needed, or is already suggested, or done.

But, by implanting these ideas, and/or other similar measures, can improve how a game is played, and would lead to less frustration.

[LordMatt]

I think the join throttling, unready ingame, and seeing the PMed commands of the autohost are good ideas.

[bibim]

I'm not sure the join throttling functionnality is the good way to do it. To my mind the problem resides in the way that the lobby protocol handles the join operation: correct me if I'm wrong, but each time a client asks to join a battle, after some basic checks the lobby server informs all clients that the client joined the battle, without even asking the battle host if the client is allowed to join the battle. Consequently, currently there is no way to really ban a client from a battle when you're hosting, all you can do is auto-kick him once he joined. So I think that a lobby protocol fix would be much better to avoid join spam.
The only workaround that I found when autohosting was to implement a special mode in which a random password would be set for the battle. And a command ("!pass" for example) would have to be sent in PM to the AutoHost in order to obtain the password. Of course the password would only be given if you fit the configured autohost filters (banlist, minimum rank ...).

Concerning the unready ingame functionnality, it could be usefull indeed, because sometimes honest players don't see other's start points. However, when players are acting like assholes as you say, I just think they deserve a ban. We can't prevent all possible ways to ruin games...

[REVENGE]

Thought we were going to fix those assholes [permabans], but I'm dissapointed.

[Peet]

AFAIK the next lobby server in development will support a proper battle/channel permission system including bans; for now there is not really any way to deal with joinspamming other than contacting a moderator.

[FLOZi]

Buttplugs!

[Licho]

I can only implement visible PM, but other things are not possible without lobby protocol changes. Host cannot prevent player from joining...

[Jonanin]

I have been thinking a lot about a new protocol, and maybe even start to roll out specifications for one (to be used with Aegis' uberserver). I would like it to be based on JSON. This is good for a lot of reasons, but I'm not going to derail the thread any more than I already have.

[KDR_11k]

Forcing distances for start positions seems like a good idea to me, even if it's just to prevent clogging the exit of other people's bases when static coms are used.

[Google_Frog]

I don't like the idea of forcing start position distances because some rush strategies involve 2 comms assisting a factory from the start.

[rattle]

Then make it a mod option.

[bibim]

AFAIK the next lobby server in development will support a proper battle/channel permission system including bans; for now there is not really any way to deal with joinspamming other than contacting a moderator.

How will the battle permission system will be implemented ? I think a banlist stored at lobby server level for each battle isn't enough. The lobby server should really ask the battle host before allowing a client to join a battle.

[aegis]

i can add mechanisms for both invite-only battles and request to join -> host accepts/denies

[ZellSF]

AFAIK the next lobby server in development will support a proper battle/channel permission system including bans; for now there is not really any way to deal with joinspamming other than contacting a moderator.

Is that lobby server 0.76b2 or 0.77?

[KDR_11k]

The lobby server does not require the Spring Engine to be changed in any way so the Spring version isn't really meaningful.

[zwARREN69]

I like the fixes that you've proposed.