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

Unfortunately that code won't work :(
Code: 
if(get_revision() >= 9599)
{
	record fullness_file_entry // holds the map found in fullness.txt
	{
		int consumptionGain;
		int level;
		string adv;
		string quality;
		string muscle; 
		string mysticality;
		string moxie; 
	};
}
else
{
	record fullness_file_entry // holds the map found in fullness.txt
	{
		int consumptionGain;
		int level;
		string adv;
		string quality;
		string muscle; 
		string mysticality;
		string moxie; 
	};
}

fullness_file_entry [item] map;
file_to_map("fullness.txt", map);
print(map[$item[chorizo taco]]);

Generates:
Code: 
> verify test.ash

Unknown variable 'fullness_file_entry' (test.ash, line 28)
 
Post 1025 has a new version (3.1.4) but is 20k smaller (more in line with post 1)than the one Theraze posted in 1008. The one I'm currently using is the one Theraze posted in 1008 with the fixes he posted this morning. Does this one incorporate Theraze's changes?
 
Winterbay said:
Unfortunately that code won't work :(
Click to expand...

Well darn, especially since I thought I tested it.

@Donavin69 - the version in #1025 has only the one change, compared to the "official" release. #1008 has a lot Theraze's work in progress. If you want to help test Theraze's work, which I encourage, then you should make the change yourself or see if Theraze has an update to #1008 to share.
 
Last edited:
I'm thinking we'll wait for the proxy fields to be added before attaching the latest version... I need to know if I should use it.adventure, it.adventures, or it.adv for the range. :)
 
I took your patch - and also changed ItemDatabase to return an empty string, not a null, for items with no consumption data.
 
Have I said today that you're awesome? :)

Okay, here's a new copy of EatDrink v3.1.4 - updated by 1 minor point from 3.1.3 - making it the same version number as the stable release.

Includes the various changes I've noted above, and includes using item proxies instead of directly reading the data files. This does mean you'll need to use mafia 9602 or newer to use this version...

Edit: The version here didn't do spleen. The one below should.
 
Last edited:
Anyways, proxy records were added to mafia for consumables, so we can leave EatDrink 3.1.3 as the final "14.7 and before" version until we want to remove it.
 
Hey guys,
Putting on my water-wings and swimming out to the deep end of the pool here,

The version of eatdrink posted at #1047 seems to really hate spleen. It used no spleen items at all. Error is "No spleen available that's good enough. Moving on." Seems to apply to a pretty large range, value of adventure was 800-1500. Mafia version is 9604.

I'm not sure if I have something screwed up in my settings, or this is a real problem, or if this is actually the problem ya'll are currently discussing.

Anyway... I'm gonna wade back to where I can touch bottom.

Thanks for all ya do! Let me know if I can help from the kiddie pool.
 
#1047 does not spleen. I seem to recall some discussion of a filter parameter that effected it but with all of the fullness file discussion I didn't find it. Out of the box ED should spleen so we need to know what this parameter is and find a better default value for it.

Edit:

The quality value for all spleen items seems not to be set. I'll let someone else figure out why. Workaround would be to set eatdrink_minimumQuality to something low but setting to -2 does not work for me.
 
Last edited:
The item description for a food item says, for example, "Type: food (decent)".
For a drink, "Type booze (good)".
For a spleen item, "Type: usable".

Since the item.quality proxy field is what KoL tells us about the item in the description file, for spleen items (and shields, and familiar larvae, and every kind of item that is not food or booze), item.quality == "".

KoLmafia will not attempt to rank items with no KoL-supplies quality into KoL quality categories. That simply ain't gonna happen; It's up to each program to decide how to rank other items.
 
Ah... so spleen is a tricky animal. This version has the quality checking moved to the food/drink checks instead of being in the main "is this item okay" check. As part of this, also moved the refusal for digital and star KLP into the food-only and the unknown bottle rejection into the drink only... this should speed that up by a little bit. Since I don't have any spleens available to me, I can't validate that this works... but it really should. :)

Alternatively, if we wanted, we could 'fake' quality for spleen objects.
Code: 
  <=1 crappy
>1<=2 decent
>2<=3 good
>3<=5 awesome
>5    epic

