Print

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

[PeridexisErrant]

Nice, I'll add a link for the SDL bit.  For the others - while dfhack is awesome, I'd prefer to have the feature in vanilla if possible!  Is the tweak available or going into r5?

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

Good point.  However, the last thing I want to do is introduce more control schemes, even if they're used elsewhere.  I think we agree on resizing with 'uhmk' for consistency and simplicity, and ditching 'UHMK' entirely. 

For moving you embark selection, how about: 
-  arrow keys move it within embark region, (bonus) plus rollover to the next embark region when moved against an edge
-  shift-arrows move to next embark region, keeping position within embark region
-  control-shift-arrows move ten embark regions

It's not exactly the same as movement in other modes, but it's clear and simple for beginners - use arrow keys to move, and more modifiers move faster; resizing works like fort mode. 

This gets us down to a single cross-mode paradigm for resizing, and a simple system for movement which has similarities to other modes.  I think in this case it's worth changing the exact relationship of 'shift' moving more for the sake of on-screen simplicity. 

[Bumber]

For moving you embark selection, how about: 
-  arrow keys move it within embark region, (bonus) plus rollover to the next embark region when moved against an edge
-  shift-arrows move to next embark region, keeping position within embark region
-  control-shift-arrows move ten embark regions

Well, if you're going to be using ctrl, might as well just swap that with shift.

[lethosor]

For moving you embark selection, how about: 
-  arrow keys move it within embark region, (bonus) plus rollover to the next embark region when moved against an edge
-  shift-arrows move to next embark region, keeping position within embark region
-  control-shift-arrows move ten embark regions

I like this, although it would take a little time to adjust to. Personally, I'd prefer Alt instead of Ctrl, but since it's easily configurable it doesn't matter too much what the defaults are.

Well, if you're going to be using ctrl, might as well just swap that with shift.

