-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Consume item" window is reset if a filter was set #36884
Comments
I've found that the consume item menu was helpful when driving because it would flash the screen when the vehicle would move. It helps me not crash into something while eating and driving, but it is indeed annoying when it flashes just holding down the enter key to eat a lot of food. I also never saw the reason for why it took up so much of the screen, I feel like it could be nice to have it as a side menu like the examine menu instead. |
I've found slightly different behaviour (latest build and recent experimentals) -- the menu seems to reset a lot more than expected, when the base menu (total amount of consumable items) contains items in multiple locations, whether filtered or not. I haven't been able to exactly pin it down, but I think the issue occurs when the unfiltered menu source items are in more than one location, AND when the results are unfiltered, OR when the filter returns items in more than one location? Example: spawned a page and a quarter of items in latest build. Some in inventory, some on floor below me. Eat any item in the list, the list resets to top item after consumption. Filter down to a list that is less than a page, but items are in more than one location, list still resets to top item after consumption: Filter down to a list that is only 3 items long, but items are in 2 locations (inventory and cupboard), list still resets after consumption: Filter down to a list that only has items in one location, list does NOT reset after consumption (which is correct behaviour IMO): Was able to replicate a smaller instance with just a few items but in two locations, the list reset to the top item in this case too: |
I just messed with this a little myself. I had to get it down to exactly one purple heading in the menu myself for it to stop resetting, and the last offender was a worn canteen with 2/6 water in it. |
Can confirm this as happening for me without filtering as in #38014. |
@scorpion451 can you please elaborate and maybe post a screenshot? Specifically is it occurring when your E menu contains items in multiple locations and/or multiple states of edibility? |
Occasionally I've been getting a "tried to duplicate item" message on eating, too. I'll grab the log next time in case it's relevant, and do some testing on eating. |
The two bugs are most likely related to an underlying problem, as the source of the duplicate item debug message was triggered by the attempts to refresh the consume item menu. |
This. I experimented with it a bit and the problem seems to only happen if there's a container in the filtered list. This also explains #38014 (comment), since the consumables in the screenshot there are all contained. |
#38342 probably stems from the same cause then as it's happening with all containers. I just had a canteen of water disappear, was about to update that it wasn't to do with freshness after all but is simply to do with containers. I've tested further and it affects any container, empty or not. |
Describe the bug
Normally, after you eat something, the "consume item" window will reopen and auto-select whatever you just ate if you had more of it. However, if you set a filter using
/
, the filter is reset and the first item in the list is auto-selected.Steps To Reproduce
Steps to reproduce the behavior:
E
and then/
, then enter something to narrow down the listExpected behavior
The item you just ate should be auto-selected regardless of whether you set a filter. As for the filter, this is less clear since there are a lot of different UI windows with filters, and they are not consistent at all with how they handle this issue. I am tentatively thinking it should stay until the window is manually closed.
Versions and configuration
Dark Days Ahead [dda],
Disable NPC Needs [no_npc_food]
]
Additional context
There's another mildly annoying UI bug with this window, but I'll write up a separate report for that.
The text was updated successfully, but these errors were encountered: