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

Theraze

Theraze

Active member
Mafia update 9599 broke EatDrink and anything else that directly parses the consumption files. The fix is to change this:
Code: 
  record fullness_file_entry // holds the map found in fullness.txt
  {
    int consumptionGain;
    int level;         
    string adv; 
    string muscle; 
    string mysticality;
    string moxie; 
  };
to this:
Code: 
  record fullness_file_entry // holds the map found in fullness.txt
  {
    int consumptionGain;
    int level;         
    string quality; 
    string adv; 
    string muscle; 
    string mysticality;
    string moxie; 
  };

Basically, just put string quality after int level. :) EatDrink should probably get a main rev update to 3.1.4 to make it work again, and we'll deal with the other changes once they've been tested up and down. :)
 
roippi

roippi

Developer
Hah, I just had the thought "I wonder if this breaks eatdrink."

Totally worth it, of course. Pretty stoked about colorizing food.
 
fronobulax

fronobulax

Developer
Staff member
The fix in #1021 will break EatDrink for folks running mafia versions prior to r9599, right?

I'm running with the fix now. I am inclined to release the fix as 3.1.4 and suffer the questions from folks who blindly upgrade EatDrink but not mafia, but I am open to other suggestions.
 
Winterbay

Winterbay

Active member
Yeah, it's a shame that that did not make it into 14.7 since that would've made most users actually upgrade to a version which had it. Can you do a switch for Mafia version around the definition of the record?
Something like:
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 muscle; 
		string mysticality;
		string moxie; 
	};
}
 
fronobulax

fronobulax

Developer
Staff member
I have not paid attention to proxy records that closely but isn't the best solution to replace reading the file with just using proxy data instead? That should work for any version of mafia that supports proxies because EatDrink does not actually use the new field, correct?

The attached version of EatDrink is labeled 3.1.4 but is really 3.1.3 with the change noted in #1021. If you are using a version of mafia newer than r9598 then you should use the attached version instead of the version in the first post of this thread.
 

Attachments

  • EatDrink.ash
    60.6 KB · Views: 43
Theraze

Theraze

Active member
Winterbay said:
Yeah, it's a shame that that did not make it into 14.7 since that would've made most users actually upgrade to a version which had it. Can you do a switch for Mafia version around the definition of the record?
Click to expand...
Could, and that's fine in 3.1.4, but I'd hesitate to include it in 3.1.5 since it actually allows for minimumQuality and I'm running with 1 to filter out crappy food, though the default is 0 to only filter out unknown or buggy food.

fronobulax said:
I have not paid attention to proxy records that closely but isn't the best solution to replace reading the file with just using proxy data instead? That should work for any version of mafia that supports proxies because EatDrink does not actually use the new field, correct?
Click to expand...

Once the adventures are actually available as a proxy record, yes. Until then, we still need to parse the data file ourselves. :( Also note that when we move from parsing to proxies, it'll break EatDrink for everyone who doesn't yet have those proxy records in their copy of mafia, similar to this but so very much worse... :)
 
Last edited:
Veracity

Veracity

Developer
Staff member
The purpose of proxy records is to let you avoid reading internal data files, exactly as you say. We do not currently provide every field in fullness/inebriety/spleenhit as a proxy field for an item, but we easily could do that. this feature request requests the missing ones.

I assume EatDrink needs those, too.
 
Winterbay

Winterbay

Active member
Not all the info in the datafile is yet in teh proxy-record. The following values used by eatdrink is not available in an item.proxy-record.
  • grub[gc].consumptionGain.max = temp_map[it].consumptionGain;
  • grub[gc].consumptionGain.min = temp_map[it].consumptionGain;
  • grub[gc].adv = set_range(temp_map[it].adv);
  • grub[gc].muscle = set_range(temp_map[it].muscle);
  • grub[gc].mysticality = set_range(temp_map[it].mysticality);
  • grub[gc].moxie = set_range(temp_map[it].moxie);
 
Winterbay

Winterbay

