Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2] 3

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

Larix

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #15 on: February 12, 2015, 05:42:29 pm »

Oh right, doors mechanically operated at high frequency = fun times. Opening/closing doors, bridges and the like eat FPS like crazy. It was the only significant FPS load of my dwarven computer, and having lots of doors doing things brought FPS down from the mid-40s to less than 10, sometimes as low as 4-5 (although that was stuff like 50 doors opening/closing all at once).

Power production and switching of gears don't seem to be very FPS-intensive.
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #16 on: June 08, 2015, 10:42:22 am »

I changed all reactors after the model widely distributed in the wiki etc. with two significant changes. 1) Instead of a hatch cover over the intake I put a door below, this does stop a reactor just fine*. 2) I added a water input in the upper level of the reactor so I can fill it completely, apart from the tile taken by the door, i.e. 63 units of water in a 2 wheel reactor, 35 units in a single-wheel reactor. Now the main point of this whole design: opening the door starts the reactor (unless overall load is too high). So the reactor can be started and closed by a single lever. So this is a signal-to-power converter without using any permanently working power sources, sth. I wanted in a reliable, loss-free setup for a long time (I had earlier setups working on low water below the wheel and a water reservoir opening for initial power, as this worked with less water it was not loss-free).

The result appears to be free of loss with the intake dry, but muddying up, all other tiles are filled 7/7 with water. Overall very satisfying results. When linking together six 2-wheel reactors, I have sometimes power losses from 1200 to 1100 and rarely 1000, without any visual clue (constant standing wave without visibly moving water) on the map, why this occurs. *When shutting the whole reactor down, I had phantom production of 200 power remain in one wing - despite all intakes being blocked by doors. I can then only shut the reactor down by increasing load. I don't think this behaviour wholly adds up with the descriptions I read in the forums and wiki.

Spoiler (click to show/hide)
« Last Edit: June 08, 2015, 10:59:06 am by taptap »
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #17 on: June 15, 2015, 09:40:08 am »

