Draco18s

Persistent chunks are chunks that persist, i.e. are chunkloaded so that they NEVER unload unless the game is shutting down. So yes, that array would be empty. If you want to check for chunk unloading, subscribe to the ChunkEvent / ChunkDataEvent events (there's at least three between those that will be of interest).

Look at how Vanilla does it.

Because the water push logic is handled by Material.WATER checks in the Entity class, explicitly. If you want a block to push players/objects you will need to code that into your block class.

List<ItemStack> drop = new ArrayList<>(); Cool, I have an array object if (drop == null) Nope, it's not null. It's an ArrayList of size zero. block.harvestBlock(world, player, pos, state, world.getTileEntity(pos), new ItemStack(block)); InventoryHelper.spawnItemStack(world, pos.getX(), pos.getY(), pos.getZ(), new ItemStack(block)); And now, I ignore the fuck out of my array object.

You need a TickEvent handler and count ticks.

You need to place the torch in the block space that should be the torch, not place the block in the space that the torch is attached to.

var propertyDirection = PropertyDirection.create("facing") That is not the same property as the one in BlockTorch. You need to use BlockTorch.FACING

This isn't a 1.11 specific issue. People have been having this problem since at least 1.7

4,962 other people have had the same problem and posted here about it.

Quite.

Blocks, then items, in preInit.

> We get an error > No error posted > No code posted You expect help. ...how?

That's because your +1is on the wrong side. You need to add it to the positive X and positive Z directions. NOT to left or right sides. Your killzone IS 5x5, but it is offset from where you want it (it includes the fence on the fat side from where it didn't kill the shulkers).

Yes. I am. But the tutorial you were using is old and shitty.

Try: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L94

All the libraries I use are my own. They're in the same repository. In fact, my second link is in said library. It shows how I use the interface I created in order to let the Item class dictate how it should handle its own NBT data for rendering, rather than having it externally. It's not any different than vanilla's IItemPropertyGetter, really. The only difference is that IItemPropertyGetter can only handle one type: floats.

That's because your "center" is not in the middle of a block, but on one corner. Radius 2 = 4x4 area centered on a corner (range [0-2, 0+2] => 4). Which is exactly what you got. If you want "radius 2" to be a 5x5 area centered on a block, then you need to expand by one in the positive X and positive Z directions (range [0-2, 0+2+1] => 5):

Your AABB is not big enough. You're missing the fact that your block exists at (x,y,z) and has a SIZE of (1,1,1)

Turn off the mob's AI. You can use the /summon command and give the datatag {NoAI:1}

Stop using ModelMesher and start using ModelLoader (and call it during preInit). All your problems will magically go away.

You won't be able to do this with a Forge mod.

It doesn't exist any more. Loot is now handled by LootTables and json definitions.

As someone who's previously teleported chunks of the world around before, there are a few things you might want to build in to avoid potential problems. Even though you use the setBlockState method that doesn't update neighbors, you might still find that redstone, rails, torches, etc. pop off their surface during the teleport. There's probably no reliable way to avoid this, and you're going in both directions. But a few things that might work, or at least help: Try putting the chunk ("the bits you're moving") into a safe middle-space before doing the replacement. This allows you to make sure that things copy over correctly as you have a non-destructive process (i.e. you can compare the original arrangement after copying). I recommend a custom dimension, all it needs to do is act as a clipboard. Put both chunks there, verify integrity, fix as needed, then copy them to their destinations, verify integrity again (this time from the clean copy in the clipboard dimension), fix as needed. Iterate over the area and place blocks by calling canPlaceBlockAt(...) and only placing it if it can go there. This will get all the solid self-supporting blocks first. Then follow up with the remainder. There is no order you can read/write in and avoid having to do this (as torches can attach to any side except underneath). You might still have problems with blocks like doors, tall grass, and falling blocks After pasting blocks into their destination (e.g. the clip board dimension), check for any dropped item entities. If there are any, delete them and validate the copied area with its source. As you haven't copied any entities yet, there shouldn't be any. Do TileEntities last, you'll want to copy the TE data from the source to the destination. Be aware that readFromNBT and writeToNBT encode the TE's position as well, and you don't want to copy that. You may have to manually edit the TE's data. BE AWARE THAT SOME MOD TEs MAY NOT TAKE KINDLY TO BEING MOVED eg any TEs that assume they're part of a network: by moving them and maintaining that data they might not work correctly (I've seen people do things like "this is a village center block, it keeps track of who owns the village and therefor who can edit blocks" which when you move that TE it's now in a different location than where it thinks it should be). Don't copy entities. Teleport them. You don't need to shove them into the clipboard dimension, just swap both sets over to the new locations. Restrict how big of an area you'll allow to be teleported. The upper-limit is probably still pretty big (e.g. radius of 32-64) but the more blocks you're moving the longer it'll take, and you really don't want to take more than a few ms, as spreading the process over multiple ticks will cause problems (entities will move, blockstates can update, etc.)

No attenuation means that it may as well not be a positioned sound: another player won't perceive the effect as a boom-box traveling with the first player, but exactly the same as if the boombox was on their shoulder.

*Facepalm* That is not how you create a git repository.