Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Reelyanoob]

Here's a way which might avoid the problems

1. use my alternating nozzles idea.

2. squirt the magma directly into the pit, let it settle there.

3. close the bridge (which is below the nozzles).

4. dump the water onto the bridge where it settles.

5. open the bridge to dump the now evened-out water.

That way, the bridge & any pressure plate on the bridge-level will only ever be used for one type of liquid. It's just a matter of linking everything together with the timing now.

[Girlinhat]

Actually, if you use a modified method of my previously-mentioned swimming pool method, you could automate a 2/7 water drop followed by 2/7 magma.  A rough diagram is:

Code: [Select]

#~###
#~~~#
###X#
# # #
#
#####Poor drawing, I know, but that X is what matters.  This is a side-view, of course, so you can't see the depth.  The idea, is that your magma (~) is sitting in a cozy box.  The X represents one hatch above another.  In this case, the X needs to be 2 tiles deep.  Step 1: Open the upper hatch, allowing those 2 tiles to flood to 7/7 magma (14 units total).  Step 2: Close the upper hatch.  Step 3: Open the lower hatch, draining the 2 tiles into 7 tiles, filling it to 7x2/7 (still 14 units).  Step 4: Close the lower hatch.  Then repeat the whole process for water, dropping it down so that is spreads over the magma and casts obsidian, and repeat as needed.

The real issue, is that the water very likely won't act right.  Instead of spreading out, you'll have 7/7 hit one 2/7 and waste that water, giving you 2 tiles ob obsidian and leftover magma.  This can be changed if you pre-spread the water before dumping it, using another chamber that's already 7 long and lightly "sprinkles" the magma.

Of course, if you have infinite fluid (a river and a magma sea) you could use the tried and true method of layer flooding.  Dig out an empty area, and then on opposite walls dig a groove.  Fill the groove with floodgates, so that it makes two "towers" of floodgates set into the walls.  Open one floodgate and fill the entire layer with 7/7 magma.  Open the next floodgate 1 level higher, and flood with 7/7 water, casting the lower layer and flooding the upper.  Open the next gate higher and flood with magma, etc...  This is slightly harder to automate, though.

[SilentThunderStorm]

I have to agree.. thinking the swimming pool idea is probably the easiest and most trouble free way of handling it... then there aren't any pressure plates to muck with at all.

Now comes the timing issue... will have to sit and time in ticks how long it takes magma to spread out... or is that random somehow as well?

Thinking I am almost completed with the basic 'wiring' diagram of the timers... once I get the actual numbers down.

[Reelyanoob]

You'll need a bridge level to even out the second liquid you release, though the first liquid per level will spread out by itself.

The magma will have time to spread while your preparing the water to drop. Since magma spreads slighty slower than water this would be the main reason to drop the magma first.

I alternated the pipes of water/magma in my dispenser idea. Then, magma only has to spread out-sideways a couple of squares. it's dropped in strips.

[gtmattz]

I was assuming that since a pressure plate has a 100 tick delay before releasing, that any magma/water built up on it would have either drained away or evaporated before the bridges closed...

100 ticks is nowhere near enough time for anything to evaporate...

[peskyninja]

i demand screenshots

[SilentThunderStorm]

Lol!  First things first.

Need to finalize the design, then build it.

Screenshots, by necessity, must come last.

[Nil Eyeglazed]

Mechanical/fluid logic's not my forte, but I can answer a few of these-- too lazy to figure out if they've been answered already   if you're interested, I could show you exact creature logic diagrams, but I only know that the same principles are available with fluid or mechanical logic-- I don't know exactly what techniques to use with mechanical or fluid logic.

The first thing I would say is to get it working with a single level first.  I don't see why you'd need five z-levels.  Making it on a single level first will teach you how to make the five-level version.

Regarding pressure plates, they're possible.  Close a door blocking access to respective plates while the wrong fluid is being pumped.  Open a door to drain pressure plate while this is occurring.  Don't set it to 2/7; set it to 3/7, you'll have better luck.

