I am trying to send a packet from server to player using an IMessage and SimpleNetworkWrapper, however, whenever it tries to send the packet it gives me this exception:

 

`io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException: readerIndex(8 ) + length(4) exceeds writerIndex(8 ): SlicedByteBuf(ridx: 8, widx: 8, cap: 8/8, unwrapped: UnpooledHeapByteBuf(ridx: 1, widx: 9, cap: 9/9))`

 

Does anybody know how would this exception raise for a simple packet send to player?

Ok, I first should note that the message itself is supposed to do nothing but reply another message from client containing requested data, thus why it is called EmptyMessage, but I wrote an integer to the buffer to prevent IndexOutOfRangeException.

 

The class:

public class EmptyMessage implements IMessage {

public EmptyMessage() {	}

@Override
public void fromBytes(ByteBuf buf) {
	buf.readInt();
}

@Override
public void toBytes(ByteBuf buf) {
	buf.writeInt(1);		
}
}

 

It is handled by this handler but I know it doesn't reach this code since I tried writing to output to no avail.

 

The handler:

public class EmptyMessagePlayerDataHandler implements IMessageHandler<EmptyMessage, PlayerDataMessage> {

@Override
public PlayerDataMessage onMessage(EmptyMessage message,
		MessageContext ctx) {
	return PlayerDataMessage.fromMinecraft(Minecraft.getMinecraft()); // This is in client
}
}

 

This is the way it is sent:

EmptyMessage message = new EmptyMessage();
Magematica.network.sendTo(message, (EntityPlayerMP) player); // On server side

 

This is the line in preInit:

network.registerMessage(EmptyMessagePlayerDataHandler .class, EmptyMessage.class, 2, Side.CLIENT);

I'm guessing this is a bug, because whenever I send an empty message (with no value in them) then reply an exception is thrown at the reply message.

The exception, which is IndexOutOfRangeException, is thrown when it wants to read the reply message, so I'm guessing it is not resetting the reading index at the reply and it goes out of range when trying to read the data.

I found out that the only solution for the time being is to send the reply packet as another packet, for anyone who wants to do this, remember to register the discriminator of the reply message to a different value than the request message.

LOL I thought the message and reply have to have the same id, since that what someone's told me here before, anyway, thanks for clarifying