Design issue 0.7d - Trouble with Flour Reloaded (or is it with item management?)
#1
I had problems with my imps not producing antroots, flour, been and bread start up rather abruptly in my game. I tried to post in the original bug report but unfortunately I didn't have permissions to post there so I'll have to post it here instead.

What happened is a convergence of events that lead to my production chains getting halted, first, I had several hundered coal being transported to a store room near my new ironworks room, next my DM room's storage barrels got filled up, and this led to a stoppage in my whole food chain (except for the fish). After reading some of the discussion in the original "Trouble with Flour" thread I realized there may be more things going on then just the %chance an imp will make flour out of an antroot.

When I looked more closely at my DM store room, after the imps had finished transporting that coal to its new store room, I noticed a lot of that coal ended up dumped in the DM store barrels when I cancelled the "store all coal here" order for the store room linked with my metalworks room. I had to do that to head off another probelm I saw in the works, if the store room for the metalworks room got clogged with coal, none of that coal could be used to produce iron ingots since the smelters would be shut down due to a full store room, which would remain full since none of the coal's being used because it's primary consumer is shut down... and so on, in a classic "Catch 22" situation.

Unfortunately, in heading this issue off, it created another, entirely new issue, and locked up my food production in that same "Catch 22" scenario instead. I'm guessing that when I cancelled the Store Coal order, the imps eventually started just picking up the remaining coal and storing it wherever they could find room for it, which filled up the store room my food chain depends on.

Basically, I think we're looking at issues with the room linking and item storage system and that these systems need to be tweaked to fix these issues. One option would be to allow rooms to be optionally connected to a secondary store room which would allow a production chain to survive one single store room filling up from shutting down an entire production chain. Ultimately, though, I think the entire item management system still needs more work.

The ability to mark items as "store here" or "don't store here" has helped. If those options weren't there, this I would have had no possible way to recover from this issue. This solution however, involves a lot of micromanagement as I had to keep monitoring my store rooms and switching items between store modes to balance out my production chains with my item management policies.
[Image: 11619898803_7d3a89e6bd_n.jpg]
The Golden One!
Reply
#2
There is definitely a problem, the catch 22 situation you described is something that need to be dealt with. I can't say now if the issue is because of a bug or that the whole system is flawed. There are some ways to solve the issue once and for all and that is to enable storage for all items in the storage room but that each item only can be stored to a certain amount. Unfortunately this solution will take away much of the dungeon management and forcing the player to really plan the dungeon. I imagine there is a certain charm in creating a really large dungeon and get the productivity to run smoothly and that there always are a chance for items clogging up if the player is not careful. But the penalty for this should not be a catch 22 situation where it is near to impossible to solve the issue.

I still believe the current room linking system, but I do feel that it needs to be simplified down a lot. There is a very steep learning curve that can get unexperienced players to never look back at the game, also because there are so many things that can go wrong it is very hard to find where the issue is when things are starting to go bad.

Either way we will keep on trying to perfect it more and more, we can't go back to where all the imps are able to do all the work. I think there is a solution for all this somewhere in the current system, I did like the idea of removing the rooms all together, but we still need to group the buildings somehow.

I try to imagine how a society is run today. Each person has their own job and their own responsibility, but we are still depending on others to do their job so that we can do ours. A society also have safety-nets when things are starting to go bad, when people call in sick there are always others to replace them, and when there is much to do there are always people that can be called in to work extra, and when things are starting to go really bad there are help organizations that will try to keep the society from collapsing.

Dwelvers has none of this...

As for now I feel like there are two ways to go, either find a new system that will replace the room linking system or perfect the current one and maybe simplify it, and also try to get some safety nets in there like having extra workers come to aid when things are starting to clog up, or giving the rooms a option to stock up on items somehow so that even when things are going bad the player has ~10 minutes to solve the issue before the production chain starts to fail. One way is for the game to be able to see the issue and re-prioritize the workers and solve it before it arises.

This is just me brainstorming a little.. For each version released we will get closer and closer to a solution to this problem. But I prefer small changes instead of reconfiguring the whole system. What is the next thing that could be done to make the system work a little better? (Fixing the bugs are a given Wink)
Reply
#3
IMO the system I mentioned earlier in another brainstorm thread would solve this with minimal extra coding. Most of the basic features this idea would use for implementation are already built in your normal, store here, don't store here modes.

Having each item have a minimum number to store value could be used to automatically that item to "store here" mode until it exceeds that minimum value, at which point the "store here" mode would be automatically turned off (default minimum for all items would be 0, which would function exactly as it does now).

Each item would also have a maximum value, this is the upper limit to how many of that item a room accepts, so if an has equal to or more then the max value stored there, it automatically goes into "don't store here" mode until that item's quantity is reduced to below the max value. The default value for this would be the store room's capacity, which again would function exactly as it does now.

Whenever an item has between the max and min values stored it would function in normal mode.

So this would be an option to automate changing modes to optimize store room usage, and could give a way to prevent a catch 22 from occurring, at least one that's out of the user's control. If the user's own settings cause one, that's easily solvable by changing those settings, and when such an event occurs could even cause a warning in the message system.

This sort of system may create the need for a bit of extra settings management whenever the dungeon layout is changed in any way that affects the production and storage chains, but once set would need no managing unless a problem arises. Basically I look at it this way, the 3 store modes are a micromanagement option, which should stay as an override to the min-max options, but the min-max settings would be a macro-management option, set up how you want items stored and then leave it to the imps to get it done, and they'll automatically make any adjustments to the store modes of each item in each store room to maintain the item storage policy you set.
[Image: 11619898803_7d3a89e6bd_n.jpg]
The Golden One!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)