[1.7.2]Is IExtendedEntityProperties just for saving, or also client-server sync?

[jabelar]

I understand what IExtendedEntityProperties does in terms of NBTCompound for saving and loading.  But do I still need to send packets between client-server if I'm keeping these extended properties up to date?  Or is the client-server synchronization also handled automatically?

[coolAlias]

If you need the data on the client, you must handle it yourself.

[jabelar]

If you need the data on the client, you must handle it yourself.

 

I kinda figured that.  I need info on client to control render animations.  I was hoping that with a built in extended properties interface they might have taken the trouble to sync it too ... but guess IExtendedEntityProperties is mostly just meant to provide consistency to NBT methods.

[jabelar]

CoolAlias, I was looking at your tutorial for the IExtendedEntityProperties.  You had the following saveNBT() method:

// Save any custom data that needs saving here
@Override
public void saveNBTData(NBTTagCompound compound)
{
// We need to create a new tag compound that will save everything for our Extended Properties
NBTTagCompound properties = new NBTTagCompound();
// We only have 2 variables currently; save them both to the new tag
properties.setInteger("CurrentMana", this.currentMana);
properties.setInteger("MaxMana", this.maxMana);
/*Now add our custom tag to the player's tag with a unique name (our property's name). This will allow you to save multiple types of properties and distinguish between them. If you only have one type, it isn't as important, but it will still avoid conflicts between your tag names and vanilla tag names. For instance, if you add some "Items" tag, that will conflict with vanilla. Not good. So just use a unique tag name.*/
compound.setTag(EXT_PROP_NAME, properties);
}

 

Why did you create a new compound rather than just adding your CurrentMana and MaxMana tags to the compound passed into the method?  I understand that compounds can be hierarchical, but isn't the compound passed in already a compound specific to the extended entities?

 

Anyway, except for hierarchy organization, is there any problem with adding the custom tags directly to the passed compound without creating a new sub-compound?

[coolAlias]

CoolAlias, I was looking at your tutorial for the IExtendedEntityProperties.  You had the following saveNBT() method:

// Save any custom data that needs saving here
@Override
public void saveNBTData(NBTTagCompound compound)
{
// We need to create a new tag compound that will save everything for our Extended Properties
NBTTagCompound properties = new NBTTagCompound();
// We only have 2 variables currently; save them both to the new tag
properties.setInteger("CurrentMana", this.currentMana);
properties.setInteger("MaxMana", this.maxMana);
/*Now add our custom tag to the player's tag with a unique name (our property's name). This will allow you to save multiple types of properties and distinguish between them. If you only have one type, it isn't as important, but it will still avoid conflicts between your tag names and vanilla tag names. For instance, if you add some "Items" tag, that will conflict with vanilla. Not good. So just use a unique tag name.*/
compound.setTag(EXT_PROP_NAME, properties);
}

 

Why did you create a new compound rather than just adding your CurrentMana and MaxMana tags to the compound passed into the method?  I understand that compounds can be hierarchical, but isn't the compound passed in already a compound specific to the extended entities?

 

Anyway, except for hierarchy organization, is there any problem with adding the custom tags directly to the passed compound without creating a new sub-compound?

I did that to prevent possible conflicts; imagine if everyone is adding custom properties, chances are probably pretty good that there will be some overlap in the NBT tags people want to use, especially if people are not careful to use fairly unique names. By storing all of my data in a new tag, I only have to add a single new key to the original player NBT data, and I can do so with a pretty much guaranteed to be unique key. Otherwise, no, there is no particular reason to do that

[jabelar]

Okay, for compatibility between mods that makes sense.

 

In my case, I'm adding these to my own entity so I don't think there is a chance of conflict with other mods, but probably good practice to do it your way so if I copy the method onto a vanilla entity I won't forget.

[coolAlias]

Okay, for compatibility between mods that makes sense.

 

In my case, I'm adding these to my own entity so I don't think there is a chance of conflict with other mods, but probably good practice to do it your way so if I copy the method onto a vanilla entity I won't forget.

Keep in mind that many mods may add extended properties even to your custom entities; my Zelda mod, for example, adds some extended properties to all entities that extend EntityLivingBase, which obviously also includes any modded entities that extend that class. Same goes for any other mods that do something similar, or to the innumerable mods (including my own) that add extended properties to EntityPlayer. I wouldn't ever assume that my properties are the only ones being added, unless you are sure that people will not be playing with any other mods installed

[jabelar]

Okay, for compatibility between mods that makes sense.

 

In my case, I'm adding these to my own entity so I don't think there is a chance of conflict with other mods, but probably good practice to do it your way so if I copy the method onto a vanilla entity I won't forget.

Keep in mind that many mods may add extended properties even to your custom entities; my Zelda mod, for example, adds some extended properties to all entities that extend EntityLivingBase, which obviously also includes any modded entities that extend that class. Same goes for any other mods that do something similar, or to the innumerable mods (including my own) that add extended properties to EntityPlayer. I wouldn't ever assume that my properties are the only ones being added, unless you are sure that people will not be playing with any other mods installed

 

Okay, that's also a good point.

 

Right now my mods are mostly for my kids' personal entertainment, and my field names are usually quite unique/descriptive, so chances are low of conflict.  But in anticipation of becoming hugely popular, I'll code my mods to play nicely with other mods!