Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[FFLaguna]

I'll be Toady One's already thought about this one.

It's frustrating to have jobs started, but then completely abandoned with no hope for continuing where it was left off at, just because Dwarfy McDwarfdwarf felt like he had to grab a glass of water.

When do you plan to implement something like this? I know something like this is on the books, I'm just trying to waste your time by satiating my need to know.  

[AlanL]

Try suspending then unsuspending the project.

[Toady One]

I'm not even sure the duration of a job resets if it is dropped by one dwarf and the materials are brought back the way it is set up now.  In any case, there has been some discussion about jobs retaining their associated items if they are dropped by a dwarf.  This keeps them tied up by that job, potentially for a long time, which would probably lead to some other frustrations.  On the whole, it's probably better to set it up that way though, at least for items that made it to the shop.

[FFLaguna]

Perhaps later on you plan to implement a system where, for example, a 25% complete job that is aborted so that the dwarf may get a drink is able to be continued at a later time? I'm curious as to your opinions and the problems associated with this... one of which is the workshop and items become tied up, as you already mentioned. Do you plan to make this toggle-able on individual workshops, etc.?

[Egg]

I'm not sure how the needs are set up but how about a system where, rather than dropping everything and grabbing a drink the instant thirst appears, the dwarf gets a provisional "I'm a bit thirsty so drink after completing this task" which after a certain period turns to "Okay fuck this I want a drink NOW" and makes him cancel the task at hand.

Of course, this could be how it works already. I don't know!

[Zurai]

Actually, I'd rather go about it the other way around - a dwarf wouldn't start a job unless he'd be able to finish it before becoming hungry/tired/thirsty. It'd require a little prediction, which could be troublesome, but it'd eliminate a LOT of hassle with dwarves starting a job halfway across the map and travelling all the way back to their start point for a drink 3 seconds after finally getting to the job in the first place.

There might have to be provisions put in for some jobs that normally take a hideously long time in the first place, like loading siege weapons. You might never be able to get a siege weapon loaded otherwise.

[darknight]

I dont have a great problem with how SHOP jobs are handled right now. But other jobs can be a real PITA. Two days ago, I watched as one floodgate got connected 6 times, before somebody FINALLY managed to get it connected to the lever! The gate was a good distance from the lever, and each time a dwarf took the job, it did exactly the same thing, it would go all the way to the already connected gate, spend time "connecting" it, then start for the lever, but before it could get to the lever, it would run off to eat, drink, or sleep. The second gate only took 4 times, but still. At least with mechanics, the job needs to be in stages or something. That way when they take a job, they can see that stage 1 is done, so move on to stage 2.

And they should use the closest things for the task. I just had a soldier, stationed at the magma river and on duty, go all the way over not just to the cave river, but to a very remote part of it, just to fill his waterskin. And this is in spite of the fact that there is a well ten steps from his post. Also a barracks, dining room, and small food and booze storage areas. Even if he felt he needed more bolts, and went to get some, and then needed a refill, there are two wells only 50 steps from the amo pile. There was no call at all for him to be something like 300 steps farther away. I have seen that kind of thing done many times, but that is the most outragious one so far. I cant even begin to imagine the twisted math going on in the software, that would have caused him to do that.

And BTW Toady, thats a left-handed compliment. To even have programming complex enough to ALLOW that kind of thing, seems like magic or wizardry to me. Your programming today, compared to the little that I used to do, is like comparing a moon rocket with a stone axe! I dont just tip my hat to you, I take it off!

[Toady One]

Yeah, there's a level at which they "might drink" versus a level at which they "cancel to drink", but that doesn't change the observed behavior, since you only see the cancellations.  If they drank earlier to prevent cancellations, they'd be drinking more often in general, decreasing productivity.  The main issue would then be keeping jobs that are some percentage done at that percentage, but there's that item tie-up issue to be resolved.  Mechanic jobs are some of the most complained about -- I don't remember at this point how much it remembers in between cancellations.  If they've connected one of the mechanisms, the next mechanic just works on the second?  I thought that's how it worked.

[zy]

I'm not so convinced that the tie-up from keeping goods in workshops for a job order, or in some other pipeline, is any worse than the tie-up from seeing those same items suddenly tasked to be hauled to and from stockpiles before you can use them again. As long as I could cancel the original job and thus free up those items for other uses then I would at least have the option of aborting and re-using before they waste or get trapped in the system.

