Topic: taptap's dwarfputing experiments (Read 16072 times)

taptap · « **on:** November 21, 2014, 05:12:51 am »

A few little applications / elements I thought up for use in combination with drainage-free fluid logic (thanks Larix). I was contemplating combinations of delayed and fast elements, sadly there is no anti-door in fluid logic and additional uses for the water-smashing going on in this kind of logic. (All three are tested, but never really deployed in large scale.)

B's are raising bridges, numbers water levels the rest are the ASCII codes in game.

Code: [Select]

≈+B^X
^ operates on high water. Input goes to all elements. This is (fast) A AND (delayed) !A. The result is a, say, virtual pressure plate, jam-free with a reliable off-signal, it needs the off-signal from input to reset. Could be of some limited use, when action is triggered by enemy pathing where a reliable off signal is important.

Code: [Select]

≈+7^+
^ operates on low water. Input goes to the second door. This is a basic water-smashing counter, the second door smashs water each on-off cycle, when low enough the pressure plate triggers whatever it should trigger and opens the door to refill.

Should be easily expandable (smashing door one z-level below to have a more controllable water removal), if you want a visitor counter for the local zoo and celebrate the 1000th visitor with a special event. This looks pretty powerful to me and may be utilized for all kinds of applications, say as a switch for a repeater (6 tiles water and a pressure plate working on 5- above, smash 7 units of water below). I can hopefully solve my eternal problem of using a single lever pull to start a repeating trap that keeps repeating and stops on a second lever pull with comparable ease this way.

Code: [Select]

≈+^+
  ^XX

^ operating on falling water levels, one to trigger at 5-, the second to trigger at 3-. Input goes to door and 2 floodgates. Expanding on both ideas a simple signal duplicator using the delay between door and floodgates to generate two signals, the (second) pressure plate simultaneously resets the whole thing by opening the front door.

taptap · « **Reply #1 on:** November 23, 2014, 04:39:59 pm »

Code: [Select]

≈+____^^   :side view
  +

This is a combination of elements already mentioned in the first post, a liquid crushing door in the z-level below tied to a (full cycle = on/off) input signal used as toggle for a wave repeater. Seen in the side view. The first ^ opens the front door at water height 4-0, the second ^ works on exactly 5 and is the output. The first full cycle input crushes 7 units of water leaving 35 units water in six tiles, leaving a 566666 wave repeater. A second input signal stops the wave repeater very rapidly, open the front door and resets the whole thing.

This is a very compact solution to my (former) problem of setting up a spike trap, that can be toggled easily. This is already quite useful, but it gets even better.

Now ...

Code: [Select]

≈+____^^   :side view
  ++

this is basically the same, but with a second, independent input, which is very easy to set up.

The required full cycle signals can be made pressure plates - or when dwarven triggered in the timeless "empty-lever-with-adjacent-pressure-plate" design.

Larix · « **Reply #2 on:** November 25, 2014, 08:07:34 pm »

Quote from: taptap on November 21, 2014, 05:12:51 am

Code: [Select]
≈+7^+
^ operates on low water. Input goes to the second door. This is a basic water-smashing counter, the second door smashs water each on-off cycle, when low enough the pressure plate triggers whatever it should trigger and opens the door to refill.

Ooh, neat idea! Especially the idea to expand the contraption and use a lower-level smashing door for "longer" counts. Breaking the mould and going beyond pure binary is something i find especially intriguing in DF logic.

Nice constructions all around!

Edit: i also like this one:

Quote

B's are raising bridges, numbers water levels the rest are the ASCII codes in game.

Code: [Select]

≈+B^X

^ operates on high water. Input goes to all elements. This is (fast) A AND (delayed) !A. The result is a, say, virtual pressure plate, jam-free with a reliable off-signal, it needs the off-signal from input to reset.

A neat approach - using the different timing periods and actions of different buildings to turn a state change into a limited-time signal; i think that's what's commonly called an "edge detector" - something that takes a single one-type signal and turns it into an on/off signal cycle. It's e.g. quite useful when your input is something that can be activated for a long time (a lever, or a pressure plate under water) but you only want to turn it into a one-shot reaction, not constant activity.

My approach to these things is to regulate part of the furniture in such a cell by the "output" pressure plate itself, which makes the construction quite a bit more complicated and intransparent, but can do the job with fewer furniture and mechanisms.

