Gui Syncing with TileEntity[Solved]

[Catwolf]

I've added a generator block into my mod that allows you to heat water to get steam and produce energy from the steam. As far as I can tell, the internal parts are functioning the way they're supposed to, but the gui is getting variables confused when I open it and when variables hit 0. The block is the BlockSteamGenerator and the classes related to it are TileEntitySteamGenerator, ContainerSteamGenerator, and GuiSteamGenerator. here is the github: https://github.com/Esrome/science-mod

Edited February 2, 2019 by Catwolf
Solved

[unassigned]

You have to send packets to the client about the data on the TE.

[Catwolf]

I've added packets to the tile entity and it has done nothing. I don't know if I added the packets wrong, but now the numbers are going wrong for the actual tile entity too, not just the gui.

 

[unassigned]

  On 1/31/2019 at 3:27 AM, Catwolf said:

numbers are going wrong for the actual tile entity

Expand  

As in your not getting expected results? Step through your code and see what's happening, it might just be a logic error.

To check for sync, you can compare values display in the gui vs values found in the TE.

 

[Catwolf]

I've searched it line by line multiple times looking for errors, but all I've been able to do is make it to where only the gui is glitching. I don't know what isn't syncing, but for some reason the gui gets very confused when steam hits zero or when you open it. The tile entity is fine, I tested it with the console, but the gui is broken.

[Cadiboo]

Have you tried debugging your code?

[V0idWa1k3r]

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/blocks/containers/ContainerSteamGenerator.java#L54

You don't need al this get/setField IInventory nonesense. Just access your fields directly.

 

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/blocks/containers/ContainerSteamGenerator.java#L74

I think you have a typo here.

 

You also need to send the initial state of the fields in Continer#addListener.

 

Unrelated but still issues that need fixing:

 

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/blocks/BlockBase.java

You don't need this, there is already a BlockBase, it's called Block. By using this you are prohibiting yourself from extending other Block subclasses and minecraft uses quite a lot of instanceof checks. Use utility methods instead.

 

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/energy/ElectricityStorage.java

Why can't you just use EnergyStorage if all your overridden methods default to super implementation anyway?

 

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/util/IHasModel.java

IHasModel is stupid cargo-cult programming. All items need models, no exceptions, and nothing about model registration requires access to private/protected data. Just register your models directly in the ModelRegistryEvent. 

 

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/proxy/ClientProxy.java#L9

This makes zero sense. Your client proxy can't extend your server proxy. Proxies exist to separate sided-only code. A server proxy either provides noop implementations for client-only methods or runs code that would crash the client. Extending it like this will crash your client if you at one time will use the server proxy to do something server relater.

 

https://github.com/Esrome/science-mod/blob/master/1.12.2/src/main/java/esrome/scienceMod/init/ModBlocks.java#L20

Don't ever instantinate your stuff in static initializers. Static initializers remove your ability to control loading order and may cause all sorts of issues. Instantinate your stuff directly in the appropriate registry events.

[Catwolf]

I managed to solve the problem via the removal of a large section of code from the container. Thanks for all your suggestions!