v50 Steam/Premium information for editors
  • v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
  • Use this page to report any issues related to the migration.
This notice may be cached—the current version can be found here.

User:Vasiln/Build order

From Dwarf Fortress Wiki
< User:Vasiln
Revision as of 19:47, 3 April 2012 by Vasiln (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

I once did some careful examination of a creature triggering a pressure plate linked to various buildings built either before or after the pressure plate. I added those findings to the pressure plate page. However, some of the things I found felt inconsistent with Hussell's findings regarding build order. In particular, he found that build order of gear assemblies affected the period of his repeaters, whereas I found that gear assemblies were always triggered on the same tick, regardless of whether they were built before or after the triggering pressure plate. Also, I found that the delay of pressure plates was 99 ticks, rather than the traditionally accepted 100.

These findings have always kind of bothered me, but I think I have a hypothesis that explains it.

The Grand Unified Hypothesis of Build Order[edit]

Every tick, the game evaluates every creature and building in sequence. Here's the order in which it does so (according to my hypothesis):

  • 1) Every creature checks its speed to determine whether it can move to the next tile in its path. If it can, it moves. If its next tile is occupied or inaccessible, it recomputes path.
  • 2) Every tile of fluid is evaluated to determine whether it should flow or teleport, and if it should, it does.
  • 3) Every variable-state building is evaluated (more on this later).
  • 4) Every tile of water is evaluated to determine whether it should flow (or maybe teleport), and it does so, if it should.

The important part of this is step 3. In particular, buildings are evaluated in the reverse order to which they were built. If you build a pressure plate, then a door, the game will first run the door's think function, then run the plate's think function.

Here are the think functions for various variable state buildings, as far as I can tell:

Door[edit]

  • If a close signal has been generated for this door, close the door.
  • Note that the door doesn't itself evaluate open signals!

Pressure plate[edit]

  • If triggering criteria are met, and the device most recently sent a close signal, send an open signal. Additionally, open any doors or hatches linked to this pressure plate, and toggle any linked gear assemblies the appearance of any gear assemblies, making them show up as engaged or disengaged.
  • If triggering criteria are met and the device most recently sent an open signal, don't do anything, except remember this tick.
  • If triggering criteria are not met, and it has been exactly 100 ticks since triggering criteria were last met, send a close signal. Additionally, toggle any linked gear assemblies the appearance of any linked gear assemblies.
  • If triggering criteria are not met, and it has been greater than or less than 100 ticks since triggering criteria were met, don't do anything.

Bridge[edit]

  • If no open or close is scheduled for this device, check for a signal. If open, schedule an open in 100 ticks. If close, schedule a close in 99 100 ticks.
  • if no signal, or an open or close is already scheduled, don't do anything.

Screw Pump[edit]

  • If the pump is adjacent to a powered gear assembly, there is fluid in its intake tile, and there is no fluid in an acceptable output tile, destroy the water in its intake tile and generate an equivalent amount of water in the first acceptable output tile.
  • Otherwise, don't do anything.

Gear Assembly[edit]

  • If an open or close has been generated by a device linked to this assembly, toggle the actual state of this assembly (not the apparent state, which is managed by the pressure plate).

*If gear assembly is adjacent to a device with power and is engaged, consider this tile powered. *If gear assembly is not adjacent to a device with power or is not engaged, do not consider this tile powered. *Note that gear assemblies do not evaluate signals!

Other Furniture[edit]

I believe that the think functions described earlier apply to all other forms of furniture. Hatches use the same think function as doors. Grates, bars, and floodgates use the same think function as bridges. Levers require a special note: I believe they function the same way as a pressure plate. However, there's a chance that the dwarf pulling them actually sends the signals, in which case you would expect to see levers functioning as if they were always built before the furniture they trigger. Levers do not function like other furniture! It is the dwarf that sends open and close signals, rather than the furniture, which means that signals from levers are always evaluated before any other buildings. Levers automatically open doors and toggle gear assemblies, since those are not functions of the furniture themselves.

