RF455-071 RF 4.55 : Chip War, the win is recorded twice per war, and win streaks are reset at every battle start

Game: RF 4.55 (Dragonborn), server v0.3.1, Windows build (stock gameserver.exe, SHA-256 c10012f3…f699a). Client: the supported Taiwan build, RF_Online.bin SHA-256 46528aac…2bbc558 (2025-07-16), Language=Taiwan.

Summary

The race-buff result (winner, loser, third race, and a streak counter for each) is recorded twice in one war, on race-buff phase 2 and again on phase 3. Phase 1, at every battle start, zeroes the whole result, streaks included. Together:

• every win ends with a streak of 1, as if the race had won twice in a row;
• a race that really wins several wars in a row never builds a longer streak.

How it is known: the streak changes the buff's strength wasn't traced (open); the server logs it as win_streak.

1. Two records per war (read)

• onChipWarRaceBuff 0x1409076c0, rbx = the phase:
  • phase 1 is handled at 0x1409076ee–0x14090776a;
  • phases 2 and 3 both reach recordChipWarOutcome (0x14090776c: lea rcx,[rbx-2]; cmp rcx,1; ja → the call at 0x140907776).
• recordChipWarOutcome 0x1409077e0 gets the races from outcomeRaces 0x1407b5a00. That reads only [cw+0xe0] (holy master) and [cw+0xe8] (destroyed stone), which don't change between the two phases. So both calls pass the same result to raceBuff.SetResult (0x140907908).
• SetResult 0x1409061e0 (rax = the result, bl winner, cl loser, edi cap):
  • 0x140906224: if the stored winner ([rax+1]) equals bl, the winner's streak [rax+4] goes up by one (capped at edi); otherwise it is set to 0;
  • the same for the third race ([rax+2], [rax+8]) and the loser ([rax+3], [rax+0xC]);
  • then it stores the three races.
• So phase 2 stores the winner with streak 0, and phase 3 sees the same winner and raises it to 1.

2. Phase 1 clears the streaks (read)

• 0x14090771a–0x140907730 (phase 1, under the result's mutex):
  • movups [rcx+8], xmm15 zeroes the 16 bytes from the result (rcx+8): the valid byte, the three races and all three streak counters (rcx+0xC, +0x10, +0x14);
  • then it sets the races to 0xFF.
• A streak can therefore never carry from one war to the next.

Expected

One record per war. The streaks survive a new battle's start, and only the current result is cleared.

Suggested fix

• Record the outcome once (phase 2), and let phase 3 only refresh the buffs.
• In phase 1, clear the valid byte and the three races, but keep [rax+4], [rax+8] and [rax+0xC].

How to reproduce

What the code above predicts (inferred: i haven't seen a war end with a winner in our log yet):

1. Win a chip war with any race.
2. When the keeper phase ends (race-buff phase 3), the log line chip war race buff result shows win_streak: 1 for a first win.
3. Win again with the same race the next battle: the streak is 1 again, not 2.

What I do locally (not a fix)

A server patch (chipwar-win-once): at 0x14090776c, phase 2 calls recordChipWarOutcome and phase 3 goes straight to refreshRaceBuffs. That makes a first win streak 0. The phase-1 clear is left as it is.