Multiple items in one space (in stockpile)

Summary:
My stockpile seems to be capable of holding up to two items in single spaces.
Steps to reproduce:

  1. Create stockpile, fill it with items
  2. observe that multiple items fit in single spaces in stockpile
    Expected Results:
    Stockpile behaves normally (One item, one space)
    Actual Results:
    Stockpile holds up to two items per space
    Notes:
    -Items aren’t “Ghosts”, Hearthlings can move and use both items
    -Seems to happen more frequently with Oak Logs.
    -Extra items seem to count towards the stockpile’s maximum capacity (200)
    Attachments:
    Screenshots:
    Stone/String inside Logs


    Save file:
    Version Number and Mods in use:
    Most recent version as of today (10/9/16)
    No Mods
    System Information:
    Windows 10
    Intel i7 quad-core Processor
    GeForce GTX 1070 Founders Edition Graphics Card
    16 GB RAM
1 Like

I’ve noticed this for a while and it bothers me with the overlap but I haven’t bothered to report it.

It sometimes seems that when the stockpile is assigning spots in-game to blips and boops in data it ends up assigning 1 data the same spot and leaves 1 spot never used. I’ve tried to empty a stock pile then get all the stuff moved back in it and they’ll leave the same spot empty.

This issue has been around for a long time. It also happens outside of stockpiles. Easiest way to see it is to mine a mineral vein. The ores will tend to collect on top of/inside of each other if there isn’t space.

2 Likes

That’s fine. I think it comes more a problem in stockpiles cause they should all technically have their own spot to be placed.

Also with things like potions needing to be clicked on from a stockpile

1 Like

It is still actually possible to click things like potions, because parts tend to stick out from behind the other items.
This is still really annoying, especially when you’re in a hurry

It’s more just the clipping and overlap looks bad.

I’m a very neat person. Probably my biggest reason for making containers is to not see these things.

Welcome to the Discourse @ihatelag2012! (great username by the way).

Thanks for the detailed report - like @Aviex and @thelegorebel I’ve seen this many times before, but it never bothered me enough to report.

Is this actually from hearthlings placing two items in the same spot on a stockpile?

One thing I notice happening is when you have a crafting bench near a stockpile. The item gets crafted, but if you have no stockpile to put the item in, the crafter will randomly drop the item somewhere nearby. If that happens to be in the middle of your stockpile, you wind up with a double stacked item.

I’m sure there are other situations where hearthlings need to drop an item for whatever reason and randomly pick a place in the middle of your stockpile.

1 Like

I would not be so sure several items are actually stored on the same spot, but I would rather say the first item is stored normally, and the other ones are just put down on top of it.

That most probably results from a situation where your Hearthlings could not find any available spot for these payloads and just dropped them on location when stuck, in order t ofree themselves for other tasks.

To me, that results from race conditions when attributing tasks, and this problem would naturally be solved if those did not exist in the first place.
I made an attempt at describing this superseeding problem in another topic

2 Likes

I was guessing this was the cause as well, and hence why I hadn’t written it up as a bug report – I had put it down to “sub-optimal, but probably working exactly as intended.”

I don’t think it’s just race conditions in tasks causing this behaviour though; it’s a deeper issue with hearthlings carrying around items they (quite literally) have no business to be carrying around… or, er… carrying them around for? Both things, I guess – they finished their original job, but picked up more of the supply than they needed; or else they were interrupted and cancelled the job while the item was in their backpack; so they’re carrying around surplus resources for no real reason.

When they’re carrying something in their hands and their task is interrupted, they put it down. However, if they have something in their hands and something in their backpack, they won’t stop and unload their backpack. So, you get a lot of hearthlings who are in the middle of a hauling task when something happens (town alert, stopping to eat, attacked by a monster, etc.), and they’re stuck with whatever is in their backpack until some new task tells them to check for space… and they realise that they’re still carrying that item.

One possible solution is to have hearthlings remember their previous job, and go back to it if they’re interrupted. This would also prevent some of the race conditions you describe; since it would mean that tasks get completed more smoothly. However, that may be resource-intensive, since the job manager would have to remember twice as much info for each hearthlings’ task – their current, and their previous one.

