1.12 mapping data is not for 1.12 actually (legacy)

[zardoy]

this says in readme: mappings between legacy (1.12) and post-flattening (1.13+) blocks and items ids, but it seems that the data is for 1.13 actually. Let's say lever for example legacy mappings & actual state data. I wonder how this data was generated/used?

FYI this issue causes every block with some state render incorrectly for < 1.13

related https://github.com/PrismarineJS/minecraft-data/issues/216

[extremeheat]

and post-flattening (1.13+) blocks and items ids

but it seems that the data is for 1.13 actually

Yes that's what it says. Are you aware of what "post-flattening" means? If not, see https://minecraft.fandom.com/wiki/Java_Edition_1.13/Flattening

[zardoy]

Thanks for commenting! Yes, I must admit you're right, I was looking for legacy block meta - legacy block state values (not 1.13).

I think the problem is not how its generated (yes it does what it says), but how it is used in prismarine-block: https://github.com/PrismarineJS/prismarine-block/blob/38e8e877e43c1ad29a90d23102a6c23e0d95ebbd/index.js#L12 (it shouldn't use 1.13 block state data). Since then, what is the intended use case for this? As I understand it can be helpful only when migrating worlds to newer versions (though I didn't see anything like this among repos).

[extremeheat]

Block states don't statically exist pre-1.13, they are computed on the fly by the render code based on id+metadata. For example, adjacent blocks may result in a different "block state". prismarine-block only provides this data for helpful purposes, for example usage inside mineflayer-pathfinder or other high level plugins can rely on property information for all versions.

[zardoy]

Yes, I understand. Prismarine block provides _properties that is used in viewer and these properties are computed incorrectly because legacyPcBlocksByIdmeta uses mappings of 1.13 and not the version that doesn't "support" flattening yet (and thus uses old states). So in this repo, I think it would be useful to have some sort of mapping: id (like in current legacy mapping) - preFlatteningState. WDYT? The current legacy mapping I would actually call flattening instead

[extremeheat]

No, that's not possible per my last comment.

Block states don't statically exist pre-1.13, they are computed on the fly by the render code based on id+metadata. For example, adjacent blocks may result in a different "block state".

This is something that could only be implemented inside prismarine-chunk.

[extremeheat]

The current legacy.json doesn't do adjacency computation, so the mapped block states are more approximations so it will indeed return incorrect mappings by design. The old metadata system did use 4 bits of information (up to 15 distinct values) which is not enough to represent things like stairs, fences, walls, etc where the block state information matters. So instead the correct states like which direction fences connect to are only known once the chunk is fully loaded.