Bay 12 Games Forum

Dwarf Fortress has excellent mod support, and is generally also at fully encapsulating mods within saves.  Third-party tools have recently and massively improved support for encapsulation of mods within save raws.

There's only one thing used by mods that can't be stored on a per-save basis: the speech raws, which are stored in data/speech/.  Moving these to raw/speech/ would be relatively easy, and would make mods completely portable.

Given that I had to hand-code this special case all over the place in the PyLNP launcher mods merge tool, I don't know why I didn't suggest this earlier!

I love the introductory movie - it's a masterpiece, with cinematography that would make James Cameron blush.

When I'm testing something and need to restart DF a number of times, it's a pain in the neck.  As it is, it's faster to kill the program, change the init setting, and restart than to wait. 

Proposal:  add a [skip] option to the intro, where you can press `esc` to go directly to the main menu - giving us the best of both worlds.

Never mind, you just have to hit it a couple of times.  *headdesk*

While a world is being generated, some basic information is displayed about the history so far. 

The Age of $something
Year ###
Hist Figs:  ####
     Dead: ####
Events: #####

It would be reasonably easy to add some more information here, and it would make a long or slow worldgen more interesting to watch.  The microsuggestion which I think has the best effort/outcome ratio is to simply list live as well as dead historical figures, but I though of others while typing

• Using commas to separate long numeric strings makes the magnitude much more readable, which is important.
• Displaying the end year helps give people an idea of how long is left to run, and together with the others informs a decision to abort or not.
• Displaying a count of the living historical figures (though maybe "active" is more precise?) would let you watch population rise and fall.
• Some kind of time series of event density over time would also be cool - and let you jump in at a time of interest. 
  
  • The obvious option is 'events in the year before this one'.  Simple, and if it keeps a list of the past few years also effective.
  • For longer histories, a longer sampling unit might be in order.  Maybe also display per decade after the first decade?  For very long histories, this pattern could be extended to centuries or even millennia
  • I suspect reworking the events display like this would require substantially more work than the other points, but it would also give a nice overview of history in the making

The Age of ###
Year ### / $end_year

Hist Figs:  ##,###
     Live: #,###
     Dead: ##,###

Total Events: ##,###
Events in
   in (year): ###
 in (year-1): ###
   <for past ten years?>

  in 100 - 110: #,###
   in 90 - 100: #,###
    in 80 - 90: #,###
   <for past ten decades?>


Or possibly a simple counter [41,200 / 593,450] items exported. 

Even on small worlds without long history, the xml export can take some time and with DF nonresponsive for the duration it's easy to think it's crashed and abort the whole thing.  Some indication of progress would help a lot. 

See eg. https://www.google.com/search?q=dwarf+fortress+phoebus&tbm=isch

I've been thinking of various small ways to improve the DF experience for some time now, and with a release - and following minor changes - approaching, I thought it might be a good time to collect them in one post. 


1.  Improve the handling of seasonal / annual autosaved backups by setting a buffer length in init options and discarding older saves, and modifying the naming system to sort by region and in chronological order (eg "regionX-YYYYY-Q-backup", Y being year and Q quarter)

Currently there's a simple on/off for backups either seasonal or annual, and they just build up until you delete them manually, cluttering the load screen and folders.  It would be fairly simple to implement an init option to keep a rolling buffer of configurable length, and delete autosaves beyond that age.  This would allow better protection from glitches than the option I currently use with autosave but no backups (as the clutter doesn't seem worth it).  This idea was mentioned on Reddit /r/dwarffortress a while ago and seemed reasonably popular, so I posted it a while ago.  The order of the proposed naming system is reasonably important, to end the mixing of regions and years that occurs in the current system. 


2.  Add an "export all" option to legends mode which exports the basic map and text files, the legends XML file, all the detailed maps, and all available site maps.

Doing this in the current interface can be very tedious, particularly on larger maps or longer histories.  Given that "everything" is a reasonably common selection of exports, this would be a very useful option.  It may also be useful to add options to "export all detailed maps" or "export all site maps" at the top of the appropriate list. 


3.  Expand the command-line worldgen options to include all advanced generation parameters.

This would be an amazing ability to include in various scripting tools, and a godsend to utilities such as PerfectWorld DF, which enable still more control over worldgen.  More generally, it would complete the console worldgen option with feature-parity to the GUI and make detailed exploration of the options more attractive. 


4.  Make the controls for embark area selection consistent with the analogous construction placement system in fort mode. 

Suggestion replaced by #11 and #12 following useful feedback and discussion further down the thread.


5.  Add the source region and year to the filename of site map exports, to prevent overwriting and allow better comparisons.

Presently, all site maps - no matter the region - are named simply 'site-map_#', with '#' being the site identifier.  This is already a problem, causing (complete) exports from each region to overwrite each other, and will be worse when more such maps will be available (and more interesting!).  Adding the region to the filename would also allow far better control in scripted processing of exports, particularly if more than one region has been exported.  I would suggest following a similar pattern to other maps, eg 'site-map_[site#]_region[,#]_[year#]'.  With sites able to change over time, this could allow comparisons of maps through time and generally be completely awesome in helping expose the new world and site level simulation.  This is a small issue and easily fixed, in which site maps are lagging behind all the other exported data available from Legends mode.  Given the very exciting possibilities the new version presents for this often-underappreciated DF experience, this would be a good time to fix it. 


