EatDrink.ash: Optimize your daily diet (and see how your old diet stacks up).

[Winterbay]

I guess what could be done is have a check for if current inebriety is larger than or equal to the limit then move on. The problem here was that Mafia thought I was at 19/19 while KoL actually knew I was at 20/19 so any continued drinking would've failed (and it was in the overdrinking-phase so my first idea of a check wouldn't work).
So not sure how to safeguard against that...

Edit: As an indication of how bad the lag was: It took me 5 hours to automate 230 turns

 

[xKiv]

Isn't the VoA an average of how much you are willing to spend to gain a given amount of adventures?

Nitpick: this is incorrect. VoA is "how much I value generating 1 adventure". The difference is importatnt because EatDrink maximizes "total value of adventures minus cost of consumables".
If you want to maximize "number of adventures, subject to maximal price of consumables per adventure generated", you are looking at the wrong script.

(example reduced to absurdity: VoA=500, only two possible choices of what to consume; first food costs 5000 meat and generates 10 adventures; second food costs 500 meat and generates 2 adventures -- option "I am willing to pay up to 500 meat per adventure" will pick the first food, and you will end up 10 adventures later with a grand total of +- 0 meat to your name -- option "I want profit!" picks the second food, you only play 2 adventures, but end up at +500 meat).

I think we had a discussion on that a few months back.

 

[fronobulax]

I think we had a discussion on that a few months back.

Yes we did. An IP formulation/implementation of the consumption problem is still in the kitchen although not quite on the back burner.

 

[Theraze]

I guess what could be done is have a check for if current inebriety is larger than or equal to the limit then move on. The problem here was that Mafia thought I was at 19/19 while KoL actually knew I was at 20/19 so any continued drinking would've failed (and it was in the overdrinking-phase so my first idea of a check wouldn't work).
So not sure how to safeguard against that...

Edit: As an indication of how bad the lag was: It took me 5 hours to automate 230 turns

Actually, it does already have a check for that...

            if (my_inebriety() > inebriety_limit()) {
               giveup = true;

which means that, in your case, mafia wasn't updating to realize that it had passed its inebriety limit. I believe the way that mafia's "I've drunk too much!" system works is that it makes my_inebriety equal the drink-1 if it fails and it doesn't expect it to... so it's not really mafia's fault either. The script does try to pick a new 'best' item every iteration, and it does that based on the doneness that mafia gives it, since it uses this to help pick...

 verbose("Choosing "+type+" to consume.");
 filter_final(conmax, doneness(type));

And that uses the following 2 bits...

void filter_final(int max, int current)

(which runs against desired and...)

int doneness(string type)
{
  if (type == "food")
    return get_fullness();
  if (type == "drink")
    return get_inebriety();
  if (type == "spleen")
    return get_spleen();
  abort("Invalid type "+type);
  return 0;
}

which returns what information mafia thinks it has. If it's still trying to drink 4 inebriety things when you don't have that, it means that mafia is still telling it that it can drink them.

Bottom line, EatDrink is only as accurate as the information mafia gives it. Nothing we can do when mafia doesn't update its doneness.

Regarding tgetgel's question... xKiv is right. It's more based on how much profit you intend to make, not how much you're willing to spend to get another one. This both raises and lowers VoA... it raises VoA, because a higher VoA means you're wanting to finish up faster and you value your time. It lowers VoA, because it means you're expecting to actually generate profit, not just break even.

I found that when I raised VoA to 1000, it meant that all the various drinks and mixers from the barrel full of barrels actually started to be possibilities in the rotation, which was good because instead of ending up drinking straight rum or something similar, it would actually mix up (at least) a whiskey and soda, or drink those White Canadians. With a low VoA, while crafting, market fluctuations can tank your daily consumption plans. It might be good for your profits (if anyone will actually buy them), but your ascension may take another 2 days... or even longer.

 

[xKiv]

Yes we did. An IP formulation/implementation of the consumption problem is still in the kitchen although not quite on the back burner.

I think the IP implementation is a different animal - and might hit more snags than I thought previously, because of the various acquirable-amount limits (you would need to consider each unit of the item as a separately optimized variable) and rising prices of an item as you buy out the lowest-priced ones (see previous parenthesis + mafia won't tell you what all the prices are before you start buying).

 

[Theraze]

Well, it already uses get_on_budget to purchase, which uses your price_flexibility based on its purchase price... so you aren't going to end up spending above what EatDrink expects, outside of your approved range.

 

[fronobulax]

I think the IP implementation is a different animal - and might hit more snags than I thought previously, because of the various acquirable-amount limits (you would need to consider each unit of the item as a separately optimized variable) and rising prices of an item as you buy out the lowest-priced ones (see previous parenthesis + mafia won't tell you what all the prices are before you start buying).

Good point but as a first approximation I would accept an optimal solution that used historical prices. If there is ever code that does that then extending it to a more practical problem and solution could be done. There definitely is some tension between a desire to be optimal based upon 'real-time' prices and the desire to not implement features that would allow mafia to be scripted into a MallBot. The latter concern should pretty much trump everything else, IMO.

I note that looking at an IP formulation is something I favor because I understand it. I can explain the inputs, the outputs and the effects various choices have on the solution. It allows differentiation between adventures and acquisition costs rather than equating them in some fuzzy way by an arbitrary valueOfAdventure variable. I will make statements about optimality that I know to be true. That said, EatDrink is a pretty good 80% solution and given the relatively static nature of most of the inputs there may actually be very little practical value to an IP solution. (If there were ash tools to solve a general IP, imagine the potential for a one pass outfit optimizer...)

Tangentially, I note that the problems of "what to use" and "how to acquire it" could be separated. Once again, I have an interest in a speculative_acquire that would tell me (the scripter) the costs of using mafia's acquire function.

 

[xKiv]

one pass outfit optimizer...)

Outfit optimization is not a linear problem. Proof: when maximizing items with a item-drop familiar, any +familiar-weight introduces a square-root component.
(how many other non-linear parts of outfit optimization are there?)

 

[fronobulax]

Non-linear (in general) doesn't scare me but you clearly have thought this through deeper than I have Scratch that idea ;-)

 

[Theraze]

Here's a question I was thinking about today... could set it so that best() is run between every decision instead of repeatedly consuming the same item until you run out. This might vary the consumptions somewhat, since it prefers items that there are quantities of, but probably wouldn't change too much around... is this something I should try out myself for a few days and upload if it works, or do we like the current best() system?

This wouldn't quite be to the full ConsumeLast level, but eventually might be similar. What I was just thinking of would be either a 3-choice preference for ConsumeLast, or an additional boolean for QueueAlways or something similar. The choices would be:
1) Act like now. Eat the single best item, repeat.
2) Make a consumption plan and craft it while eating. Reconsider if something better happens to show up partway through.
3) Make a consumption plan and craft it all, then eat it.

3 would be the truer ConsumeLast, as it is trying to save turns of milk and ode from adventure burn. However, for people with Inigo or Boxen, 2 would be the more appealing option. For the less trusting, 1 would provide the EatDrink experience they feel comfortable with.

I'd be fine with completely scrapping 1 once we're certain that 2 and 3 are both reliable. It comes down mostly to if we care about people complaining about speed of calculation, as creating multiple stacks of consumption plans based on all possibilities will likely take a few additional seconds, especially when in aftercore. The benefits should definitely be worth it, though... If we do completely scrap option 1, we could just function based on the current ConsumeLast value that's already being set.

One additional thought... Option 3 could (instead) function like this:
3) Make a consumption plan and craft it all. Reconsider if something better happens to show up partway through consumption that doesn't involve crafting.
The problem with that is it makes 3 more messy. The benefit is that we aren't locking them down if something bizarre happens along the way. Though since there aren't really crafting failures, there's no real time when it makes sense to use modified option 3... when in aftercore, you'd want to use option 2 because the mall will probably be better than you can craft at cost. Option 3 modified is only really useful in cases of aftercore with a price flexibility of 1, so a raised-price purchase fails...

Once we have the framework of eating plans sorted, we should be able to generate at least an initial consumption plan that will get you completely full/drunk if possible and it provides more total adventures than just single best items... This wouldn't relate (directly) to whether your example of pear tarts or bat wing chow meins would be purchased, but part of the consideration would be creating the stack with total cost, and then comparing that to a lowered speculative VoA stack. This would hopefully then decide on pear tarts (or something similar) that provides for a better total experience.

 

[fronobulax]

3) Make a consumption plan and craft it all. Reconsider if something better happens to show up partway through consumption that doesn't involve crafting.

How would you do this? What is your detection criteria for something better showing up? How efficient would this be in terms of server hits to get information to see if something better is available? Do you mean just craft or a more generalized acquire?

Once we have the framework of eating plans sorted, we should be able to generate at least an initial consumption plan that will get you completely full/drunk if possible and it provides more total adventures than just single best items...

I can prove that is not true although you will need a good grounding in linear algebra and related mathematics (i.e. think third year in an American college in a technical major) to understand the proof. Alternatively, perhaps I don't understand how you get the initial plan and what you then do to see if there is a better one. Perhaps you always calculate the plan by doing "best item available" but create alternative plans by looking at various VoA values?

 

[Theraze]

Regarding 3, disable EAT_MAKE for the purpose of calculation, after crafting the items. Since it will already have crafted the items it wants, either it will be able to purchase cheaper items, or the best items will remain the same that it has already crafted.

Regarding framework, what I'd likely end up doing would be changing best() to be best(gain). Since 'gain' is appetite/drunk/spleen, if it finishes queueing and there is still appetite/drunk/spleen remaining, go back a step or two and consider best(gain-1) and then finish off the rest of the sequence, compare that to the prior series. If room remains, check best(gain-2), repeat until gain-<number> equals 1. This does mean generating (generally) up to 5 sequences initially to decide on 'best' for given VoA.

This same series will be considered against the speculative VoA. What I said earlier was this:

What we may need to do is if my_meat() < VoA*ConsumptionLimit, run a speculative VoA against my_meat()/ConsumptionLimit for VoA. If the speculative works better for total adventures, run that level of VoA instead of your saved VoA. This would only lower VoA, not raise it.

This would still run the same as the sequence I mentioned earlier. If the consumption level is completed with the first, it will stop there. If not, it will use the same gain-<number> until either it ends or it finds a better result.

With this, I expect to keep 3 or 4 stacks. Best (complete), progressive (almost done - one step off complete), and speculative (trying to finish the stack). The best would be whatever the complete series would be... there will be a best stack as soon as it finishes once. Progressive will be used as soon as the first step has begun... Speculative is the initial step... There may be a 'test' stack that is only worth the remainder of the last item of consumption... generally 2-5 after finished.

Sequencing full appetite, in my current mindset:
1) A 'best' item is decided through best(15). If an item (we'll call this item2) is found for best(15-item.con), add the first 'best' item to the speculative stack.
2) If there is another item (item3) found for best(15-item.con-item2.con), move the speculative stack to the progressive stack. Add item2 to the speculative stack.
3) Repeat until no 'best' item is found. The progressive stack is now done.
4) If the progressive+speculative stack is higher than the best stack, replace the best stack.
5) Check for best(item4.con-1). If progressive+test is better, set that to the speculative stack.
6) Repeat the check until it runs out. Set the best progressive+speculative on the best stack.
7) Repeat 1-6 using the speculative VoA listed above.

 

[Theraze]

Started some initial work in this... currently have done the following:
1) New internal variable, USE_STACK. Currently forced to true on my copy, because I don't want to dump in a lot of useless preferences I'll just be scrapping, but will eventually be removed once the stack is fully successful.
2) New map named consuming.

int [item] consuming;

Items are currently added to this map as the consumeone function runs. If USE_STACK is on, it runs a check to see if consuming contains con.it already. If so, it adds one to the value. If not, it makes consuming[con.it] = 1. Items in here should be able to be considered at any time following their addition.
3) New int value added to the con_rec record type, using. This is so we have easy checking for how many items are still available after our usage, since once we have stacks working properly, it should try to plan everything before the first item is used, whether ConsumeLast is configured and it will go through the whole stack, or if it plans another stack following the first item. If we're not using ConsumeLast, it should wipe this when a new consumption stack is begun, but for now it sets this to 0 when the item is loaded (in update_from_mafia), is incremented by 1 when an item is planned to be used in consumeone, and decremented by 1 after consumption happens in consumeone - after ateone in both the SIM_CONSUME false and true segments. In the functions effective_price, set_prices, inbudget, and filter_final, it checks for con.having - con.using as its usable amount. In availability, after it does all of the other additions, it runs con.have = con.have - con.using, so that used items count against the availability.

These changes shouldn't actually affect the way EatDrink runs for me tonight, yet. If I have it express the consuming map, it should give me a result similar to the summarized food, but simply telling me which items it ate and how many of them were eaten total in that script execution. Though con.using is counted against availability and those, it's only incremented and decremented inside USE_STACK inside the consumeone function, and it should always (currently) return 0 if checked outside of that function.