How this reconciles Hussell's clock and my goblin repeater[edit]

This model of build order demonstrates how a gear assembly can both be engaged at the end of a tick, yet a pump attached to that gear assembly may or may not yet be powered, based on the order in which the two components were built. That disconnect between my data and Hussell's been bothering me, and this hypothesis explains both results.

Predictions[edit]

Now that I've got a working hypothesis (including bits that I'm not very sure of, for instance, exactly when non-dwarves are evaluated, exactly how power is evaluated, exactly when flow is evaluated), it's time to make some predictions.

Formulating data[edit]

200-step repeater[edit]

Let's examine the behavior of Hussell's 200 step repeater in terms of my theory. Reprinted here:

Z-level +1 Z-level 0 Z-level -1
% %
*
> *
% % ^
*
X *
^
<

Just to clarify, pressure plates trigger on 2+/7 water, and are linked to the gear assembly of the same color. Device is built in the following order: first the upper pump, then the lower pump, then the gear assemblies, then the pressure plates. Beginning state has 7/7 water in the left-hand reservoir, both gears disengaged. At t=0, we engage the green gear via lever. Let's examine, in order, the events happening during important ticks.

In a previous version of this page, I got everything wrong about this sequence. Rather than strike-out a bunch of stuff, I've just replaced it-- you can always look at the revision history if you want to see my embarrassing mistakes.

T =  0: Lever sends open.  Red plate has water on it, but did last tick as well: no signal.  Green plate has no water, no signal.  Green gear assembly engages in response to open.  Lower pump pumps left-to-right.
T=  1: Red plate deactivated, schedules close for T=100.  Green plate has water, sends open.  Green gear assembly disengages.  Lower pump unpowered (but will continue to pump through T=49).  Upper pump unpowered.
T =100: Red plate sends close.  Green plate has water, but previously activated.  Red gear assembly engages.  Lower pump unpowered.  Upper pump powered, moves water right-to-left.
T =101: Red plate dry (water needs to fall onto it).  Green plate dry, schedules close for T = 200.  Lower pump unpowered, upper pump powered.
T~=120: Water falls onto red plate.  Red plate sends open.  Green plate dry.  Lower pump unpowered.  Upper pump unpowered, but will continue to pump through T~=168.
T =200: Red plate previously activated.  Green plate sends close.  Green gear assembly engages.  Lower pump powered, moves water left-to-right.  Upper pump unpowered.  Same as T=0.

In the previous version, I underestimated the time it took pressure plates to reset. I'm embarrassed about that, and it led me to a quixotic search for a 100 tick repeater that wasted a lot of my energy.

Pressure plate trigger data[edit]

Here, I'm just going to link you to http://mkv25.net/dfma/movie-2363-timingdetails.

Actually, on reviewing that, it doesn't necessarily demonstrate what I want it to. This could be due to imperfect frame-by-frame capture for movies, or it could be because I screwed up. I will have to confirm. Yes, it does demonstrate the effects, you just have to slow it down to a rate below 1 to see all of the frames.

Dropping a dwarf takes 7 ticks[edit]

Creatures fall at a constant rate of 6 ticks. However, when you drop a dwarf, it takes 7 ticks for the dwarf to fall the first z-level. This, according to my hypothesis, is because the dwarf doesn't know the ground isn't there during the tick the floor disappears, because the ground doesn't disappear during the dwarf's think, it disappears later, during the hatch's think. But see the caveat below!

Testable Predictions[edit]

Screw pumps and pressure plates[edit]

The following design, seen from the side, can behave multiple ways, depending on build order.

