5 minutes ago, diesieben07 said:

This has nothing to do with Forge.

They update just fine if you use the proper APIs for it (requires dependencies on the mods that create the capabilities you wish to update).

No, deserializing from NBT is not this API.

 

Also, no, I did not say you need a relog. I said to respawn the player.

I did just that but, didn't work for AOA a mod I was testing it with. Yes I backported 1.12.2 code

So I was agreeing with your original conclusion of to not break expecting mods force player relog>

The thread is still valid he said inventory wipe but, in reality it's the entire playerdata from my analysis. I have had it happen in 1.12 before as well with just forge.

There are alot more two more second search more recent and more valid:

 

Edited May 5, 20187 yr by jredfox

6 minutes ago, diesieben07 said:

Show that code. Backported 1.12.2 code? WHAT?

 

Then investigate what causes it and submit a fixing PR to Forge. Do not hack around by overwriting UUIDs and shit like that. You are breaking more stuff than you are fixing.

look at my code I don't change anything just readfromnbt and then force close client for syncing purposes
https://github.com/jredfox/evilnotchlib/blob/master/src/main/java/com/EvilNotch/lib/main/events/TickHandler.java

1.7.10 backport:
https://github.com/jredfox/tst

Edited May 5, 20187 yr by jredfox

So you really don't need to know why since you don't believe it ever occurs. If it never occurs then my event will never do anything. just every 6 seconds check if uuid has been changed per player

Back to the main point why is the player post with both readFromNBT() on server and connection set location not working when player get's disconnected does the server have to send itself a packet? I don't understand why it doesn't insta sync unless the client is controlling writing to the disk for integrated server and client wasn't aware of changes? no clue

Edited May 5, 20187 yr by jredfox

2 ways to get this "bug" to happen,

1 you have a launcher that is fucking things up,

2 you are in dev mode and not logged in so your UUID is going to change

show us proof that this happens and report it to mojang/forge dont "fix" this on your own you will break more stuff on the way

Edited May 5, 20187 yr by loordgek

5 hours ago, diesieben07 said:

I am not even going to try and decipher this crap.

 

Not even gonna go there.

you asked.

so what's the deal with it not saving the pos does it need to happen next tick or how many ticks what isn't syncing? Does it have something to do with multi threading how do I know when it's written to memory?

Edited May 5, 20187 yr by jredfox

1 hour ago, loordgek said:

2 ways to get this "bug" to happen,

1 you have a launcher that is fucking things up,

2 you are in dev mode and not logged in so your UUID is going to change

show us proof that this happens and report it to mojang/forge dont "fix" this on your own you will break more stuff on the way

Don't have to show proof it occurs often enough that there are hundreds of posts on it look it up. And yes it occurs in compiled I am not worried about dev don't know why dev changes the uuid on purpose. Most of them are called inventory wipe but, I have verified it's the entire playerdata.

If you looked at my source I don't change the uuid of the player I simply patch the data for when it does so it shouldn't break anything except forge capabilities syncing so player has to relog but, that is acceptable since it should never change to begin with.

Edited May 5, 20187 yr by jredfox

6 hours ago, diesieben07 said:

I am not even going to try and decipher this crap.

 

Not even gonna go there.

nevermind fixed the issue it turns out if your players dimension is "wrong" because you didn't teleport across dimensions properly it doesn't matter your pos is it and other data is going to be somewhat ignored.

So my fix is fully teleport player to dim again then disconnect player