[1.8.9] I need some explanations about tile syncing

[Ermans]

Hello, I have some questions about these way to sync data.

 

1) Custom Packets

    a. I shouldn't use them for update values in the GUIs, rigth?

 

2) BlockEvents

    a. On which side should I call them?

    b. Are they a good way to update values in the GUIs?

    c. Now I know this: World#addBlockEvent (called server-side) fires Block#onBlockEventReceived (both sides) and here I have to call TileEntity#receiveClientEvent (both sides) and update values.      It is right?

 

3) IInventory Fields

    a. Are these the better way to update values in the GUIs?

    b. Why these methods are on the IInventory interface instead of an ISyncable or something like this?

 

So, what should I choose to sync values in the GUIs?

 

Thanks

 

 

[Ernio]

It would be MUCH better if you could describe what are you after.

 

1.a. Packets as in IMessage and PacketHandler can be used to do anything for any side. That includes GUI updaes, Tile updates, Entity update, etc. You can even send configs and global-like data (e.g on client connection).

This covers how to deal with them: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html

 

2.a. "Block Events" is a VERY wide term. There are "events" as in methods inside Block.class which you can override when making YOUR OWN blocks. Most of them will be called on both sides - you can use if(!world.isRemote) to execute them only on server.

I higly recommend reading this, before continuing:

http://mcforge.readthedocs.org/en/latest/concepts/sides

As to "actual" Events - Forge Events - we are talking about @SubscribeEvent annotation. Those are fired for any blocks.

Again - there are a LOT of different Block-based events. You need to be more specific.

Most of them, again - fire for both sides. If you want to make them run only on server thread - you again use if(!world.isRemote).

 

GENERALLY: All data manipulation can only ever happen on server. Client should only ever display stuff (eventually modify it for display purposes) or send requests/actions to server.

 

2.b. Values anywhere including GUI can be updated in literally any way. If the event is fired on both sides and you expect outcome to be exacly the same - you can freely use those actions to update gui. Just note - client has no access to actual data - what client only does is display, so if outcome of event will vary depending on side (server or client) you need to update client from server - and that you do with packets.

 

2.c. Well, this thingy has not very wide range of uses. Sure - whatever works for you. Again - remember that server is the one that should manipulate data.

 

3.a. Again - GUI values can be updated by anything. Most of dynamic updates will simply NEED you to have custom IMessage. Then you can (from handler class) access currently opened screen and change values.

Big note:

http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html

 

3.b. What methods? Are you talking about those shits that seem like they are used for syncing? Well - they are not (at least not if you don't make them to). Generally - IInventory is quite useless for mods (it lacks compatybility and is really just failed interface in my opinion).

Note: As of 1.8.9 Forge has new Capability system:

http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/

Use this is favor of any IInventory implementation (or actually any other).

 

"So, what should I choose to sync values in the GUIs?"

I recommend IMessages mentioned earlier.

 

Lemme just stress this out: It would be MUCH better if you could describe what are you after.

[jeffryfisher]

IIRC, Forge's wrapper calls events, and our mods subscribe to (handle) them. If you're thinking about calling (firing) events, then you're either way more advanced than I, or else you're asking for trouble.

 

For starter tile entities, just writing a useful pair of NBT methods (override the read & write) and marking a tile "dirty" should suffice.

[Ermans]

I need to update values for the GUI (energy bar and progress bar), I already use IMessage for things that need to sync all the clients in a range, but I don't want to use them because I need to send message only to player who have the gui open.

 

About Block Events, I apologize for not being specific, I mean World#addBlockEvent, Block#onBlockEventReceived and TileEntity#receiveClientEvent and I need to know if these methods are a good way to update values in the GUI.

 

About the third question, I mean IInventory#getField,  IInventory#setField and IInventory#getFieldCount. These methods are use by vanilla furnace to update the GUI, I  just wondering why these methods are inside IInventory interface and not in a ISyncable interface or something like this.

[coolAlias]

Those types of GUIs use the Container as an intermediary between the server and the client.

 

If you take a look at the ContainerFurnace class, you will see how it calls the IInventory methods as well as #detectAndSendChanges and another method like #addCraftingToCrafters - the former is the one responsible for updating the GUI values from the TE values, and the latter is one that typically adds players that need to be informed of changes.

 

Ideally, your TE-based Container/GUI combo wouldn't ever need to explicitly send messages or block updates, but would all be handled via the Container.

[Ermans]

Those types of GUIs use the Container as an intermediary between the server and the client.

 

If you take a look at the ContainerFurnace class, you will see how it calls the IInventory methods as well as #detectAndSendChanges and another method like #addCraftingToCrafters - the former is the one responsible for updating the GUI values from the TE values, and the latter is one that typically adds players that need to be informed of changes.

 

Ideally, your TE-based Container/GUI combo wouldn't ever need to explicitly send messages or block updates, but would all be handled via the Container.

 

Thanks, but I already knew that, I was just asking if there was other ways better than vanilla way. I think I will use containers so