Any thoughts or caveats I should keep in mind? My plan is to have it run like this for a bit, then split the stacking and consumption into a minimum of two functions - stack and consume - or possibly three - stack, obtain (have/pull/buy/create), consume. Once it properly runs in a multiple-stage process, I can begin speculating against stacks.

Working through the above sentences, I think the 3 function process should work better... with the ConsumeLast preference set it would just stack fully, obtain fully, and then consume fully. The normal behaviour would be stack fully, obtain one, consume one, clear stack, stack fully, obtain one, consume one, repeat. Takes more time, but should provide better overall results, since it's giving you the best result based on the fullness you have left and your current situtation.

One strong possibility as well would be changing the map (consuming) to a record type. Position in the stack matters, so I've been somewhat torn in terms of whether it would best be served as an array, but the problem is that with mojo filters and other items, I can't just have the array max size be conmax (the desired full/drunk/spleen) because it might be significantly larger by the time it's done... *ponders*

If I just make a map like this...

item [int] position;

then I can do position[0] = con.it, position[1] = next con.it, etc, right? That should skip out of the record issue, give me position of consumption, etc...

Okay, set a new int, maxposition, which is reset to 0 on each iteration of the consumption series. This ties into the item [int] position above, and should let me plan a stack and repeat it (in order).

Excellent... currently it displays the items as it's adding onto the stacks, which is rather spammy as it goes, but shows that it's working properly. Though it also shows me that I need to have it wipe the stacks once they're done, so I don't get this:

simulating consumption of one chocolate seal-clubbing club.
In position 0 is chocolate seal-clubbing club
In position 1 is slip 'n' slide
In position 2 is slip 'n' slide
In position 3 is slip 'n' slide
In position 4 is fine wine
In position 5 is fine wine
In position 6 is fine wine

Had it remove each entry in the position table between iterations, and it now works...

simulating consumption of one chocolate seal-clubbing club.
In position 0 is chocolate seal-clubbing club
1: chocolate seal-clubbing club lev:0 gain:1.0 adv:3.0 musc:0.0 myst:0.0 mox:0.0 meat:2400 own:0 value:600

Anyways, it runs, it stacks in order, it clears... I'll spam myself a few days and ponder splitting the functions out. As I said above before I came up with the position map, yell if you have caveats for me. Otherwise, I'll try to split things together and post the split-function version so it can be validated to run the same for other people as well as myself... odd how things run differently when they get out into the wild. Part of this would be that the milk/ode could be compared against the full stack, so it would have milk still work with a VoA as low as 100 or less, depending on mall prices...

Once it's validated to have proper base-code, my plan for the next step is 2 stacks... configured VoA, speculative VoA if lower, and automatically use whichever of the two is best... If you can save some meat and still end up with more total adventures, that counts as a win/win in my book.

After we have speculative VoA working properly, my next plan is to start messing with the decision of what makes the best last item. If it wants 2 +5 adventure 3 fullness items with 8 current fullness (10 total gain, 6 fullness, 1.66 adv/full), but we can use 7 items that provide +1.5 adventure at 1 fullness (10.5 total gain, 7 fullness, 1.5 adv/full), we've ended up a TINY bit better. Not much, but every adventure helps. We'd likely want this to be another preference though, because what we're doing is (potentially) reducing our efficiency for the day because of wanting immediate gains. This would be most useful early on in low-skill HC or BM ascensions when you're moderately likely to end a day or two with 13/15 fullness or to go into your overdrink with 12 or 13/14. After you start getting access to more locations and crafting, it's less likely to end up bringing extra adventures. Additionally, this would help in cases (beginning using the example above) where you have 2 items that are +3 adventure, +3 fullness as well as 4 that are +2 adventure, +2 fullness. Instead of eating to 14 fullness for 6 adventures, it would eat to 15 fullness with 7 adventures (begins with one of the +3 fullness items before eating 2 of the +2 fullness items) giving a bit of benefit...

We can skip that last step if the collective thought is that it won't be useful or used. I just noticed early on in ascensions that my fullness often ended up missing a bit, and would be curious if it could be utilized more efficiently. Personally after level 3 or so, I'd just as soon disable that though...

 

[tgetgel]

I'll spam myself a few days and ponder splitting the functions out. As I said above before I came up with the position map, yell if you have caveats for me. Otherwise, I'll try to split things together and post the split-function version so it can be validated to run the same for other people as well as myself... odd how things run differently when they get out into the wild.

I am willing to test it out in BM (DB kitty core - done except for freeing the king and doing a couple of trophy things).

 

