Bay 12 Games Forum

It might be useful to add a description of the overall DF development process to the Dev page, as well as using the Arc concept in the development description. The purpose of this would be to help people new to DF to understand the process used for DF development to temper their expectations.

In order to keep the things most people want most of the time closer to the top, I'd suggest a link in the Overview section to a new section at the bottom of the page.

The info I'd like to see is roughly:
- DF is developed in Arcs, where an Arc is a development cycle mainly focusing on the development of a single area of the game.
- DF development is subject to change, with more or less sudden additions of things previously intended for later development.
- An Arc takes somewhere between 1 and 6 years from start to finish.
- An Arc consists of the following broad phases:
  - Development: DF is developed without any releases for the majority of the Arc. Dev notes provide some insight in what's happening.
  - First release and emergency bug fixing of crash bugs, typically lasting for a number of weeks.
  - Bug fixing and further development. This phase includes fixing of less serious bugs, with a primary focus on those introduced with the new contents. It also contains balancing of the new features, as well as addition of more contents to the features (which may be fairly bare bones at the first release). This phase can be fairly long, depending on how much additions it contains. This can result in semi major releases with their emergency bug fixing releases.
  - End phase. This phase tends to be rather short, typically weeks, and typically fixes general bugs as well as bugs and balancing of the Arc's contents.
  - The beginning of a new Arc, with a long development phase...

It would be useful if this section also explained how Premium releases would be handled, as automatic pushing out of rather unstable/unbalanced first releases to everyone through the normal auto update process isn't desirable. It might take time to decide on such a process, though.

Another useful piece of information would be to describe how DF development will work with respect to Premium releases, once that's been decided upon. My suggestion would be to state that the aim for the development phase of Arcs is to see small bug fix releases for the last Arc approximately once per month (or some other suitable interval) to show that the game is supported and in development (this would require maintaining parallel development environment for both the current and the previous arc).
A further suggestion is to use the Premium Arc to set this system up and trim it so it's working smoothly once the Big Wait starts.

I'd also like the "Upcoming Development" section to make use of the Arc concept to state that the current (as the time of this writing) Arc is the Villains one, the next one will be a small Premium one (which currently is completely missing from the Dev Page, which isn't surprising since the announcement was made after the page was last updated), and the one after that will be the Myth & Magic one. The Arc beyond that is not set in stone (unless Starting Scenarios has been set), but candidates are ...

Something that's currently missing from the Dev Page regarding the Myth & Magic Arc is all the infrastructure work it requires, as well as an explanation that this will result in a Big Wait and save game incompatibility. Adding the infrastructure items to the page might help improve understanding of why it will take time, and also provides items to tick off to show progress.

Not a DF suggestion, but rather a minor DF development process one.

A time stamp (primarily the date) updated when the dev page is updated would make it easy to see at a glance that the page has been updated (or not) recently when checking it, rather than having to scour it and determine that something does look like it has changed (or not, depending on how often you check it). Even better if the page could recover the time stamp of its latest change and display it, as that wouldn't require any manual effort (and remembering to do it) once set up.

There's currently a bug fest surrounding sending squads out of the fortress on missions, with severe crashes, equipment allocation trouble (including, I believe, allocation of the same piece of equipment to multiple dorfs). In addition to that, dorfs returning drop equipment left, right, and center, and room allocations are removed as squad members leave. I suspect the same issues occur for messengers.

I'd suggest squad members offsite should be retained in the fortress in the "inactive" state (like inbound performance troupe members, merchants, etc.) while on a mission, and be removed from the fortress only when they're reported dead or become members of another entity (i.e. occupy a site or are reported to side with an entity they've been imprisoned by, if that happens).

This ought to mean that offsite fortress members would retain their rooms and private/squad equipment, and would just keep those when returning (as well as not being considered new citizens). Once units are removed from the fortress, their equipment should be either confiscated by the fortress (as if they'd died), or removed from the fortress (if the items were carried offsite). Squad allocated equipment would likewise either be returned to the fortress if it remains locally (and, I guess, still allocated to the squad position), or removed from the fortress and squad if offsite.

Occupying squad members returned by a messenger as "workers" would be "new" members of the fortress (as opposed to the messenger, who'd just return), as they'd have been removed from the fortress when they occupied the site (unless there's a new mission state where squads may be on occupation duty, while still members of the fortress, as I think I've seen suggested somewhere, in which they'd just return when the squad is recalled), and their equipment would be "new" equipment from the fortress perspective (again, as it would have been removed when they became members of the site).

The purpose of this suggestion is to make it easier to manage offsite assets for the player (room allocation, returning squad members ought to retain their equipment and only drop things as part of the upgrading cycle, etc.), as well as to possibly provide an easier way to address some of the bugs associated with missions.

1. I eliminated the human vampire diplomat without its guards reacting. The year after no caravan showed up, and the year after that gobbo invaders blocked the humies. The year after that "the enemy has come and laying siege to to fortress". Given what I've read about people deliberately trying to goad elves into war and failing, I'm a bit surprised that a single incident results in war (the caravan left normally with a tidy profit as well). Is this expected, and have the rules changed?

2. Are there any rules of thumb for how large a force you need to conquer a site? My preference would be to do so without a fight (i.e. by being sufficiently much stronger that they yield when demanded), but how many inhabitants would you expect a squad of axe lords to defeat (assuming the X inhabitants aren't backed up by giant animals, trolls, and the like)? Also, does it scale linearly, i.e. 2 squads beating twice the number as one squad)?

3. Is it possible to whittle down a 10000 gobbo dark tower (with its support of ogres, etc.) with repeated raids so the site can be conquered once cut down to size? I'm looking for what it takes to do so, not merely a "Yes" (although a "No" would answer the question, of course).

I just had a quester demand that I'd hand over "On The Trees" to him for delivery to a character, and the quester claimed to have started a few months ago. However, exported Legends info (viewed with Legends Viewer) shows that the quest giver died towards the end of the previous year, and the quester demand happened after the 20:th of the 12:th, which means the quest giver has been dead for over a year. I suspect it just a bug, rather than a deliberately lying quester, but regardless, I refused the demand (a liar doesn't deserve it, and a dead quest giver has no use for it).

I've had several cases where I've tried to melt designate piles of gobbo junk left after execution, and d-b-m fails to designate some things, while managing to get most of them. The ones it's failed on have been copper armor worn to the 'x' or 'X' level, but I've seen some that were designated correctly. The reason it's only copper is that this is the only armor grade metal the gobbos bring.
Manual melt designation of the missed items works.

Has anyone else encountered this?

But did get one just now. I pitted an arriving FB against a contained one. Both had "deadly dust", but the new arrival apparently had a sleep inducing one, as it put the other FB to sleep with it ("very drowsy" on the wounds screen, and "Z" above it when the game was paused). The victor had put a Jabberer to sleep before that, and a Reacher after taking care of its competitor.

The reason for my question is that I have a bit of reanimating biome on my embark, and I have an almost unkillable black bronze FB that seems to ignore the reanimate critters resulting from its rampaging, including at least one reanimated FB.