[SOLVED][1.8] Is entity spawn timing on client different from 1.7.10?

[jabelar]

I've had a solid packet system based on SimpleNetworkWrapper working for a while.  One thing I do, is whenever I spawn an entity (on server) I also send a packet to sync up the values of some custom fields in that entity.  In the message, I include the entity ID based on the getEntityId() method for entities.  In the past, this seemed to be the way to reference the same entity on both client and server, so when client receives the message it looks up the entity using the following code:

	public static Entity getEntityByID(int entityID, World world)        
{         
    for(Object o: world.getLoadedEntityList())                
    {                        
        if(((Entity)o).getEntityId() == entityID)                        
        {   
        	// DEBUG
            // System.out.println("Found the entity");                                
            return ((Entity)o);                        
        }                
    }                
    return null;        
} 

 

This worked great in 1.7.10 and it always found the entity.

 

Now I'm updating to 1.8 and getting a null pointer exception when trying to create an entity using the received ID.  Sure enough, at that time there is no such ID on the client.

 

So I'm wondering, did the timing of the spawning of an entity on client change such that if I send a packet referencing the entity immediately after creating it on the server it doesn't exist yet?  Basically I wondering if my packet gets sent before the built-in packets that sync the client entities.

 

Alternatively, has the entity ID scheme changed in 1.8 such that the numbers no longer match on client and server?

 

[jabelar]

Sure enough I put a debug statement in the constructor of the entity.  I found that the constructor fires on the server and then the packet is created on server and received on client before the constructor is called on the client.  I actually found that occasionally the constructor on client was called before the received messages and in those cases no NPE crash happened.

 

So I guess I can no longer count on the spawning of an entity to immediately send a spawn packet.  I guess I'll play around with adding some delay, but I'd like to ideally have the ordering logically controlled.  I suppose I could create some sort of message queue on the client where if an entity isn't found then it is retried each tick until it is found (or times out).

[Ernio]

One link: http://www.minecraftforge.net/forum/index.php/topic,27615.msg141586.html#msg141586

 

If you'd want more about ticking/packets/direct-updates/special update calls/tracking - my post history is a MINE of those questions, all answered. Look from 3-10 pages.

 

And yes - making task will ensure entity with given id is constructed when data in Runnable is processed.

[coolAlias]

The problem is that packets are handled on a different thread now, and these don't always sync up. Vanilla's 'solution' to this problem is to then WAIT for the main server thread to process the packets.

 

You can see here how I do the same in my packet system.

 

That being said, it is much easier (and provides better encapsulation) to implement IAdditionalEntitySpawnData in your entity class, which then lets you tag along extra data with the actual spawn packet, rather than writing and sending your own additional packet(s) on spawn.

[jabelar]

The problem is that packets are handled on a different thread now, and these don't always sync up. Vanilla's 'solution' to this problem is to then WAIT for the main server thread to process the packets.

 

You can see here how I do the same in my packet system.

 

That being said, it is much easier (and provides better encapsulation) to implement IAdditionalEntitySpawnData in your entity class, which then lets you tag along extra data with the actual spawn packet, rather than writing and sending your own additional packet(s) on spawn.

 

Okay, that would explain it.

 

Is the IEntityAdditionalSpawnData synced continuously or just during spawn?  If it is synced continuously (my custom field values can change during game) I'll try the additional spawn data approach.  I haven't been using that because I have had for a long time a successful similar implementation of my own (NBT on each side for saving/loading custom fields plus custom packet to sync) but with this new issue of synchronization the additional spawn data seems much preferred.

[jabelar]

One link: http://www.minecraftforge.net/forum/index.php/topic,27615.msg141586.html#msg141586

 

If you'd want more about ticking/packets/direct-updates/special update calls/tracking - my post history is a MINE of those questions, all answered. Look from 3-10 pages.

 

And yes - making task will ensure entity with given id is constructed when data in Runnable is processed.

 

Thanks, that thread has some great info and is exactly the sort of thing I was running into.

[coolAlias]

The problem is that packets are handled on a different thread now, and these don't always sync up. Vanilla's 'solution' to this problem is to then WAIT for the main server thread to process the packets.

 

You can see here how I do the same in my packet system.

 

That being said, it is much easier (and provides better encapsulation) to implement IAdditionalEntitySpawnData in your entity class, which then lets you tag along extra data with the actual spawn packet, rather than writing and sending your own additional packet(s) on spawn.

 

Okay, that would explain it.

 

Is the IEntityAdditionalSpawnData synced continuously or just during spawn?  If it is synced continuously (my custom field values can change during game) I'll try the additional spawn data approach.  I haven't been using that because I have had for a long time a successful similar implementation of my own (NBT on each side for saving/loading custom fields plus custom packet to sync) but with this new issue of synchronization the additional spawn data seems much preferred.

IEntityAdditionalSpawnData only allows you to piggyback ONCE on the initial spawn packet; any synchronization required after that is still up to you.

 

Typcially, I use IEASD for unchanging fields that the client needs to know about, and either DataWatcher or setEntityState + handleHealthUpdate for the ones which can change. For some examples of the latter, see here - it's great for things like animation timers.

[jabelar]

IEntityAdditionalSpawnData only allows you to piggyback ONCE on the initial spawn packet; any synchronization required after that is still up to you.

 

Typcially, I use IEASD for unchanging fields that the client needs to know about, and either DataWatcher or setEntityState + handleHealthUpdate for the ones which can change. For some examples of the latter, see here - it's great for things like animation timers.

 

Okay, I guess I'll use a hybrid of the IEntityAdditionalSpawnData (for the initialization) and custom packets for the additional sync (I can probably safely assume that entity will be spawned later in the game) and maybe put in some graceful handling of the case where entity isn't found.

 

I already tried this on one entity and it seemed I was able to get it working.  Will keep looking at it.