Yes that was it, thanks. I think it's a bit silly that this is even an option you can turn off, though.

@JasonL It works! Thank you!

Hi - so we highly recommend that apps using brainCloud utilize the client APIs for interactions from game clients. That API is purpose-built to represent a player -- the entire api is implemented from the perspective of a player of the player - and the built-in security model supports and enforces this. Mimicking that via S2S is not recommended. It's inefficient and error prone. Feel free to reach out to us via the support widget if you'd like to have a deeper conversation regarding what you're doing and why. Thanks, Paul.

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.

brainCloud developers have just release several playable builds of our famous examples! See our cool features in action. Find them at https://getbraincloud.com/demos for Windows, Mac, online and mobile.