Minecolonies & some quite important fixes!

Sorry for my absence, but University and some other projects got me quite occupied. I did some progress on Minecolonies in the last 2 weeks though.

I fixed some quite important things and was able to install some auto fixing.

First of all, we had some issues with citizens being assigned to the wrong jobs which carried also forward from some older versions, which in turn, lead to a bunch of reports of crashing servers or flooding error messages.

Auto fire job:

For that, I created an easy way to detect this.

Some time ago I created a method which allows us to get the building by type.
Now, I created a method which does return the building class the worker expects and which each worker has to override with his expected class.
Now on getOwnBuilding, it detects that it gets the wrong one and automatically unemploys the citizen.

What we do is basically this:

• Get the expected class type
• Compare it with the actual class type
• If differ, unemploy citizen
• The citizen without a job stops working by definition

This way we will have no crashes or issues with this anymore.

Small fixes:

Besides that, I added a small fix regarding an NPE we had.

Which means we have to auto default to a type if it's not given, also since a missing type also can only be caused by a bug.

Besides that, I increased the saturation requirements of the citizen (they weren't eating enough which made it slightly unbalanced)

Which I did by adjusting the formulas slightly.

Additionally, I added an extra delay for the builder if he works in great depths (to avoid abuse to use the builder as a miner)

Also, we got a report with crashing Minecolonies related to another mod, the other mod was calling our citizen hashcode during initialization which caused a null pointer exception.

That's why we built a null check in, to avoid a crash.

Builder and colors:

Another issue there was, was the builder which always only built to one type of bed (white beds) and always only requested red ones.

Some players reported this since they were annoyed that they scanned in different beds and had to get red wool, but he finally placed white ones.

The issues here was that the Bed color is stored in the tileEntity (extended storage in the world for a block) and not in the block itself.

Therefore, in order to get the right color from the block, I now ask the tileEntity for the block.

Then, to guarantee he places the right block and calls the tileEntity request method I did the following.

When the block is the head of the bed (we have to place both parts of all double blocks in the same tick or it won't work) we check if it gets placed by an entity or automatically. If it gets placed by an entity we get the block from the tileentity and not the conventional way and then request this.

Afterward, we set the bed (both positions) and following that we handle the tileEntity placement at both positions (both positions will need to be updated with the tileentity).

More efficient miner:

We also had some requests to make the miner more efficient and less buggy (he was standing around motionless sometimes).

For that I did the following:

First, I store the current and last node in the building.

Then, I adapted that we do not get a random node, but in a percentage of cases, we just get a close node.

For that, we'd calculate the chance, and if we want the close node iterate through the closest node recursively (with a max depth level of 3 to avoid infinite recursion which is extremely important).
Each iteration we would get a random neighboring node and if that one does not exist or is the main shaft we'd go one level deeper.

Memory leak:

I was also able to find the memory leak we had which was caused by the miner not deleting his workOrders which got stored and would eventually cost a lot of RAM and CPU (to iterate through them every few ticks).

I fixed this with two actions:

• Call super.executeSpecificCompleteActions() which will close the current workOrder.
• If there are more than a threshold of workOrders of a given type we'll iterate through all of them and remove them.

Backup issues:

Also, we had issues with our backups, interestingly it was something unrelated to the backup process, it was indeed related to when we ran it.

We actually ran it before we initiated the colonies which resulted in backups without colonies, after moving the call of the automatic backup process this was easily fixed.

These updates should help us to run Minecolonies way more smooth on the servers again.

I hope you liked our newest updates, I hope I'll be able to make a few more PRs in the upcoming week.

PRs:
https://github.com/ldtteam/minecolonies/pull/2517
https://github.com/ldtteam/minecolonies/pull/2518
https://github.com/ldtteam/minecolonies/pull/2550
https://github.com/ldtteam/minecolonies/pull/2548