1) I can see how to trigger the pressure plates once they are all covered with magma/water... simply attach each pressure plate to a gear, and attach the gears to each other sequentially.. apply power to one end, and the power will not come out the other until all of the pressure plates are simultaneously active.  This would work fine for pump control, as the pumps require power to activate...does it still work for bridges?  If not, how does one trigger a bridge with an AND gate?

AND outputting to a bridge is mediated through a memory cell-- through another pump.  You build one more of those pumps that only works when all pressure plates are simultaneously active and link it to a pump that moves water onto a single tile containing a triggers on>x pressure plate.  Link that pressure plate to the bridge.   If at any time your AND is true, your pump begins working, and moves water onto your pressure plate.  About 100 ticks later, your bridge opens.  Of course, you need to drain the memory cell afterwards to re-close the bridge.  If this idea of memory (tiles that either contain or don't contain water) is new to you, experiment with it until you understand everything it can do: I think it's really at the heart of good logic design.

2) I am looking up timing controls now to compensate for the 100 tick delay... this way, when the pressure plates empty off (due to the bridge dumping), I can time when to activate the other set of pumps, and accurately assume that the bridges have closed.  Or am I over-thinking, and there is some way of determining directly that the bridges have closed?

2-step repeater at http://df.magmawiki.com/index.php/User:MrFake/TwoStepAlternatingRepeater gives you a process to create a 200 tick delay.  Longer delays can be created easily, if that's what you need.  Power the repeater when you want the delay to begin; unpower it by feedback.

3) I am unsure how to switch power from one system (like magma) to the other (like water)... in other words, once the magma side has done its thing, and the 100 tick delay has expired, and the bridges have closed, how do I then trigger the water side rather than the magma?

Memory.  Learn it, use it, love it.  Separate machine components, activated or deactivated by the state of a memory cell.

4) How do I get the entire process to shut down when complete?  My initial thought is to have a separate pressure plate up top (probably on the side of the bridge pit, and centered between the towers).  This one (two actually, water and magma) would trigger if covered by (2/7 magma OR 2/7 water) AND bridges have been open for xx ticks.  This would require a separate timing mechanism, at least.

Isn't it complete after you drop the last batch of water?  I'm afraid I don't understand why this would be a difficulty.

Oh, you're envisioning it going nonstop.  No, once again, the way to do it is memory.  After each iteration, z_complete:=z_complete+1.  While z_complete<5, make obsidian.
The memory that I would use for this would actually be ring of ten pumps.  Water in one cell indicates z_level 0, pour magma; water in the next, z_level 0, pour water; water in the next, z_level 1, pour magma-- etc.  The final cell contains a pressure plate that stops the process (or more likely, each of the preceding cells contains a pressure plate that allows the process).

5) Last but not least... if I succeed at getting this entire system automated, and get a dwarf to throw the switch, then that switch will be in the same position when all is said and done... (ex. He turns it on, it is still 'ON' when process completes)... this might lead to issues with repeating the process.  Is there a way to trigger the switch to turn itself off (somehow, I strongly doubt this)?  Is there a way to have the system trigger whenever the switch is thrown, regardless of its actual position?  Would I simply have to have the dwarf thrown the switch twice in succession every time he started it ('OFF' then back to 'ON')??

If it starts via gear, one throw is enough.

It's not a problem, if it starts via a hatch or door: you just queue up two pull lever jobs.

If that bothers you, consider the following:

Code: [Select]

  ###
  ^l#
  ###
l is lever, not connected to anything; ^ is pressure plate, citizens trigger, linked to device; # is wall

The pressure plate always sends both an on and an off.  The only thing the lever does is get a dwarf to run across it.  That works even if the process is begun via bridge, floodgate, whatever.


Here's pseudocode involving memory:

Begin started by writing true to pump_magma memory
Pump magma from activation of pump_magma memory
Wait until adequate magma on peripheral pressure plate
Write false to pump_magma from peripheral magma plate; this stops magma pump in 100 ticks
Begin 200 tick delay from magma activation that outputs by writing to bridge_drop memory and new delay circuit:
Set bridge_drop = 1 (ie write true to bridge_drop from activation of magma plate; memory outputs to bridges)
Set bridge_drop = 0 (just drain bridge_drop memory, can have a pump activated by the presence of water in bridge_drop for this purpose, timing's not important)
Begin new 200 tick delay that outputs by writing to
Set pump_water = true from delay output, this activates water pumps
...just like for magma, even using same memory, except we're triggering changes with a different pressure plate...
Increment z_count (best way to do this is with a five-value memory cell; intermediary steps with alternating pumps is easiest way I know to build this)
Each of the first five (full) steps of z-count writes true to pump_magma
Last step of z-count incremented to 0 step of z_count by lever or pressure plate; this is how you wait for your miners and haulers.  (0-step writes true to pump_mamga, which begins process all over again.)

[SilentThunderStorm]

Regarding pressure plates, they're possible.  Close a door blocking access to respective plates while the wrong fluid is being pumped.  Open a door to drain pressure plate while this is occurring.  Don't set it to 2/7; set it to 3/7, you'll have better luck.

Perhaps... however, I am getting quickly convinced that I was wrong... pressure plates for this setup, at least in the manner that I was thinking of using them (to detect when water/magma had spread entirely across the bridge), are probably the wrong way to go... even with your workaround, there is a bit of micromanagement involved in simply keeping them from deconstructing on every cycle.

I have to agree with Reelyanoob that it is probably better to do the math first, and dump exactly enough for one spread... doing a small amount of work here before setup would eliminate a LOT of work after setup.

I will take your advice on 3/7, though... especially given that this would probably be best setup on aquifier/volcano setup, there is really no solid reason to be a conservationist, and it would probably eliminate a lot of false starts and empty pockets.

AND outputting to a bridge is mediated through a memory cell-- through another pump.  You build one more of those pumps that only works when all pressure plates are simultaneously active and link it to a pump that moves water onto a single tile containing a triggers on>x pressure plate.  Link that pressure plate to the bridge.   If at any time your AND is true, your pump begins working, and moves water onto your pressure plate.  About 100 ticks later, your bridge opens.  Of course, you need to drain the memory cell afterwards to re-close the bridge.  If this idea of memory (tiles that either contain or don't contain water) is new to you, experiment with it until you understand everything it can do: I think it's really at the heart of good logic design.

The concept is not entirely new, but also not entirely familiar.  I had never thought of using the presence of water as a boolean before.  I had (imagine this) been treating it like a float.  Rather than [water] and [no_water], I had been thinking in terms of how full the square was [0...7]... but it is looking about as reliable as trying to compare floats in programming... random evaporation, and unstable flow characteristics.

It would probably be better to simply have one of your memory cells... but to leave the water in it until I was ready for the bridge to close (or, if I can work it into the timing schematic, 100 ticks BEFORE I am ready to trigger the bridges again).  I really do wish, however, that there was a good method of triggering without a 100 tick delay OR an off signal at all.  I would far prefer having to use two pressure plates (one to close, the other to open) than having an automatic 100 tick toggle switch.  At least with two separate plates, I could time it far more accurately and simply.

2-step repeater at http://df.magmawiki.com/index.php/User:MrFake/TwoStepAlternatingRepeater gives you a process to create a 200 tick delay.  Longer delays can be created easily, if that's what you need.  Power the repeater when you want the delay to begin; unpower it by feedback.

Wonderful... that is exactly the type of thing that I was looking for.

Even better, this would solve the problem I have had regarding switching from the water side to the magma side...

However, given that I have multiple steps, I may actually build an n-step repeater instead... realistically, I could chain them together like a nested loop... thus:

While (System is active)
{
    while (currentFluid is active)
    {
          Close Bridges
          Open Floodgates
          Programmed Delay
          Close Floodgates
          Open Bridges
     }

     currentFluid != currentFluid; // assuming boolean (water/magma)
}

Again... one of the issues that I am seeing repeatedly is the 100 tick 'OFF' signal that the pressure plates create.

In a basic setup where you want something triggered on and off repeatedly, this would not be an issue... but it would be nice to simply have a single 'ON' signal for a setup like this; where the timing depend on which fluid is active, and there are multiple steps in a continuing sequence... in such a case, stray 'OFF' signals are a nuisance.

I am thinking, if I am using two separate loops for water and magma, due to the timing being different between the fluids, then I could simply have chambers that flood to time rather than passing around a single block of water.... this way, the pressure plate would not de-trigger at all (as they are still covered) until their cycle is completed, and the water is evacuated from them (although it might be easier to simply dump it to a temporary chamber which is continuously being evacuated.... that would probably make for more agile timing). By that time, I would have that side detached from the mechanism (through a gear), so the 100 tick signal would fall on deaf ears.

This leads to a question, then...

Does anyone have any idea how many ticks it takes a pump to fill a single 7/7 tile?  I am thinking of timing like this:


%>     %>     %>
XX   __XX   __XX
XX   XXXX   XXXX
XXXXXXXXX   XXXX
XXXXXXXXXXXXXXXX




In such a case, the yellow would fill the pool beneath it, which, when full would trigger the red.  Red has a deeper pool to fill, and would take longer, then finally trigger the blue.


The above is only for illustration... I understand doing it exactly as above would lead to issues (such the red plate repeatedly triggering/untriggering as blue pulled water off of the plate).... those issues are handleable, and were drawn as above only for simplicity of typing.

• Rather... how many ticks does water take to fill a tile like that?
  
  A related by slightly separate question would be: How long would it take to dump a tile?  Assuming gravity dropping water directly through an open hatch, how would one compute the ticks required to drain a room? 
  
  How about flow time?  For example, water continuously pumped down a 1 tile channel would travel how fast?  How do flow characteristics change on an open floor?

Has anyone already done that work?  If so, is there a link?


Many of the designs hat I have seen seem to imply that water is immediately transferred in 7/7 chunks from one side of the pump to the other.  In such a case, the above design would be an extremely rapid timer.


This would be quite usable, however, if you chained small sets of timers together, you could, in effect, time any number of ticks you wished.  Timer 1 takes 10 ticks, for example, then dumps its water (for sake of illustration, here, assume instant drainage... real numbers may vary), triggers timer 2, and starts again... timer 2 also takes 10 ticks, but since it is only triggered once every 10 ticks, it finally triggers on tick 100.  You could, in effect, build a dwarven clock, so you could tell the number of ticks that had elapsed in a season, for example...


for (i = 0; i < 10; i++) // pump 1
{
     for (n = 0; n <10; n++) //pump 2
     {
     }
}

Memory.  Learn it, use it, love it.  Separate machine components, activated or deactivated by the state of a memory cell.

OK.  Will do... That makes a lot of sense.

No, once again, the way to do it is memory.  After each iteration, z_complete:=z_complete+1.  While z_complete<5, make obsidian.
The memory that I would use for this would actually be ring of ten pumps.  Water in one cell indicates z_level 0, pour magma; water in the next, z_level 0, pour water; water in the next, z_level 1, pour magma-- etc.  The final cell contains a pressure plate that stops the process (or more likely, each of the preceding cells contains a pressure plate that allows the process).

Gotcha.  I can see that working.

Thinking about nested cycles, however...

while (cycleComplete  < 5)
{
   activate water side

   water:
   {
       deactivate magma side
       close brides
       open floodgates
       wait waterDelay ticks
       close floodgates
       open bridges
       activate magma side
    }
    magma:
    {
        deactivate water side
        close bridges
        open floodgates
        wait magmaDelay ticks
        close floodgates
        open bridges
        mark cycleComplete + 1
    }
}


I was afraid that I would have to create a separate complete set of mechanisms for each cycle, and have the system continuously go through them, stopping at the end.

Your method is much simpler... I, honestly, hadn't thought of mechanics in the same way that I think of programming... much is the pity.  Functionally, I could simply have the system fill one cell with water on the completion of each cycle, then, using the AND gate from earlier, have it kill the process, and empty the 'buckets' after they are all filled.

If it starts via gear, one throw is enough.

Yeah, I had been realizing that using a lever to initialize the process was using the wrong tool for the job.  I had been thinking of using a plate, but you are correct... a gear would be far easier, as I wouldn't have to deal with yet ANOTHER 100 tick delay.

The pressure plate always sends both an on and an off.  The only thing the lever does is get a dwarf to run across it.  That works even if the process is begun via bridge, floodgate, whatever.

That, however, is really my problem with it... starting the system, then 100 ticks later, getting a second signal could throw a bit of a wrench into it.  A gear seems a far easier solution to the issue.

Or better, using separate loops for water and magma, you simply detach the pressure plate from the rest of the works before it sends its off.  Then you don't have to screw with it at all.

Here's pseudocode involving memory:

Begin started by writing true to pump_magma memory
Pump magma from activation of pump_magma memory
Wait until adequate magma on peripheral pressure plate
Write false to pump_magma from peripheral magma plate; this stops magma pump in 100 ticks
Begin 200 tick delay from magma activation that outputs by writing to bridge_drop memory and new delay circuit:
Set bridge_drop = 1 (ie write true to bridge_drop from activation of magma plate; memory outputs to bridges)
Set bridge_drop = 0 (just drain bridge_drop memory, can have a pump activated by the presence of water in bridge_drop for this purpose, timing's not important)
Begin new 200 tick delay that outputs by writing to
Set pump_water = true from delay output, this activates water pumps
...just like for magma, even using same memory, except we're triggering changes with a different pressure plate...
Increment z_count (best way to do this is with a five-value memory cell; intermediary steps with alternating pumps is easiest way I know to build this)
Each of the first five (full) steps of z-count writes true to pump_magma
Last step of z-count incremented to 0 step of z_count by lever or pressure plate; this is how you wait for your miners and haulers.  (0-step writes true to pump_mamga, which begins process all over again.)

Again... I am ashamed.

I had been thinking of mechanics the way I think of working on my car.

It is far more elegant to think of mechanics the way I think of programming an application.  Had that been my approach walking in, I do not believe many of these questions would have been asked. 

I think getting a basic schematic done will be my goal of the day.

[Nil Eyeglazed]

Paradigm shift's always cool

I will take your advice on 3/7, though... especially given that this would probably be best setup on aquifier/volcano setup, there is really no solid reason to be a conservationist, and it would probably eliminate a lot of false starts and empty pockets.

I mentioned 3/7 because not being sure about evaporation would leave 1/7 on plates.  Dunno if it's necessary for measured flow.

However, given that I have multiple steps, I may actually build an n-step repeater instead... realistically, I could chain them together like a nested loop... thus:

Exactly-- I think you can see that the 2-step repeater is also boolean memory; that a n-step repeater is base n memory.

Again... one of the issues that I am seeing repeatedly is the 100 tick 'OFF' signal that the pressure plates create.

Signal management can be a total bitch, it's true.  But it's doable.  I don't know if there some kind of super, instant, gear-based memory or not-- hell, I guess just a gear is gear based memory.  But imagine you're using a design similar to the 2-step repeater for boolean memory.  How do you set it to false?  Activate pump-from-true screwpump (via gear/power).  How do you set it true? Activate pump-from-false.

Except the pumping happens almost instantaneously-- in fact, to limit the refractory period, you need to follow the activation with deactivation.  So to set to true, activate then deactivate pump-from-false.  That's exactly what somebody running over a pressure plate does.

Meanwhile, what kind of signal does this memory send?  It sends a single open at the time it's made true, and a close 100 ticks after it is no longer true.  Mostly, it turns every 2 open-closes it receives into 1 open-close, sent at divided, controlled times.

The question then might be, how do I get this kind of memory to send an on-off to write to memory directly?  I suppose you could always make a flow.  Don't know the best way.  But I think you can see how signal management is both a headache, and vital to functioning logic.

In a basic setup where you want something triggered on and off repeatedly, this would not be an issue... but it would be nice to simply have a single 'ON' signal for a setup like this; where the timing depend on which fluid is active, and there are multiple steps in a continuing sequence... in such a case, stray 'OFF' signals are a nuisance.

Lol, yeah, that's the advantage of mechanical logic, that's the problem with mechanical logic.  I use redundant signalling in creature circuits pretty regularly (like to send a close, i send an open-close to a device that I know is already open.)

Does anyone have any idea how many ticks it takes a pump to fill a single 7/7 tile?  I am thinking of timing like this:

It happens (almost?) instantly.  Your repeater would work, but would go extremely fast.  Water falls and flows at a random rate, meaning that it would not be a perfectly predictable delay, but would fall into a certain range.

That, however, is really my problem with it... starting the system, then 100 ticks later, getting a second signal could throw a bit of a wrench into it.  A gear seems a far easier solution to the issue.

Unless you want to start by, say, writing to water pump memory, in which case you want an on-off.  Signal management.  Sometimes you want an on, sometimes you want an on-off.

If you don't like the bridge delay, you could always use hatch covers instead.

There are probably ways to manage memory using pure mechanics; it sounds like you would much prefer instantaneous memory, with one signal = one change of state, with no differentiating between kinds of signals.  I'm sure everything is possible that way, although I don't know how it works.  Mechanical logic will always have to output to pumps and fluids, but it can do weird stuff internally.  Consider your magma pump gear: that gear is actually memory.  It stores whether or not you are pumping magma.

[SilentThunderStorm]

Hatch covers would still involve the exact same delay.

From what I am seeing, it isn't the bridge causing the delay, its the switch...

When  the water hits the pressure plate, it signals on.  Whenever the water rolls off, the plate sits there completely dry for another 100 ticks before sending the OFF...

The fact that a bridge delays another 100 ticks makes this a 200 tick delay... and THAT is simply unacceptable for a device that is supposed to run automatically (at least in my impatient mind).

Although, to be honest, I am really thinking of these functioning more like function calls...  One doesn't tell a function to start, then tell it to stop... you tell the function 'do this' and it does it.  I guess I am too used to OOP.

This would be FAR easier to implement if I could simply hook a bridge to a gear. A gear is EXACTLY the type of thing I am looking for... this pressure plate twin signals thing is driving me bonkers.  If I could do that, I could simply connect the bridge to the pressure plate with a gear between them.  Then, when it head triggered ON, I could just disconnect the freaking gear and ignore the OFF signal completely.

It should probably be recommended to Toady that allowing such direct connections would not only make sense... but would also allow even novices (like myself) far more direct access to dwarven !!SCIENCE!!... but I have a feeling that it is running exactly as the all-seeing one envisions.

Still working on it... thinking I might have to pre-trigger several events in order to make this thing happen fluidly... still working on specs.

[Reelyanoob]

Bridges Grates and floodgates definitely have a slower opening reaction time to hatches and doors! Known fact.

e.g a hatch pressure combo (HP) stops all passers because it opens instantly. They can walk over a grate before it opens if used insteads of a hatch.

[SilentThunderStorm]

Right... was doing research as I was typing... bad habit of mine.

It causes me to start saying one thing, and finish saying another.

The 100 tick delay that I HAD been looking at was from the pressure plate itself.  Upon being released, it delays 100 ticks, then sends the OFF signal.

In addition to this is the 100 tick delay on the bridge...  This means that closing the bridge via an 'OFF' signal from a pressure plate would be a 200 tick wait; whereas the hatch would only be a 100 tick wait.

I would like to eliminate these various delays (wish me luck).

I am thinking that, since the delays are known in advance, I might be able to time the releases such that I clear the pressure plate 200 ticks before I want the bridge to close... so the bridge closes right on time.

That will take a bit of real planning; so I am currently running flow analyses on water and magma to see how predictable the speeds are.  Someone stated that they are random... looking at the results I am getting, it doesn't look quite random to me... rather, it seems that there is a pattern to it.

Haven't actually gotten to the tick by tick analyses, yet.. rather watching it flow, and watching as the numbers run across the top... it appears that the flow is set to be circular (well, a dwarf circle... a human square) running counter clockwise.  Not sure how useful this will be, yet... but that's !!SCIENCE!! for you.

Hopefully, there will be a specific spread ( like between 150 and 200 ticks )... in that case, I can simply time for the longer side to guarantee coverage.  If the results end up really random (like rain, or, apparently, evaporation), I would have to give that idea up, and just go with 'close enough'.

[Reelyanoob]

If you have fully pressurized 7/7 water and magma, it's pretty non-random. Because there's only 1 way it can flow.

When you have variation in levels, e.g. spreading out non-pressurized, that's when random rolling takes over.

EDIT: you should be able to design your system so you never have to wait for evaporation. That takes literal game-weeks or months.