Hi everyone, as you guys now, abstracting and refactoring things is one of my big programming hobbies and while setting up some new features I noticed that I could save a whole lot of code if I would break this task down into abstracting the existing code and then in the next step using this for the new GUI.
In this first post, I will head into the abstraction work and the new features will be explained in the following post.
What is it about:
Now, for quite a while already we had GUIs displaying lists of items where the player was able to select certain items for certain actions and in one of these GUIs, we even had an input option to filter.
But, there were all scattered all over the place and had nothing in common. And while only one had the input filter, all of them could actually make use of this.
For this reason, I created one universal filterable GUI which will have the items, an on/off the trigger and input on top for filtering.
The first step of this was defining a building type which would define what kind of data would be needed on the server side.
Read and write the data from disk.
Besides that, it needs the methods to manipulate the ArrayList and finally a way to serialize it to send it to the client side.
Then I needed a client-side representation for it as well:
Where the add and remove methods would already do the synching to the server side.
And a method to deserialize it.
Also, I edited the existing message to make it more generic for this purpose.
And register it to the network.
Then, I created the abstract window class.
Which would take care of switching the pages, register the on/off button and set up the lists and the description label of the list?
When clicking on the switch button it would trigger it and change it to on/off depending on the previous state and also trigger the building view which as previously explained would then trigger the server update.
On open, most importantly it queries all items which fit the required description and filter.
After getting it from the blockList and from the exception list.
Those would be overridden by the final GUI.
On key typed, it would update the resources to update the filter.
Similar, in the update element of the list it would check if the item is contained in the list or not it would set the icons etc of the list.
And finally, to create a working worker I just had to make sure to extend the right classes and override the list of blocks.
Resulting in this very simple composter window.
This will make it way easier for new devs to enter and create simple GUIs for a worker which requires this functionality.
Extra bits:
Since people asked, we also added a config option to turn on/off the holiday special.
With the config option (using the forge config annotation)
And then checking for the feature where we activate it.
Besides that, we also added the new Student model for the library which looks similar to the monk which you saw at the beginning of the post.
Where I only adjusted the model output to the real output, which is a pain nonetheless.
Another issue I fixed was that people were complaining that request manipulation was only slowly synched to the client.
For that reason, I added functionality to the methods taking care of that on the client side so they don't have to wait for the server to sync the updated data over.
I hope you liked this update as much as I did, in this refactor we added an additional 300 lines but in this case we added a lot of additional functionality to the GUI (filtering) and made the code way easier to understand, if you check out my upcoming post you're going to see how much we really earned from this.
Pull requests:
https://github.com/ldtteam/minecolonies/pull/3204
https://github.com/ldtteam/minecolonies/pull/3215