Beds never get undeployed, even after several nights of all hearthlings being idle.
Steps to reproduce:
Load either attached save.
All beds get undeployed that are flagged.
Only about half of the beds I asked to get undeployed, got undeployed.
I can deploy and undeploy other items and hearthlings complete these tasks immediately. Asking to move the bed moves it immediately. I already deleted these beds in future saves via console to make progress.
I don’t consider this “not a bug”. I shouldn’t need storage to undeploy as the ground is available. I shouldn’t be required to create storage for something that I don’t want to store. I just wanted to sell these and/or use them for Comfy Beds. Crafting production doesn’t normally halt because I don’t have storage. It is unintuitive behavior for undeployment to halt because I don’t have storage. If they refuse to undeploy without storage, there should be a pop-up icon a la building completion being inhibited to indicate there is a problem.
Edit: Side comment, if there was storage when they undeployed, but storage ran out or the hearthling got hungry/sleepy, he would dump the bed on the ground.
Right, but the game’s code doesn’t see it in such gray logical terms. It requires that you have open space in a stockpile of the correct type and without it the hearthlings simply don’t understand what to do with the bed.
Depends. I would view deploying/undeploying as a “build” task. It seems that undeploying, at least in part, is viewed as a “hauling” task. Whether the undeploying can be delivered to a storage IMO should be part of a “hauling” task that would not be queued up until after the bed is undeployed. The “build” task of undeploying should have nothing to do with whether storage exists or not, the same as crafting is not dependent on storage. Considering the hauling aspect of undeployment to decide whether to perform that task was a design choice that IMO results in bug-like behavior.
Edit: An additional example is chopping down a tree, mining, or other gathering task is not dependent on storage. This is an inconsistent design paradigm, which in game design is a point of frustration and IMO a bug.
I over produced mean beds so I had a fair amount in storage. I wanted to sell some that I didn’t need, and use the others for upgrades. I already had more in storage than I wanted to sell.
Great question. Probably? I would assume so, at least. See above. I destroyed them out of impatience before a salesmen came around that would have inadvertently solved my problem.
I’m perfectly fine with this being moved to suggestion, as it currently is. I was not fine the status not_a_bug aka working as should aka developers disregard. Whether something that goes against user experience and design principles is a bug or a feature in need of improvement is more of a religious/philosophical debate. Let’s not get pedantic about the definition of a bug. Wars have been fought over less like
Well, it would be tedious otherwise since if the undeploy only undeployed and didn’t give them in their hands immediately it might be a case of a different Hearthling far away trying to get the item that is now on the floor,
That’s why i suspect the game says “undeploy this and put it in a empty slot by the one undeploying it”
To clarify, I don’t think this topic is that important, since it is a nuisance, and not critical in any capacity. I am just maintaining discourse. I would much rather the developers work on many other issues before this one.
I agree that is separate, but related issue. However, civilians dropping what they are holding is:
widely accepted, if not status quo, in this genre.
still preferred behavior to me because at least they still do what I want without intervention.
Maintaining a sub-optimal design decision because of other sub-optimal design decisions is serious anti-pattern, specifically commitment bias, and not a valid argument.
There is no reason a hearthling couldn’t attempt to complete tasks with items in their hands first, put the item in their back pack and/or take it back to town before arbitrarily dropping on the ground (among other potential solutions).
It is very likely a developer (even a random unfamiliar one like me) could fix, but not exhaustively test, either of these issues in less than a regular workday.