I built this Larix-inspired device for the new obsidian factory. Unfortunately despite a reasonably fast edge detector (advanced fluid logic one), this configuration doesn't work yet / the working one doesn't look so neat anymore, since the carts emerge faster (around 30k at start) than I thought they do (about push velocity). It will do after some refitting. (Don't ask me how I manage to stretch obsidian making into seven stages.)



Edit: The new setup works. It has this counter with a few more corners added, "4 bits of memory" (S/R latches for power/water/magma/bridge state) + an edge detector. So now I can pull one lever 7 times instead of pulling a handful of different levers. Quite pointless, but a great step for the dwarves of Subtlehammers nonetheless. Sadly, my main engineer - architect of this triumph - drowned shortly before finishing in an accident, while trying to understand these weird unstoppable water reactors.
« Last Edit: June 15, 2015, 03:58:22 pm by taptap »
Logged

ImagoDeo

  • Bay Watcher
  • [NOT_THINK:UNTHINKABLE]
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #18 on: June 17, 2015, 03:18:24 pm »

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.

I used the bridge deconstruction bug in a successful 34.11 fort to have a functional lava landmine system that I shamelessly stole from someone or other. I can think of some improvements to the design that I eventually settled on, though - a spout aboveground would be more invulnerable to building destroyers with the right grate setup.

Anyhow, my experience using deconstruction bugging indicated that it works just fine with bridges in magma. It doesn't permit vertical liquid leakage with a lowered bridge, so far as I know, but it does permit horizontal leakage with a raised one.

I feel like the instant response time could somehow afford all of you brilliant minds with some time savings in terms of calculations in the dwarfputers you build, but maybe I'm wrong.
Logged
What would it be like to live in a world that was copy/pasted? Would we even notice? If not, how many times have we switched celestial harddrives or whatever?

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #19 on: June 17, 2015, 06:27:23 pm »

Anyhow, my experience using deconstruction bugging indicated that it works just fine with bridges in magma. It doesn't permit vertical liquid leakage with a lowered bridge, so far as I know, but it does permit horizontal leakage with a raised one.

I feel like the instant response time could somehow afford all of you brilliant minds with some time savings in terms of calculations in the dwarfputers you build, but maybe I'm wrong.

Thanks for bridge details, I haven't explored it further. My default in-game-signal, that can be given by the overseer used to be goblin-based (unforbidding a door), but I haven't seen many goblins in the new version. This is one of the few goblin logic things that should still work. I don't have many emergencies tinkering around in almost lockdown with 50 overtrained dwarves admittedly.

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #20 on: June 28, 2015, 06:30:06 am »

Ugh, I reinvented something (fluid logic repeater*), that was on the forum since 2009.

It is one of several cases of how the same furniture can achieve completely different things depending on wiring. Which I find fascinating, but it gives you a headache when inspecting your old installations.

Code: [Select]
≈+^+    :^ low water (s/r latch or edge detector)
Code: [Select]
≈+B^X   :^ high water (repeater* or edge detector)

Both can be used as edge detectors with proper wiring. Sadly, the second one is too slow for my needs (ON-OFF interval 200 ticks+), the first one is occasionally one tick too fast for slow furniture. (See: http://www.bay12forums.com/smf/index.php?topic=140163.msg6333326#msg6333326 and following posts for details) I now made a simple powerless minecart edge detector. (Drop into straight ramp pit, go over plate linked both to hatch and output, drive around until hatch closes again, stop on hatch.) It achieves the aim to have a stable just over 100 tick interval between ON and OFF signals for the bridge in the ring counter, the whole interval until reaching the starting position again is 140ish (this could be optimised further, but no need for this application). The obsidian factory ring counter should not malfunction again.

I would like to build a proper clock based on a SINGLE 200 tick clock signal and plenty of stacked counters ("hours", days, weeks, 2-month periods, years). This would require to run the fastest "hour" counter (for 200 tick signals) on fast furniture (6 hatch covers instead of a bridge). The rest should be conceptionally simple, if time consuming, to designate and build ring counters.

____________

A minecart rising edge detector, the hatch is above a straight track ramp, plate is on a straight track, output and tied to the hatch as well. Initial delay 18 turns to ON, full cycle w/ return to starting position is close to the possible minimum with the given initial delay.

Code: [Select]
%▼▼=======+▼^+▼%
« Last Edit: July 01, 2015, 05:38:21 pm by taptap »
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #21 on: July 23, 2015, 02:43:31 pm »

I made a clock. Only little innovation in it, but I wanted to do it myself and do it the way only a single clock signal is counted, instead of several clock signals nestled into each other. The 200-step repeater (upper z-level seen in the lower right) is widely published, although I had a lot of trouble with weird permaflow, main machinery is a number of ring counters. The counter for the main signal needs to react faster than the normal ring counters do, so it has some custom design, otherwise it is straight from Larix blueprints. The additional edge detectors on the left were only build for testing, but they allow to feed in additional days, weeks, 2 month cycles into the system. (Blinking minecarts standing on hatches are sadly missing in the screenshot, three on the edge detectors on the left and the minecart in the 6x200-step counter.)

Spoiler (click to show/hide)
« Last Edit: July 23, 2015, 02:46:02 pm by taptap »
Logged

taptap

  • Bay Watcher
    • View Profile
mine cart collision lock / oscillator circuits / scales
« Reply #22 on: November 25, 2015, 09:14:53 am »

mine cart collision have different results depending on age, weight, speed. some of them are not elastic. to avoid complications all following observations only consider a moving mine cart hitting a static one. with only one moving mine cart to consider, age (i.e. move order) is eliminated as a factor. please read this (http://dwarffortresswiki.org/index.php/User:Larix/Minecart_Collisions) before proceeding.

1) mine cart collision lock

the first application is a novel solution to the locksmithing problem. (see: http://www.bay12forums.com/smf/index.php?topic=151799.msg6623297#msg6623297) only mine carts sorted by decreasing weight result in max speed after colliding another mine cart into the line. any other order results in a lower speed. this can be used to check whether a number of levers were pulled in a defined sequence.

2) oscillator circuit



(The second minecart standing on the north to south roller.)

A is sped up to a given speed, hits B, B circles around, is sped up to the same speed, hits A (that has moved around on the z-level below to the same spot B stood earlier) etc. the carts circle through this circuit in different speeds dependent on weight. the ratio of ticks needed through the circuit is reasonably close (not exactly for several reasons) to the weight ratio. more importantly the total time for a full cycle is lowest with mine carts of the same weight, i.e. neither collision loses speed. the total time for a full cycle increases the higher the difference to the point the oscillator breaks down when the heavier cart does not manage to complete the circle anymore.

this oscillator circuit allows for very different applications. a notable one is achieved by adding a pressure plate only activating for the heavier cart. this turns the circuit into a variable cycle length repeater, whose cycle length can be varied without any changes to furniture just by adding (or removing) some load to the carts.

3) scales

with careful calibration around pressure plate resets, so that any loss of speed results in a reset and a signal (off), it is possible to compare mine cart weights.

Larix

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #23 on: November 25, 2015, 12:57:04 pm »

Oh, that's groovy! Minecart collisions really have a lot of potential, i think. Weight's definitely the most useful parameter to play with.

2) I think the inaccuracies are mostly due to the way friction works - the slower a cart moves, the more time it spends in the cycle and the more speed it loses in the process. Corners take a fixed 1000 speed, making the mathematics even messier.

