Bay 12 Games Forum

the Pied Piper, bridge variation, COULD be used as an emergency entrance as well. (Which is what I thought it was for, to get people inside if they're outside when the siege shows up.) IF you close your gates, put out an alert, and then activate the entrances, then everyone outside will march to the nearest emergency entrance, step on the pressure plate, march up to the wall, and fall a safe 1Z into a corridor below.

There's two problems with using pressure plates/hatches for emergency fort access:

1) Building destroyers

2) No way to make a pressure plate triggerable by only citizens and not invaders

Here's what I would start with for an emergency entrance:

######
h^hhC#
######

h is hatch: middle is over a down stairs leading to your fort, first and third are over channels; ^ is pressure plate (citizens trigger) linked to all hatches and the door;
C is construction designated for removal; best to link leftmost hatch to lever so you can turn it off when desired

Now, outside dwarves path to the construction, find no path when they get there, and no path to anything outside, but now there's a staircase going down into your fortress.  The hatches form a sort of airlock, so there's never a path into your fortress at the same time as there's a path into the device.  Very close invaders still have a remote possibility of making it in along with your dwarf, but it's only a small chance, and there shouldn't be many of them.  Dwarves shouldn't path up while the hatches are open, because it's not a path to anything interesting or anything that needs doing, but if they do, they won't be able to leave the device.

To protect against building destroyers, you need something like:
 
######################
^bbbbbbbbbbbbbbbh^hhC#
######################

Right section is as above; b is bridge over channel; left ^ is pressure plate (only invaders trigger) linked to bridge

It's ugly, but it'll keep out trolls.  Won't work against titans.

If what you want to do is drop all of your dwarves into a deep, deep pit, you build:

 
###################
bbbbbbbbbbbbbbb^hC#
###################

Pressure plate is citizens trigger, linked to both bridge and pressure plate

It's not very pretty.  Not good for emergency access, because you drop near-by invaders as well, and invaders may wander onto the pressure plate themselves (if pursuing a path to a dropped dwarf, maybe?)

Longer bridge is better; fastest possible dwarves will escape this one.  If you don't want to drop all of your dwarves, it's easy to filter by assigned jobs or specific (adult) dwarf-- replace the construction with profiled lever, or with a workshop.  If you want to filter out adults and only grab children, you build pressure-plate controlled access onto the left like so:

 
##
^h
##

You just set the pressure plate to only trigger at certain weights-- 35k+ should keep out even small adults, although it might keep out some large adolescents as well.    Build it with a lower value (15k+?  Needs testing) and leave it open to institute an "Only huge children survive to age 3" eugenics program-- they won't accept the job as a baby.  As with all of these designs, you'll want to be able to block access with a door/bridge to prevent job spam.

This doesn't work: hatches activate instantly.  The dwarf will step onto the plate, and the hatch opens immediately.  Without a path, the dwarf will cancel the job and wander off.  Replace the two hatches with a drawbridge that raises towards the plate.  This will cause the dwarf to step on the plate, and walk forward.  100 ticks later, the bridge will raise, forming a wall, and negating any "fling" from the bridge, due to the 1x1 space.  With an empty space there now, the dwarf falls straight down, and the bridge resets.

Good luck doing this in time to get all your dwarves inside during a siege.

The point's not to drop them-- it's to summon them.  (You're right, though, that a bridge based construction similar to this could be used for dropping dwarves, if that's your thing.  I'm pretty sure you'd need to reload it every once in a while though.  Still, it would be more useful for most people than my device.)

What you do is build several of these deep in your fortress.  Depending on population, you might need a lot, but they're simple so you can do that.  The dwarf gets there, cancels the job; 100 ticks later, the path opens up again, and some dwarf-- maybe the same dwarf-- takes the job.  You need a number of these proportional to your population, but every idler will get grabbed.  The further you place these from where you don't want your dwarves, the better.

The dwarves might wander off when they lose path, but the job is high enough priority that as long as one of these is unclaimed, they won't wander far, and you've already done your job by bringing them to a certain location.

It'll work nearly instantly-- almost as fast as you can pull a lever (and consider a high-speed creature-based switch if that's not happening fast enough for you).  Remove construction is a super high priority job.

I envision using this to control year-long flow through a fortress.  With slightly more than your population, you can bring your entire population to any particular point in your fortress just by flicking a switch.  As soon as you want them to return to work, you close the hatches.