This version currently just skips quality for spleen, but we could do the force-set if we wanted to... we're already calculating average values for the MINIMUM_AVERAGE check, so it wouldn't take much more work. It's mostly just a question of, should we?
 

Attachments

I think #1053 will spleen now. At least it simulated doing so, unlike prior versions.

My sense is that 'quality' is a bogus concept when it comes to spleen items at least until KoL itself defines the concept. The ideal solution would be to either never ask about the quality of a spleen item OR to have get_quality tweaked so that spleen items are always considered regardless of the quality setting. I could argue in favor of either approach.

Remember that "success" is achieved when the unofficial version produces the same diet (or a better one) than the official, release version.

Thanks.
 
Yep. Well, the same/better diet than actually running the official release version, since the official release version has no clue about items disappearing during simulation. :) It'll happily use your one mulligan stew over and over and over...

Okay, we'll leave quality in the form that 1053 currently has... only considered for food/drink. Should run faster than the earlier versions due to skipping a get_ronin and 2 item checks on non-food, and skipping a property check and 6 item checks on non-drinks.

Edit: Here's something fun... took a page (well, at least a paragraph or two) from Veracity's book in the speed trials and generate the consumable map once per cycle instead of every speculation. Cut my execution down from 7.8 seconds to about 5.5 on average, using gametime_to_int to test. We still generate the map every time a completely new consideration happens, but... less delay is a good thing. :) Won't remove the above script for now, but... 30% improved speed isn't a bad thing, though more testing won't hurt.

Edit2: To avoid double-posting, I'll skip out on posting the next bit just yet. One bug that it had was if it wanted multiple of an item but was unable to get all of them, it would skip using any of them... that's just not quite on. Anyways, if part of the item retrieval is a success, don't eliminate the item fully from consumption, just recalculate the stack.
 

Attachments

Last edited:
Used post #1055 with mafia version 9610. Everything went better than expected. Spleen worked and good cost/adv.
Thanks for the update!
 
#1055 seemed reasonably well behaved. it did not spleen for one character but i think that was due to a couple of non default parameters left over from testing.

it seemed to be doing an awful lot of mall searches for a character in ronin.

i was surprised that it did not pull good food for me, nor would it consume what I pulled for it. the former may be a matter of settings and i'm sure the latter is the usual problem where the item is deemed more valuable in the mall than being consumed.
 
Most likely, yep... remember that pulling is valued as costing an additional 3000 meat per item if in ronin, if that's where you were having it not pull... so it would have to be quite wonderful to be selected. It still uses mall pricing to decide if your item should be consumed, unless you've set it to not consider inventory as valuable, in which case it'll use everything available without regard for what else it might be useful for; this is generally a very bad thing to have happen.
 
Theraze said:
use everything available without regard for what else it might be useful for; this is generally a very bad thing to have happen.
Click to expand...
<veer>
Someone either here or over at GD introduced the terms cashflow and profit. EatDrink, Universal Recovery and mafia itself all have good support for profit but nothing for cashflow. Profit makes sense if a character can buy and sell in the mall but it is deferred gratitude at best if those are not true. There are players who script and don't have mall stores and profit really doesn't do anything for a player in ronin or hardcore. I'd love to have a good algorithmic definition for cashflow so it could be agreed upon and supported. My simple one would be a threshold. Items in inventory with a mall value less than or equal to threshold will be treated as zero cost when considering consumption. Alternatively there could be a user provided file of items to be valued at zero when consuming. The former preserves hard to get items. The later gives more fine grained control. Neither idea is fleshed out enough to be useful yet but it does annoy me when there is a common readily available food in my inventory and EatDrink decides it is too valuable to eat and buys 8 mugcakes. Let's get the plan/execute consumption working and rolled out and then we can deal with this :-) </veer>
 
Well, I was talking about why it was checking mall_price, and even with your threshold, it would still need to check pricing so it could know whether or not it was in the "use me!" category or not... but yeah, it might be good to have something where we can set a value, and anything below that cost per adventure/per consumption-point is considered to be of equal value... With that, you could set a total "pricing" of, say, 1000 per consumption point. Or higher... that would be the purview of the player. But yeah... eventual goals. :)
 
You must log in or register to reply here.
Back
Top