Open lethosor opened 3 years ago
I guess there shouldn't really be a notion of ipairs on it, then. Unless the format does have a sensible end? Either way, it feels more like a function actually-- decodeTileInfo or whatever. Ykwim?
There definitely is a logical "end" - the attrs
table stores attributes about each enum item, and there are a fixed number of those. That's what my comparison to the behavior of @df.item_type
was intended to demonstrate - ipairs()
on an enum does end.
However, the Lua layer (maybe also C++) has a "default" attributes object for any enum items that aren't defined, which also includes values past the end of the enum. Here's another example. 1
and 2
are valid item_type
s, but 999
and 9999
are not, and the last two refer to the exact same table.
[lua]# !df.item_type.attrs[1]
<item_type._attr_entry_type: 0x7ffff7dcf430>
[lua]# !df.item_type.attrs[2]
<item_type._attr_entry_type: 0x7ffff7dcf448>
[lua]# !df.item_type.attrs[999]
<item_type._attr_entry_type: 0x7ffff7dcfca0>
[lua]# !df.item_type.attrs[9999]
<item_type._attr_entry_type: 0x7ffff7dcfca0>
So while we do want invalid indexes to continue to work, we should make ipairs(some_enum.attrs)
stop at the same place as ipairs(some_enum)
to fix this.
To reproduce:
This can be stopped with
kill-lua
if run withdfhack-run
(since printall_ipairs() is pure Lua).Reported by @wolfboyft on Discord