Hi there,
 

I'm currently creating a block called a Mixer. Its task is to mix different ingredients. So far, I have created my own Recipe system and so on.
Everything works, except the progression bar in the GUI. I have tried different methods, such as give GUI class access to my TileEntity to receive the values (mixTime & currentMixTime),
however, it did not work. I have looked into the 'Furnace' and it seems to use an interface (IInterface) to send the different fields. Do I have to use that as well?

What do you mean by 'it did not work'? What happens that's different from what you want/expect?

1 hour ago, Jay Avery said:

What do you mean by 'it did not work'? What happens that's different from what you want/expect?

I expected, that the Gui would take the values from the Tile Entity and calculate the percentage to display the process, but it stayed the same, zero.

Sounds like a problem with server/client syncing. Assuming you do your main TE behaviour on the server side (!world.isRemote) as recommended, you'll need to send packets to the client whenever the values that need to be displayed are changed. The forge docs cover the basics of using packets which should get you started.

4 hours ago, Jay Avery said:

Sounds like a problem with server/client syncing. Assuming you do your main TE behaviour on the server side (!world.isRemote) as recommended, you'll need to send packets to the client whenever the values that need to be displayed are changed. The forge docs cover the basics of using packets which should get you started.

Thanks. I will look into it and give it a try :).

Okay, I tried to look into it this morning, but I'm lost. Where should I add the packets and so on? Inside the Tile Entity?

A bit more help will be appreciated!

Edited May 29, 20178 yr by RaxiCax

First you need to create and register a packet according to the docs. The packet should contain the position of the TE and the data that needs to be updated, and the handler should process the packet by updating the TE at the given location with the given data. Then inside the TE, when the data changes that needs to be displayed on the GUI, you send a packet. It only needs to go from server->client, so check for !world.isRemote (sending from the server), then create a packet and sendToAll (every client needs to have their TE information updated).

 

Here is an example from my mod:

• Here is the method where I send the packet, inside the TE.
• Here is the class where I register packets and network channel.
• Here is the packet and handler.

As far as I am aware you do not need packets if you only want to see things changing in the gui. See how it is done in vanilla's classes, for example in ContainerFurnace (the methods that interest you are addListener, detectAndSendChanges and updateProgressBar). Vanilla uses get/setField that you should not have unless you are implementing IInventory which you should not do, but they are only a level of abstration, you can still send/recieve any numeric data you want with IContainerListener::sendProgressBarUpdate and Container::updateProgressBar. The only thing that changes is that you can't use IContainerListener::sendAllWindowProperties... but you can still send everything using sendProgressBarUpdate.

 

Although custom packets will obviously work too, they are just a bit more complicated

Personally I use custom packets more because I find it easier to understand what's going on when I've created it from scratch, rather than adapting vanilla things.

51 minutes ago, V0idWa1k3r said:

As far as I am aware you do not need packets if you only want to see things changing in the gui. See how it is done in vanilla's classes, for example in ContainerFurnace (the methods that interest you are addListener, detectAndSendChanges and updateProgressBar). Vanilla uses get/setField that you should not have unless you are implementing IInventory which you should not do, but they are only a level of abstration, you can still send/recieve any numeric data you want with IContainerListener::sendProgressBarUpdate and Container::updateProgressBar. The only thing that changes is that you can't use IContainerListener::sendAllWindowProperties... but you can still send everything using sendProgressBarUpdate.

 

Although custom packets will obviously work too, they are just a bit more complicated

3

 

49 minutes ago, Jay Avery said:

Personally I use custom packets more because I find it easier to understand what's going on when I've created it from scratch, rather than adapting vanilla things.

1

1

The idea from @V0idWa1k3r seems to be a lot easier, but the technique with custom packets is more understandable when you know how the packet system works.
Right now, the packet system is really confusing, so I will try the vanilla one first.

 

By using the method from Void, it works! Hopefully, in the future, I can switch to packets. 

Edited May 29, 20178 yr by RaxiCax
SOLVED