Here's how stuff happens: (in order)

*** Server constructs player ->Player gets his IEEP -> Joins server world -> Client constructs player -> Player gets his IEEP -> Joins client world. ***

 

Now - I can't send any packet from server->client before client constructs him. ### How can I do this without using Client-request packet (which till now I'm doing). ###

Note: I can't use PlayerLoggedInEvent since it's not fired on respawning. When player respawns events go same as in *** above, there is just PlayerEvent.Clone launched (server-side) after construction.

 

Some time ago I posted similar thread, but since that I've learned about Tracking (PlayerEvent.StartTracking and few other tricks which are server-side). Sadly StartTracking is not working for player himself (event.target is never him).

So that leaves question: Is there a way to know when player starts tracking himself (start tracking happens after client alredy has his PlayerEntity which would solve ### part)?

 

Goal: Send synchro packet to player after he reconstructs (no matter why - login/respawn). Ofc do it without using ticks and client-side requests.

 

Oh my god. I totally forgot (didn't know) to look more into cpw events.

 

http://www.reactiongifs.com/r/2012/08/well_done_sir.gif[/img]

EntityJoinWorldEvent works perfectly for this, too, if you want to catch both login and respawn in one event, but it fires for all entities so you have to check if it's a player so it's probably less efficient than using the two specific events combined.

 

Still, if you are doing other stuff there already, it's handy.

"Joins server world -> Client constructs player"

This here is perfect reason why I didn't use EntityJoinWorldEvent and was looking for events like ones proposed by diesieben (those ensure that client constructed PlayerEntity).

 

If you'd try to send packet from server->client in EntityJoinWorldEvent there is no guarantee the packet will arrive. Reason: Client haven't constructed PlayerEntity yet. All packets send to this refered player will be lost (not read).

 

Also funny thing: it seems like sometimes Joins server world is laucnhed after Client constructs player, In different situation different shit happens man. On Dedic one, on Integrated other. I have no idea what is the correct reason for this (because of 2 separate threads most likely), but I don't like randomness.

 

Sending from EntityJoinWorldEvent does work, unless you are you talking about 1.8? In that case, yes, you have to make sure you only process the packet on the main thread, otherwise you are right, the client player will not have been constructed yet.

 

I've used it plenty and it works fine for me, but use whatever works mate.