Ascend.ash: hands-off ascension script

I'll review too, but what the wrapper does is prevents ED from spending meat after a certain point. So if it runs out while consuming it will definitely keep trying other drinks until it gets something it can "afford". The wrapper is also a bit awkward since SIM doesn't actually know how much you will need to spend to actually accomplish something so the SIM results are not effected by the wrapper imposed budget.
 
Found it, line 135, 6 parameter on the line is 600 for value_of_adventure. It's hardcoded instead of reading in a variable (as are the rest of the inputs to eatdrink). Looking at the wrapper, all it seems to do is handle the monetary management for the day, all other variables are passed through. So one solution would be to have Ascend just call the regular eatdrink function (unless of course there is something special in all of the hardcoded values) or the less intrusive way would be to have Ascend read a set of Ascend specific eatdrink preferences.
 
Very interesting. The hard coded values are present in the earliest version of Ascend that I have access to which, by definition, predates EatDrinkWrapper. EatDrink called directly uses the property valueOfAdventure which probably explains the different behavior.

Almost makes me wish for zData - a collection of preferences that might apply across multiple scripts and script writers get a red star for using a zData variable instead of something specific to the script. Examples might include: whether familiar swapping is allowed, name of the max adv rollover out, name of the default outfit, value of an adventure...
 
Wouldn't that just be a set of standardized zlib variables with an ash wrapper of getters? Or did you have something bigger in mind?
 
shazbot said:
Wouldn't that just be a set of standardized zlib variables with an ash wrapper of getters? Or did you have something bigger in mind?
Click to expand...

That would work on a technical level. The real problems would be a) documenting them so that everyone understood what they meant; b) maintaining such documentation; and c) convincing various script authors to convert. Not everyone uses zLib variables.
 
Don't forget zarqon's caveat that all zlib variables are loaded with every zlib script, so if the amount of variables balloons, it'll start to lag people with slower systems eventually. :)
 
Theraze said:
Don't forget zarqon's caveat that all zlib variables are loaded with every zlib script, so if the amount of variables balloons, it'll start to lag people with slower systems eventually. :)
Click to expand...

Well ideally, if we effectively consolidate the primary variables, it would net less zlib variables used.
 
fronobulax said:
Examples might include: whether familiar swapping is allowed, name of the max adv rollover out, name of the default outfit, value of an adventure...
Click to expand...

These exist, pretty much by default:

ZLib setting: is_100_run
CLI command: maximize adv, switch disembodied hand
ZLib setting: defaultoutfit
Mafia property: valueOfAdventure

Anyone using ZLib but not using those probably just didn't know they already existed.

One thing I need to add to the ZLib documentation is that ZLib settings should only be used for things that users will want to configure. Not for variables stored, read, and changed only by the script -- mafia properties, which are much less expensive, can be used for those.

I especially don't want to duplicate in ZLib what already exists in mafia, so anything that is already a mafia property really has no business being a ZLib setting.

fronobulax said:
The real problems would be a) documenting them so that everyone understood what they meant; b) maintaining such documentation; and c) convincing various script authors to convert. Not everyone uses zLib variables.
Click to expand...

a) Relay editors for ZLib settings -- there are already at least three of these. If I ever un-give-up on the frigging WOSSMAN, we'll even have an "official" one.
b) vars_documentation.txt is publicly editable on the Map Manager.
c) This problem applies to everything that anyone may want to standardize. In the end, people will always choose what works for them, standards notwithstanding. For standardization to be effective, you have to make the standard the thing that works best. :)
 
So in my version I went ahead and replaced eatdrinkWrapper with
Code: 
void eatdrinkWrapper (int foodMax, int drinkMax, int spleenMax, boolean overdrink)
and the call with
Code: 
    SIM_CONSUME = false;
    eatdrink (foodMax, drinkMax, spleenMax, overdrink);

And all 5 calls to eatdrinkwrapper I truncated down 4 or so lines of function call to just the first line (no point copy pasting). That way it heeds all eatdrink global variables (except sim) and still does the meat management. However, it will still eat, adventure, and then do all of your drinking (including overdrinking) and spleen use. Personally, I like to rollover with as little adventures as possible, but I don't know if there might have been a more specific reasoning for it functioning the way it does.


On another note, I was trying to patch the Ed the Undying fight, but I found that it would handle 1-2 fights with him per call to adventure(), so running adventure(7...) doesn't work quite right. Would a better option be to trying to hit a common page, and if it's a combat page you continue to run_combat? THat seems like unecessary server hits. It could be adjusted at the mafia layer, but that doesn't seem like the correct avenue to fix it.
 