taptap · « **Reply #3 on:** November 28, 2014, 08:31:11 am »

Thank you, Larix. Very much appreciated. The designs were made mainly while experimenting with different delays and water smashing, not strictly with applications in mind. Now thinking of the effect, the s/r-latch layout on the wiki with pressure plate linked to the front door, is probably what you do.

Code: [Select]

≈+^+ :^ low water, linked to front door and other output

I didn't dare calling the "virtual pressure plate" an edge detector, because it kind of only detects one edge (and there is no fast "anti-door" for a complementary device). Something like the following is probably a proper advanced fluid logic edge detector (requiring a ton of mechanisms though).

Code: [Select]

≈X^^B or ≈B^^X :^ are complementary working on 0-5 and 6-7 respectively

It produces both an on and an off signal during each state change. The way delays are involved made me wonder whether it would be possible with complementary pressure plates and a little distance to make "fast switches" (for say opening doors very shortly) say turning a pressure plate to off and during the delay trigger another pressure plate on, which is then followed shortly after by the off from the first pressure plate.

Larix · « **Reply #4 on:** November 28, 2014, 10:09:24 pm »

"Edge detector" with two doors - yep, you nailed it. Have you been reading my secret notes?

Slow "falling" edge detection - yeah, to detect an input switching off, you either need to wait until a bridge decides to react (inconveniently long wait) or muck around with hatches and infinite drains, and i must say the only type of infinite drain i don't find infinitely annoying are aquifers, which aren't available everywhere and come with their own complications.

That "double-action" state change detector with two plates is really clever, i never thought of that. The fun thing is that it should absolutely work if you link both plates to a single door or hatch - buildings always conform to the _last_ valid signal they received, and this way, you always get an "on/open" instantly after the input-governed buildings switch, and an "off/close" 99 steps later. Since it requires bridges/floodgates to work, it has a bit of a reaction delay, but that can't really be helped.

There may be some ways beyond the usual to build timers based on fluid: a single pump _should_ move only a limited amount of water per time unit, so it might be possible to, say, have a pump push water down a channel of a specific length and get a precise or at least reasonably regular delay between pump start and a plate at the end of the channel responding. I've never seriously played with such concepts, my primary logic area is minecarts; my fluid logic explorations are much less ambitious.

taptap · « **Reply #5 on:** December 01, 2014, 07:08:03 pm »

The main advantage of this advanced fluid logic is pretty much not requiring a drain and not requiring power, for the sake of FPS and everything. I built my lab as a multi-level "water battery" hanging below an aquifer, it is drainable to edge or by bridge for maintenance, but I don't plan to do this regularly. It is compact enough to build utilities for a running fortress with it, i.e. messing with drainage requiring elements even for added functionality is pretty much out of limits. Drainage was the reason I stayed away from fluid logic before, after all.

How would you, Larix or if anyone else reading this is up for a challenge, build a regular short delay, for say exposing a live-target for targetting but blocking the flight of the arrow, in minecart logic? (Nil had a design with bridge and floodgate and one of the signals slowed by a creature fall delay, which all sounds kind of neat but more proof of concept than ready for application.) Or in the reverse with increased utility, opening a door for marksdwarves to shoot, but closing fast enough to block incoming arrows.

Some updates:
The slow, "double-action" edge detector works in practice, as it should.

Experimenting with different wave repeater designs for spike traps, using two output plates. For spike traps working on water height of 7 - thus 8 tiles - seemed better as it leaves retracted spikes = on as base position when fully filled. Cross-patterns seem to toggle faster than linear ones of same length, the last design appears to work best about as fast or slightly faster than the 6-tile, double output one. Though cross-patterns reset far slower than simple linear ones. Ultimately all of this doesn't matter much with locked-in opponents. The experiments with different types of wave repeaters really brought home the message how irregular water movement in small channels is.

Code: [Select]

simplified top-view, only top-level and output pressure plates shown

≈+^____^      : 6-tile double-output (output working on 5)

≈+^______^    : 8-tile double-output (output working on 7)

  _ _ ^
≈+ _ _        : 8-tile, cross-pattern, adjacent outputs
  _ _ ^

  _ _ ^
≈+ _ _        : 8-tile, cross-pattern, output on opposing sides 
  ^ _ _

