Why forge instantiates client-side packet handlers in dedicated server environment?

[MrJake]

Hi,

 

Question as in topic. I'm trying to get my mod working on a dedicated server and keep getting a

java.lang.NoClassDefFoundError: net/minecraft/client/entity/EntityPlayerSP

exception.

 

I understand the concept of sides and I'm registering my packet with correct receiving side:

INSTANCE.registerMessage(PacketHandler.class, Packet.class, id, Side.CLIENT); id++;

 

As the handler should only be run on client side, I thought it would be OK to use this:

EntityPlayer player = Minecraft.getMinecraft().player;
World world = player.getEntityWorld();

 

So again, why this class is instantiated when it's only supposed to be called on the receiving side(which is the logical client)?

Should I wrap this up in a proxy and use side specific methods? (Seems kind of useless as it shouldn't be called on server...)

[MrJake]

2 hours ago, diesieben07 said:

only register your client packet handlers on the client

I suppose that with regular channel it's not possible?

I've tried that(Not registering client-side packets on dedicated server) and it crashed with unknown enumerator error.

[MrJake]

So, what's the diffrence between these two? Are there some docs regarding EventDrivenChannel?

 

[MrJake]

Nice explanation, thanks. I'll probably stick to the simple channel.

[Draco18s]

Oh, and for reference, Forge doesn't even have to instantiate the class in order to get a ClassNotFoundException the way you have.

 

Simply by telling the JVM that your client sided packet handler exists is sufficient.

 

Because the JVM goes "I have to load this class, I don't know when--or indeed if at all--any given part of it will be executed, so I'm going to check that all of it is valid. To do that I need to make sure any additional classes it references are ones I can find, just in case I need to load them in the future. Oh what's this? I see a reference to EntityPlayerSP, I don't know what that is or where it find it. Crap."

[MrJake]

Yes, It kind of made sense to me, after thinking a bit longer. References also matter...

 

I'm trying to find a reasonable solution. Why not use @SideOnly after all? I have an interface to synchronize my Tileentity states(and opening GUIs) setup like this:

@Override
@SideOnly(Side.CLIENT)
public void setState(EnumStateType stateType, State state) {		
	switch (stateType) {
		case GUI_STATE:
			openGui = new RingsGUI(pos, (RingsGuiState) state);
			Minecraft.getMinecraft().displayGuiScreen(openGui);				
			break;

		default:
			break;
	}
}

 

[DavidM]

The @SideOnly annotation will not somehow make the associated code only run on the specified side.

IIRC the @SideOnly will cause a crash if the associated code is used in sides that is not specified in the parameter of the annotation.

[Draco18s]

*Referenced

 

@SideOnly literally deletes the code on the other side. If you have a reference to it that isn't also covered by @SideOnly (even if its never called!) the JVM will say, "Whoah boy! You've got a method call in this class that isn't valid!" and terminate.