Suggestion for stockpiles that should solve a few problems.

[Mike-al]

The fundamental point is I dislike the way that suggestions are being treated on the suggestion forum at the moment. Sure, say how the existing interface can let you achieve something, maybe provide some constructive criticism - but the extreme disdain and need to refute every idea which is rampant at the moment will just drive away suggesters. I trust Generic Container will exercise judgement when reading the suggestions.

If by this use of the passive voice you mean me specifically, then say so. In my opinion, not naming names is much, much more rude than doing so. If you mean me, can I please have some examples of "extreme disdain" and a "need to refute every idea"? Have you actually read this thread? In responding to Maklak here, for instance, I agreed with nearly everything he suggested.

But even if the suggestion itself is flawed, there may be part of a good idea in there. If we discussed it perhaps we'ld come up with a nice new system that is even better, maybe by combining it with some other suggestions.

You have a strange definition of discussing things, because I could swear that you and Walker were, in fact, discussing it just now.

I wasn't trying to be technically correct and honestly I wasted too much time writing that post anyway. And this one. Takes hours and then someone nitpicks through the whole thing.

That doesn't seem to be an attitude that's conducive to discussing things, if you consider participating in a thread wasting time.

't about claiming that the game needs to be learned instantly on first glance, or achieving perfection. It is about suggesting incremental improvements to mechanics and UI to make the game more usable/learnable. If it is possible to make it easier to handle certain aspects, why not do so?

Who says we shouldn't?

Then please participate in discussion in a constructive manner and perhaps we can come up with a system that does.

Define constructive, if you don't think Walker's replies are.

Constructive criticism, not telling them the current system is fine and their problem is non-existent. Or that it isn't worth developing the changes to the UI. Or they should read the forums to learn how to play.

Who's said anything like any of those, and where? I, for one, have repeatedly said that the current system is far from perfect and stands improving. And that the UI specifically isn't perfect. Nor have I said that anyone should "read the forums and learn to play".

But really it doesn't feel like suggestions are welcome at all at the moment either.

I don't understand what it is that you want. Should there be people replying to every suggestion thread with "Hooray! A suggestion! That's great!" and nothing else?

Implementation-wise, yes. Suggestion-wise, no. This is a response to so many "the current system is fine" rebuffs to suggestions.

When has anyone on this forum said that because the current system is, in some respects, fine, no-one should be making suggestions at all?

True, so suggest how these ideas can be improved!

What if one doesn't accept the premise of the idea at all? For example, some people are complaining elsewhere about monsters spawning from permanents like the stone quarry. I, on the other hand, feel that this is a key game mechanic that shouldn't be changed. How do I "improve" that idea when I don't agree with it at all? Or is your point that no-one is allowed to disagree with a suggestion? Then this isn't a discussion forum but simply an idea repository.

[immortius]

I take serious issue with that. When have I "blasted" someone for making a suggestion? Are there some civility rules on this forum that say no-one in the Suggestions forum is allowed to say "I disagree with your idea" or "I don't understand what your problem is", the latter meaning literally what it says?

viewtopic.php?p=3258#p3258 - "Rubbish. You're just doing it wrong."

The person explained what he felt the problem was and suggested some possible solutions, and you just told them they were doing it wrong.

