[SimpleNetworkWrapper] Bi-directional packets

[coolAlias]

Hello again,

 

While updating one of my mods, I noticed that IMessage/Handlers with SimpleNetworkWrapper don't seem to allow for the possibility that one may need to send the same packet to both sides (at different times, not simultaneously).

 

I tried something like this:

instance.registerMessage(handlerClass, messageClass, 1, Side.CLIENT);
instance.registerMessage(handlerClass, messageClass, 2, Side.SERVER);

 

but the packet seemed to only work for one side while in the game.

 

Obviously I can copy the class and make one for each side, but they both require exactly the same fields / data (and some are even handled identically), so I'd rather not do that if possible.

 

Is it even possible to do something like this with SimpleNetworkWrapper, or do I need to write my own network implementation?

 

Cheers,

coolAlias

[SanAndreaP]

AFAIK, you use the same discriminator for the same message on both sides.

So on both, you use 1.

[Kwibble]

With the on message method, you can return a message to the client... Wait, nevermind.

 

What I was going to say is you could have a boolean passed in to the constructor representing whether or not you want to "send" it to the server or not. That boolean then determines whether or not the onMessage updates the server side values, or returns the packet to update the client.

 

Maybe you can subclass say MainPacket and call the child class MainPacketClient and just pass all functionality to the super class? It could potentially lead somewhere.

[coolAlias]

@SanAndreasP Tried giving them the same discriminator, but it had the same result; oddly, one of the packets I send gets sent fine to the client but fails to play sound, and the other gets sent to the server and works, but can't be sent to the client for some reason. Anyway, I think I've just about had it with SNW - it seems every step of the way I run into something that just doesn't work the way I think it should.

 

While the implementation from the wiki may indeed have a memory leak, it has never caused any problems that I can see and has always worked flawlessly for everything I need it to do, so I may just stick with that one until something better comes along. Maybe if I get enough time, I'll poke around and see if I can fix whatever is causing the memory leak

 

Thanks for the reply (you too, Kwibble).

[jabelar]

@SanAndreasP Tried giving them the same discriminator, but it had the same result; oddly, one of the packets I send gets sent fine to the client but fails to play sound, and the other gets sent to the server and works, but can't be sent to the client for some reason. Anyway, I think I've just about had it with SNW - it seems every step of the way I run into something that just doesn't work the way I think it should.

 

While the implementation from the wiki may indeed have a memory leak, it has never caused any problems that I can see and has always worked flawlessly for everything I need it to do, so I may just stick with that one until something better comes along. Maybe if I get enough time, I'll poke around and see if I can fix whatever is causing the memory leak

 

Thanks for the reply (you too, Kwibble).

 

Interesting.

 

I noted that LexManos made a remark in one of the changelogs for recent release that indicates he planning on re-writing the networking underpinnings.  Maybe if he's reading this he can hint on what that is.

 

I had yet another method of custom packets that used the FMLCustomPacket class.  Like you said it seemed to work well for me, and seems like a legit method (heck, it's even called FML custom packet).  I also don't think it would have had the memory leak problem, since I wasn't doing all that pipeline stuff, although I suppose I never really understood what the cause of the leak was.  On the other hand I might not have stressed the system fully either.

 

Anyway, definitely sucks that there isn't a trustworthy and comprehensive implementation yet.

[coolAlias]

@jabelar That's just the thing - I have never seen anywhere someone point to what, exactly, is causing the memory leak in the pipeline code; not to say that there isn't one, but if no one can point it out, then... Many people are writing their own implementations, but without the amount of scrutiny that went in to discovering(?) the pipeline leak, who's to say that those implementations do not also have memory leaks? If there is a leak, it must not be very severe, as I've sent many many packets over the course of several hours without any adverse effects, but I am certainly no expert in the matter. I can't help but feel like the pipeline code has been wrongly maligned...

 

At any rate, I'm looking forward to Lex's rewrite, if that's indeed what he is rewriting - we could certainly use a stable 'Forge-team-certified' network code.

[SanAndreaP]

If you're interested in not using the SimpleNetworkWrapper and not having any memory leaks, use the event-driven packet system:

https://github.com/SanAndreasP/ClaySoldiersMod/tree/master/java/de/sanandrew/mods/claysoldiers/network

 

Doesn't cause any problems for me.

[jabelar]

If you're interested in not using the SimpleNetworkWrapper and not having any memory leaks, use the event-driven packet system:

https://github.com/SanAndreasP/ClaySoldiersMod/tree/master/java/de/sanandrew/mods/claysoldiers/network

 

Doesn't cause any problems for me.

 

Yep, I did mine the same way -- handle ServerCustomPacketEvent and ClientCustomPacketEvent.  I haven't had problems.

[coolAlias]

If you're interested in not using the SimpleNetworkWrapper and not having any memory leaks, use the event-driven packet system:

https://github.com/SanAndreasP/ClaySoldiersMod/tree/master/java/de/sanandrew/mods/claysoldiers/network

 

Doesn't cause any problems for me.

Thanks - I'll tinker around with it when I get some time. Pretty neat-looking mod, btw - that clay soldier looks like a fun opponent