RF455-133 RF 4.55: empty combine recipes, Halloween weapons, the Level 50 Armor Set Coupons, and the self-select vouchers

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

Follow-up to RF455-127Fixed, The mechanism is the one from RF455-127Fixed and is not repeated here: a combinetable2 row whose outputs are all -1 is dropped by loadCombineRecipe, and the combine is refused with "unknown manual index" before anything the player did is looked at.

The three groups are in different states, so they are separated below. Group B can be taken straight from the table the items are already there and the pattern is fixed by nine rows that already work. Group A's recipe-to-weapon mapping is read from the data (the civil masks pin it). Group C needs a decision: the data names a grade and a level but never the item list, so what I give is the candidate set, not an answer.

First, a heads-up on RF455-127Fixed's own fix

m_nOperationCount is how many times combineDraw runs, and each run takes one output that has not been taken yet (0x14088bec0: the loop bound is the recipe's +0x30, the taken-markers are the byte slice written at 0x14088c152 and tested at 0x14088caf1, and the chosen entry's m_dwPdProp is subtracted from the 10000 ceiling at 0x14088c198).

That is how the Armor Set Coupons grant five pieces: combinetable2 10069–10104 each have five outputs at m_dwPdProp 2000 and m_nOperationCount 5, so the five draws take the five pieces, one each.

All 18 rows in RF455-127Fixed carry m_nOperationCount 1 (29922–29930 and 30137–30145, every one). If the fix only fills their outputs and leaves that at 1, each coupon will hand over one random piece of the five instead of the set. They need m_nOperationCount 5 as well. The same applies to every five-piece row proposed below.

A. The Halloween weapon recipes (combinetable2 27676–27686)

Each row takes a recipe item plus iyetw13 장난 사탕 ×10, with a 100,000 fee, and has no output.

The weapon each row is for is read, not guessed: the row's m_strCivil matches the weapon type's own m_strCivil exactly, type by type, the Staff row is 11110000 against the Staff weapon's 11110, the two Launcher rows are 00001000 against the Launchers' 00001, and the other eight are 11111000 against 11111. Four weapon families share each type and each civil value, so the type is pinned and only the family is open.

The one choice: the four families are 할로윈 데이 ("Halloween Day") and 할로윈 캔디 ("Halloween Candy"), each in a permanent and a [30일] 30-day form (m_bIsTime 1). The material is candy, which hints at the Candy family, but nothing in the data settles it, all four carry the same civil per type, and the recipe items are named just "할로윈 <type> 레시피". Pick a column; the row only needs that one output at m_dwPdProp 10000, m_nOperationCount 1.

Two leftovers in the same block:

• iyetw12 할로윈 스페셜 패키지[Cash] ("Halloween Special Package"), combinetable2 27843, one material, fee 0, no output. A package's contents are not derivable from anything in the data, it needs your list.
• iyetw13 장난 사탕 is a material in those 11 rows and an output of none, and it appears in no cashshop, storelist, specialstore, itemcombine, boxitem, itemlooting or event-looting row, so even with the recipes filled, the candy has no source and the chain still cannot run. Worth deciding whether that block is meant to be live at all.

B. The nine Level 50 Armor Set Coupons (no recipe row at all)

iygco90–iygco98 are named exactly like iygco18–iygco53, the Armor Set Coupons that already work, but they have no row in either combine table so the combine window cannot even be opened for them. They are not in cashshop either.

Every Level 50 piece already exists in the item tables. The nine rows below are the Level 53 rows with 53 changed to 50 in the five output codes; all 45 codes were checked to exist.

Build each like its model row: five outputs, m_nOutNum 1, m_dwPdProp 2000 each, m_nOperationCount 5, m_bSelectItem 0, m_dwCommit 1000, m_bCombineExist 1. The combine index is 60376 + the new row number, and the row's m_strCode follows it (cocsa<index>), as every other row does.

C. The self-select vouchers (combinetable2 37659–37685, 37803–37804)

29 rows, all the same shape: one material (the voucher, ×1), fee 0, m_bCombineExist 1, m_nOperationCount 1, m_bSelectItem 0, no output.

This group needs a decision, and here is why. The names say 自選券 or "self-select voucher", but m_bSelectItem is 0 on every one of them, so as the data stands they would draw at random rather than let the player choose. Only nine rows in the whole of combinetable2 have m_bSelectItem 1 (22834, 22837, 22838, 22840 and the rest of the daily-certificate block); each offers three outputs at m_dwPdProp 10000 with m_nOperationCount 1, and that is the only worked example of a pick list in the data. If these vouchers are meant to let the player choose, they need m_bSelectItem 1 as well as outputs.

The names give a grade, a level and sometimes a race, but never an item list. What follows is the candidate set each name points at, not a decode of the intended reward, you will have to confirm or replace it.

Weapon vouchers, the eight standard weapon types at that grade and level:

Armour vouchers, five pieces, race from the name, class not stated:

Shield and cape vouchers:

(every code above was checked to exist in its item table)

What the data does not say for group C

• The weapon lists above are a judgement call. 83 different items match iw??b55; the eight in the table are the eight standard weapon-type stems (kn sw ax ma sp bo fi da) that combinetable2 30146–30153 already use as a set at d75, and at each grade and level they form one consistent named family (Divine / Saint / Patron / Beelzebub). iwdab55 does not exist, so 55B has seven, not eight. Is the intended list is a different series?
• The armour vouchers name a race but not a class. One row each, three class sets per race, the three are in the table. The machinery cannot pick a class and then grant that class's five pieces from a single row, so either these need one row per class (27 rows instead of 9, like the Armor Set Coupons), or the fifteen pieces go in one row with m_bSelectItem 1 and a different grant shape. Your call.
• The "+0 / +2 / +3 / +4 / +5" in the names is an enhancement level, which lives in the output's m_dwUpt. Rows that already do this are combinetable2 1350–1373, where otherwise identical rows step the top nibble (0x1fffffff, 0x2fffffff, 0x3fffffff …). Which bits mean "+N" is not decoded here, so the exact values are yours.
• iyetw58, iyetw59, iyetw60 (rows 37683–37685) have no name at all m_strName is just the item code. They look like placeholders; probably they should have m_bCombineExist cleared rather than a reward.
• None of these 29 vouchers is in cashshop, so unlike RF455-127Fixed nothing here is being sold. The cost of leaving them is a combine window that opens and always fails, not a wasted purchase.

Suggested order

1. Group B is ready to apply as it stands.
2. Group A needs one choice (which weapon family), then the eleven rows are mechanical.
3. Group C needs the reward lists from retail; the rows and candidates above are the groundwork.

And in all three: set m_nOperationCount to the number of items the recipe is meant to hand over, not 1, the point from the top of this report, which also applies to the RF455-127Fixed fix.

Local workaround

None. As with RF455-127Fixed, a GM can hand out the items directly.