Bay 12 Games Forum

Quote from: Jothki on March 11, 2013, 03:16:36 pm

It's still kind of spammy, at least in the background. It breaks the model of jobs being posted once and then sitting until a dwarf decides to handle them, since the job needs to constantly check whether resources are available for it. From what I assume, repeated tasks work the way they do now for a very good reason.

The main problem would occur when a workshop is left with only jobs that are waiting for materials.  If programmed incorrectly, such a workshop would get into a recursive loop that locks up the entire game.  (That's likely to get fixed quickly.)  Even if programmed optimally, FPS will take a hit every time you have such a workshop and at least one idle dwarf enabled to perform each job in the queue.

Isn't this basically equivalent to the way that stockpiles work now?  A stockpile with free space will intermittently check to see if there's an item it can store;  if it finds a storable item, it creates a hauling job to bring the item to the stockpile.  Having a workshop with nothing but Wait jobs shouldn't cause any more lag than is caused by having a furniture stockpile on a map with no furniture.

I'm one of the people who voted for that topic, but this is a somewhat different suggestion.  That suggestion is for a way to keep stockpiles full by spawning new jobs when the stockpile is empty;  this suggestion is for a way to keep jobs queued and run them when resources are available.  The other suggestion would let you say "make sure I always have 200 barrels of dwarven wine";  this suggestion would let you say "automatically brew plump helmets whenever I have them".  It's a different thing.

I think this is a somewhat better suggestion, in several ways.  For one thing, this suggestion wouldn't cause job cancellation spam.  For another, this lets you set jobs per-workshop rather than per-stockpile;  it's more powerful than the other suggestion because it allows you to use workshop profiles, and won't create jobs in workshops you'd prefer it to avoid (like the current manager tends to do). 

Yup....I agree that the 'custom profession' thing in Dwarf Therapist makes this a whole lot easier. Most of my castes are based around burrows, so that dwarves in a particular caste tend to hang out with one another.  Each burrow/caste is assigned to particular production chain;  these are usually (but not always) the same as the default DF professions.

A few of the more non-standard combinations I like are:

Fisherdwarf / warrior:
Assign dwarves to a combat squad, give them good armor and weapons, and tell them to wear their uniform always.  Once they're trained up to expert or master in a bunch of different combat skills, remove the squad from active duty, disable all other skills, and tell them to fish.  Because fisherdwarves spend so much time hanging out outside, they tend to be my first point of contact with enemies or hostile wildlife;  when this happens, I can re-activate the squad and watch them hack up the hostiles.  Taking the time to train swimming helps, too, since they have a distinct tendency to dodge into rivers.

Woodcutter / herbalist / hauler / warrior:
Pretty much the same as the fisherdwarf, only they do all the other outside/cavern tasks.  Once I get a decent number of these, I usually use burrow restrictions to keep all the other dwarves from going outside, ever.  Training them with axes is the best, since the woodcutter skill means they'll always be lugging battle-axes around.

Miner / pickdwarf:
I never seem to do that much digging once the fort is established and I have a decent stockpile of gems and ores.  So, I put all the miners into a squad with picks assigned as weapons.  When they aren't actually digging, they're training with the picks (which also trains mining skill), and when they fight with the pick it uses the mining skill (which is by far the easiest skill to get to legendary).  This is also nice because dwarves who hit legendary with the pick will still mine, unlike axelords or whatever.  It's also worth noting that picks make surprisingly good weapons;  I once had a trained-up miner get jumped by a GCS while prospecting around the edge of the caverns, and the miner single-handedly killed the GCS in a single turn of combat.

I injured one of the dwarves in the seaside embark, and created a minimalist hospital to treat him with.  Another dwarf went to the well and filled a bucket with salt-laced water to wash his wounds.

Am I the only one who finds this hilarious?

A UTM simulate from blue to red, and that's it, repeat. The rest of the memory is unused (infinite or not), until next level of a simulated UTM is needed. Other wise its just doing the blue staff. Every next step of a complete simulation will add additional running space, and time. But the clock rate isn't change. The problem is only occurred when this is layered infinite times. Otherwise it can always running, just more processes and slow to show the next level.

While this would work with infinite memory (an ideal Turing machine), it simply wouldn't work with finite memory.  The issue has to do with something called the pigeonhole principle.

The basic concept here is that, if you want to use/store/manipulate 2ⁿ bits of data, you need at least 2ⁿ bits of storage to store it in.  Otherwise, you'll inevitably start losing data fidelity.  But because Turing machines also need to keep track of their own internal state, you'll need some additional data storage to store the state in.  So Turing machine A needs enough data to store both whatever it's simulating and its internal state;  if Turing machine B is simulating Turing machine A, B needs enough data to record A's data, A's state, and its own state.

This means that in your graphic, the length of the blue bar in each child simulation should be equal to the sum of the length of the red and blue bars in the parent simulation.  If the blue bars don't grow, you'll be stuck simulating either a smaller universe or a lower-fidelity universe -- in other words, you'd have to simulate a universe that contained less information than its parent.

I've since related this to a question that was posed in my metaphysics class about the likelihood of god based on the seemingly intelligent construction of the universe.  The laws of physics are composed of variables that would unenable life as we know it if altered by the slightest fraction.  It seems like everything was designed specifically to enable us.  So do we hand-wave it as a matter of pure chance, despite being astronomically unlikely, or do we consider the notion that these circumstances were constructed intentionally?

As I see it, the mathematical issue with the whole "anthropomorphic principle" debate is that you can't look at the universe in terms of probability (analyzing what's likely to happen);  you have to look at it in terms of statistics (analyzing what has happened).  And given that the statistical sample size is a single universe, we don't have a large enough sample to use statistics in any meaningful way.

