Cobra111783

Cool. I just wanted to make sure that was the best way to handle things with capabilities (since I'll have to copy the "current energy" from the EnergyStorage into the trackedIntArray whenever it changes). Thanks! 🙂

I currently have a block that uses the Forge Energy capability (via EnergyStorage). I want to display a power bar on the UI, but otherwise don't need the energy level on the client-side. I was doing this by syncing the TilleEntity's energy level, but this seems like a lot of unnecessary network traffic. My current thought is to used a trackedIntArray to store a copy of the current energy level and pass that (through the container) to the client's screen. Is this the best way to do this kind of syncing, or is there a more efficient way that is recommended?

That's much cleaner! Thanks! 🙂 Updated solution for future knowledge-seekers: ServerLifecycleHooks.getCurrentServer().execute(() -> { [YOUR TASK HERE] });

Switching to enqueueing it on the server (vs client) fixed it. Thanks for your help! For anyone else looking for the solution, I used something like this: var server = ServerLifecycleHooks.getCurrentServer(); server.enqueue(TickDelayedTask(server.getTicketCounter(), () -> { [YOUR TASK HERE] })); (See below for better solution)

Hrm... I hadn't considered thread safety on MC's end... (derp!) Thanks for the clarification! Is there a built-in mechanism to schedule a task to occur inside the main thread? I thought that's what Minecraft.getInstance().enqueue(...) was supposed to do, but maybe I'm misunderstanding the correct uses of that method (since it appears to run things inside a rendering thread).

I need to retrieve a TileEntity from another thread. I have the BlockPos of the entity, as well as the appropriate ServerWorld. However, I keep running afoul of this line in net.minecraft.world.World (line 639): } else if (!this.isRemote && Thread.currentThread() != this.mainThread) { return null; } (Specifically, it's detecting that the current thread isn't the main thread) I've also tried variations of this with no luck (Kotlin code): val queue = SynchronousQueue<TileEntity>() Minecraft.getInstance().enqueue { val tileEntity = dimension.getTileEntity(BlockPos(destination.x, destination.y, destination.z)) queue.put(tileEntity) } val tileEntity = queue.take() However, this seems to run on a rendering thread rather than the "main" thread. Is there any way to get a TileEntity from another thread? (FYI, the part of TileEntity in that I'm planning to access uses thread safe code, so I'm not concerned about that part of the equation.) (Side note: Just getting the TileEntity from the ServerWorld worked in 1.12, so I'm guessing that "safety check" is new...)

Excellent! Thanks again for the assistance! 🙂

Thanks for the info! What's the correct way to get the MinecraftServer instance? I see a lot of references online to FMLCommonHandler.instance().getMinecraftServerInstance(), but that doesn't seem to exist anymore.

I'm currently trying to pick up my mostly-completed 1.12 mod and update it to 1.16. As part of the mod, you can send a package to a destination using coordinates (dimension name + x/y/z). In 1.12, I retrieved the target world via this code: var dimension = DimensionManager.getWorld(destination.dimension) And then retrieved the tile entity at the target location via: var tileEntity = dimension.getTileEntity(BlockPos(destination.x, destination.y, destination.z)) However, so far I have been unable to find a replacement in the 1.16 API for the DimensionManager.getWorld call. Can anyone suggest a way to look up a world via its name?

That works! Thanks!

I'm trying to build an inventory that has an inventory where one slot can only be emptied via the GUI, but it can be inserted into by the GUI or other process (e.g. hopper). There is also a second slot that can be interacted with normally. Is there a preferred way to do this? The only solution I've come up with so far is to have two ItemStackHandlers that share the same backing NonNullList<ItemStack>, but that seems to cause strange client/server desync issues.