Hmmm... And what is the difference in the result if you click "don't care" because you don't like being bugged and not voting because you... hmmm... don't care?Joe-Schmoe wrote:If you're forced to vote, then people might just hit "don't care" right away and keep playing, which would eliminate the purpose.
Why not both? BTW: I didn't think non-voters were counted as No-votes. Hmmmm... Not good. So I support your idea. "don't care" (i.e. non-voters at the moment) usually means "I go with the majority".L4m3r wrote:Another idea would be to just not count people who don't vote, and instead take a tally only from those who actually voted.
Well, it may just become an automatic reflex to hit "don't care", just like one automatically hits "i" or whatever they have mapped to respawn.Hmmm... And what is the difference in the result if you click "don't care" because you don't like being bugged and not voting because you... hmmm... don't care?
Heh, it definitely happens... usually when there's a really bad language issue, or very high lag, or blatant cheating. It is difficult to get everyone's attention sometimes, though.Joe-Schmoe wrote:I don't believe I've ever seen a successful poll ban/kick.
That would help a lot. At least I would vote more often if they always knew the reason for the poll.Mac Rep wrote: A reason for the poll should be mandatory too:
/poll ban "Mac Rep" for "Being a bugger"
Or something like that so that the question one is asked can show the reason for the poll.
Polls to set variables, reset flags, kick, and ban are currently implemented. The problem with arbitrary command execution is that some things just aren't meant to be decided by popular vote. For instance, what about a poll to set yourself to the LOCAL.ADMIN group? Or a poll to execute a server shutdown? Or a poll to ban a large range of IPs? Clearly server owners don't want this kind of capability in the hands of the players.F687/s wrote:A good plug-in would be to make a mechanism for executing arbitrary commands by poll. For example:
/poll set _shotsKeepVerticalVelocity 1
would start a poll to execute the command if the majority complied. A variation would be
/poll "Should we stop CTF?"
Slash commands can be overriden in the 2.1 development version. The poll and voting framework is already almost 100% server-side, unless I'm mistaken. But why would you need to change the commands at all? You can add options, perhaps (for instance, "/poll changemap <mapname>" for a mapchange plugin), but this is about as straightforward as you can get.F687/s wrote:The only problem would be integrating it so that you could have the old functionality without having users learn a new set of slash commands. Can you override slash commands in BZFS?
In addition, voting is mainly server-side, and shouldn't be integrated into the client.
Yes, being able to add options to /poll was the primary reason I suggested that to Jeff in the first place. 2.1 will make that very easy.Constitution wrote:Slash commands can be overriden in the 2.1 development version. The poll and voting framework is already almost 100% server-side, unless I'm mistaken. But why would you need to change the commands at all? You can add options, perhaps (for instance, "/poll changemap <mapname>" for a mapchange plugin), but this is about as straightforward as you can get.
Even better would be a custom poll option framework, something like the custom slash command handler we have now. Poll options could be registered with a list of options and a pointer to a handler called when the poll is successful, etc.L4m3r wrote:Yes, being able to add options to /poll was the primary reason I suggested that to Jeff in the first place. 2.1 will make that very easy.
Not really. IMO being able to simply override commands would be much more versatile, and would not require any "special" stuff in the API. It may be just a little more complex for this situation, but on the whole it gives more capabilities with less work.Constitution wrote:Even better would be a custom poll option framework, something like the custom slash command handler we have now. Poll options could be registered with a list of options and a pointer to a handler called when the poll is successful, etc.
Indeed - I didn't mean that poll hooks in the API should replace overriding slash commands... just that creating a framework for custom poll options would probably be a better idea than creating an entire poll manager from scratch (with the plugin) when implementing it. It would also allow for different kind of custom polls (something not possible when one plugin totally overrides the /poll and /vote commands). For instance, you could have a mapchange poll option, and a poll option to vote for the "admin of the month", and a poll to vote whether players like the map, etc.L4m3r wrote:Not really. IMO being able to simply override commands would be much more versatile, and would not require any "special" stuff in the API. It may be just a little more complex for this situation, but on the whole it gives more capabilities with less work.
In fact, I think command handling in 2.1 would make everything discussed in this thread possible with a plug-in.
We could add some utility functions to make poll handling easier, but I don't think a new handler would be necessary.Constitution wrote:Indeed - I didn't mean that poll hooks in the API should replace overriding slash commands... just that creating a framework for custom poll options would probably be a better idea than creating an entire poll manager from scratch (with the plugin) when implementing it. It would also allow for different kind of custom polls (something not possible when one plugin totally overrides the /poll and /vote commands). For instance, you could have a mapchange poll option, and a poll option to vote for the "admin of the month", and a poll to vote whether players like the map, etc.
It's also just a lot less work in general, IMHO. No need to create or adapt a huge poll manager framework into a plugin that's otherwise simple.
Yes, just as map files are restricted in their options, so should polls. One way to do this would be a magic "poll" group, or letting only admins set those kind of polls, or using some whiz-bang object coded in Python.Constitution wrote:Polls to set variables, reset flags, kick, and ban are currently implemented. The problem with arbitrary command execution is that some things just aren't meant to be decided by popular vote. For instance, what about a poll to set yourself to the LOCAL.ADMIN group? Or a poll to execute a server shutdown? Or a poll to ban a large range of IPs? Clearly server owners don't want this kind of capability in the hands of the players.
Kind of like the Apache way of handling plug-ins, where each one along the chain gets to handle the request, and the chain stops when one plug-in says it is finished. I remember implementing something like this in another app, where the program passed the information to each plug-in, and they returned whether they WILL handle the request (at which point the program lets it), whether it WON'T handle the request (excluding it), or whether it CAN handle the request (at which point the server makes a decision). Of course, letting everyone handle the slash command in their own way will result in sheer chaos, causing plug-ins to be named "AAAAAVoteController" in order to be higher up in the chain, and whatever.L4m3r wrote:Also, overriding commands would not be an all-or-nothing deal. iirc the handler will have a "handled" flag so that commands can be handled normally. This would also allow multiple plug-ins to handle the same command, one after another, without stepping on each other's toes.
As far as I know, voting isn't an essential part of BZFlag; it is just there to kick people without them knowing why (um...). Most of the servers are run under a sort of dictatorship, where vote is a justified /kick.Constitution wrote:Even better would be a custom poll option framework, something like the custom slash command handler we have now. Poll options could be registered with a list of options and a pointer to a handler called when the poll is successful, etc.
This seems to be the most logical suggestion so far, but all of them are good. We need a better voting system.ts wrote:My opinion is that players hardly know how to vote. We should bind "/vote yes" and "/vote no" to two different keys and put those keys in the poll message. That way people would not have to type that much and therefore it would be easier to get votes, especially from newbies.
