desht

After you get the block below the entity, first check if the block above that is farmland, and if so, use that block instead. Alternatively, get the blockpos one block below the entity's position with a small positive Y offset.

I'd put an IDE breakpoint on the line of code that's being unexpectedly hit (this.entityWorld.playEvent....) and find out what the blockstate actually is there (and verify that the blockpos is what you expect it to be, i.e. the block the entity is standing on).

Yeah, it'll just get ignored by the client.

setEntityState() sends out a SPacketEntityStatus to tracking clients - the magic byte is handled in NetHandlerPlayClient#handleEntityStatus() for a couple of values, otherwise forwarded to Entity#handleStatusUpdate(), which is a method overridden many times by subclasses of Entity. The opcode 10 appears to be handled by EntitySheep, setting the entity's (clientside) grass eating timer to 40 ticks. I haven't done an exhaustive search, but I doubt any other vanilla entity subclasses use it. It looks like it just controls the sheep's head animation as it leans down to eat.

If the data is only needed client-side for GUI display purposes (as opposed to block rendering purposes), you could just have that custom packet sync the necessary data and trigger the GUI opening client-side. If you do it this, you might also need a way to update any already-open GUIs if any data changes server-side (that's dependent on how you intend your GUI to work). If the data is also needed for block rendering, it needs to be sync'd in some other way whenever it changes server-side. Either via vanilla-style TE syncing (getUpdatePacket() / onDataPacket()) or - preferably - via a custom packet.

I propose adding a "3. LEARN TO USE YOUR IDE's DEBUGGER!" entry under General Issues in your Common Issues / Recommendations post. @MyRedAlien43seriously, the debugger is a lifesaver. Modding without it is like trying to run with your shoelaces tied together.

If you need to open a containerless GUI from the server side, you'll need to send a custom packet to the client. But if you're doing this from onBlockActivated(), is there a reason you can't just open the GUI if called client-side (maybe you want to do some server-side validation first, I haven't examined your code too closely) ?

You should take a careful read of the 1.12 -> 1.13/1.14 update primer linked at the top of this forum. In particular, this comment will be helpful to you: https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a#gistcomment-2870154 Regarding your original problem (TE data not saving), are you marking the tile entity dirty when the inventory changes? If not, your changes won't get saved. Best bet is to override the onSlotChanged() method of your ItemStackHandler object to call te.markDirty().

Also worth mentioning that the MBE04 approach linked above won't work in 1.13.2 at all, since extended blockstates are no longer a thing. However, this PR just got merged: https://github.com/MinecraftForge/MinecraftForge/pull/5564, which is great.

Fair enough. Still makes me uneasy though... I've had too many experiences with dependency hell in the past, Forge or otherwise

See https://mcforge.readthedocs.io/en/latest/tileentities/tileentity/#synchronizing-the-data-to-the-client Personally, I'd go with a custom packet - NBT is a poor format for network communication (overly verbose), and a custom packet will be more efficient in terms of network traffic. Also, I noticed you're using a PropertyInteger for your block's facing - why?? There's a builtin PropertyDirection class for exactly this (look at BlockFurnace for an example of a horizontally-constrained rotation, or BlockDispenser for an example of an unconstrained rotation). That would allow you to ditch that disgusting code in onBlockPlacedBy().

Even that is horrible. OP, just list Baubles as a required dependency on your mod and be done with it. Ensuring that the right dependencies are present for your mod is a job for modpack authors, not mod developers.

Yeah, Botania uses it for the mana pump and corporeal crystal. The code is all available for perusal on github.

What on earth is this for? if(stack == new ItemStack(this)) And why do you keep trying to compare damage > 1 ? What do you think that's achieving? All you need to do is clamp the item's damage value between 0 (undamaged) and item.maxDamage() (fully damaged, just before breaking) inclusive. By the way, you should be testing your code (and ideally running it through your IDE's debugger when it fails) rather than just inventing snippets to post here.

No, you want to check that damage <= item.getMaxDamage() before you update the item's damage. Remember that the item damage increases as it becomes more damaged.

Then override Item#setDamage(ItemStack, int) for your item. In your overridden method, just make sure that the stack's item damage never exceeds its max damage, and the item won't break.

No, he's the author of some code to unbind the TESR, not the author of Bonsai Trees. But looking at the github issue, the Bonsai Trees author is looking into the performance issues. @DavidM The unbinding code looks fine on the face of it, having looked at TileEntityRendererDispatcher, but I'd recommend testing it with Bonsai Trees and as many other mods as is feasible.

Personally I'd go with the entity, no questions asked. Since you're shooting the fireball anyway, it sounds like the perfect candidate for something that extends EntityProjectile. You'll get all the shooting/collision logic for free, as well as not needing to do any manual rendering, transformations, etc.

Don't call World#getTileEntity() directly from getActualState() (or getExtendedState()), or you could end up with mysterious crashes and other flakiness. Read the warning section here for a full explanation of why: https://mcforge.readthedocs.io/en/latest/blocks/states/#actual-states A safer version (for use by getActualState()/getExtendedState()) looks like this: public static TileEntity getTileEntitySafely(IBlockAccess world, BlockPos pos) { return world instanceof ChunkCache ? ((ChunkCache) world).getTileEntity(pos, Chunk.EnumCreateEntityType.CHECK) : world.getTileEntity(pos); }

I suspect you're not including your mod name when you register those blocks; your calls in the event handler certainly don't include the mod name, but that goes through a few levels of utility methods which I don't feel like tracing via web browser. To be certain, debug with your IDE and set a breakpoint in your code where you call Block#setRegistryName() and check what you're passing there. It should look like "modid:blockid", not just "blockid".

Oh FFS. I wrote yesterday: The updated method name for EnumFacing.getHorizontal() is EnumFacing.byHorizontalIndex().

byIndex() might seem to work, but it is not the method you want. I gave you two options for possible replacements for EnumFacing.getHorizontal() but you seem grimly determined not to pick the obviously correct one. As for the "invalid source release" error, not sure, but what JDK version are you using in your project?

The error tells you exactly what the problem is. getHorizontalIndex() is not a static method. It's also not the method I pointed you toward in my last post.

There's no need to download MCP or do any decompiling yourself for normal mod development. That's all handled for you (by the gradle setupDecompWorkspace task, for example). Minecraft, as it's shipped by Mojang, is obfuscated, which means that all those class names, field names and method names which make perfect sense in your dev environment (like EnumFacing.getHorizontal()) are replaced with unreadable symbols like xyx.a() (note - that isn't the actual mapping for EnumFacing.getHorizontal()). To make modding possible, MCP is a project which maps all those unreadable names to the ones that make sense to humans. So when you run setupDecompWorkspace, ForgeGradle uses MCP and related tools to de-obfuscate the Minecraft code, and make the readable names available to your IDE so you can code against it. When you build your mod (with the gradle build task) your code is reobfuscated so that when you ship your mod to be run against shipped (and obfuscated) Minecraft instances, it works. The mappings do change and evolve, and when you update your mappings, it's possible that some of your code will no longer compile because it's referencing old mappings. In this case, you hit this problem with EnumFacing.getHorizontal(). A little investigation is often all that's needed; find methods in the class with the same signature for a start, and use some intuition to figure out which method might be the replacement for the old one. In this case, there are only two static methods in EnumFacing which take a single int parameter and return an EnumFacing: byIndex() and byHorizontalIndex(). I'll leave it to you to figure out which one of those replaces getHorizontal()

Check on both sides: on the client so you're not sending unnecessary packets, and on the server because rule #1 of multiplayer gaming is don't trust the client.