[2308] Keep initiating player battle rewards - #2328
Merged
Merged
Conversation
Resolve the attacking troop against the current map-event roster before applying score hits, so a late join cannot redirect the initiating player's contribution and rewards.
…ator-battle-rewards # Conflicts: # source/GameInterface/Services/MapEvents/Commands/MapEventDebugCommands.cs
Late-joining clients can hold a different PartyBase identity from the registered map-event party. Prefer the registered party owned by this client so mission reserves bind to the correct local origin.
The live-test oracle previously inferred both participants from each client local map event, but a late joiner can have a partial involved-party view while the mission scoreboard already contains both players. Report the scoreboard-derived player-party count so the exact scenario observes the UI state it is intended to prove.
…ator-battle-rewards
Late-join clients can retain a partial MapEventParty graph even after the server has calculated rewards for every participant. Carry the receiver side in the result and unpack only the loot addressed to that stable party id so reward staging does not depend on the local replica graph.
The result handler already owns the game-thread boundary through RunSafe. Unpack the receiver-specific rosters inline so failures stay under that guard and no nested blocking call obscures the synchronous out parameters.
ShoT-UPfps
marked this pull request as ready for review
July 27, 2026 13:56
Contributor
Author
|
fake codefactors |
garrettluskey
approved these changes
Jul 27, 2026
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
2 participants
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.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Starting a battle gives the initiating player no loot or prisoners when another player joins later, while the joining player receives almost all of the rewards.
What is the new behavior?
Resolves #2308
Starting a battle keeps the initiating player's contribution attached to the correct troops after another player joins, so both players receive their own share of loot and prisoners at victory.
Bot Changelog Entry