* Vote System: Approval Voting (#73749)
## About The Pull Request
Approval Voting is a system in which voters can select as many maps as
they want, instead of selecting only one. Final tallies show how many
votes each map received, and the winner is the map with the most
support.
## Changes since https://github.com/tgstation/tgstation/pull/73413
- Custom votes can now be started using either system
- Icon during AV votes indicating your selections
- Map population filter counts active players and participating ghosts
https://user-images.githubusercontent.com/83487515/222580901-61506cc3-dc42-4435-9775-1e6291a3f734.mp4
## Why It's Good For The Game
First-past-the-post (our current voting system) has flaws such as
creating a bunch of wasted votes, in that a large number of selections
ultimately have no impact and for example, a map can win a 3 way race
11/10/10, even though 2/3 of the votes were not for that map. This leads
to people having to vote strategically, and perhaps not what their true
choice is.
Approval Voting solves this by instead allowing the player to select all
the maps they would like to play, so they can vote for their true
preferred choice, as well as alternates.
For example, a player that wants Metastation, is okay with Icebox, and
doesn't want Delta may feel pressured to vote Icebox if it's in a 2 way
race with Delta.
AV lets them vote for Meta, and Icebox or as many others as they want as
their alternates and creates a more fair outcome of a map vote.
Map population filter removing AFK/lobby screen dwellers gives a better
number of active players so as to not trip the map filter's population
cap earlier than it should.
tl;dr: Less of this
## Changelog
🆑 LT3
rscadd: Added new multi-vote system
balance: Map votes are now calculated using multi-vote instead of the
old single-vote system
admin: Admins can now use either multi-vote or single-vote for custom
votes
code: Map choice filtering uses active player count, not all connected
clients
/🆑
* Vote System: Approval Voting
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* End Of Creating Map Votes with One/Zero Options. (#70340)
Makes it so you can't call a map vote when there is less than two maps to choose from
Co-authored-by: VexingRaven <msgerbs@ users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* End Of Creating Map Votes with One/Zero Options.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: VexingRaven <msgerbs@ users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Verbose Vote Initiation Feedback Tooltippery (#69763)
* Verbose Vote Initiation Feedback Tooltippery
Hey there,
So basically, the old implementation had it such that when a vote was disabled and you tried to trigger it, you could get a very nice message in your chat explaining why you could not trigger that vote in that moment. HOWEVER, there's a current fatal flaw in this logic:
You can't ever get that to_chat reason as to _why_ this vote is disabled since you can't click the button. I don't know if this ever worked, which is sad, because we had a lot of these nice messages that one would never see. So, let's leverage the power of TGUI and add messages.
The messages are applied per-datum singleton, and are a generic explanation of what the vote does when there is no specific reason assigned to it when the can_be_initiated() proc runs. If it can not be initiated, we change the message to reflect exactly why the player can not initiate the vote. It ends up looking something like this:
In order for this to work well for the restart vote and to lessen the amount of copy-pasting I might have to do, I created a new proc that checks to see if a valid admin is online, and uses that for both updating the message and restarting the server if the vote clears.
* fixes messages not resetting
* removes misleading section
the admin can always restart the server if they wish
* Verbose Vote Initiation Feedback Tooltippery
Co-authored-by: san7890 <the@san7890.com>
* Rocking The Boat, er, Map Vote (#69561)
* Rocking The Boat, er, Map Vote
Hey there,
A while ago, I spooke (typo intentional) to some other people. One frustration I heard was the fact that people would sometimes sneak through map votes during the very start of a shift, during a high-paced portion, or just as a meme. People in OOC would then flood the vote, putting in any given station. However, if a vote happens 10 minutes in- and the round goes for 70 minutes and not many of the original players are around, then it's not particularly fair to those who have to play next shift on a map they bemoan.
So, we can rock the vote! If a player isn't particularly chuffed with the hand they are given, they can poll the players to see if they want to change the map as well. If rocking the vote goes through, huzzah, you get the ability to vote for the map again. If it doesn't go through: tough luck. You can rock the vote one time per shift by default, and server operators can change the amount of times you can call to rock the map vote at their discretion. Calling to rock the vote either successfully or non-successfully counts as a "call", and when that limit is exceeded: no more calls.
Does this mean that we will only rotate between two maps because pissants will keep rocking the vote until they get what they like? Maybe? I still see people bemoan getting Tram or shit the bed over IceBox, but I think enough people get sick of bread-on-butter to take the server where it need to go. If operators don't really like seeing only two maps play, they can always adjust the config to ensure it doesn't happen.
* makes the grammar grammar
it would be "Rock the Vote vote" otherwise
* Rocking The Boat, er, Map Vote
Co-authored-by: san7890 <the@san7890.com>
* Fixes strange runtime with restart votes (#67080)
So, I refactored votes a little bit ago.
This line was present in the result process for restart votes.
for(var/client/C in GLOB.admins + GLOB.deadmins)
if(!C.is_afk() && check_rights_for(C, R_SERVER))
active_admins = TRUE
break
So, I converted it to this.
for(var/client/online_admin as anything in GLOB.admins | GLOB.deadmins)
if(online_admin.is_afk() || !check_rights_for(online_admin, R_SERVER))
continue
Seems fine, right?
Unfortunately, no.
GLOB.deadmins is a global list of deadminned ckeys. Not deadminned clients.
So, the original loop iterated over a combined list of clients AND ckeys, but ONLY typechecked for clients.
Why were we adding in ckeys in the first place, if it didn't even check them?
No idea. But it seems like, since no one noticed restart votes weren't checking for deadminned admins in the first place, there isn't a reason to continue to consider them. Admins can re-admin to cancel restart votes or address the server's concerns if they're online, I suppose.
* Fixes strange runtime with restart votes
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Fixes some minor formatting issues with vote text (#66913)
* Fixes some minor formatting issues with vote
* Wrong thing.
* Actually I think this is supposed to be here
* Fixes some minor formatting issues with vote text
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