You are right, there are no rules on the forum (or I can't find them anyhow). I personally would feel you don't assume good faith on the part of people post to this forum, and are overly abrasive in your replies, but if you don't see things the same way then fine. I've said my piece.

In my opinion, this would make the whole stockpile menu much more confusing, and that would offset the gains.

See screenshot below and comment. I find it hard to believe there is no way to handle moving items between stockpiles that would be acceptable. I would be quite happy with just two states and items removed from stockpiles if they are deselected too, but I understand that you don't like that idea. I will agree that having target numbers or sliders for each item would be over the top. Some other possibilities might be to be able to be able to specify a number of goblins dedicated to rearranging items, but that seems too different from existing mechanisms and maybe a bit too uncontrolled? Or maybe a single button in the Stockpile interface to request unaccepted items be removed?

[Walker]

The fundamental point is I dislike the way that suggestions are being treated on the suggestion forum at the moment. Sure, say how the existing interface can let you achieve something, maybe provide some constructive criticism -

What's your definition for constructive criticism? Asking a person to justify his suggestion by demonstrating a problem and showing how the suggestion is an improvement seems constructive to me. First passes of many suggestions too often take the form "here's how I think this should work" or "this is how things work in another game". Devil's advocate can help improve those suggestions, too.

I trust Generic Container will exercise judgement when reading the suggestions.

He has largely kept his own counsel, but that doesn't mean we need to let suggestions here go without feedback. Presumably they are submitted here to be discussed.

That's precisely the point. Why make things more difficult? Currently, if you want to move wood from one stockpile to another, you allow wood for the second, and dismantle the first.

Those two processes aren't equivalent. The first is totally destroying a stockpile to move all its contents elsewhere. The second moves part of the contents while the original stockpile still exists.

They are when you want to move all the contents elsewhere. The question arises which use cases are typical. And an even better question "what is the player trying to accomplish"?

Actually I mean usability, of which learnability is a subset and accessibility is related. I wasn't trying to be technically correct and honestly I wasted too much time writing that post anyway. And this one. Takes hours and then someone nitpicks through the whole thing.

Did you really mean to say that you want us to discuss things, but think participating in a discussion is a waste of time? Or am I nitpicking again?

This isn't about claiming that the game needs to be learned instantly on first glance, or achieving perfection. It is about suggesting incremental improvements to mechanics and UI to make the game more usable/learnable.

If it is possible to make it easier to handle certain aspects, why not do so?

If it is counterproductive to wider aims it shouldn't be done. If SMB came with a button to auto-complete a level, it would make things easier, and pointless. The backrest on my chair is comfortable, but a backless chair would spare me a lot of back pain in the future.

Why do people want to move things between stockpiles? I almost never do that, and it seems an indication of failed planning. If, and I don't assert it is, the reason for the feature request is to cope with the results of failed planning, having to tear a failed stockpile down and build a new one sends a stronger signal that mistake was made, and may thus facilitate faster learning of good design principles. I think game should steer players towards good habits.

That is, UI should make it easy for people to do things they should be doing, but it is not necessary to make it easy to do things they shouldn't be doing. Simply suggesting an interface change without explaining what use case is being served is not most useful thing.

We certainly don't want things moving in the opposite direction, do we?

Depends on things. Games are something of a special case in UI design, as it is often not desirable to make things too easy to player. Interface in a strategy game, granted, rarely falls in that category.

Intuitiveness is overrated, it is enough that things are learnable.

Things which are intuitive are easy to learn though. This is one of the reasons physics games are popular to make, because the mechanics line up nicely with our expectations of how things should behave.

Yes. First placing a container and then putting items in it fits my expectations. You don't first fill a warehouse and then try to add shelves. It's good when game mechanics line up with the real world, but I'm not sure they need to line up with expectations formed by other games, for example.

My problem with many of the supposed fixes suggested on this forum is that they don't actually propose a clearly superior system, or at all address the underlying learnability issue: they merely swap one set of expectations for another.

Then please participate in discussion in a constructive manner and perhaps we can come up with a system that does.

If you think I'm not, I'm not sure I can be a lot of help.

Surely their suggestions are open to criticism.

Constructive criticism, not telling them the current system is fine and their problem is non-existent. Or that it isn't worth developing the changes to the UI. Or they should read the forums to learn how to play.

Has anyone actually said any of those things?

It needs to be made more obvious, but that doesn't necessarily mean introducing a new way of doing it. Pointing out that the current way to do it is the way to do it would also work.

That would also be fine, but the destroy->recreate stockpiles mechanism may also just be a work around rather than a proper way of doing it. It seems very heavy handed and generates more jobs than necessary if you only want to move some items.

Orcs should be heavy-handed, so it fits the game. But we come again to the question why players would want to move things from container to another. That should be answered before considering UI solutions.

I can think of two scenarios right now:

1) Recovering from failed stockpile allocation. In this case I think game should signal the player they have failed, and current system does that well. Also, there's no reason to move decaying items, as they will rot away on their own, and items in use will be removed eventually. That's not obviously slower than goblins removing them as low priority jobs, and if the player needs this done ASAP, he'll probably end up blowing the stockpile anyway.

