The Unofficial Ascend.ash support thread.

Ferdawoon said:
The part with King's chamber is that a few of the locations in the Cobb's knob zone have changed name, and Mafia have changed the names as well, meaning every script that menion these locations will need to have the zone names changed. I'm using BCC ascension script atm and just quickly editing the names of hte locations in the script to match those that Mafia use now solved the issues.

Dunno if this is what your problem was though.
Click to expand...

When I tried to use eatdrink it called zlib which proceeded to bork when it got to the line I quoted. Since I didn't read it closely enough at first I thought eatdrink.ash was calling the King's chamber.

Basically even if you aren't doing anything at all in the knob apparently any script calling zlib will break until the line about the king's chamber is fixed.
 
Not sure what happened with eatdrink.ash today. It was supposed to get me to 19 drunkenness out of 20 then stop but at some point it entered a loop and kept repeating

Code: 
Drinking 1 cup of primitive beer...
Inebriety limit reached.
cup of primitive beer price updated from 625 to 625.
FAIL: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:625 own:0 value:3315
Choosing drink to consume.
You have at least one cup of primitive beer in inventory.
Since you are not in a Moxie sign, you may not visit the brewery.
Drinking 1 cup of primitive beer...
Inebriety limit reached.
cup of primitive beer price updated from 625 to 625.
FAIL: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:625 own:0 value:3315
Choosing drink to consume.
You have at least one cup of primitive beer in inventory.
Since you are not in a Moxie sign, you may not visit the brewery.
Drinking 1 cup of primitive beer...
Inebriety limit reached.
cup of primitive beer price updated from 625 to 625.
FAIL: cup of primitive beer lev:12 gain:1.0 adv:3.5 musc:57.5 myst:0.0 mox:0.0 meat:625 own:0 value:3315
Choosing drink to consume.
You have at least one cup of primitive beer in inventory.
Since you are not in a Moxie sign, you may not visit the brewery.
Drinking 1 cup of primitive beer...

When I checked it turns out it went all the way to 20. As far as I know I have the most recent copy of eatdrink from this thread and I'm certain I told it "eat 15 drink 19 spleen 15 overdrink false sim false" like I do every day. The kicker that convinces me this wasn't user error is that while the relay browser tells me I have 20 drunkenness mafia tells me I have only 18. I'm running r9083.
 
Likely one of the items you drank before the primitive beer has incorrect inebriety information. Any chance you have that information saved? Otherwise, we can't really help you much...
 
Theraze said:
Likely one of the items you drank before the primitive beer has incorrect inebriety information. Any chance you have that information saved? Otherwise, we can't really help you much...
Click to expand...

I can see if it's in my session logs. I was checking up on some webcomics and it looped so long anything it drank before the loop was no longer visible to me. Be right back after I check the logs.

Ok, according to the logs it began drinking at 0 and was to drink to 19 as I thought.

Then it drank 10 pear schnapps. At two drunk a piece. It looks, from what my log tells me, like one single shot in the middle registered to mafia as not giving me any stats, adventures, or drunk.
 
Last edited:
So I'm attempting to use the macguffin.ash script and the obtain function is just killing me. I've stumbled through the zlib thread discussing and, but it's just too massive to figure out what's still relevant. What would have to be done to make it so you abort when you get beaten up? 'cause mafia keeps getting caught in loops where you restore some health, fight, die, repeat. I'm HC so my restore options are limited and I never use the auto recover while HC.

