Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2

Author Topic: Some practical suggestions, unrelated to game / simulation issues  (Read 9650 times)

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile

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
« Last Edit: June 04, 2014, 09:24:32 pm by PeridexisErrant »
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

Bumber

  • Bay Watcher
  • REMOVE KOBOLD
    • View Profile
Re: Some small and practical, non-gameplay suggestions
« Reply #1 on: January 15, 2014, 04:59:11 pm »

I support all of these. Particularly number 1.
Logged
Reading his name would trigger it. Thinking of him would trigger it. No other circumstances would trigger it- it was strictly related to the concept of Bill Clinton entering the conscious mind.

THE xTROLL FUR SOCKx RUSE WAS A........... DISTACTION        the carp HAVE the wagon

A wizard has turned you into a wagon. This was inevitable (Y/y)?

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Some small and practical, non-gameplay suggestions
« Reply #2 on: January 16, 2014, 10:05:11 pm »

I'd love to hear similar suggestions from anyone else, and could add them to the top post. 

And another thing from me, which has been a problem for me lately as I work on a script to handle legends exports:  site map names.  I am honestly surprised that this hasn't already been done, and intended to have it in the post from the start but forgot. 

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. 
« Last Edit: January 16, 2014, 10:08:37 pm by PeridexisErrant »
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

Meph

  • Bay Watcher
    • View Profile
    • worldbicyclist
Re: Some small and practical, non-gameplay suggestions
« Reply #3 on: January 21, 2014, 08:11:51 pm »

All of these sound good. +1 from me. :)
Logged
::: ☼Meph Tileset☼☼Map Tileset☼- 32x graphic sets with TWBT :::
::: ☼MASTERWORK DF☼ - A comprehensive mod pack now on Patreon - 250.000+ downloads and counting :::
::: WorldBicyclist.com - Follow my bike tours around the world - 148 countries visited :::

Lielac

  • Bay Watcher
  • [ETHIC:PEDANTRY: PERSONAL_MATTER]
    • View Profile
Re: Some small and practical, non-gameplay suggestions
« Reply #4 on: January 22, 2014, 04:03:58 am »

Hell yes, these all sound awesome.
Logged


Lielac likes adamantine, magnetite, marble, the color olive green, battle axes, cats for their aloofness, dragons for their terrible majesty, women for their beauty, and the Oxford comma for its disambiguating properties. When possible, she prefers to consume pear cider and nectarines. She absolutely detests kobolds.

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Practical suggestions that aren't about gameplay
« Reply #5 on: February 24, 2014, 09:57:38 pm »

Another one, inspired by a series of requests for help/changes to my newb pack: 

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.  I am unaware of whether there are corresponding issues on other operating systems. 

While tapping 'alt' is a simple fix, this issue is particularly problematic for new players who haven't heard of it and should be relatively easy to fix (most trivially, by releasing the key after eg. a 60-second hold regardless of pressed status)
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

Propman

  • Bay Watcher
  • Eh.
    • View Profile
Re: Practical suggestions that aren't about gameplay
« Reply #6 on: February 24, 2014, 11:30:47 pm »

Make tiles respect caste. It seems fun!ny (in the DF sense) that the default ASCII can respect caste differences (like say, a soldier antman as opposed to a worker) yet not let formalized tiles do the same!
Logged
Quote from: from Pathos on April 07, 2010, 08:29:05 pm »
( It was inevitable, really. )

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Practical suggestions that aren't about gameplay
« Reply #7 on: February 25, 2014, 01:01:19 am »

Make tiles respect caste. It seems fun!ny (in the DF sense) that the default ASCII can respect caste differences (like say, a soldier antman as opposed to a worker) yet not let formalized tiles do the same!

While working toward allowing more varied tile/sprite/graphics packs would be awesome, it's sadly not a priority at the moment... and probably falls under gameplay suggestions.  FYI you can vote for that, and many other suggestions, in the Eternal Suggestions Vote - full graphics support is #4. 
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

Loci

  • Bay Watcher
    • View Profile