Active member
Theraze said:
Could, and that's fine in 3.1.4, but I'd hesitate to include it in 3.1.5 since it actually allows for minimumQuality and I'm running with 1 to filter out crappy food, though the default is 0 to only filter out unknown or buggy food.
Click to expand...

Well, yeah, it's not a good long term solution but as a way to solve the current problem it would work :)
 
Theraze

Theraze

Active member
Yeah... as he says, consumptionGain is actually the same value iterated twice so if there are exceptions they can be manually shoehorned in, but we also have adventures and all 3 stats as a range (min and max). If he doesn't make a FReq in the next hour or so, I'll try to make my words actually make logical sense and put together a FReq. :)

Edit Besides adding in minimumQuality as another zlib variable, also added in unknown_recipe as a function... this one basically just looks to see if there's a preference with the item's number saying that it's unknown. Tested and it does eliminate Russian Ice from my suggested make list, so that's nice. Put that into the make section as opposed to the initial filtering, because you might still buy an amazing idea item from the mall or something similar.
 
Last edited:
fronobulax

fronobulax

Developer
Staff member
The preferred solution is to use proxy records but that won't be possible until mafia supports all of the fields that EatDrink uses. When that happens, EatDrink will no longer work with earlier versions of mafia. I'm afraid that the user friendly solution will be to have EatDrink be version aware, at least until the proxy code gets into a point release of mafia. I will edit the mainline as per #1024, test it as far as I am willing, and release it as 3.1.4, probably tomorrow. OK?
 
Theraze

Theraze

Active member
I think he just means that Winterbay's "get_revision" check will be in version 3.1.4, and version 3.1.5 and higher will need newer mafia, since hopefully they'll have proxy records instead of directly pulling the data files.
 
fronobulax

fronobulax

Developer
Staff member
xKiv said:
Do you mean "maintain two branches - one for 14.7 and one for daily builds"?
Click to expand...

No. Ignoring Theraze's work for the moment, there will be a single version that will work for all versions of mafia. It will work because it checks the version and behaves differently. My guess is that sometime around mafia 14.8 the version checking code will be deleted and the mainline version will require mafia 14.8 or better, but that is a guess based upon my current preference not to have version dependent code.
 
roippi

roippi

Developer
Maintaining legacy support is a pain, I agree that after 14.8, eatdrink should stop supporting 14.7-style datafiles.
 
Theraze

Theraze

Active member
It's going to take a long time for my changes to get rolled into the main, then... since 14.7 doesn't support quality as a proxy value, meaning that anything that checks that will break, etc. Ah well, I can wait to get 'official' for 14.8. With Veracity about to take a break that should get rolled when... 2012? :D
 
xKiv

xKiv

Active member
fronobulax said:
there will be a single version that will work for all versions of mafia.
Click to expand...
I fear that a version that has any access to {proxy attributes available from rXXXX on} will not work before rXXXX, even if it doesn't actually execute those lines.
 
Theraze

Theraze

Active member
Validation is where it gets iffy... Winterbay's post redefined the fullness record. If we're using the built-in item record type, we aren't able to redefine that without defining our own version of what $item should mean. As the proxy wouldn't exist under the old record type, that means...
 
fronobulax

fronobulax

Developer
Staff member
xKiv said:
I fear that a version that has any access to {proxy attributes available from rXXXX on} will not work before rXXXX, even if it doesn't actually execute those lines.
Click to expand...

Yes. But until convinced otherwise I am willing to tell an EatDrink user that in order to use the latest version of EatDrink they must update mafia to the latest version available on Sourceforge. I am not, however willing to tell them they must update to a Daily Build greater than rXXXX. If mafia ever self checked for new versions elsewhere then I would reconsider.

Since EatDrink reads a file into a local data structure, in theory it should be possible to isolate the version dependencies. If unexecuted code that references an unknown proxy field triggers a compilation error then there will probably be no legacy support. If the error occurs at runtime then legacy support might be feasible.

To the extent that I have time to devote to KoLmafia in chunks greater than five minutes, it seems as if the best use of my time would be to make sure the proxy fields get added sooner rather than later.
 
You must log in or register to reply here.
Top