EDIT: If you're not so hot on the idea of idler/child summoning, maybe you'll see the value in a small variation-- I call it the Undump.  They're gonna be big one of these days.  One day, you'll say things like, "Yeah, I used to play DF, before undumps came along and ruined stockpiling."

 
#####
^shs#
#####
h is hatch; ^ is pressure plate, citizens trigger, linked to hatch; # is wall; s is stockpile (same type)

Single tile stockpile while preserving dump functionality, without having to mark anything as dump.  Tested.  Works.  No bins necessary, etc.  Works great for mechanisms, doors, bags, corpses, hair, skulls, ammo, even stone should you feel the urge for a clean fortress.

Then again, I might just build one.

Here is my plan for 16 bits of memory.  I plan to have 8 of these, to run 4 bit instructions taking a 4 bit address argument and to have 8-bit data bytes.  Of course, you can always use more than 1 byte to store a value.



First thing you might notice is that 16 bits are a lot more streamlined than our single bit with addressing goblin.  We can use a single goblin to read from or write to the specified bit.  That unfortunately means he's going to be moving slower though.

Second thing you might notice is that everything is a little streamlined.  We still have 4 paths per bit, but we're reusing some of those paths.  Since our addressing goblin is guaranteed an addressable bit, we don't have to give him a backup path.  Our memory doesn't have the side doors either.  That's because I realized we don't need them.  We just send a trip to one of the hatches between memory states.  (By trip, I mean an open-close signal, like we get when pathing over a pressure plate.)  That's a little slower, and I might build doors in later.  I've got the room.

Next thing you might notice are two special memory bits.  They're versions of my memory 2.0.  That's because these are going to have special functionality.  Together, they will form a 16-bit clock that I can read from.  That's nice functionality for any programs we might write.  The first clock bit toggles from a clock signal, and each succeeding bit increments every time the last bit goes from 0 to 1.

But I can also write to them.  That's important for a couple of reasons.  One is that if my clock rolls over to 0 before I check for time>clock+100 (for instance) then my programs won't work.  So I want to be able to zero my clock.  The other reason is that 16 bytes aren't a lot of memory space, and I want to be able to use these clock bytes for regular computer purposes if I don't need my clock.

Wouldn't positions 0 and 1 make more sense for my clock bytes?  Or 14 and 15?  Yeah, but reading from clock is very timing dependent.  I want these bytes close to my addressing goblin.  In fact, my increment clock signal needs to open a hatch for each clock byte to prevent reading or writing during state transitions.  (I can already write without triggering the increment feature.)

There's one more thing I'm going to need, because if I want to use my clock bytes for regular data, I need to output to clock, to send Dostngosp along an alternate clock loop (so he keeps time) that doesn't increment my clock bytes.  I could make a special output instruction, since I now have room for 16 opcodes and only use 6, but instead I'm going to designate an output byte.  That means that the state of my clock (increment clock bytes, or don't increment) is going to be determined by one of my memory bits.

But I'll eventually want to output to other things as well, and I don't want to waste a byte on each output.  So we're going to need a way to write bits to memory instead of bytes.  Right now, we don't have that.  We'll need a new instruction for our cpu.

There's one other thing.  Our computer is going to run really, really slow.  It won't be able to keep up with the numbers on our clock.  So we're going to change our comparison instruction from a "jump if reg1=reg2" to a "jump if reg1>=reg2."  That'll work for clock programs, and it'll still work for FOR loops.  Mostly, we can use our exact same comparison design-- we already have an arm that fires if reg1 is 0 and reg2 is 1, and vice versa.  We're only going to have change how we handle the integration of 8 of those signals.

EDIT: Actually, I can read and write bits.  To toggle bit 0, for instance, I increment it once.  To read bit 7, I see if it's >=128.  Reading bit 0 takes a lot of operations and/or constants, and writing to bit 7 takes a lot of incrementation.  I don't think I'll have the memory to read bit 0 (but there's probably a trick to trade speed for memory.)  Someday I'll need bit-specific operations, probably a position shift, but for right now I won't worry about it.

Also, my output byte should also be an input byte, to report on the status of every device outputted to.  That way I can still have a lever controlling my drawbridge and maintain programmed drawbridge functionality.  So the output byte will need to be synced like the clock (outside input blocks read/write access via a hatch triggered with every write) to prevent simultaneous read and write operations.  This goes both ways (for the clock too).  Since I can't slow Dostngosp, I'm going to block access in anticipation of his write, as well as following his write.  Maybe I'll only allow a brief window to write.  I'll need adressor ground after all, for when no path is accessible due to outside writes.

