Feature - Implemented Wanting to Eat With Milk Clears Food Queue

icefall5

Member
In the Item Manager, I always queue food then eat it all at once. If I forget to drink milk beforehand, the typical box pops up asking if I'm sure I want to eat without milk. When I hit no, however, my queue is cleared. It would be nice for the queue to stay where it is while I run to the drink milk button, then I can hit Consume again and life is good.

If it helps, the food I ate today required that it be made by mafia first. Somewhere in the process of clearing the queue it made one of the two foods I had queued (both needed to be made), but it didn't have me eat it (because I told it not to). The "Are you sure you want to eat without drinking milk?" window popped up a second time after that was done, I clicked no again, then it was done and my queue was cleared. I'm running r9782.
 
On a perhaps related matter, mafia has (or at least did some 50 revisions back when I last did the following) issues when you cancel a consumption that had helpers (flutes, mugs, forks, etc.) queued up, or the consumption otherwise fails. What I remember happening is that I'd cancel a consumption with helpers queued (or the consumption would otherwise get stopped, perhaps due to low HP when using mugs/forks), I'd go and eat/drink with helpers in the relay browser manually, and if I tried to consume other stuff later mafia would try to use the previously-queued helpers again. Even if I no longer had any in inventory, which would result in a red error state. I probably need to give more accurate details on this, but it's been awhile. If no one else chimes in with their own experience, I'll see if I can replicate this problem.
 

roippi

Developer
Fred, that's not really related at all. If you get a repeatable result, make a new bug report.

icefall, this sounds like a feature request; mafia is operating as intended by the programmers, but you would like it to behave differently. I'll change the tag.
 

icefall5

Member
icefall, this sounds like a feature request; mafia is operating as intended by the programmers, but you would like it to behave differently. I'll change the tag.
I was debating between the two, but why would it be intended that the queue be cleared, one of two foods needing to be cooked was cooked (instead of both or neither), and that I would be asked the question a second time? This sounds like a bug to me, regardless of whether it's intended that the queue be cleared or not.
 

Winterbay

Active member
Per definition if something behaves as it was programmed and not as a consequence of an error in the programming it is not a bug. Changing that would then be a feature request.
 

fronobulax

Developer
Staff member
Per definition if something behaves as it was programmed and not as a consequence of an error in the programming it is not a bug. Changing that would then be a feature request.

So if the programmer made a logic error or wrote code that was based upon an incorrect assumption about how KoL worked then what would you call the observation that something wasn't right and a request that it be corrected? The implementation behaves exactly as programmer intended but there was something flawed nevertheless.
 

roippi

Developer
This is an age-old debate. The idea is that at some high level, there is an intent to perform some action; the programmer takes that intent (i.e. "I want to be able to create items in mafia"), turns it into a specification (i.e. "the CLI command 'acquire' calls this method which recursively calls these other methods), and implements it. If the programmer was making an incorrect assumption to do x, I'd say that there was a higher-level intent to do y, which was not fulfilled by the programmer's implementation - making it a bug.

In any case, a bug is categorically not defined as "does not perform as the end-user thinks it should perform." Users can have wildly varying opinions on what a program should do.
 

Veracity

Developer
Staff member
Is that the situation here, fronobulax, are are you just trying to make a rhetorical point? I'd say the latter.

There are several issues here:

- The code for Milk and Ode were originally written when the effects did not go away when you consumed items. KoL changed and you lose turns of the effect when you consume, so you can lose the effect before finishing your consumption.
- If you don't have Milk active, making the item can use turns.

Combining both of those, you can use milk, consume (some of) your queue, be told that milk will run out before finishing eating - and then have to go spend a turn to craft more, perhaps.

Given that, I think it's pretty clearly not a BUG, per se, to require you to rethink your crafting and such before executing your queue. I frequently re-queue fewer items to use my remaining turns of Ode or Milk and then craft milk or cast Ode later to finish my consumption.

On the other hand, I think it would be a reasonable implementation to check if you have enough turns of Milk and Ode to cover your whole queue BEFORE consuming anything and tell you up front if you don't.
If you say "go", use the whole queue without further prompting.
If you say "no", abort without consuming anything, leaving the queue intact, and let the user adjust the queue and/or get more turns of the effect before trying again. For MY usage pattern, that would involve dequeuing a few items and saying "go" rather than re-enqueueing a few items and saying "go". For ME, it's a wash.

Changing the behavior like that is clearly a Feature rather than a Bug fix.
 

fronobulax

Developer
Staff member
Probably rhetorical, but the OP's expectation that when things were queued the execution would be ALL or NONE at least suggested to me that investigation would be worthwhile. I also confess that I find that making too fine a distinction between a Bug and a Feature Request is often an impediment to progress unless, of course, I am the one whose work is being referred to as a Bug ;-)

Continuing in a rhetorical vein, when KoL changed Milk and Ode so that the effects did go away with consumption, how should things be categorized? The code did exactly what it was intended to do but the KoL change made that fact somewhat irrelevant. In this particular case I actually like the New Content tag because it implies that some things are neither preferences or mistakes but merely events beyond "our" control. Can we apply that to a KoL change that happened a while back?
 

Veracity

Developer
Staff member
I think it is New Content - and it more serious than I described above. This has been mentioned elsewhere, I think, but if you queue up Fancy food or booze and don't have the appropriate box servant, you will use turns crafting - and if you cast Ode or drink Milk before you start, you will potentially run down turns of the effect before you even begin your consumption, depending on where the crafting happens in your queue.

You can not only queue up more fullness or inebriety than your current effect can boost, you can also queue up overhead turns for crafting.

So, do you do all your crafting first and THEN look for Ode or Milk? Or, if you have (some) turns of Ode and Milk and some - but not all - of the items you have queued are already in stock and others require turns to craft, do you consume the in-stock items first and then warn? What about consumption helpers? I want the divine champagne flute to be used before my to-be-crafted 4 inebriety drink, not my in-stock (or free-to-craft) pumpkin beer, say.

This is looking more and more complicated.
 

stannius

Member
I vote for the proposed solution to abort consumption but leave the queue as-is. Although, in a related feature request, it would be nice if there was some way to create everything in the queue but leave it there.
 

Veracity

Developer
Staff member
Code:
r12740 | veracity0 | 2013-09-28 15:32:49 -0400 (Sat, 28 Sep 2013) | 6 lines

When eating/drinking things on the consumption queue, if the user says "do not
continue" because Ode or Milk will run out, abort processing queue and
requeue failed (and unprocessed) items.
 
Top