Conversation
riichienv-core 0.4.8 gates chi/pon/kan detection on wall.drawable_count > 0, a stricter variant than Riichi City plays. Observed on a live 2026-08-24 capture: the server offered a chi on a discard made with the live wall empty (the hand's final discard at haitei), the engine's claim set came back empty, can_act went false, and the bot was never asked — the call window burned its full timer with Akagi silent. Any hand that plays toward an exhaustive draw hits this: the final discard happens at wall == 0, and pon (from any player) or chi (from the previous player) on it is suppressed. Ron is unaffected — the ron arm runs before the wall gate, so houtei raoyui still works. Kan replacement draws also deplete the engine's count despite coming from the dead wall, so kan-heavy hands can hit the suppression a few tiles early. Fix: after applying a wall-empty dahai, re-run the engine's own claim detection with the gate satisfied (bumping drawable_count by one and restoring it immediately — the ron arm already ran during apply with the true haitei conditions) and splice the chi/pon claims into current_claims, setting the response phase. Kan stays gated: an empty live wall is the engine's own call there. 4p and sanma twins; a unit test pins the offer and the wall restoration.
CI's clippy pass lints test targets too, and the floating stable toolchain newly flags the single-element &[String] slices built via clone in profile.rs — pre-existing on v3, hit by any PR that runs clippy --all-targets.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes a pre-existing gap in shared code, observed on a live 2026-08-24 Riichi City capture:
riichienv-core 0.4.8gates chi/pon/kan detection onwall.drawable_count > 0, a stricter variant than the games actually play. With the live wall empty — the hand's final discard at haitei — the engine's claim set comes back empty,can_actgoes false, and the bot is never asked. In the capture, the server offered a chi on that discard and the call window burned its full timer with Akagi silent.Scope
Any hand that plays toward an exhaustive draw hits this: the final discard happens at wall == 0, and pon (from any player) or chi (from the previous player) on it is suppressed. Ron is unaffected — the ron arm runs before the wall gate, so houtei raoyui still works. Kan replacement draws (rinshan, dead-wall) also deplete the engine's count, so kan-heavy hands can hit the suppression a few tiles early. Platform-independent: the same tracker/engine path feeds Majsoul and Tenhou, where the visible effect is the bot going quiet on a claim the server is offering.
Fix
After applying a wall-empty
dahai, re-run the engine's own claim detection with the gate satisfied (bumpingdrawable_countby one and restoring it immediately — the ron arm already ran during apply with the true haitei conditions) and splice the chi/pon claims intocurrent_claims, setting the response phase. Kan stays gated: an empty live wall is the engine's own call there. 4p and sanma twins.A unit test pins the offer (chi from the previous seat at wall 0) and that the wall is restored after the splice; a tile we cannot use still yields nothing.
The second commit fixes pre-existing
clippy --all-targetsfailures inprofile.rstest helpers that the floating stable toolchain newly flags on v3 — any PR currently trips them.cargo testgreen on top of latest v3 (937 passing), clippy-D warningsand rustfmt clean.