Bay 12 Games Forum

I've been trying, but just cannot get vanilla 0.6.12 to recognize v0.34.06. I do have a slightly odd situation because I run the linux DF and the windows DT under wine (because I don't do a .deb compatible distribution), but that shouldn't be an issue. Previously I've just dropped the right .ini files into the right memory_layout folders and I've been good to go. This worked, for example, with v0.34.02.

Call me spoiled, but I simply cannot run any reasonably sized fortress without DT anymore. It's not worth the pain.

My Fort has just succumbed to a Tantrum Spiral do to, at least in part, excessive interrelationships.

First migrants had six kids and it just went downhill from there. At the Fort's peak we had 97 dwarves and 50 children. I was managing to feed all the buggers, but it wasn't just the individual families... later migrants giant families were -also- related to earlier migrants (Come to BoiledPlanks! Bring the family!) so I ended up with bazillions of cousins, who all then had fits when Dad/Uncle Urist had a mood and couldn't get any spider silk. Then the other kids got mad because *their* kids punched one of *our* kids and some hyperkinetic schoolyard brawl insanity ensued.

Of course the manager and mason were early casualties, leading to a fatal lack of coffins, corpses decaying on the stairs, and more insanity.

Dwarves also need to invent better anaesthesia. The manager went insane in the middle of his own surgery, got up, and starting beating the poor doctor.

It seems in this version, however, children are the new cats.

So... due to the new migrant wackiness my fortress is 60% children.

One of them just threw the fort's first party, and only invited about a third of the other kids. "Ha-Ha"

There's a "clunkiness" penalty to rolls and an overall speed penalty, I think.  I'm not sure what the overall deal should be with armor weights.  We're missing things like padding under metal armor, and I don't know anything at all about how leather armours work with that or how much they should weigh or encumber compared to other armors.  There's kind of an RPG tradition there, but I'm not sure how it should actually work.

You've been pretty simulationist about things so far, so it would seem reasonable to continue in this instance.
Simple case: total weight carried reduces speed, metal armours add an appropriate amount of "noise" when moved.
Advanced: Leg armours primarily effect movement. Arm armours primarily effect craft skills and attacks. Head armours effect perception. Overall encumbrance also effects movement speed.

Forgot to mention that order is relevant...
Rather than build weird trees of belonging, the first rule that fits applies.

Also considered weird averaging schemes, but they generally aren't worth it.
I do really like the emergent behaviour from this though. Worth sharing.

There are equations for acceleration on an inclined plane.

They aren't really needed for the discrete timescales you're dealing with.

All you really need is conservation of energy, lessened by friction.
So... set a value for kinetic energy lost to friction per tile rolled over and a value for kinetic energy gained per tile dropped. This is also nice since it would let you drop a boulder several z-levels to build up speed before it hits your ramp. Velocity is technically then related to the square root of the boulder's current kinetic energy, which indicates how many squares you move each step.

If you wanted to get slightly more fancy (and tone down speeds), count friction for a ramp as 1.5x that for a flat (approximating the square root of two for the longer surface).
If you wanted to get even more fancy, you could define the rolling/sliding friction for all the various floor surfaces (or all materials), so that the boulder would roll very quickly down your ironclad hallway, then quickly come to a stop when it hits that patch of sand.

The interesting (and harder to program) question is what happens when a fast rolling boulder hits a ramp up, or a sideways ramp. The easy solution would just ignore them and roll onwards, shedding energy when forced to go up, but it potentially sets things up for crazy Dwarven Marble Madness. 

I've had a brewer die of dehydration because he's too busy making beer to drink any of it - that is just dumb.

And arguably un-dwarfy. Nothing is more important than a nice beer break!

Really, I'm going to throw my vote in for the non-option of something completely different than either purely reactive method. Before a dwarf takes on a task, it should take an extra few ticks to consider the following things:
1) How far away is the job from my/a bed and my/a dining room (we'll let dwarves assume food and drink will be available near any dining room)?
2) How far away is the job from where I am now?
3) How long will the job take to complete, including round trip time?
4) What's my current state of thirst/hunger/fatigue and what will it be at the soonest I can assuage it if I take this job?
5) If I'm going to be hungry/thirsty soon, consider grabbing a bite/drink before leaving for the job or (if enabled) taking a sack lunch or wineskin along with me.
6) If I'm going to be too tired to do this and get back to my/a room, is it reasonably possible to do so? If no, plan to sleep at the job site. [Hmm, maybe Clothiers should be able to craft blankets or bedrolls that will reduce the unpleasantness of sleeping on the ground. If added, a dwarf sent to a distant woodcutting or construction site would now have the forethought to bring one along...] If yes, check other jobs for something more reasonable and put this off until morning.

It shouldn't need to be terribly complex logic. Just let the dwarf project themselves forward in time to the conclusion of the task and, if their state would at that point be dire given the proximity of bed/food/drink, either take precautions or put off this particular task until later.