Bay 12 Games Forum

I've never tried any such thing... However, I am reasonably certain that DF saves are compatible across OSes (uh, except for the compressed mode that is known to depend on how your OS handles its bits and is in that regard essentially broken) because people put them up on the DFFD without any mention that "this save is for Linux"... plus I can't imagine with all the succession games that I wouldn't have heard loud complaints at least once about how the Linux people are excluded or something. No, all I hear is the trouble of getting DFHack and the Lazy Newb Pack working on other OSes. The game itself seems to be pretty agnostic unless you want to play with the "supposed to work but might crash your computer because graphics drivers lie" sorts of graphical mode settings.

Would this shortcut be the sort of link that, to a program using the filesystem, is treated the same as if it were the folder it points to?

It might be worth engaging in some fourth-wall-disregarding !!science!! to find answers to these questions.

Have you, uh, been to the "Community Games and Stories" section of these forums? I mean, not that the average thread there is published novel quality, but as a basic answer to the theoretical question... Or look up Boatmurdered on the wiki. I think you'll wind up in most of the same places whichever end you start at (Boatmurdered is then, the forum section is now).

Alternatively, for shorter stories, there's this site. There are some epics in their own right on there.

If you're using water, and if you have a walkable area around the "lake" or moat on the z-level above where the water should wind up, you should be able to designate a pond zone around it and have the dwarves fill it up with water, if I'm not mistaken.

I'd personally like a Cave Story mod. Kobolds already remind me of mimigas. Some people already build fortresses in the sky, and if you turn off caveins theoretically you could suspend them up there entirely. You can also theoretically breed dragons, although I've heard DF dragons can't fly (so, mod them into the sky dragons... in addition to flying, see if you can make them take a long time to hatch from their eggs, and make it so your civ is likely to start with tame ones), and it's conceivable for old witch women to herd packs of dogs in the middle of the desert. If we could figure out how to make a type of red flower and an artifact crown give off a kobold/mimiga-enraging syndrome, we'd be nine tenths there. Also make more of the races playable... Make the humans all researchers... Change the demons to be little angry cupids... Replace elves, dwarves and goblins with the funky green guys who refuse to speak except cryptically and robotic Soldiers From the Surface...

In fact, you could call the mod that. "Soldiers From the Surface". Maybe subtitle it "Fortress Story".

Oh yeah, and name all titans/megabeasts/FBs Balrog, but replace their available body forms with "lunchbox" and "toaster".

Thing 1: There's a difference between an easier world and an easier embark. (People have been discussing elements of this, but it's important to know in order to understand their contributions.) Generating a world can rig the majority of the area easier or harder, but most worlds generated with the "basic world generation" mode have a good variety of embarks to look for. That's typically where the advice about what to search for and avoid comes in.

Thing 2: There's both a world generation parameter set and a pseudo-random number generator seed. The parameter set limits and influences the procedure that generates the world; the seed is where the "random" numbers start and therefore determines the incidentals of how the world happens to be laid out. This means that if the world generation procedure is given both the same parameter set and the same seed it will produce the same world, since the sequence of pseudo-random numbers is determinate starting from the same number. It also means that changing the parameter set and using the same seed is usually not practically different from changing it and using a different seed: because the way the procedure uses the sequence of "random" numbers is different if the parameter set is different. However, you can change the seed to get different worlds with the same parameter set and hence the same general characteristics (or at least, the same likely general characteristics within the same limits), whereas changing the parameter set itself will not only get you a completely different world but one with different characteristics (whether drastically or subtly).

Thing 3: The difference between an incomplete feature or feature set and a bugged one can be subtle, and by extension so can the difference between completing a feature or feature set and fixing it. It doesn't matter so much if the developer really is trying to meet people's needs or expectations -- or at least his own high standards of worthwhileness and not just some sellability factor. Speaking from experience, you will, in contrast, find other people out there who will try to spin obvious bugs -- things where the functionality's logic literally cannot produce the result that is the stated purpose of the feature -- as "being built to the design" such that "if you want it changed that will be an enhancement that will cost an extra [insert large number here] dollars." And if they're really bad, you will never actually get to see the design you're being chained to or have any other proof that they're not making it up off the top of their heads. That's one reason savvy contract-writers have to be so savvy: they've got to ensure that the design is itself required to actually be something that meets the requirements of the customer and that if it doesn't the developer can't hide behind it. Similarly, you need clear designs and good quality assurance testing if you're going to separate development and support internal to an organization, otherwise support is left to pick up the ball whenever development doesn't do as well as they should and inevitably they become better experts at it than the people who actually have power/authorization to improve the thing.

Of course, you could argue that there's a note of similarity to this in Toady going off and developing whatever currently interests him instead of fixing whatever the current biggest bugs are, but there are crucial differences: It's a game and not an application a business depends on, Toady's not requiring us to pay him for bug fixes or for the game in the first place, Toady doesn't pretend these issues aren't issues (nevermind whether they're bugs, which doesn't matter so much if you agree they're issues and should be improved without extra cost), and perhaps most importantly Toady is focused on making the game well for its own sake.

All that was probably more than needed to be said, but there you have it nonetheless.

If he's not going to use the vampire, it makes more sense to kill it with any method or even to wall it in an empty room and forget it than to worry about keeping it sane while it's imprisoned; keeping it sane is only a factor if he does want it to be a lever-puller or something in that line. Also note that you can dump in dwarven wine (or whatever swill the elves hippies bring if you're feeling cruel) if you're going to dump in clothing or anything through a dropchute, so alcohol deprivation doesn't have to be a factor if the player is willing to manually supply the vampire.

@ImagoDeo: Note that it is just as conceivable to make your vampire a solitary craftsdwarf or worker of some sort, who has raw materials dumped into his room with the drink and fresh clothes, works them into something worth having (or trading) at a workshop in his room, then himself dumps the products down another dropchute back to the rest of the fortress. You could get a real starving artist thing going, although it'd be completely manual. May be worth it if he has any good skills already.

Otherwise, if you're not up to manually supplying him via dropchutes, it's not like you have to make every dwarf useful... I mean look at your average Noble.

Its possible for a particular civ to only be able to access an embark side from one direction.

As stated before, everything from the civ is coming from the side with the point of access to the depot.

If your embark is bisected by a river that was liquid at the moment of embark, wagons will only arrive from the side of the river that your wagon started on.

This kind of wagon access is not affected by the relative location of your civ.

Hmm, now that's a possibility, depending on the exact logic... What I have is like this:
R = big river
r = small river
. = earth
W = embark wagon
D = depot access

.....
.rrrr
.r...
.rW.D
RRRRR
.....Is it possible the game is only considering one of the rivers and has decided that "the correct side" is the North side alone?

Unless the answer's a sure no, this definitely makes it worth seeing if the wagon will come from the far side of the small river if nothing else (the big river's a little difficult to build across, although I guess I could if I had to)... but by now I've got goblins ambushing me and slaughtering my dwarves, so a test depot for this would be tricky... well, I'll see what I can do.