Repository navigation
Conversation
DosMike
marked this pull request as ready for review
June 1, 2023 19:29
Contributor
|
Author
There you go :) |
Rushaway
approved these changes
Jun 24, 2024
Rushaway
added a commit
to srcdslab/sourcebans-pp
that referenced
this pull request
Sep 3, 2026
…ial values Ports upstream sbpp#894. - Initialize g_iBanCounts/g_iMuteCounts/g_iGagCounts to -1 so the natives report "not yet available" rather than stale values before the async OnConnectBanCheck callback resolves. - Reset those counts to -1 in OnClientDisconnect_Post. - Add global forward SBPP_CheckerClientBanCheckPost(int iClient), created in AskPluginLoad2 and fired from OnConnectBanCheck once counts are populated (before the PrintCheckOnConnect guard so it always runs). - Document the new -1 return contract and the forward in the include. Adapted to fork divergence: fork splits comms into separate mute/gag counts and uses SB_VERSION, so no manual VERSION bump; forward creation lives in the fork's AskPluginLoad2 alongside g_bLate. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: DosMike <xanatosefan@gmx.de>
Rushaway
added a commit
to srcdslab/sourcebans-pp
that referenced
this pull request
Sep 6, 2026
* feat(checker): add SBPP_CheckerClientBanCheckPost forward and -1 initial values Ports upstream sbpp#894. - Initialize g_iBanCounts/g_iMuteCounts/g_iGagCounts to -1 so the natives report "not yet available" rather than stale values before the async OnConnectBanCheck callback resolves. - Reset those counts to -1 in OnClientDisconnect_Post. - Add global forward SBPP_CheckerClientBanCheckPost(int iClient), created in AskPluginLoad2 and fired from OnConnectBanCheck once counts are populated (before the PrintCheckOnConnect guard so it always runs). - Document the new -1 return contract and the forward in the include. Adapted to fork divergence: fork splits comms into separate mute/gag counts and uses SB_VERSION, so no manual VERSION bump; forward creation lives in the fork's AskPluginLoad2 alongside g_bLate. Co-authored-by: DosMike <xanatosefan@gmx.de> * review fixes - SBPP_CheckerGetClientsComms returned -2 (the sum of two -1 sentinels) before the check resolved, breaking the "-1 if not yet available" contract the include now documents. Return -1 when either half is unavailable. - OnConnectBanCheck only assigns the mute/gag counters from optional FetchRow() branches. If the result set ever came back short, those stayed at -1 while the ban count was populated, making commcount negative and firing bogus "Comm Warning" prints (the `if (commcount)` truthiness test passes for -1/-2). Clear the sentinel on both counters once the check completes, so post-check values are always >= 0.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
As user of the SourceBans Checker API I would like to be notified when the bans and commbans counters are actually valid, or at least be provided with fallback values until they are.
Motivation and Context
As of 1.8.0 the values in g_iBanCounts[client] and g_iCommsCounts[client] remain stale between a disconnect and the async
OnConnectBanCheckcallback. This might cause issues if you want to rely on, or react to these values as soon as they are available. If a plugin is polling values this would currently still give incorrect results for quite some time, even if the the client is ingame AND authorized, thus resetting the values to -1.How Has This Been Tested?
Types of changes
Checklist: