Table of Contents

User Interface Implementable List

NOTE: This page may only be edited / added to by development team members.

  • This page contains a list of approved implementable items.
  • Developers should create patches for each implementable as soon as possible.
  • Each implementable links to the referring wiki discussion page or mantis.
  • An Urgent! indicates high priority. Patches are particularly welcome!
  • Do not delete the Implementable tag at the end of this page.

To suggest (short) ideas, go to Interface Improvement Ideas (Bulk), or start a new page in the User Interface namespace.

For ideas specific to the Tiles version, see Tiles Interface Ideas (Bulk).

This page contains very good ideas for how to improve the interface. So good that I'd say they can go in at any time. Here, I mean “interface” in a very strict sense: only changes that do not affect gameplay at all. So, for example, new commands for allies would not belong here, even if they make ally play much more convenient. — dpeg 2009-12-10 05:25

It is not quite clear how to implement these ideas. Most of them are good, but if we just open Mantis items, they will sit there and rot (as with the SF FRs). So instead, I suggest to pick a few for each major release after a discussion. Seeing this list here will make it easier to access which interface changes are most urgent. If someone codes additional ones, all the better. In particular, we should move interface ideas from Mantis items to here after a while.



Internal consistency

Currently, menus use many different structures internally. That's bad. See 75 for one instance.

The initial structure is in place but lacks full multiselect and paging support at the moment so it's not yet used everywhere. The initialization of various structures can also lead to a repeating blocks of code. — felirx 2010-10-07 18:41

Interface consistency

In all paged lists, the following keys should just work: PageUp, PageDown, <, >, Up, Down.

If other keys are available (e.g. + and - for Ctrl-P), they should work, too.