If you had a lever hooked up to a hatch such that the lever-puller is dropped into a pit, then hooked up a pressure plate where the droppee would land, would the following sequence

Spoiler (click to show/hide)

1. Urist McUnlucky pulls lever.
2. Lever gives hatch "open" signal and opens.
3. Urist McUnlucky falls.
4. Urist McUnlucky hits pressure plate.
5. Plate gives hatch "open" signal, but the hatch is already open.
6. Urist McUnlucky dies or leaves hatch.
7. Plate gives hatch "close" signal. Hatch closes.
8. Urist McOnlySlightlyLuckier pulls lever.
9. Repeat from Step 1 as desired.

occur?

As has been said, it won't work because your dwarf will stand on the lever square to pull, but other than that, your reasoning is correct.  The pressure plate will send a close signal that will automatically close the doors.  In fact, even if another dwarf was standing on a different pressure plate someplace opening the hatch, the close signal would still close the hatch.

This can cause problems for some designs; it can also be useful.  I've been using the effect frequently recently in creature-based logic machines.

It's true that you'll need to pull the lever twice-- as first pull will send close, second will send open-- but it's easy to just queue up two pull tasks for each lever; the same dwarf to accept the first job is almost guaranteed to accept the second job.

(The thing I do is to make a lever and a pressure plate in front of it.  The pressure plate is the trigger; the lever is connected to nothing, and is designed just to send a dwarf over the pressure plate.  That way my devices sort of automatically reset to base state.  Not what you want for a drawbridge, but what you want for your sort of device.)

Here's what I'd do for your sort of device:

 
#############
bbbbbbbbbb^l#
#############

b is bridge, ^ is pressure plate linked to bridge, l is unlinked lever


Dwarf walks over, trips the pressure plate; depending on speed, bridge drops him.  Longer bridge is better, as fast dwarves will get away before a ten-long bridge opens.  Close signal gets sent from pressure plate after drop, system returns to base state.

Like? When I want 'em to go somewhere IMMEDIATELY, I kinda need 'em too. Set them all to make stone bins? x.x

Thanks for the help, btw.

In my forts, creating a big stone stockpile usually does wonders for pulling in idlers.  Just have to remember to delete it afterward.

(I can't use civilian alerts because I generally run close to 100% military.  Never seemed to work on unit members, even if inactive.  Maybe I never gave it enough of a chance.)

Just get the runesmith utility and set attributes your self, eliminates testing.

The thing is, it doesn't work.  First you have to know what causes a certain speed; as far as I know, that's not a solved problem.  Yes, agility and strength affect it, but so does something else, something unknown.

I'd try this but I don't think I can even grasp it, let alone comprehend it.

I'm happy to explain anything.  The fun in this for me is totally in figuring it out, and I think just a little bit of understanding can get the creative juices really flowing.  Basically, anything is possible.

One thing I don't mention very much is the basic layout of controlling goblin movement.  It's totally based on Fenwah's goblin grinder designs described at

http://www.bay12forums.com/smf/index.php?topic=62798.0

and I totally owe Fenwah a shout-out.  I think a lot of people missed the fact that Fenwah's real innovation wasn't the goblin grinder trap, but the high speed switches he (she?) designed.  I straight up ripped off one of those switch designs are my basic memory cell.  (I didn't even realize that until I just looked at the thread again).

1. While this DOES make it less dwarfy, it is easier to get 400+ cats or tame birds than goblins. To make up for it, drop failing cats/birds to give the clock a nice red coat.

Isn't there a breeding limit?  And it's hard to kill off cats to get a new test set.  In the meantime, the goblins send me about fifty invaders once or twice a year.

And they don't die of old age, don't have babies, don't eat or drink, don't sleep, don't go berserk or melancholy.  Flightless birds might be okay, but they still die of old age.

Mostly, I'm just not too familiar with domestic pathing, and by now I'm really confident about invader pathing.  Like, aren't cats trapimmune?  And what if they start pathing to some vermin in the same cell as the cat?  Plus, building these pressure plates with citizens trigger would mean build hell-- think of all those stuck dwarves.

2. Speed is measured in hundredths of a step between moves. To my knowledge, a creature cannot have a fractional speed.

You notice that I talk about delay, not speed.  That's because delay is something that I can observe, whereas speed is not-- although you can express either as a function of the other.  When I say that a creature has a 9.99 delay, one way to think about that is that it's a creature with 899 speed.  That means a 99% chance of moving at delay 10 with any given move, and a 1% chance of moving at delay 9.  The probabilistic nature of movement is one reason that I have to run creatures through the loop so many times, and even then, I can't have full, 100% confidence that they're actually delay 10.

Delay should be (speed+100)/100.  But attributes modify speed, and don't do so in integer based increments-- a creature with 900 speed and high agility, for instance, might function as if it had a speed of 850, so what would high agility do to a creature with base speed 100?  Same modifier would lead to fractional modified speed unless Toady rounds it, and he doesn't have to round it to the nearest whole number.  There are other modifiers too, ones that I don't understand.  But the overall picture is that I'm not going to work under the assumption that delay*100 is an integer.  Well, at least, I don't have full confidence in that assumption, even if I do believe it.  (Notice that I have been working under the assumption that some multiplier of delay is an integer.  Otherwise, there is no way that I can ever have any level of confidence in my delay 10 goblin.)  (Heavily edited this section because I got it wrong the first time-- so if you're saying, "Wait, you were wrong and you changed it!" you're correct.)

On preview:

Having watched the video, I have a question:

Why is it that you can forbid the doors even after goblin prisoners pass through them without the doors becoming claimed by the enemy and thus uncontrollable? Is it because the goblins are trying to escape rather than attack?

Wow.  That's a good question.  I've never even stopped to think about that.  I guess it must be because they're all captured and in flee mode.  (Just in case it's not clear, those are just manual switches that allow me to set memory values before my whole computer is finished.  They can be easily automated, as demonstrated by the memory and register cells.)

Okay, excuse my tangents, and permit me a new one.

I've just been making components so far, but it's time for the big picture.  I've got to figure out exactly how my processor is going to function.  There's got to be a flowchart:

1) Read 6-bit value from memory address pointed at by 3-bit next_instruction_address register into buffer (I was calling this a register before, but now I'm going to call it a buffer)

2) Increment next_instruction_address register

