Minecolonies & Feature Backlog #2

6개월 전

Hi everyone, this is already the second post in the series but is going to be a good bit more interesting than the first one.

Small fixes:

Previously, certain states blocked citizens from eating since we considered the execution of these states more important than eating. Nevertheless, I had the opinion that this is valid as long as the citizen is not starving (zero saturation).

That's why I added a check which will avoid the not eating when the citizen has 0 saturation.

if (citizenData == null || citizen.getCitizenData().getSaturation() >= CitizenConstants.HIGH_SATURATION || (!citizen.isOkayToEat() && citizen.getCitizenData().getSaturation() > 0))
            return false;

In the same topic, people had been complaining that our workers were eating less efficient raw food.
For that reason, I added another predicate which does not only define if something is edible but also if it is in his final "cooked" stage.

Then, I just had to substitute the isFood predicate for the canEat predicate everywhere in the code where people try to eat.

While working on that I also noticed that the cook would be stuck forever if he can't reach the citizen he tries to serve.

For that reason, I would remove the stuck check from where it was and add it in the walk check and if stuck remove the citizen from the queue and clear the path.

Another issue had been found where ArmorStands would be removed by the builder after placement. The issue was that the armor stand is not a block, this way he would in the clear stage clear the air block and thus delete the armor stand.

So I made sure to not clear air.

This is not only more efficient but also makes sense =P

Finally, when fulfilling a request sometimes not the right item was being transferred. This was the case because we only took the item damage into account when transferring the items.

Thus, I made sure that the transfer considers the equality of the item and not only the id and item damage.

This is the case since mods often add custom NBT values to an item which are not considered in the item damage.

Which brings us to the pathing changes.

Pathing fixes:

Pathing has always been an issue in Minecraft and since we needed our own Pathfinder which is built on top of the Minecraft one it doesn't make the task much easier.

One of the first bugs which were being reported was that ladder checks can break if we give a null entity (certain mods require the entity in the ladder check).

Which was easy in the miner for example.

But not so easy in the path jobs since I had to add the entity as a field.

And then hand it through all the constructors.
Until finally reaching the ladder check.

The next bug caused the citizens to spin on blocks or drop onto blocks they can't walk on (fences).

This happened because in the pathing check where we allow them to drop down we didn't check if the blocks midway are air and he can drop through them.

The fix was straightforward. I just had to add a check if the block is air in the for loop to make sure that he can drop through it.

Another issue was that our workers wouldn't move away nicely anymore when stuck. This seemed to happen because he would override the moveawayjob with his current pathing job.

That way I had to make sure that he does not only block the creation of a pathing task if one is in progress but also when one is currently computing.

On the side of the stuck handling, I decided to allow the citizens to have not only one attempt to move away.

Thus, I changed the boolean to an int.

Adapted wherever there was a boolean to consider the number of retires.

And also added that the citizens have not only a random move away range but also a minimum move away range (case the random returns 0 or 1 which is instantly true)

citizen.getNavigator().moveAwayFromXYZ(citizen.getCurrentPosition(), MIN_MOVE_AWAY_RANGE + citizen.getRandom().nextInt(MOVE_AWAY_RANGE), 1);



Pull Requests:


Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  trending
  • Great explanation of coding choices based on the game needs.
  • The RGB dots in the main pictures are a troubleshooting view of the AI paths?

Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.

To view those questions and the relevant answers related to your post, click here.

Need help? Write a ticket on https://support.utopian.io/.
Chat with us on Discord.


Exactly, green is the path he chose, blue were alternatives and red were not optimal.


Thank you for your review, @helo! Keep up the good work!

Calling @originalworks :)
img credz: pixabay.com
Nice, you got an awesome upgoat, thanks to @raycoms
BuildTeam wishes everyone a great Christmas and bullish Holidays
Want a boost? Minnowbooster's got your back!

Hi @raycoms!

Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your post is eligible for our upvote, thanks to our collaboration with @utopian-io!
Feel free to join our @steem-ua Discord server

Hi, @raycoms!

You just got a 7.76% upvote from SteemPlus!
To get higher upvotes, earn more SteemPlus Points (SPP). On your Steemit wallet, check your SPP balance and click on "How to earn SPP?" to find out all the ways to earn.
If you're not using SteemPlus yet, please check our last posts in here to see the many ways in which SteemPlus can improve your Steem experience on Steemit and Busy.