Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

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


jabelar
 Share

Recommended Posts

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?

 

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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).

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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.

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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.

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Check out my tutorials here: http://jabelarminecraft.blogspot.com/

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.