Feature - Implemented Don't empty consumption queue after unconfirmation

[Nappa]

If you queue some booze in the item manager, when you hit 'Consume' it will check whether you have ode active. If not, it may ask 'Are you sure you want to drink without Ode?'. If you reply 'No', Mafia will not proceed with the consumption. However, it will clear the queue of any/all remaining items. Is it possible to change this so it will leave the items in the queue alone?

(This will probably also be applicable to food consumption w/ milk and fieldgar)

 

[Bale]

Seconded! This has happened to me many times. It would be much more convenient if I didn't have to queue them up again after being warned by KoLmafia.

 

[Veracity]

Me too.

 

[Veracity]

Actually, my experience is that if you queue multiple items, it will consume them in order until ode or milk would run out and then it will prompt. If you say "don't do it", it will continue on with the next queued item and check again - and it may or may not prompt. If you have 3 turns of Ode left and a 4, a 2, and a 2 queued, it will prompt for the 4, drink the 2 (reducing Ode to 1) and prompt for the last 2. In any case, the queue is emptied.

Looking at ConcoctionDatabase.handleQueue, that is exactly what I see: it pops everything off the queue and processes them in order, calling UseItemRequest for each item - which is where the "do you want to continue" checking happens. It never checks for whether UseItemRequest failed. Presumably if it does fail, it should abort processing right then and restore the queue - including re-queuing consumption helpers.

That is a change of behavior from the current situation, where if you say "no", it will go on and (possibly) succeed with a smaller size consumable which is later in the queue.

Is that how we want it to work? If you say "no", it should stop right then, rather than moving on? I think so.

 

[Bale]

I agree with you.

 

[Winterbay]

I think so too. It would be a great addition to the already excellent consumption handling.

 

[Nappa]

I think it would be a good idea. If the current behavior is very valued by some though, it might be an option to leave this as a choice to the user, a 3-choice where OK = consume without further confirmation, Skip queued item = current behavior, and Abort consumption queue (= proposed change, restore unconsumed items to the queue).

 

[Veracity]

Bump to remind myself to Make It So.

 

[Veracity]

OK, revision 12740 should do it. Tested with milk:

got 10 turns of Got Milk
queued 4 super salad (12 full) and a handful of nuts and berries (1 full)
Consume
prompted: Milk will run out before finishing those (on 4 super salad). Are you sure?
Said no.
4 super salad and 1 handful of nuts and berries re-queued.

Observations:

- In order to make this work, I had to make EatItemRequest and DrinkItemRequest print a red error message when consumption was disallowed. I'm actually surprised they didn't behave like that before, since they do that if your food helper is not available or you are insufficient level to use the item. In this case, just like the others, eating/drinking failed.
- The "milk will run out" confirmation dialog doesn't identify which item & quantity was being consumed. Considering that the queue is already cleared and being sequentially processed, you can't automatically tell how much has been done already.
- The "queue" is displayed & handled sort of funny

as you queue things, internally, they are "pushed" on a stack
when we execute the queue, we pop them off and push them on a different stack
and then we pop them off the second stack and consume them.

So, pushing on the first stack reverses the order of the "queue", leaving the items in reverse order.
Popping items from the first stack removes them in reverse order
Pushing items on the second stack leaves them in original order
Popping items from the second stack processes the items in the order they are queued.

However, when I look at the queued items, they seem to be displayed in inverse order - i.e., the order they are on the first stack. That seems a little confusing. I'd like to see things added to the bottom as you queue them and removed from the bottom as you dequeue them, so you can see exactly what will happen in the order it will happen.

 

[Veracity]

Looking at the code, the "queue" being displayed is simply ConcoctionDatabase.usableList - in whatever order it is in, which is probably by itemId - but with everything that is not "queued" filtered out from being visible.

I suppose that is why you can queue 2 of an item, queue something else, queue another of the first item, and you see 3 of that item queued.

That's a little confusing, when you include consumption helpers; it'd be nice if it showed that I queued two wrecked generators, then a Frosty's mug, then another wrecked generator, for example, so I can look at exactly what will be done in what order. The actual "queue" has that information in it, but the Item Manager doesn't show the actual "queue".

That would be a different Feature Request, though.

 

[Nappa]

Didn't really keep up with this request, but I noticed today that you implemented this. Sweet, thanks!