While working on an automatic obsidian factory, I built a reactor that reliably toggles on a lever pull by putting a hatch in the pump output. When toggling on, the water above the hatch is enough to start the water wheel just by its flow, when toggling off, the pump continues long enough to refill the area above the hatch with 7 water. It isn't as compact as the one in the wiki, but still I find it convenient to have a reactor that is easy to restart mechanically by lever. I was hoping to get more water-to-power elements, say by wave repeater under water wheel, but this didn't really work out.

Larix · « **Reply #6 on:** December 01, 2014, 09:31:59 pm »

Simple powered minecart circuit which opens a door or hatch cover for a short time:

Path above, installations below.

The two rollers push to the "outside" and are switched in oppositve phase, i.e. whenever the input toggles (working with a lever), the cart switches from the short loop to the right to the one to the left and vice versa. Between lever flips, the cart stays in its loop and holds the pressure plate active.

When the cart switches from one side to the other, it no longer holds down the pressure plate and thus queues up a "close" signal, due 99 steps after it last touched the plate. The path between the two halves is just long enough that the cart reaches the plate in the _other_ loop - activating it - _just_ before the "off" signal fires.

Thus:
-lever flip
-cart leaves its current loop, "off" signal is queued up
-cart travels to the other side
-O:cart touches plate on the other side, hatch opens (i'm using a hatch)
-C:a few steps later, the 99 steps are up, the vacated pressure plate resets, sends its "off" signal and shuts the hatch again
-cart is stable in the new loop, holding the plate activated, door remains shut (because the "open" signal has already been sent and processed at O.)

In the screenshotted design, i work with medium-speed rollers and the hatch is open for three steps when the cart goes from west to east, six steps when going from east to west (asymmetric layout). For practical uses, longer "open" times might be desired, but you can get practically any period by fiddling with path length and roller speed. The long path makes it less than optimal in power consumption, but i didn't care too much since i have a sufficient 40-per-mill windpower on the embark anyway.

It's also possible with unpowered carts, but that'd be a bit harder to achieve and calibrate.

PS: and kudos on the exploration of wave repeaters - their behaviour depends on the mechanics of non-pressurised liquid flow, which is still rather mysterious on larger scales. You're doing proper science there.

taptap · « **Reply #7 on:** February 04, 2015, 01:04:18 pm »

I made an overcomplicated / unnecessary detector as part of my obsidian factory. (Never imagined pressure plates could work submerged in obsidian.)

1) the detector

Code: [Select]

≈+^
  +     : side view, fluid detector without fluid retention

2) the rising edge detector (used as inverter)

Code: [Select]

≈+^+    : ^ low water, linked to front door and detector front door

My first time I do something in magma, so I wanted the detector to reset with complete removal of fluid. The pressure plate hangs in midair and was constructed on top of a later removed wall. The output of 1) goes into the backdoor of 2) producing an ON/OFF signal. The ON part of that signal is ignored (the detector is open when it detects something), the OFF signal closes the detector. Later a sufficiently delayed full signal (ON/OFF) removes all liquid out of the detector and resets 2) into its initial state by closing the backdoor.

I love how many different things you can achieve with basically the same +^+ design.

taptap · « **Reply #8 on:** February 05, 2015, 07:58:39 am »

Musings:

A door already is a "D-Latch" (Premise: input ON/OFF signal - output OPEN/CLOSED state.), or say it can function as its own memory cell, just like a gear assembly. What comes after the initial door is a reading device to produce a signal from the door state. (Probably more obvious in Larix' shiny new cart+door logic.) In the standard fluid logic memory cell (≈++^) the reading device is limited to reading out the state once after a change (and only after a change). Arranged vertically (with infinite drain) there would be a repeatable full cycle output signal for each full cycle read signal, if data (door is open) and no signal without data. (We tend to use OFF signals as 0, but using ON/OFF as 1 and no signal as 0 should be possible as well.) It could also (by using exploits to place doors and floating pressure plates) be arranged space efficient since free fall would not require all the walls to contain it.

If a reading device is designed like the fluid detector in the previous post with the output pressure plate linked to a rising edge detector that operates a drainage door (once read door is closed). It should w/ proper delays output ON/OFF signals when there is data and no signal when there is none - in a repeatable way not requiring state changes in the D-Latch (the data door). Of course this is far more complicated than the theoretical vertical, infinite drain solution.

1) data door + repeatable reading device

Code: [Select]

≈++^
   +    : side view

Larix · « **Reply #9 on:** February 05, 2015, 03:10:18 pm »

