Bay 12 Games Forum

Of course it wouldn't really take 12 million ticks   You can see from the movie that most invaders fail within 20 steps.  Even a 10.01 goblin is more likely to fail than not before his 2nd time around the main loop.  Evaluation of invaders is limited by number of invaders, not by loop time.

There are actually a number of reasons not to use clowns-- hard to get, don't set off plates, building destroyers, fly over hatch spaces, don't path predictably.  Also, they don't have 0 speed.  All of the ones in my game right now (just checked world.dat) have default speed (900) but high attributes that make them faster than normal speed 900 critters.  Essentially, they're the worst possible clock generators.  At least FBs path predictably.  It's too bad, because it would be pretty cool to use one.

Goblin-based binary memory

This is my first-generation goblin memory cell.



If you followed the counter construction, this should be pretty obvious.  Plate/hatch combos at either end block access to escape and block return to position.  Doors on left and right allow one-way motion when opened.

You can do a few things with this cell.  You can evaluate for state (say, true or false, or 0 or 1, or north or south, however you want to think about it) via linking the bottom and top pressure plates to things like doors and hatches.  You can set the state of the memory to north or south by opening one door or the other.

There's also something a little weird you can do that's not necessary for most memory: you can send a toggle signal.  You do this by sending an open-close, as you'd get with a creature walking over a pressure plate, to the hatches in the middle.  The close signal will override the open signal sent by the goblin standing on the pressure plate, and he'll cross to the other side, no matter where he's standing.  Toggles are nice for increments-- you don't have to evaluate the memory cell in question to decide where to set it.

If you think about it, this cell has some problems.  You have to close a door before you open the next one.  That's easy enough with pressure plates, but look at the signals the goblin in this pic is sending-- he's sending an open to someplace, with no close scheduled.  That could be a problem if you want to chain a few of these together.  (Depending on what kind of effect you're going for.)  You could get around this, now that you have a clock-- limit signal propagation to certain frequencies, send resets every-other step-- but gawd, that sounds complicated.

What about if you just made it 1 tile taller and put a pressure plate in the middle?  That would be okay, because at least you could send an on-off, but the goblin would trigger it regardless of whether he was moving north or south.  You'd need to AND that signal with the state status of the memory cell to get a useful signal.  Inelegant.

Enter memory cell 2.0:



You might feel this is a little bit big for a binary memory cell.  It is.  It's designed to do everything we would ever want to do with a memory cell.  It'd be easy to reduce size if you were willing to settle for reduced functionality.

Right now, goblin is at north end-- let's call this 1, and south end 0.

We can set state = 0 by opening the eastern door, or set state = 1 by opening the western door.

We can toggle in a number of ways.  Preferred method is to send an open-close to the hatches to the east and west of the doors, because this moves the goblin in a predictable loop (clockwise).

We can evaluate for state by looking at the northeast or southwest pressure plate.

We can also send state changes by the northwest and southeast pressure plates.  These state changes are nice because they're predictable-- anytime goblin changes state from 0->1 he triggers NW, anytime from 1->0 he triggers the SE.  They're also nice because they make this system repeatable.  We can use the NW or SE to send on-off signals, which is the form we want a system like this to accept-- in other words, the output is in the same language as the input.

If we want to do a left-side or right-side toggle, we can do that easy enough too, although I can't imagine a reason you'd want to do that.

EDIT: Remember the 6-count and the 25-count?  Sometimes it's nice to be able to think in different number sets.  Decimal is very intuitive to us; base-12 is nice for something like counting months.  But binary is efficient.  Each of these memory cells is essentially a resettable 2-count.  Put goblins in the south (0) position of, say, 7 of these memory cells.  Link one pressure plate in our main QA loop to toggle the first memory cell.  Link the SE pressure plate of each memory cell to toggle the next memory cell in line.  With just that, you have a binary incrementation system that counts from 0 to (2^7)-1 -- 127, higher than we were counting before, for less work (fewer hatches and doors).

Bauxite doors...

Lol, wouldn't want them to catch a chill.  Heated rooms for everyone!

Movie at http://mkv25.net/dfma/movie-2364-dostngospthechosenone

Update:

Remember how I said the goblin feed wasn't working properly?  I think I figured it out.

I mentioned that it needed manual reset once the goblin well ran dry-- the problem was that my manual reset wasn't sending a close signal to the door, so if one made it into the QA loop before the next triggered the reset, there were two invaders in QA.

I redesigned the reset.  I decided to do it a little bit weird.  It was the first thing that came to mind.  Well, okay, it was the first thing that came to mind that would have worked.  (First I was going all crazy on binary goblin memory cells, which btw are really cool and I didn't show you one at all, to keep track of whether an invader was in QA or not, and creature logic devices to turn a lever pull into a toggle.)



See that lever?  It used to be linked to the door now linked to by the pressure plate.  Now, it links to nothing.  It's just a doo-dad to get a dwarf to path through the one-way corridor pictured.  (It's one-way because the pressure plates are triggered by citizens, so the trigger the adjacent hatches, and dwarves always go through the lever hallway left to right-- although they have no reason to go there unless I give them a pull lever task.)

Now, the pressure plate links to the door opening up QA, so it sends an automatic close task that happens before another goblin can make it through (before a path exists from the queue).  Additionally, I made another hatch-pressure plate system before the reset switch, to prevent re-entering QA after triggering the reset.  Now, I have no problems.  I just route invaders through a couple of serrated disc traps (just after the reset switch) if they manage to escape QA, and I drop them all into the mass pit.

EDIT: Btw, try not to let any trolls into your QA pipeline.

And try to avoid cats.

{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.

Superquick one: will flooring over a natural pool be enough to keep it from freezing in winter?

No.

Niiiiiiiiiice!

New question: My current water trap works well, but about half of my goblinite goes through the hatch at the end and disappears. How do I remedy this?

No doubt there are engineering possibilities.  Using vertical or horizontal bars to block off the grate is probably a good idea, but I don't think it'd work; flow pushes objects through those kind of things currently, which is, again, probably not intended.

However, I bet your problem goes deeper than that.  There's currently a bug that does some weird hiding thing (sometimes?) to objects that are pushed by flow.  They're still visible in the stocks screen, and they can be zoomed to, but you can't see them when looking at the ground-- you'll zoom to what looks like an empty square.  Not sure if they can be dumped via stocks or not though-- if so, that'd be a decent workaround.

Otherwise, to do what you want, you're going to have to revise your drowning trap so there's no flow.  That, obviously, won't work.

But fluids don't flow at 1/7.  "But nobody ever drowns in 1/7!"  No, but they still burn in 1/7 magma.

So as a far-fetched workaround to existing bugs, you might consider a way to evenly distribute 1/7 magma on top of a bridge and then dump it on goblins.  You might have to dump it more than once.