After the last updates creating new workers we're focusing again on bringing more stability.
If you want more info about what we're doing, check out our website or wiki:
http://www.minecolonies.com/
https://wiki.minecolonies.com/
Some fixes:
First, I added some null checks case people configured the crusher wrongly.
Then, the builder got stuck with null stacks so I added a null check to filter the stream.
Then I noticed that our code comparing ItemStorages doesn't do a valid equals check.
Besides that the max citizens per config setting wasn't being followed accordingly.
I noticed it wasn't checked accordingly in the code which checks for the max to spawn more kids.
Besides that, citizens were sleeping in bed with a block at the head position which made them die, so I added a check to avoid this.
Inventory improvements:
Also noticed that we were calling the wrong method to get the valid itemStacks for chisel and bits block (we were calling the structurize method which doesn't have support for this)
After doing some debugging I noticed that we were losing a lot of performance with inventory actions.
Digging deeper into it I noticed that we were not filtering handlers validly quite often.
So, what happened is that per provider of inventory we added it up to 7 times. (Once per direction and one without direction).
This was because the comparison of two inventories is based on the instance and not based on the actual inventory.
So I made sure that, for example, the citizen only returns one which we cache.
More complex it was for buildings, since we want to check actually if we have an inventory from all sides but we can't cache it too long since the inventory of a building expands if more chests are added.
So I also added a cache.
Which we fill if null.
But every ticking update of the actual building we will reset it.
This way, during one single request within the same tick it will be more efficient since the work is quite big to join in all the inventories but at the same time it will be more efficient since it won't have to search 7 times the same inventory space.
Correctly request bigger quantities:
So, first of all I added the count to the stack request.
Then, I added that we don't break after adding one result stack back to the inventory. (Case there is more left)
Then I added that in the resolver of the building which tells the worker how much it has doesn't break after the first, but sums it up.
As a detail I used an atomic integer since you can't increment non final variables within a stream (side effects).
Then, I added that the worker picks up all delivery stacks and not the difference.
Else we would always have to request the total quantity and not the difference between total and what we have.
Then, at the inventory I added a "force" variable which checks how necessary it is to have all items we need on a request.
If force it is true we go through all the items we have to calculate correctly the difference.
Then I'd calculate the total amount from the difference.
And make sure we take this calculated amount.
Later I noticed that in some places we were not requesting enough blocks.
Building Naming:
Then, I finished some work of another coder which left it behind a while ago.
So I fixed up the message to only work on the server side and add it to the building.
And cleaned up the way to make sure if no custom name is given the default is chosen.
Pull Requests:
https://github.com/ldtteam/minecolonies/pull/3483
https://github.com/ldtteam/minecolonies/pull/3485
https://github.com/ldtteam/minecolonies/pull/3489
Repository
https://github.com/ldtteam/minecolonies/pull
Thank you for your contribution.
checkForListInInvAndRequest
especially you have made quite a lot of changes which need to be covered by tests.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? Chat with us on Discord.
[utopian-moderator]
Thanks for the evaluation.
Usually, we either add logging where we don't expect nulls to happen at all. In some places, where it can happen due to the code flow, we don't.
I agree with the unit testing part, but, this is not so easy since mocking Minecraft is not an easy part at all. When we extend our API we plan on improving the way we handle Minecraft libraries to make mocking much easier.
Thank you for your review, @justyy! Keep up the good work!
Very cool
Posted using Partiko Android
Hi, @raycoms!
You just got a 10.25% 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.
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
This post has been included in the latest edition of SoS Daily News - a digest of all the latest news on the Steem blockchain.
Hey, @raycoms!
Thanks for contributing on Utopian.
We’re already looking forward to your next contribution!
Get higher incentives and support Utopian.io!
Simply set @utopian.pay as a 5% (or higher) payout beneficiary on your contribution post (via SteemPlus or Steeditor).
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!