Bay 12 Games Forum

I set up a hatch with a switch over a channeled-out ramp with a section of straight track on it.  Seven adjacents to the ramp are solid walls, the eighth is open ground.  Straight track laid over the ramp.  Put cart on the hatch, throw the switch.  The cart drops onto the track and ramp, and just sits there, unmoving.

Sounds like you have a nonfunctional ramp. Does it have two (at least) track directions indicated? E.g. a track-ramp that's supposed to push the cart out north and with a wall to the south would need "NS" track. A ramp with only "N" track will not accelerate the cart.

The reactor works, axles and rollers are powered - this is confirmed by the animations they show when turning in-game.  Throw the switch, open the hatch, drop the cart.  Cart falls on the powered, operating rollers... and just sits there, unmoving.  The rollers are rolling under the cart, which doesn't move. 

Is there track underneath the roller? Rollers without track don't affect carts. Track direction rarely matters*, but you must have actual track on the tiles.

* only two-connection corners can affect carts' movement directions on the flat.

There just making granite bookshelves same as the third lesser skilled one is doing but they're making the rookie do all the work.

If your issue is with a work order for stone bookcases, then it's quite simple: those are made by stonecrafters, not by masons.

^ yep, "upper body is gone" just means "It's dead, Jim."

As i understand it, when multi-part bodyparts have gone missing, DF only reports the "root" one as gone - i.e. entire leg gone: "upper leg is gone" (no mention of lower leg, foot or toes, who are also all gone); entire arm gone: "upper arm gone" (no mention of the also missing lower arm, hand and fingers)*. Thus, dead =  entire body gone, always reported as missing "root" part of the whole body, which is the upper body: "upper body is gone". It does not mean there's an unconnected lower body hanging around, because the lower body is a daughter limb of the upper body and thus, if the upper body's "gone", the lower one's necessarily gone as well. It's a bug so far as restricting the report to only the root limb sometimes produces unclear messages and anyway it really should just outright say "this unit is dead" instead of reporting the unit's body as "gone".

* which i find confusing/misleading, since it does sound rather like e.g. the lower arm's maybe still there, just... attached directly to the shoulder??

As i understand, sleep is the one thing that normally should *not* be possible, since dwarfs are said to absolutely refuse to sleep on top of traps. I can't find the research, but the effect is referenced more than once, e.g. here:
http://www.bay12forums.com/smf/index.php?topic=134194.msg4830952#msg4830952

However, there's been a "sleepwalking" bug in the 0.40 range of versions. Perhaps the "Siren" plugin accidentally re-implements that bug by summoning units without properly waking them up?

(Footnote: you might find reports of dwarfs coming to harm when sleeping on top of traps, but that was an emergent bug ca.2008, when dwarfs' trap immunity was revoked when unconscious, without sorting out the "sleep on the floor" choice of sleeping spots. That one was corrected long ago (before 2010?) to the state documented in the post quoted above.)

Today i stumbled over an old Acer Aspire someone had left by their door, complete with power brick but without battery. Took it home to see if it was a freebie or just someone outsourcing their garbage disposal and yes, it's alive and has a clean Win10 installed. So before i re-donate it, i ran The Benchmark (tm):

CPU: Intel Core2 Duo P8400 2,26 GHz (pub. Q3 2008)
RAM: 4 GiB 1066 MHz
Stable World: 1 min 54 s
History until year 250: 29 min 12 s (3:31 until 125, 25:41 for the rest)
Total: 31 min 5 s

Barely beaten by methylatedspirit's AMD A9, still massively faster than an Apollo Lake Celeron (but then that's just an upmarket Atom).

Sadly, the DF running in emulation ran out of memory before reaching year 250.

However, it took 6min,30sec to land on a stable world with 11 rejections, and ran for over an hour and a half trying to generate history before running out of RAM, someplace around year 210.

How much RAM/what processor?

I tried on two systems:

System 1:
i5 - 3230M (2,6 GHz, sometimes turbos to 2,7 or 2,8)
8 GiB RAM, apparently DDR3-1600 (Thinkpad X230, seems to only use this type)
Windows 7

Time until start of history:
0:47
History generation until year 250:
13:30 - 14:00
NB: not fully sure on the histgen timing; the first, properly recorded run apparently had typos in the name seed which not only created a differently-named world, i could also see a road on my final map that didn't exist in the reference worlds, indicating different events. The second run, with the correct settings, started making history after 47 seconds as well, but i missed the exact moment when histgen ended because i was wrestling with system two at the time; it was definitely under 14 minutes.

System 2:
Atom Z3735G; 1,33 GHz (turbo up to 1,83)
RAM: 1 GiB LDDR3-1333
Windows 10 (lowest acceptable specs with the given amount of RAM and a mere 16 GB storage, but fully up to date)

Getting to the stable world:
0:10:00
History until year 250:
2:09:40
Note: "finalising" after histgen alone took almost three minutes.
I got the same world name as the screenshotted worlds in this thread, but more dead units and only ~480 000 events; maybe because this was the 32-bit version?? I'm frankly surprised the system managed to complete the task. It's by far the weakest performer in this thread.

Just for funsies, i ordered both systems to save the result. System one took just over 4 minutes to save to HDD. System two saved to an inserted micro-SD card and took 43 minutes, crawling to just over three hours for the whole ordeal.

PS: both systems with iGPU, unsurprisingly; intel HD4000 and the "HD" but otherwise unnamed junk Intel put on Z3700 atom chips.

Quote from: Schmaven on August 12, 2019, 07:31:13 pm

Also, how long has it been since you made the ropes / chains?  They could be tasked for hauling and thus unavailable.  Try making a stockpile for just ropes and chains next to the well and once they are in that stockpile, see if you get the same issue.

 that rope had just been made. There is a stockpile there, but no dorfs seem inclined to move the rope as yet. I guess I'll wait until it gets moved and then try again.

Edit: Well, I don't know what did it, but I made another rope out of yarn and suddenly all of the rope was available to be used. All's well that ends well! ¯\_(ツ)_/¯

The problem was the stockpile. Making buildings that require ropes is much easier if you go without stockpiles that accept them.

In general, stockpiles are purely optional for usage of stuff - items are used just fine off the ground or directly from the workshop that produced them. If hauling distance, rot and workshop clutter are no concern for the specific use, stockpiles can have negative utility (like in the case above, where hauling tags make ropes inaccessible for the building menu).

Code: [Select]

......
.WWW.. W:wall
.W*W\. *:gear
.WWW.. \:ramp
......

Even better - build a floor above where the gear goes, i.e. obscure the central power routing: windmills can transmit power through unbroken floor. Build all windmills on solid (natural or constructed) floor, put in the gears after the mills are finished and you have a power plant that offers no incursion route to the fort proper and where gearboxes underneath the mills can be freely switched without causing collapses - the mills are held up by the floor and not the mechanisms underneath.
The worst thing that can happen is that invaders topple your windmills, denying you power. Walls/chimneys can mitigate the risk of that happening.