Lobby server evolutions

[bibim]

I really think following changes should be applied to Spring Lobby Server:
- let the battle founder decide if someone can join his battle or not, instead of having to auto-kick
- use unique IDs as explained here (this is transparent for users, they can still rename and create multiple accounts)

Does Aegis' server implement these features ? Is it planned to switch to this server soon ?

If not, I'm ok to write a patch to implement them in current lobby server if needed.

[LordMatt]

Not sure if Betalord is still maintaining the current server. Perhaps after some patches you could maintain it.

[aegis]

My server implements server-side bans for both battles and channels.

[aegis]

Of course, we DO NEED someone who steps in to maintain the archaic tas* and causes the replacement to not be used.

[smoth]

I like the idea of unique ids. I think it would be very nice.

[aegis]

Unique IDs are tracked and used with all of the server-side services (like banning users from battles)

[bibim]

Not sure if Betalord is still maintaining the current server. Perhaps after some patches you could maintain it.

Well, at the moment I just really miss these two functionalities. And unfortunately I can't garantee I will have time to do further patches for the lobby server (I think I will be busy with the autohost for some time when next Spring version is released :/ ). But if I have enough free time, why not

My server implements server-side bans for both battles and channels.

By server-side you mean that the host can send a list of banned users (banned IDs ? banned names ?) to the server, but he can't use filters based on rank, cpu speed, or name-regexp for instance ?

Of course, we DO NEED someone who steps in to maintain the archaic tas* and causes the replacement to not be used.

You know, I have nothing against your server... All I know is that you're working on a new lobby server, but I'm not aware at all about what is planned about this server, how much testing is still needed... That's why I asked (and also to have some admin opinions... If they don't think it worths it, obviously I won't spend time making a patch that won't be used...).

[aegis]

By server-side you mean that the host can send a list of banned users (banned IDs ? banned names ?) to the server, but he can't use filters based on rank, cpu speed, or name-regexp for instance ?

The system is abstracted enough... I can implement requested features.

I'm not aware at all about what is planned about this server, how much testing is still needed...

I can implement requested features. You can test anything you like (spring.clan-sy.com:8300) and give me your thoughts.

That's why I asked (and also to have some admin opinions... If they don't think it worths it, obviously I won't spend time making a patch that won't be used...).

[aegis]

...and if you know Python, feel free to contribute.

Code: Select all

git clone git://springlobby.info/git/aegis/uberserver.git

[AF]

Is there a version that doesn't require git? there are operating systems with zero support for git you know...

[aegis]

Is there a version that doesn't require git? there are operating systems with zero support for git you know...

Name one with a moderate userbase?

Yes, there is the link I use for deploying on servers with wget.

[lurker]

AF, you've not mentioned trying cygwin on the forum. Have you? The localized msys git installer is for nubs.

Sadly coLinux doesn't work on 64-bit yet.

[bibim]

By server-side you mean that the host can send a list of banned users (banned IDs ? banned names ?) to the server, but he can't use filters based on rank, cpu speed, or name-regexp for instance ?

The system is abstracted enough... I can implement requested features.

What I wanted to show here is that I think this system is not flexible enough. Each time a user wants to do something that is not implemented in your current ban system, or each time a new client attribute (or flag) is added in Lobby protocol, you will have to modify your ban system to be able to handle it. Whereas if you just had implemented the much simpler "ask-to-battle-founder" method, you wouldn't have had such impacts. And lobby clients wouldn't have been impacted neither as long as they don't want to use this new attribute for their ban system...
And what if someone wants to use white lists instead of ban lists (i.e: only people of the list can join) ? And what if someone wants to use dynamic ban lists (based on hour of the day) ? I think we could find lots of other things that would require server changes and maybe lobby protocol changes if they are implemented server-side, whereas they would only require lobby client evolutions with the "ask-to-founder" method...

I'm not aware at all about what is planned about this server, how much testing is still needed...

I can implement requested features. You can test anything you like (spring.clan-sy.com:8300) and give me your thoughts.

