Kick-vote control about ballistica HOT 8 OPEN

Ok I've added an admin list and the ability to disable kick votes in the latest commit: e0c827c

just do a make prefab-server-debug-build and you should see some new commented out options in the config_template.yaml in the build directory: 'enable_default_kick_voting' and 'admins'. There's more info available in the comments there.

Currently admins cannot be kicked and any kick vote they start passes immediately. We can give them more powers as we think of things...

Let me know if you have any thoughts/feedback.

from ballistica.

I've been thinking a lot about this too since it is indeed a tricky problem (as you explain above). We can't just flip everything over to asset-packages in one update since that would leave lots of servers and clients unable to communicate. It generally takes a long time for updates to trickle down to everyone so I think its good to plan for a graceful transition. Also there are still lots of people with modded 1.4 servers and I'd like to support connections to those for as long as possible.

My plan is to do something similar to your minimum_client_version idea: basically having 2 modes the game can operate in; 'scene-v1' and 'scene-v2'.

• scene-v1 is the game as it exists today; with no asset-packages. Assets are specified with simple paths such as 'textures/bombStickyColor', etc. Even though the game's scripts will be modified to use asset-packages instead of the old flat paths, under the hood they will simply be mapped to those old paths with the old loading mechanisms. So in a Python script there might be some sort of internal_assets@1' package containing a bomb_sticky_color texture, but under the hood it will still be doing the same old 'textures/bombStickyColor' load. This means scene-v1 mode can interact with old clients and servers because everything is still the old-school paths at the low level. However this also means that it will be limited to a hard-coded set of 'fake' asset-packages corresponding to old assets; no fancy features such as dynamic downloads will be available.
• scene-v2 will be the real deal, supporting actual dynamic downloadable asset-packages. So all of the 'internal' asset-package paths from scene-v1 will work, but user-generated cloud based ones will too. Scene-v2 will not be able to communicate with older versions of the game at all (but that's why scene-v1 will still be around). Since this will be a total break in compatibility, I also plan to take the opportunity to include several other substantial changes I've been holding off on such as an overhauled network protocol.

So the idea is that everything will run in scene-v1 by default for a while, so everything will remain backwards compatible, but the same Python code should also function in scene-v2 mode. Scene-v2 will only kick in when connecting to a scene-v2 server, or when explicitly enabling some hosting config setting. This means scene-v2 will probably be changing rapidly with lots of breaks in compatibility for a while as it is remains 'experimental', but eventually it will be distributed enough and stable enough that with some release of the game we can flip it over to be the default and it should cause minimal disruption.

from ballistica.

I go yes!

from ballistica.

I also have some ideas about Kick-vote. Sometimes, when I play on my own server, I will be kicked out of the room maliciously by other players. Sometimes this kind of thing is really uncomfortable. After all, I run the party, but I get nothing and sometimes get kicked out of the party. Fortunately, some commands can be used in future versions, such as mgr.clientlist(), mgr.kick(id), mgr.restart(), etc. Although these features are good, they are not so convenient for someone who usually uses a mobile phone to play this game. To solve this problem, I have the following two suggestions.

1. "Owner ID" adding an additional piece of configuration information to the server version configuration file. This configuration item can be filled in with the BS ID of the server owner to protect the server owner from being kicked out.
2. "Allow voting" adding a configuration item to the server configuration file. Users can configure whether to enable the voting function, which is enabled by default. In this way, if a server owner wants to disable this option, it can be changed.

Hopefully these suggestions will be of some help to you.

from ballistica.

These all sound like good ideas. Right now there is a smattering of individual hooks and functions such as filter_chat_message() but my hope is to combine everything into a single clean 'ClientController' or possibly 'AppController' class that can be overridden by modders. This would have hooks for all client related stuff such as 'on_client_join_request()', 'on_client_join()', 'on_chat_message()', etc. And the default kick logic will be implemented as Python within that class and overridable. I hope to get this added as part of 1.7 but perhaps I can fit it in sooner...

I also think the "Owner ID" and "Allow voting" sound like good things to add to the standard server config. For "Owner ID" I might just call it "Admin IDs" and make it a list. For now the only property of an admin will be that they are un-kickable but we can expand what that means in the future (and again it'll be overridable once the ClientController class happens). I'll try to get to these two additions today as they should be quick.

Let me know if you have any thoughts on any of this, or if there are other things related to this stuff that would be nice to have/etc.

from ballistica.

Mentioned issue moved here; suggested a logging for kick-votes.

from ballistica.

Hey, I wanted to suggest a feature too, but for the upcoming 1.7 release. I thought this would be the best for that suggestion as it will only be useful after the 1.7 (dependency system) release.

I suggest adding a minimum_client_version config setting for the server headless builds. The server could set the minimum version the client build should be to be able to connect to it, the BombSquad GUI client when trying to connect to the server will receive this value and reject to connect if it does not meet the requirement.
Take the following usage example:
Suppose when V1.7 is released with the dependency system, and many servers update to it. Now some of them might use the asset packages while some may not. And just like servers, there are clients' devices some of which are updated and some which are not on 1.7.
The older client builds won't be able to play correctly or even create some issues with the v1.7 server which uses asset packages as the older client don't have support for it so the older clients can reject the connection to all newer servers to fix this problem but it might as well then reject the connection to servers that are using latest builds but not using asset packages.
In that case, the minimum_client_version could become useful as the servers which use asset packages can have the client's device know that they especially require the updated build while the servers that don't use them will do just fine with older clients.

This might even be used when new similar changes are released in the future versions that may or may not be used but will require updated clients to connect to the server when used.

I would really like to know how other modders think of this suggestion.

from ballistica.

I see that is quite a good plan, the existing connections won't be disrupted and at the same time, we could try the new scene-v2 mode separately.
In my opinion, the breaking changes in scene-v2 should not be a big concern for now for most server owners as everything made till now and more will be supported with v1, and we will have v2 with every update making it better for the new experience and testing.

from ballistica.