A good analogy here is poker hands;  the odds of receiving any given five-card hand by drawing from a random 52-card deck are 1/287414400.  If you draw a royal flush on the first deal, you can look at your hand and say "gee, it's pretty unlikely that I'd draw that hand" -- but you could say that equally well for any hand you drew, regardless of what hand it was.  Now, if you just drew 10 royal flushes in a row, you can statistically say that the game is likely to be unfair.  But if it turns out that the game is actually fair (and you've just seen a ridiculously unlikely set of happenings), then the probabalistic odds of you drawing any given hand in the next round will still be 1/287414400.

Will the new were-curses stack? 

For instance, if a dwarf is bitten by a were-elk and turns into a were-elk, and the dwarf is then bitten by a were-groundhog, what will happen?  Will the dwarf remain a were-elk?  Become a were-groundhog?  Become a bizarre hybrid were-elkhog?  Turn into a randomly-mutated abomination similar to a forgotten beast?

But we encountered a more daring problems, it's now not only the trading was dying out, but the cities themselves were dying out. And the reason is simple, they relied on trading to survive too much. Because only those regions are lucky enough to own most of the importance resourced can sustain themselves, the others were having difficult finding the right partners to import the goods they required.

Maybe I'm missing something, but it sounds to me like your simulation was working correctly.  There are some fairly well-known and well-documented issues with export-based economies;  these issues become even more overwhelming when an export-based economy isn't capable of sustaining itself.

Off-hand, the only cities that I can think of that would tend to succeed in such a scenario would be the ones producing high-demand, high-scarcity products such as oil.  Historically, this works for a while (in a classic economic boom) until either the market gets saturated with the product or the city runs out of the resource.  Either way, the export-based economy then collapses -- so cities disappearing, when they were relying entirely on exports to sustain themselves, sounds like the correct behavior.

It also sounds like you were having some problems with simulated latency in the system;  but, again, that's the expected behavior.  In the real world, you'll never have huge industries appear or function without an adequate supply of the raw resources they're processing.  For instance, you'll never have a city suddenly found a huge number of gem-cutters without having an adequate supply of gems.  Generally, industries tend to start small, then grow hand-in-hand with their raw material imports as the industries succeed.  In other words, someone is unlikely to build a lumber mill without already having access to a large number of logs;  as the lumber mill profits, more people will try to sell logs to it;  when there are enough logs available to make a second lumber mill profitable, that's when a second mill will be built.  An empty lumber mill that can't quickly find someone to sell it logs is likely to go out of business, and a business or city that depends on a failing lumber mill is also going to fail.

So, while I'd fully agree that simulating economic networks is tricky, I'm not convinced that it will radically affect the future of DF.  Given that cities in world-gen already need to be self-supporting, and that all or most of the trade networks will be grown between these self-supporting cities, I suspect that Toady will manage to dodge most of the issues you had in your sim.