Reported by
A community member, referred via @ezemania2. They report having tried client-side troubleshooting first and reproduced across multiple clients, which points at the server.
A second contributor independently investigated this on their server with the same observations — long-standing bug across multiple Erupe forks/Discords going back years with no documented fix.
Symptom
When using the 2nd guild stove to select a Clan Food recipe, picking an ingredient causes a random item to be auto-selected into either the 3rd or 4th ingredient slot. The auto-filled item is not a valid cooking ingredient (one observed instance: "Book of Combos 3").
The bug appears specific to the 2nd stove; the 1st stove behaves normally.
Reporter quotes
"Essentially it only occurs when using the 2nd stove in game, selecting an ingredient will automatically cause a random item to be selected for either the 3rd or 4th ingredient slot, I've tried troubleshooting the issue (thought it was client sided at first) but the issue is present across multiple clients so i've been trying to investigate it server side"
(Screenshot of the affected guild's cooking UI was provided privately.)
Relevant config:
"ClanMealDuration": 86400
From the second contributor:
"What's weird is even scoping around in multiple discords, this issue was present years prior, but I can't find any concrete source/fix. I tried to band-aid it server side by automatically wiping the ingredient selection if not one of the correct item IDs, but something still seems to cause corruption on that stove."
"When a player interacts with a cooking stove, the client sends `MSG_SYS_CAST_BINARY` packets containing the `3d 01` (stove selection) and `3d 02` (ingredient selection) messages. The server receives these and rebroadcasts them as `MSG_SYS_CASTED_BINARY` to other players in the stage so everyone can see what's being cooked."
"The `BroadcastTypeTargeted` path is where cooking packets flow, and after `msgBinTargeted.Parse` strips the targeting header we get access to the inner payload containing the `3d 01`/`3d 02` data."
"The fundamental limitation we hit is that `MSG_SYS_CAST_BINARY` is a broadcast packet — the client sends it to inform others, but the client itself has already decided what to display locally before sending it."
Why server-side filtering isn't enough
`MSG_SYS_CAST_BINARY` is informational broadcast. The originating client has already committed to its local ingredient state before sending the packet. Server-side scrubbing of invalid item IDs only changes what peers see — the cooking player still has the bad slot locally, and any persisted recipe outcome may still be wrong.
Suggested investigation
- Confirm whether the corruption is purely client-local display state or whether it persists to the DB (guild cooking table). The `repo_guild_cooking.go` / `handlers_guild_cooking.go` layer should be checked for whether stored recipes round-trip the bad item.
- Determine why the 2nd stove specifically is affected — is there a stove-index-dependent code path, or a per-stove offset into a shared buffer that's miscounted?
- Capture raw `3d 02` payloads from a real client on the 2nd stove to determine whether the bad item ID is on the wire or injected client-side by something else (UI logic, save load, struct misalignment).
- Check `handlers_cast_binary.go` and the save load path (`loadCharacterData` in `handlers_helpers.go`) for any field overlap between guild cooking ingredients and bookshelf / combo-book data — observing "Book of Combos 3" specifically suggests possible struct misalignment between adjacent regions.
- Check whether the issue correlates with client version (G-rank/ZZ vs older modes). Recent ZZ save blob layout work (commits b1972e3, 47277c7) shifted offsets and may have other untracked moves.
Relevant code paths
- `server/channelserver/handlers_guild_cooking.go`
- `server/channelserver/repo_guild_cooking.go`
- `server/channelserver/handlers_cast_binary.go`
- `network/mhfpacket/msg_sys_cast_binary.go` / `msg_sys_casted_binary.go`
- `network/mhfpacket/msg_mhf_load_guild_cooking.go`
- `network/mhfpacket/msg_mhf_regist_guild_cooking.go`
- `server/channelserver/handlers_helpers.go` (load/saveCharacterData)
Severity
Medium — visible gameplay bug affecting guild cooking, persistent across forks for years, no clean fix yet identified.
Reported by
A community member, referred via @ezemania2. They report having tried client-side troubleshooting first and reproduced across multiple clients, which points at the server.
A second contributor independently investigated this on their server with the same observations — long-standing bug across multiple Erupe forks/Discords going back years with no documented fix.
Symptom
When using the 2nd guild stove to select a Clan Food recipe, picking an ingredient causes a random item to be auto-selected into either the 3rd or 4th ingredient slot. The auto-filled item is not a valid cooking ingredient (one observed instance: "Book of Combos 3").
The bug appears specific to the 2nd stove; the 1st stove behaves normally.
Reporter quotes
(Screenshot of the affected guild's cooking UI was provided privately.)
Relevant config:
From the second contributor:
Why server-side filtering isn't enough
`MSG_SYS_CAST_BINARY` is informational broadcast. The originating client has already committed to its local ingredient state before sending the packet. Server-side scrubbing of invalid item IDs only changes what peers see — the cooking player still has the bad slot locally, and any persisted recipe outcome may still be wrong.
Suggested investigation
Relevant code paths
Severity
Medium — visible gameplay bug affecting guild cooking, persistent across forks for years, no clean fix yet identified.