RF455-072 RF 4.55 : Chip War, the losing races can still mine after the war

Game server RF Online: Dragonborn v0.3.1 low · filed by cybercyber 20h ago

Fixed

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 chip war decides which race may mine until the next war. The server keeps the result (raceBuffResult), but nothing in the mining handlers reads it, so every race can mine whatever the outcome.

What the server does (read)

miningGateOpen 0x1408a3be0 (rax = server, rbx = client) is the gate the mining handlers call (6 callers). It returns true when the client has a character ([rbx+0x78]), is in the world (isInWorld) and isn't dead (isDead). It looks at nothing else.
validateMineStart doesn't look at the war either.
The result is there: [srv+0x298] points at the race-buff result. +8 is the valid byte and +9 the winning race, written by raceBuff.SetResult 0x1409061e0 after a war and cleared at the next battle start (onChipWarRaceBuff phase 1).

Expected

After a chip war only the winning race can mine. With no winner (time-out, chaos), the game's rule applies; the gameserver allow everyone.

Suggested fix

In miningGateOpen (or validateMineStart): when the race-buff result is valid and its winner isn't the character's race, refuse with the client's "can't mine" code.

How to reproduce in game

Let a chip war end with a winner.
Before the next battle, start mining in Crag Mine with a character of a losing race. It works.

What I do locally (not a fix)

A server patch (chipwar-mining-gate): miningGateOpen keeps the server pointer in its spill slot, and at the end a live miner is refused when [[srv+0x298]+8] is set and [...+9] isn't the character's race ([[client+0x78]+0x30] >> 1).

Reported on version 0.3.1

Replies 1

OSO AI Staff

Lv 12

Inspect OSO AI

18h ago

Reported: After a chip war the losing races can still mine.

Found: As described. The server kept the war's result but the mining checks never read it. The original server does not check race directly: it gives a mining permit for that war to the winning race, and during the keeper phases it refuses mining to anyone without one.

Fix: in the next RF 4.55 update, when the Control Chip falls, every player of the winning race who is online gets that war's mining permit. A player who picked up the Holy Mental also gets one when the server allows it. From the keeper phase until the next battle, starting to mine or installing a mining machine needs the permit. Without one it is refused. The permit is kept across a relog and ends when the next battle starts. A winner who was offline when the chip fell does not get one, as on the original server.

Also affected: the same fix is in RF Golden Age, RF 4.15 and RF 1.5.