NOTE: This page may only be edited / added to by development team members.
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.
Urgent!
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
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).
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.
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?
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
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.
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:
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.
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:
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
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.)
Partially from 1059. These proposals could be slightly controversial, so perhaps an option is in order.
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:
under a plant
to begin with (in Ctrl-F and Ctrl-X).The item sits under a plant. Do you want to travel there anyway? (y/n)
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
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.
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.
I suggest a new cycling order if cycling stairs on the level map: Sort all stairs and hatches by the following rules:
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.
When clearing the map, make an exception for stationary monsters which have been seen.
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.
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.
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.
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 !
.
Once we allow commands in the Ctrl-O screen (like _
and !
proposed above), we need a help screen, naturally on ?
.
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:
Z - friendly ogre zombie
z - friendly killer bee zombies
Zz - 2 friendly monsters
? - a scroll of remove curse
! - a potion of heal wounds (unseenpile)
())%+++
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
Don't show a list of cards that a deck may contain when all cards in the deck are known.
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.
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.
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.
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.
These have a rather high priority and can go in any time. Patches would rock our little world!
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.^
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.
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.
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).
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:
Such things could already be done through lua.
dpeg thinks that none of these is controversial and they're all worth it; patches welcome!
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.
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 ?)
Messages along the lines [foo] looks stronger
are not very useful on summons and can be actually annoying. Ideas:
[foo]] looks stronger
also extends their duration. (The latter two are slight gameplay effects.)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.
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
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 disintegrationtgw: 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.
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.
From 1296. This would make weapons of reaching much easier to play, hence Urgent!
If you wield a weapon of reaching, then
It might be an option to be more radical:
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
with 1. taking preference over 2.
When you manually fire at something (usually for invisible monsters), that location should be the default for the next round.
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…
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:24I 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
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
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
.
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.
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.
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.
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).
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)?
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
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
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.
*
) for this behaviour.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.)
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:
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
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.
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.)
)
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.
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.
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 --------------------------------------------------------------------------------
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.
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.
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:01R
=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
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.
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.
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.
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.
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:
(…)
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:
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
—-