Bay 12 Games Forum

{EDIT: This thread isn't really about a clock, even though it purports to be.  It's about creature logic in general.  If you're finding this on some kind of search, be aware that later posts delve into the things we'd need to make a programmable creature logic clock; the intro post describes a creature timing loop to find a creature of a certain speed, just as masturbatory indulgence in creature logic and timing effects.

If creature computing is your thing, you might want to check out my wiki user page at

http://df.magmawiki.com/index.php/User:Vasiln

I do a lot of theorizing and planning about both creature logic structures and the infrastructure needed to make them actually work on that page.}

No water, no wind, no power?  No problem.  You can still build a clock.

{UPDATE: There is now a movie to watch this thing in action, if you so desire.  I kept it relatively short.  It's at:

http://mkv25.net/dfma/movie-2364-dostngospthechosenone }

This is what I call a creature 40-loop:

Each corner pressure plate is linked to the adjacent hatch and door.  Important: the doors must be built before the pressure plates.  It keeps the goblin moving clockwise: at any given moment, there is always one and only one path for the goblin to take.  Alternating pressure plates link to an incrementation device (don't worry, I'll show you how it works in a bit).

I call this a 40-loop because it takes exactly 40 steps to get to where you were before.  You can make this loop as big as you want, but you can only shrink it so far-- a 16 loop is the smallest you could get away with with a 10-delay goblin like Dostngosp.  16 is plenty small, though, since you can fill the whole thing with pressure plates to trigger anything you want.  You could make a perfect 40-on, 40-off spike repeater out of this same circuit, use Dostngosp to drive both the spike and the clock at the same time.  It looks simple enough, but believe me, I went through a lot of failed versions before settling on this style.

All you need is one dwarf, a shitton of rock, and a delay 10 goblin.

What's a delay 10 goblin?  It's a goblin that takes exactly 10 ticks to move one step-- never more and never less.

"Yeah, I could build a clock with a delay 10 goblin-- and if I had a million bucks, I'd be a millionaire."

That's right.  So how do we get a delay 10 goblin?  We're going to examine each goblin we get, watch it take about 3000 steps, and make sure that it never takes 9 or 11 ticks to take a step.  I figure it should take about 400 goblins before we find one that works.

Don't worry, you're not going to do it manually.  We're going to build a goblin QA device.



So the goblins get dropped into someplace (I use a mass pit, but dropping them from a bridge trap would work as well), get separated and shuffled off to the QA.  Let's start with the first part of the QA process, rule-out fast:



This one is pretty simple.  That pressure plate is linked to everything you can see.  Goblin travels left to right.  Pressure plate blocks off the hatch, so the goblin doesn't escape downstairs; it opens the doors, so the goblin can proceed (the two adjacent doors are a legacy of a previous and-gate, but I don't use the and function anymore); it opens the far door, making the goblin think he has a path; it opens the far hatch, so the goblin thinks his path is downstairs.

If the goblin has a delay of 9 or less, he reaches the space occupied by the door before it closes-- then he escapes.  Otherwise, the door closes, hatch closes, goblin re-evaluates his path, and continues forward to the rule-out slow.



So this is simple too.  The pressure plate is linked to a hatch cover and to two doors on the far end.  Yes, two doors-- one of them is open in this picture.  You'll see why.  Important: doors must be built after the pressure plate!

Goblin is pathing to the downstairs, but when he reaches the pressure plate the hatch doors close and he loses path.  No problem, because the newly opened doors ahead of him give him a new path.  He races towards them.  If he is delay 10 or faster, he reaches the second door just as it closes-- in fact, if it takes him 100 ticks to reach the far door, it closes on the exact tick he reaches it, and it gets wedged open, like you see here.  If he is even one tick slow, the door closes in his face, he waits for the hatch cover to close again, and escapes downstairs.

In case you're curious, rule-out fast and rule-out slow were both relics of a previous loop design, where it could be screwed up by certain speeds of creatures that were much slower or faster than the 10 delay I was looking for.  I left these two initial passes because it eases design-- it's wonderful to only have to consider creatures taking between 9 and 11 ticks to cross a tile, much better than having to consider every possible speed of creature.

If the goblin had the right speed, the door more towards the left is now closed, and he continues pathing down to the initialization of the main loop.



So don't get intimidated by all of the doo-dads in here.  Start with initialization chamber: goblin is drawn down by the exit, but a pressure plate opens the hatch before he gets there.  That same pressure plate opens the door entering the loop as well as the first door that the goblin will run into after entering the loop, goblin can now path to the next pressure plate.  This pressure plate opens a far door (important: build this door before the pressure plate).  Ignore the rest for right now.

