Bay 12 Games Forum

Even if the warning can't be toned down / altered for this particular forum - especially in that case, actually - a note at the top of the forum that thread necromancy is the way to go if you have an actual contribution to make could be a good idea.

That same warning crops up elsewhere, and carries the connotation "don't post here unless you've got a really pressing reason to do so". Assuming that forum newcomers will see that same message and get the forum-specific subtext of "and contributing to the suggestion is a pressing reason" isn't exactly fair to them.

And to argue it from another direction - what would it hurt? Tangential thread necromancy may still be less of a nuisance to sort through than the same idea being brought up 10 times because the original thread(s) went stale.

All this is true, but there might ONLY be one region tile's worth of soil. Knowing where it is can be a great help to setting up your initial farms.

I think the main advantage to training pump operator to legendary before drafting is the additional skill gains. A few levels in toughness especially can help prevent tragedy when the dwarves get to sparring. Maybe not eliminate, but reduce, at least.

This will of course become less useful in the next version with the overhauls to sparring.

That said: very much in agreement with notification of legendary skills. Especially since there's only going to be one champion per fort in the new version, generalizing it to any skill, military or civilian, that hits legendary would be welcome.

Granted, what's really being signalled in the case of champions is a profession change; honestly the skill would be more useful to me.

Arrow slits aren't straight holes cut in the channel, AFAIK; they're tapered, spreading out on one side. Sure, someone who gets right up to it can still fire through them, but they might not be able to do so as well as people standing on the correct side.

The argument that this only does so much to someone right up against the slit would be an argument for multiplicative rather than additive benefit/penalty. Then it's up to the defenders to keep the enemy from GETTING right up to the slit.

A trench makes sense for outer walls, but somewhat less sense for a gatehouse(and to the best of my knowledge, trapping the enemy between two portcullis with the defenders able to shoot through arrow slits and murder holes was not uncommon, though I can't recall the name for this structure offhand).

What I was getting at would be a much more complicated function than the difference between fullscreen and windowed: it would be using different tilepages for different portions of the screen. Perhaps the same logic that goes into switching between windowed and fullscreen modes could be used to change tilepages on the fly in general - this would be a boon for trying out new tilesets, even if the changes are not persistent without going in and manually editing the init.txt.

I don't run DF in fullscreen(I don't like the effort my system goes through to switch graphic modes, and I like having utilities visible as I play), so a way to make this work in windowed mode, not just fullscreen, would be appreciated.

But yeah, so would opening up the graphics in general; allowing graphics for not just CREATURE:{CREATURENAME}, but e.g. OBJECT:BED. Maybe even trees, if someone is feeling really ambitious. And allowing dyes to be shown in their full colour, for that matter. Or just opening colours into RGB values in general; that might be better and/or easier than handling dyes as a special case.

Being able to designate an area for digging according to a set pattern would be nice. This would allow for not only exploratory mining(you set the corners of the zone, ideally on all three dimensions, and the "anchor" point, and it fills in the little passageways for you based on a tiled pattern), but also living quarters, workshop spaces, and the like. The ideal such system would include all mining-related designations - digging, stairs, ramps, channels.

I'm not sure how well I'm explaining this. Basically, you could define a tileable pattern of some sort. This pattern would have a base level, and maybe a few options for vertical levels(top, bottom, interior). You would also set where, on the periphery of the base level, the tile is anchored, and, if appropriate(mostly at corners), which direction the "anchor" passageway goes. Then you go to dig by template; you set the region you want to dig by x, y, and z, you set the anchor point, you say which direction the anchor passage goes, and bingo, the game fills in that region, repeating the pattern if necessary, going up and down as need be. This would GREATLY save on labour for, say, digging diagonal passages for that particular flavour of exploratory mining, which otherwise needs the player to press "move on diagonal, enter, enter" for every single tile and get carpal tunnel(augh, the pun) repetitive strain injury.

Macros are well and good, but for mass designation they are inefficient, and somewhat limited in scope. This would be a refinement of the same general idea, but a little more scalable.

Rather than make up a whole new thread for it when it seems relevant to this one - might it be worthwhile to, at the top of this forum where the guidelines are posted, say under the "search for existing thread", note that thread necromancy is not only permitted but encouraged/expected in this forum? I've seen a number of times that people are reluctant to revive old threads - and in many forums it is considered bad etiquette to do so - but, hell, I've seen Toady himself do it, what more confirmation could you ask for that it's the way to go here?

Putting it right on the forum's index page might encourage at least a few more people to find and resurrect an existing thread rather than making a new one - it is a rather nonstandard approach to things, after all, so it's understandable that people would go with the usual and let dead threads lie. Without specific examples to the contrary, I can imagine a lot of people would interpret "Search for an existing thread" as implying that the existing thread be recently active.