3) Funny that - i've fiddled with a "weight checker" over the last few days. It was a pure concept test and all i cared about was getting actionable results, so it ended up quite large:

Spoiler: spoilered for size (click to show/hide)

The cart that's to be "measured" spends all the time on the bottom level. It first gets accelerated to max. ramp speed in the three-ramp coil in the northeast, then released through the door. It turns north and smacks into the alder minecarts sitting in the three-tile hook in the very north. The push propagates through the alder carts and returns to the measurable cart, pushing it out south at ~260k * (lower involved weight/higher involved weight). It then travels "up" a row of impulse ramps until it's too slow to push through a corner. At that point, it tries to leave to the side. In this setup, it actually doesn't leave, it pushes the "output" cart sitting on the level above where it tries to leave, then accelerates back north and goes through the regulator hook again.

At the given very high input speeds, the measurement granularity is pretty good: it can tell apart willow, alder, chestnut, highwood, maple, cedar, ashen, birchen and oaken minecarts. The given setup fails to make a difference between larch and ash and between highwood and pine, though. Looking at the game data, density difference between each of those pairs is a mere ten, while twenty points of difference seem enough for different outputs: willow has 390 density vs. 410 for alder and 430 for chestnut; and willow and chestnut give slightly different results when testing either against alder.

Spoiler: idle rambling (click to show/hide)
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #24 on: November 26, 2015, 01:49:04 pm »

Yes, and there is the part of the track between roller and collision, where the weight of the cart has no influence on the speed whatsoever.

I use a roller because I want to use loaded minecarts eventually (the testing is with different metals for now). I tested a little with the one shown above (roller on high speed), and I can tell apart brass and bismuth bronze (3,5%), but I could not tell apart tin and zinc (2%).

I like your three minecart corner. Theoretically the best granularity should be possible with an "infinite", low friction track and high starting speed, where even a small weight difference results in a measurable length difference. I.e. sending your cart after the collision not back through "anti-impulse" ramps but a really long track.

I am still experimenting around with oscillator circuits to build a calibrated one, but I do not understand what happens tick by tick.

Spoiler (click to show/hide)

Larix

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #25 on: November 26, 2015, 05:02:06 pm »

I never explored the timing thoroughly, because someone else already did all the heavy lifting:

http://dwarffortresswiki.org/index.php/User:Vasiln/Build_order

If i understand it correctly, this means
1. Minecarts are a type of mobile furniture and resolve move order in the normal furniture queue. If a pressure plate was installed after a minecart was constructed, the plate takes its move first within the tick, finds no cart and stays inactive; then (in the same tick) the cart takes its move and moves into the plate's location. The plate only notices the cart's presence on its (the plate's) next action, in the next turn. The same applies to the cart leaving the plate - the plate only "notices" the cart's absence with a full step of delay. In the given example, the plate registers the cart's presence on step 2 and its absence on step 5.

2. Doors and hatches get opened directly by the plate activating (ignoring build order) but wether they close on the turn the plate turns off or one turn later depends on build order.

Hope this helps.

PS (not making a new post): "construction" means the time a dwarf went and installed a building on site. Manufacture of the door or mechanism (by mason or mechanic) doesn't matter. Door built before the plate closes the moment the plate resets, door built after the plate closes one tick later.
And concerning 1. - i misremembered. As taptap noted (and i worked out in a verification test by myself before that post went live ;) ) build date of the minecart seems to have no impact on plate activation. Would be a bit strange actually, since fixed furniture acts from "youngest" (last built) to "oldest" (first built), while movement resolution between minecarts is exactly opposite, from oldest to youngest. For minecarts, build time is the only parameter, placement doesn't matter (would be kind of strange anyway).

My current best guess is that minecarts take their turns as their own block within the movement queue, after installed furniture is done doing its thing.
« Last Edit: November 27, 2015, 01:12:31 pm by Larix »
Logged

Pseudo

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #26 on: November 26, 2015, 10:08:57 pm »

Define "constructed" there? Is that when it was made, or when it was placed?
Logged
The lady the dog the paper the boy writ hit bit knit.

English is weird.

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #27 on: November 27, 2015, 11:50:02 am »

Define "constructed" there? Is that when it was made, or when it was placed?

Different for immobile and mobile furniture. Assumption is immobiles have the time stamp of their installation, mobiles of their construction. Vasiln has not written about minecarts in his post (though Larix has experience with his age-sorter).

Findings:

* Door and pressure plate changed when (re-)built in reverse order. Door then closes on tick 104 as well. (As expected.)
* Minecart and pressure plate interaction showed no difference, when old minecarts were exchanged for newly forged ones! I.e. minecarts move after installed furniture no matter what. I checked all minecart + pressure plates at hand in slow motion and it was always the same. (A bit surprised, but this is a relief!)

Pseudo

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #28 on: November 28, 2015, 09:09:47 am »

That is a relief...
Logged
The lady the dog the paper the boy writ hit bit knit.

English is weird.

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #29 on: November 29, 2015, 11:02:31 am »

Shamelessly stealing design choices from Larix I arrived at this one. A calibrated, weight sensitive cycle/repeater



Of the many cycles of 102 ticks length in default settings this is the most neat-looking one. Highest speed rollers. 3 same-weight minecarts in corner. A same weight minecart will hold the pressure plate down, with even a slight weight difference in either direction the cycle takes longer (since one collision either into or out of the corner will lose speed) and the pressure plate will reset. Brass to bismuth bronze (acc. to wiki about 3.5% difference, in game it looks even smaller when looking at minecart weights, produces 5 ticks difference), so this looks like even 1% weight differences should be measurable.

Either to compare minecart weights or as a variable length repeater depending on load, workable starting from 103 ticks to xxx ticks length (I guess should work fine until about 200). Additional load needed for longer cycle length probably needs to be written down in a table for your fav comparison minecart, close to comparison weight it might be somewhat proportional to weight, but I don't expect this to hold up. A lot of friction in the track (14 corners), so a minecart twice the weight will take more than twice time and beyond that minecart movement will soon get so slow as to break the mechanism.
Pages: 1 [2] 3