tl;dr: should macguffin fail when you die instead of getting stuck looping, and if so, what needs to be done to do it (I don't mind contributing, just need some direction).
 
I have had similar problems running macguffin directly and there is also an interaction with Bale's Universal Recovery script. I would start by making sure that UR does abort when there is a problem with recovery (rather than make all efforts to continue automation), then I would set the restore options so that I aborted at low health and finally I could consider setting a mood that aborted when I was Beaten Up.

I had the opposite problem - my goal is to automate at all costs even if the cost is burning adventures unnecessarily in a non-optimal fashion so the suggestions are things that I recall having to undo.

For the record, I find Ascend very impressive because of the vast quantity of material that is automated but if I cared about efficiency I'd probably look at bumcheekascend as an alternative.
 
There's a wide variety of these snippets out, but yes... bumcheekascend will do it, as will Azazel and some of the variants of Level 6... fairly sure that there are other options here on the forums as well. :)
 
The version of wossname.ash is dated. It does not read zlib variables for battle plan and it will not print out messages for it being an old version.
 
shazbot said:
The version of wossname.ash is dated. It does not read zlib variables for battle plan and it will not print out messages for it being an old version.
Click to expand...

That's not what you said in the other thread. More to the point you are the only person reporting that problem and have so far failed to provide any information that would help anyone help get it fixed for you. I question your motivation for introducing the subject in a different thread but it may be that I am predisposed to expect an attitude from you after this post.
 
fronobulax said:
That's not what you said in the other thread. More to the point you are the only person reporting that problem and have so far failed to provide any information that would help anyone help get it fixed for you. I question your motivation for introducing the subject in a different thread but it may be that I am predisposed to expect an attitude from you after this post.
Click to expand...

I assure you, my methodology was valid. If you would take the 2010_08_24.zip, open it, unzip the included to_zip.zip file, go to the new to_zip direcotry, and look at the wossname.ash file, you would see on line 21 that it's version 1.5.3. If you look at the source for wossname 1.5.3, you would see that it never once reads zlib's variables (it was customizable via hardcoded character values in the ash script, example lines 25 and 26 in the included file). Coupled with my zlib issue where my verbosity was somehow set to 0, I was not alerted that it was an old version in the first place, hence my issues in your first linked thread.

EDIT: I do guess I wasn't clear in my previous post here. I meant the version included with this bundling of ascend.ash
 
Last edited:
Theraze said:
Verbosity 0 is not a script bug... it's that you've managed to set it improperly at some point.
Click to expand...

I have never set verbosity myself, but fronobulax mentioned that they have seen it getting inadvertently set. It may not be a script bug, but it's still a problem. All I'm saying, is that if your making updates to the package of scripts, you might as well include newer versions of all of them, not just ones that have a specific need to be updated.
 
Eh, you're reporting an unrelated not-a-script-bug here, as if it were a problem with the script or the package. Ultimately, there's nothing we can do to fix what you've managed to set on your own preferences... the fact that you've (hopefully inadvertently) disabled the update notification isn't something we can solve.

Regarding attaching updated scripts created by people besides dj_d to the package... that's something that dj_d and the various script creators worked out. In the absense of dj_d, either the repackaging would need to be reaffirmed by the script creators (knowing that their scripts are already notifying you of where to get the updates), or the current behaviour should continue.
 
shazbot said:
The version of wossname.ash is dated. It does not read zlib variables for battle plan and it will not print out messages for it being an old version.
Click to expand...
The version bundled with Ascend is a modified one. If you don't want to use the "fastest-fratonly" warplan, you have to edit the script and modify the plan at the top of the Ascend wossname.ash.

It also doesn't use vprint() though, so changing the zlib verbosity wouldn't make it start printing out stuff. You should make sure the Ascend wossname.ash is the only file with that name in your /scripts folder or sub-folders.

EDIT: it *does* use check_version(), pardon me. That uses vprint() of course.
 
Last edited:
OK. I think what is being reported here is a packaging problem or a misunderstanding on my part. One of the goals I had for supporting Ascend was to make it so that it worked with the latest, unmodified versions of other people's scripts. With that philosophy, packaging them with Ascend was a convenience. Regardless of whether I continue unofficial support, or not, I do have one more release to make and I will make it clear when Ascend requires modified versions of other scripts.

For the record, I am running wossname 1.5.8 with Ascend but I have no recollection of how I was informed that 1.5.3 was no longer the latest version.
 
You must log in or register to reply here.
Back
Top