will be nce if we can set a number on stockpiles
so for exemple i have a mason building with a little stockpile next to it with only stone selected
then when i give it a number like #1 the workers will restock the pile from a other one like a bigger one
so that the mason worker dont need to walk far to get stone
18 Likes
Iâd definitely like some more control over my stockpiles. So Iâd like to add the idea of temporary/transport stockpiles, which could possibly be done the same way. For example: While clear-cutting a forest, my Hearthlings bring logs to a nearby stockpile. Other Hearthlings, and them once theyâre done, can bring the logs to a more permanent place. This saves a lot of time and uses larger villages more effectively.
3 Likes
Good idea. There is a way to do that right now: you could set the bigger stockpile to not stock the object you want to move, thus causing your Hearthlings to bring the desired object to the next closest stockpile that stocks this object.
Youâre right, though, it is a good idea. Doing what I suggested is a bit of a dirty solution, and gets out of hand quickly when the number of stockpiles goes up.
I love this idea. Having several regional âsorting stationsâ where everything goes temporarily for inventory and re-routing purposes sounds like an awesome idea. Might come in VERY handy when it comes to setting up far away mining camps and the like.
3 Likes
it would also be helpful if you have a mining camp far away, you could set up a temporary food stockpile, thus your hearthlings wouldnât have to march all the way back to your town to get food.
2 Likes
For the last days I have been playing this more frequently and I find it kinda annoying that I canât manage my stockpiles.
Iâve came up with some options to help you do just that (but I have no idea if it is hard to code)
- I would love to have a option to have stockpiles feed into one another, so that my hearthlings would be able to keep a set or a minimum number of items in a stockpile at most times.
The main use for this was that I can keep my craftâs men/woman supplied with all the materials they need near them and that they wont run around all the time to get the stuff they need
-
Bulk storage. This is a storage type that is only used to store items that canât be placed elsewhere and if there is room somewhere then a hearthling will get the item.
-
Maybe even a new class named stockpile manger that gets faster and faster when he/she levels up and also can take more (of the same sort) items with him/her if he/she levels up.
Also an idea for leveling him/her up, is XP for distance he/she has run with items (see it as strength training)
I did found a topic with a somewhat similar problem but that was to prioritize it and not manage it
1 Like
Stockpile management is something that will need to be looked at in the future. As it stands right now, it is acceptable, but will proceed to steadily worsen as more and more things are added to the game. Worry not, there will be improvements!
I was mainly curious about point one, and I think that you may be asking for something a little different. I think you are wanting to be able to have stockpiles feed into one another, so that you could setup a large storehouse for wood, then setup a stockpile near your smithy for your blacksmith to take from, and tell it to take wood from the big one? This makes a little more sense to me, rather than having you set stockpile amounts per item type per stockpile.
1 Like
that is a way better explanation of what i tried to tell in point 1.
thanks for that ill adjust it (if it is possible).
and yes i know it is good for what it is right now, I just wanted to suggest a better system so that they will look in it and maybe change it.
im pretty sure there is already a thread for this⌠will try and find it.
edit: here it is,
@Relyss could merge perhaps?
1 Like
It would be really nice if we could somehow assign stockpiles to maintain certain items. For example, I might want a stockpile near trees to collect fallen wood, but a more permanent storage pile in my warehouse. So if we could assign maintain resource x I could simply tell my warehouse to maintain enough to be full and hopefully my workers would move the wood from the woodcamp stockpile to the warehouse stockpile until it was full. It would also be nice to do theis to maintain small amounts of food stockpiles in houses. This would also be nice to be able to tell the farmer Maintain x flowers, or x turnips or whatever. We could still setup our turnip fields or whatever, but the farmer would only plant them if we needed them in the stockpile. If you cant do this in hte stockpile itself, maybe have a ledger or something craftable that we can assign to a stockpile. Maybe make a Farmers shed or somehting like the carpenters stump.
I would like to setup a small stockpile by a carpenter for wood, and another small stockpile by the workbench for output, so that the carpenter doesnât have to walk all that far.
The problem is that the small stockpiles empty/fill, and the carpenter ends up walking all the way to the main stockpile anyway.
It would be nice to say that certain stockpiles were able to be set to fill (keep full, even if you have to pull from other stockpiles), hold (current behavior), or send (if there is any other stockpile that accepts this stuff, move it on) behavior.
This would allow a better managed logistics system, which will be needed once further production chains begin to come into existence, and free the expert tradies from unneeded hauling duties.
thatâs good idea. maybe settings to stockpiles that you can choise. "this stockpile is important/less important/normal
or like that settings. so if you set one stockpile to important, your workers keep it full, and less important, your workers fill it after important stockpiles is full, normal, just like now all stockpiles.
The problem is that youâre thinking backwards. Or rather, the game does it backwards. Instead of an item searching for a stockpile to go, itâs actually stockpiles that search items to be refilled. That makes it easier (by always taking the closest item to a stockpile, rather than searching the closest stockpile for every item - youâll likely have less stockpiles than items) to manage code and performance wise, but does kind of disallow any sort of priorisation.
Itâs not impossible to change that (for example, stockpiles could constantly search for items, keep that list, maybe even create a lease on the item), but it would require some thinking.
3 Likes
So it currently works just like sorting clothes then? Whenever I put away clothes, the closet always searches for any nearby and orders me to get them.
What? You mean that doesnât happen for you?
3 Likes
Whatâd be an interesting feature to see would be if you could specify which stockpile you want materials to go to when you give a harvest or mining command. Maybe this could even be extended to assigning stockpiles to entire zones, such as farming, trapping grounds, and pastures (which could also get reassigned after creation).
Of course, that doesnât necessarily solve the problem of dropped items. Maybe a tab can get placed on the collected item (visible and changeable by the player in the GUI), retaining its intended destination unless otherwise specified? Iâm not sure how intensive such a system would be for the gameâdo any of you code masters have an idea? I assume it wouldnât retain the pathfinding, only the destination entityâs name/info. Destruction of the destination should result in the removal of the tab, leaving an item open for general, unspecified collection and storage.
Personally, I wouldnât mind being able to set destinations for crafting orders too (and assigning stockpiles to workstations), but that does run the risk of becoming too excessive with management. The issue of course is keeping the input stockpile filled with the necessary resources and materials for crafting.
1 Like
Like Iâve said, youâre currently looking at this the wrong way around. Items donât search for stockpiles. Stockpiles search for items. Think of it as some sort of pathfinding liquid: It spreads evenly out from a stockpile and every item it touches is checked for its availability (âDo my filters match this entity?â). If it does, the worker will carry this item to the stockpile - so only after it was decided which item is to be carried, itâs actually figuring out the way from the item to the stockpile.
That makes a lot of sense, as Iâve said above. Imagine you have 3 stockpiles but a hundred items. Three stockpiles searching for items equals three pathfinders doing work. If the items were to search a stockpile, we had a hundred different pathfinders doing different pathfindings - which would be infeasible.
So: Items do not have a destination. Stockpiles are really just greedy bastards with a first-come-first-taken mentality. That makes it difficult to have any sort of priorisation done.
Example: Letâs say we have two stockpiles, Lefty and Righty. And an item.
Letâs say that lefty has a high priority of 6, and righty a low priority of 1. They both could stock the oak log.
With the current system, thereâs no way to determine in which stockpile the log will end up in. Because whatever stockpileâs pathfinder first registers the oak log will claim the log for itself. That could be lefty. That could be righty.
So how could a priority system work? Itâs difficult. It canât work this way, but letâs assume that both pathfinders were running at the same time and with the same speed. Obviously, righty would find the log first, because itâs closer. Lefty has no chance to even say âHey, that log is more important to meâ, because by the time it finds the log, itâs already claimed by righty. The pathfinder does, for obvious reason, ignore entities that have been claimed, so the log is not considered a valid entity for lefty.
Thereâs a possible fix, which is even semi-nice. Itâs a radical change from what we have currently, however, and it might even improve performance a lot, assuming a few things are done properly in the engine/game:
A service would take care and keep track of stockpiles (and items). Whenever an item is dropped onto the ground, the service will check some frames later if the item is still unreserved (to avoid messing with entities that are picked up immediately/soonish). If it is, itâs checking the item against all stockpiles, creating a list of stockpiles that could fit this item. This does not involve any pathfinding at all; itâs a simple check which stockpiles could be considered.
Once it has the list, we could start sorting it. For example, by stockpile priority. Or stockpile priority / air distance. Or whatever heuristic might seems appropriate. That way, we would end up with one stockpile that has âwonâ the census by being the most appropriate one.
If there was no eligible stockpile, the item could be added to a âreserve listâ. Whenever any stockpile is modified or one is removed/added, every entity in the reserve list is considered to be âdroppedâ again, therefore querying all stockpiles again.
At this point, we have both a stockpile (the destination) and the item that needs to go there. We can now tweak the AI even further by doing a BFS-search from the item and find the closest (free) worker to move the entity. This has the advantage that hearthlings no longer run across the whole map when thereâs somebody closer by; because it would always pick the closest worker.
So what we would gain:
- Customizable stockpiles: Priorities, quantities and all these things could become possible, even on an per-entity basis (i.e. fine chairs have a priority of 100, normal chairs are not stocked). By plugging lua into this, you could have filters and priorities that are as fine as you want them to be. It would also be possible to have âroundaboutsâ stockpiles; i.e. âI take oak logs with priority 100 until I have 20 of them; then I donât take any moreâ.
- Customizable items: This whole process could be a bidirectional thing. Stockpiles filter and prioritise themselves, but the item can pick too. For example, you could define a region and everything inside that region is taken to stockpile X, no matter what the stockpiles themselves want (for example, have all stuff from your mines put into some intermediary stockpile at the entrance to avoid hearthlings running across the whole town because thereâs a designated stockpile elsewhere). This picks up @Atralaneâs idea of tagging items.
- Improved performance: Because there is no continuous pathfinding involved anymore, the game can use these resources for other things.
- Improved AI: Items are taken by the closest worker, not the one whose PF found it first. Therefore, weâre reducing the overall walking and standing around in odd places.
This is based on some assumptions:
- There is a proper callback to find out when an entity was dropped into the world. One can trace the terrainâs entity_container to find out when children have been added, which could work. However, workbenches do not add the items to the terrain but rather the workbench, and the PF can/is doing recursive searches; so our service would need to do that too (i.e. instead of just tracing the terrain, it needs to trace every workbench too, and every other entity that can act as container).
- The stockpile components need to inform the service whenever a filter is changed. If the filter is expanded (i.e. less entities types may be stocked), all now unfitting entities must be reported as âdroppedâ. If the filter is reduced, the service must check if there are reserve entities that could be stocked. The same applies to removing/adding stockpiles.
- For the closest-AI approach, there would have to be a way to find out if a worker was currently âidleâ. I suppose there could be, because you could simply check for idle actions (i.e. if your current action descends from stonehearth:idle). There would also need to be a way to dispatch tasks to entities directly. I suppose thatâs all stuff the task scheduler does, so in the very worst case that could be recycled.
It sounds like fun to do, actually.
7 Likes
This was entirely too much fun to read! Thank you for this gem.
Would it be possible to add some stacking functionality to stockpiles? Whether visibly stacked or not, such that one tile holds 2+ logs, for example. 1 item per tile takes up a lot of prime real estate, imo.
1 Like
[quote=âValnus, post:17, topic:10594â]
Would it be possible to add some stacking functionality to stockpiles? Whether visibly stacked or not, such that one tile holds 2+ logs, for example. 1 item per tile takes up a lot of prime real estate, imo.
[/quote]this kind oâ stuff has been discussed in other places, will try to find em later.
Found one 
1 Like
and thus i realize how insufficient i amâŚ