[1.7.10] Problem syncing NBT tag compound between client and server

[Roboguy99]

So I have an NBT tag compound I'm saving to an item, and in single player it saves fine. On a server, all of the tags exist but are set to 0. I know this is an issue syncing something properly, despite having a packet.

 

I've tried playing around with many, many things but I can't get it to work properly. As you can currently see, I've tried constructing the NBTTagCompound and sending that in a packet, but it doesn't seem to actually update. At this point I'm out of ideas....

 

Here's the packet: https://github.com/Roboguy99/HotbarBag/blob/master/src/main/java/roboguy99/hotbarBag/network/packet/SettingsUpdate.java

Here's the NBT saving code: https://github.com/Roboguy99/HotbarBag/blob/master/src/main/java/roboguy99/hotbarBag/inventory/BagInventory.java#L265

Here's where the packet is sent from: https://github.com/Roboguy99/HotbarBag/blob/master/src/main/java/roboguy99/hotbarBag/gui/GuiConfig.java#L316

 

If anybody could explain what I'm doing wrong, that would be great. Thanks.

[Roboguy99]

You are approaching this from the wrong direction. Don't let the client tell the server "hey this is the new Item now, kthnxbai" and the server just trusts it. Instead send a packet when e.g. a button is pressed saying "hey, user pressed a button", then the server decides what to do with that information, in that case probably update some NBT on the ItemStack or something.

 

So if I have a bunch of client-side settings variables (see https://github.com/Roboguy99/HotbarBag/blob/master/src/main/java/roboguy99/hotbarBag/Config.java), which are actually set through the user using a GUI, how would I go about doing this? I assume the settings variables should not be client-side, but as they're different for every instance of the mod (depending on a config file), I don't know how to do this.

 

I hope that made sense...

[Roboguy99]

Forge has a config GUI, why are you not using that?

 

My configuration GUI is on a per-item basis, using the configuration file for per-mod-instance defaults. The actual configuration file is not being changed in game.

[Roboguy99]

Right.

You need to send the serverside defaults (!) to the client when the GUI is opened. Then send any changes that the client makes to the server so it can apply them to the Item. Again, do not simply send a new Item, send a request stating "hey I wish to change this setting, please do that".

 

Right, I know that the request from client to server is going to be a packet. Will I send the instance of the GUI to the packet to get the variables, or will this just result in the same problem as before with the client sending data?

 

I'm sorry, I'm getting very confused over this...

[Roboguy99]

Will I send the instance of the GUI to the packet to get the variables, or will this just result in the same problem as before with the client sending data?

Ehm... what.

"send the instance of the GUI" - No. The server sends a specific packet that contains the serverside defaults and also tells the client to open the GUI.

Then client sends back a different packet which contains things like "setting foo is now value bar please". Server then gets player's current Item, checks if it's yours and if so applies the change.

 

Ahh, that makes a lot more sense. Thanks.

I've just had nearly 2 weeks of exams so I'm a bit tired, and so a bit slow at the moment

[Roboguy99]

Ok I think I've still got the wrong idea somewhere, so I thought it makes sense to come back here and ask again before I get way too far into the wrong thing. I've also got a feeling you still haven't 100% understood what I'm trying to do (which is my fault for not explaining it well enough), so here's a picture of my current situation; I'm not ignoring what you've said, I just don't quite have the understanding to incorporate it into the diagram. I hope it's clear enough...

 

 

I've been working on the packet which contains the defaults, and opens the GUI. Hopefully you'll be able to a) Understand what I want with the diagram and b) Agree that I've done something wrong.

 

https://github.com/Roboguy99/HotbarBag/blob/master/src/main/java/roboguy99/hotbarBag/network/packet/SettingsOpen.java

[Roboguy99]

So now you do want the config to be changed? I thought it was only for the default values...

 

There are 2 sets of values.

 

There are the default config values, which every item should start with as its settings. These are read from a config file, and so are on a per-mod-instance basis, allowing each user to have their own defaults.

There is then the item config values, which are loaded/saved from the item using NBT. If these don't exist, the default is used instead.

 

The config file does not need to be changed in game. The server's config file should not be used, as this would stop users from being able to change their own defaults. Obviously the item configs values should be changed and these are what are changed by the GUI.

[Roboguy99]

I do not get your problem then...

 

My problem is that with my current approach, when connected to a server the config values for an item are read as 0, and I'm not sure whether what you previously said still remains correct given the full description of what's going on, or whether I should be doing something else to fix it.

[Roboguy99]

Which config are you talking about now? The default values?

 

No, I'm talking about the per-item values.

 

The issue probably does apply to both, though; both sets are held in the Config class...

[Roboguy99]

Wait, what! How the heck are you storing per-item values in the Config class? Those need to go in the ItemStack.

 

Erm..I have no idea, but it sorta works...

 

I tell you what, I'm going to go away for a couple of days and just rework/figure out what I've made and try to fix it. We're both getting equally confused at this.

[GotoLink]

If you have client values, read and used by the clients...

They should stay on client side. Never into the world data, which is server property, including item NBT.

Write the client stuff on the client config file.

 

Now if the server use values, the defaults should be from the server configuration. Because there may be no client connected.

If the client need to know about those values, the server would send them through packet at appropriate time.

 

 

Let say there is a value such that both sides care about.

Server config contains "X" as default, sends it over to client.

->X | X  (both sides)

Client config applies a "client modifier=A" on it:

->X | X*A (use it for its own purposes)

User makes a modification "+" in GUI.

->X | X*A+A (temporary client side evaluated expression, based on client config)

Client send "+" packet, (contains GUI id and other stuff for identifying source) server receives "+" packet and applies its change.

-> X + 1 | X*A+A

Server may need to send back an update (could be same packet as first time), just in case...

-> X + 1 | X + 1

Which client config still apply client modifier on before use

-> X + 1 | (X+1)*A

etc.

In summary:

"A" is never sent over the network. It is kept by the client side data (in config file, probably).

"X" is sent by the server to the client. It is kept by the server data (in world save, probably), send by packet to client.

"+" is an operation known to both sides (or only server, in which case update packet is mandatory everytime). It is not data, and is thus not saved by either.

Client to server packet will ask server to perform "+" operation on its value, based on mutual agreement of the code needed in the packet to identify as "+" operation, such as channel name.

"*" is a client side operation. Server doesn't care nor understand.

[Ernio]

I am very happy today (exams), so may I suggest my assistance in solving your problem via Skype? I really feel like coding some shit before I restart my own works Skype: ernio333

[Roboguy99]

I am very happy today (exams), so may I suggest my assistance in solving your problem via Skype? I really feel like coding some shit before I restart my own works Skype: ernio333

 

I haven't really got enough time tonight, and my head isn't quite in the right place. I'm going to just go and sort it out over the weekend, and once the code seems to make some sort of sense I'll come back here.

 

Thanks for the offer though.