Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rom1504 opened this issue Oct 1, 2015 · 21 comments
Open

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

rom1504 opened this issue Oct 1, 2015 · 21 comments
Labels
block funded high priority Stage3 idea is precisely specified, only coding is left to do

Comments

@rom1504
Copy link
Member

rom1504 commented Oct 1, 2015

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
Copy link
Member Author

rom1504 commented Nov 14, 2015

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
Copy link
Member Author

rom1504 commented Nov 14, 2015

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
Copy link
Member Author

rom1504 commented Jan 7, 2016

@rom1504
Copy link
Member Author

rom1504 commented Jan 7, 2016

(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
Copy link
Member Author

rom1504 commented Jan 7, 2016

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
Copy link
Member Author

rom1504 commented Mar 3, 2016

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

@rom1504
Copy link
Member Author

rom1504 commented Jan 21, 2017

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
Copy link
Member Author

rom1504 commented Aug 9, 2020

#1145 made this happen

Follow up :

  • create an example showing how to save a mineflayer world to anvil (rendered trivial by using prismarine-world)
  • 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)
  • 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
Copy link
Member Author

rom1504 commented Dec 28, 2020

deprecating blockAt would be really useful

@issuehunt-oss
Copy link

issuehunt-oss bot commented Dec 28, 2020

@rom1504 has funded $10.00 to this issue.


@introquest
Copy link

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
Copy link
Member

@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.

rom1504 added a commit to PrismarineJS/prismarine-world that referenced this issue Jan 1, 2021
see https://github.com/PrismarineJS/mineflayer/blob/master/docs/api.md#blockupdate-oldblock-newblock

working towards PrismarineJS/mineflayer#334 (comment)

this will do a get at each set, making the set methods a bit slower
it is needed to keep compatibility with mineflayer

I think it is ok as initialize can be used to do a faster set for many blocks
@rom1504 rom1504 added the Stage3 idea is precisely specified, only coding is left to do label Feb 6, 2021
rom1504 added a commit to PrismarineJS/prismarine-world that referenced this issue Feb 20, 2021
see https://github.com/PrismarineJS/mineflayer/blob/master/docs/api.md#blockupdate-oldblock-newblock

working towards PrismarineJS/mineflayer#334 (comment)

this will do a get at each set, making the set methods a bit slower
it is needed to keep compatibility with mineflayer

I think it is ok as initialize can be used to do a faster set for many blocks
rom1504 added a commit to PrismarineJS/prismarine-world that referenced this issue Feb 20, 2021
* add the same block events as mineflayer

see https://github.com/PrismarineJS/mineflayer/blob/master/docs/api.md#blockupdate-oldblock-newblock

working towards PrismarineJS/mineflayer#334 (comment)

this will do a get at each set, making the set methods a bit slower
it is needed to keep compatibility with mineflayer

I think it is ok as initialize can be used to do a faster set for many blocks

* fix posInChunk thing
@issuehunt-oss
Copy link

issuehunt-oss bot commented Apr 14, 2021

@sauberesache has funded $20.00 to this issue.


@rom1504 rom1504 changed the title Use prismarine-world Move the whole world state to prismarine-world for better packaging Aug 15, 2021
@issuehunt-oss
Copy link

issuehunt-oss bot commented Dec 11, 2021

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

@issuehunt-oss
Copy link

issuehunt-oss bot commented Dec 20, 2021

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

@rom1504
Copy link
Member Author

rom1504 commented Feb 4, 2022

signs and block entities are done

next step deciding what to do with paintings

@rom1504
Copy link
Member Author

rom1504 commented Feb 4, 2022

once paintings is gone we can merge #2453

@rom1504
Copy link
Member Author

rom1504 commented Feb 6, 2022

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 rom1504 added the funded label Feb 6, 2022
@rom1504
Copy link
Member Author

rom1504 commented Feb 6, 2022

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
Copy link
Member

Gjum commented Feb 6, 2022

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
Copy link
Member Author

rom1504 commented Feb 6, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
block funded high priority Stage3 idea is precisely specified, only coding is left to do
Projects
None yet
Development

No branches or pull requests

4 participants