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

[SOLVED][1.7.10] Detect if event.entity is mc.thePlayer?


Ernio
 Share

Recommended Posts

@SubscribeEvent
public void onEntityConstructing(EntityConstructing event)
{
	if (event.entity instanceof EntityPlayer)
	{
		Side side = FMLCommonHandler.instance().getEffectiveSide();
		if (side == Side.CLIENT)
		{
			System.out.println(((EntityPlayer) event.entity) == Minecraft.getMinecraft().thePlayer);
		}
	}
}

== - nope

.equals - nope

It's either impossible inside EntityConstructing or I am doing it wrong.

 

This print is always false.

 

At that point (constructing) entity doesn't have id, they are probably not the same as an Objects, so basically - what can i do to compare them?

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

Link to comment
Share on other sites

Check player.worldObj to find out whether you are on server or client. You can't yet detect if it's Minecraft.thePlayer since the event is literally fired from the Entity constructor, so of course the thePlayer field cannot be assigned yet.

If you want to exclude other client-side players, check for instanceof EntityOtherPlayerMP.

Link to comment
Share on other sites

Okay so this is kinda second thread after:

http://www.minecraftforge.net/forum/index.php/topic,26990.0.html

Which I marked as solved since I found a way to do what I want.

 

If you would read thread above you would see the problem - server doesn't know if the client-side EntityPlayer has been constructed yet, and sending any kind of packet that would update client-side IEEP will result in that packet being not received.

 

To overcome this I had to create client-side request packet that requests player data just after its constructed on client (server always constructs it 1st) and the send data from server. This way I don't have to check anything every tick (which saves some "power").

 

Basically next problem (this thread) was to not send request from every connected client and then send data to all client from server, but to send one packet from client that actualy is "himself" and then handle rest on server (some of that data is private and only accessible by this certain player, rest shouldn't know about it).

 

This code seems to be working:

@SubscribeEvent
public void onEntityConstructing(EntityConstructing event)
{
	if (event.entity instanceof EntityPlayer)
	{
		System.out.println("CONSTRUCTING");
		if (ExtendedPlayer.get((EntityPlayer) event.entity) == null)
			ExtendedPlayer.register((EntityPlayer) event.entity);

		Side side = FMLCommonHandler.instance().getEffectiveSide();        
		if (side == Side.CLIENT)
			if ((EntityPlayer) event.entity instanceof EntityPlayerSP)
			{
				System.out.println("BAM, THIS IS YOU");
				PacketDispatcher.sendToServer(new PacketRequestPlayerData());
			}
	}
}

 

Works ofc. on Client-Server and Client-Dedic. Tested with 2 players connecter, everything seems like I expected :)

 

diesieben07 - i know you hate Side.X but, it's NOT bad, when I tried using world.isRemote ANYWHERE in code regarding synchronization I literally ALWAYS had problems, Side is pretty straight forward (I am aware that there is one "bug", i am avoiding to use Side with it).

 

P.S I will also check EntityOtherPlayerMP, it might be better.

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

Link to comment
Share on other sites

Don't do that - you can send a packet from PlayerLoggedInEvent instead, or even EntityJoinWorldEvent, but not during EntityConstructingEvent.

 

Well, I was testing different ways of doing it:

PlayerLoggedInEvent is ONLY called server side and ONLY when player enstablishes connection, never after Clonning (respawn).

EntityJoinWorldEvent will basically do same damn thing, maybe more "safe" since it's not in constructor.

 

Note that (i pointed it out in thread linked in my last post)

this is how things happen:

[20:01:11] [server thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.events.ForgeEvents:onEntityConstructing:33]: CONSTRUCTING
[20:01:11] [server thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.events.ForgeEvents:onPlayerClonning:42]: COPYING
[20:01:11] [server thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.events.ForgeEvents:join:54]: JOINED
[20:01:11] [Client thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.events.ForgeEvents:onEntityConstructing:33]: CONSTRUCTING
[20:01:11] [Client thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.events.ForgeEvents:join:54]: JOINED

If I am sending request packet from client to server it doesnt really matter if i use constructing or joined event - server-side has alredy constructed and has stable EntityPlayer object and will receive that packet. As to safety - request packet happens (see code in last post) after player gets his IEEP, so the response packet from server will not cause null pointer in any way.

 

For convinience I guess i could use Joined, I just used Constructing because that saves me subscribing to Joined and again checking if eneity is Player and stuff (2 times same shit).

 

You gotta do, what you gotta do (tricks and stuff), some things just don't want to work like I want :P

I was even considering kicking player after death... and just use PlayerLoggedInEvent, but nah... that's it the easy way.

 

Thanks all, I think the thread is solved (until my entire code will stop working and crash shit out of me) lel.

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

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.