Alpvax

Maybe post an image during the day so the armour can actually be seen? Also, we will need your rendering code to be able to debug it.

I would rather not use "decorative_blocks" because that doesn't really say what they are, and people may start adding other "decorative" blocks into the tag. Maybe "small_storage_blocks" or "storage_blocks_2x2" or something similar would be better. As for the actual blocks, there are more than just quartz and copper which would fall into the 2x2 tag: Glowstone Clay Snow Honeycomb Honey (reversible, but requires 4 glass bottles) Magma Cream Quartz Copper (reversible, but I think only if the block isn't weathered?) Amethyst Sandstone (possibly? It's a bit different being block -> block, but follows the same irreversible principle). Prismarine (has both a 3x3 "prismarine_bricks" and a 2x2 "prismarine" recipe. Both are irreversible). Purpur (probably not, the recipe produces 4 blocks, so more of a conversion like the various stone types).

You're missing part of the item name in 6 of the last 7 entries in your loot table

You're trying to create a new instance, but not calling a constructor. Get rid of the "new" keyword.

Is this now preferred to using ObjectHolder? Or has this approach superceded ObjectHolder?

There are 3 methods which sound like they do something very similar, overridden by various different blocks: updatePostPlacement is used to make connections with adjacent blocks (fences/walls). /** * Update the provided state given the provided neighbor facing and neighbor state, returning a new state. * For example, fences make their connections to the passed in state if possible, and wet concrete powder immediately * returns its solidified counterpart. * Note that this method should ideally consider only the specific face passed in. */ public BlockState updatePostPlacement(BlockState stateIn, Direction facing, BlockState facingState, IWorld worldIn, BlockPos currentPos, BlockPos facingPos) neighborChanged appears to be used for detecting redstone changes (or water in the case of sponge) // No Javadoc public void neighborChanged(BlockState state, World worldIn, BlockPos pos, Block blockIn, BlockPos fromPos, boolean isMoving) And the forge-added onNeighborChange is called from World#updateComparatorOutputLevel: /** * Called when a tile entity on a side of this block changes is created or is destroyed. * @param world The world * @param pos Block position in world * @param neighbor Block position of neighbor */ default void onNeighborChange(BlockState state, IWorldReader world, BlockPos pos, BlockPos neighbor) My question is which method should be overridden for what purpose, as many of the call paths are similar. I have spent quite a bit of time trying to trace the call paths and have become lost multiple times. I was using neighborChanged, but switched to using updatePostPlacement (as that already supplies the direction, and sounds more like what I needed (making connections between blocks)). The effect in-game did not change, so I am wondering when I should be using each of these methods. There is also the following forge-added method, which doesn't appear to be overridden anywhere, and is only called by the blockstate method of the same name, which is itself not called: /** * Called on an Observer block whenever an update for an Observer is received. * * @param observerState The Observer block's state. * @param world The current world. * @param observerPos The Observer block's position. * @param changedBlock The updated block. * @param changedBlockPos The updated block's position. */ default void observedNeighborChange(BlockState observerState, World world, BlockPos observerPos, Block changedBlock, BlockPos changedBlockPos)

You've commented out the event listener (ModelBakeEvent) which actually instantiates your custom model (in BlocksMod.java).

Check out TheGreyGhost's MBE04: Dynamic_block_models. It does almost exactly what you want (make sure you understand, not just copy-paste).

That is the only way. All blockstates are calculated on registration, so there is no way to save that to a single blockstate. If there are that many, you may need to rethink your approach. You could maybe store a chunk capability with a map of blockpos -> blockstate, but I'm not sure that would save you much (after all, that is what the world saves). And you'd have a much harder time sorting out the rendering.

I'm assuming big-endian. But TBH, I thought the byte order was part of the UTF-8 spec. I've never seen it called UTF-8 BE.

You could try looking at how the vanilla /fill command does it. I'm not sure how optimised it is.

Should probably be a new topic, as it's a different issue. I believe it is the same as the undyed version. The dye is saved in the NBT.

I'm not fully convinced of that. You should send "player scrolled X slots", that way the actual scroll amount per slot can be configured client-side.

It is also possible to use NBT tags to create swords which have custom attributemodifiers and models in order to have more than the usual sword types. It can be done with any item, but you cannot add new functionality and behind the scenes they are still the vanilla sword item. See https://minecraft.gamepedia.com/Model#Item_predicates for more info on custom models (uses an NBT tag to select which model override to use).

I saw, thank you. I'll hopefully test it tomorrow, but it looks good. I've never managed to get my head around this, so thanks for helping.