Draco18s

Yes. Good job. Tell the moderator the rules.

You see where it says = new Thing()? Remove = new Thing()

Any time the TE data changes and you want to update the client, call these methods: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L95-L98 And have these methods overridden https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L174-L189

Block are registered before items. Therefor this line: https://github.com/InterdimensionalCat/ModTest/blob/master/java/com/benthom123/test/proxy/CommonProxy.java#L87 Runs before this line: https://github.com/InterdimensionalCat/ModTest/blob/master/java/com/benthom123/test/proxy/CommonProxy.java#L70 Which means that this line: https://github.com/InterdimensionalCat/ModTest/blob/master/java/com/benthom123/test/blocks/CopperOre.java#L32 Assigns the CURRENT VALUE of the field (which has not yet had the ObjectHolder annotation run to inject a value) to the block's field. Also: https://github.com/InterdimensionalCat/ModTest/blob/master/java/com/benthom123/test/ModItems.java#L36 Seriously? NO, BAD MODDER. DO NOT ASSIGN THESE FIELDS MANUALLY. ESPECIALLY NOT WITH A SEPARATE INSTANCE

Caused by: com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Expected name at line 19 column 6 path $.variants

Look at BlockLogsOld and BlockLogsNew

You should not be doing this.

The parameter to BlockStateContainer's constructor already takes an IProperty[] array, so use array operation magic.

new BlockStateContainer({ A, B, C, D, E, F, G, H, I, J, K, L})

Caused by: java.io.FileNotFoundException: poverhaul:models/block/camp_fire.json

By "inefficient" you mean "built into the TE class all you have to do is override three methods" right? One of which is literally called getUpdateTag and returns an NBTTagCompound

4) In that case, IBattery should extend IChargable or you have to interfaces IChargable and IDrainalbe (or whatever) and a battery just implements both. But in any case, you should really learn to use capabilities. It really isn't that difficult. This is pretty much all you need: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/capability/RawMechanicalPowerHandler.java Only instead of IMechanicalPower you'll use whatever the interface is that Forge supplies for Energy. You'd then set up some kind of object for the energy storage (look at the ItemStackHandler for inspiration on how to handle it) and then supply that object instance via getCapability. You might need this, I'm not sure: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/capability/SimpleCapabilityProvider.java

https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/farming/entities/TileEntityTanner.java#L174-L189

Thing I noticed as I was perusing your code to see what it does: 1) Why are you asking an item stack what the charge time is when sending energy to a TE? https://github.com/44tim44/BetterThanElectricity_1.12.2/blob/master/src/main/java/se/sst_55t/betterthanelectricity/block/solarpanel/TileEntitySolarPanel.java#L62 2) Why are you allowing for a null item stack? Item stacks are never null in 1.12 https://github.com/44tim44/BetterThanElectricity_1.12.2/blob/master/src/main/java/se/sst_55t/betterthanelectricity/block/solarpanel/TileEntitySolarPanel.java#L85 3) Not that getItemChargeTime gives a shit about the item passed to it anyway... 4) Why is IBattery not an IChargable? https://github.com/44tim44/BetterThanElectricity_1.12.2/blob/master/src/main/java/se/sst_55t/betterthanelectricity/block/solarpanel/TileEntitySolarPanel.java#L36 These two interfaces even supply the same method: https://github.com/44tim44/BetterThanElectricity_1.12.2/blob/master/src/main/java/se/sst_55t/betterthanelectricity/block/solarpanel/TileEntitySolarPanel.java#L45-L51 5) Why are you using Interfaces at all? This is why capabilities exist. Forge has even supplied a capability definition for Energy. 6) This else return false is extraneous. https://github.com/44tim44/BetterThanElectricity_1.12.2/blob/master/src/main/java/se/sst_55t/betterthanelectricity/block/solarpanel/TileEntitySolarPanel.java#L121 7) This boolean does nothing https://github.com/44tim44/BetterThanElectricity_1.12.2/blob/master/src/main/java/se/sst_55t/betterthanelectricity/block/solarpanel/TileEntitySolarPanel.java#L42

Ok, I misread at first. I thought you said you couldn't see the value updating. One minute...

My immediate guess is that you are synchronizing the value to the client.

Let me break this down for you: The server is responsible for EVERYTHING except rendering and user input. The client is responsible for rendering and user input. Which side would it make sense to do things on?

Either: A) I don't understand the question or B) That's only a question you can answer. What side do you WANT to add/set/get/remove energy?

Hmm. My mental model must be out of date. I just checked and I'm running stuff through my proxy as well. Never mind.

That's what new topics are for. That are "trying it and seeing." But yes.

*Opens his IDE* *Copy-pastes the code* *Looks at the Javadoc attached to the function* *Finds the answer* Use MinecraftForge#EVENT_BUS instead, they're the same thing.

You need to create the storage in the readFromNBT method, once you know what the capacity and transfer speeds are.

NPEs are easy to solve if you have a stack trace as it tells you exactly what line it occurred on. However, I do not have that information.

No. getRegistryName() does not need the substring(5) bullshit that using getUnlocalizedName() does.

Why you would ever have to pass that through your proxy, I don't know. You already know which side it's on as packets should only go one way: it's sent from the server to the client, the packet handler therefor only exists on the client and it's safe to use Minecraft.getMinecraft() Likewise, going the other way.