Bay 12 Games Forum

Unfortunately using a reset lever causes a net loss of 1 mechanism, the pp will give 2 back when deconstructed, but the mechanism attached to the bridge connecting to the pp is still stuck. For a closed loop system the +- should be equal to zero.

Edit: I made the assumption the plate wasn't working because i thought it would automatically send an open single n ms after the trigger, leading me to assume it bugged out. Are you saying that after sending a close signal, the plate is ready to send anothet close signal without having to iterate (like how levers need to pull twice)?

"An integrator in measurement and control applications is an element whose output signal is the time integral of its input signal. It accumulates the input quantity over a defined time to produce a representative output."

I've been reading up on soviet water integrators, and I've been wondering about using DF as a didactic tool to learn how to set up simple integrator circuits. Currently the manager screen (i'm also using dfhack) allows one to set limits and watch certain stocks to indicate demand, but that only allows a pseudo automation that essentially relies on large surplus buffers of just about everything. I tend to leave the game running while doing other tasks, everything works fine. I just want to find ways of (A) improving fps effficiency, and (B) using more advanced automation for fine tuning.

 Is it more processor efficient to chain order conditions (to other orders), or does the order still query the entire parameter list daily?. Because if it is more efficient, it's possible to query the reagants list in the 1st chain link, and all subsequent orders in the production chain only need an order linkage, since the reagants' state was already cached by the 1st order (as TRUE).

Other applications I've found is the implementation of a simple dwarven calendar. If you set a yearly mint of coins, those coins will have the name of the year on them. If the furnace is linked to a sans-bin stockpile, each individual tile will upon k-look display the year of minting, and the entire stockpile becomes an active screen calendar.

Of course the classic analog mode integrator involves water. For whatever reason, it's hard to find a variable that corresponds directly to fortress population (unless i'm missing something). However, demand is essentially a linear function of fortress population (trust me, i'm an economist), and it's hard to model that using stocks since stock buffers less than ten tend to cause cancellation spam due to hauler idiocy. But it is possible to obtain an estimate of fortress population by placing pressure plates along a main thoroughfare, precisely accounting for delay and water flow, opening a floodgate to a sealed chamber, the integer count of signals equals (water total)/(water per signal) = p, and p/Population gives the percentage of traffic through the area, which can be accounted for by trivial conversion later when initializing finalized params.

The problem with water integration is one of extracting the data once processed. For example, the pressure plate in the sealed chamber, when full, releases the water pressure, which can open a door to a locked stockpile (a really, really convoluted way of managing production by supply), or even more simply, the water releases pressure which sends the contents of a food stockpile down the corridor, through a shaft, falling onto a filtration grate located within the dining room of your safely imprisoned evil monarch (quantum stockpiling without dumping, since after pop 30 my dwarves stopped giving a damn about dumping for some reason).