Jump to content

[1.7.10] ForgeDirection becoming null in packet from client to server


Recommended Posts

Posted

So I am sending a packet from my gui with a forgedirection to my tile entity.  The forge direction is becoming null in toBytes or fromBytes.  It is not null in the constructor. It is null in onMessage.

Here is the to and from Bytes methods:

direction is the ForgeDirection being passed in through the constructor.

 

 

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

        direction = ForgeDirection.getOrientation(buf.readInt());
    }

    @Override
    public void toBytes(ByteBuf buf) {
        super.toBytes(buf);

        buf.writeInt(direction.ordinal());
    }

 

 

Posted

 

 

package com.professorvennie.bronzeage.core.network;

import cpw.mods.fml.common.network.simpleimpl.IMessage;
import cpw.mods.fml.common.network.simpleimpl.IMessageHandler;
import cpw.mods.fml.common.network.simpleimpl.MessageContext;
import io.netty.buffer.ByteBuf;
import net.minecraftforge.common.util.ForgeDirection;

/**
* Created by ProfessorVennie on 1/9/2015 at 11:12 AM.
*/
public class MessageConfigUpdate extends MessageCoords implements IMessageHandler<MessageConfigUpdate, IMessage>, IMessage {

    private ForgeDirection direction;

    public MessageConfigUpdate() {
    }

    public MessageConfigUpdate(int x, int y, int z, ForgeDirection direction) {
        super(x, y, z);
        this.direction = direction;
    }

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

        direction = ForgeDirection.getOrientation(buf.readInt());
    }

    @Override
    public void toBytes(ByteBuf buf) {
        super.toBytes(buf);

        buf.writeInt(direction.ordinal());
    }

    @Override
    public IMessage onMessage(MessageConfigUpdate message, MessageContext ctx) {
        /*if(Minecraft.getMinecraft().theWorld.getTileEntity(message.x, message.y, message.z) instanceof ISideConfigurable){
            ((ISideConfigurable) Minecraft.getMinecraft().theWorld.getTileEntity(message.x, message.y, message.z)).changeMode(direction);
        }*/
        System.out.println(direction);
        return null;
    }
}

 

 

 

Here is the Message Coords:

 

 

package com.professorvennie.bronzeage.core.network;

import cpw.mods.fml.common.network.simpleimpl.IMessage;
import io.netty.buffer.ByteBuf;

/**
* Created by ProfessorVennie on 12/14/2014 at 7:42 PM.
*/
public class MessageCoords implements IMessage {

    public int x;
    public int y;
    public int z;

    public MessageCoords() {
    }

    public MessageCoords(int x, int y, int z) {
        this.x = x;
        this.y = y;
        this.z = z;
    }

    @Override
    public void fromBytes(ByteBuf buf) {
        x = buf.readInt();
        y = buf.readInt();
        z = buf.readInt();
    }

    @Override
    public void toBytes(ByteBuf buf) {
        buf.writeInt(x);
        buf.writeInt(y);
        buf.writeInt(z);
    }
}

 

 

Posted

This is because the IMessage instance and the IMessageHandler instance are not the same object, even though you implement them in the same class.

 

Thus the standard implementation being an IMessage class with a static nested class for the handler:

public class SomeMessage implements IMessage {
private int field;
public SomeMessage() {}
public SomeMessage(int something) {
this.field = something;
}
// rest of IMessage methods

// Static nested inner class which takes your message object as a parameter, meaning
// that your message will be passed to it when received
public static class Handler implements IMessageHandler<SomeMessage, IMessage> {

@Override
public final IMessage onMessage(SomeMessage msg, MessageContext ctx) {
System.out.println(msg.field); // not null anymore because you got it from the IMessage instance rather than the handler
}
}

Posted

That fixed it but I still don't know why it's bad so many other mods do it this way. Ee3 does it this way

It's bad because it doesn't make any sense for your MessageHandler class to have class members or methods such as 'toBytes' - those belong to the message class and are actions a message can perform, but it is nonsensical for the handler to read itself from the byte buffer.

 

Also, while you technically could implement it as you have, it gives you the false impression that you can use 'this.field' inside of the handler class to access your message's class members, but since the handler is not the message, this is again false and leads to errors such as yours.

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.

Announcements



×
×
  • Create New...

Important Information

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