Is indexing in items.json and blocks.json a good thing ?

[rom1504]

Currently blocks and items are indexed by id in items.json and blocks.json.
Is that really a good idea ? As seen in #7 users sometimes need to index by name or by metadata+id.

It should probably not be the responsibility of minecraft-data to choose that indexing, but the responsibility of the reader/user.

Not doing that indexing would simply mean using json arrays instead of json objects.

[roblabla]

👍 to removing the indexing, the data should be as natural as possible. Building an index table isn't hard to do in most languages anyway ^^.

[Gjum]

Not opposed, as it often depends on how the data are used and should be done by each application.

[rom1504]

So... not sure that's so easy. That means changing everywhere in mineflayer that use that indexing, also probably everywhere in stuff using mineflayer.

[roblabla]

@rom1504 we just need to create a js that exposes the indexed minecraft_data, and use that in the files instead of minecraft_data, don't we ? I don't think there would be a lot of code-level changes.

[rom1504]

@roblabla yeah sure, it actually already kind of exist there https://github.com/andrewrk/mineflayer/blob/master/lib/item_index.js

Problem is it also exists here https://github.com/Darthfett/helperbot/blob/master/lib/items.js#L14
and there https://github.com/rom1504/rbot/blob/5802c9806077be85974c830426aa387dc1d58257/task.js#L27

Also in lot of places in mineflayer (there for example https://github.com/andrewrk/mineflayer/blob/7890055e1046098487d8ce6ac5ded811813ea7b9/lib/block.js#L14)

So : yes we should provide a wrapper in mineflayer instead of providing the raw data, but that means changing stuff in lot of places.

Not sure this https://github.com/andrewrk/mineflayer/blob/master/doc/api.md#enums should still be in mineflayer API.

[rom1504]

I'm using the diff to check whether the data I'm extracting looks correct or not, so I'll do this change only when #8 is done.

[rom1504]

I'm not entirely sure we should get rid of indexing in the end.
The fact that it makes the diff easier to read is really useful (see 2655321 for example)
It might be possible to define a standard way to sort the blocks/items/recipes enums so that the diff is still useful but that would mean adding that sorting to all extractors when stringify currently does that sorting automatically.

[rom1504]

If we keep the indexing, maybe also index variations by metadata.

[Gjum]

When we start indexing everything by ID and metadata, we also should do it with recipes.json. Although there it would also involve drastic changes in the format because of multiple recipes per item (same ID and metadata).

[rom1504]

Well if we want to index recipes by id+metadata we could just index by something like "1:1" for stone with metadata=1.