Bay 12 Games Forum

I'd take this a step further and make each species-gender a collapsible/expandable category, like the Stocks screen.  So at first you'd just see "8 male cats," "5 female horses" and so on.

The way the stocks screen is arranged[1], it'd be categorised as something like "Equine", "Ungulates", "Canine", "Primates", etc, then within the list (as expadned by <tab>) the creatures grouped in sub-type order (horse, mule, etc).  Possibly the marked-for-butchering ones get appended to the end by a different colour(like dump/forbid, and maybe melt, in the Stocks list).

If the stocks menu is being redone for greater control[2], then it could be done so that the the animals could be similarly sorted.  Your choice of gender/pet-or-butcher-statuses/animal families (and subtypes within).

But, for now, a hard-coded sorting by animal-type, then gender (or age) within, then age (or gender) within, and possibly pet-at-top-and-butcher-at-bottom either as the final sub-sort or at the first level...  Should be simple.  (Noting that I may be a coder in a number of languages, but I haven't had any opportunity to look at Toady's code, so I'm just going on the general principle, not the reality.  Nor am I accounting for Toady's priorities or own thoughts on this matter, of course.)


[1] It needn't be, but it the possible savings of time by re-using/adapting the existing code could make it easier to implement, and thus more likely.

[2] Multiple levels of expansion, and/or possibly choice of groupings so that all plant fibre footwear can sit together then whether they are socks or shoes, as opposed to being grouped as socks or shoes and then plant or silk (or leather, for shoes) within that as per present... and be able to supercede the (decreasing) value order within that by any other choice...

I'm sure I've seen this suggested before (at least alongside other animal-related chatter), but consider this a voice of support.

