Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PeridexisErrant]

I've been thinking about the DF interface for a while now, and plenty of new players have come to me with complaints or suggestions for things to fix.  This thread is to collect the most important and most realistic - things I think can and should be done as part of the 0.40.xx release series. 


1.  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.

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.  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 - especially as it helps developers and users of third-party tools. 


2.  Allow command-line worldgen to substitute an arbitrary file for world_gen.txt

The command-line worldgen option is amazing powerful, and also barely used.  More people might take it up if it didn't require modifying world_gen.txt to do the most interesting things.  I therefore suggest allowing, as an alternative to the param name flag, passing the path to a file which contains exactly one param set.  Scripts could then use temporary files to avoid having to handle world_gen.txt and risk deleting something.


3.  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 controls across embarkation and fortress mods. 


4.  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, especially the above frees up the lower-case controls. 


5. Prioritize completion of the XML legends export.

Even in 0.34.11, there were gaps in the exported legends.  With 0.40 generating a significantly richer world, it would be a shame not to make more of the history available for story construction in other programs. 

[Bumber]

This thread feels very familiar somehow.

[lethosor]

Regarding #2, wouldn't it be possible to add a custom profile to world_gen.txt and use that from the command line?

[PeridexisErrant]

This thread feels very familiar somehow.

Yep.  But given that the linked thread was posted (and last updated!) before 40.01, and some of the suggestions have been implemented, I thought when I saw the "consider making a new thread" message I might as well. 

Regarding #2, wouldn't it be possible to add a custom profile to world_gen.txt and use that from the command line?

Probably, in the same way that exportlegends kinda covers #1 - it could be a decent workaround, but upgrading the basic feature would be better for reliability and ease of use.

[GavJ]

If this is really easy stuff to do, then sure whatever, but in case it is not, then I would like to see more justification for why Toady should spend time on it rather than the handful of modders who would actually need to work with any of this stuff (auto interface scripting is a lot more esoteric than, say, putting tags in the raws).  As just one representative example:

who knows what we might find when we can leave exploratory scripts running? 

These should be pretty trivial to make as is by just hardcoding knowledge of how many key presses to get to each advanced parameter. Is that tedious? Yes. But it's tedious on the modder's end, instead of Toady's, allowing him to focus on features more people will benefit from. (and not give in to the soul crushing nature of I/O stuff). If people can make bots for auto-fishing in a 3D online MMORPG that is actively hunting for cheaters, then a parameter searching world gen thing on a fixed options ASCII game should be pretty doable...

What exactly are you hoping to apply this to? Do these 3rd party projects exist yet? How many and what are they?



The newbie resizing consistency stuff seems like all great ideas no matter what though.

[PeridexisErrant]

If this is really easy stuff to do, then sure whatever, but in case it is not, then I would like to see more justification for why Toady should spend time on it rather than the handful of modders who would actually need to work with any of this stuff (auto interface scripting is a lot more esoteric than, say, putting tags in the raws).  As just one representative example:

who knows what we might find when we can leave exploratory scripts running? 

These should be pretty trivial to make as is by just hardcoding knowledge of how many key presses to get to each advanced parameter.

What exactly are you hoping to apply this to? Do these 3rd party projects exist yet? How many and what are they?  The newbie resizing consistency stuff seems like all great ideas no matter what though.

The embark screen changes would take a moderate amount of work, but make it much more intuitive than at present. 

The legends export-all options should be trivial, but it makes it a lot easier for anyone who wants to use external tools.  Improving the coverage of the legends XML is for the same reason:  there are a lot of people who use DF to generate settings for other reasons, and never play one of the 'game' modes.  If it's easier to export all the information, more people are going to appreciate the worldbuilding process - and there's more incentive to develop interesting utilities which build on this.  (see:  Legends Viewer, Dorven Realms (minecraft map maker), World Viewer, DFMaps, map processing scripts, etc.)

SDL / alt-key fixes:  it seems like a minor issue, but it's the single most common problem I troubleshoot for newbies.  This commit demonstrates that it's possible and even fairly easy to fix - the problem is just that Toady doesn't like going back to the graphics code.  It's not the kind of thing I would ask unless it really was important; and it could probably be fixed by Baughn or someone if that would work better than Toady digging in directly.

Command-line worldgen:  at present, there isn't much that takes advantage of this - because in it's current state it's not very powerful and thus not very useful.  The closest is PerfectWorld, which can take real maps and convert them into ultra-detailed advanced worldgen parameters - or you can paint you own map instead.  If the CLI was more powerful, it could directly call worldgen when you finished - and inform you of failure to allow quick tweaks.  Or someone could generate a thousand worlds with varying parameters, to test the relationships between civilisations under various conditions.  Basically it would very interesting to see what's possible, and given that DF can already take these parameters from a file it shouldn't be too hard to upgrade the command line interface.

[GavJ]

Those are all seemingly quite reasonable, except MAYBE the command line thing. It might be super tedious and time consuming to add each thing to the command line. If not, then I agree.

Regardless, in the meantime, I still suggest if you're interested in that, you just make a bot to do it using the regular human interface. Direct keyboard input and pixel peeping. I used to make bots all the time for stuff like this, e.g. the game Puzzle Pirates -- most puzzles were keyboard controllable, and pixels are easy to interpret in grid graphics. Was pretty trivial even in a more complex game to make bots that read the screen and put in appropriate input. And in this case, you don't even have to worry about security staff catching you. Most of my effort was put into things like exploiting mac loopholes that don't inform the program whether it's real mouse input or not, and adding random noise to mouse movements to mimic human wrists, etc. etc. that you don't have to worry about here.

[lethosor]

Command-line worldgen:  at present, there isn't much that takes advantage of this - because in it's current state it's not very powerful and thus not very useful.  The closest is PerfectWorld, which can take real maps and convert them into ultra-detailed advanced worldgen parameters - or you can paint you own map instead.  If the CLI was more powerful, it could directly call worldgen when you finished - and inform you of failure to allow quick tweaks.  Or someone could generate a thousand worlds with varying parameters, to test the relationships between civilisations under various conditions.  Basically it would very interesting to see what's possible, and given that DF can already take these parameters from a file it shouldn't be too hard to upgrade the command line interface.

If PerfectWorld can generate usable worldgen parameters, it should be trivial to add them to world_gen.txt and generate a world with those parameters from the command line (automatically, that is). Also, there are different command-line length limits on different platforms (8191 characters on recent versions of Windows, if I understand it correctly; the limit on Unix-like systems is higher, and there are ways to pass arguments from a file, for instance, that can bypass these limits). It may be simpler to allow DF to read worldgen params from a file other than world_gen.txt, which would avoid the need for utilities to modify world_gen.txt, but I think passing every option from the command line would quickly become unwieldy (particularly for worlds like this).

[PeridexisErrant]

It may be simpler to allow DF to read worldgen params from a file other than world_gen.txt, which would avoid the need for utilities to modify world_gen.txt, but I think passing every option from the command line would quickly become unwieldy (particularly for worlds like this).

That makes a lot of sense actually.  Maybe simply expand the interface a little - allow a name to be supplied for a custom param set in world_gen.txt, or path to a file containing exactly one param set.  Then it's trivial to point it at a temporary file, and cleaning up without damaging anything is much easier.

[lethosor]

You can already specify specify a parameter set in world_gen.txt:

Dwarf Fortress currently offers one command line option, a world generator, suggested by genmac.  You can use it as follows:

FORMAT:   "Dwarf Fortress.exe" -gen <id number> <seed> <world gen param title>
EXAMPLE:   "Dwarf Fortress.exe" -gen 1 3498 "MEDIUM ISLAND"
EXAMPLE:   "Dwarf Fortress.exe" -gen 2 RANDOM CUSTOM6

I agree that specifying a temporary file would be cleaner, though.

[PeridexisErrant]

Yep, the new bit would be specifying a tempfile as an alternative to a param set.

[lethosor]

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

There is a known issue where if the player uses alt-tab to change focus and later returns to DF, the game assumes that the 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. 

According to research in the DFHack thread, this is actually a problem with the way DFHack handles keybindings. DF itself actually appears to contain a workaround to handle modifier keys correctly.

[PeridexisErrant]

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

There is a known issue where if the player uses alt-tab to change focus and later returns to DF, the game assumes that the 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. 

According to research in the DFHack thread, this is actually a problem with the way DFHack handles keybindings. DF itself actually appears to contain a workaround to handle modifier keys correctly.

Source?  This sounds like the kind of thing that should be on the DFHack issue tracker!

[lethosor]

It should be simple to verify:
1. Enter the (b)uild menu
2. Alt-Tab out of DF, then Alt-Tab back
3. Press "s". (This should select the "Statue" option)
Then repeat steps 2-3 with a DFHack keybinding bound to Alt-S in the build menu context (or globally).
I've opened an issue on the DFHack issue tracker, but please let me know if you can reproduce this in vanilla DF (i.e. without DFHack).

[Abadrausar]

3.  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 controls across embarkation and fortress mods. 


4.  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, especially the above frees up the lower-case controls. 

Any prepacked keybinding change proposed in the starter pack should take the responsability of ensuring that the proposed change does not break in any way the internal Dwarf Fortress macro system or the Quickfort utility that is also distributed with the Starter Pack.

At a minimum if that can not be done the user should be informed that any arbitrary change in the keybindings could break the macro system and Quickfort.

Any keybinding change that invalidates the possibility of using macro designations well developped by others users is probably a non worthy change.