I know that, I have already performed some tests and pointed out some bugs concerning your server... What I meant is I don't know at all what admins have planned for your server (switch to it, do not switch to it ? How long to wait before switching ? ...).

[aegis]

By server-side you mean that the host can send a list of banned users (banned IDs ? banned names ?) to the server, but he can't use filters based on rank, cpu speed, or name-regexp for instance ?

The system is abstracted enough... I can implement requested features.

What I wanted to show here is that I think this system is not flexible enough. Each time a user wants to do something that is not implemented in your current ban system, or each time a new client attribute (or flag) is added in Lobby protocol, you will have to modify your ban system to be able to handle it. Whereas if you just had implemented the much simpler "ask-to-battle-founder" method, you wouldn't have had such impacts. And lobby clients wouldn't have been impacted neither as long as they don't want to use this new attribute for their ban system...
And what if someone wants to use white lists instead of ban lists (i.e: only people of the list can join) ? And what if someone wants to use dynamic ban lists (based on hour of the day) ? I think we could find lots of other things that would require server changes and maybe lobby protocol changes if they are implemented server-side, whereas they would only require lobby client evolutions with the "ask-to-founder" method...

Who says I haven't taken any of this into consideration and/or implemented it already?

My system is and will be as backwards compatible with itself and as efficient as possible. None of my additions break lobby clients who don't know they exist, save the predefined start positions feature.

You don't know enough about the system to be bashing it.

[Kloot]

Nobody really knows anything about it because development of
your "uber"server code and protocol hasn't been exactly visible
until now.

[AF]

Can we have a protocol definition of what changed, even if you haven't had time to write a paragraph to explain it yet. I get the feeling that in order to implement your additions one has to sit 24/7 in the #springlobby and hope they filter out uberserver talk from springlobby talk, otherwise its just assumed that you know already.

[aegis]

Nobody really knows anything about it because development of
your "uber"server code and protocol hasn't been exactly visible
until now.

The HEAD revision in git is actually intended to be compatible with TASServer.

[bibim]

You don't know enough about the system to be bashing it.

Sorry if you took it this way, but I'm not "bashing" your server at all. I just tried to explain why I think that asking the battle founder when someone wants to join a battle would be better than implementing server-side battle bans. Of course, I may be wrong, and we can discuss this detail without "bashing" anything.

Who says I haven't taken any of this into consideration and/or implemented it already?

That's exactly what I mean: for each of the few examples I gave you, you must have taken it into consideration for it to work. Whereas if you just asked the battle founder if such player can join or not, you wouldn't have anything else to do: any lobby client dev could implement his own advanced filtering functionalities without asking you to adapt your server. I don't see how you could have the same flexibility with the server-side ban system, however generic you make it...
Some other examples that I doubt are currently possible with your server (I'd be happy to be wrong):
- when 10 players are already in the battle, only players from clan "abc" can still join the battle
- only allow players who are in channel #foo to join the battle
- rank-limit only between 8h and midnight

Furthermore, current lobby clients already have their own filtering system for auto-kick. With the "ask-to-founder" method, all the devs have to do is basically replace the kick command by a "no" response. Whereas with the "generic" server-side ban system, they would have to implement a new command, convert all their filters into your generic filter names and commands syntax... And this syntax could become quite complex if you start allowing filter combinations, regexps, whitelists, timed bans etc...

However, as I said, it's just a detail, and it's obviously better than having no ban system at all. It sure could already avoid a lot of auto-kick floods...

[AF]

bibim, why are you chasing the lobby server when its the lobby client developers that are the biggest part of your feature request?

btw msys doesnt work on Vista 64bit, it generates hundreds of empty console windows and then clsoes them all until they've all closed when ran. Im not sure cygwin runs either.

[bibim]

bibim, why are you chasing the lobby server when its the lobby client developers that are the biggest part of your feature request?

I guess you're referring to the two changes I've listed in my first post ? Well I find it quite logic to ask about making the server side evolutions before asking for the corresponding client-side evolutions. Because if the server-side evolutions aren't made, there's no point making the client-side evolutions anyway.

I feel like I didn't understand the question