Refined Relocation

Refined Relocation

3M Downloads

Clean up (maybe even rewrite) GUI networking code

Dynious opened this issue ยท 3 comments

commented

The GUI networking code is a mess. It has always been and still is. We need to design a good system that is easily extendable and works in the same way every time. The main problem right now is that we do not have a server side class that receives messages for the opened GUIs. The message receiving is done by the class that needs a GUI or sometimes the container, which is messy and weird.

We need to brainstorm on a good solution.

Possible solution:

All GUI elements are a subclass of a class that is also present on the server (Gui elements are only client side, so we can't access them on the server). The class has methods to send and receive messages. So, the class will act as a port to send and receive data, nothing more.

The class will register networking numbers (add the class to a parent are all children should register a sync number). A message can be sent using the class without need to manually do anything to make sure it's received on the other side correctly (index sending should be handled correctly, only the instance should be passed), only when a GUI element needs to send more that one thing (like a list) it will need to handle this.

It should be clear, send message using the 'port' and you'll get it back on the other side in the 'port'.

commented

The only thing that I see is messy about it is the fact that we're using Object for the value parameter in the handler method. The message receiving is ALWAYS done by the Container class. The GUI doesn't even have a callback for that. The sending can be done either from the GUI (user action) or from the container (sync), but the receiver is always the container. I think that makes perfect sense.

I feel making an API-like complex system in the way you describe it is totally overkill for the simple purpose of syncing GUI and container. We shouldn't fix a working system.

commented

Yea, you might be right. The filtering interface syncing is just a little different, so I was really confused. I still think the GUI part of the mod is the most messy and confusing, but it might not be that bad. The fact the I created a billion GUI widgets of which most do the exact same thing, but have a different texture and sync packet certainly doesn't help :P

commented

Added the sendSyncMessage helper function to ContainerRefinedRelocation and got rid of some old updateProgressbar syncings.

Also splitted the onMessage method into onMessageBoolean, onMessageInteger, etc. to get rid of the Object-to-Primitive casting and allow MessageGUIBooleanArray.

We should move the network IDs from MessageGUI to GuiNetworkIds (didn't know that existed) and make sure we use that everywhere instead of using magic numbers and then we should be completely fine and never have problems with conflicting network IDs.