lyn mimistrobell

It seems there are a number events/methods used when a block is placed: canPlaceBlockOnSide getStateForPlacement onBlockPlacedBy Are there any more? Are these always called in this order? I have a block where I want to remember the TE against which the block was placed - let's call it targetTE - (so it can act as an interface to that targetTE). I implemented canPlaceBlockOnSide to verify that the user actually clicked a TE and not a regular block; e.g. it returns false if you try to place the block against dirt but true if you place the block (shift-click) against a chest. I implemented getStateForPlacement to rotate my block the correct way to face the targetTE. I believe both methods are called before the block is actually placed. I also implemented neighborChanged to break (and drop) my block if the targetTE is removed. Which method would be the best method to store the targetTE? onBlockPlacedBy doesn't provide the EnumFacing I need to find the block (and TE) the user clicked. Should I store the targetTE or determine it every time I need it (using my blocks PropertyDirection) - which may be every tick? I couldn't find any documentation on the order of events for placing a block - is there any?

Wow I totally missed that it's parsing the NBT to a new local ItemStack and then ignores it... thanks.

I did add more debugging and found the issue is with ItemStack.deserializeNBT which doesn't handle the NBT (created with ItemStack.serializeNBT) properly (created a separate topic for that). I use Eclipse Neon 2 and I know how to set breakpoints (unfortunately, they didn't help for this problem) - I didn't think use the property as watchpoint but I'll do that next time. Thanks.

ItemStack: public NBTTagCompound serializeNBT() { NBTTagCompound ret = new NBTTagCompound(); this.writeToNBT(ret); return ret; } public void deserializeNBT(NBTTagCompound nbt) { // TODO do this better while respecting new rules final ItemStack itemStack = new ItemStack(nbt); this.stackTagCompound = itemStack.stackTagCompound; this.capNBT = itemStack.capNBT; } So effectively, that's what those methods already do...

I have an ItemStack with a single piece of e.g. coal; when I call itemStack.serializeNBT I get: {id:"minecraft:coal",Count:1b,Damage:0s} When I then try to deserialize the tag I get: 1xtile.air@0 I found that deserializeNBT calls new ItemStack(compound); it calls Item.getByNameOrId("minecraft:coal") which returns 1xitem.coal@0. For some reason, this fails and causes ItemStack to have 1xtile.air@0 : this.item = Item.getByNameOrId("minecraft:coal"); This works, however: itemStack = new ItemStack(Item.getByNameOrId("minecraft:coal")); Am I doing something wrong calling nbt.setTag("mystack", itemStack.serializeNBT()); and itemStack.deserializeNBT(tag.getTag("mystack")); ?

Hi, For my mod I created a custom Capability that handles fuel burning (initial burn time, remaining burn time, etc.): My TE calls setFuelItem with an ItemStack that has coal; the log shows that the coal was accepted: [18:32:02] [Server thread/INFO] [RadioTools]: [TileEntityFurnaceGenerator.update] fuelItemStack: 1xtile.blockCoal@0 [18:32:02] [Server thread/INFO] [RadioTools]: [FurnaceGeneratorHandler.setFuelItem] fuelItem: 1xtile.blockCoal@0 [18:32:02] [Server thread/INFO] [RadioTools]: [FurnaceGeneratorHandler.setFuelItem] this.fuelItem: 1xtile.blockCoal@0, initialBurnTime:200 Next, sendBlockEntity calls TE.getUpdatePacket which calls TE.getUpdateTag which tries to get the NBT of my Handler, but for some reason this.fuelItem was reset: [18:32:02] [Server thread/INFO] [RadioTools]: [FurnaceGeneratorHandler.serializeNBT] this.fuelItem=0xtile.air@0 [18:32:02] [Server thread/INFO] [RadioTools]: [FurnaceGeneratorHandler.serializeNBT] tag={remainingBurnTime:200,fuelItem:{id:"minecraft:air",Count:0b,Damage:0s}} The only places where I expect the fuel to be updated are setFuelItem and decreaseRemainingBurnTime when it finished burning but that doesn't happen until 10 seconds later: [18:32:12] [Server thread/INFO] [RadioTools]: [FurnaceGeneratorHandler.decreaseRemainingBurnTime] Finished burning I'm probably missing something obvious but I right now I'm blinded and I can't find it... The only other logging was from the client which (of course) deserialized a tag with fuelItem air; deserializeNBT is never called on the server. Full log: Anybody with good eyes? Linda

Hi, It's my understanding that one of the key benefits of the Capability system is that other mods can provide the Capability you designed - is that right? So far I've discovered that Forge provides Capability<IAnimationStateMachine>, Capability<IEnergyStorage>, Capability<IFluidHandler>, Capability<IFluidHandlerItem> and Capability<IItemHandler>. I suspect many people have created their own Capabilities by now and I'm sure some (almost) duplicate Capabilities exist out there. Perhaps we should be sharing and documenting Capabilities rather than each invent our own. For example, I created Capability<IFuelHandler> which provides basic furnace functionalities related to remainingBurnTime, initialBurnTime, etc. I can imagine a number of implementations; e.g. one that provides the vanilla Furnace implementation, one (that I made) that provides higher burnrates (with more FE/t) for "higher" fuels (coke, buckets of lava, etc.), etc. Is there any kind of sharing for Minecraft (other than bitbucket) "snippets" like Capabilities, GUI helpers (haven't we all made one?), etc.? Linda

