• Categories
  • Recent
  • Tags
  • Popular
  • Solved
  • Unsolved
  • Users
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (Darkly)
  • No Skin
Collapse
brainCloud Forums

Does LeaderboardService.RemovePlayerScore revert rewards?

Scheduled Pinned Locked Moved Unsolved Cloud Code
6 Posts 2 Posters 28 Views
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    moondory77
    wrote last edited by
    #1

    Hello,

    I'm working on a system to purge tournament records of fraudulent players.

    If I call LeaderboardService.RemovePlayerScore to wipe a player's entry, does the service also handle the reversal of rewards (or update their reward status) linked to that specific score? Or do I need to manually handle the reward adjustment?

    Thank you in advance!

    1 Reply Last reply
    0
  • J Offline
    J Offline
    JasonL bitHeads
    wrote last edited by
    #2

    No, RemovePlayerScore() does NOT handle reward reversals. You need to handle that manually. Also note that if the leaderboard is configured for a tournament, it will throw an exception and refuse to remove the score. Call LeaveTournament() for a tournament-based leaderboard, but it does not reverse rewards either.

    1 Reply Last reply
    0
  • M Offline
    M Offline
    moondory77
    wrote last edited by
    #3

    Thanks for the clarification.

    Just to be sure: if an abusive score has already been accumulated, is there no way to exclude that user from the reward table and dynamically recalculate the rewards for others? i.e., Can we not adjust the rewards distributed through the Claim API retroactively?

    1 Reply Last reply
    0
  • M Offline
    M Offline
    moondory77
    wrote last edited by
    #4

    @JasonL

    To clarify a bit more, I'd like to ask about the interaction between these API calls and the "Calculate results" job.

    1. Regarding LeaveTournament():
      If a user is kicked via LeaveTournament() before the "tournament - Calculate results" job runs, does the calculation job ignore their prior score? Or does the score they recorded before leaving still affect the overall reward eligibility?

    2. Regarding PostTournamentScoreOnBehalfOf:
      If we use PostTournamentScoreOnBehalfOf to manually reduce a user's score before the "Calculate results" job runs, will the rewards be determined based on this modified score?

    1 Reply Last reply
    0
  • M Offline
    M Offline
    moondory77
    wrote last edited by
    #5

    I have one more question regarding the behavior of division instances.

    Suppose there are instances ^1, ^2, and ^3 generated by a division set ID named "week". If a user belonging to instance ^2 is removed via the LeaveDivisionInstance API, what happens when the next user joins the "week" division set?

    Will the newly joining user fill the empty spot left in instance ^2, or will they just continue to join the latest/new instances (like ^3 or ^4) regardless of the eviction?

    1 Reply Last reply
    0
  • J Offline
    J Offline
    JasonL bitHeads
    wrote last edited by
    #6

    Q1: The removed player is completely excluded from reward calculation, so if the deletion happens before the job runs, that player is never iterated over and receives no rank or rewards.
    Q2: Yes, the modified score will be used. The job always reads live state. Note that whether the score actually gets modified depends on the leaderboard type (e.g., for the LOW_VALUE type, only updates if the new score is less than the existing)
    Q3: No backfilling, the next joiner goes to the latest instance, not the freed spot in ^2. No loop over earlier instances (^1, ^2) ever happens. The next joiner goes to ^3 (or ^4 if ^3 is full). The freed spot in ^2 stays empty permanently.

    1 Reply Last reply
    0

  • Login

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Solved
  • Unsolved
  • Users