There are two applications of this:

1. While doing long distance pathing, some blocks are better than others. Right now, anything that is canWalkOn is stored as SOLID, however that doesn't capture things like magma, soul sand, etc. Storing the locations of those alongside might be beneficial. This is somewhat mitigated by path trimming to loaded chunks (it will already avoid the first part of the soul sand / magma patch, and when it plans the next segment it'll avoid the next) but it isn't great because it can get trapped in corners and stuff. (see #18)

2. Valuable blocks. For example, /pathToAndRightClickNearest minecraft:ender_chest. Obvious reasons. We should store the locations of:

• Ender Chests
• Chests
• End portals
• Nether portals (the blocks, not the obsidian frame)
• Shulker Boxes
• Furnaces
• Hoppers
• Blocks of {Iron, Gold, Diamond, Emerald}
• Beacons
• Brewing Stands
• Mob Spawners (with type)
• Item frames (with item)
• Skulls (player, mob, wither)

Only mob spawners spawn commonly from this list, but they're interesting enough that I think it's no big deal to keep them. Uncommon natural spawns include brewing stands in igloos and end ships, loot chests in nether fortresses, strongholds, villages, etc, End portals in strongholds, furnaces in villages and igloos.

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.

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.

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

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

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

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

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.

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.

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.

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

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

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 =)

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.

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!

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?