Here's my Ed attack bit:
Code: 
  if (contains_text(visit_url("pyramid.php"), "pyramid4_1b.gif"))
  {
   if(my_adventures() >= 7)
   {
    print("Ready to fight Ed the Undying.");
    restore_hp(0);
    restore_mp(0);
    visit_url("pyramid.php?action=lower");
    run_combat();
    visit_url("fight.php");
    run_combat();
    visit_url("fight.php");
    run_combat();
    visit_url("fight.php");
    run_combat();
    visit_url("fight.php");
    run_combat();
    visit_url("fight.php");
    run_combat();
    visit_url("fight.php");
    run_combat();
    council();
    wait(1);
   }
Basically, visit fight.php between each fight to make mafia aware that a new fight has started, then run_combat again. Repeat.
 
does your council() call work? Because I just put in a bug report because I had Holy MacGuffin, but nothing would happen when I reran ascend (which calls council() in it's startup), nor when I ran council manually in the CLI.

Other than that, thanks. I put that in my ascend for next run I do.
 
Yeah, the council call has worked for me for ~15 ascensions just fine. Sometimes a call to a page fails though... best thing to do if it sometimes works and sometimes doesn't is, when it's failing, turn on debug (help menu), run the command, and turn off debug again. That gives a log you can attach to your bug report that can be parsed and the developers can try to figure out what's different between your attempt and a working attempt. Might be that a council call needs to have your password hash sent with it or something, similar to (apparently, since Veracity just found this in a debug log I posted) vacations. :)
 
Next time I start talking about an update - which should be Real Soon Now - remind me to include the Ed change.

As for the EatDrinkWrapper I like the idea that ALL calls to EatDrink should use the variables/parameters already defined and with some meaning rather than some hard coded values. Would you consider restoring the wrapper but changing the calls so that variables were passed? More kludgy but less work would be to just edit the wrapper to ignore passed parameters and substitute preferences.

I understand that the decision to eat, adventure and overdrink in that order is based upon a desire to optimize turns of Ode to Booze. If you have capacity of 19 and access to 6 drunkeness drinks and each cast is five turns then (assuming no turns are spent acquiring the drinks - see Theraze who is working on a solution to that) you just cast five times, drink and no turns are wasted. Contrast that to 4 casts to drink to 19 and two casts to get to 25 later.

Too fiddly for me and I often run EatDrink manually before firing up Ascend.
 
I'm integrating it in, but there are different states for the eatdrink call. If you don't have your *of_steel, it weights prime stat at 10 and does not prioritize pies, otherwise it's prime stat at 5 and does prioritize pies. It makes sense, because it tries to rush you to get your *of_steel and then you can worry about the other stuff. The question is, how do we want ascend to handle it? I'm thinking just hardcode the pies in the calls to eatdrinkWrapper and setting primestat to the variable*2 for pre-steel. Thoughts?

I made those updates, but because of the nature of Ascend, I'm just going to kmail it to you frono. Also, another update that should be made to the suite is Ascend Status.ash needs this line replaced at line 210, because it doesn't handle hippy victories.

Code: 
!contains_text(finishedQuestLog, "pirates to annihilate both") &&
       !contains_text(finishedQuestLog, "For Gaia!"))
 
Last edited:
I have read back about 20 pages and don't see a fix for this so I am not sure what to do and I apologize if I just missed it. Btw I am using KolMafia V14.3 r8934 and I am using straight out of the box ascend.ash the one labeled 2011_03_19

> call scripts\EatDrink.ash

Bad location value: "throne room" (zlib.ash, line 419)

I tried updating with the file on the eatdrink thread and it gave me this

> call scripts\EatDrink.ash

Expected ), found ? (zlib.ash, line 169)

Hope someone can help but not to stressed over it i know how busy people can get so just get to me when you can please and thanks ahead of time.
 
thank you that fixed that problem but it gave me a new one

> call scripts\EatDrink.ash

Refreshing stash contents...
Validating adventure sequence...
No location selected.
Stash list retrieved.
Internal checkpoint created.
Loading favorite consumables from user settings...
adding favorite: rockin' wagon
adding favorite: pr0n chow mein
adding favorite: twinkly wad
Starting EatDrink.ash (version 3.1.3).
Consuming up to 15 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 3000 meat each.
An adventure has the value of 500 meat. Moxie subpoint is 10.0. Nonprime stat subpoint is 2.0.
Already updated from http://nixietube.info/mallprices.txt in this session.
Pass 1: food.
food: At 0, consuming to 15.
Loading food map from Mafia's datafiles
Map modified within foreach (EatDrink.ash, line 986)

Hope you can help
 
nsd45 said:
thank you that fixed that problem but it gave me a new one

> call scripts\EatDrink.ash

Refreshing stash contents...
Validating adventure sequence...
No location selected.
Stash list retrieved.
Internal checkpoint created.
Loading favorite consumables from user settings...
adding favorite: rockin' wagon
adding favorite: pr0n chow mein
adding favorite: twinkly wad
Starting EatDrink.ash (version 3.1.3).
Consuming up to 15 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 3000 meat each.
An adventure has the value of 500 meat. Moxie subpoint is 10.0. Nonprime stat subpoint is 2.0.
Already updated from http://nixietube.info/mallprices.txt in this session.
Pass 1: food.
food: At 0, consuming to 15.
Loading food map from Mafia's datafiles
Map modified within foreach (EatDrink.ash, line 986)

Hope you can help
Click to expand...

Report noted. Not sure I have a suggestion for you yet, but I'll poke around a bit.
 
Wasn't that error the one about Genalen bottles?

Change where it says Genalen in the script to none, so that instead of != $item[Genalen bottle] it says != $item[none] and that should fix it.
 
Nope just looked at it already says none grr i kinda wish i knew more about programming so this wasn't mostly gibberish to me i appreciate all the help
This is line 983 to 989 if it helps

}
else
verbose2("Skipping "+it);
}
}

boolean needakey = !can_interact() || my_level() < 13;
 
You must log in or register to reply here.
Back
Top