-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Votes improperly pass on map change #7
Comments
This would probably be easiest avoided by cancelling all votes OnMapEnd, correct? I also haven't had a chance to look over the vote evasion commits, but I assume that would be safe as to not improperly punish players who technically "Disconnect" on map change, if a player vote was ongoing. |
Votes in progress will be canceled on map end. See #7
I've added a fix however I was unable to reproduce the issue and test the fix on TF2. |
I'll go ahead and test the fix this weekend, but it looks like the commit you added should solve the issue! |
Commit 1be0d5b unfortunately does not cancel votes, as OnClientDisconnect is fired before OnMapEnd. I did a little research and found this thread: https://forums.alliedmods.net/showthread.php?t=168389 I've tested hooking |
Also forgot another factor: At times of an RTV pass and the map changes, this will also cause a client disconnect but not fire any of the above events, so that would also be an issue. |
Cancel votes using game events (TF). #7
Hate to re-open this, however the issue does not seem to be solved on 1.16.3U-dev. On a test server, everything seems fine yet once in production with multiple other players and a much higher longevity, things go awry.
This is just one example, it's happened a few times. Under the circumstances of the map change, the game event has been fired, causing a cancel. I'm willing to guess |
As you can see here, 11 minutes later (on a normal map change), the vote that failed suddenly gets passed. Educated myself a bit, IsVoteInProgress is a stock SourceMod function, and given the circumstances the bool value it is returning is correct. I'm really not sure why the map vote is not being invalidated properly upon failure. It seems to work the same as all other votes, as seen here. |
Describe the bug
When someone creates a change map vote that is set to end outside the bounds of the current map timelimit (map will change before it is over), the vote will always pass.
To Reproduce
Steps to reproduce the behavior:
Config:
Wait until there are 10 seconds left until map end, initiate a vote. Map changes to initially voted next map, then immediately changes to custom voted map.
Expected behavior
If map vote ends after map ends, it should fail instead of passing without the required votes. This has started happening frequently now that this exploit has been found, sometimes players calling votes as soon as 2 seconds prior to map change to ensure they get the map they want.
Screenshots
N/A
Game Server
Additional context
Some logging:
As you can see, the map is immediately changed after proper next map is loaded, without even giving clients time to load into the server.
The text was updated successfully, but these errors were encountered: