[Solved]getEntityData() versus IExtendedEntityProperties

[jabelar]

I usually use IExtendedEntityProperties frequently.  But when I was going through Entity class recently I noticed the getEntityData() method which is described as:

    /**
     * Returns a NBTTagCompound that can be used to store custom data for this entity.
     * It will be written, and read from disc, so it persists over world saves.
     * @return A NBTTagCompound
     */

 

That seems very similar idea.  However, looking through the code that calls this method, it seems to have little use in the rest of the code -- only used in clone player or something.  So probably sort of an orphan functionality.

 

Anyway, is the getEntityData() useful or should I stick with IExtendedEntityProperties?

 

[coolAlias]

Here's what I've gathered from my modding experience - anyone feel free to add on to or correct me on any of this.

 

IEEP gives you certain advantages:

- Automatically calls its saveNBTData method every time the player data is being saved

- Automatically calls its loadNBTData method whenever the player data loads

- The class you make for it is a handy place to store your data for use between save and load cycles

 

Now, you could certainly do some work to get similar results with getEntityData, such as nesting it in a class with some functions and storing your variables, but since you have no hook for the player save, you will have to write to this compound every time one of your variables changes value.

 

I do use getEntityData occasionally, but only for sort of 'one-time' things, like marking a vanilla entity as 'already spawned' if I'm doing something like having it spawn in with a buddy or whatever. Anything that I actually want to access during the game, I use IEEP.

[jabelar]

I missed your answer until you pointed it out in another thread.  Thanks for the detailed reply.

 

You said: but since you have no hook for the player save

 

I guess that's true because I couldn't find any.  The comment for the getEntityData() seems a bit misleading though because it says "It will be written, and read from disc, so it persists over world saves."  Are you making a distinction between world saves and player saves?

[coolAlias]

No, I'm not. The data IS written and read, but it doesn't tell you when it does so meaning you cannot have one central method to write everything you want to save, so you have to make sure you write the data to NBT every single time you change it, or it will be lost. You could, of course, hook into EntityJoinWorldEvent to load your data, and I guess you might be able to do something for logging off, but IEEP has all that built in for you.

[jabelar]

Got it.  Thanks for the detailed answer.

 

(It's funny because as I learn modding and crawl into new areas of code, I almost always find you've been there before me!)

[jeffryfisher]

I was wondering a similar question about NBT utility: why are saves and world-loads done with NBT tags while entirely separate packets are used to spawn entities during play? Why don't entities utilize the NBT read/write methods they already have to make their spawn packets? Then I saw how huge the NBT tags are. Apparently, the complete state of an existing entity is vastly more complex than the default initial state of a freshly spawning one. Using NBT tags to spawn new entities would be very wasteful.

 

Still, I wonder if packets could have been implemented as an O-O method system in Entity and its subclasses. Extending packet data would be so simple then.

 

[jabelar]

Then I saw how huge the NBT tags are. Apparently, the complete state of an existing entity is vastly more complex than the default initial state of a freshly spawning one. Using NBT tags to spawn new entities would be very wasteful.

 

While I think it is good to be aware of performance and "waste", the reality is that modern computers and modern networks can push a heck of a lot of data.  For something that occurs infrequently I don't think it is that bad to use NBT even if it is overkill.  Sending it every tick for a lot of entities might start to be a problem, but if it is only sent on changes to the entities and if there are only a few, it is probably just fine.

 

In coding it is common wisdom that as long as you're not stupidly wasting perf, if there is advantage in terms of clean coding logic, coding maintainability, or code reuse, it is okay to not be fully perf optimized.  You should only perf optimize those things that are proven to cause perf problems.  This is because the Pareto rule usually applies, most of the perf problems will be dominated by a couple inefficient parts of the code.  It can be a waste of time as well as bad coding result to try to make new, possibly more contorted code, in your entire code base because you're overly obsessed with performance.

 

Remember also that most performance bottlenecks are usually solved by the next year's computer technology.  In fact computer performance is probably increasing faster than most of our ability to code more efficiently.

 

Just don't do obviously stupidly wasteful stuff.  So in this case, if NBT has advantage of being fully consistent with the save data and already easy to pack into packet payload, it is worth considering.