Store locations of special blocks about baritone

[oldgalileo]

As per #17, the contents of Chests should be stored alongside the chunk caching to enable pathing to a chest with a given item.

Merging #17 into this and closing #17 for consolidation.

[leijurv]

I made them separate on purpose. Storing inventory contents is different from storing valuable block locations, other than that they're both ancillary data we're attaching to cached chunks.

[leijurv]

But #17 was pretty sparse, so no big deal.

[oldgalileo]

@leijurv I'm not sure that that's true. We should be storing special blocks and their NBT data inside the ancillary data we're attaching to chunks and as far as I know, chests still use NBT data.

[leijurv]

@HowardStark You don't get chest contents with the chunk. Once we get a chunk and can convert into storage format, we can get the simplified 2-bit version, and the locations of all special blocks, immediately. Blocks with inventories are separate, since we only get them once we actually right-click and open the inventory.

[oldgalileo]

@leijurv We should be storing the chest/inventory-block locations inside the ancillary data and updating that block with the proper NBT data for their contents if and when we are given that data.

[leijurv]

Okay, however I think updating only once we get the data is a separate and more complicated issue from just modifying our existing Chunk -> CachedChunk converter to include special block locations alongside the overall 2-bit representation.

[oldgalileo]

Why? We're not touching the 2-bit representation with special blocks at all. This is, as you say, separate and thus is not as big of a deal, especially since we don't have any of this written as of the time this comment was made.

[leijurv]

Because it's entirely self contained within the Chunk -> CachedChunk converter. As opposed to also reaching into GuiInventory to get the contents of the open chest later on.

[leijurv]

I'm just saying they're different issues, not that they should be stored differently on disk.

[oldgalileo]

I'm not seeing how they are different. Perhaps renaming this issue to "Store special block data" would be more appropriate?

[leijurv]

Because there's a clear delineation of first step: store where the blocks are. second step: store their contents once we open them. The first step can be easily accomplished in our Chunk to CachedChunk converter. I'd prefer to have more "bite-sized" issues, but still each comprising a new feature =)

[oldgalileo]

Storing where the blocks are and storing what the blocks are I assumed would be the same here. In Minecraft, a block can contain NBT data. Now, I assumed that we would simply serialize the blocks and their metadata as they were, or make a serializable wrapper that contained that information.

Granted, I may be wrong in assuming that, but either way, we're diving into implementation details of a feature which has no implementation, it seems overzealous imo to try breaking these issue down in advance. If upon implementation, it becomes an issue, then I think we should, by all means, create an issue.

In addition to the rename proposed above, perhaps it is time to begin using GitHub projects as, if I remember correctly, tasks can have subtasks for I agree that the container item storage is a subtask. I simply disagree that it necessitates its own issue at this state and feel it clutters the issue list given the clear dependency on this being implemented even before that.

[leijurv]

Yeah, it's just that the server doesn't give you the contents of the chest / shulker / furnace until you actually right click it.

I'd love subtasks!

[ZacSharp]

Storing the locations of BLOCKS_TO_KEEP_TRACK_OF has been added 3 years ago in d0fc77e. That's version 0.0.3.
Can this be closed now?