(I'd also like to see the gender of an animal in the "Assign to chain" menus.  I'm sure I've mentioned that, before, though.  In passing.)

Or would it leave 1 stacks all throughout the chambers beneath the forges?

AIUI, 1-deep magma evaporates into thin air, much the same as water.  If this is the case (I'm an "all or nothing", person, so 1-depth magma is usually only an issue for me at the forefront of a new route being flooded into) then as long as you can drain one spot of a magma-filled area, for long enough, any other 'column' of lava will redistribute itself around within the same area until it too finds itself drained (up, or down), and the process continues.

If you don't have an "infinite dumping ground" (or at least large enough to drain it all and let it settle into 1/7ths and less) I would personally try (for laughs, at the very least) a pump (or hatch) with a magma-sensitive pressure plate on the 'dumping' point that activates it only when there is no magma on that spot, to draw up/dump as much magma as available (the full 7/7ths of the one spot being drained) in the first instance, and with at least 7 squares of 'evaporation chamber' (but make it two or three times as many, to make sure) for this to level out into and dissipate.  Immediately the dunmping starts it'll shut it off, but when it's gone from the plate-top (noting that it might still be 1/7 or even slightly more in the other spots, as well as a delay in reaction, hence the multiplication of the space you make available) more comes in and redistributes accordingly.  It'd also be more efficient in its evaporation if it "spreads", rather than flows along a tunnel.

I'd probably try one of the following solutions (first for a pump from a channel, second for a lower-level cistern centred below a hatch, other variants are possible for same-level pump/floodgate/doorway control methods).

######
#++++#
#++++#
#+++^<<_
#++++#
#++++#
######

#######
#+++++#
#+++++#
#++^++#
#+++++#
#+++++#
#######

I think that floodgates also "chomp" anything that is flowing through them when they close (as my concern is usually preserving liquid water on maps with too little available, I try to avoid this situation, as well as 1/7ths evaporation, and without checking the wiki I can't be sure this is the case for magma), so maybe this could be developed into a method of getting rid of excess fluids.  I'm also not sure if you can Atom-Smash a flooded area free of its liquid (a 1x10 tunnel, or even a 10x10 cavern, with a bridge (suitably magma-proofed if necessary) lowering from the far end when a 1x1 alcove at one side detects the presence of the liquid), but something like that might be worth a try, if there's nothing on the Wiki or here that gives a definitive no!

Use doors instead of floodgates.  They can be hooked up to pressure plates, and are instantaneous.

Your choice.  I suppose I got in the habit of lever-controlled floodgates due to them not being 'pickable'.

Kobolds don't trip pressure plates or traps.

Wasn't sure at the time of writing, but, given one had apparently been cage-trapped, I thought I'd run with the idea.  Cage traps: yes; Weapon traps: no?

Still, the next goblin you cage would be a better ironic canditate for powering the "on/off" spikes or other reciprocating trap.

Something like the following, maybe:
   abcdefghijkl
 '''''''''''''''
 '''''''''''''''
1''''#F#######''
2''''# F^    F''
3''''# #####F#''
4''###F#   #^#''
5''FCF #   # #''
6''###^#   # #''
7''''#F##### #''
8''''F    ^F #''
9''''#######F#''
 '''''''''''''''
 '''''''''''''''

Assuming I've not made any errors (in understanding the mechanics/game behaviour or in the presentation of the diagram or following description), the "C" at b5 is the hostile's original cage, with floodgate (or other suitable switchable barriers) controlling access to the immediate outside world (a5) and "inner circle" (c5), controlled at leisure for the purposes of loading and releasing.  The cage can be conntected to the same control as the c5 gate, probably.  Start with all 'outer' gates closed except k2 and all inner ones closed except e2 and the one at d4, then let them loose.  Hostile heads towards 'escape' outside k2, wanders over e2 pad which closes e2 and k2, but opens j3 and j9 so it'll keep on going round to the new exit.  Hostile then activates j4 which closes j3 and j9 but opens i8 and c8, to similar effect.  Stepping on j8 closes i8/c8 and opens d1/d7.  d6 sets up the cycle again.  d4 closed, with a5 and c5 opened and b4 reset as a cage trap will bring the event to an end.  But while it's working, if you've set the pressure plates to perform other tasks (or linked up other ones, not shown), FNU!

A variation on that can be made which doesn't need so much of a micromanaged reset, and doesn't snare the hostile in the vicinity of the b5 zone, just confine them.  On/off control of this process can easily be made and configured with pressure plates and a single external "activate/deactivate" switch (or pressure plate from another goblin-powered ring to form an appropriate cascade of logic!)  If you're not as bothered about this automation, the c5 barrier can be ommited.  As long as a5 remains closed (i.e. you're not wanting to reclaim the original release cage, or set up anything else in there) there's no reason for it.

Obviously the reaction times of the floodgates is a factor (as might be the possibility of crushing the 'worker'?), so either longer legs of the 'circle' (with the added advantage of giving a longer period cycle, if required) or using hatch-covered pits (and an appropriate set of steps back up for those caught on them, just in case) would be a better barrier.  If you want to bash the invader around, 'launch' them around parts of the circle with lengthy bridges with an appropriate direction of raising, and see how long they survive...

Of course, my original thoughts were just about a reciprocating method ("Run run run, towards the western exit!  No, that's closed now.  Run run run, towards the eastern exit!  No, that's closed now. [...repeat...]") which would be far simpler, but not as much fun to look at.  And with a circuit, one can coral a number of hostiles through its system (inserting new ones all the time), where the slower ones get caught out by the barriers closing behind the faster ones.  (Though I'm sure you'll have realised that this causes problems with multiple plate activations, without a suitable 'buffer' mechanism to stop that.  And also some might possibly become caught behind closing barriers, and potentially escaping from the anti-clockwise exit when the leading ones reopen them, near the end of the next full cycle.

Less symmetrical (or just more convoluted) systems with other than four 'modes' can be made...  Never mind branched ones (figure-of-8 two circles joined being the simplest) with carefully equal-length exits (or externally and/or chaotically influenced escape-paths, to draw the hostile round one circuit or another) which is of course the start of any large-scale flow-based computational device.

I really ought to try this, you know (I have an excess of caged hostiles, a whole stockpile full of them, including a couple of elven members of the goblin masses).  But I'm not going to be able to play my DF at home until next week.  Darn, why do I always get ideas like this when I can't do anything about them? 

Yeah...early year 1.Im with my starting 7,no military.What could I do with him this early?

Set up a trap corridor, with him at one end, 'escape' at the other and (more or less) certain death inbetween?

Possibly even "Kobold Computing", if he'll activate pressure pads, by using a maze of corridors which open and close various exits as he approaches them, sending him backwards and forwards.  (Perhaps, in future, to cycle the spikes that invaders will encounter...  Would be mildly ironic if they're prisoner-powered.)

If that "rotating walls" idea was implemented, it'd also be nice if they could be used to make massive gears. I mean, we already have "gears" as a noun for fortress names; we might as well make good use of it.

Can't run flash on this computer, but I believe from the description that http://www.youtube.com/watch?v=ipaf-NXqF7Q is the one I intend to be a suitably witty response regarding revolving walls and other mechanical schemings.  (And, if not, it's probably funny anyway.)

No, didn't mean an atom-smasher.  I meant build bridges instead of hatches, as a "dump them down a level".

You see, I originally thought you were forcing them to take a circuitous path over hatches and then dropping them into water, I now think I realise that you're letting them walk in a drowning room, letting water flow in on them at this level and then drain water and enemies alike onto the grates on opening the hatches.  I think bridges will still suffice for that modus operandi.  And, if not, there may be another modification to the plan that you can make to effect a similar end.

You're still left with the grates on the level below needing full supporting (no simple "on-grate/off-grate" mass-area device, in the same way as a bridge analogues to a mass of hatches) but, except for slightly slower draining, you can modify the lower level to make all elements supported at the expense of some non-permeable flooring in the key additional-support locations added on to the "W"-plan, above.