Print

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

[papyrus_eel]

"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).

[mikekchar]

Very interesting thoughts.  From a practical standpoint, I think you may be overthinking the problem a bit, but DF doesn't have to be about practical standpoints :-)

I don't believe chained conditions will be more efficient than non-chained conditions.  I am almost 100% sure the entire list will be iterated over each time.  I don't have data one way or the other, but programmers have certain styles of doing things and that seems to be Toady's style.  Having said that, I doubt that it will have any appreciable effect on FPS.  Activation of management tasks happen at most once a day.  There are 1200 ticks in a day, so any calculations there will impact FPS at least 2 orders of magnitude less than other things (like temperature calculations, water pressure calculations, etc).  Also, it is not feasible to create complex enough orders to take any appreciable time.  We're talking *max* 1-2000 calculations.  So at 100 FPS, we're talking probably under 1% of the load.  At 20-30 FPS, it will have even less impact.

As for keeping low stock levels, I do it all the time and get no cancellation spam (except for milking and shearing, but only a few each season).  Usually my stock levels for each intermediate item (something that is used in construction of something else) is 5 and for final items (something that is used directly by the dwarfs) is 3.  Of course it depends on the item.

I was going to write my usual long description of stockpiles and workshops, but sometimes people just like doing things the way they like doing things, so it might be a waste of bits.  The main hints are: almost always make 1 item at a time.  Since the job is checked every day, that means only making 1 a day.  Trust me, this is fine for almost all automated tasks.  Make a specific input stockpile for each workshop right next to the workshop (I literally surround the workshop with 16 stockpile tiles).  Generally, don't use containers in these stockpiles.  There are ways to do it, but it is very prone to error.  Since you never need more than 5 tiles per item, there is almost nothing that requires a container.  Make your stockpile big enough so that you can build the replacement and haul it before you run out of stock.  Since you are only making one item a day, and it takes a fraction of a day to make something, this means you really only need to keep a stock of size one.  A stock of size 5 allows your dwarfs 5 whole days to haul the goods.

You might be wondering, why 1 item a day is enough.  There are 336 days in the year.  Making 1 item every day means that you can make 336 items a year.  For most things, that's *way* more than enough.  For a few industries, you may need more.  For cloth, for example, if you want new outfits for every dwarf every year, you might need to do 4 jobs a day.  That would mean weaving/dying 4 jobs a day.  But even with that, if you have pigtail, yarn, silk and rope reed, then you are only doing one of each per day.  And there is no reason why you can't have 2 workshops.

You are correct that demand is linear on population size, but I'm struggling to think of a way to utilise that information.  There are only a few things that you can't "pull" on demand: rock because you have to mine it manually, wood because you have to chop it down manually, to some extent plants because you have to build farm plots manually, leather because you have to butcher manually, wool and milk because you have to choose a job size that corresponds to your flock size.

It would be cool to be able to say, "I have 100 dwarfs, so I will auto mine 300 rocks, and auto chop 5 trees, and my flock size is bigger than I need, so I'll butcher x animals, and I need more plant capacity so I will build farm plots", but none of those things are possible.

Still, the idea of a water integrator that fills up a reservoir as people step on a pressure plate is a very cool idea :-)

[Fleeting Frames]

Correctly calibrating that pressure plate is a mess, though. Past a certain point of congestion, the pressure plate will never turn off. For cool things mikechar listed, there are plugins/scripts for autobutcher, autochop and autofarm, though none of those really takes dwarf population as direct input without modding them; only consumption rate/animal population.

If you want to quantum stockpile without dumping, here is a guide to making a minecart QSP I wrote. That said, I believe it is likely you turned on 'o'rder that dwarves ignore refuse from outside or had forgotten dump zone.

For an use of an integrator in DF, I guess you could use one to check the average result of your random signal generator.

[taptap]

What do you actually try to achieve? I read water integration, but wonder how it relates to the better automation you seem to want.

[papyrus_eel]

