Add legacy id:meta to block state map

[Flonja]

This has been auto-generated.

[extremeheat]

Where did your source this data from?

[extremeheat]

The schema is also not correct, it should be encapsulated inside a blocks object like the pc legacy.json. That will allow it to be added here https://github.com/PrismarineJS/node-minecraft-data/blob/master/index.js#L109 and used like doc in https://github.com/PrismarineJS/node-minecraft-data/blob/master/doc/api.md#minecraftdatalegacypcblocks

[Flonja]

Where did your source this data from?

Good question, it's based on:
https://github.com/pmmp/BedrockBlockUpgradeSchema/blob/master/block_legacy_id_map.json

The schema is also not correct, it should be encapsulated inside a blocks object like the pc legacy.json.

Would that still be okay? I don't include the items part like the pc legacy.json.

[extremeheat]

I don't include the items part like the pc legacy.json.

Yes, I mean you would need to fix that. I don't see how it makes sense to do special handling inside node-minecraft-data over just fixing the schema here to match the existing one.

[extremeheat]

OK, and to be clear this is only mapping 1.2 (pre-flattening) -> and 1.3/1.4 (post-flattening) right?

[Flonja]

I generated the data with 1.2 (id:meta) -> 1.18.10 mappings

[extremeheat]

Merged, you can open an accompanying PR to node-minecraft-data to expose the new data by adding bedrock to here: https://github.com/PrismarineJS/node-minecraft-data/blob/master/index.js#L109

Additionally, we may need additional mapping here per PrismarineJS/prismarine-chunk#230 that blocks may have been renamed after flattening stringification in other versions. However, this can be investigated later on what the optimal way to handle this is.

[extremeheat]

/makerelease