dnovikoff/tempai-core

Riichi mahjong golang library

tempai-core's Issues

Is there logic for the full game such as declaring riichi and calculating furiten?

Thanks for this great library.
I wonder is there an example, possibly built on top of this library, that contains a playable game in the terminal?
I imagine such a full implementation of the game in the terminal might require additional logic to handle proposing melds, riichi, and imposing furiten.

Can it correctly calculate the shanten for less than 13 tiles case?

thank you for this go package. I have two problems with it.

1. how can I get the right shanten value for less than 13 tiles case? the same case in tempai.net is right, "11223m55p1z" best drop is 1z, shanten value is 0, but use these package, it got 5, all less than 13 tiles case will get the wrong answer.
2. I found that when tenhon and tempai.net calculate the effective, If there is 3n+1 tiles in hand, it will be completed to 3n+2, but effective.Calculate() won't do that, it will get a wrong answer with 3n+1 tiles. Does anyone need the effective with 3n+1 tiles? if I want to completed the 3n+2nd tile, what rule should I use ?

Issue with Riichi Mahjong Points Calculation

I am using this package for calculating Riichi mahjong points. I've noticed an inconsistency when handling special hands, particularly with YakumanTenhou and YakumanKokushi13.

Problem Description:

When setting ctx.IsFirstTake = true and providing a Kokushi13 tile set, both YakumanTenhou and YakumanKokushi13 should be valid simultaneously. However, only YakumanKokushi13 gets registered.

The root cause appears to be in the func (c *calculator) run() *Result method. If c.tryKokushi() returns true, the function immediately proceeds to c.calculateResult(), bypassing the c.tryTsumo() method where YakumanTenhou is determined and added.

Expected Behavior:

Both YakumanTenhou and YakumanKokushi13 should be recognized and calculated correctly when the conditions are met.

Suggested Solution:

Adjust the function's control flow to ensure that c.tryTsumo() is called even when c.tryKokushi() returns true.