Re: Practical suggestions that aren't about gameplay
« Reply #8 on: February 28, 2014, 05:13:58 pm »

Those sound like good improvements, and I support all of them. However, I would like to see the saving functionality fixed first, before it is improved. It is very frustrating when DF creates a corrupt save. One known cause in particular, a lack of disk space, should be handled much more gracefully than just pretending everything is fine.

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.  I am unaware of whether there are corresponding issues on other operating systems. 

While tapping 'alt' is a simple fix, this issue is particularly problematic for new players who haven't heard of it and should be relatively easy to fix (most trivially, by releasing the key after eg. a 60-second hold regardless of pressed status)

I support fixing the problem, but I think your "quick solution" is as bad as the bug. I may indeed hold down keys longer than 60 seconds--the shift key while "fast-trading" comes to mind--and I don't want the game arbitrarily deciding to drop my key press. Surely there's some way to detect the actual key state instead of just blindly guessing.
Logged

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Practical suggestions that aren't about gameplay
« Reply #9 on: March 03, 2014, 02:30:09 am »

I support fixing the [alt-tab] problem, but I think your "quick solution" is as bad as the bug. I may indeed hold down keys longer than 60 seconds--the shift key while "fast-trading" comes to mind--and I don't want the game arbitrarily deciding to drop my key press. Surely there's some way to detect the actual key state instead of just blindly guessing.
Yeah, I'm certainly not advocating that this ugly workaround should be implemented when there's an actual solution - as demonstrated by most software.  It was intended solely to illustrate that this should be a small change and not require major re-writes (I hope).

Those sound like good improvements, and I support all of them. However, I would like to see the saving functionality fixed first, before it is improved. It is very frustrating when DF creates a corrupt save. One known cause in particular, a lack of disk space, should be handled much more gracefully than just pretending everything is fine.
Save corruption would definitely be a good thing to fix... I might add this too.  Are there any known causes, beyond insufficient disk space?  If we could list known causes of problems, just dealing with that list would be easier than hunting down more bugs and still be a big step forward - and thus more practical and likely to happen. 
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