# %% #  Return pump
# %%^#  Feed pump, plate (1+/7 water)
# ####  7/7 reservoir
###
  • 1) Build return, feed, then plate. Plate doesn't trigger. Water is moved first from the feed, then to return, and stays in the reservoir.
  • 2) Feed, return, then plate. Plate doesn't trigger first tick, but triggers on the next tick. Water is moved first from the return, then the feed, and so stays on top of the pressure plate.
  • 3) Return, plate, then feed. Plate triggers, although water remains in the reservoir.
  • 4) Feed, plate, then return. Plate doesn't trigger, although water remains on top of the plate.
  • 5) Plate, return, feed. Plate doesn't trigger, and water remains in the reservoir.
  • 6) Plate, feed, return. Plate triggers, and water stays on top of the plate.

Those are the predictions. Time to test!

Findings[edit]

I forgot to take gravity into account in my predictions. Water takes a certain amount of time to fall, and until it falls fully into the reservoir, it cannot be pumped back by the feed. This changes where we expect water to sit, but it doesn't change our predictions regarding pressure plate activation.

  • 1) Plate doesn't trigger. Water stays in the reservoir side. Meets predictions.
  • 2) Plate triggers. Water stays mostly in the reservoir side. That's because it takes time to fall to get pumped by the feed again. I missed the first tick, can't say whether it only triggered on the second tick.
  • 3) Plate doesn't trigger. Doesn't meet predictions. Will rebuild to verify.
  • 4) Plate triggers. Doesn't meet predictions. Will rebuild to verify.
  • 5) Plate doesn't trigger.
  • 6) Plate triggers.

Note that both feed and destination tiles are muddy. I'll DFHack unmuddy them to see if water is actually never touching a the ground on the machines.

After rebuild, 3 triggers, and 4 doesn't trigger. I figure I screwed up build order originally. Note that it doesn't look to me like Hack can unmuddy specific tiles, so I didn't test that.

So far, so good. Predictions are as expected.

Levers[edit]

Next prediction is regarding levers. I anticipate that levers behave the same way as pressure plates in regards to build order. Those predictions are established on the pressure plate page, and my hypothesis tells me to expect them. I'm going to test bridges, doors, and gear assemblies (as those represent the three build types in my hypothesis). Note that it's hard for me to establish exactly when a lever is activated, so I'm instead just going to compare the open and close signals of furniture built before and after the lever.

  • 1) Both doors open at the same time, but the door built after the lever closes 1 tick later.
  • 2) Both gear assemblies open and close at the same time.
  • 3) The bridge built earlier opens and closes 1 tick before the bridge built later.
Findings[edit]

Findings did not meet predictions. Buildings responded identically, regardless of build order.

  • At tick=-1, there is an active "pull lever" job at the lever.
  • At tick=0, there is no active "pull lever" job. Doors open or close, and gears engage or disengage.
  • At tick=100, bridges open or close.

There are two interesting parts to this finding. First, lever signals are being evaluated before all other signals-- I believe it's happening in the dwarf phase, with completion of the lever pull task. Second, open and close signals are being acknowledged by bridges at the same time-- 100 ticks after receipt of signal. Is there some way to rectify this with the behavior of bridges linked to pressure plates? Of course there is-- it is the 99 tick delay associated with pressure plates that is responsible for the 199 tick closing of bridges, not the bridges themselves.

Gear assemblies[edit]

Consider the following machine:

# %%*#  Return pump, return gear
#*%%^#  Feed gear, feed pump, plate (1+/7 water)
# ####  7/7 reservoir
###

Both gears begin disengaged, linked to a lever that has just been pulled (t=-1, queued pull job; t=0, no queued job)