The goblin's in the loop.  He paths to the far exit; the door just in front of it will close 99 ticks after he leaves the pressure plate.  He will reach the space the door occupies at tick 100.  If he crosses the 10 tiles in only 99 ticks, he's home free.  But he doesn't.

Let's continue on to the next arm.



Look at the pressure plate with the yellow line.  It's linked to a door that's currently open-- you'll see why in a second.  Important: this door must be built after the pressure plate.  It will close exactly 100 ticks after the goblin leaves that pressure plate.  If he takes 101 ticks to cross that space, it closes in his face.  If he takes 100 ticks exactly to cross that space, it closes on him (and is wedged open, as shown).

Look at the red pressure plate.  It's linked to the door as shown.  Important: this door must be built before the pressure plate.  It will close exactly 99 ticks after the goblin leaves the pressure plate.  If it takes him 100 ticks to cross that space, it closes in his face.  If it takes him fewer than 100 ticks, he escapes.

That should demonstrate the basic loop.  What about the rest of the stuff?  All of the doors on the inside of the loop are for building access only; now that the loop is finished, I could remove them.  The hatches on the outside are important because they give an escape route to a goblin that moves too slowly; the hatches in the middle of the loop arms block retrograde pathing down these escape routes for a goblin moving at the proper speed.  (Goblins move counter-clockwise in this loop.)

So far, so good.  But like I said, I expect we need about 400 goblins.  We're not going to be dropping them in individually.



So goblins get dropped down from a mass pit on to the leftmost square here.  You can make this chamber as big as you want, to accomodate as big of a mass pit as you want; you can also connect this chamber to a pit under your entrance bridge, so dropped goblins make it down here.

Goblins path through the pressure plates toward the QA process.  Each pressure plate is linked to the orthogonal hatch.  The presence of a single invader on a square thus blocks access to or past that invader's square.  A door, currently open, connects the system to the QA process; escaping goblins trigger a pressure plate that opens the door, giving entrance to the right-most invader for non-stop testing.  (If the goblin-well ever runs dry, you will need to manually open the door via a lever to get the process started again.)  Goblins that fall path back up the ramp to this chamber.

This is one of the imperfect parts of the design-- occasionally, two invaders will make it through into QA, gumming up the process.  Eventually, the system will get back to normal, but it can take a long time.  I haven't figured out exactly what's going on yet; when I do, I might be able to make it perfect.

Okay, so that's out of the way.  Next problem is that we need a lot of confidence in our invaders delay.  An invader with delay 10.01 has a 67% chance of making it through the loop once; we want a lot more confidence than that, but we don't want to sit around counting the times the invader has looped.  We're going to build a counter.

An invader with 10.01 delay has only a 9% chance of making it through the loop 6 times.  Let's build a six-count.



My goblin counters are pretty simple.  Each pressure plate is linked to all adjacent hatches.  A pathway of doors provides a route around the hatches.  These doors are triggered by alternating pressure plates; in this case, the NW pressure plate on my main QA loop is toggle1, and SE pressure plate is toggle2.  Each time the goblin loops the QA loop, the goblin in our 6-count moves forward two pressure plates.  Three alternating doors provide escape routes to the goblin-- don't worry, he'll never reach them.

There's only one problem with this-- what if the QA goblin makes it around the loop a couple of times and then fails?  The 6-count needs to be resettable.



