RF455-079 RF 4.55: items stack only to 99; since 4.151 the limit is 200

Game: RF 4.55 (Dragonborn), server v0.3.1, Windows build (stock gameserver.exe). Client: the supported Taiwan build, RF_Online.bin SHA-256 46528aac…2bbc558 (2025-07-16), Language=Taiwan. Expected (wiki) Credit to RFDB for https://wiki.rfdatabase.net/ : Update 4.151 "Ataraxia Arrival", Improvements: "Stack limit: 99 → 200". No later page changes it.

Summary

• The server refuses any stack above 99 (read). Each of its three merge paths compares the merged amount with 0x63 (99): picking up loot, merging in the bag, and merging in the bank.
• The client allows up to 255 (read for the one path below). Its bag "add to stack" check only refuses an amount above 0xFF, and the stack amount is a u8 in the client and in 07/04.
• So 200 would fit the client and the wire. Only the server's constant keeps the 4.151 limit out.
• It matters most for crafting: Lv70 recipes need 140–648 of one material (itemmakedata row 214, iwkna70: irria05 ×378). At 99 per stack that takes up to 7 bag cells for one material.

Server side (all read, v0.3.1)

• (*Server).mergeLootIntoStack 0x1408026c0: at 0x140802880, cmp r9d, 0x63 / jbe, where r9d is the stack's amount plus the loot's. Above 99, the loot doesn't merge into that stack.
• (*Server).mergeStacks 0x140887f40: at 0x140888470, cmp r9d, 0x63 / ja (refuse). In mergeStacks.func1, 0x140889049–0x14088904e clamps an amount to 0x63.
• (*Server).handleTrunkIoMerge 0x140956a60: cmp edx, 0x63 at 0x140956c40 and 0x140957334.
• No table in gamedata_rf455.db has an overlap or stack column, so nothing per item changes the cap. The cash shop has its own "byOverlapNum %d > %d" check, whose limit wasn't read.
• Crafting isn't affected otherwise. consumeN 0x14097d760 takes u32 counts across several stacks, so a recipe for 378 works from four stacks of 99.

Client side (read, RF_Online.bin 46528aac…)

• CItemBoard vtable 0xAAC5D4, slot 12 (+0x30) = 0x479240, the merge onto a stack. It checks that the two items are the same kind (0x460420), then calls 0x46BAE0.
• 0x46BAE0 adds the amount: GetAmount (vtable +0x40) + the added amount, cmp ecx, 0xFF / jle at 0x46BB38. It refuses only above 255.
• The amount is a u8 (SetAmountBySerial 0x4772B0, and the 07/04 "stack grew" reply u8 amount).
• Other client checks weren't traced (for example, a split or drag dialog that might cap at 99). So that the client would show 200 is inferred from this path only.

Suggested fix

Raise the 0x63 checks in the three merge paths to 200 (0xC8), and the cash-shop overlap limit with them. The client field and 07/04 carry up to 255.

Local workaround

None without patching the server.