- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
User:Jfredett
Fortress Logs
Being a Star Trek fan, I thought it might be fun to keep a "Captain's Log" -- from the perspective of my Expedition Leader, The dates correspond to actual dates I played, along with timestamps of when I took the notes (more or less). The dates are in mmddyy, 24hourtime format, a entry marked with only a time indicates a supplemental log.
Current Fortress
- Rirassodel "Greatershield"
- This is the first fortress I started keeping logs on. UG River and Mag Pipe are on the map (somewhere), sparse trees and IIRC I'm in a serene area. Sandy area easily accessible (for once... I can't tell you how many times I have had to hunt for arable land for the early fortress farm...
Play style
I tend to play till I screw something up or the game crashes -- something is amiss with my version, and pressing F11 to go to fullscreen causes a game crash. I occasionally do silly things, like drop cut a "Helm's Deep" into the side of whatever mountain I start near -- effectively caving in a large, sheer, straight cliff on three sides. I had been playing a fortress like that, but it crashed as I was about to finish the plumbing for a (if I do say so myself) brilliant plumbing system, see the ideas section for more info on that. Largely my interest is less in military and fighting and more in interesting defense systems. Among my favorites is the washout technique, I don't know if someone has come up with that idea before, but it's pretty neat.
Ideas
Some fun ideas and suggestions for future DF stuff.
Most of this is TBA, you have been warned.
Plumbing
WRT plumbing, the setup I like to use works something like this.
Overview
Depending on the location of your watersource (mine tends to be a UG River or an overground river, but in any case), you will likely need to pump water up/down to truly effectively make use of it. In my forts, I tend to have an active overground presence, I keep my farms, barracks, dining hall, crafts, and butchery/leather chain almost always above ground (though not necessarily outside. I find that this setup (with workshops directly beneath it, and furnaces/metalcrafting going on directly below that (usually in range of a magma pipe, sometimes some pumping needs to be done)) leads to a nice "clustering" of resources that minimizes need for multiple stockpiles, increases efficiency, etc (For those interested, I keep the bedrooms on the third floor up from the bottom).
To this end, I really want to put my well/water source on the top floor, near to the dining area, barracks/hospital, etc. This is means I need to pump/redirect water from whereever it is to this area. With an overground river, one can generally just redirect water through some fortifications outside of their main wall into a pool, something like (side view) :
| W | |---------------####----| ~=~~~~~~~~~~~~~~~~~~~~~~~| -------------------------
Where
| : a wall = : a fortification W : a well - : the ground # : grates
This is fairly standard, and it's not particularly difficult to redirect a river (or even damming the old outlet of the river afterward- that's another story though...). However, pumping water up from an underground river leaves one with other considerations to make.
- Are we going with powered or manual pumping? Generally you'll want powered pumping for the main cistern, but you may want to use manual-only for the well to prevent overflows. You could also use a more complicated "autofill" system using pressure plates, but I won't go into that here.
- How much water should we store? Each level will be filled to pressure, but how big should those rooms be. This also plays into the next point- about "unfilling" in the event we need to do work in/extend the current system.
- How should we drain the system if the need arises?
Further, we need to worry about controlling the intake tunnel, setting up a power structure, etc. Obviously we want to minimize the number of axles/gear assemblies we use, since those increase power overhead.
One simple design is to simply create a shaft with pumps filling a series of stacked boxes. This method is simple, but somewhat featureless. We can get the water from A to B, but what about draining? What about controlled filling, eg, filling only certain parts of the shaft, and not the whole thing? For this, we need to have a more complicated design. Principally we need to think about two things:
Intake
Let's assume we're drawing from an underground river, since pumping is almost certainly a necessity in this case. We'll assume an ideal case, where we can easily build perpendicularly to the river, in the event you can't, it's not difficult to adjust these plans, even if it is a little more difficult to construct the appropriate filters.
Here's the map:
############################################ 77777777777777777777777777777777777777777777 77777777777777777777777777777777777777777777 77777777777777777777777777777777777777777777 ############################################ ### #X# #X# #X# #X# ###
Symbology should be fairly obvious, but here's a key:
X : up/down stair (or whatever) # : wall 7 (or some number) : water at a given (listed) depth.
The simplest intake system is simply a shaft into the wall, use a channel 1 z-level above to cut it on, and some fortifications to prevent any unwelcome guests. However, this misses a brilliant opportunity to not only save on power, but generate all you'll ever need too. For example
############################################
77777777777777777777777777777777777777777777
77777777777777777777777777777777777777777777
77777777777777777777777777777777777777777777
###################__#######################
#FF#
#GG#
### #__#
#X#################__#
#X................D__#
#X########.########__#
#X# #.....# #WW#############
### #.....# #WW=====*=====*#
#.....# #WW#####|.####^-main power
#L...L# #WW#####|.#
####### #WW=====*.#
#WW#####|.#
... etc ...
X : Stair
# : wall
| : NS Axle
= : EW Axle
* : Gear assembly
W
W : Water Wheel
W
F : Fortification (here it spans 2 levels)
G : Floodgate (this is 1 z-level below, just wanted to avoid needing 2 maps)
Using a pair of levers here to control main power (all routed through one gear assembly) and one for water intake (through the floodgates). In the event you decide to dam your UG river (which can be done, but that's another post), perhaps so you can (safely) redirect it to be in a nicer location, you may want to replace the top level of fortifications with walls.
This design is nice because it leaves us with an iterable (you can make the shaft with the waterwheels as long or as wide as you like. I typically use a 3x5 design, the first power unit will cost 30 units of power (30u) to run, leaving me with an total generation of 270u for the first row, each additional row costs 22u, so my total system costs 30u + 22u + 22u = 74u, and generates 1500u, for a net of 1426u total power generated. Now we can talk about pumping water through the levels.
A naive design is as follows:
...outside world... Z-level n #D# #*# ##|### #_XX.# #####.#### #........# #........# #........# #........# ########## Z-level n+1 #D# #*# ###|## #.XX_# ##.####### #........# #........# #........# #........# ########## XX : screw pump, pumps from the side with the channel. D : a door
This system is "good enough" for simple use, our goal will be to make some simple improvements. Note that, since stone is so
unbelievably abundant, we just prefer to disregard the cost of mechanisms entirely. In fact, we disregard cost in general, especially when we talk about using computing here.
to be finished
Computing
I'd really like to see some kind of ability to hook gear assemblies to lever states in both directions. As it stands now, you can connect a lever to connect/disconnect gear assemblies. I'd really like to go from gear assemblies back to some kind of switch. This would make doing [computing] a bit easier, since rather than using the pump/plate method. I find that this is typically unreliable as a means of controlling things with logic gates, since they can get overpushed/whatever. There is some ability to protect against this with flipflops, since you could simply send the same signal to the "set" gate repeatedly without changing the state of the flipflop, and send the reset manually, but this requires even more parts and space, making any real system generally prohibitively expensive. Basically, I think putting in a "connect lever to state of gear assembly" option would be _brilliant_, so that when the gear assembly is powered, the lever is in the green (pointing right) position, when it is unpowered, it is in the negative position. Heck, even allowing levers to just connect to power, with the same semantics, would make life much easier.
Washout Defense
TBA