Proper way to read/write multi-part entity to/from NBT? [SOLVED]

[awger]

I'm trying to work through a chicken-and-egg problem, and I'm not sure what the "proper" method is supposed to be.

 

I have a parent entity that instantiates multiple child entities.  Parent has an array for keeping track of children (accessed via getParts) and each child has a pointer to the Parent. Everything works fine when a player builds the item (spawned on server, writeSpawnData sends all the necessary data over, and everything is instantiated and reconnected on the client).

 

The problem occurs when the parent+children is written to NBT and then read back out.  All the data is there but, because the children already exist and sometimes get spawned on the client before the parent, reconnection is all out of whack -- MC is trying to update and render the various bits before all the linkage is complete, and it keeps hitting null objects.

 

I've added copious null checks (in the MC code as well) and rigged my children to do lazy linkage back to the parent, but I'm stuck on the parent's child array.  It's an MC-defined interface (an array of known size), and it has to exist before the children start showing up, but in between the parent instantiation (and allocation of the array) and the registration of all the children, MC comes along and tries to start loading skins, hits a null, and throws.

 

I tried killing all the children (chunk remove and setDead) when the parent is written to NBT, and then creating new children when the parent is read back out, but that didn't seem to get me much further (caused different problems, like occasional concurrent access throws).

 

Is anyone else using multipart entities?  How should the parent+child NBT writing/reading be handled?

 

[4pwnda]

Travel to the end in order to ask the Enderdragon, or just look in his java classes. It is he right?

[awger]

You would think... but, no. 

 

The EnderDragon takes many shortcuts, not the least of which is the parent recreates its children in the constructor, and the children written to NBT are orphaned.  Not a huge problem when you only have one dragon with half a dozen children, and the dragon only gets instantiated when the end loads, but it quickly becomes a problem when you're dealing with dozens of parents that have hundreds of children each.

 

The more I look through the vanilla code, the more I'm convinced that the child entitiy handling was an afterthought.

[awger]

Had to do a very lazy late linkage in both directions. 

• SPAWN ORDER IS NOT DEFINED.  When restoring from NBT, objects are spawned in random order.  parent will spawn before, in the middle of, or after all the children.
  
• getUniqueID() in parent extended constructor.  UUID is passed in writeSpawnData and written to NBT
  
• children track parent by parent UUID (and of course, written to NBT)
  
• parent.getParts() has to check for all children loaded and linked, return null if some are missing
  
• chlid.onUpdate checks for linkage to parent, attempts to link, bails out if not linked
  

 

Additional parent/child null checks, in places you wouldn't otherwise need them, will be required.  Under normal circumstances (children spawned by parent) the parent will be known when the child instantiates, but not after an NBT load.  Same for parent iterating through its child array -- until all children are relinked there will be uninitialized members.

 

Note that external code doesn't null check array members before trying to access them.  In order to avoid throw/crash you'll have to trick them into not running (getParts() returns null until all children are linked).