We already have our escape reset switch to allow the next goblin into the QA (actually, it's also linked to the doors that can get wedged open in the main QA loop, to reset the system for the next goblin).  We build a little escape into the middle of our counter, gives access to it from any pressure plate, and link the doors to our reset.  When a goblin escapes the QA loop, our 6-count goblin returns to the beginning of our loop, and an ad-hoc AND gate permits access the next time a goblin runs the QA loop.

Just so you know, this 6-count loop is really sloppy.  I didn't care about timing too much.  Really, our reset ought to lead us to the first position in the loop.  All I cared about was making a really big number.

No, 6 isn't so big.  But then, 9% chance of error is too high for me.  And what if the game works such that our test invader has a 10.001 delay?  We need to test that goblin many more times than that.



This is basically the same thing-- except it has 25 cells and it's in a straight line.  In fact, it's equally sloppy.  This is my first time making these things resettable.

But rather than toggle 1 and toggle 2 being driven by the QA loop, they're driven by the 6-count loop-- at the 6th and 12th cells of the 6-count.  Once a goblin escapes from this 25-count, he triggers a trigger-once pressure plate that closes a pretty bridge on the surface, and I know that a goblin has been running around in my QA loop for about 3000 steps-- for 30,000 ticks.  Even if he can have a delay of 10.001, there's less than a 5% chance of that goblin making through my entire QA process.  (And if you're curious, when I found Dostngosp, I had him run through again, for higher confidence, and he passed again.  Odds of that happening to a 10.001 are about 0.25%.  Not 25%-- 0.25%.)

Why's it a 25 count and not a, I dunno, 12.5 count?  Mostly just because it doesn't trigger any further counters.  So every step of this matters, instead of every other step.  Every 6 steps of the 6-count triggers one step of this; every twelve, two.  We could just as easily call the 6-count a 12-count and call this a 12.5-count.  It adds up to the same thing.

What about the clock?  Look at that 6-count.  Couldn't you as easily make 3-count?  (You can.)  How long does it take a 10-delay invader to run a 40-loop?  400 ticks.  What's 400x3?  1200.  How many ticks are in a day?  1200.

Couldn't you make a 7-count?  Yup.  Couldn't you make a 4-count?  Couldn't you make a 12-count?  All of the above.  And you have week, month, and year.

In fact, there is only one problem remaining, but it's a doozy.  Attribute rust.  In fact, rust will occur in less time than it takes an invader to complete my QA process.  This is the one place where my clock requires cheating: it requires modifying goblins (and/or elves) to suffer no attribute rust.

I was doing some agility and timing tests recently, trying to figure out my goblin clock, and ran into some data that contradicts what is popularly 'known' about DF.

Using runesmith, it's easy to make a goblin have any agility.  So I was playing around with agility values.  Naked, unwounded goblin, of course, although it'd be good to hear of any other variables people think might matter.

The first surprising thing is that a goblin with 1000 agility (the average) does not move every 10 frames.  Most of the time, he moves every 11.  Now, this would be easy to explain as an error by 1, except it's not even every 11 either: it's more like he moves every 10.9 frames.  (In the pursuit of a 10-frame step, I settled on an agility of 1200: looks pretty good after a hundred steps or so).

For kicks, I looked at the same goblin with agility of 1 and with agility of 5000.  The goblin with an agility of 1 moved every 14 frames-- didn't test for long enough to rule out fractions.  The goblin with an agility of 5000 moved every 7 frames.

So I suspect that while 1000 agility is the typical value, it's not the value at which every thing comes out even.  I'd suspect agility to function as a logarithmic scale, probably base 2, maybe natural log, but polling a few more data points could confirm it. 

So I was noticing that dwarven water logic is pretty complete.  Still, I noticed one missing function: the random number generator.

Why do you need a RNG?  Let's consider that you're integrating water logic with a creature based timing system.  You have a goblin with agility 1050.  Half of the time, he will cover 10 steps in 100 ticks; half of the time, he will cover 11.  You can build a path that is 10 or 11 steps long, but not 10.5 steps long.  You can't build a system that makes the path 11 steps long every 100 ticks and 10 steps long every 100 ticks, because that's begging the question; if you had a 100 tick timer, you wouldn't need the goblin based timer in the first place.  The answer?  A path that is 10 steps long 50% of the time and 11 steps long 50% of the time.  Over 100 ticks, it won't be accurate, but over 10000, it will be good.

Now, the big problem with the dwarven RNG is testing.  It's easy to assume that the 3/4 bridge/floodgate repeater provides a 50/50 of 3 or 4 water level.  But does it?  Maybe it's 3 deep 75% of the time?  66% of the time?  The ultimate test of an RNG would be a cumulative test: a read-out displaying the ratio of on to off that approaches 50% as the fort ages.

I don't know the answer.  I'm just throwing this out there as a potentially solvable logic challenge for players much more skilled than I.

So I was thinking of more fun stuff for ghosts to do, stuff that's sort of appropriate.  How about machinery coming to life on its own?

Right now this would only affect screw pumps and mill stones.  But screw pumps can cause some serious havoc when they run on their own.  I think it would be fun.

I think this should be something reserved for energetic poltergeists, with the poltergeist spending a little bit of time on the machinery in question, sort of how ghosts haunt specific people sometimes.  If it would be possible, it would be especially cool for miller or pump operator ghosts to do this.

This is partly a suggestion, and partly a query to the DF folks about the best way to do it.

So, all this talk about vampires has me thinking about some of the stuff that Toady hasn't yet talked about dealing with: can't enter without invitation, repelled by the cross, by garlic, can't cross running water.  I think Toady wants vampires to be procedurally generated such that all of the things involved in real legends are at least possible, but sort of randomly determined.

Of course, there's vulnerabilities, but it's not like anybody's going to have a +garlic halberd+ right?

So I was starting to think about pathing restrictions for certain creatures-- cursed creatures, for sure, maybe other creatures.

There's loads of awesome stuff you could do with this, that would lead to fun discovery in-game: like the vampires in your world can't stand fisher berries, that they can't stand images of two flasks or of Zuglar contemplating (because the image of the cross stuff isn't really appropriate), that they can't walk over running water, can't walk over running magma, can't go through an unopened door, can't walk over a piccolo-- you get the picture, it could be cool figuring out what you needed to do, and discovering some accidental sanctuary.

But the part that I was thinking about was the details.  Could you do some kind of pathing cost?  That would make it so vampires could be forced over garlic, but they'd take almost any other route in preference.  Could you just ban a certain creature from a square, make him jump back and recalculate path?  That seems like it might be problematic if there were two bane squares next to each other, with the vampire just pathing alternately between them uselessly.  Could you treat bane squares as locked doors, impassible, not to be pathed through?  Not sure how pathing works, if it would be difficult to notify each square of a "do not path vampires" every time you dropped some garlic on it.

And what about combat?  Would carrying fisher berries make the vampire jump back, fail in all attacks?  It would be uncommon enough in dwarf mode, but exploitable in adventurer mode-- once you learned the secret, at least.  Maybe it should be exploitable?  Should it just autofail vampire charges, as they can't enter your square?  Or should it have no effect?

I think this has the potential to be really interesting, the sort of thing that makes a player feel smart when he or she figures it out and exploits it.  It's not just about vampires-- i think bogeymen and clowns would both benefit from procedurally generated banes like this.  I mean, how cool would it be to realize that your engravings formed a tiny square of protection?  (Now all you have to do is get your dwarves to stay there.)  It would also have the potential to draw flavorful things (crafts, images, etc) into gameplay.  An amulet might suddenly become very important to a player, depending on what it depicted.

Currently, the magma forge is designed to work off of, well, magma-- doesn't matter if the magma is hot or cold, just matters how deep it is.

Why not change it so that the magma forge works based off of the temperature underneath its impassible tiles, rather than the presence and depth of magma?

Why?

It would play better with the rest of the game.  In the future, we can imagine various things that can provide great heat other than magma.  Some of those things already exist, in fact; how cool would it be to run a forge off of the heat of a trapped creature with a tremendously high homeotherm?

Why not?

Maybe because it would end up breaking the minimum magma depth mechanic-- even magma 1/7 provides that heat, if I'm not mistaken.  But that mechanic isn't very significant, now that there's magma on every map (used to matter, if you relied on the pits for magma in 40d).  If you can make 1/7 magma, you can make 7/7 magma.

Fifteen stockpile pages of leather...  forty of meat...  deep metal secrets spoiled by forge and stone options...  mysterious creatures, even mythical creatures, showing up on options...

I propose that stockpile and workshops only show you options that you have stocks for.  For instance, if there's only mountain goat leather on your map, when making a stockpile, you only have the option to stockpile mountain goat leather or all leather, not every conceivable type of leather.  If you don't have any orthoclasse, then you can't nominate it economic, because it doesn't even show up on the screen.  If you lack garnierite, then you can't even see that you can make nickel.

(One option here is to also let you see things that any of your dwarves have preferences for.)

Why?  One reason is because these lists are getting totally out of hand, and they'll only get worse.  A player that actually wants to stockpile a particular piece of leather faces the herculean task of actually FINDING that option on the leather list.

Why else?  Because the way it's done now, a certain sense of mystery is destroyed.  Sure, you know there are dogs, you saw them when the trader brought them.  But voracious cave crawlers?  Should be a new and exciting encounter.  Deep metal/stone discovery should be a "holy cow what is that" experience rather than spoiled by stone and workshop options.

Admittedly, this spoiler effect is not as important for those of us that are already heavily spoiled.  However, it is a big part of a new player's experience, and it's important for mods, and for anything that will ever be procedurally generated.  For instance, there is a good suggestion currently on the forum about procedurally generated forgotten forests.  Seeing the wood type on stockpile options would destroy the mystery that discovering a forest like that would generate.

(As for reasons not to do it this way: I think some people like being able to see the invalid, red options on their forges to easily figure out what's missing.  Maybe it could be along the lines of discovery: once you'd forged your first bar of steel, the option wouldn't disappear just because you lacked flux.  There's the potential that some players might like to get stockpiles ready before encountering something-- is that a significant concern?)