Overview
Part of #28 — Split GP Tracking feature.
When a drop is submitted with players_included for a group that has split_gp_tracking enabled, the pipeline must:
- Persist split credit records to
drop_splits.
- Adjust the group leaderboard in Redis so each participant (including receiver) receives an equal share of the GP value.
Work Required
File: data/submissions/drop.py — drop_processor()
Insert after the existing group config loading block (~line 320, after player_groups is resolved and group configs are fetched):
For each group in player_groups:
- Check if
split_gp_tracking config is "1" for this group.
- If enabled and
players_included is non-empty:
a. Resolve each name in players_included to a Player row (query by player_name).
b. Filter to players who are valid members of this group — reuse check_split_capability() from data/submissions/point_awards.py.
c. Build participants = [receiver] + [valid split players].
d. split_value = (drop.value * drop.quantity) // len(participants).
e. For each non-receiver participant:
- Create a
DropSplit(drop_id=drop.drop_id, player_id=p.player_id, group_id=group.group_id, split_value=split_value) and flush.
- Call
redis_updates.add_split_credit(p.player_id, split_value, partition, group.group_id, world_type).
f. Adjust the receiver's group leaderboard score: call redis_updates.add_split_credit(receiver_id, split_value - full_value, partition, group.group_id, world_type). This is a negative delta that brings the receiver from full_value down to split_value on the group board only — the global leaderboard and player:*:total_loot keys are untouched.
Key Constraints
- The global individual leaderboard and
player:{id}:{partition}:total_loot Redis keys are never modified here — only leaderboard:{partition}:group:{group_id} sorted sets.
- Groups without
split_gp_tracking are unaffected; no DropSplit rows are written.
players_included is already normalised at line 110 via _normalize_incoming_players(); use that result directly.
Overview
Part of #28 — Split GP Tracking feature.
When a drop is submitted with
players_includedfor a group that hassplit_gp_trackingenabled, the pipeline must:drop_splits.Work Required
File:
data/submissions/drop.py—drop_processor()Insert after the existing group config loading block (~line 320, after
player_groupsis resolved and group configs are fetched):For each group in
player_groups:split_gp_trackingconfig is"1"for this group.players_includedis non-empty:a. Resolve each name in
players_includedto aPlayerrow (query byplayer_name).b. Filter to players who are valid members of this group — reuse
check_split_capability()fromdata/submissions/point_awards.py.c. Build
participants = [receiver] + [valid split players].d.
split_value = (drop.value * drop.quantity) // len(participants).e. For each non-receiver participant:
DropSplit(drop_id=drop.drop_id, player_id=p.player_id, group_id=group.group_id, split_value=split_value)and flush.redis_updates.add_split_credit(p.player_id, split_value, partition, group.group_id, world_type).f. Adjust the receiver's group leaderboard score: call
redis_updates.add_split_credit(receiver_id, split_value - full_value, partition, group.group_id, world_type). This is a negative delta that brings the receiver fromfull_valuedown tosplit_valueon the group board only — the global leaderboard andplayer:*:total_lootkeys are untouched.Key Constraints
player:{id}:{partition}:total_lootRedis keys are never modified here — onlyleaderboard:{partition}:group:{group_id}sorted sets.split_gp_trackingare unaffected; noDropSplitrows are written.players_includedis already normalised at line 110 via_normalize_incoming_players(); use that result directly.