On current main (7c9d119), the red-mahjong state documentation describes state.players.meld_tiles as the tile IDs making up each meld. However, the array is initialized to -1 and is not populated during play.
The meld update helper updates melds and meld_counts. A minimal reproduction of that update path:
import jax.numpy as jnp
from mahjax.red_mahjong.action import Action
from mahjax.red_mahjong.env import _append_meld
from mahjax.red_mahjong.meld import Meld
from mahjax.red_mahjong.state import State
pon = Meld.init(jnp.int32(Action.PON), jnp.int32(28), jnp.int32(3))
state = _append_meld(State(), pon, jnp.int32(0))
print(int(state.players.meld_counts[0]))
print(int(state.players.melds[0, 0]))
print(state.players.meld_tiles[0, 0].tolist())
Output, verified against the above commit on CPU:
We encountered this in a downstream observation adapter: reading the documented array silently omitted existing meld tiles and undercounted visible tiles. Decoding state.players.melds resolved it. MahJax's own dict observation already reads the packed melds, so this report concerns the documented meld_tiles field.
Is meld_tiles intended to be populated, or is it an unused field retained in the state layout? If it is intentionally unmaintained, could the documentation and field declaration say so and point users to melds? I would like to confirm the intended contract before proposing a runtime change.
On current
main(7c9d119), the red-mahjong state documentation describesstate.players.meld_tilesas the tile IDs making up each meld. However, the array is initialized to-1and is not populated during play.The meld update helper updates
meldsandmeld_counts. A minimal reproduction of that update path:Output, verified against the above commit on CPU:
We encountered this in a downstream observation adapter: reading the documented array silently omitted existing meld tiles and undercounted visible tiles. Decoding
state.players.meldsresolved it. MahJax's own dict observation already reads the packedmelds, so this report concerns the documentedmeld_tilesfield.Is
meld_tilesintended to be populated, or is it an unused field retained in the state layout? If it is intentionally unmaintained, could the documentation and field declaration say so and point users tomelds? I would like to confirm the intended contract before proposing a runtime change.