2) Moving things from a remote stockpile to one closer to point of use. This is a thing I often wish I could do with charcoal. Currently there's a trade-off between fire safety and efficiency. Ability to feed items from one stockpile to another would reduce the efficiency penalty, but that would make the problem less interesting, and so the game a little more boring. I'm not sure supporting this functionality, much as I'd want it, would be an overall benefit to the game, especially if it made stockpiles more complex.

True, but an interface change to afford one's preferred style of play doesn't automatically make a game better. And some of the suggestions here end up with every item in every stockpile surrounded by checkboxes and sliders, and I don't think that would contribute to gradual learning. On that front, I think, GC is doing well, with every tier opening new constructions, and every new construction introducing new items, though the tier progression may still be a little fast.

True, so suggest how these ideas can be improved! What I like about the Accept/Hold/Refuse system is it merely adds an extra state to the existing system, minimizing the change to UI and not adding any clutter. And it is also a proven mechanism in Caesar 3. But I guess the check box needs to make obvious what those states are and mean somehow.

Okay, here's a suggestion: if 'hold' is merely 'don't accept', why is it a separate check box? Just have the check boxes for 'accept', like now, and 'remove'. There's even a case for checking both: sending things from a stockpile close to point of production to one closer to point of use.

But that doesn't necessarily make things more learnable than things are now; player would still need to learn what 'remove' does. Lack of documentation is currently the biggest problem, IMO.

But really, I'd like a convincing case made for including the functionality before planning an interface for it.

[immortius]

What's your definition for constructive criticism? Asking a person to justify his suggestion by demonstrating a problem and showing how the suggestion is an improvement seems constructive to me. First passes of many suggestions too often take the form "here's how I think this should work" or "this is how things work in another game". Devil's advocate can help improve those suggestions, too.

I consider both of those things are constructive, at least when not presented abrasively. I don't have any issue with your posts, I was out of line with those comments.

Actually I mean usability, of which learnability is a subset and accessibility is related. I wasn't trying to be technically correct and honestly I wasted too much time writing that post anyway. And this one. Takes hours and then someone nitpicks through the whole thing.

Did you really mean to say that you want us to discuss things, but think participating in a discussion is a waste of time? Or am I nitpicking again?

I guess I'm just bemoaning how long it takes for me to write these replies, double or triple checking things and then still screwing them up. More my fault than anyone else's. I should know better than to use accessibility instead of usability. I wasn't thinking in the non-functional requirement mindset though.

They are when you want to move all the contents elsewhere. The question arises which use cases are typical. And an even better question "what is the player trying to accomplish"?

...

If it is counterproductive to wider aims it shouldn't be done. If SMB came with a button to auto-complete a level, it would make things easier, and pointless. The backrest on my chair is comfortable, but a backless chair would spare me a lot of back pain in the future.

Why do people want to move things between stockpiles? I almost never do that, and it seems an indication of failed planning. If, and I don't assert it is, the reason for the feature request is to cope with the results of failed planning, having to tear a failed stockpile down and build a new one sends a stronger signal that mistake was made, and may thus facilitate faster learning of good design principles. I think game should steer players towards good habits.

That is, UI should make it easy for people to do things they should be doing, but it is not necessary to make it easy to do things they shouldn't be doing. Simply suggesting an interface change without explaining what use case is being served is not most useful thing.

...

Orcs should be heavy-handed, so it fits the game. But we come again to the question why players would want to move things from container to another. That should be answered before considering UI solutions.

I can think of two scenarios right now:

1) Recovering from failed stockpile allocation. In this case I think game should signal the player they have failed, and current system does that well. Also, there's no reason to move decaying items, as they will rot away on their own, and items in use will be removed eventually. That's not obviously slower than goblins removing them as low priority jobs, and if the player needs this done ASAP, he'll probably end up blowing the stockpile anyway.

2) Moving things from a remote stockpile to one closer to point of use. This is a thing I often wish I could do with charcoal. Currently there's a trade-off between fire safety and efficiency. Ability to feed items from one stockpile to another would reduce the efficiency penalty, but that would make the problem less interesting, and so the game a little more boring. I'm not sure supporting this functionality, much as I'd want it, would be an overall benefit to the game, especially if it made stockpiles more complex.