We expect that power won't be transferred to pumps on the tick it's received by a gear assembly unless that gear assembly is built after the pump to which it's transferring power.

  • 1) Build plate, then feed pump, return pump, feed gear, return gear. Both pumps are in operation on the first tick (t=0), and feed pumps last. Plate triggers on t=0.
  • 1.1) Build plate, then feed pump, return pump, return gear, feed gear. Exactly as with 1).
  • 1.2) Plate, feed pump, feed gear, return pump, return gear. Exactly as with 1).
  • 2) Plate, then return pump, then feed pump, return gear, feed gear. Both pumps operate at t=0, but return pumps last. Plate doesn't trigger.
  • 2.1) Plate, return pump, feed pump, feed gear, return gear. Exactly as with 2).
  • 2.2) Plate, return pump, return gear, feed pump, feed gear. Exactly as with 2).
  • 3) Plate, return gear, return pump, feed pump, feed gear. On tick 0, feed is powered and return is not. Plate triggers on t=0. At t=1, return gear activates, plate sends close at t=99.
  • 4) Plate, feed gear, feed pump, return pump, return gear. On tick 0, return is powered and feed is not-- no trigger at t=0. At t=1, feed becomes powered, and plate triggers.


I'm not going to test 1.1, 1.2, 2.1, or 2.2. I will test the others. Particularly notable is the behavior of 3.

Findings[edit]

Initial findings were flawed. 1, 2, and 4 behaved as predicted, but 3 didn't-- in fact, it never activated the plate at all. Tearing down and rebuilding, even rebuilding gears earlier in the power supply, didn't change anything. In fact, the strange behavior of 3 makes me distrust what I saw with 4-- maybe I didn't look carefully enough?

Gear assemblies revised[edit]

What does this mean? Could it be because I turned power on with a lever? That would suggest that gears do manage their own signals in a way. What if I do a pressure plate activated gear, built before the plate that activates it, but after the pump it powers? Something like,

  *
# %% #
# %%^#
# ####
###

Okay, build return pump, feed pump (independently powered), plate, gear. 1) Gear starts out inactive. Plate doesn't trigger. Feed moves water. Return doesn't function. 2) Gear is inactive. Plate triggers. Feed has nothing to pump. What does the return pump do? Pump, or not? If it does not, then the plate was unable to activate it this tick. I know that the gear appears active at the end of the turn, but that doesn't mean it functions.

Findings[edit]

What actually happens: Tick 1: feed works. Tick 2: Return doesn't pump. Tick 3: Return pumps.

So the trick is that gear assemblies look like they toggle without regard to build order, but build order still affects whether they actually transmit power or not.

Water flow[edit]

This is a simple one, and I'm going to use Hack to test it.

# ## 7/7 water
# ^# 7/7 water, 0/7 water and plate that triggers on 2+
####

Predicted: Plate does not trigger on first tick, but triggers on second tick.

Findings[edit]

Water doesn't teleport on the first tick-- it takes a few frames. When the water lands on the plate, the plate triggers immediately, rather than at the next tick. This suggests that water moves before buildings are evaluated.

Mutual Lever Drop[edit]

So I started thinking about when exactly hatches open, since build order doesn't affect them, and think I came up with a good way to see if they open in the triggering device's turn. We design a simple drop system, where a lever controlled hatch drops a dwarf a z-level. The thing is, we get two dwarves, and we let them drop each other using this method. If levers are evaluated in the dwarf phase, and hatches open when triggered (not later in the tick), then one dwarf, later in the dwarf queue, will take 6 ticks to fall, and one dwarf, earlier in the dwarf queue, will take 7 ticks to fall. It's totally important to only let two dwarves into the system-- who pulls the lever might be a determining factor for how long it takes the dwarf to fall!

Findings[edit]

Yup, sure enough, it takes a different amount of time, depending on who pulls the lever. When a dwarf that has arrived more recently pulls the lever dropping a dwarf that has arrived earlier, it takes 6 ticks. When the earlier dwarf drops the later dwarf, it takes 7 ticks. This suggests:

  • Dwarves are evaluated in a last in, first out method, similarly to furniture.
  • Lever signals are sent during the turn of the dwarf who pulls the lever.
  • Hatches (and presumably doors as well) open immediately upon an open signal, rather than waiting for the hatch to evaluate that signal.

Very interesting.