Minecolonies & What we can do after Abstracting


10 days ago4 min read

As announced in my last post here, the abstraction done there, opened a lot of new doors to easily develop new things.

Small adjustments:

When I started porting the other GUIs over I noticed that I needed a bit more functionality for a few of them.

For example, I needed the isInverted field to be able to switch between the "Whitelist" and "Blacklist" approach.
In general, all items in the list are considered on (allowed) and all besides that off (not allowed).
But in some cases like the lumberjack, we want the ones which are off (not allowed) to be in the list since that is more efficient.

This way, depending on the state of the field we have to set the button differently

if ((isInverted && !building.isAllowedItem(new ItemStorage(resource))) || (!isInverted && building.isAllowedItem(new ItemStorage(resource))))

I also noticed that the panes needed a way to set the parentView of an element since if this is not set buttons which are added to the view after construction would not work.

This way, on each addChild, I would also manually set the parent.

Also, I improved the StackList request to include a description field which would be displayed in the GUI to the player as a human-readable field and not only "StackList" as previously.

And then return this value when needed on the client side.

I also fixed a small bug with the walking distance of the workers where the wrong value and not a constant was being used.

What I was able to remove:

Due to the previous abstraction, I was able to remove:


  • Most of the Baker Window

Reducing it to a page around the size of the composter window where only the blocklist query is different.

  • Most of the Baker Building code

Including everything related to the list, to deserialization or serialization, storing from and to disk etc and the same counts for the baker building client-side representation.

  • A bunch of the baker AI
    A lot of the baker AI class which was previously poorly managed with having the list store all items independent if on or off.
  • The Baker recipe message
  • The Baker GUI XML


  • Reduce the Window Class

The lumberjack class is a bit more complex because it is a) Inverted and b) needs extra functionality.
The beginning is quite similar, as in getting the blockList and extending the same class as the baker.

But, on open it would load a new button which allows toggling between replanting or not the saplings.

This is what I needed the add child method for.

And then needed to set up the replant button with the methods.

  • Reduce the building Class
    Where I was able to remove similar to the baker all the items which previously were needed to manage the list.

  • The lumberjack sapling selector message

  • The lumberjack GUI XML

After adding a bunch of new functionalities the first pull requests resulted in:

Long awaited features:

Which brings us to a bunch of long-awaited features based on the new abstractions.
People previously complained a lot that the smelter and cook would use quite expensive materials to fire the furnaces. With this new abstraction, it was very easy to add to their two GUIs the functionality to let the player select which materials they want them to use.

Which was just too easy.

For the windows:

For the building:

To allow to query this new info:

     * Getter for all allowed fuel from the building.
     * @return the list of itemStacks.
    public List<ItemStack> getAllowedFuel()
        return getCopyOfAllowedItems().stream().map(ItemStorage::getItemStack).peek(stack -> stack.setCount(stack.getMaxStackSize())).collect(Collectors.toList());

And then add in the entity AI code of the workers a way to detect if no fuel is set and notify the player about it.

And then request the StackList instead of a burnable.

            worker.getCitizenData().createRequestAsync(new StackList(getOwnBuilding(AbstractBuildingFurnaceUser.class).getAllowedFuel(), COM_MINECOLONIES_REQUESTS_BURNABLE));

Pull Requests:





Sort byBest