Ok, in my experience the circumstances the main times it has happened for me is
1. When I make a mistake in setting up a stockpile. Particularly including an item you shouldn't have - perhaps from choosing an upper category rather than a specific one. End up a mixture of items and you want one out. It happens, partially because the categories aren't necessarily clear.
2. A bunch of things that probably would be solved if containers could be moved into stockpiles with items. Moving seeds out of seed stockpiles and containers in, etc.
3. Putting the wrong type of container in a stockpile because it isn't obvious what can hold some type of item (if anything).

Logistics like having a stockpile near the manufacturing point and another near the points of usage are also possible - if you want to make the resource right now, but not use it until later (possibly due to decay of the original resource or other factors) you might have it fill the nearby stockpile and export it out later to save goblin usage. Having a stockpile of food near a stationed squad might be another example. Hard to say since it isn't an option at present.

Yes. First placing a container and then putting items in it fits my expectations. You don't first fill a warehouse and then try to add shelves. It's good when game mechanics line up with the real world, but I'm not sure they need to line up with expectations formed by other games, for example.

That does make sense. It doesn't make sense that goblins can't be given the job to do the necessary rearrangement though. Especially because you can force it to happen manually by recreating the stockpile, and the goblins will even add the containers into the stockpile on top of the same (not stored by still present) contents if you do so.

Generally games within a genre will conform to similar mechanics for usability, but I can't think of any games with stockpile/container mechanics but DF and a single game shouldn't represent a quorum on mechanics - so you are right that it is not particularly relevant.

Okay, here's a suggestion: if 'hold' is merely 'don't accept', why is it a separate check box? Just have the check boxes for 'accept', like now, and 'remove'. There's even a case for checking both: sending things from a stockpile close to point of production to one closer to point of use.

But that doesn't necessarily make things more learnable than things are now; player would still need to learn what 'remove' does. Lack of documentation is currently the biggest problem, IMO.

But really, I'd like a convincing case made for including the functionality before planning an interface for it.

That was the suggestion earlier in the thread. Mike-Al didn't like it because it means you can't hold onto objects in a stockpile without preventing more being receive - he gave an example of reaching some desirable number of an items stored and setting it to not be accepted so other items get routed elsewhere. I guess there is the question of whether there is a use-case for that though.

[Mike-al]

I can think of two scenarios right now:

1) Recovering from failed stockpile allocation. In this case I think game should signal the player they have failed, and current system does that well. Also, there's no reason to move decaying items, as they will rot away on their own, and items in use will be removed eventually. That's not obviously slower than goblins removing them as low priority jobs, and if the player needs this done ASAP, he'll probably end up blowing the stockpile anyway.

I agree: I don't see this as a large enough problem that it's worth making the interface more complex.

2) Moving things from a remote stockpile to one closer to point of use. This is a thing I often wish I could do with charcoal. Currently there's a trade-off between fire safety and efficiency. Ability to feed items from one stockpile to another would reduce the efficiency penalty, but that would make the problem less interesting, and so the game a little more boring. I'm not sure supporting this functionality, much as I'd want it, would be an overall benefit to the game, especially if it made stockpiles more complex.

Here's an idea. My assumption is that in general, the situation in which this happens is when a resource is far from the camp (a bog, quarry or clamp), and what one would like is for the resource to be stored near where it's extracted and later moved closer to the camp itself, where it's used.

How about making it so that goblins will, as a lowest-priority task, move things from stockpiles that are further away into stockpiles that are closer to the center of the camp? For example, in the charcoal case, if your clamp is far from the camp (as it should be!), you could have one stockpile of charcoal right next to the clamp that would fill up with charcoal as it's produced, and another stockpile inside your camp that accepts charcoal. The charcoal would be gradually moved from the first stockpile to the second, and as it's used up from the second, it gets replaced by charcoal from the first stockpile.

This would be a very tidy solution because it's all happening under the hood and requires no changes to the interface whatsoever.

[Burningpet]

I dont see why the interface has to punish a player for making mistakes. sure, this is a complex game and big part of it is the proper arrangement of the camp, but the punishment for mistakes should come from efficiency of the camp, not the ui.

if a player filled a certain stockpile with say planks and logs and later on wants to seperate those stockpiles he shouldnt be destroying the first stockpile all together. a simple solution will be to make green "accept an item", red "do not accept and take out of the stockpile" if there is another stockpile that can accept the item.

