Move the whole world state to prismarine-world for better packaging

[rom1504]

This will make blockAt async and break everything depending on it. But it's for the good cause of being able to implement a world representation with any kind of backend (especially async backend like databases)

https://github.com/PrismarineJS/prismarine-world

https://github.com/andrewrk/mineflayer/blob/master/lib/plugins/blocks.js

[rom1504]

One way to make the transition smoother is to just deprecate blockAt, implement it using prismarine-world-sync and use bot.world for everything else.

[rom1504]

Something interesting about this is a prismarine-world-blockfinder could be made and used in mineflayer-blockfinder that would then be just a few lines.

[rom1504]

requires https://github.com/PrismarineJS/prismarine-chunk/issues/16#issuecomment-169614381

[rom1504]

(using prismarine-world-sync would break mineflayer in the browser though, maybe it should be an optional dependency and we'd have no blockAt function for the no-prismarine-world-sync case, or maybe we could just remove blockAt altogether, but that would mean doing PRs on all projects using mineflayer)

[rom1504]

Related idea : have a prismarine-world-snapshot that would take a snapshot of a given region and allow a sync api on that region. That might be useful to speed up blockfinder. (or maybe doing it asyncly would be fast enough, better benchmark before doing that)

[rom1504]

Alright, let's start with using prismarine-chunk in mineflayer. That will give us cross platform chunk (https://github.com/PrismarineJS/prismarine-chunk/issues/19) + we don't have to deal with the async problem for now.

[rom1504]

p-chunk is now used. using prismarine-world could be considered but would involve a lot of async everywhere. Not not obvious to do

[rom1504]

https://github.com/PrismarineJS/mineflayer/pull/1145 made this happen

Follow up :

• [x] create an example showing how to save a mineflayer world to anvil (rendered trivial by using prismarine-world)
• [x] Some events, world is already an EventEmitter, but no events are emitted (blockUpdate, chunkColumnLoad/Unload, etc..) eventually those events could be removed or proxyed in mineflayer
• [ ] store signs paintingsByPos and paintingsById in prismarine-world (/chunk)
• [x] A way to store block entities https://github.com/PrismarineJS/mineflayer/blob/master/lib/plugins/blocks.js#L27 it would make sense to have it directly in prismarine-chunks similar to what mojang do (would simplify things for storing chunks), but that could go first in prismarine-world
• [ ] deprecate bot.blockAt , bot.world.getBlock should be used. (that'll be when everything of the world is ported to prismarine-world)
• [ ] move find block to somewhere outside of mineflayer, so it can be used with any prismarine-world (either its own package, either directly in prismarine-world)
• [ ] entities ? If we want to be able to use only pworld in pviewer, we also need the world to emit entity related events: https://github.com/PrismarineJS/prismarine-viewer/blob/master/lib/mineflayer.js#L82
• [ ] make the viewer use prismarine-world only

[rom1504]

deprecating blockAt would be really useful

[issuehunt-oss[bot]]

@rom1504 has funded $10.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[introquest]

Faced with the fact that mineflayer duplicates some things from prusmarine such as Block, Item, Recipe, etc. Is it about reusing all of this from prismarine? And what remains to be done on this task?

[TheDudeFromCI]

@introquest Mineflayer does not duplicate anything from those libraries, but imports then. The goal of Mineflayer is to move as much code out of Mineflayer as possible into micro-modules. (prismarine-block, primsarine-item, etc) Ideally, by making many very small libraries, they become very easy to maintain and reuse since they are so small.

As for this issue, prismarine-world should contain all of the world states, with Mineflayer acting solely as a stateless transformer for the world. The world contains submodules that further divide the state. Prismarine-chunk, Prismarine-Entity, etc.

[issuehunt-oss[bot]]

@sauberesache has funded $20.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[issuehunt-oss[bot]]

@sauberesache has cancelled funding for this issue.(Cancelled amount: $20.00) See it on IssueHunt

[issuehunt-oss[bot]]

@rom1504 has cancelled funding for this issue.(Cancelled amount: $10.00) See it on IssueHunt

[rom1504]

signs and block entities are done

next step deciding what to do with paintings

[rom1504]

once paintings is gone we can merge https://github.com/PrismarineJS/mineflayer/pull/2453

[rom1504]

new plan after discussion in discord:

move everything to pchunk

• [ ] paintings
• [ ] entities
• [ ] inventories as part of entities
• [ ] players as part of entities
• [ ] bots as part of players

since entities can move between chunks,

• [ ] pworld should handle the move of entities from one chunk to the next

once this is done, mineflayer should contain no state and be only a packet <-> world and action <-> packet/world synchronization layer it will allow

• same state storage for bot/client and server
• natural multi bot support with one world
• possibility to emulate world changes without client and server
• easy to test features of the world (like find block, pathfinding, visualization...) without network

[rom1504]

since we have some funding now, any significant PR towards that goal is eligible to $20 of reward (using open collective money)

of course working on it because it's cool stays a great reason :)

[Gjum]

why would entities be part of a chunk, and not just part of the world? their id is unique in the entire world, most entities move freely between chunks all the time, and accessing entities through their current chunk is rather useless as you typically want to find entities nearby regardless of what chunk they are in.

[rom1504]

the world abstraction (pworld) would expose the ability to search for an entity by its id or to look for an entity in a location based on properties (by looking and/or indexing the information stored in chunks) having the entities in the chunk make it natural to save/load them to disk (anvil) and to load/unload them when chunks get loaded/unloaded. It also does a clean separation of concern between chunk storing the data, and world just exposing and doing the orchestration

having the entities be part of the chunk should make it easier to scale the world to large sizes