I just happen to be interested in computing and programming, and by figuring out how the game works i can learn some fundamental concepts.

@mike

Re: chained conditions

The analogy I'm thinking of is database efficiency. The purpose of caching is to preclude queries to the entire database. Since the order list is always smaller than the item list, it should hypothetically be more efficient to query. But since I don't know how toady implements search, i can't actually say that for sure. It's only speculation.

As far as cancellations, it's caused by dwarves dropping job items down bottomless pits or on top of trees. My standing orders claim death items, so it's just easier to buffer the job items than to hunt down every single inaccessible one. I also get what you're saying about single orders, I use that for anything that rots, since an item check only processes the modulus of the order size, leaving the remainder to rot.

@fleeting frames

The real reason I want to use an integrator is to learn how to build one in the first place. These are things that used to be done by engineers as statr sponsored megaprojects, that someone on the internet can find an easy tool to do it is just amazing.

I know what you mean about pressure plates being finicky, i can program them in principle, but in practice they always seem to mess up. For example my drawbridge sends the close signal all right, but it doesn't send the open signal after the stimulus ends, meaning i have to deconstruct both to reclaim the mechanism. But in theory the close signal should activate just as the enemy traverses the causeway, flinging them into the air, and reset itself after.

For the population sensor, i suppose i could put it in the trap filled maze next to the entrance that dwarves seem to path through on occasion. Extrapolating that weak signal seems more trouble than it's worth honestly, except to establish in principle that it can be done.

Of course it would be far simpler to write a dfhack query to the actual population size, and put that in the conditions screen.

@ taptap

See above.

[PatrikLundell]

Whenever you use a drawbridge controlled by some kind of trigger, it pays to have the bridge also hooked up to an override lever so you can toggle it back to the starting state manually by two lever pulls: that definitely beats de-re-construction.

[papyrus_eel]

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)?

[Fleeting Frames]

You assumed wrong.

On signals: Plates sends On signals right away or 1 step after (i.e. with minecarts). Then the bridge registers it either on same step or 1 after depending on build order.

Off signals: Plate sends Off signal 99 steps after On-signal causing trigger on it is removed. (ditto build order etc.)
Note that if a plate re-gets on-signal causer in those 99 steps, it resets the waiting period AND sends no signal; a minecart driving in a small loop over a plate for eternity will send one and only one signal.

Bridges/Floodgates/Grates/etc. getting stuck: All slow buildings can't register new signals for 100 steps after they implemented last signal; This can happen with single pressure plate only if the trigger condition is present only for a single step, such as with checkpointing/fast minecarts or small pumpstack. They'll also ignore the signal that already matches their state, so this way you can toggle those buildings with a plate.

More commonly would perhaps be with levers or multiple pressure plates.

[PatrikLundell]

Fleeting Frames types (or at least thinks) faster than I do, so the above is basically a repeat.

Your original response left me puzzled...

Yes, the normal reason for problems with pressure plate triggering leaving the triggered item in the wrong state is that the trigger was sent, but at a time where it wouldn't be processed by the device, not that the triggering device malfunctions. Thus, in the case of a pressure plate used to atom smash goblins released from a cage (with a lever), the goblin sometimes stops on the pressure plate rather than continue "toward freedom", the bridge raises up, and remains in the up position because the goblin remains standing on the plate. Pulling the override lever twice will lower the bridge, the goblin will move out onto the bridge, and manually pulling the override will remove another goblin from the world (usage of a locked door ensures the goblin doesn't actually get out before a dorf feels like pulling the lever again). Since the goblin has moved from the pressure plate, it sends a close signal to the bridge that's already closed, and is ready to send a new open signal.
You can also get out of sync with a pulled lever, if it's pulled again too quickly (harder to do with the current DF version than with the one before the jobs rewrite): double pulling it with get the lever in sync with the bridge again (the open signal does nothing to an open bridge, so there's no delay blocking the processing of a close signal from the second pull).