Why files instead of using const variables?

Because I wanted to create a "one place for all constants" so we don't forget to update constants (protocol version number in initial_handlers, version string "Feather 1.18.1" in initial_handlers, anvil format number in base/anvil/region, and other constants in different places), but I completely forgot that I could create a constants.rs file.

Would it be too much to ask, if we moved this to a separate PR... since there are some stuff I would like to discuss, for instance moving to on build generated files, using build.rs.

Yeah, I think this pr should've been split into many PRs for worlds, dimensions, generators, 1.18, etc., but I was updating it like "old dimension_codec.nbt doesn't work, then I need to implement multidimension and biome loading, the packet doesn't work - rewrite proxy, a packet couldn't be deserialized - fix a bug in hematite-nbt" and so on, and I didn't want to stop if something doesn't work. I'm not sure if this would be compatible with old generators, but I think I can try to move it.

I think it's better to leave generators in this PR because:

1. 1.16 requires a biome generator, which is not implemented here (it extracts biome information at runtime rather than hardcode the Biome enum in generators) and I don't see any solutions other than "write a generator and then delete it" or "it doesn't work, but it'll work when 1.18 is merged" and have CI failing.
2. main doesn't have feather_base::consts, and this pr won't be able to use data_generators::extract_vanilla_data, so we'll need to have duplicate code across 2 PRs and then create another pr to remove it (or forget about it and have 2 different implementations, like we had feather-blocks and libcraft-blocks)
3. minecraft-data has removed Item::Air from their 1.16 data, but main still uses it as a default item, that'll create even more problems.
4. Should I replace libcraft-blocks with feather-blocks in this PR or in generators PR? Both variants have obvious issues such as merge conflicts in use statements.

This would cause a panic on loading an invalid world?

This would cause a panic on loading an invalid player.dat file. minecraft-data removed Item::Air and other non-item blocks from items.json, and I don't think panicking on invalid world saves is bad. Anyway, it's better than just silently wiping out a player's inventory.

Would it be better to only implement TryFrom?

Why use files, instead of a constants module?

Can bits_per_value be zero?

I don't know, but bits_per_value is not NonZeroUsize

Can panic.

This can only panic on non-utf8 file names, files not ending with .json, and invalid biome .json files, I think that failing fast on startup is better than making a user think "why doesn't my biome work?" because of a trailing comma.

non-utf8 thing is just sad but whatever,
invalid biomes should ideally not panic if the biome is never used but also passable,
files not ending with .json immediately stops working on mac. you can rely on the OS to insert a .DS_Store file anywhere you look. also why not have texts or images or any other crap hidden in datapacks, who does it hurt?

P.S, yes, this is my first appearance on feather gh

You're right, it should ignore .DS_Store, but images or text files shouldn't really exist in biomes/. Also, worldgen/ is not a datapack, though it would be great if we extract the full vanilla datapack when we implement the datapack support, so it's rather a temporary solution.

Feather (or any non-prototype rust code for that matter) should only panic on programming errors, never on I/O errors, which can and will definitely occur in normal usage. init_game already returns anyhow::Result so you don't even have to make big changes through a lot of code to implement proper error handling. Just pass the error up the chain by using ? and letting init_biomes return anyhow::Result<()>. This also applies for init_dimensions and anywhere else (I have not reviewed the PR yet).

Nice work, looks good

Remove path and or minor.

Remove patch and or minor.

An entire file commented out?

Commented out code.