[Ferdawoon]

Ehhm, what happened here? r9260
Just updated zlib, but other than that, no difference to yesterday when it worked.
Mafia show me as 19/19 drunkeness.

******************************************
Now, to recap...
******************************************
Starting EatDrink.ash (version 3.1.3).
Consuming up to 14 food, 19 booze, and 15 spleen
Considering food from inventory Hagnk's the mall. Per-item budget cap is 25000.0.
Price will be a factor if you own it already. Hagnk's pulls (if enabled) will cost 1000 meat each.
An adventure has the value of 777 meat. Mysticality subpoint is 5.0. Nonprime stat subpoint is 1.0.
food: At 0, consuming to 14.
0: milk of magnesium price: 870 value: 2238.0
1: spooky lo mein lev:6 gain:4.0 adv:18.0 musc:0.0 myst:0.0 mox:33.5 meat:1300 own:0 value:3188
2: spooky lo mein lev:6 gain:4.0 adv:18.0 musc:0.0 myst:0.0 mox:33.5 meat:1300 own:0 value:3965
3: spooky lo mein lev:6 gain:4.0 adv:18.0 musc:0.0 myst:0.0 mox:33.5 meat:1300 own:0 value:3965
4: handful of nuts and berries lev:12 gain:1.0 adv:4.0 musc:0.0 myst:55.0 mox:0.0 meat:745 own:0 value:3690
5: handful of nuts and berries lev:12 gain:1.0 adv:4.0 musc:0.0 myst:55.0 mox:0.0 meat:745 own:0 value:3690
drink: At 0, consuming to 19.
1: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
2: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
3: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
4: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
5: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
6: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
7: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
8: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
9: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
10: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
11: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
12: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
13: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
14: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
15: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
16: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
17: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
18: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
19: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
20: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212
spleen: At 0, consuming to 15.
1: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
2: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
3: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
4: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
5: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
6: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
7: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
8: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
9: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
10: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
11: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
12: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
13: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
14: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
15: stench wad lev:6 gain:1.0 adv:1.0 musc:18.0 myst:27.0 mox:9.0 meat:430 own:0 value:671
choc: Checking non-filling crimbo chocolates - all 3 kinds
Best find was chocolate saucepan with a value of -169. That's no good, so not consuming and moving on.
Finished. You had Milk of Magnesium-Ode to Booze in effect. Adventures listed above does not reflect that, but this does:
Spent 20950 meat. Gained Fullness: 14. Inebriety: 19. Spleen: 15. Adventures: 167. Muscle: 1310. Moxie: 224. Mysticality: 513.
Eating, drinking, and spleening complete. Commence merrymaking (at your own discretion).

 

[Winterbay]

That looks like a normal summary, or am I missing something?

 

[Ferdawoon]

It say it is drinking to 19, yet it drink a 20th cup. Mafia show me as 19/19 as well. So, a lag bug? Some way to prevent overdrinking due to some lag thingy happening?

Consuming up to 14 food, 19 booze, and 15 spleen

20: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:399 own:0 value:3212

 

[Winterbay]

Ahh. If you open up the relay browser what does your drink status say?

 

[Ferdawoon]

I closed Mafia and restarting the session ofc let mafia know that I am 20/19 drunk. Did not check what the relay said, but 80+adv spent in the Drunken Stupor before I noticed would indicate that I am indeed overdrunk =S

EDIT: 20/19, not 20/20..

 

[Theraze]

Yeah... if you lag like that, there's no way to really protect you since KoL doesn't tell mafia how much food/drink you've actually had, it's working based on mafia's information... but mafia doesn't update if KoL lags and misses it.

What we CAN do, after I get it sorted a bit more, is generate the consumption stack and have it set not to recalculate initially... that would should make it provide the same results that EatDrink currently does. The recalculating stack (when it happens) will still be affected by lag, since it will calculate based on the information that mafia is giving it, but...

What we probably want to have is a "EATDRINK_RECALCULATE" boolean that defaults to true... if it's set true, the stack will recalculate while it's consuming (should be more optimal than the current EatDrink behaviour for non-lagged people). If it's set to false, it will just use whatever stack it initially creates, and won't change it even if it finds it impossible later (due to price variances or the like). The benefit though is that if you're lagged, it should just consume however much drunkenness you told it to do initially, even if lag means that mafia thinks you still have drunkenness available. If you choose to ignore it and re-run it after, that's your choice, but at least you'd have a setting that's lag friendly.