No, memory generally "holds" a bit of information while the input can change. A door always follows its input, i.e. is in the state dictated by the last signal it received.

A door taking input from the plate in a standard memory cell will mirror the state of that cell and so - using it as "data" entry of another D-Latch - can be used to "read" that cell indirectly. But if you want to "memorise" a temporary signal (e.g. a goblin passing through an area - pressure plate resets when the goblin isn't stuck on it), you have to feed it through one of the basic memory cells first. It's different if your input comes from levers and is guaranteed to be in the desired state.

Mind, this is primarily an issue when you want to play around with actual dwarven computers; of course, i think you already have most of the basic building blocks for one worked out. Sticking them all together and making the whole thing tick is quite a bit of a project, though.

wierd · « **Reply #10 on:** February 05, 2015, 04:47:50 pm »

(chuckle)

I remember when you were at this point Larix, after spending months making really tight, single purpose detectors, logic gates, and memory cells. I remember telling you that all you needed to do to make a computer was combine the parts you had already made, and use a simplistic instruction set.

It would make me laugh (in a good way) for multiple people to all create thier own logic systems, assemble them into thier own personal designs for dwarfputing, then evaluate their work against the work already done by others.

The most logical outcome of that, is for the best parts from each designer, and the best cognitatived models of reduced instruction computing to come together to create a community designed dwarfputer.

I would be happy to see such a thing.

Go on Tap-Tap, take the plunge!

taptap · « **Reply #11 on:** February 05, 2015, 05:53:42 pm »

Quote from: wierd on February 05, 2015, 04:47:50 pm

Go on Tap-Tap, take the plunge!

Apropos plunge: I just realised a few minutes ago that accidentally assigning a raised bridge for removal, even with instant stopping without anything done, changes the status of a raised bridge. I also realised in that moment, that doors, contrary to popular belief, are not waterproof. My control room (with access to drainage and aquifer plug) survived, but I do have several rooms behind lead doors completely flooded.

Sadrice · « **Reply #12 on:** February 06, 2015, 06:48:27 am »

However, the bridge thing provides an excellent instantaneous player controlled switch. Link your front gate to a pressure plate triggered by depth with a raised bridge between it and a water source. Order the bridge removed to close the gate instantly, with no delay from a lever puller.

taptap · « **Reply #13 on:** February 09, 2015, 05:01:06 am »

I have trouble to understand Larix machines, yet alone doing something similar. He deserves adamantine minecarts and mechanisms as token of appreciation by every fort.

Bridge deconstruction bug: Interestingly it doesn't happen with my bridges in magma, the bridges in my water battery (10x1 raised copper bridge) does start to leak when I assign for deconstruction and stop deconstruction. In some respects, however, it remains raised, e.g. changes (water-stompingly) to non-raised with lever-pull or is not passable by dwarves.

Upscaled water reactor: Not exactly dwarfputing, but it differs from the common design by not requiring priming. Thus it is off by default (fps-friendly) and can be activated by a lever pull, i.e. it transforms "potential" water energy into power, which starts the pump and keeps it going. The upscaled version promises to be even more space efficient than common designs. The limiting factor for further upscaling will be the amount of water a single pump can pump into the reservoir in the interval while waterwheels / pump still work despite the reservoir being closed.

Spoiler (click to show/hide)

Later: Small scale single wheel reactor works fine under this paradigm, upscaled reactor did so during test, but does not in the long run (water losses, one pump not sufficient).

taptap · « **Reply #14 on:** February 12, 2015, 05:12:16 pm »

Quote from: Larix on December 01, 2014, 09:31:59 pm

Simple powered minecart circuit which opens a door or hatch cover for a short time.

I combined this, linked to 3 doors, with a slow repeater and put the crossbow squad to train in the range. Worked very well, but the whole setup singlehandedly brought FPS from high 50's to 20's. Can't see me doing much powered logic, if this goes on with reactor, power transmission, a delay linked to three doors and a repeater. (Or I have to cheat with the power plant and build wheels into the aquifer in future.)

News:

Author Topic: taptap's dwarfputing experiments (Read 16072 times)

taptap

taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments

Larix

Re: taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments

Larix

Re: taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments

Larix

Re: taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments

Larix

Re: taptap's dwarfputing experiments

wierd

Re: taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments

Sadrice

Re: taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments

taptap

Re: taptap's dwarfputing experiments