Bay 12 Games Forum

I've had that issue as well, several times. Strangely enough, no jobs to haul the straying war animals back to their pastures are generated. When it comes to dogs, firstly I keep them in an indoor pasture with a non pet-passable door (unless they are assigned to watch duty, which typically means locked in a 1 tile room with a grate overlooking a passage), and secondly, I don't care too much if they're running around. It was quite different with my war elephants, however, since the first one starved to death while straying, and the second one had to be slaughtered because it would otherwise suffer from the same fate.
I don't know what triggers animals to suddenly decide to abandon their pasture to follow their trainer. The first war elephant stayed on its pasture for several years before it suddenly decided to roam, though it might somehow been triggered by the training of the second elephant.

Thanks Larix!

That explains it. The corpse was from a Giant Kea shot down by caravan guards, so it makes sense it would fall on whatever tile was below it, and if it's unwalkable, well, unfortunate...

I had a similar issue, with a workshop with a corpse and a few items they just refused to dump, stockpile, or otherwise deal with. I eventually resorted to deconstructing the workshop and they promptly moved the corpse two tiles over to the refuse stockpile.
I also had another issue where some stone blocks were in the way of traps I needed built, so the trap construction was halted. The dwarves just ignored dump orders, linked stockpile orders, and everything else I could think of (including burrowing a dwarf with the blocks, a dump site, and a stockpile, although not all of them at the same time). Eventually I forbid the blocks, and then unforbid them, and finally Dumped them, and then it worked. I have a vague recollection there is a bug involving a hidden forbid tag somewhere.
Thus: try to forbid the items, unpause/pause, unforbid them, and then either wait for normal hauling, or dump them. If this doesn't work, deconstruct the workshop and rebuild it.

I don't think a virtual machine could change how things are done on a higher level, such as merging tile calculations. To do that, you'd have to rip out the appropriate parts of DF and replace it with the modified logic.
To precompute or use alternate calculation methods you'd have to identify the appropriate internal interfaces or "API"s and replace the code underneath. If some of the calculations are made by .dll/.so/... binaries, such binaries could be replaced with ones that use the modified logic/GPU resources.

I'd say these kinds of improvements/modifications would require DF to be opened up even more, and possibly that more people would work on DF itself.

The problem with "simple" multi threading is that bolting it on afterwards is no easy thing. If designed for multithreading in mind from the start, it might be easy, but otherwise you'd probably enter a quagmire of multiple access protection issues and computation order dependencies. Take equipment wear, for instance:
- You can have a thread that goes through all wear-prone items and applies wear to them. Normally, that would be it, but:
- Sometimes things are destroyed or subject to non standard wear (such as being exposed to fire), and this would likely be applied by the main thread.
- You could link items subject to wear from different sources into a temporary list that's post processed after the normal calcuations.
- You could let it be "random" whether wear is applied before or after an item is used (if a piece of clothing is falling apart, and it's hit in combat, chance [i.e. the order in which the threads processes the item] governs whether it was hit or whether it had already been destroyed, for instance).
- All of this hinges on the item structure being such that it safely can be accessed from multiple threads. A linked list where you remove an item from the list or reshuffle the list can give "interesting" results.

It would probably be better if the problem was attacked at the root, i.e. if DF itself was redesigned to be/support multithreaded. One clear candidate for a separate thread is the calculations for events external to the fortress (at least in fortess mode) since they have a very small interaction with the fortress itself (probably only diplomat/liason reports) and thus should have a limited need for multiple access protection and separation, another one is graphics, a third one is equipment wear, and a fourth is liquid flow and temperature calculations (there are probably others as well).
I doubt a GPU would be of much help for most of DF, since GPUs are very good at doing a very narrow range of repetitive tasks really fast, but are quite poor for general computing. There is, after all, a reason CPUs aren't just replaced by GPUs.
Another problem with GPUs is that they are not nearly as standardized as CPUs are, so you may end up with separate binaries for separate GPU configurations.
I would also suspect virtualization will slow things down rather than speeding them up, since emulation carries an overhead cost. If there is something that a virtualization improves, it can probably be improved more and better if the corresponding change was made in DF itself (but if the virtualization was targeted to a specific architecture, it might do tricks unsuitable for a general solution).

Up/Down staircases, 'i', will work everywhere, but they have side effects at the top and bottom in that they sort of poke into the tile above/below (such as puncturing the aquifer and letting the water down, or letting creature diagonally below the staircase up [presumably diagonal access is an issue from above as well]). Therefore, making the staircases "properly", by having a 'j' down staircase at the top of the stairs and an 'u'p staircase at the bottom is recommended unless you intend to expand the staircase at a later stage.
Note that this builds on what karhell said:
j: top
i: continous staircase
i
i
:
u: bottom

The attempts I have made have been unsuccessful. There were non zero numbers for the fishing zone option when settning up the zone, but every attempt to fish has resulted in "there is nothing to catch in the <direction> swamps" and the fishing zone number becoming zero. I've done this both with an aquifer lake and an "outdoor" artificial pond.
However, building a lake and filling it from a cavern lake (closing the access off afterwards) was successful, as pond turtles were caught. I might either have been unlucky or lakes need to be "seeded".