There should be a help screen (if there's more to do than exit and scroll) and line providing clues (see below).

Help line

Every screen should have a line with command help. This will most often be the last line (as e.g. for Ctrl-P) but we can be flexible: d can use the top line. Currently, many screens give no clue whatsoever. See 75.

Travel (G) and autoexplore (o)

Holding down a direction key starts a long walk

Holding down any key is dangerous so we never do it. What if it could be useful? Holding down a direction key starts a long walk in the direction. What to do if the player is still holding the key when the long walk stops?

  • If it was stopped because of an intersection, the long walk could be resumed (if possible) after a reasonable delay if the player keeps holding down the key.
  • If it was because of any other reason, nothing should happen until the player has released the key (to avoid any problem if the long walk was stopped immediately before you could release the key) — galehar 2010-06-16 09:38
I think this is a brilliant idea. Holding down keys is bad, but often used by new players to cross short distances. For that, the above idea is perfect. — evktalo 2010-03-12 11:20
Also, holding down 5 (or s or .) triggers a long rest. I bet this mistake is even more common among new players. — galehar 2010-07-08 15:26

Traps in the way

When two parts of a level are separated with a trap, autoexplore says “can't reach some places” and autotravel says “I don't know how to get there”. In both cases, Crawl lies to the player because places are reachable (with caution) and there's a known route. It'd be much nicer to ask “Do you really want to walk over [name of trap]?” and then stop near unsafe (trapwalk_safe_hp option) traps, giving a message that something dangerous blocks character's route.

Stop autotravel when safely triggering a trap

This can be easily set in the options, but I think that discovering traps is important enough to interrupt autotravel by default because traps are valuable source of ammo/nets and T&D training in the early game. Two possibilities:

  • Add traps to the list of features announced by autotravel (needs special handling because traps can be detected quite close). This way it can be easily turned off.
  • Add the detection message to the default travel stoppers.

Default prompt for auto travel stoppers

Currently, the default for the autotravel prompt that pops up when you have to go through another level to reach a point on the current level is “no.” I encounter this prompt often enough that I think it should be “yes:” in most cases, the level you're going through is previously cleared and it's ok to just do it. The prompt itself should be enough warning in cases where autotravel would take you through a dangerous, noncleared level.

More verbose travel stop messages

Urgent! Instead of “Sorry, I don't know how to get there.” i would like to see something more like “Sorry, I don't know how to get there: reason why”. For example:

  • travel exclusion on Lair:5.
  • annotation on D:4: [here the actual annotation]
  • can't find stairs up on D:5.
  • can't reach stairs up on Orc:2.
  • monster nearby.
  • too close to harmful cloud.
  • starving.

Comments why auto-explore does not start

Urgent! There should be single line hinting at why auto-explore does not start (presence of monsters, or ailments, or clouds) or why it does not resume (stacks on traps, or traps blocking access to some parts. Basically, each break within autoexplore should have its own message.

Darshan added on instance of this today (a message when travel/explore won't start because you're in an exclusion). The others are still urgent! — dpeg 2011-01-08 01:06

Easy picking up of items when autoexplore stops

From 11: If an item is announced by autoexplore (and hence autoexplore stops), but that item is not to be picked up automatically, there should be a command (eg. g) to add it to the autopickup list. This makes sure that subsequent interruptions will still make you pick up that thing. There is something to think about: it sometimes happens that a number of items come into view (and hence stop autoexplore) at the same time, think of opening a door. We could make g add all of them to the list in this case, or simply have them be added to a traverse this item list, i.e. further autoexplore would walk over those items, but you wouldn't pick them up. (Rather, you'd choose by pressing either o or g when stopping over them.)

Announce all items/monsters, always

Partially from 1059. These proposals could be slightly controversial, so perhaps an option is in order.

  • Like autoexplore, long walk (Shift-Dir) should stop and announce when a new item comes into view. Often times a lengthy 'long walk' takes you right past an item you would've preferred to pick up.

Items under plants

From 451: If you try to travel to an item below a plant, you'll move to the right dungeon level, but then just stop. Traveling to that item when in same dungeon level again, nothing will happen. Instead, the following should happen:

  • The item should have been listed as under a plant to begin with (in Ctrl-F and Ctrl-X).
  • You should get a prompt when starting to travel there: The item sits under a plant. Do you want to travel there anyway? (y/n)
  • If so, move the character as close as possible.
  • On autoexplore, you auto attack fungi - you could autoattack plants here.
This is better now the stash menu shows you the stash on the map before travelling. — rob 2010-05-19 14:13

From 764: items under friendly plants are entirely invisible on console. — og17 2010-05-19 14:17

Running could follow corridors

From 99: Running via Shift-<dir_key> should follow corridors until they branch or let out into an open space. Or at least there should be an option to do so.

Allow continuing autotravel with G in portal vaults

Currently all use of the inter-level travel command G is blocked in portal vaults to protect the player from accidentally leaving the level. There are still safe and useful uses though: continuing interrupted travel commands on the same level (issued via X, should be G+return as usual), and going to the nearest exit (could be G+< and/or G+>, or G+e). Traveling to the exit is less important, it is easily possible with X.

Level map (X command)

Cycling stairs in overmap

I suggest a new cycling order if cycling stairs on the level map: Sort all stairs and hatches by the following rules:

  1. staircases before hatches
  2. the player's component before other components (those where you have to change level)
  3. by distance

Indicate autoexplore/travel path

Show how the character would move using autoexplore. The shown path can be very short, of course. This might warrant an option — I could even imagine some players asking for the autoexplore path to be shown on the main map.

A similar request could be done for any travel (e.g., whenever you move the cursor on the overmap, the path is shown) but I think that the autoexplore feature is more useful.

Clearing the map

When clearing the map, make an exception for stationary monsters which have been seen.

Fogs and clouds

Currently, the level map does not show clouds anymore. This is good, but it would be even better to have a cloud toggle for the level map.

Dungeon Overview (Ctrl-O)

Differentiate between found and reachable altars

It can happen that you have all altars to some god are unreachable (because of fog, glass, water, lava). It would be good to display this on the Ctrl-O display, ideally with colours: unknown altar = darkgrey, reachable altar = white, all altars unreachable = lightgrey. This seems to require genuinely new code, however.

Allow travel

At least for altars, this is highly desirable. Currently, after exploring the Temple, players will press Ctrl-O to check which gods are there, but then have to use Ctrl-F to move to the desired altar. I suggest that pressing _ asks for a a letter (the initial of a god, with TSO being replaced by 1) and starts travel to the nearest altar.

It might be useful to do the same for branches, but that's less necessary, because G is more convenient to use.

Change level annotations from Dungeon Overview (Ctrl-O)

The new level annotation (!) feature is great, but suffers from the fact that you can only change a level's annotation while either on that level or on stairs to that level. This leads to annotations becoming out of date, without any good way to change them without wasting a lot of time going back to the level.

Pressing ! in the Ctrl-O screen should bring up a small dialogue (only five lines will be used, and all current annotations are still on-screen). That dialogue looks exactly like the Ctrl-G prompt, with the exception that Enter and . are shortcuts for the current level and that you are allowed to enter any level. (So you could annotate Elf:8 with “Don't die here again!” if you'd like to.) Once you've chosen a level, the game lists the current annotation (if any) and proceeds as with !.

Ctrl-O help

Once we allow commands in the Ctrl-O screen (like _ and ! proposed above), we need a help screen, naturally on ?.

Items and shops

Item list

There have been several proposals for adding an item list in style of the monster list. While there is the new Ctrl-X command in trunk, its use is a bit different to the list(s). Some ideas:

  • The monster list should have strict preference over the item list. (This is especially crucial for standard terminals with their mlist of only 5 lines.)
  • In the end, this might need an option, but for the default, I'd suggest this:
    • Have the monster list grow from top to bottom (as now).
    • Have the item list grow from bottom to top.
    • Always keep a blank line between the two lists.
  • There could be an option that reduces friendly monster list noise: Instead of
    Z - friendly ogre zombie
    z - friendly killer bee zombies
    Zz - 2 friendly monsters
    (i.e. only one line for all friendly monsters). Perhaps this is even worth a toggle.
  • Perhaps we should use the display for large stacks. Show items in full, if number of items and number of monsters allows:
    ? - a scroll of remove curse
    ! - a potion of heal wounds (unseenpile)
    and switch to a long list if not:

Autoinscribe fruits for Fedhasites

From 1027: Followers of Fedhas should have all fruits autoinscribed with !e. This is slightly difficult because there's no trigger for current god, I think.

This is doable in Lua currently (if you.god() == “Fedhas” then autoinscribe = fruit:!e …) but that's not quite a perfect solution since it requires saving and reloading upon joining the god. — MarvinPA 2011-04-14 18:07

Card list for fully known decks

Don't show a list of cards that a deck may contain when all cards in the deck are known.

New colours for consumables

This needs to be discussed. If it goes in, we need an option.

Potions, scrolls and wands could be colour-coded in world-view the same as they are in inventory, e.g. potions of mutation purple. The main point of the current unknown item descriptors (“a bubbling blue potion”) is flavour. Accordingly, all unknown potions would be given the same colour.

Abort prevented item use consistently

Scrolls of teleport and blinking are not wasted while wearing stasis or -TELE, but e.g. potions of speed are. Similarly, Teleport Self prompts to abort while casting Haste at self does not. It would be good to have consistency here, one way or the other.

more consistent behavior of commands under exceptional circumstances

Several commands have uses besides their direct effects. For example, 'e' can be used to quickly check what food the player has in inventory, which can be useful for e.g. a Sif follower with gourmand deciding whether to channel or rest. However, this cannot be used when engorged: you immediately get a message “You're too full to eat anything.” I would prefer to get the list of edible food first, then only get that message upon selecting an item.

Track Chunk Creation Time

We internally track chunk creation time, but for a player who picks up chunks, they do not arrive in inventory in any given order. Therefore, it would help the player to know which chunk is the most aged in order to eat responsibly rather than have to track chunk age manually. Trunk age should be counted in the number of turns since it was created (if known) or discovered (if unknown). This information could be in the description of the chunk (elf, etc.) or could be in the title of the chunk.

Dropping (d) and pickup (,)

These have a rather high priority and can go in any time. Patches would rock our little world!

^ refers to last item picked up

For all commands that require an item from the inventory (read, quaff, put on, wear etc.), ^ should be the shortcut to mean “the item (of that sort) I've last picked up”. For this to be useful, after pressing q (for example) we should print:

  • Quaff which potion? (Press ^ for [last potion].) if automenu is not used.
  • List the ^ at the very top of the screen if the menu is displayed.

The advantage of this system is that players have to press fewer letter keys, leading to less screen-keyboard focus switches. In particular, d^ would drop what you just picked up.

Selective drop menu

I'd love to be able to only drop certain types of items, similar to what NetHack has bound to the 'D' key. It could prompt with a list of the different types of items in your inventory (scrolls, wands, potions etc.), and then you select which you want to view.

Similarly, there could be a selective inventory view (similar to Nethack's I).

Note: the D key is actually free for the latter, but the I key is not available for selective inventory. However, since I believe that selective dropping is more important, we could start with that.

Drop order

From 1907: Items should be dropped in the order you select them (in the inventory screen). Advantage: this saves some keypresses occasionally (e.g. facing a mummy, or a monster with sticky flame). Drawback: The current system (sort by item letter) is very simple. Unless we add a system to display the selection order (which we don't want!), the new system would be a little bit less transparent.

Altogether, this would probably be an improvement (and hopefully not need an option).

Easier quantity selection

It's especially annoying when you want to grab as much stuff as possible without burdening yourself. You pick too much, then in the drop menu you choose a stack and try different quantity until you find the good one. Here is 2 proposals to help with this:

  • In the pickup menu, if what you've selected would burden you, it is displayed at the top of the screen.
  • In both menus, there are commands to increment and decrement quantity. Maybe left and right arrows, but I think they have another use planned. There is also a third command that select the maximum quantity you can pick (or the minimum you have to drop) without being burdened. — galehar 2010-09-03 11:31

Autopickup improvements

Such things could already be done through lua.

  • Don't pick up more than two rings (if they stack). 760
  • Don't pick up more than two or three chunks on butchery (unless gourmand, sublimation,…)

Discoveries (\ command)

dpeg thinks that none of these is controversial and they're all worth it; patches welcome!

Jumping in discoveries list

Urgent! Often, you just want to know if some particular scroll or potion is already know. Pressing the key of an item category (one of !”/? etc.) within the discoveries screen (\) should jump to that section.


Low MP warnings

Currently the MP warning is set for a percentage of total MP. However, it is often more useful to warn on a given absolute amount of MP, which could then be precisely chosen high enough to allow to cast a given set of spells (e.g. controlled blink, flight+swiftness). It would also make sense to require confirmation upon casting spells that would reduce it past the critical value.

borsuk: I think this is not only a good idea, but it should become the new default.

The reason HP warning by percentage works is that HP-based threats scale up much more consistently than MP threats. Thorough the game, you can expect a powerful enemy to hit you for 1/3 or more of your total HP, for example. This is not at all the case with magic. A magic-oriented character may use MP-efficient spells for killing, like poison or sticky flame. High-level character with magic does not necessarily imply more expensive conjurations. Conjurations are just a part of magic. Another character may be a transmuter and only really need so much MP as to transform into his combat form. Even at the end of the game, his MP costs are going to remain the same, and his investments will be placed elsewhere (training combat skills, getting certain items etc). I think it would be best to have absolute MP warning adjustable easily in the game, without even the need to save&exit to make config changes take effect (is there another way ?)

Reduce message spam

"looks stronger"

Messages along the lines [foo] looks stronger are not very useful on summons and can be actually annoying. Ideas:

  • Only show them for permanent allies.
  • Stop summoned/temporary creatures from ever leveling up.
  • [foo]] looks stronger also extends their duration. (The latter two are slight gameplay effects.)

Hidden Escape/more mechanic

When faced with more messages than fit the message window, pressing Escape allows you to skip past all more() prompts until your input is required again. This is not at all clear from the interface, and should be made more obvious.

Condensated combat messages

I have a few ideas for message condensation. Coders wouldn't love it (special cases?), but players could:

“The ogre hits the kobold with a giant spiked club !!! The Kobold dies.” → ” The ogre kills the kobold with a giant spiked club !!!”
“You hit the imp ! You freeze the imp ! The imp dies” → “You freeze the imp to death !”

With “helpless” idea from above, it could look like this:

“You freeze the helpless imp to death !”

I stumbled upon this ideas as I was thinking about making summoners' lives easier. And there are reasons to believe players would like fancy death messages. (“The ogre smashes the kobold into a pulp with a giant spiked club !!!”)

b0rsuk 2010-09-02 13:27

More consistent use of interpunction

Currently, interpunction (ie. using . vs ! or !! in messages) is used to indicate damage. However, we are not very consistent about this:

  • [monster] convulses in agony! on pain
  • [monster] is blasted. on disintegration
tgw: Also, melee hits which deal no damage explicitly say “you hit the [whatever], but do no damage.” This should be extended to spells as well, rather than the separate message ”[whatever] appears unharmed” that they currently use.

Highlighting important events

Colourcoding @ symbol

Suggested by poop in 1812631: Since the “about to teleport due to mutation” message is so urgent, why not make the @ symbol blink or change color? That would be really hard to miss.

Similarly, low hp could cause the @ symbol to change to yellow, then red.


Reaching weapons

From 1296. This would make weapons of reaching much easier to play, hence Urgent!

If you wield a weapon of reaching, then

  • pressing Shift-Direction should attack a monster two squares away (in cardinal directions) — to be precise: without pressing 'v' and entering targeting mode. With that monster in sight, running (the usual effect of Shift-Direction) won't work anyway.
  • you could still press 'v', in which case autotargeting works as now (is it already restricted to enemies in range 2, I hope). Shift-Direction should work when targeting, too.
  • further pressings of 'v' inside targeting mode should cycle among all eligible targets (hostile and within range 2). This would make it easier to attack monsters at a knight's jump distance.

It might be an option to be more radical:

  • Walking (i.e. pressing a direction key) attacks two squares away. Advantage: this is exactly what you want, in the vast majority of cases. Drawback: there's no obvious mode how to suppress this feature in the few cases when you want to move closer rather than attack (both Ctrl-dir and Shift-dir look a bit odd for that).


Better choice of default beam path

When Crawl autotargets, it uses one (simplistic) out of (usually) many beam paths. Instead, it should consider all beam paths that go through the desired target (i.e. the last target or else the nearest hostile monster) and take the one that

  1. minimises friendly targets
  2. maximises hostile targets

with 1. taking preference over 2.

Reuse manual targets

When you manually fire at something (usually for invisible monsters), that location should be the default for the next round.

New cyclers in target mode

  • r - cycle through monsters running away although I am not sure whether to start with nearest or farthest. And only target those fleeing monsters with clear beampaths?
  • w - cycle among monsters, starting with most wounded one — again, only those with clear beampath?

Not so sure about most wounded…

Individual spells


When casting Apporation, make a” synonymous with * (jump to next item). This will work wonders if you put your Apporation spell on slot a. Auto-target should be the closest item on the autopickup-list; closest item otherwise. Autopickup usually includes fired items.

I don't see the point of this. What's so special about Apportation? The fact that the user has to change spell slots to make this work shows that this wouldn't work out of the box. 2074 is more general about this, though I'm still not convinced. — jpeg 2010-08-16 22:24
I changed apportation targeting so that + and - (next/previous monster) can be used to cycle through items. I think it's enough. — galehar 2011-06-12 00:33

Mephitic Cloud

The game should place the cloud so that it hits as many hostile monsters as possible and does not envelop the player (the second check can be skipped if player has clarity or rPois). If no monster can be reached, place the cloud as close to as many monsters as possible.

A simpler solution is just to target Mephitic Cloud as if its range were one greater. In the case where the nearest target is out of range you'll have to move the target one space, but that is easier than moving it all the way from the @. — lemuel 2009-12-14 05:26

The same holds for all other cloud spells. This change is pretty important by my assessment (dpeg).

What if a player wants to hit a particularly threatening creature with the edge of a cloud, so that the creature needs to travel through more cloud squares at the expense of other nearby monsters not being covered at all? What if a player wants to avoid confusing a specific creature with meph (to avoid drowning, for example)? Having to retarget clouds from arbitrary starting points would make the player stop to see what the game decided was best on every casting, pulling the player out of the game. “Intelligent” behavior is never as intelligent as the user - I don't care for this sort of thing at all. — og17 2010-05-19 14:22
The player can still move the cursor as desired, and I think this change would make that less frequent. This is also very useful for endgame casters, whose only long range spell might be Fire Storm: it would be nice to not have to position it manually every time a weak enemy enters LOS, but have the game position the cursor sensibly automatically. — luca 2010-05-20 12:11


Never disable Q command

Currently, the quiver command (Q) is disabled if you don't have any throwable item. However, it might be useful to quiver any item. Therefore, we should allow Q even if the quiver lines shows You aren't carrying any items that might be thrown or fired.

Restrict ammunition cycling to launcher

If you wield a bow and cycle ammunition with the ( and ) commands, you will still go through throwable items like javelins or stones. I think that's bad. If you want to fire those despite wielding a launcher, that's what the F command is for.


Shopping List: Make the stash tracker and shopping list aware of each other

Status effects

Prioritise status effects

See 2868736.

Sort status effects by importance, possibly depending on character build, and then show as many as fit into the allocated space, ending in ”…” if there are more. We could add a key to show all of them in a separate menu/list/screen or have them intrude into the monster list with a toggle. On the other hand, we already have the @ and % commands, which should include all this information.

Priority could also depend on the status strength or duration. As a specific example, the grey “Glow” status is informational only and would get a low priority, whereas the coloured ones would be mentioned earlier.

Searching (Ctrl-F)

Searching allies

Would be nice if you could search for allies, e.g. Ctrl-F “allies” and get a list of them. This is technically problematic, however, because allies can die without you knowing, or leave level via shaft accident. The interface must not give this away. See 2818084 for a discussion.

Ctrl-F when reading manual etc.

It would be nice to have Ctrl-F work when reading documentation. This is not urgent, but a patch would be cool. Same for the history. In my opinion, neither is really crucial because these are available as text files (well, for the history, the dump command (#) should also dump the history).

Monster list

What to list

Some thought could be spent on the question what to list. Generally, we will want to see the most dangerous enemies. But what if allies are around? Do we want the strongest allies to be listed prominently as well? If there are really many monsters around, is it worthwhile to fill the last line of the list with the bare glyphs (including brands, as above)?

Character Dump

Religious affairs

Currently, you cannot assess from the dump who the character worshiped, and for how long. A simple version would be a table like this:

[god]     [begin]-[end]  [maxpiety]  [left how]
Ashenzari    4050-80923  *****       abandoned for Lugonu
Lugonu      80923-127714 ******

> All of this is already present in the dump:

69 | D:1 | Acquired Makhleb's first power
1248 | D:2 | Acquired Makhleb's second power
2137 | D:3 | Acquired Makhleb's third power
3418 | D:4 | Acquired Makhleb's fourth power
4020 | D:5 | Acquired Makhleb's fifth power
87129 | Abyss | Fell from the grace of Makhleb
87129 | Abyss | Was placed under penance by Makhleb
87129 | Abyss | Became a worshipper of Lugonu the Unformed
Ie, you get not only the turn range, but also the history of the piety going up and down. For some reason piety thresholds that don't give an ability are suppressed, this could be changed. — KiloByte 2011-08-17 02:42
Yes, this is true, of course. I didn't explain where I was coming from. The character dump could give a much better overview over the character (dead or alive). I will come up with a complete description. — dpeg 2011-08-17 22:22


Remember invisible monsters' position

If you see a monster turn invisible, a grey glyph (or special tile) should be displayed at this position, similar to NetHack's 'I' glyph. Also applies to invisible monsters attacking you, though things become less clearcut with ranged combat, invocations and reaching.

Could also be used for monsters coming into los, then leaving again before the player's turn. Alternatively, we might leave a single turn cloud, but that might be a bit odd. See 2882108.

If this is done, we might also want to improve monster AI, so smart invisible monster step away from said glyph. (Though I guess this only makes sense if spellcasting doesn't give away the exact monster position.) — jpeg 2009-12-28 21:50

Curiously, there is a comment in one of the very early Crawls that the 'i' glyph is reserved for the eventual implementation of exactly this feature. — sorear 2009-12-29 01:50

Switching of items, spells, abilities (= command)

Currently, you can use the = command to switch items, spells, abilities. But for that, you have to remember the two slots. It would be much simpler if you could turn on a “swapping” mode while watching the inventory, the spells or your abilites. So here goes:

Pressing = within the inventory (i command), the spell list (I command) or the ability list (a command) toggles between “normal” and “swapping” mode. In swapping, pressing the slot of an existing item/spell/ability highlights it and pressing any other letter assigns that key to the item/etc.

Note that in principle we could also allow this mode change via = in the spellcasting commands (z and Z) — but we cannot allow them in the drop menu (d) because = means “select jewellery” there. There is also a slight inconsistency in that we have “view items” and “view spells” commands but not “view abilities” command. But this should not affect the above idea, just something to think about.

Spell memorisation (M command)

  • Sometimes it is good to show all (not yet learned) spells from the carried books; sometimes it is not. I suggest to show all spells if everything still fits on one screen; otherwise, restrict to unknown spells which you can actually learn. There should be a toggle (*) for this behaviour.

In-game macro list

It would be convenient if there'd be a command to see in a nice overview table all macros which are defined during a game. (Otherwise, especially after a longer pause from the game, you have to look up all your previously defined macros you can't remember any more.)

I dpeg suggest two additional entries for the ~ prompt:

l - list the current macro file
? - display macro help (as available per ?~)
f - flush: The string of keys entered here will be taken literally, without any additional logic.

Flush would allow sequences like w-mae[Enter] which, if used upon game start, unwields the weapon and changes some skills in the m screen (the latter is currently not possible!).

From a similar FR: “I'd love to see a nicely sorted macro list which expands keycodes into readable labels, shows the meaning of each macro, takes keymaps, keybindings and inscriptions into account and allows to copy and move macros to other keys. Example:

1: za {cast Slow}
2: ab {invoke Might}
3: ac {ability currently n/a}
^A: aa {evoke Invisibility}
^I: va {evoke rod of destruction for Bolt of Inaccuracy}
*: p {pray}
Numpad Enter: f {fire}
Numpad Ins: w2 {wield +2,+3 scimitar of Smthng {rElec}}

etc.” (dpeg is not sure if this is worth the coding trouble.)

Closing doors

The change of the C behaviour (don't prompt if there's only one door adjacent) is a good one, It can still be improved:

  1. Abort action if all adjacent doors/gates are blocked by monsters or items.
  2. If exactly one door/gate is usable, then close that without prompting.
Other gate issues fixed in 0159202fc. The first remaining suggestion is a good one, but I'm unsure about the second one. — jpeg 2010-08-18 10:00

force_more_message prompts

The current implementation of force_more_message option treats the forced messages as any other more messages. This is better than nothing, but players are inundated with a multitude of -more- messages over the course of a game and it is easy to inadvertenly clear forced messages. It would be better if these forced messages should be cleared only by a specific keypress, perhaps similar to easy_confirm = safe , which forces a capital Y or N prompt on potential game ending actions.

Force pickup with ;;

The ; command picks up autopickupable stuff at your location, provided there are no monsters nearby. If there are, only the contents are shown. We suggest that another pressing of ; should force the picking up, regardless of the monsters. There should be a message to that effect. (Things that are here: (Press ; to force picking up.))

Explain autoexclusions

Monsters that are automatically excluded (oklobs, statues) should have an extra description when viewing them:

This [monster] is dangerous but cannot move. For your safety, it has been excluded from exploration and travel.

Could also be done for features (clouds) but here a new player can be less confused, I think.

List monster glyph/tile in description

From 324: It is possible to look up monsters by glyph and see their name. But it's not possible to look up monsters by name and see their glyph. It would be best if monster descriptions contained the glyph, e.g. in a separate line, or as part of the first line: A gnoll (g). For tiles, show the tiles rather than the glyph. The same comment also applies to items and features.

I / II Screen

The I and II screens (memorised spells) could probably be condensed into one with a bit of abbreviation.

-------------------------------------------------------------------------------- (80 hyphens)
Your Spells                Power      Range    Hunger     Level Success   Type
Lee's Rapid Deconstruction ########## @------> Strawberry   5   Excellent Enchantment/Translocation

Your Spells                Power      Range    Success   Hunger      Type    Lvl
Lee's Rapid Deconstruction ########## @------> Excellent Strawberry  Enc/Trl  5

W/T and P/R commands

As you can see below, most of this is controversial. What's worse, it is not clear to me (dpeg) if we actually gain much from this.

''W-'' as synonym for ''T''; ''P-'' as synonym for ''R''

In the long run, T and R might be dispensed with; until at least 0.7, the commands R and T should be kept. Note the analogy to w-. The main idea is that rare commands like T, R (rare because you'll often use W and P instead) should take a backseat; also, they are not mnemonically sensible.

  • A terrible idea, you use T and R exactly as many times ad W and P (deaths excluded), requiring an additional keystroke would be pure tedium. It's very counterintuitive too – you don't speak about wearing things when you think about disrobing. — kilobyte 2009-12-11 10:01
  • Not sure about terrible, but definitely controversial. I think that having R=P- and T=W- will be good. We could even count how often T is used. I am pretty sure that at least in my games, T comes up rarely — I usually use W. — dpeg 2009-12-11 18:10
  • I rather agree with KiloByte here: a lot of the time I just want to try out an item I just found, so I (P)ut it on and then (R)emove it again. Of course for complete identification sessions, I'll use W/P repeatedly, so those do get used more often than T/R. Still, I don't see “W-” as an improvement. (Note that, other than for w-, you still have to pick *what* you want to take off, so you're not even saving yourself the trouble of having to look up the slot, which I guess is the whole point of w-) — jpeg 2009-12-13 20:16
  • Less ideal, but 'R' and 'T' could be folded into the same command without much trouble and enable us to reclaim one of the keys, at least. It's just as sensible to “Remove” armor as it is to “Take off” jewelery. — wensleydale 2010-10-05 00:42

Shopping cart (dis)robing

Via W! and P! or combined, e.g. [. The proposal: W! brings up the list of all armours. You can (de)select items. Select an item deselects the old item of the same type (cloak, gloves etc.) if any. Pressing Enter starts gear change. Display number of turns needed, as for dropping. The application would be full gear changes.
Something similar could be used for jewellery, P!. It might be a good idea to combine both into a single command, e.g. [.

dpeg is not sure this gains so much.

''W='' switches to rings. ''P['' switches to armours.

It turned out that some players keep confusing W and P. For those, a single switch to go from armours to jewellery would be useful.

Option to combine ''W'' and ''P'' / ''T'' and ''R''

See above, this might be the better way. A similar option to combine W and T / P and R already exists (equip_unequip). Combining this and the new option could probably give one screen with all of P R T W.

Removing jewellery

Enable the left-hand < right hand > functionality of Putting on jewelery for Removing it as well, if you don't want to replace it with anything. In addition, there should be the R” shortcut for removing your amulet. (It is a mental shortcut because you don't have to look up/press the amulet's letter key.)

I wanted to add that the 'R'emove interface does not need the full map. It's feedback should sit in the message area, just like when you're 'P'utting on a new ring and the game asks which one to replace.

Each equipment slot gets dedicated character

Imagine each equipment slot has a dedicated character, for example:

)Wielded weapon
^Worn helmet
_Worn boots or barding
Worn amulet
=Worn ring (prompt to choose?)
[Worn body armour
] or |Worn shield

…then we could do things like this:

  • d-: drop wielded weapon
  • d_: drop worn boots
  • d”: drop worn amulet

(…) These would actually be quite useful when testing new items by trying. I think dropping all items of X kind is a corner case, it's mostly when there's a firedrake behind the corner. So it can be slightly longer. I suggest d*SLOT_CHARACTER drop all. Asterisk * means “all” in many places, it seems like a natural fit.

More imporantly, introducing these absolute slot symbols would mean we could get away with just one command for taking off and unwielding. For example:

  • R): Remove wielded weapon
  • R_: Remove worn boots
  • R”: Remove worn amulet
  • R^: Remove worn helmet
  • R]: Remove worn body armour
  • R|: remove worn shield (because ][() are too similar to each other)

I don't know about you, but when I need to take something off I don't care which letter it is. Letters for individual items are nice when you need to wield something quickly, or put on a ring. Speaking of rings, I wonder if each of them should get a separate slot letter.

Overall, I think it would make the interface quite a bit faster once you get used to the symbols. It's not exactly intuitive, but intuitivity is often short-sighted. I prefer a bit of learning curve and convenience in the long run.

b0rsuk 2010-08-16 20:08

Now that's what I call “thinking out of the box”, I like it. That is, I like it for replacing the current remove/take off mechanic. I rather prefer the current system of allowing e.g. d= to mean “drop all rings” (and then unselect the few I don't want this applied to), thank you very much. For the R* system I suggest allowing both the item slot and the special character, similar to how it already works with the ring swap prompt, from which we incidentally could borrow < and > for left and right ring. Also, [ seems like a better fit for shields, or maybe use that one for cloaks, which AFAIR leaves only gloves. Great idea! — jpeg 2010-08-18 10:52


Logged in as: Anonymous (VIEWER)
dcss/brainstorm/interface/interface_implementables.txt · Last modified: 2018-02-10 05:47 by aidanholm
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki