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 14919 times)

taptap

  • Bay Watcher
    • View Profile
sub-coordinate positions in dwarfputing
« Reply #30 on: February 04, 2016, 09:54:31 am »

(all experimentation done in DF 40.19)

It should be possible to build "memory" using sub-coordinate positions of minecarts. Basic idea: a line of carts "remembers" whether last hit from left or right, resulting in delays for a left/right incoming cart dependent on the state (left/right) of the minecart line. Idea would require the memory minecarts to remain in place.

Preliminary findings:

1) It works with a line. I need to come up with applications.

2) It does not work at all with track corners. I tried with with a 3-cart-collision-corner similar to the one in the post above. The delay between entering the „input tile“ and exiting was dependent exclusively on direction of incoming mine cart (12 and 15 ticks respectively in my case, slight difference in speed and build order can account for this difference), yet no difference dependent on the direction of the previous minecart was found. This result is NOT consistent with the findings of the Post Scriptum to the mine cart graduate course by Larix (1).

Expectation:

A minecart ends after a corner in the center of the exiting tile edge. After a consecutive collision from the same direction it has to travel half a tile distance to the edge, where the corner is accounted for and the cart transferred to the center of the exiting edge. When entering the input tile from the different direction afterwards it would find the carts at the center of the edge from where they had to travel a whole tile to the opposite edge, where the corner is accounted for and the cart transferred to the center of the exiting edge. A consecutive cart from the same direction would only require half a tile distance. Thus a difference of 3 half tiles / cart speed was expected between first cart after direction change and consecutive carts. This difference could not be observed.

Further reading (all posts by Larix):
(1) http://www.bay12forums.com/smf/index.php?topic=144328.msg6279282#msg6279282
http://www.bay12forums.com/smf/index.php?topic=145317.msg6007040#msg6007040
http://www.bay12forums.com/smf/index.php?topic=145028.msg5756169#msg5756169
« Last Edit: February 04, 2016, 10:05:45 am by taptap »
Logged

Larix

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #31 on: March 27, 2016, 04:36:24 pm »

Hm. That's odd, because i'm definitely getting the expected difference: three-cart collision corner filled with birchen carts, pushing a birchen cart into it from same distance.

When pushing "against" the age order (from younger to older) the cart exited the corner after 14 steps when the previous push came from the other direction, 10 steps after a same-direction push.
When pushing "with" age order (from oldest to youngest), exit times were 12 and 8 steps respectively.

Evaluating such a memory could be done by hitting a pressure plate before the corner that triggers a delayed opening/closing of a building somewhere behind the corner. I'd probably use a grate that opens while a cart coming from a "reverse-biased" corner is still on top of it, i.e. it would fall while other carts would barely pass over it.
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #32 on: March 31, 2016, 11:27:19 am »

Hmm. This is seriously weird and I am not pretending to understand.



The push comes from the tile with the lone cart (probably losing a bit of velocity compared to you). I switch between bridge and a track corner beneath the bridge exposed while the bridge is retracted. The cart leaves in expected directions, but I could not find any of the expected memory after testing it for a while. They left the "corner" on turn 15 or turn 12 respectively (counting arrival as turn 1).

Wondering whether age order might messing things up, I completely reassigned the carts ordered by age (the youngest as working cart) - now I found a different delay in the first run and the second run. Wondering whether now memory was happening, I switched the corner tile, and again had two different delays in first and consecutive runs. I thought, hmm, memory after all. Let us try this again. Switched the corner tile once more, but now the first run and consecutive runs had the same delay and now in several iterations the cart is consistently leaving the corner on turn 16 or turn 11, respectively.

Larix

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #33 on: April 13, 2016, 11:33:47 am »

Ah, stupid me, i didn't do enough test runs. Yes, once the circuit has "settled in", each pass takes the same (short) time, regardless of where the last push came from.

That's because the premise is flawed:
carts take the corner at the end of a tile. If a cart is blocked from entering the tile "past the corner", it stops at the end of the tile as though it ran into a blocking wall in the original movement direction.

I.e. if a cart moves northward into a SE corner, it'll try to turn away to the east. If movement to the east is blocked, the cart will stop at the northern end of the tile. It will not move to the east or west. If the same cart now gets a push to the west and the exit to the south is blocked, it will stop at the western end of the tile. Once again, its NS coordinate will stay the same, i.e. it will now stand at the very northwestern sub-coordinate of the tile and each northern or western push will instantly move it through the corner. Once your corner array has processed one push in each direction, all carts will stand on the corners and there'll be no more difference in propagation time of a push through the circuit.

Positional "memory" is possible, but you'll need to base it on non-corner tiles:
instead of

╔╗
╚╬


a block of nothing but corners, add two straight track tiles:


╔╗
║║
╚╬

There must be minecarts on all tiles apart from the four-way crossing, where pushed carts arrive and depart. Haven't tested it much, but the logic seems sound and same- vs. opposite-direction pushes result in ~10 vs. ~20 steps delay. (Before the corners have "settled", you can get delays of up to 28 steps.) Cart position on the two straight track tiles _does_ vary depending on the last push direction, which is enough for a count- and probably measurable difference over several tries. Downside is that five carts seem a bit much for one bit of "memory".
« Last Edit: April 13, 2016, 11:40:44 am by Larix »
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #34 on: May 02, 2016, 02:18:00 pm »

A little minecart riddle:





Two minecart tracks are shown, second picture has rollers and minecart hidden. Above roller pushes south, below roller pushes west. Both are set to the same speed. The above circuit uses one tick less at the roller tile, yet the circuit below will slowly pull ahead. Why?

Fleeting Frames

  • Bay Watcher
  • Spooky cart at distance
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #35 on: November 06, 2016, 07:36:47 am »

Nice riddle :)
1) It works with a line. I need to come up with applications.
One application is with that multi-push lighter cart on heavy one: Adding more than 1 heavy cart on track stops would just lengthen the timer for each cart added thus.

Another would be for similar setup, expect with pushes provided nigh-simultaneously from both directions - could use the start of line for speed relay to cause an elastic collision, thus making use of the highest friction track stop for timers.
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.
Probably not possible - reposting from trivial findings:
EDIT: I have learned that minecart collisions only use whole urist weights by cart. A cart with 1 or 0 wood nestboxes inside gets same push, and cart with 2 acts as if it's weight was exactly 1 urist larger. If they also floor sub-tile positions, the above cobaltite nestbox in adamantine cart pushing on platnium-water cart checks out.

Disappointing, though.
Highwood was 500, and Pine is...510. So that's 20 and 20,4 Urist weight for both - both treated as 20 for collisions. Though the above quote was speaking about standard 600 density.
« Last Edit: November 06, 2016, 07:39:38 am by Fleeting Frames »
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #36 on: November 06, 2016, 08:11:10 am »

I think we were both extrapolating from a continuous reality to a discrete dwarf fortress world. And smaller relative differences (in percent of weight) were measurable after all one heavier carts. A bit disappointing it works with whole Urists, when everything else has subunits.

(For future readers: Fleeting frames on non-trivial findings thread: http://www.bay12forums.com/smf/index.php?topic=145317.msg7251241#msg7251241)

Fleeting Frames

  • Bay Watcher
  • Spooky cart at distance
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #37 on: November 06, 2016, 08:14:21 am »

On the bright side, you can check the weight the cart in-game to calculate exactly how much of an impulse it will get - no need with messing around with calculating density*volume for cart and everything in it. Though it is sometimes continuous, i.e. 2 nestboxes giving cart exactly 1 urist instead of 0, despite both being less than 1 urist individually.

I'd call this a bug.

Forces the use of heavier carts for higher 4-tile timers, though.

EDIT: Just curious, but since you mentioned wanting it: what would you do with weight-adjustable timer/repeater anyway?
« Last Edit: November 06, 2016, 08:23:03 am by Fleeting Frames »
Logged

taptap

  • Bay Watcher
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #38 on: November 06, 2016, 09:04:39 am »

On the bright side, you can check the weight the cart in-game to calculate exactly how much of an impulse it will get - no need with messing around with calculating density*volume for cart and everything in it. Though it is sometimes continuous, i.e. 2 nestboxes giving cart exactly 1 urist instead of 0, despite both being less than 1 urist individually.

I'd call this a bug.

Forces the use of heavier carts for higher 4-tile timers, though.

EDIT: Just curious, but since you mentioned wanting it: what would you do with weight-adjustable timer/repeater anyway?

Might be rounding. (We don't know where the limitation to single urists happens, lower weights apparently exist otherwise they would not add up when multiples are put together.)

Weight adjustable timers / repeaters: you have seen my odd water plant, would have been easier if I could pick suitable length timers right out of the handbook. Even neater if I could see the interval at a glance by looking at the minecart loads. We could even put a table in the wiki (horizontal lead cart with x bolts, vertical wood cart with y bolts: resulting delays in the type A multi-collision minecart repeater).

It also seems to be the best method available for really long cycles. Less nestling required, smaller footprint.
« Last Edit: November 06, 2016, 09:13:10 am by taptap »
Logged

Fleeting Frames

  • Bay Watcher
  • Spooky cart at distance
    • View Profile
Re: taptap's dwarfputing experiments
« Reply #39 on: November 06, 2016, 09:42:47 am »

Well, if the output from devel/watch-minecarts is correct for speed, then I'm certain that minecart + 2 nestboxes is treated as 25 Urists, not 25,2 Urists as it should be.

Your odd water plant would still have required figuring out cycle length. Granted, once that is done it is convenient, I suppose....

Wiki would have static table, which isn't very attractive, as you'd need a separate table for each possible cycle length (ranging from 1 to 50000) to display the array of suitable weight min and max multipliers for each input speed and friction.

But as far as quick guesses go, a quick and reasonably accurate estimate for single-step movement cycles can be gotten simply with input speed*input cart weight/((50000/(cycle length-0,5)+suitable friction).

Ex, 200 repeat cycle, normal wood cart, 2174 input, medium friction: 24*2174/(500+50000/(200-0,5))=69,5. Toss into cart 2 doors, bin and bucket for 50000/(2174*24/70-500) = 205 repeat cycle. Or leave out bucket for 196 one. If you leave out the -0,5 part and have a convenient input speed, could calc it entirely in your head quickly.

Can obviously get closer or exactly to desired results with lower frictions, higher weight carts (here in particular, tossing another cart into pusher cart is attractive) and multiple movements per push (the formula for that one is kind of complicated), but just to show that it can be pretty quick to calc.
« Last Edit: November 06, 2016, 09:53:27 am by Fleeting Frames »
Logged
Pages: 1 2 [3]