Hey everyone, I had a really productive weekend after the end of the semester and I got a lot of old bugs flattened out and things added to the mod.

Waypoint rendering:
---

First of all, I added back the waypoint rendering. Minecolonies adds waypoints on structures like streets and lamps etc. to help the pathfinding of the citizen. We do this since Minecraft pathfinding is very costly and, therefore, we added our own system based on waypoints which we deploy all over the colony. But, unfortunately, after updating a few of our rendering classes our all system to render these points didn't work anymore and we had to rewrite it.

![](https://i.imgur.com/8s7MMIF.png)


For this, we have a client event handler class.

![](https://i.imgur.com/cYqIwE9.png)

Which in turn has to subscribe to the render event which is being called every render tick on the client.

![](https://i.imgur.com/VDxI7k5.png)

From there, we check if the user wants to render a structure with a waypoint in it atm. And, if so, if this structure belongs to the waypoint group (infrastructure) and if it is inside a valid colony.

![](https://i.imgur.com/EGkCiFh.png)

Now, we calculate the relative position of the player entity in relation to which we will have to render the waypoints.

Then, we instantiate a structure template of the waypoint itself (Only needs to be done once per client session for performance reasons).

![](https://i.imgur.com/o0IVvjI.png)

Afterward, we only have to run through all waypoints within a colony.
Calculate the relative position compared to the player.
And call our template renderer for each of this positions and offsets.

Fixes:
---

Now, while I was debugging the colony I ran into a whole bunch of fixes all over our systems. I spent 2 full days debugging a colony flattening out all bugs which annoyed me on the way.

As small visual bugs as too long lists:

![](https://i.imgur.com/nAaJ8aD.png)

As guards teleporting on roofs because they are stuck, which I prevented by limiting the y difference they can teleport.

![](https://i.imgur.com/15BZCzJ.png)

As fixing an issue where citizens should sleep during barbarian attacks but they didn't obey because we handled it in the AI and not in the decision if they should sleep or not.

![](https://i.imgur.com/wyckty0.png)

> So I added the above to the sleep decision and removed it from the AI.


I also fixed the death penalty of citizens when barbarians are close:

![](https://i.imgur.com/ozT7zPb.png)


> If a citizen gets killed by a player in a colony the happiness of the colony falls to 1, but sometimes they are killed by accident while fighting the barbarians, so they shouldn't affect the happiness so strongly.

The problem was that a new citizen with the wrong position had been taken to check the position and not the citizen we were executing this in.

We also had to make sure that the horde is calculated correctly as barbarians might not be killed and might despawn.

![](https://i.imgur.com/j4dlL8g.png)

Therefore, we added a cleanup task to the method which checks if the entity still exists.

And finally, what took me weeks to figure out:


Request System fixes:
---

Minecolonies is built on top of a complex request system which allows workers to do asynchronous and synchronous requests (blocking and non-blocking).

Now, I fixed one small bug, which triggered two other bugs which I resolved afterward.

I had placed a cook which requested food, but although there was food in the warehouse the deliveryman didn't deliver it.

I debugged this and found out that the request only tries to resolve exact quantity matches.

Therefore, I removed the exact quantity match of all requests.

![](https://i.imgur.com/nw0A4H2.png)

![](https://i.imgur.com/BGNfxle.png)

etc...

Unfortunately, sometimes workers like the cook and smelter executed async requests and got stuck in an infinite resolving loop.
I only recently found out that this happens because their building tries to resolve their requests.

After I had deployed the above fix this started happening really often and I found out this was caused by the following:


> The cook wants to have at least 120 food at all times at his building to be able to supply all possible workers
> The cook will request 64 food since he has less than 120.
> The cooks building notices it has 20 food which is not enough, but since it doesn't need to resolve it exactly it will tell the cook that it can solve the request.
> The cook will then try to pick it up and notices he hasn't enough and he creates another request which in turn the building instantly accepts.

After I found out how this was happening I figured that buildings actually do not need to resolve non-blocking requests since all over our code, the AI actually checks if the buildings have enough and then requests if not, or retrieves from the building if it has the required item.
This means the building resolver should skip these.

Therefore, I added a check to the building resolver to avoid resolving asyn tasks:

```
if (building.getCitizenForRequest(request.getToken()).isPresent() && building.getCitizenForRequest(request.getToken()).get().isRequestAsync(request.getToken()))
{
    return false;
}
```

and I added to the resolver that the async task list is filled before sending the request to the system to be assigned to a resolver.
(Else the resolver wouldn't be able to detect it).


```
/**
     * Create a request for a citizen.
     * @param citizenData the data of the citizen.
     * @param requested the request to create.
     * @param async if async or not.
     * @param <R> the type of the request.
     * @return the Token of the request.
     */
    public <R extends IRequestable> IToken<?> createRequest(@NotNull final CitizenData citizenData, @NotNull final R requested, final boolean async)
     {
        final IToken requestToken = colony.getRequestManager().createRequest(requester, requested);
        if (async)
        {
            citizenData.getJob().getAsyncRequests().add(requestToken);
        }
        addRequestToMaps(citizenData.getId(), requestToken, TypeToken.of(requested.getClass()));
 
        colony.getRequestManager().assignRequest(requestToken);

```

And then to the calling methods, the boolean if async or not:

![](https://i.imgur.com/DhOXju2.png)


But the happy end was not quite there yet.

After deploying this I noticed that the loop was broken but that the worker requested it and the request was only once checked against the resolvers and then never again touched.
I debugged the retrying resolver for a while until I noticed that it didn't have a correct instance of the request manager to reassign the request.

What I quickly fixed by assigning a valid one before each call to the resolver.

![](https://i.imgur.com/0szr3Vp.png)

Our players are pretty psyched by the new update since it will make minecolonies way more stable and the cook finally a reliable provider of food in their colony.

I hope you enjoyed this little update. Until the next time!


Pull requests:
https://github.com/ldtteam/minecolonies/pull/2630/files
https://github.com/ldtteam/minecolonies/pull/2627