Choonster

ItemStack capability syncing has been discussed quite a lot in GitHub issues (e,g, here and the issues/PRs linked by it), but there's no real resolution yet. One method of syncing that works fairly well is a custom IContainerListener, as described in this thread. I recently implemented this for my mod's item capabilities here. One issue with this is that an item's capability data is completely reset when taking it out of the creative menu.

It doesn't look you have access to the LootTableManager from LootTableLoadEvent. Since the event gives you the option of replacing the LootTable with another one, it probably should give you access to the LootTableManager. You could suggest this be changed, but in the mean time you can remove the LootTable's existing LootPools and then add a new one with a LootEntryTable in it that references the replacement LootTable.

I can't see any obvious issues from a quick skim of your code, so I suggest you set some breakpoints and step through the code in the debugger to figure out exactly what's happening and where and why it's failing.

The ForgeData tag has never been automatically synced. If you want the data available on the client, you need to sync it yourself. That said, you shouldn't need it on the client. Cancelling EntityJoinWorldEvent on the server will prevent the entity from being sent to the client at all.

The type argument of your IStorage implementation must be the interface you register the capability for (IThirst), not an implementation of it (Thirst).

Minecraft doesn't really have the concept of books, it just has several items that are called books and are indirectly related to each other. The only way to achieve this is with a whitelist of book items and an API to add items to the whitelist.

You can get an entity's bounding box with Entity#getEntityBoundingBox and then use AxisAlignedBB#intersects(double, double, double, double, double, double) to check if it intersects with the region's coordinates. This is essentially what World#getEntitiesWithinAABB does for every entity in the chunks covered by the AABB.

Store the player in a field of the Money class.

I don't think there's any other way than checking every tick, but doing it per-player may be less expensive than using World#getEntitiesWithinAABB.

One alternative would be subscribing to PlayerTickEvent and checking if the player is in the region before teleporting them back. This probably has fairly minimal overhead, but you should profile it to check.

ItemLayerModel is the class that generates item models, either use this or look at how it generates quads from textures. You may not actually need a TESR, you may be able to achieve what you want with a baked model generated at runtime.

"Ticking entity" is just a generic message used for any crash report that happens when an entity is being ticked. It doesn't say anything about what caused the crash report. If your code is crashing, post the crash report (or read it yourself and figure out why it's happening).

Call Capability#getStorage on the IEnergyStorage Capability instance to get its IStorage instance, then call IStorage#writeNBT and IStorage#readNBT to write an IEnergyStorage to/read it from NBT. You can get the Capability instance from the CapabilityEnergy.ENERGY field or create your own static field and annotate it with @CapabilityInject(IEnergyStorage.class).

Because IStorage is an unrelated interface for reading capabilities from and writing them to NBT. Use Capability#getStorage to get the IStorage of a Capability.

The first search result for "System editor can only open file base resources" was this thread, where diesieben07 explains how to fix this.

The IStorage for the IEnergyStorage capability simply saves the stored energy as an NBTTagInt. Either use the IStorage or do the same thing yourself. You can still use IContainerListener#sendProgressBarUpdate and Container#updateProgressBar to synchronise numeric data like stored energy and progress, you just can't use IContainerListener#sendAllWindowProperties. Alternatively, you can use your own packets.

Use World Capabilities or World Saved Data, either per-map or per-dimension as needed. You can see how RFTools stores its telerporter destinations here.

Don't. If you solved your problem, post the solution so other people can find it when they have a similar problem.

I think you're translating to the wrong position. AnimationTESR sets the translation to the coordinate arguments minus the TileEntity's coordinates, you're setting the translation to the TileEntity's coordinates.

Use a custom IRecipe implementation.

Create your own copy of the ItemStack#damageItem method without the creative mode check.

You mentioned an ore recipe, but you didn't mention that the ingredient was an ore dictionary entry. In that case, you need to use OreDictionary.WILDCARD_VALUE when adding your item to the ore dictionary.

You're probably using 0 as the ingredient's metadata when adding the recipe, so only metadata 0 is accepted. Use OreDictionary.WILDCARD_VALUE to accept any metadata value.

That's not what Draco told you to do. You damage the ItemStack, but then you return the result of the super method (a completely separate ItemStack). The original ItemStack that you damaged is ignored. You need to return the ItemStack that you damaged.