6. Recognise that the 'alt' key is not being held after alt-tabbing away and returning.

There is a known issue on Windows where if the player uses alt-tab to change focus and later returns to DF, the game assumes that he alt key is still being held and parses keybindings accordingly.  This can be fixed by tapping the alt key, at which point the key release is noticed.  While tapping 'alt' is a simple fix, this issue is particularly problematic for new players who haven't heard of it.  This potential fix has been drawn to my attention, simply clearing held modifier keys when the window focus changes. 


7. Improve save-game and export failure behaviour.

Save file corruption is rare, but when it happens can be extremely frustrating.  While reducing it's frequency still further would be lovely, reducing the damage it does should be a priority - if a save fails the player should be notified, perhaps based on capture of I/O errors.  It may also be possible to avoid errors due to insufficient disk space, which are a common cause of issues (source 1, source 2). A related issue is that exports may fail if DF lacks write permisions, which could also affect saves - both are mainly a problem because the failure is silent. 


8. Add an 'settings' item to the main menu, for an interface to change the init options.

An interface similar to that used for basic worldgen would be a good fit for the init and d_init settings, where there is a list of settings with a few settings each.  Having an in-program way to adjust these settings makes them much more accessible to many players - it's historically been a selling point of the Lazy Newb Pack that there's a simple way to change settings.  It may be appropriate to keep them as seperate sets of settings, in which case 'init settings' and 'd_init settings' would be self-explanatory based on existing knowledge and documentation.  At present, the only settings menu is an off-list prompt to press 'esc' for options, which does not include persistent settings beyond the keybindings.  Bringing these options into the main program would make the experience more coherent and facilitate rapid switching (such as between forts). 


9.  Add an init option to confirm embark.

Inspiration thread.  Because sometimes hitting 'e' by accident can be very frustrating.  Currently we have an init option to always confirm embark site selection, and even if disabled you sometimes get the warning (eg for salt water).  Actually embarking is arguably a bigger deal than choosing a site, and having the option to set a confirmation would be great (like for abandoning a fort).  It would also be possible to set conditions in which the warning would pop up regardless, most obviously if no equiptment was selected or if less than 20% of embark points have been spent. 


10. Prioritize completion of the XML legends export.

Even in 0.34.11, there are some gaps in the exported legends.  With the upcoming version generating a significantly richer world, it would be a shame not to make everything available for story construction in other programs. 


11.  Make moving the embark area more intuitive.

Currently, the embark area is moved within a region with 'uhmk', changed between regions with arrow keys, and in ten-region jumps with shift-arrows.  Only the first of these can be changed to different keybindings in "interface.txt"; and at the edge or a region there is a hard limit to embark movement.  I propose a set of related small changes: 

1.  Allow all movement controls to be set by interface.txt, so that alternative control schemes are possible
2.  When the embark area is against the edge of a region and moved in that direction, move to the corresponding edge of the next region.  This will work well once the artificial edges are removed, and significantly reduces the preception of them.
3.  Change the keys used for movement to arrows for moving an embark by one tile, shift-arrows to move to the next region, and alt-shift-arrows (or ctrl-shift, etc) to skip ten regions.  This maintains the 'modifiers move further' paradigm while unifying the movement modes. 


12.  Make resizing the embark area exactly like resizing a construction in Fortress mode.

Currently the embark area is resized with 'UHMK', and uses the SW corner as a reference point (ie size changes only affect the north or east edge).  This is close to the Fort mode system of 'uhmk' to resize (allowed following #11), and taking the center as reference point; removing these differences should be fairly easy.  Reducing the number of UI paradigms for players to learn and remember is always a good thing, and in this specific case it will also teach new players the control scheme for constructions. 


Edit:  Added point 5, 2014-01-17.
Edit:  Added point 6, 2014-02-25. 
Edit:  Added points 7 and 8, formatting, 2014-03-05
Edit:  Added points 9 and 10, 2014-06-02. 
Edit:  Split/removed point 4, see new #11 and #12 (2014-06-05); added a useful solution link to #6

Currently there's a simple on/off for backups either seasonal or annual, and they just build up until you delete them manually - using up storage space and cluttering the load screen. 

It would be fairly simple to implement an init option to keep a rolling buffer of configurable length, and delete autosaves beyond that age.  This would allow better protection from glitches - or mistakes with levers - than the option I currently use with autosave but no backups. 

This idea was mentioned on Reddit /r/dwarffortress and seemed reasonably popular, so I thought I'd post it here.  Thoughts?

Edit:  The naming convention for seasonal backups could also be modified so that saves are listed in chronological order, which is most easily accomplished as "regionX-YYY(...)-Season-(other)", with as many years as required.  If the region is not kept as the first part, regions with histories of the same length will be mixed.