3) Copy first 3 bits of buffer to 3-bit next_instruction register

4) Copy last 3 bits of buffer to 3-bit instruction_target_address register

5) Evaluate next_instruction:

 a. 000: Jump: Set next_instruction_address equal to instruction_target_address
 b. 001: Read to register 1.  Write 6-bit value pointed at by instruction_target_address into buffer.  Copy buffer into 6-bit register_1.
 c. 010: Read to register 2.  Write 6-bit value pointed at by instruction_target_address into buffer.  Copy buffer into 6-bit register_2.
 d. 011: Write from register 1.  Copy 6 bit register_1 value into the memory cell pointed at by instruction_target__address
 e. 100: Increment register 1.  Add 1 to the 6-bit register_1 value.
 f. 101: Compare registers.  If register_1 is equal to register_2 then set next_instruction_address equal to instruction_target_address; otherwise, don't do anything

6) Repeat.

So to make this I'm going to need:
 a 6-bit buffer (writes to and reads from any memory; writes to and reads from register 1; writes to register 2, instruction register, and instruction_target register)
 a 6-bit register (write to or read from buffer; increments; compares to register 2)
 another 6-bit register (read from buffer; compares to register 1)
 a 3-bit next_instruction_address register (increments; reads from instruction_target register; addresses memory)
 a 3-bit instruction_target register (reads from buffer; writes to next_instruction_address; addresses memory)
 a 3 bit current instruction register (evaluate to determine instruction)

We know how to build increments.  We know how to build memory.  We know how to read and write.  We know how to address memory.  In fact, the only thing we need that we haven't already built is a compare function.  (We'd be better off using an add rather than an increment for instruction 100-- we can always store a 000001 someplace in memory.  Hell, we could design an add that outputs to register 2, store a 000000 in memory, and then we could free up instruction 010 also, although if we did so we'd probably want a write from register 2 instruction.  But increment's good enough for now.  After all, with a loop, we can add anything anyways.)

And with that, I'll have a programmable computer.  Of course, the only thing it'll really be able to do is run a FOR loop.  I've got space for two more instructions.  Any suggestions?

Uh, no, the children DO kill the animals.
I have actually had a child go into a rage before.
Trust me. It does happen. This happened in only two years, with ONE kid.
Spread that across 12 with 3-6.

You're right, I wasn't considering berserk children.

Still-- wouldn't going berserk be less likely with friends, and with more room for happiness-inducing stuff that larger chambers could afford without sacrificing creature density (because all of the children and all of the animals were in one room)?