Print

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

[Fleeting Frames]

Quire and Scroll material is the sheet material. So plant paper ones matches "Allow non-plant/Animal (!) Plant Cloth material". And parchment quires/scrolls don't get moved, even to everything stockpile.

Distinguishing scroll rollers from jugs....You could maybe do it with a minecart that is so full a jug (size 300) doesn't fit in & scroll rollers (size 100) do, but I'd suggest stockpile linking or keep scroll rollers stuck in workshop.

[ldog]

Yeah, I'm not really sure what to do about the other book-making stuff.
I'd hold off on adding until a library is built.
I'm still nervous about that too. Does anyone know if the endless cycle of taking out books and putting them away is fixed?

The roof continues to be a major manpower sink. I still can't get the traps, levers & bridges done first, even with 2 mechanics & 2 masons.
It should go to its own stage, even after the barracks. Barracks could actually go with surface5 I think. Make roof 6 and the extra traps/walls 7.
Otherwise barracks 6, roof 7, extra 8.

[myk]

Ok, let's:

• build the entire barracks in /surface5 (I just need to make a note that the player should check to ensure the little roof segment over the barracks beds has been finished. it's usually the long tail of /surface4)
• move the traps into /surface5 so they can be completed before all the walls/flooring show up
• /surface6 will be the labor-intensive step, but traps, levers, and bridges should be completed before it begins. Walls will get built first, then floors, then roof (thanks to buildingplan remembering the order in which constructions were planned, of course there's always some variation depending on when the "ready" tasks actually get picked up)
• /surface7 will be the extra trap corridor (and corresponding roof extension)

edit: done. playtesting the changes now.

[ldog]

Ok, let's:

• build the entire barracks in /surface5 (I just need to make a note that the player should check to ensure the little roof segment over the barracks beds has been finished. it's usually the long tail of /surface4)
• move the traps into /surface5 so they can be completed before all the walls/flooring show up
• /surface6 will be the labor-intensive step, but traps, levers, and bridges should be completed before it begins. Walls will get built first, then floors, then roof (thanks to buildingplan remembering the order in which constructions were planned, of course there's always some variation depending on when the "ready" tasks actually get picked up)
• /surface7 will be the extra trap corridor (and corresponding roof extension)

edit: done. playtesting the changes now.

I think just move the roof. Getting the walls done sooner rather than later is important. The roof is important, just it can wait until the other things are done.
The issue I am seeing is that everyone will prefer to do the wall/floor construction over everything else. If we have a hard pause in between the roof, it gives us time to get other jobs done as well as all the building. I just went and manually cancelled the roof and now bridges are getting built.

[Fleeting Frames]

I'm still nervous about that too. Does anyone know if the endless cycle of taking out books and putting them away is fixed?

43.04 fix.

[ldog]

Updated automation.json
I had forgot leather cloaks, added the papyrus, adjusted bone & wood bolts jobs.

I'm still nervous about that too. Does anyone know if the endless cycle of taking out books and putting them away is fixed?

43.04 fix.

Awesome!

[myk]

I think just move the roof. Getting the walls done sooner rather than later is important.

yeah, after playtesting, I agree. The bridges can get done if you wait to start /surface6 until after /surface5 is completely built (bridges, et. al.), but the roof distracts from finishing the walls. will move.

Updated automation.json

Thanks! I'll update the master.

[ldog]

Didn't realize you shrank the guard barracks. Was wondering why the jail cells were off (I had already dug with older plan).
The dining hall needs to be resized more; it isn't filling out the room.

Annnnnd...I am finding myself in the position where I am actually going to make iron weapons & armor initially. The flux is fairly deep (below 2nd cavern) and I've got too much other stuff to do before I work my way down there. The cassiterite is deep as well, so the only bronze is what I brought and that's already been turned into xbow bolts. I forgot how shallow the embarks Vjek designs are (not to mention 1 cavern simplifies a few things) compared to default. It does change how you go about it a bit.

Of course the current bunch also made a liar out of me, they are putting their civvies in the barracks chests. Since I wasn't at all prepared for them with gear, I gave them "wear over" as opposed to the usual "replace", and so they put the clothes they had to remove in the chest as they got gear. NM, got excited over nothing. Was looking at someone's equip. They stashed some food in the chest, which will of course rot and stink up the place.
At least they're good for something Cannonfodder all of them, the last 2 migrant waves have brought me 30+ semi-useless twats. More than half of them have level 2 animal care and nothing else. A 15 mechanic. About 5 various low level soldiers. That's it. Not even a legendary cheesemaker among them.

Error in the sheet orders, needs to be just plain sheets or it'll keep making them, "reaction_class" : "PAPER_PLANT" not working.
Updated v6 now.

[myk]

Whew, I went through and reworked the command checklist to make it (I hope) more useful. Each stage is now annotated with about how long it should take (measured in migration waves).

Updated hospital, dining room, and surface roof according to your suggestions. Please tell me if I missed anything.

I updated the master automation.json and the dreamfort.csv file in the pull request.

[myk]

I've been playtesting dreamfort a few more times, and I keep running an issue where miners channel themselves down through the ramp but haven't dug it out fully so they can't get back up, trapping themselves down below. setting priorities for the ramp to make sure it gets dug in the right order has been partially successful, but miners don't always do it exactly right, especially when there are multiple miners involved.

Currently, I have the dig tiles for the ramp at priority 6 and the channel tiles at priority 7. This, normally, causes the miners to dig out an entire level before, digging the ramp dig tiles and then finally digging the channel tiles (or at least one of them) before starting on the next level down. This normally works fine, but for the services level, the channel tiles for the wells provide an alternate route down to the next level, and the sequence gets messed up. I solved the problem for this particular level by adding a staircase up from the cistern to the main services level. On my latest runthrough, a single dig tile got canceled (dangerous terrain or something random like that) and my miners got stuck on the guildhall level.

Do you see issues like this with your ramps? how do you avoid them?

My initial thought is that we can build in a failsafe. I can build a staircase that goes up each level next to the ramp. Not a single column that would have the same danger as the original central staircase that we replaced with the ramp, but alternating staircases on the left and right of the ramp, like this:

Code: [Select]

` ` h7 d6 `
d ` d6 ` u
` d6 h7 ` `
#>
` d6 ` ` `
u h7 d6 h7 d
` ` ` d6 `
#>
...

thoughts?

[ldog]

I've been playtesting dreamfort a few more times, and I keep running an issue where miners channel themselves down through the ramp but haven't dug it out fully so they can't get back up, trapping themselves down below. setting priorities for the ramp to make sure it gets dug in the right order has been partially successful, but miners don't always do it exactly right, especially when there are multiple miners involved.

Currently, I have the dig tiles for the ramp at priority 6 and the channel tiles at priority 7. This, normally, causes the miners to dig out an entire level before, digging the ramp dig tiles and then finally digging the channel tiles (or at least one of them) before starting on the next level down. This normally works fine, but for the services level, the channel tiles for the wells provide an alternate route down to the next level, and the sequence gets messed up. I solved the problem for this particular level by adding a staircase up from the cistern to the main services level. On my latest runthrough, a single dig tile got canceled (dangerous terrain or something random like that) and my miners got stuck on the guildhall level.

Do you see issues like this with your ramps? how do you avoid them?

My initial thought is that we can build in a failsafe. I can build a staircase that goes up each level next to the ramp. Not a single column that would have the same danger as the original central staircase that we replaced with the ramp, but alternating staircases on the left and right of the ramp, like this:

Code: [Select]

` ` h7 d6 `
d ` d6 ` u
` d6 h7 ` `
#>
` d6 ` ` `
u h7 d6 h7 d
` ` ` d6 `
#>
...

thoughts?

Might not be a bad idea. Probably not going to make pathing any worse.
Other than the services level, which I ran into that issue too, saw your fix I haven't really had problems with them digging out the ramp, other than a "miners strike"
It was wierd, I set another batch of ramp, have like half a dozen miners or so, they went and dug it all and then they sat there for a bit at the bottom acting like they were stuck. There was more to dig above but they wouldn't budge for a few. I designated a few more things at very high priority and then they got moving. Maybe try using priority 5, which should still make them dig the levels out first. 6 & 7 seem almost bugged to me, like they would rather go haul than mine at that point.

So I got a large undead siege, filled all the cage traps and then some. I shudder to imagine what would have happened if we didn't have them (still lost 1 soldier to stupidity). What a pain it is clearing them out though. Need to look into mass-pitting solution. I vaguely remember hearing it is broken these days.

[myk]

I was thinking more about the ramp -- I wouldn't want the side staircase to break the surface, so I was going to modify to handle that, then I got to thinking, why do we need a ramp at all? wouldn't it be both "fall to death safe" and "miner dig self into hole safe" if we just used a spiral staircase?

Code: [Select]

` j7 `
u ` u
` j7 `
#>
` u `
j7 ` j7
` u `
#>
...

This would allow miners to dig up or down from their current position. Is there any advantage to using a ramp over this design?

yeah, I haven't had much luck with mass pitting in recent versions. In a previous version of dreamfort, I had an automated goblin flinger where hostiles in the animal stockpile would get loaded into a minecart, pushed down a series of impulse ramps, and shot through a fortification, where they would drop, stunned, into the middle of my barracks. Made for lots of well-trained soldiers : ) I took it out of dreamfort, though, since it made the surface that much more complicated to build. I might put it back in someday as an extra, though, once dreamfort "settles down" a bit.

edit: ok, so I just read the ramps vs. stairs thread and the stairs vs. ramps thread (and the why ramps instead of stairs? thread), but I'm not so sure if ramps have the definitive advantage here.

another suggested approach is a vertical shaft of stairs with hatch covers every few levels, but I don't like the thought of having to produce so many hatch covers.

ramps vs. spiral staircase:

we're paying the complexity cost of a different layout on every level with both approaches, so that's moot.
both prevent dorfs from falling to their deaths, both prevent line of sight issues (enemy on staircase on the surface would be able to see all the way down a central staircase shaft), and both prevent temperature issues from being open to the sky (not sure if this is really a thing, though).

ramps reduce dorf path distance when traversing.

stairs are guaranteed not to get any dorfs stuck in a hole and die.

I'm willing to be convinced one way or another, but at this point I'm leaning towards spiral staircase, since I like the "don't get stuck" quality of stairs and I'm not sure how relevant the "efficiency/FPS gain" from ramps is.

[ldog]

I was thinking more about the ramp -- I wouldn't want the side staircase to break the surface, so I was going to modify to handle that, then I got to thinking, why do we need a ramp at all? wouldn't it be both "fall to death safe" and "miner dig self into hole safe" if we just used a spiral staircase?

Code: [Select]

` j7 `
u ` u
` j7 `
#>
` u `
j7 ` j7
` u `
#>
...

This would allow miners to dig up or down from their current position. Is there any advantage to using a ramp over this design?

yeah, I haven't had much luck with mass pitting in recent versions. In a previous version of dreamfort, I had an automated goblin flinger where hostiles in the animal stockpile would get loaded into a minecart, pushed down a series of impulse ramps, and shot through a fortification, where they would drop, stunned, into the middle of my barracks. Made for lots of well-trained soldiers : ) I took it out of dreamfort, though, since it made the surface that much more complicated to build. I might put it back in someday as an extra, though, once dreamfort "settles down" a bit.

edit: ok, so I just read the ramps vs. stairs thread and the stairs vs. ramps thread, but I'm not so sure if ramps have the definitive advantage here.

another suggested approach is a vertical shaft of stairs with hatch covers every few levels.

I'm not so sure either anymore. I loved the 3 wide spiral ramp, but this one it seems like I get a lot of cancelation spam related to it (probably them bumping into each other in passing). The dual 2x1 ramps I squeezed into 1 iteration of Dreamfort didn't seem to work so well. A single 3-wide ramp would require a 7x7 well. A 3x3 of stairs is surely bad for pathfinding and hence FPS, but if its as bad as other people say I don't know. Before I went to ramps I used a central 2x2. Granted, as mentioned, hatches at regular intervals do work, as long as you remember to place them.

I'd say that new design of yours is worth a shot if nothing else. It really shouldn't be any different than the current ramp design FPS wise.

[myk]

Updated to stairs, and no problems seen, so I removed the "escape route" stairway near the jail cells. Continuing to play test to refine the checklist order. I'm moving the automation import down until after the stairwell is protected on the surface and the hospital has basic functionality. Otherwise the dofs are too distracted to set up defenses on the surface. I'm also playing with the configuration of the starting dwarves to understand how much faster we can go with higher starting skills. Making the miners and masons proficient really seems to make a difference in how quickly we can get the basic fort up and running.

I working on updating (and documenting) the quantum hauling aliases so they can more easily handle multiple input stockpiles, needed for the heavy piles.

edit: Heavy piles done. I kept them small to keep the current footprint -- 3x3 refuse and corpse pile became 2x3 refuse and 1x3 corpse, 3x3 otherstone and gem became 2x3 otherstone and 1x3 gem, etc. We'll see if that's big enough or if we need more. Once my wheelbarrow-setting PR is merged, I'll initialize them each with 2 wheelbarrows. quickfort orders will pick up that config as well and generate orders to build the wheelbarrows as well (this functionality is implemented, but it's built upon several unmerged PRs so I can't start the code review until the current crop of code reviews is done. Given the core team's focus on df-0.47.05, all this might not land until dfhack-0.47.05-r2, but we'll see)

Here is the most recent batch of alias updates:

Code: [Select]

sp_link: s{move}p{move_back}
sp_links: {sp_link}
quantumstop: ^hrn{name}&sn{stop_name}&&xxx{route_enable enter_sp_config={enter_sp_config_hauling}}{sp_links}^^q
corpses:     {refuseprefix}b{Right}{Down}p^
forbidcorpses:     {refuseprefix}{Right}{Down}f^
permitcorpses:     {refuseprefix}{Right}{Down}p^

and, for the interested, here's the updated documentation for how to use the quantumstop alias (though the docs look better in HTML):

Spoiler (click to show/hide)

...
Finally, the quantumstop alias is a more general version of the simpler quantumstopfrom* aliases. The quantumstopfrom* aliases assume that a single feeder stockpile is orthogonally adjacent to your track stop (which is how most people set them up). If your feeder stockpile is somewhere further away, or you have multiple feeder stockpiles to link, you can use the quantumstop alias directly. In addition to the sub-aliases used in the quantumstopfrom* alias, you can define the move and move_back sub-aliases, which let you specify the cursor keys required to move from the track stop to the (single) feeder stockpile and back again, respectively:

#query
{quantumstop move="{Right 2}{Up}" move_back="{Down}{Left 2}"}

If you have multiple stockpiles to link, define the sp_links sub-alias, which can chain several sp_link aliases together, each with their own movement configuration:

#query
{quantumstop sp_links="{sp_link move=""{Right}{Up}"" move_back=""{Down}{Left}""}{sp_link move=""{Right}{Down}"" move_back=""{Up}{Left}""}"}

Note the doubled quotes for quoted elements that are within the outer quotes.

[ldog]

Updated to stairs, and no problems seen, so I removed the "escape route" stairway near the jail cells. Continuing to play test to refine the checklist order. I'm moving the automation import down until after the stairwell is protected on the surface and the hospital has basic functionality. Otherwise the dofs are too distracted to set up defenses on the surface. I'm also playing with the configuration of the starting dwarves to understand how much faster we can go with higher starting skills. Making the miners and masons proficient really seems to make a difference in how quickly we can get the basic fort up and running.

I working on updating (and documenting) the quantum hauling aliases so they can more easily handle multiple input stockpiles, needed for the heavy piles.

edit: Heavy piles done. I kept them small to keep the current footprint -- 3x3 refuse and corpse pile became 2x3 refuse and 1x3 corpse, 3x3 otherstone and gem became 2x3 otherstone and 1x3 gem, etc. We'll see if that's big enough or if we need more. Once my wheelbarrow-setting PR is merged, I'll initialize them each with 2 wheelbarrows. quickfort orders will pick up that config as well and generate orders to build the wheelbarrows as well (this functionality is implemented, but it's built upon several unmerged PRs so I can't start the code review until the current crop of code reviews is done. Given the core team's focus on df-0.47.05, all this might not land until dfhack-0.47.05-r2, but we'll see)

Here is the most recent batch of alias updates:

Code: [Select]

sp_link: s{move}p{move_back}
sp_links: {sp_link}
quantumstop: ^hrn{name}&sn{stop_name}&&xxx{route_enable enter_sp_config={enter_sp_config_hauling}}{sp_links}^^q
corpses:     {refuseprefix}b{Right}{Down}p^
forbidcorpses:     {refuseprefix}{Right}{Down}f^
permitcorpses:     {refuseprefix}{Right}{Down}p^

and, for the interested, here's the updated documentation for how to use the quantumstop alias (though the docs look better in HTML):

Spoiler (click to show/hide)

...
Finally, the quantumstop alias is a more general version of the simpler quantumstopfrom* aliases. The quantumstopfrom* aliases assume that a single feeder stockpile is orthogonally adjacent to your track stop (which is how most people set them up). If your feeder stockpile is somewhere further away, or you have multiple feeder stockpiles to link, you can use the quantumstop alias directly. In addition to the sub-aliases used in the quantumstopfrom* alias, you can define the move and move_back sub-aliases, which let you specify the cursor keys required to move from the track stop to the (single) feeder stockpile and back again, respectively:

#query
{quantumstop move="{Right 2}{Up}" move_back="{Down}{Left 2}"}

If you have multiple stockpiles to link, define the sp_links sub-alias, which can chain several sp_link aliases together, each with their own movement configuration:

#query
{quantumstop sp_links="{sp_link move=""{Right}{Up}"" move_back=""{Down}{Left}""}{sp_link move=""{Right}{Down}"" move_back=""{Up}{Left}""}"}

Note the doubled quotes for quoted elements that are within the outer quotes.

Looks good. Small feeders should be fine. I don't do much bigger.