Posted July 24, 201411 yr I'm trying to do a request-reply message packet. I knew how to construct them, but I have no clue about how the reply mechanism works. I just don't know how I would react to a reply from the packet sending code. Can someone enlighten me please?
July 24, 201411 yr AFAIK a reply is just a normal message that is sent to the opposite side by forge which means that packet replies are only there for convenience and the reply can and must be handled exactly as a normal message. You could of course encode the original message in the reply so that you know to which message you got an answer to but that goes too deap into actual code (you already know?, if not feel free to say so)
July 24, 201411 yr Author So this means that after returning the reply message in the handler forge sends another packet using the message you supplied to the sender. But how would it handle it if it doesn't specify the handler? Does it use the same handler?
July 24, 201411 yr With the SimpleNetworkWrapper implementation you have to `registerMessage(Class<? extends IMessageHandler>, Class<? extends IMessage>, byte, Side)` where you provide an IMessageHandler and an IMessage basically telling forge that the provided IMessageHandler handles Messages of type IMessage. Now I don't know what happens if you send a message which type hasn't been registered/has no handler. But if there is one for the type of message you sent it will be handled by the IMessageHandler you registered. Replies get sent on the channel they have been received so that is how forge knows that the answer belongs to your mod. Replies are nothing more than messages that get encode and sent and then get handled by the IMessageHandler you registered for the TYPE of IMessage that has been sent. So a messageflow may look like this (A and B are both IMessages): In MainClass: SimpleNetworkWrapper networkHandler = new SimpleNetworkWrapper("MHFC"); // "MHFC" is the channel's name In PreInitialization: networkHandler.registerMessage(AHandler.class, A.class, 0, Side.SERVER); // A is a message to the server networkHandler.registerMessage(BHandler.class, B.class, 0, Side.CLIENT); // B is a message to the client Normally you register both messagetypes on both sides (if needed) but here we have a simple bounceback Anywhere: A messageA = new A(someArgs); MainClass.networkHandler.sendToServer(messageA); Now the following happens: messageA -> encodedMessageA (by calling messageA.toBytes()) -> .... internet.... -> messageA (with messageA.fromBytes()) -> select handler (from registered handlers) -> handler.onMessage(messageA) -> messageReplyB -> encodeMessageB -> .... internet.... -> messageB -> select handler -> handler.onMessage(messageB) ->... Only the original messageA and the two handler.onMessage(message) calls happen outside of forge but give you full control. Now notice the ... at the end. This means that another answer package could be sent etc. Forgive my formatting, it's bad but w/e, follow the flow PS: Networkwise the messages aren't recognized by class but by the byte (third argument in registerMessage(...)). So make sure that you select a different byte for each message you register.
July 24, 201411 yr Author So you should use the IMessage class to the opposite side that you already registered using the same "discriminator" on the same SimpleNetworkWrapper. Am I getting this right? Thanks anyways for yous clarification.
July 24, 201411 yr That is correct. The descriminator byte has to be the same on both sides if you register the packet on both sides.
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.