this way you do not only decide what will be future accepted into the stockpile, but decide what will be in the stockpile. this is much more intuitive and what i initially thought the red/green does.

[Noah]

If I understand you correctly, you want a stockpile for empty containers, that could be moved to some future stockpile? Generally, that won't work in Goblin Camp. The thing to understand is that, in Goblin Camp, containers are a fixture of a stockpile. Once it's there it's there. (Though goblins will grab empty barrels or sacks from any convenient stockpile.)

This is exactly how it feels--like containers are fixtures of a stockpile.

I think this is a big part of my issue then. I'm trying to store stacks to use later to create flower (Which requires 1 sack, not as a container, but as an item) You are saying that sacks are part of stockpiles and can't be removed.

The point is that you should be able to store containers in stockpiles just like everything else in the game. If it weren't for sacks I'd say that this would only be "Should", but since sacks are clearly both an item and a fixture of a stockpile there is no question--it's a must.

[Walker]

But we come again to the question why players would want to move things from container to another. That should be answered before considering UI solutions.

Ok, in my experience the circumstances the main times it has happened for me is

1. When I make a mistake in setting up a stockpile. Particularly including an item you shouldn't have - perhaps from choosing an upper category rather than a specific one. End up a mixture of items and you want one out. It happens, partially because the categories aren't necessarily clear.

So this one would be at least partially solved by improving the categories. Some of them are rather bad right now.

(Another reason this happens, at least to me, is when I accidentally click a category when scrolling the list, and some stupid goblin drops a bolt of cloth in before I can click it again. This didn't use to be a problem for me as there used to be a delay of some seconds before new setting were applied, but that delay was removed thanks to user feedback. No biggie, though, I just pause before adjusting categories.)

2. A bunch of things that probably would be solved if containers could be moved into stockpiles with items. Moving seeds out of seed stockpiles and containers in, etc.

Yeah, that'd probably address many of the complaints.

3. Putting the wrong type of container in a stockpile because it isn't obvious what can hold some type of item (if anything).

This would be fixed by informing the player, it really isn't something that player should learn through trial and error. There was a good suggestion by Sidran that would address this: show container item can be stored in along with components in Stock manager tool tip.

All in all, I think only 1. would need to be addressed with a remove form stockpile-feature. And none of the scenarios involve deliberately setting up situations where things would be moved from one stockpile to another, but are recovery from mistakes, and mistakes that should grow fewer as the player learns the game. That's why I'm a little leery of addressing them with introducing a mechanic that would be always present and would thus suggest shuffling things between stockpiles is routine business. That sort of neatness-obsession doesn't feel too goblin-y. Current method of recovering from mistake underlines it being a mistake, and is appropriately brutal approach.

Having a stockpile of food near a stationed squad might be another example. Hard to say since it isn't an option at present.

It would not really be an option with your proposed system either. That's why I suggested accept/don't accept and remove/don't remove as separate controls. Then you could set up distribution from near to far, or gradual relocation from far to near stockpiles.

You can create a food stockpile for squads with the way things currently are, though; I've done it a few times. Either make sure you produce more food than fits in the nearest food stockpile so the overflow gets carted to more remote locations, or accept only some subcategories in different food stockpiles.

Yes. First placing a container and then putting items in it fits my expectations. You don't first fill a warehouse and then try to add shelves. It's good when game mechanics line up with the real world, but I'm not sure they need to line up with expectations formed by other games, for example.

That does make sense. It doesn't make sense that goblins can't be given the job to do the necessary rearrangement though. Especially because you can force it to happen manually by recreating the stockpile, and the goblins will even add the containers into the stockpile on top of the same (not stored by still present) contents if you do so.

I think we can agree to agree on this one. I don't think I've seen any resistance to this suggestion.

Okay, here's a suggestion: if 'hold' is merely 'don't accept', why is it a separate check box? Just have the check boxes for 'accept', like now, and 'remove'. There's even a case for checking both: sending things from a stockpile close to point of production to one closer to point of use.

But that doesn't necessarily make things more learnable than things are now; player would still need to learn what 'remove' does. Lack of documentation is currently the biggest problem, IMO.

But really, I'd like a convincing case made for including the functionality before planning an interface for it.

That was the suggestion earlier in the thread. Mike-Al didn't like it because it means you can't hold onto objects in a stockpile without preventing more being receive - he gave an example of reaching some desirable number of an items stored and setting it to not be accepted so other items get routed elsewhere. I guess there is the question of whether there is a use-case for that though.

I was a little confused, for some reason I though you were suggesting some arrangement of three radio-buttons rather than one three-state button, and thought that was excessive. The mock-up you posted was quite neat, and would preserve the current functionality and add the remove without greatly complicating interface.

It's just that I'm not convinced there is a great need for it. It wouldn't actually allow the player to do anything he can't already do, even if it might require an extra step currently; it might encourage counterproductive practices; and it would not facilitate the most interesting case I see for moving things between stockpiles, namely setting up redistribution chains.

[Walker]

2) Moving things from a remote stockpile to one closer to point of use. This is a thing I often wish I could do with charcoal. Currently there's a trade-off between fire safety and efficiency. Ability to feed items from one stockpile to another would reduce the efficiency penalty, but that would make the problem less interesting, and so the game a little more boring. I'm not sure supporting this functionality, much as I'd want it, would be an overall benefit to the game, especially if it made stockpiles more complex.

