Hey Myk. The latest tweaks to the Dreamfort design have really helped speed it along, I will be on schedule for the 3rd migrant wave.
So far everything is fairly clean and trouble-free.
Awesome! I've been pretty happy with it too. I think we've achieved a good balance of functionality and simplicity.
The new stairwell design doesn't suffer from the job cancellation issues the ramps had. I think the digging priority needs adjustment from 7 to 5 (and leave the 4 at 4) because I have noticed the lower priority tasks aren't just lower than other similar tasks, but all tasks (such as hauling;I don't use designated haulers, everyone hauls when they aren't otherwise busy). 5 will keep them from being dug before any 4s, even ones halfway across the map.
Hummmm. I'll need to give this some thought. Lowering the priority of the stairwell tiles will make it trickier to dig the well cisterns on the services level. I might be able to do it with the stairwell at priority 6, but I need priority 5 to force the miners to dig the cistern tiles in the correct order. Otherwise we could end up with messy ramps or undug tiles on the main service level. Would raising the priority of the stair tiles to 6 be enough? An alternative would be to change *all* the default 4 dig tiles to 3 and move everything up a notch. I think that would make the blueprints unacceptably messy, though, and they'd be less useful as the "copyable examples" I'd want them to be.
I guess I've never run into this before since I use dedicated diggers. I enable hauling on all my other dwarves (or rather I let the
autohauler plugin do it for me), but, at least in my forts, diggers are diggers 'til the diggin' is done. I don't really want to impose that playstyle on everyone, though, so I'd like Dreamfort to be as flexible as possible.
I found a way to cheat and add empty bag to sand collection (in-game it won't let you) by copy-pasta and importing order:
Nice. I'll add it in.
Still trying to get the soap cancellation spam to stop, seems like I am constantly ordering extra lye manually, but at least once we get full stock it will stop.
It has been difficult to find an orders configuration that works well for soap. I've been thinking, perhaps the best way to solve this problem is to write a dfhack fix script that scans existing orders and adds the missing condition for lye-containing items for any order that produces soap bars. If we call that script from onMapLoad.init, it would solve the issue on every map load after df fails to restore the condition from the savegame.edit: ok, so I went to the DF bug tracker to get the bug number for this issue, and I was surprised that I couldn't find it. So I started to file it myself. While I was verifying the "steps to reproduce", I found that *the bug has been fixed*! "lye-containing items" conditions are properly restored from saves now! I guess I haven't checked since 0.47.05 came out. I'll update the orders we've been using and see if the "proper" configuration works now.
I have been adjusting some of the orders to require n+1 of problematic inputs, which seems to help a bit.
Yeah, I've been playing with that as well. The issue seems to be:
1) needed item is produced
2) manager identifies that the needed item exists, activates the orders that use it
3) needed item is picked up and hauled to a stockpile OR item is used by another order
4) newly-activated order can't use the item because it's "in a job" (or already consumed)
I'm experimenting with requiring at least 5 (or, rather, n+4+number of other orders that can consume item) of any item that we use as input. This solves the competing automation orders problem, allows manually-added orders that use the same items to take precedence, and has a very low chance of having all free items in hauling jobs at the same time. It also has the (potentially) useful side effect of maintaining a small cache of basic items that the player can use in an emergency. The downside, of course, is that it will take longer to build up enough items to get started on the item pipelines. This might not be such a bad thing, though, since the automation orders are intended to "nudge" the fortress into a good steady state. I'll play with it a bit and see if there are any problems with the longer ramp-up time.
The automation orders are turning out to take more careful design than I originally thought they would! I'll have to write some documentation on how they work so players can understand and extend them more easily. In the far future, maybe this entire set of automation orders could be implemented as a configurable DFHack script (or integrated into the
orders plugin as a
generate command).
I'm also making some annotated screenshots of the dreamfort levels (and I'm realizing how difficult it is to make readable annotated screenshots : ) All this will eventually go into the
quickfort library guide, I think.
Author
Topic: DFHack: quickfort | buildingplan | blueprint | blueprints/library (Read 91857 times)