Employed villagers will only eat if fired
kmarple1 opened this issue · 15 comments
Minecolonies version
Version: 0.10.49-ALPHA
Expected behavior
- Villagers should eat when hungry, if they have food in their inventory or a restaurant available.
Actual behavior
- Villagers with a job will perform expected behavior only if fired from their current job. Rehiring doesn't stop them from eating until full.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Quick note since the edit link isn't working for me: they'll line up at the restaurant while employed, but won't actually eat unless I fire them.
I never have this problem at all. Mine will stop at random walking through town to eat or will line up at the cook and wait for food.
I've noticed that if their hunger bar is completely empty, like on a newly hired arrival, they won't go to a restaurant to eat, and indeed will complain that they don't have one, despite all the other colonists using it correctly. Is the "go to restaurant" job not properly exempted from the hunger check?
OK, this may have something to do with unmet requests. I had a builder waiting on stone that only ate once the request was fulfilled.
i can confirm kmarple1 report, workers do not eat if waiting for resources. they hunger can drop to zero, and they start eating when you deliver the resources to them
just i want to mention this: actually i see the food requirements are too high, and citizens are consuming food like crazies. if you make workers eat food wile waiting for resources (and thus, doing nothing) it will just agravate the food consume. It is possible to minify the hunger drop if they are wainting, sleeping or doing nothing?
Yeah I looked into this when I was digging for the rs logic. I am pretty sure that this has nothing todo with the rs. On the other hand we should check the conditions for the eating taska
Not fixed, has been reintroduced, or another very similar bug.
I've yet to fully narrow down full reproduction, but it definitely has to do with the request system. If they just get hungry on the job, they'll eat fine, but if they are currently requesting something while also being hungry, they won't eat, but since they are hungry, they won't accept fulfilled requests either. This does not happen 100% of the time, but does happen often enough to cause trouble: I noticed it most with the miner.
If I manually fulfill his request, the item goes to inventory and the request is complete, but he will not move or eat; while the request is open, he will not eat either. If you fire him, feed him, then re-hire and fulfill request, he works fine.
I need a way to reproduce this so I can check what exactly the problem is. If you got a small world where a worker is doing that at the moment, I could debug that world too.
So i checked the ai classes and your point that this is caused by the rs is simply impossible. We use two different vanilla Mc entity tasks to achieve eating and the general citizen ai that the logic for the rs is part of.
The eating ai has a higher priority so it will abort the normal ai, on top of this the waiting for requests task as part of the normal ai, is Implemented like any other ticking loop we have, the smelter does for example the same while he waits on furnaces to complete.
Without a proper reproduction this still just conjecture and I can not reproduce this either.
It happened to me already when playing on our server, but I was never able to reproduce this in a smaller environment. It is weird since the eating AI has a higher priority and should be able to take over everything.
I think it should be reproducable by the following steps:
- Fulfill all the current requests of the worker you want to reproduce it with
- give the Cook enough items to stock the restaurant
- keep the colony chunkloaded on a server
After a few days at most (probably more like a few hours) the worker should be standing around somewhere with a request and hungry, fulfilling the request does not make them eat.
@Raycoms Does that PR actually fix the issue? The author of the PR specifically said it didn't.