Spring RTS Engine

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?

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

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...

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

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?

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

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...

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

Nope.

Host port's already fixed. I guess it's possible for Spring to be unable to grab the desired port, but wouldn't it exit and people would know it's possible to error? I don't think a silent connection failure can happen from hole punching itself, but I don't know all the details.

lurker wrote:Host port's already fixed. I guess it's possible for Spring to be unable to grab the desired port, but wouldn't it exit and people would know it's possible to error? I don't think a silent connection failure can happen from hole punching itself, but I don't know all the details.

The problem isn't really binding locally a port for Spring, but successfully opening additionnal NAT'ed connections using the same NAT'ed port as the one with third party server but with different endpoint, which is the principle of hole punching. It seems some routers don't support this. And in this case, the Spring server (respectively client) would try to send UDP packets to client (respectively server) NAT'ed ports that wouldn't accept connections from this host. So at client side it could fail by due to connection refused (if the host NAT doesn't support hole punching) or timeout (if the client NAT doesn't support hole punching), which is maybe what you meant by silent connection failure ?

lurker wrote:Host port's already fixed. I guess it's possible for Spring to be unable to grab the desired port, but wouldn't it exit and people would know it's possible to error? I don't think a silent connection failure can happen from hole punching itself, but I don't know all the details.

I'm usually the only one to fail to connect in such cases so the NAT traversal clearly works for the majority. (Also I've never fail to connect to hosts not using NAT who properly forwarded ports.)

Could just be some other incompatibility somewhere, no clue, but it's a fact that there is some small group of people who can host fine for the majority, but not for me, and it's also a fact I can connect to the majority of hosts fine.

(IIRC I've yet to be able to connect to Ivory King, for example, while he can host fine for everyone else, AFAIK.)