Dirst

  • Bay Watcher
  • [EASILY_DISTRA
    • View Profile
Re: Practical suggestions that aren't about gameplay
« Reply #10 on: March 03, 2014, 09:49:58 am »

Those sound like good improvements, and I support all of them. However, I would like to see the saving functionality fixed first, before it is improved. It is very frustrating when DF creates a corrupt save. One known cause in particular, a lack of disk space, should be handled much more gracefully than just pretending everything is fine.
Save corruption would definitely be a good thing to fix... I might add this too.  Are there any known causes, beyond insufficient disk space?  If we could list known causes of problems, just dealing with that list would be easier than hunting down more bugs and still be a big step forward - and thus more practical and likely to happen.
I imagine that predicting a save file's size is tricky, otherwise the fix would be trivial and already released.  Capturing an I/O error isn't that hard, but just what is DF supposed to do with it?  At best it can give you a notice to clean crap off your drive then re-try the save.  And if Toady tries to make the save failsafe, he'd have to leave your old save in place while trying to write the new one, increasing the likelihood of running out of space.  My immediate advice would be to spend $30 on a big USB stick and run the game from there.

The only other save corruption I know of (not that I'm an expert) is The Case of the Missing Minecart.  This is a reported bug in which DF does a bad job of handling an invalid state.  Otherwise, the application seems remarkably well-behaved for an alpha.
Logged
Just got back, updating:
(0.42 & 0.43) The Earth Strikes Back! v2.15 - Pay attention...  It's a mine!  It's-a not yours!
(0.42 & 0.43) Appearance Tweaks v1.03 - Tease those hippies about their pointy ears.
(0.42 & 0.43) Accessibility Utility v1.04 - Console tools to navigate the map

Loci

  • Bay Watcher
    • View Profile
Re: Practical suggestions that aren't about gameplay
« Reply #11 on: March 03, 2014, 08:54:27 pm »

I imagine that predicting a save file's size is tricky, otherwise the fix would be trivial and already released.
Even trivial problems don't fix themselves. Case in point:
Capturing an I/O error isn't that hard, but just what is DF supposed to do with it?  At best it can give you a notice to clean crap off your drive then re-try the save.
Merely notifying the user is indeed much more graceful than failing silently. If the game tells you it can't save, you're unlikely to spend several additional hours playing while generating an entire string of worthless, corrupted saves. Then, for bonus points, when you finally realize your saves are corrupt, the first instinct is to go back through to find the most recent uncorrupted save. If, after doing so, you exit using the standard menu, it gleefully corrupts that save as well. So, comparatively, a crash would be more user-friendly than doing nothing, and, as you point out, handling basic I/O errors isn't exactly complicated code. Posting an error and offering the option to try saving again is only slightly more complex, and it would completely eliminate this particular problem. Saving doesn't have to always succeed, but it should fail gracefully.
Logged

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile

Adding two this time, save issues prompted by discussion and another idea that just came to me while I was poking around in the main menu - init settings could have an interface in the main menu, like persistent settings for most other games.  So: 

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). 
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Some practical suggestions, unrelated to game / simulation issues
« Reply #13 on: June 02, 2014, 12:14:38 am »

Another double-update:  news of an update made me think about a few issues I've had with the legends exports - most are covered by previous ideas, but the incomplete XML wasn't, and when I saw the embark warning idea I realised that it would have been useful for me a few times...

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 equipment 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. 
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

lethosor

  • Bay Watcher
    • View Profile
Re: Some practical suggestions, unrelated to game / simulation issues
« Reply #14 on: June 03, 2014, 03:52:50 pm »

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

When selecting the embark site you currently move within a region with "uhmk", change regions with arrow keys, and resize with "UHMK".  I propose basing the controls on construction placement in fort mode:  move within a region with arrow keys, change regions with shift-arrow keys (as larger movements), and resize with "uhmk".  As an extra improvement, scrolling against the edge of a region could move to the next one over.  While in fort mode a variety of controls is an unavoidable consequence of keeping menu depth reasonable, there is no reason not to make embark controls similar to those the player is about to use after embarking.  This simple change would slightly reduce the learning cliff faced by new players, and also the number of controls for all players to memorise. 
I disagree with using Shift+arrow keys to move between regions, because they're already used to jump 10 region tiles at a time (similar to Shift+arrow keys in fortress mode). Making them move a single region tile would either make moving around large maps more time-consuming than it already is, or introduce another inconsistency by using different keys to jump 10 tiles. I would, however, like umkh to resize the local area (it took me weeks to figure out that Shift was necessary to resize) - maybe wadx could be used to move around the local map (this is what is used to set drawbridge raising directions, and I'm pretty sure there are other thing that use these keys too).

Quote
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.  I am unaware of whether there are corresponding issues on other operating systems.  While tapping 'alt' is a simple fix, this issue is particularly problematic for new players who haven't heard of it and should be relatively easy to fix (most trivially, by releasing the key after eg. a 60-second hold regardless of pressed status)
I was wrong about this being an issue with the SDL library - there is, in fact, a fairly easy way to fix this (see http://www.bay12games.com/dwarves/mantisbt/view.php?id=6455). The fix would probably take more effort than that example in DF, but it could be possible to implement in DF's open-source section (libgraphics).
Quote
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). 
This would actually be fairly straightforward to implement as a DFHack plugin/script, although it would be nice to have something like this in the vanilla game eventually. (It's probably not a high priority on Toady's list, given the time it would take, although we'll have to wait and see what happens during the next release cycle.)

Quote
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. 
Changing it to alt-e can help. This would actually be very easy to implement as a DFHack plugin, or even a tweak - I'll see if I can pull something together in the next day or so.

Edit: Made a simple DFHack tweak to add an embark confirmation.
« Last Edit: June 03, 2014, 05:40:14 pm by lethosor »
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.
Pages: [1] 2