Here's an idea. My assumption is that in general, the situation in which this happens is when a resource is far from the camp (a bog, quarry or clamp), and what one would like is for the resource to be stored near where it's extracted and later moved closer to the camp itself, where it's used.

How about making it so that goblins will, as a lowest-priority task, move things from stockpiles that are further away into stockpiles that are closer to the center of the camp?

That's a good idea, and seems like a neat mechanic. It addresses one specific case, though. It wouldn't help with the reverse, like distributing food and drink to squads stationed further away. How about low-level activity of balancing the levels between multiple stockpiles with same allowances? Weighted based on distance from center, maybe.

I seem to recall some suggestion of having goblins sometimes storing things to stockpiles other than the nearest, weighted by distance. That, too, might be a nice feature, and would go well with this one.

Constant rearrangement does not seem very orcy, though. This might be a perfect idea to mention an idea I had previously when wishing the stockpiles were neater. (My desire for a neat and orderly camp and my desire to make things more orcy are in constant conflict.) An exotic migrant that does more or less what goblins do, but likes things neat. Kidnapped dwarf children or outcast elves or something. These poor guys would be constantly battling the chaos goblins leave behind: balancing and compacting stockpiles, moving loose items into containers, hell, why not removing things from stockpiles that don't accept them. It's work that would be appreciated by players with a taste for neatness, it might be funny to watch, and it shouldn't make things *too* orderly, as these guys would always be outnumbered by sloppy goblins.

[Walker]

I dont see why the interface has to punish a player for making mistakes. sure, this is a complex game and big part of it is the proper arrangement of the camp, but the punishment for mistakes should come from efficiency of the camp, not the ui.

The punishment does come from the inefficiency. But does the interface need to cater for correcting one specific class of mistakes? And does it fit the rest of the game?

a simple solution will be to make green "accept an item", red "do not accept and take out of the stockpile" if there is another stockpile that can accept the item.

this way you do not only decide what will be future accepted into the stockpile, but decide what will be in the stockpile. this is much more intuitive and what i initially thought the red/green does.

This is why I don't like the use of the word 'intuitive'. It often just means 'what I expect'. There's nothing intuitive about that behavior, IMO. Okay, that's what you expected. Where did this expectation come from? Not everyday world, I think. If a fridge door is open, I can put things in it. If I close it, I expect I can't put things in; I don't expect things to come spilling out.

Now, that's just saying that I don't think it's as intuitive as you seem to think. It doesn't mean it shouldn't work like you suggest.

The reason I think it shouldn't work like that is that it would, IMO, be more confusing than the current system, as the behavior of a stockpile would depend not only on the state of that stockpile, but on those of other stockpiles as well. If I have only one stockpile accepting leather, unchecking that box means "don't store anymore". If there happens to be another stockpile with leather checked, it suddenly means "don't store here anymore, and move existing stock out to another stockpile".

The three-state solution suggested by immortius would be better for this functionality, as it would make those three states explicit.