Add a way to quickly examine the contents of an item #51252

ZeroInternalReflection · 2021-08-31T02:41:11Z

Summary

Interface "Add examine contents menu to inventory menus"

Purpose of change

As raised in #50887, when looking at items in the player's inventory, 'e'xamining them will describe the container prior to describing the contents. For many items, this is logical (e.g. describing the mp3 player before describing the batteries). However, for other items, such as a bottled drink or a sealed can of food, the player is interested in the contents, and has to scroll to find that information.

Describe the solution

This branch adds a new inventory menu derived from inventory_selector that is set up to examine the contents of the selected item. This can be pulled up from the inventory menu (or the drop menu, the pickup menu with #51033, or the AIM). It's currently pulled up with 'o'. For an item that has no contents, the behaviour is equivalent to 'e'xamining. For an item with only one thing inside (a bottled drink), it looks like this:

But the menu also handles items containing multiple other items:

And can be called recursively.

Describe alternatives you've considered

Adding a new, independent class for displaying item contents:
See some of the earlier commits of this pull request. Eventually, proper sorting/collapsing/filtering code just added up to too much duplication of what inventory_selector already does.

Changing the behaviour of 'e'xamining items in the inventory to focus on contents:
This would require some judgment calls on when the player is likely to care more about the container or the contents, and I can see it constantly feeling like we guessed wrong.

Quicker navigation on the 'e'xamine screen to jump to the contents:
Probably of benefit, but might still not provide all of the information the player is looking for.

Testing

I've tested the behaviour of the menu with a variety of items. Empty, full of items, one item, full of items filtered to nothing, etc.
I have not tested the menu with any language other than English.
The menu looks reasonable on my computer monitor, but might not work well on different screen sizes/shapes.

Additional context

(This text was updated 2021-09-08 & 2021-09-10 & 2021-11-05based on changes to the PR)

A couple of tweaks to inventory_selector were necessary to ensure the window was always going to be a useful size (There's an image in the comments below of how small the item detail pane could be if inventory_selector was left unmodified). The way this is done should probably be cleaned up a bit, and I've left some TODO notes to that effect.
The examine contents menu should work with the AIM and with every other menu derived from inventory_selector. I've tested it on 'i'nventory, 'W'ear, 'w'ield, 'T'ake off, 'a'ctivate, '('Disassemble, and (with Migrate pickup menu to a new inventory_multiselector menu #51033 now merged), 'g'et. It's not particularly relevant on some of those, but I don't think it's a problem having it anywhere
The examine contents menu could probably be added to a couple of other menus like '+' re-layer clothing and 'V'iew nearby items, but I have not done so
I'm also working on a related change to the crafting menu (&) to provide quicker access to the information on e.g. crafting sealed cans of food (Modify crafting UI to show details of byproducts and jar contents #51496)
Currently, the hide/show contents actions do not play nicely with inventory_examiner (see Show/hide contents functionality in menus removes items from it that are not on the character #51490). I've removed the check disabling this, but it's still not functioning perfectly

Some notes on keybindings:
I've set it to use 'o' in both inventory_selector menus and the AIM:
Scrolling the item details uses Page Up/Page Down, where in the main inventory screen, that scrolls through the item list. I'd have preferred to use "<"/">", but those are in use in inventory_selector for show/hide contents.

RandDenner · 2021-08-31T04:21:57Z

Looking at that wallet graphic list, any chance some kind of default sort can be applied?
Maybe alphanumeric by default, but possibly a category toggle on top, as a user toggle?

Qrox · 2021-08-31T06:32:26Z

It may look nicer if identical items are stacked in the list.

src/item_contents_ui.cpp

andrei8l · 2021-08-31T09:24:31Z

Does this really need a whole new UI though? Why not show a regular inventory_ui window with the contents instead? Other item UIs are also being migrated to inventory_ui, see #51033 and #50015.

ZeroInternalReflection · 2021-08-31T15:13:57Z

Looking at that wallet graphic list, any chance some kind of default sort can be applied?
Maybe alphanumeric by default, but possibly a category toggle on top, as a user toggle?

&

It may look nicer if identical items are stacked in the list.

I agree that some sorting /collapsing of identical items would be beneficial. Sorting feels like it should be fairly simple to add. Collapsing seems trickier, but I'll look into it.

Does this really need a whole new UI though? Why not show a regular inventory_ui window with the contents instead? Other item UIs are also being migrated to inventory_ui, see #51033 and #50015.

I agree that certain things would be a lot simpler if this was yet another derived inventory_selector class. That's what I looked into first, but I couldn't see a way of making it work. It felt like (and I absolutely could be missing something here) inventory_selector was not intended to be extended to cases like this. The drawing was specifically walled off in private base class functions, and I didn't want to muck about with them and risk over-complicating/breaking everything else.

mqrause · 2021-09-01T07:32:49Z

I agree that certain things would be a lot simpler if this was yet another derived inventory_selector class. That's what I looked into first, but I couldn't see a way of making it work. It felt like (and I absolutely could be missing something here) inventory_selector was not intended to be extended to cases like this. The drawing was specifically walled off in private base class functions, and I didn't want to muck about with them and risk over-complicating/breaking everything else.

It could work as a sort of nested inventory screen, without the item info directly in the same window, so you still press e to show that. I'm not sure that would really fulfill the goal of this, though.

ZeroInternalReflection · 2021-09-05T23:41:36Z

I've spent some time looking at inventory_selector and trying to see how this functionality could be integrated, and have not had a great deal of success. Various things I've looked at include:

Setting up a situation where inventory_selector automatically opens an 'e'xamine pane in the window for whatever item you're looking at (then you could get equivalent functionality by just creating an inventory_selector and adding the contained items). Unfortunately, it seems like the method for creating the 'e'xamine window always takes over input, it mucks up navigation (scrolling took two key presses instead of one). The test looked something like this:
Creating a derived class of inventory_selector which can display the item info in place of one of the columns. Unfortunately this seems like it would duplicate a lot of code, since you'd need to recreate the draw functions.
Creating a derived class of inventory_column, specifically for displaying arbitrary input. This also seems like it would duplicate a lot of code.
Modify inventory_entry or inventory_column to allow for display of arbitrary input (i.e. the item information). I think this is probably the most workable, and would probably be useful in other inventory menus, but I don't think it's something I can do without a lot more planning and research.

So, as of right now, I'm still using a separate item_contents_ui class. If anyone sees anything I'm missing, let me know.
I have, however, implemented basic sorting by name:

And by category (though not yet with category titles):

toy reimplementation of CleverRaven#51252 using advuilist

andrei8l · 2021-09-06T06:42:43Z

Unfortunately, it seems like the method for creating the 'e'xamine window always takes over input, it mucks up navigation (scrolling took two key presses instead of one).

Were you using inventory_selector::action_examine? You could add a boolean that's passed on to data.without_getch so it doesn't block for input (just like in your implementation). Or you could draw the item info yourself on an external window+ui_adaptor.

IMO, it's a little concerning just how much code (or boilerplate) and functionality is duplicated for UI, but that's not specific to your PR.

ZeroInternalReflection · 2021-09-08T04:10:04Z

Unfortunately, it seems like the method for creating the 'e'xamine window always takes over input, it mucks up navigation (scrolling took two key presses instead of one).

Were you using inventory_selector::action_examine? You could add a boolean that's passed on to data.without_getch so it doesn't block for input (just like in your implementation). Or you could draw the item info yourself on an external window+ui_adaptor.

IMO, it's a little concerning just how much code (or boilerplate) and functionality is duplicated for UI, but that's not specific to your PR.

I stared at the data.without_getch line for a while thinking "It can't possibly have been that easy this entire time, right? Right?". Thankfully for my self-esteem, if not much else, it wasn't quite that simple, but I've now put together a version derived from inventory_selector that I'm reasonably happy with from a usability perspective:

It does require some minor changes to inventory_selector and inventory_column (in particular inventory_selector::prepare_layout and inventory_column::set_width) to force a larger window. If there were only one or two items in the container, the default window was nigh-unusable.

There are also some edge cases where it's not as clean as it the separate class implementation. For instance, when resizing the window or filtering your inventory, the item details disappear until you're done, while the item list continues updating automatically. I don't think that's a dealbreaker though.

I'll be updating the PR as soon as I've cleaned things up a bit.

andrei8l

Nice job.

andrei8l · 2021-09-08T21:04:47Z

src/advanced_inv.cpp

+            }
+            item_location sitem_location = sitem->items.front();
+            bool contents_to_examine = false;
+            if( !sitem_location->is_container_empty() ) {


This block of code is identical to the one in inventory_ui and could perhaps be moved to a helper. It's not a big deal though

I agree that the duplicate code here isn't ideal. I'm contemplating various ways to simplify the use of various inventory_selector classes (there seems to be a similarly-duplicated block of code for each of them), but I think that's a longer-term goal.

andrei8l · 2021-09-08T21:05:53Z

src/inventory_ui.cpp

+            if( selected ) {
+                return selected.any_item();
+            }
+        } else if( input.action == "HIDE_CONTENTS" || input.action == "SHOW_CONTENTS" ) {


You can fold this into the branch below with else if !(...) { on_input() }

I suppose it could be folded in. If I understand you correctly, the main result of this would be one fewer check in the loop. However, the resulting line:
} else if( input.action == "HIDE_CONTENTS" || input.action == "SHOW_CONTENTS" ) { on_input(); }
Feels like it would be harder to parse six months from now. If that's just my read on it, then I can make the change.

Is there any particular reason why input_context doesn't have a "deregister_action"? Because that would allow this check to be removed entirely.

There probably just wasn't any need for a deregister_action so far.

If you want to disable more actions though, you'll still have to fold them into one of the branches or you'll get a clang-tidy error (duplicate branch).

What's the unexpected behavior exactly?

Probably the same I found with the pickup menu. Made an issue about that: #51490.

This should be fixed in master now; let me know if you still have issues with HIDE/SHOW_CONTENTS

This should be fixed in master now; let me know if you still have issues with HIDE/SHOW_CONTENTS

Yep. 51727/52602 disable hiding/showing contents in this new screen, so this line is no longer necessary. I'll add the commit once I've dealt with some new rebasing conflicts.

This should be fixed in master now; let me know if you still have issues with HIDE/SHOW_CONTENTS

Looks like I spoke before I'd fully caught up on the changes. After rebasing, you can use the show/hide contents buttons in this menu, and it won't hide/show/change the items listed, which was the problem before, but it will still say it's hiding things:

I've removed the specific block on hiding/showing in my code, because I don't consider this to be a major problem for the menu anymore, but it's still a bit quirky.

I can't test atm, but from a quick look I think it's because you're replacing the ui_adaptor::on_screen_resize() for the base class so prepare_layout() never gets called to hide the entries. You can probably fix that by calling select_one_of( get_selected().locations) in your resize callback.

EDIT: nooope

#52659 will definitely™ fix it. Sorry for the false info in the previous comment.

src/inventory_ui.cpp

andrei8l · 2021-09-09T06:09:55Z

src/inventory_ui.cpp

+        point start_position = point( ( inv_column_width + border_width + 1 ),
+                                      get_header_height() + 1 );
+
+        draw_item_info( catacurses::newwin( height, width, start_position ), data );


This creates and destroys the info window every draw cycle, which seems excessive though it simplifies resizing. You could create this window in a dummy ui_adaptor::on_screen_resize() since prepare_layout() and others are private.

quick demo patch

diff --git a/src/inventory_ui.cpp b/src/inventory_ui.cpp index b3e447b0ce..7b79e4ada2 100644 --- a/src/inventory_ui.cpp +++ b/src/inventory_ui.cpp @@ -2933,28 +2933,36 @@ void inventory_examiner::action_examine( const item_location sitem, const bool f //Tries to create a window covering the right half of the inventory screen data.without_getch = true; - // NOTE: This assumes that the first column (currently own_inv_column) is used for the item list: - int inv_column_width = get_all_columns().front()->get_width(); - /* NOTE: By flagging force_max_window_size as true, this forces the inventory_selector window to be - * TERMX x TERMY , allowing us to assume the window starts at 0,0 and is TERMX by TERMY. If this is - * changed in inventory_selector::prepare_layout, then everything breaks. This obviously isn't a - * great solution */ - - int border_width = 1; //Assumed, since the value in inventory_selector is private, but reasonable - int width = TERMX - 2 * border_width - inv_column_width; - int height = TERMY - get_header_height() - 1; - point start_position = point( ( inv_column_width + border_width + 1 ), - get_header_height() + 1 ); - - draw_item_info( catacurses::newwin( height, width, start_position ), data ); + draw_item_info( w_ex, data ); } } item_location inventory_examiner::execute() { shared_ptr_fast<ui_adaptor> ui = create_or_get_ui_adaptor(); + ui_adaptor dummy; + dummy.on_screen_resize( [this]( ui_adaptor &ui) { + // NOTE: This assumes that the first column (currently own_inv_column) is used for the item + // list: + int inv_column_width = get_all_columns().front()->get_width(); + /* NOTE: By flagging force_max_window_size as true, this forces the inventory_selector + * window to be TERMX x TERMY , allowing us to assume the window starts at 0,0 and is TERMX + * by TERMY. If this is changed in inventory_selector::prepare_layout, then everything + * breaks. This obviously isn't a great solution */ + + int border_width = + 1; // Assumed, since the value in inventory_selector is private, but reasonable + int width = TERMX - 2 * border_width - inv_column_width; + int height = TERMY - get_header_height() - 1; + point start_position = + point( ( inv_column_width + border_width + 1 ), get_header_height() + 1 ); + w_ex = catacurses::newwin( height, width, start_position ); + ui.position_from_window( w_ex ); + } ); + dummy.mark_resize(); while( true ) { - ui_manager::redraw(); + ui->invalidate_ui(); + ui_manager::redraw_invalidated(); const inventory_entry &selected = get_active_column().get_selected(); if( selected ) { diff --git a/src/inventory_ui.h b/src/inventory_ui.h index 02ace17a7b..e03f6b14af 100644 --- a/src/inventory_ui.h +++ b/src/inventory_ui.h @@ -833,6 +833,7 @@ class inventory_examiner : public inventory_selector { private: int examine_window_scroll; + catacurses::window w_ex; public: explicit inventory_examiner( Character &p, const inventory_selector_preset &preset = default_preset ) :

You can also add action_examine() to this callback to solve your resizing quirk. Not sure if this is appropriate style though; maybe @Qrox can weigh in.

EDIT: I just realized that this approach disables scrolling in the info window.

I think you can just override the create_or_get_ui_adaptor function and move the item info window creation and drawing code to the callbacks there. Or, just pretend the item info window is an overlay instead of a part of the inventory menu, and create a separate ui_adaptor for it. Do note that the game window may resize while get_input is blocking for input, so redrawing it after ui_manager::redraw instead of in a redraw callback will make it resize incorrectly.

I'm not terribly familiar with ui_adaptor right now, but I'll do some playing around with it. Right now I'd favour treating it as an overlay rather than trying to mess with any underlying functions.

How significant an impact is it to create the window every cycle? Given that it's waiting for user input every time I'd file it under "Not a great solution. Kind of annoying", but are there are any things happening further under the hood that might make it more of an issue?

data/raw/keybindings.json

Qrox · 2021-09-09T09:04:09Z

src/inventory_ui.cpp

+        point start_position = point( ( inv_column_width + border_width + 1 ),
+                                      get_header_height() + 1 );
+
+        draw_item_info( catacurses::newwin( height, width, start_position ), data );


I think you can just override the create_or_get_ui_adaptor function and move the item info window creation and drawing code to the callbacks there. Or, just pretend the item info window is an overlay instead of a part of the inventory menu, and create a separate ui_adaptor for it. Do note that the game window may resize while get_input is blocking for input, so redrawing it after ui_manager::redraw instead of in a redraw callback will make it resize incorrectly.

Qrox · 2021-09-09T09:12:40Z

src/inventory_ui.cpp

+            if( selected ) {
+                return selected.any_item();
+            }
+        } else if( input.action == "HIDE_CONTENTS" || input.action == "SHOW_CONTENTS" ) {


What's the unexpected behavior exactly?

ZeroInternalReflection · 2021-09-10T19:32:33Z

I've moved drawing to a ui_adaptor-based setup, and things have checked out fine on my end. The examine screen now draws correctly when filtering/resizing. Some of the setup is still a bit clumsy, but it seems to work.

The keybinding is now 'o' for examining contents.

I also fixed a bug where the item detail scroll rate was based on the size of the item list, and could thus be negative.

src/inventory_ui.cpp

Qrox · 2021-09-11T00:27:29Z

src/inventory_ui.cpp


        const inventory_input input = get_input();

+        //Basically anything the player can do at this point will invalidate the examine screen
+        ui_examine.invalidate_ui();


ui_manager::redraw() always invalidates the topmost ui_adaptor before redrawing. ui_manager::redraw_invalidated can be used if you want to explicitly mark ui_adaptor for redrawing.

Is there a specific sequence you recommend for this? My testing for this was a fun cycle of "the main window draws, but it's not calling on_redraw for ui_examine"->"ui_examine redraws, but the main window doesn't anymore"->"The main window is back, but ui_examine only shows up after user input"->etc.
I remember something going wrong when I didn't invalidate ui_examine, but I'd have to go back and test.

Never mind. It turns out that line was a holdover from a previous iteration where ui_examine was created before calling create_or_get_ui_adaptor. I've removed that line, but left myself a comment at the redraw() call so I remember the thought process.

src/inventory_ui.cpp

stale · 2021-10-12T15:16:41Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not 'bump' or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

Brambor · 2021-10-29T19:56:26Z

Is this ready @ZeroInternalReflection ?

ZeroInternalReflection · 2021-10-30T16:01:17Z

I considered it to be functional as of the last update, and the admittedly-limited testing I'd done had worked correctly.
I see 51490 has been resolved with 51727, so I can probably remove the lines disabling show/hide contents. That's a simple change, though.

… inventory_selector

The previous keybinding of 'c' required a change to existing keybindings in the AIM.

Item detail scroll rate was linked to terminal height, and thus should updated on_screen_resize() rather than in ::execute(). Invalidation of ui_examine was not required since it was the most recently created ui_adaptor. Renamed inventory_examiner::action_examine(item_loc,bool) to draw_item_details(item_loc), since, after refactoring, it wasn't really related to inventory_selector::action_examine anymore.

ZeroInternalReflection · 2021-11-05T17:38:42Z

The commit history for this PR is getting to be a bit of a mess, but I've rebased to the latest version. This mostly resolves the issues with showing/hiding contents (see discussion with andrei8I above), and also brings the new 'g'et menu into the fold.
I believe I have re-tested this on every menu derived from inventory_selector ('w'ield,'W'ear,'T'ake off,'('Disassemble,'E'at,'i'nventory', 'd'rop, 'a'ctivate, 'g'et, etc.). It's currently available from all of them, in addition to the AIM.

ZeroInternalReflection · 2021-11-05T20:29:06Z

Moving my conversation with @andrei8l above to the main thread:
#52659 works nicely in my standard test case:

Of course, having the ability to hide items within this menu introduces a couple of other fun edge cases:

If an item is hidden in this child menu, it should be hidden when returning to the parent menu (I'm currently testing a patch to force recalculation of inventory_column paging when exiting this menu, so this should be resolved with the next commit)
If you attempt to examine the contents of an item whose contents you've hidden, I would expect to still see the contents, but, at present, you do not:

Attempting to dynamically un-hide things when examining contents seems like it'll be fraught with ways to screw up, but I'll give it a shot.
There are certain types of items that are, by default, hidden in the inventory (e.g. a cellphone's batteries). However, the way the inventory_examiner screen is set up, those items are visible. I personally like that, as it makes clear that this could be a separate item, and you're specifically looking at what's inside the parent item. However, since these items are hidden by default, they apparently can't be hidden right now. If you have a cellphone in a container, '>' hide the contents of the container, then examine c'o'ntents, you'll see the battery but not the phone.

Any thoughts on whether a tweak to set_collapsed() would allow these items to be handled as expected?

andrei8l · 2021-11-05T21:14:39Z

1. If an item is hidden in this child menu, it should be hidden when returning to the parent menu

This is just a matter of repaging on refresh (or similar) since collapse status is implemented as a pocket setting. Most likely overkill though and probably out of scope for this PR.

2. If you attempt to examine the contents of an item whose contents you've hidden, I would expect to still see the contents, but, at present, you do not:

That's because is_hidden() only checks if the parent container is set to collapsed, regardless of whether that parent is in the list as well. I don't think you can solve this easily without a lot of looping over all entries in prepare_paging() so maybe just un-collapse the item in inventory_examiner::execute()

3. There are certain types of items that are, by default, hidden in the inventory (e.g. a cellphone's batteries).
Any thoughts on whether a tweak to set_collapsed() would allow these items to be handled as expected?

Move (most of ) the functionality of set_collapsed() to item and iterate over all pocket types instead of just containers. Or add an accessor to item that exposes more pocket types. Both of these are definitely out of scope for this PR though.

ZeroInternalReflection · 2021-11-06T17:53:42Z

Ensuring the paging was rechecked in inventory_selector after hiding something in inventory_examiner didn't turn out to be too complicated, so that's been implemented, hopefully solving the first item I raised above.

For the second item, I did implement a way to expand/collapse the item you're looking at. I'm not a fan of the partial duplication of set_collapsed(), but I felt the cleanest implementation was for inventory_examiner to only look one level deep when expanding. Otherwise, it would need to remember the status of nested items. So, if you examine c'o'ntents of an item that you've collapsed, it'll show you the contents, but any nested containers will still be collapsed. I think that's a reasonable solution.

For the third item, I think I agree that changing the showing/hiding behaviour of things like installed batteries is probably outside the scope of this PR. It'll be a confusing quirk, but it should be a fairly specific corner case now (an item with an installed battery/etc. inside a collapsed container inside the container you're actually looking at).

Qrox reviewed Aug 31, 2021

View reviewed changes

src/item_contents_ui.cpp Outdated Show resolved Hide resolved

src/item_contents_ui.cpp Outdated Show resolved Hide resolved

ZeroInternalReflection force-pushed the ContentsUI50887v2 branch from 8ea1118 to c7fdf60 Compare September 5, 2021 23:24

andrei8l added a commit to andrei8l/Cataclysm-DDA that referenced this pull request Sep 6, 2021

inventory_ui: contents ui

788ac7d

toy reimplementation of CleverRaven#51252 using advuilist

ZeroInternalReflection marked this pull request as ready for review September 8, 2021 19:10

andrei8l reviewed Sep 8, 2021

View reviewed changes

andrei8l reviewed Sep 9, 2021

View reviewed changes

Qrox reviewed Sep 9, 2021

View reviewed changes

ZeroInternalReflection mentioned this pull request Sep 9, 2021

Modify crafting UI to show details of byproducts and jar contents #51496

Merged

Qrox reviewed Sep 11, 2021

View reviewed changes

stale bot added the stale Closed for lack of activity, but still valid. label Oct 12, 2021

stale bot removed the stale Closed for lack of activity, but still valid. label Oct 29, 2021

ZeroInternalReflection added 12 commits November 5, 2021 12:15

Fix merge conflicts after rebasing

3ceb12b

Undo an accidental change to show/hide contents keybindings

eb3e078

Switch from new item_contents_ui class to inventory_examiner based on…

c3b48fd

… inventory_selector

Remove keybindings added for item_contents_ui

70dbb59

Remove inventory sort keybinding added for item_contents_ui

30ba1ee

Switch keybinding for examine contents to 'o'

20c9ff3

The previous keybinding of 'c' required a change to existing keybindings in the AIM.

Remove a duplicate declaration of selected in inv.._examiner::execute

bdf464a

Add a ui_adaptor to inventory_examiner, allowing update on resize

dbffe23

Fix a bug in inventory_examiner where item info scrolling could reverse

53732f5

Fix an error in merging that breaks the pickup menu

9123ade

Remove the block on showing/hiding contents in inventory_examiner

2db305a

ZeroInternalReflection force-pushed the ContentsUI50887v2 branch from 213a2c3 to 2db305a Compare November 5, 2021 17:23

Fix formatting of inventory_ui.cpp to meet astyle requirements

cecba9e

andrei8l mentioned this pull request Nov 5, 2021

inventory_ui: invalidate paging on collapse #52659

Merged

Allow hiding an item in inventory_examiner to update the parent screen

f970a5c

ZeroInternalReflection added 4 commits November 6, 2021 13:06

Move some of the boilerplate setup code inside inventory_examiner

8a1d34a

Do an astyle pass on inventory_ui.cpp

cc3cdfe

Allow examining an item's contents even if they've been hidden

0282c7e

Astyle pass on inventory_ui.cpp

b75d5a9

Resolve clang-tidy errors

503dbc4

kevingranade merged commit a74caca into CleverRaven:master Nov 12, 2021

andrei8l mentioned this pull request Nov 12, 2021

Reimplement trading UI #52572

Merged

This was referenced Nov 12, 2021

Prioritize content description over container description #50887

Closed

Examine contents header and column fix #52854

Merged

andrei8l mentioned this pull request Dec 13, 2022

'g' Pickup menu no longer shows item description #62718

Open

Add a way to quickly examine the contents of an item #51252

Add a way to quickly examine the contents of an item #51252

Conversation

ZeroInternalReflection commented Aug 31, 2021 • edited Loading

Summary

Purpose of change

Describe the solution

Describe alternatives you've considered

Testing

Additional context

RandDenner commented Aug 31, 2021 • edited Loading

Qrox commented Aug 31, 2021

andrei8l commented Aug 31, 2021

ZeroInternalReflection commented Aug 31, 2021

mqrause commented Sep 1, 2021

ZeroInternalReflection commented Sep 5, 2021

andrei8l commented Sep 6, 2021

ZeroInternalReflection commented Sep 8, 2021

andrei8l left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZeroInternalReflection Nov 5, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrei8l Nov 5, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrei8l Sep 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZeroInternalReflection commented Sep 10, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stale bot commented Oct 12, 2021

Brambor commented Oct 29, 2021

ZeroInternalReflection commented Oct 30, 2021 • edited Loading

ZeroInternalReflection commented Nov 5, 2021

ZeroInternalReflection commented Nov 5, 2021

andrei8l commented Nov 5, 2021

ZeroInternalReflection commented Nov 6, 2021

ZeroInternalReflection commented Aug 31, 2021 •

edited

Loading

RandDenner commented Aug 31, 2021 •

edited

Loading

ZeroInternalReflection Nov 5, 2021 •

edited

Loading

andrei8l Nov 5, 2021 •

edited

Loading

andrei8l Sep 9, 2021 •

edited

Loading

ZeroInternalReflection commented Oct 30, 2021 •

edited

Loading