Why? Using Shift+arrow keys is pretty much standard for moving in larger increments in DF. (Also, some OS's use Ctrl+Arrow keys for OS-specific functions).

[sal880612m]

Seemed more of an instead of Ctrl-Shft-Arrow why not just go Ctrl-Arrow as it is easier to type. I imagine Alt-arrow would work just as well.

[Cobbler89]

Here's a good one: Separate text font and graphical font so as to allow graphics packs to override letters more completely with even less effect than currently on text that's still supposed to be text. Currently implemented as a plugin, though I don't know how much of the rendering mode limitations they've resolved.

Similarly but separately, I really, really wish barrels and screw pumps could be given different tiles/characters/whatever. One of the main reasons I stick to the vanilla text set instead of using graphics packs is that I can no longer see barrels or screw pumps based on context when they both actually look like barrels. (The other reasons are that I want at least some experience with the vanilla text set for canonicity's sake, and that text is generally easier to make clear at small sizes and smaller sizes let me see more of the fort/land at once; niether of these, however, is exclusive like the immersion-breaking annoyance of screw pumps under the appearance of barrels.)

[PeridexisErrant]

<graphics improvements>

I agree with all of this, but I'm not going to add them to this thread - it's a lot of work that Toady has said he doesn't want to do right now, and he does know people want it!

For moving you embark selection, how about: 
-  arrow keys move it within embark region, (bonus) plus rollover to the next embark region when moved against an edge
-  shift-arrows move to next embark region, keeping position within embark region
-  control-shift-arrows move ten embark regions

I like this, although it would take a little time to adjust to. Personally, I'd prefer Alt instead of Ctrl, but since it's easily configurable it doesn't matter too much what the defaults are.

Well, if you're going to be using ctrl, might as well just swap that with shift.

Why? Using Shift+arrow keys is pretty much standard for moving in larger increments in DF. (Also, some OS's use Ctrl+Arrow keys for OS-specific functions).

Yeah, if it's configurable it doesn't matter that much what keys are used to move-ten-regions.  Making it configurable is up to Toady!  With the OS-issue alt-shift may be better, but details don't matter too much for that bit. 

I also just had a loot through interface.txt, and found that the keys to move and resize the embark are already configurable: 

Spoiler: interface.txt (click to show/hide)

Code: (vanilla interface.txt) [Select]

[BIND:SETUP_LOCAL_Y_UP:REPEAT_SLOW]
[KEY:U]
[BIND:SETUP_LOCAL_Y_DOWN:REPEAT_SLOW]
[KEY:M]
[BIND:SETUP_LOCAL_X_UP:REPEAT_SLOW]
[KEY:K]
[BIND:SETUP_LOCAL_X_DOWN:REPEAT_SLOW]
[KEY:H]
[BIND:SETUP_LOCAL_Y_MUP:REPEAT_SLOW]
[KEY:u]
[BIND:SETUP_LOCAL_Y_MDOWN:REPEAT_SLOW]
[KEY:m]
[BIND:SETUP_LOCAL_X_MUP:REPEAT_SLOW]
[KEY:k]
[BIND:SETUP_LOCAL_X_MDOWN:REPEAT_SLOW]
[KEY:h]

Code: (alternative interface.txt until embark region movement keys can be modified) [Select]

[BIND:SETUP_LOCAL_Y_UP:REPEAT_SLOW]
[KEY:u]
[BIND:SETUP_LOCAL_Y_DOWN:REPEAT_SLOW]
[KEY:m]
[BIND:SETUP_LOCAL_X_UP:REPEAT_SLOW]
[KEY:k]
[BIND:SETUP_LOCAL_X_DOWN:REPEAT_SLOW]
[KEY:h]
[BIND:SETUP_LOCAL_Y_MUP:REPEAT_SLOW]
[KEY:a]
[BIND:SETUP_LOCAL_Y_MDOWN:REPEAT_SLOW]
[KEY:w]
[BIND:SETUP_LOCAL_X_MUP:REPEAT_SLOW]
[KEY:s]
[BIND:SETUP_LOCAL_X_MDOWN:REPEAT_SLOW]
[KEY:d]

However with only LOCAL_X AND LOCAL_Y movement and resizing, the arrow keys would conflict with non-local movement and so I don't think it's worth reconfiguring. 

Can anyone think of a sensible temporary set of keys for moving an embark, so I can rebind that and selection? 

I'm thinking 'wasd' is a common movement prompt to anyone who's played a few games, and more intuitive than the bridge 'waxd' - the goal is ease-of-use, not minimal total keys used despite the overlap.  I'll probably put this in the next version of the starter pack.

Edit:  hmmm, having played around a bit the resizing acts differently to constructions as well - it just modifies the north and east edges, where constructions alternate sides.  This could also be changed. 

[Bumber]

Well, if you're going to be using ctrl, might as well just swap that with shift.

Why? Using Shift+arrow keys is pretty much standard for moving in larger increments in DF. (Also, some OS's use Ctrl+Arrow keys for OS-specific functions).

Not for the increments, for the next embark area. Nothing important that I can tell. Ctrl+Arrow is just for jumping between text boxes (or something like that) on Mac and Linux (which I don't think would work with DF's interface.)

[sal880612m]

What about somthing like an init file for the military where you can set pre-defined uniforms and general alerts.

[m-logik]

I like the ideas presented in this thread.

I think that having an in game menu for controlling announcements, particularly pauses and recenters (but ideally everything in announcements.txt), would be a natural addition to your list, perhaps as an expansion on item #8. I played for months before I even knew that this behaviour could be modified, and even then I learned purely by accident reading an unrelated thread.

[Cobbler89]

<graphics improvements>

I agree with all of this, but I'm not going to add them to this thread - it's a lot of work that Toady has said he doesn't want to do right now, and he does know people want it!

Hmm; I had assumed that, compared to most of the graphical fixes people want, the linked hack would be relatively simple to work into vanilla with relatively far-reaching benefits (since he doesn't have to actually reconfigure anything with the vanilla font, just make the separation available in the first place), but I didn't read any of the technical details, so I'm probably wrong. The barrel thing I have no idea if it would be hard (well, a lot of work), I just figured I'd throw it out there since it's just one character/tile/whatever and yet I find it personally more aggravating than all the other limitations combined. So, fair point that it's not necessarily a known quick fix type thing.

What about somthing like an init file for the military where you can set pre-defined uniforms and general alerts.

There's a suggestion you don't hear every day that would go a long way toward reducing work in setting up new forts.

[PeridexisErrant]

Following the excellent discussion, I've split/updated #4 into #11 and #12: 

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. 

I also added the SDL alt-bug link; thanks Lethosor!

Other cool ideas I've seen recently include a way to rearrange the main fort-mode menu, and possibly a file of military standard settings - more detail on that would be good, I like the idea but it's a little vague at the moment. 

[sal880612m]

Basically a init file that is somewhat similar to an embark profile for military schedules, and uniforms.
Uniforms would be pretty standard something like:

Code: [Select]

[Uniform]
   [ARMOR:MAIL_SHIRT:ADAMANTINE]
   [SHIELD:BUCKLER:WOOD]
   [WEAPON:INDIVIDUAL_CHOICE_MELEE]
Training schedules could also be relatively straightforward

Code: [Select]

[ALERT:HALF_YEAR_ROTATION_ALT_MONTHS]
  [SCHEDULE:SQUAD_ONE]
    [NAME:ALT_MONTHS_TRAIN_ODD]
    [GRANITE:TRAIN:1]
    [SLATE:NO_ORDERS]
    [FELSITE:TRAIN:1]
    [HEMATITE:NO_ORDERS]
    [MALACHITE:TRAIN:1]
    ...
    [OBSIDIAN:NO_ORDERS]

  [SCHEDULE:SQUAD_TWO]
    [NAME:ALT_MONTHS_TRAIN_EVEN]
    [GRANITE:NO_ORDERS]
    [SLATE:TRAIN:1]
    [FELSITE:NO_ORDERS]
    [HEMATITE:TRAIN:1]
    [MALACHITE:NO_ORDERS]
    ...
    [OBSIDIAN:TRAIN:1]
Idea is that the above would create an alert called Half-Year Rotation and provide Training order for squads one and two such that they alternate training every month. Squads one and two could be straight up named squads one and two, signify that the first two squads in the military should be given these orders or denote special squads like the fortress guard. It would help if you could save these in the same manner you do embark profiles.

While the more complex scheduling would either require manual input of things like points on a patrol route or points/burrows to station your troops or work around it by allowing their to be some sort of incomplete state where the init orders can accept prenamed things but will not work until such time as they are actually set. So it will attach to that route/area or those points when you give them the appropriate names, or create them if the appropriate names are something like point1 or burrow1. While some of this can be achieved relatively effortlessly with macros it will still take some time and macros take time to run and/or have less stable results than could be achieved by an init file.

More thought spent on the matter makes it fairly clear to me that to get the most out of something like this you would need to be able to have things be okay with being in an incomplete state or perhaps simply reread the init file whenever points or routes or burrows or squads are created.

Also throw in Ammunition profiles for good measure on a squad by squad basis. It would take work to set it up initially and depending on it's implementation would require either intelligent use or if the init was reloaded every time something relevant was created/destroyed an option to respect and not alter any changes made to the already loaded portions.
I hope some of this makes some sense, I am tired at the moment so if parts of it don't point them out and I will check back tomorrow with fresher eyes.

[lethosor]

#9 is now included as a tweak in DFHack r5 ("tweak confirm-embark").

[PeridexisErrant]

Added to dfhack.init for starter pack r59, but why isn't it there already?

[AltF4]

What about somthing like an init file for the military where you can set pre-defined uniforms and general alerts.

This, or at least the ability to copy paste uniforms. I spend so much time setting up almost identical uniforms so that I can assign different weapons.