(If you're worried about items going MIA then the item screen in job assignation could show similar items currently flagged as tasked but not yet placed or finished -- all within existing functionality, possibly? -- and with the option of intervention).

I'm also unconvinced that master craftsdwarves would walk out on a job for a drink, half an hour before completion, when they know that it would undo days of labour as the prized meat, thread, hide etc. rotted or wasted in their dereliction of duty. How do you code when you're hungry, Toady? Do you dash straight off, or do you give yourself five minutes to finish what you've been working on? And do those five minutes not turn into an hour sometimes?

For all of their supposed skill levels, none of my dwarves have been coded with a love of what they do.

Of course, if this extra effort means that you eat more, drink more or pee longer when you're finally free, or that you take an extra long break after the deadline to make up for your overtime, then there's a bit of balance to the overall productivity. Heck, you could introduce a hangover state for citizens who can't handle the pace of fortress living.

The danger I see is the time I'm spending in nano-management, coming up with tiny stockpiles and impromptu job cancellations, when I'd rather be thinking about how I can stage the best club night in all of dwarven history.

[qwip]

Are we trying to fix something that's really a player problem?

This is a game about supply chain management.  The player who strategically places food/drink/stockpiles in relation to planned work will benefit from the existing system, and those who don't are seeing the issues described above. If you have jobs that send a dwarf from one side of your fortress to the other, perhaps that just your bad planning?  (I certainly feel like its my fault when I realize that I'm hauling recently mined rock out to the mine entrance to be mason'd into blocks, which are then hauled back to my bar/block stockpile deep inside the fortress.)

Perhaps it should be nigh impossible to connect a lever to a bridge that is 400 spaces away? I didn't see a job to turn malachite into Cat5 network cable. Are these mechanisms on a WLAN (DFLAN?)

On the flip side, if you do have mechanism stockpiles right next to both the lever and the bridge, I don't think you can pick the closest mechanisms without lots of guesswork.

Also, I wonder how the "burrows" concept that's planned will affect this situation.

[Retro42]

That's actually a great idea...

What about a "Pick Closest" option for certain jobs or maybe a "sort by closest" option for picking materials.  If I wanted to make my floodgates w/ diamond studded mechanisms I could pick those, but if I just want to get it running.....the closest available would work better.  Just a thought.

Another thought:
The reclaim designation is actually VERY helpful to clean up tasks.  What if you could paint areas/items as "In Use" and hauling jobs would ignore them?  

Example:  Butcher Shops/Trap creation/Roads
If they are "In Use" all Hauling shops to that location/item are ignored.  It might be a touch more micro-managing but it could help streamline some of those long distance tasks.

Retro

.....Then again Burrows could just solve this anyways.  Toady has an excellent plan put together  

[zy]

quote:Originally posted by qwip:
<STRONG>Are we trying to fix something that's really a player problem?

This is a game about supply chain management.  The player who strategically places food/drink/stockpiles in relation to planned work will benefit from the existing system, and those who don't are seeing the issues described above. If you have jobs that send a dwarf from one side of your fortress to the other, perhaps that just your bad planning?  (I certainly feel like its my fault when I realize that I'm hauling recently mined rock out to the mine entrance to be mason'd into blocks, which are then hauled back to my bar/block stockpile deep inside the fortress.)
</STRONG>

I don't think that's a fair criticism of what I'm describing, no, and I've already mentioned the use of pit-stop stockpiling (the recent custom options are ace for speeding up delivery lines). But even if you have inbox / outbox piles right next to the workplace, that doesn't mean the job itself might not be taken by a peasant many miles away who then travels several leagues to haul an item two squares in order to put it back on the available list. And who can, themselves, give up and wander off half-way.

It's not even such a concern to me that a job takes a long time and lots of hands in a big fortress (a neat simulation of bureaucracy...). I'm more concerned about seeing items with a shelf-life go to waste or disappear into the system when they are really needed. Plus, I suppose, seeing an expert tanner abandon a rare skin, or a master weaver just drop her spider thread on the floor and dash off after she's fended off a snakeman ambush to collect it, just doesn't sit right with me.

Though that's probably bitterness that I have to wait till clocking-out time to grab a pint while my dwarves can get away with it any time.

[Aquillion]

quote:Originally posted by qwip:
<STRONG>Are we trying to fix something that's really a player problem?

This is a game about supply chain management.  The player who strategically places food/drink/stockpiles in relation to planned work will benefit from the existing system, and those who don't are seeing the issues described above.</STRONG>

The time-wasting involved in a dwarf who suddenly gets hungry on the job is simply too high to justify this.  As it happens now, if a dwarf does a job and gets thirsty halfway through, these are the steps that happens:

* Dwarf starts job, grabbing an item.  Both the job and the item are now reserved and can't be done or used by anyone else.

* Dwarf starts hauling, working.  No matter how well I, the player, have set things up, this is going to take some time for many jobs.

* Dwarf gets thirsty, drops item, wanders off.

* Someone else--from anywhere in the fortress has to do a haul job from the arbitrary point where they dropped the job's item back to the stockpile.

* Possibly at the same time as this, another dwarf has to haul an identical item to where the job is being done.

The main problem here isn't that this is stupid (it is, a little, but they're dwarves, we're used to them occasionally doing stupid things); it's that it can waste a huge amount of time even with a perfect setup by the player, and it's totally random.  That isn't good.  A player with even a moderately functional fortress should be able to assign a job and know that it will be accomplished in some reasonable amount of time.

Anyhow, the easy way to reduce this problem:  Increase the total amount of time it takes a dwarf to go from sated to starving, and pour all this extra time into the time between 'peckish' and 'hungry enough to drop a job'.  This will make dwarves eat at roughly the same rate when they're free to do so, but will let them push it back further when they're working.  Of course, this will also cause dwarves to eat less under complete starvation conditions, but most of the time they'd be eating the same amount, since they'll normally eat when peckish.

[ January 17, 2007: Message edited by: Aquillion ]

[Toady One]

I guess, for this kind of thing to work, the builidngs shouldn't be able to pick peckish dwarves to work provided they haven't failed to find food yet.  There's a good chance, without something like this in place, that when a peckish dwarf finishes its current job, since the building is immediately tagged to recheck for a dwarf at that point, the dwarf would be selected again.  I think with the addition of one more timer/flag this could be avoided, and then it should work out.  A peckish dwarf that failed to find food would continue working, and continue taking new jobs as long as food is unavailable.  However, they'd be given a short window of time after every job to check for food, where buildings couldn't select them.  Alternatively, a peckish dwarf could force a food check immediately after finishing a job, without giving buildings a chance to search for workers, but this is a bit more annoying to do, since there would be more exceptions.

[ January 17, 2007: Message edited by: Toady One ]