I found the problem; my writeToNBT method didn't call super.writeToNBT so the TileEntity class never stored my TE's id.

I've implemented: - getTileEntityClass - getTileEntity - hasTileEntity (returns true) - createTileEntity(world, state) (though deprecated) - createTileEntity(world, meta) (though deprecated) My Block and TE class have a constructor without parameters. One thing that bugs me is that all registrations happen through event.getRegistry; except for the TE registration which uses GameRegistry.registerTileEntity - seems inconsistent.

I provided all the relevant code... In the log I see it does: - preInit (on Client) - RegistrationHandler.registerBlocks (on Client) - GameRegistry.registerTileEntity (on Client) - RegistrationHandler.registerItems (on Client) - RegistrationHandler.registerItems (on Client, for the models) - init (on Client) - postInit (on Client) Then when I right-click my block: - onBlockActivated (on Server) - TE.onLoad (on Server) - TE.onLoad (on Client) Anything unexpected here? The block itself is registered on RegistrationHandler.registerBlocks; is that a problem?

I'm having the same issue and I'm wondering about the different events that are being used. My main class implements: @Mod.EventHandler public void preInit(FMLPreInitializationEvent event) @Mod.EventHandler public void init(FMLInitializationEvent event) @Mod.EventHandler public void postInit(FMLPostInitializationEvent event) It also defines this class @Mod.EventBusSubscriber public static class RegistrationHandler implementing these methods: @SubscribeEvent public static void registerItems(RegistryEvent.Register<Item> event) @SubscribeEvent public static void registerItems(ModelRegistryEvent event) @SubscribeEvent public static void registerBlocks(RegistryEvent.Register<Block> event) I got this from some tutorials and I was under the impression that the RegistrationHandler was the new preferred implementation. I tried this in both the preInit and the registerBlocks events: GameRegistry.registerTileEntity(MyTileEntity.class, "mymod:my_tile_entity") And still my TE doesn't trigger onLoad until I right-click the block to open the GUI. Previously I had seen some "Skipping BlockEntity with id " (and no id was printed there) which leads me to believe my TE's weren't storing their NBT but after moving the registryTileEntity to preInit that error is gone. 1. What is the preferred implementation for the registration events; in which event should I register the Block and the TE? 2. Why is my TE not loaded on world load?

I want an ITickable class to keep track of and regularly update multiple blocks and possibly items; serverside. It shouldn't be dependent on things like chunk loading and actually I actually don't event want an inworld block for it. Is there a recommended way to imlement this? Can I use a TileEntity and can I just initialize this in my mod postInit? Would it be able to store NBT data?

I found it to be the best way without the need to expose new methods (requiring me to cast the TE to my own TE class). I didn't feel like doing this just for the IItemHandler issue but I suspect a Progress capability can will be useful more often.

I was able to get it working with the facing option (of course, it restricts me to 6 IItemHandlers but for now I just needed 3 anyway). I feel it's a hack/workaround and not a proper solution tho... I did create a custom capability for my furnace progress. The vanilla furnace uses IInventory which offers getField and setField, I feel that's missing from the standard capabilities; perhaps I'll create a generic IStorage<IProperties> capability to offer generic properties handling to any TE... For now, I created a Progress capability (with minValue, maxValue, value and a method to get actual progress) that my TE sets to 0, initialBurnTime, remainingBurnTime and from which my Gui calls getProgress(34) (my progress bar is 34 pixels). Am I correct that every custom capability needs all this? - Capability interface (ICapabilityProgress) - Capability class (CapabilityProgress implements ICapabilityProgress) - Serializer (CapabilityProgressProvider implements ICapabilitySerializable<NBTBase>) - Storage class (CapabilityProgressStorage implements IStorage<ICapabilityProgress>)

Clever, thank!