[Solved]Letting Client Player know It Needs to read NBT

[jabelar]

Guys, most arguments in life are usually about a difference in terminology.

 

jredfox, the reason why you are frustrating diesieben07 is that your terminology isn't really the best. Yes, NBT data is involved in storing data related to a player, but the way it gets to the client is not by reading it directly from disk. Your use of the term "cached" is also not very correct as it has a very specific meaning.

 

I do understand what you're trying to say though -- sometimes the client seems to get out of sync with the data you expect. However, it may actually be that the server has lost the data and the client is actually in sync. That is why diesieben07 keeps asking to understand the exact nature of the bug.

 

The way it is supposed to work is that the server will save and load data on the player using NBT format (technically serialized and deserialized when written to disk). You can see in the log where it says "saving players". I believe that in addition to saving when you ask it to save, it also saves every 45 seconds or something like that.  When you load the game again, and if you log in again as the same player, then the server will read that NBT back.

 

All that though is on the server. For the client, it relies on the server sending packets with the information. Now the thing is that there isn't just one packet, there is some for position and motion, there is some for inventory, some for capabilities, and so forth. This should all work automatically.

 

So diesieben07's main point is that if you lose player data it must be happening on the server. The client will automatically be synced.

 

I find it hard to believe though that the server would actually lose the data, so I think the problem is probably that it does not think you're logged in as the same player. I noticed earlier in the thread that you said the UUID is changing, but that means you're not logging in as the same player. I also see that you posted a console log earlier that said "[16:48:29] [main/INFO]: Setting user: Player120".  That means that you're not logging in properly -- every time you run will be a different player. What you need to do in Eclipse is set your login information in the Run Configuration. To do this you need to edit the run configuration and add "--username=<your e-mail address> --password=<your password>" where you put in your Minecraft login credentials.

 

You definitely cannot test player data save/loading without logging in properly.

[jredfox]

9 hours ago, jabelar said:

Guys, most arguments in life are usually about a difference in terminology.

 

jredfox, the reason why you are frustrating diesieben07 is that your terminology isn't really the best. Yes, NBT data is involved in storing data related to a player, but the way it gets to the client is not by reading it directly from disk. Your use of the term "cached" is also not very correct as it has a very specific meaning.

 

I do understand what you're trying to say though -- sometimes the client seems to get out of sync with the data you expect. However, it may actually be that the server has lost the data and the client is actually in sync. That is why diesieben07 keeps asking to understand the exact nature of the bug.

 

The way it is supposed to work is that the server will save and load data on the player using NBT format (technically serialized and deserialized when written to disk). You can see in the log where it says "saving players". I believe that in addition to saving when you ask it to save, it also saves every 45 seconds or something like that.  When you load the game again, and if you log in again as the same player, then the server will read that NBT back.

 

All that though is on the server. For the client, it relies on the server sending packets with the information. Now the thing is that there isn't just one packet, there is some for position and motion, there is some for inventory, some for capabilities, and so forth. This should all work automatically.

 

So diesieben07's main point is that if you lose player data it must be happening on the server. The client will automatically be synced.

 

I find it hard to believe though that the server would actually lose the data, so I think the problem is probably that it does not think you're logged in as the same player. I noticed earlier in the thread that you said the UUID is changing, but that means you're not logging in as the same player. I also see that you posted a console log earlier that said "[16:48:29] [main/INFO]: Setting user: Player120".  That means that you're not logging in properly -- every time you run will be a different player. What you need to do in Eclipse is set your login information in the Run Configuration. To do this you need to edit the run configuration and add "--username=<your e-mail address> --password=<your password>" where you put in your Minecraft login credentials.

 

You definitely cannot test player data save/loading without logging in properly.

Thanks for that but, no that wasn't the cause of the bug and no my terminology was just fine. I had to describe a player's data and it just happens to be stored as a file for further use later so I was describing the in memory data needs to be updated in multiple different ways to him and he didn't help. 

 

The bug was I wasn't syncing all the forge events that mods depend on for updating data for player properties. For vanilla data the solution was readFromNBT() on both client and server and change dimension, the other solutions I had to do a bit figuring out on my own by decompiling other people's mods and seeing what events are necessary. 

 

Yes I tried to explain this to him in multiple different terminology he either didn't want to help, wasn't fully listening or simply didn't care. He has done this on every forum I have ever posted no matter how simple the problem is. Like how do I get the static liquid from the flowing liquid

 

 

[jabelar]

2 hours ago, jredfox said:

Yes I tried to explain this to him in multiple different terminology he either didn't want to help, wasn't fully listening or simply didn't care. He has done this on every forum I have ever posted no matter how simple the problem is. Like how do I get the static liquid from the flowing liquid

The thing you have to understand is that people who are attracted to programming are often very precise, meticulous people. I work with many engineers who can't get past terms that are imprecise. So while I could understand what you were trying to say, I also understand why the way you were describing the problem would bother many programmers. 

 

You were mixing the ideas of the data itself with the intermediate format used by the serialization, you were mixing concept of caching with the concept of any data in memory, and you were mixing the concept of client saving data with the client communicating with the server to save data.  Some people simply find it hard to work with loosely applied terminology.

 

So please don't resent diesieben07. His multiple attempts to clarify were actually his way of showing he cared, was trying to listen, and wanted to help. It's just that he has a very precise mind and is most effective at helping when the problem is framed precisely.

Edited October 5, 2017 by jabelar

[jredfox]

1 hour ago, jabelar said:

The thing you have to understand is that people who are attracted to programming are often very precise, meticulous people. I work with many engineers who can't get past terms that are imprecise. So while I could understand what you were trying to say, I also understand why the way you were describing the problem would bother many programmers. 

 

You were mixing the ideas of the data itself with the intermediate format used by the serialization, you were mixing concept of caching with the concept of any data in memory, and you were mixing the concept of client saving data with the client communicating with the server to save data.  Some people simply find it hard to work with loosely applied terminology.

 

So please don't resent diesieben07. His multiple attempts to clarify were actually his way of showing he cared, was trying to listen, and wanted to help. It's just that he has a very precise mind and is most effective at helping when the problem is framed precisely.

I am a programmer myself, and I did describe the precise issue and when he didn't understand I gave him multiple views both general and specific.

I am not mixing any data and serialization. the playerdata is a file when and on world creation/ several other events it puts them into variables. I already knew how to update the playerdata files that wasn't the issue just the variables. readFromNBT() with the player doesn't do it's job if it's only vanilla and if you were not to teleport anywhere.

 

He didn't show multiple attempts. If you look he waisted my time. I clearly said for a page and a half how do you fool the server/client that the player has respawned/died. He clearly understood but, didn't recommend manually firing forge event's.

 

I am done talking here if you want to waist my time I am going to be pissed as well. I am not a noob here. I don't like dealing with people that waist my time, won't listen or don't get it since they won't listen.