## About The Pull Request
Changes map votes to be based on a persistent tally count.
Tallies for maps are cached between rounds and are added to by map
votes.
When a map is chosen, and it wasn't the only valid one, the tallies for
said chosen map will be reset.
Refactors map vote handling and moves it from SSmapping to SSmap_vote.
Rock the Vote has been removed as a result of this refactor.
## Why It's Good For The Game
Makes it more likely that all maps will be played over the course of a
server instead of always being truly random.
Removes some clutter off of SSmapping.
🆑
refactor: Map Votes are now carried over between rounds. When a map vote
is actually a contest, the winning map will have its votes reset.
/🆑
## About The Pull Request
Closes#83020
This proc, called *every single ui_data tick*, was mutating the vote's
list of choices. Grahhh impure procs grahhh
f112369547/code/datums/votes/map_vote.dm (L57-L60)
Weirdly, I have no idea how this *ever* worked, even prior to my PR,
because I didn't touch this or any consuming code. It was called in the
same place, same args, etc. prior to my PR. So I have no idea.
## Changelog
🆑 Melbert
fix: Map vote should work better
/🆑
## About The Pull Request
- Fixes `vote_delay` not being a thing. I broke this two years ago but
there's no bug report associated.
- Admins can now reset the vote delay (to let people vote again
instantly)
- Admins can now end the current vote immediately (rather than
cancelling)
- Custom multi and custom single combined into one vote
## Why It's Good For The Game
Makes voting a bit easier to use, both for admins and for coders adding
new votes.
## Changelog
🆑 Melbert
admin: Custom Single and Custom Multi votes are now combined into one
vote
admin: Admins can now end votes instantly, rather than cancelling them
admin: Admins can now reset the vote cooldown
fix: Vote cooldown actually applies now
/🆑
## About The Pull Request
Allows polls to hide the voting statistics, both while the poll is
running and when it completes, so that people vote in isolation of
knowing what other people are voting for.
It looks like this:
This functionality is also available for custom votes triggered by
admins, if they want it.
## Why It's Good For The Game
Put simply, if likely to be controversially, sometimes people get upset
that an event with a 5% chance of happening occurs 5% of the time. Now
they really won't know what the chance was, only that it was picked by a
weighted choice.
Lack of knowledge about what other people are currently voting for
should also curb "meme votes" where people pile onto something they see
other people voting for, your vote in a poll with hidden stats can only
be influenced by your own opinion because you can't see what the crowd
is doing in order to join their bandwagon.
## Changelog
🆑
add: Displaying the voting statistics is now optional on a per-poll
basis, and is disabled for map voting.
/🆑
## About The Pull Request
Reverts map vote to single selection rather than multi selection
## Why It's Good For The Game
Now that map vote is weighted, multi selection serves no purpose anymore
other than allowing people to gain "additional weight" in the vote,
which is unfair. It's weighted, everyone should have 1 vote.
## Changelog
🆑 Melbert
del: You can only vote for 1 map at a time again
/🆑
## About The Pull Request
See the title.
## Why It's Good For The Game
Mothblocks wanted map votes to not be simple winner take all and wanted
it to be randomly chosen based on votes.
## Changelog
🆑
add: Map Votes are now weighted random.
add: Custom Votes can now take advantage of Weighted Random winner
selection
del: Removed Herobrine from the game
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
Unfortunately, back in #70340 (4085e792ab)
which was declared to fix the issue of having only one map to vote for,
I cocked up a part of it. For some reason, the part where it states that
only one map could be voted for would only play on the emergency shuttle
leaving. I think I did this because of the fact that the mapvote would
auto-call, and this didn't really respect the fact that people would
also call their own votes with only one map to vote for. Thus, the vote
would fire with one map to choose for and there wouldn't be the message
on there being only one map to vote for that I added in the
aforementioned PR. This brings it back to the intended working
condition.
## About The Pull Request
A successful restart vote will revert any pending map change. Also
performs the end round task so persistence data gets saved.
## Why It's Good For The Game
Admin request for lowpop hours.
## Changelog
🆑 LT3
admin: Successful restart votes will now restart on the current map
code: End round and persistence data will be saved before executing
successful restart vote
/🆑
## 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
/🆑
* 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
* 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
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.
