Custom NBT data for player doesn't save [Solved]

[Spaceboy Ross]

This week, I've added capabilities into my mod and I try to save the newtype NBT data but the data doesn't get saved. GitHub: https://github.com/SpaceboyRoss01/MSGundam.

Edited September 16, 2018 by Spaceboy Ross

[Spaceboy Ross]

Correct Link: https://github.com/SpaceboyRoss01/MSGundamMod

[V0idWa1k3r]

You can't do this client-side only

if(button.id == this.btnNewtype.id) this.nt.setHumantype(EHumantypes.NEWTYPE);
if(button.id == this.btnOldtype.id) this.nt.setHumantype(EHumantypes.OLDTYPE);

This only sets your data on the client(and that data won't be persistent as one might guess). You need to send a packet to the server and set the data there.

 

https://github.com/SpaceboyRoss01/MSGundamMod/blob/master/src/main/java/com/spaceboyross/gundam/capabilities/providers/NewtypeProvider.java

The generic type for ICapabilitySerializable is either NBTBase or any of it's children. If you are using NBTTagCompound to begin with you should just use it as your generic type rather than casting all over the place.

And why are you introducing a HANDLER generic type You do not need it as far as I am concerned.

This makes absolutely zero sense. A capability of NBTBase? The generic constraint there is your capability interface, not the type it is serialized into. I have no idea how it is even working and not crashing you completely.

 

This line is useless. It just creates a final field that is assigned to null. If you want your capability to be injected there you need to add the annotation.

 

root.setInteger("humantype",instance.getHumantype() == EHumantypes.OLDTYPE ? 0 : (instance.getHumantype() == EHumantypes.CYBER_NEWTYPE ? 1 : 2));

=>

root.setInteger("humantype",instance.getHumantype().ordinal()));

 

instance.setHumantype((new EHumantypes[] {
					EHumantypes.OLDTYPE,
					EHumantypes.CYBER_NEWTYPE,
					EHumantypes.NEWTYPE
				})[root.getInteger("humantype")]);

=>

instance.setHumantype(EHumantype.values()[root.getInteger("humantype")]);

 

You also must copy the data from the old capability to the new capability upon PlayerEvent.Clone, otherwise your capability data will reset to defaults every time the player is cloned(respawns for example)

 

ResourceLocations should be all lower-case. In 1.13 the "should" turns into "must" as an exception will be thrown on non-lower-case ResourceLocations.

 

TL;DR: I think that your problem is not serialization but 

a) The fact that you only ever set the values on the client

b) That your capability provider is broken.

[Spaceboy Ross]

I was following the capability code from https://github.com/Choonster-Minecraft-Mods/TestMod3/tree/b3d71dfddf7f212f0d86ef36e6ae1d06b8493ebc/src/main/java/choonster/testmod3/capability.

Edited September 16, 2018 by Spaceboy Ross

[Spaceboy Ross]

I fixed the code locally, I just need to update github.