An alternative is to add a “check inventory, and if you find anything, store it or drop it immediately” stage to the end of every task. It might seem inefficient to do it at every task; but really that extra step doesn’t add any significant workload to the task (either from the hearthling’s perspective or the game’s perspective), and it would mean there’s no possible situation where this issue could crop up in future. Even if something unexpected happens and the hearthling somehow manages to miss one “check inventory” step, the next job will trigger it again, even if that task is idling or healing or rallying at a banner… and if that new task gets cancelled too, the next task will provide the same guarantee. By the time four or five tasks in a row have been cancelled before they’re completed… well, the town obviously has bigger problems than who is carrying what around in their backpack; so there’s no chance for items to pile up on top of each other like they currently do.

I do not remember having noticed this behavior.
If it was the case, I would still consider that as buggy, since someone else’s task might depend on what the hearthling you currently consider is carrying in his bagpack: what happens if a carpenter needs the very last wood log available to craft a bed another hearthling carelessly carries across the map?
IMHO, hearthlings are not ‘mobile storage solutions’ and thus should always empty (at least partially) their inventory on task change, when the new task does not need the inventory contents (or at least part of it).
Allowing such a behavior prepares the ground for loads of conflicts and deadlocks.

The corollary is you are going to need to remember much more than that. Why only one? And if you consider tasks which shall not/cannot wait, you are going to need to pile them on top of the ‘normal’ one.
Remembering = memory consumption, and you probably already noticed the game has trouble with that in the current state (Alpha 17 made some early optimization steps). Not to mention memory leaks/dead leafs (game slowing down, even on new/loaded game, need to restart). Mixing that with a potentially unlimited amount of tasks to be remembered and you get a feeling of where all that goes.
My precept is generally to make simple things work rather trying to be too smart too early. There will only be room for improvement if you crush task/resource allocation bugs and your game runs smoothly with a high number of hearthlings on a big maps with loads of events on a very long session.

I see a lot of hypothesis in your ideas, and while it would be great to have some level of sophistication in Stonehearth, you won’t be enjoying those before you can build a complicated-enough structure, carry resources and executes tasks without bugs/deadlocks.
That means muuuch later (if ever) to me judging by the current state of the game. :wink:

I will thus stick to the ‘bug’ categorization of this problems and the related ones. If you sit back and looks and them fro ma distance, you can notice similarities. I would not be surprised if the underlying mechanisms were similar.

More on this, and little illustrations of the bugs & deadlocks I mentioned: not even humans are good at this.

Imagine a workshop emplying a dozen people where some allow themselves to carry tools & resources once a task requesting them has been completed/canceled while proceeding to some other occupation.
What happens if someone else needs tools or resources carried by the first person?

  • Person #2 does not know where the tools/resources are
  • Person #1 has no way to know someone needs them

The only choice left is to bruteforce the situation at hands to find a solution: broadcast a message, hoping the involved parties will hear each other.
IRL that might translating to having person #1 literally shouting all over the place, hoping for being noticed by person #2, or having person #1 spending time querying everyone until reaching person #2.

And now imagine the required tools & resources being split over loads of people. You could clearly see where that leads: chaos and productivity hell.
IRL you could even have psychological effects of working there, such as lost of motivation, etc.

You could also go one step further and imagine cross-split of stuff needed by 2 persons, wandering around the workshop asking everyone. Since one meets every other person asking about what it needs (which is being carried by the other person I focused on), they might never meet!

On the contrary, workshops where the rules are to put tools & resources back to a pre-defined location once not being used anymore avoid those caveats.
Why would not all that be true for a game? I’d hope Stonehearth to follow that path: much simpler to design, much simpler to debug, avoids a lot of pain in allowing a behavior which, in the ends, brings little-to-nought.

1 Like

Exactly, and that’s why I want the hearthlings to empty their inventory immediately after completing a task. There’s no benefit to them carrying that item around, and I don’t think it’s intended behaviour anyway.

It’s probably an oversight, even though it’s “working as intended” (i.e. exactly as the program states) I’m sure the Devs don’t actually intend that… it’s just how the program is written.

1 Like