autoBasement.ash - Better basement automation

The script decides if it should use philters of phorce based on necessity and mall price. Why would you want to change that? If you want to decide what potions to run, you might as well use Mafia's built-in Basement automation.

I could understand running a mood before a combat, though.
 
Good evening!

First of all, thank you for helping keep this script up to date, it comes in VERY handy for burning adventures when I don't have the time.

I do have one question regarding functionality. Is there any way to set this up so that it sustains custom moods? Running this as a Sauceror is great for potion economy, but when the script doesn't want to use philters of force to pass Gauntlet tests when I have it on my mood is starting to grate on my nerves just the slightest bit.

Is there a setting I'm missing to do this, or is this something that can be added to the script?

Do you have any output around where it didn't? It should do so only if needed and if it can pass without then why should it, but if it failed you may need to tweak some settings or we may need to tweak something else.

Also, what type of mood would you want to have on?
 
Good evening!

First of all, thank you for helping keep this script up to date, it comes in VERY handy for burning adventures when I don't have the time.

I do have one question regarding functionality. Is there any way to set this up so that it sustains custom moods? Running this as a Sauceror is great for potion economy, but when the script doesn't want to use philters of force to pass Gauntlet tests when I have it on my mood is starting to grate on my nerves just the slightest bit.

Is there a setting I'm missing to do this, or is this something that can be added to the script?

As Slyz says, the script use whatever potions and buffs it have available based on necessity.
However. There is a setting in Zlib where you can set a maximum cost of a potion for the script to consider it. This to prevent the script from using those 50k+ potions =P
Gocheck your Zlib variables and see what the autoBasement_max_potion_price setting is. If it is still at default, 2000meat, then maybe the philter of phorce potions are more expensive than that and thus will not be considered.
 
Potion pricing is at the default two thousand, but philters at that point were 648 in the mall (personal check).

There were situations where I was aborted at the Gauntlet when a philter would have done it (the way this script does the gauntlet is a bit shaky - after level 200 I had to manually put on sponge helm and pants to jack DA where the script does not). Because, as a Sauceror, I could get 45 adventures of phorceful for 1050 meat, it's easier to run it for the HP for combats, and for that particular level than to let the effect expire then use it the level after when it does so.

I suppose I could multiuse the potions before running the script, but it's a pain to remember them all.
 
There were situations where I was aborted at the Gauntlet when a philter would have done it
In that case it does look like a bug. Next time this happens, could you provide more precise information? What HP was the script trying to get, how much it got, what potions it used, etc...
 
I just started a new ascension, so it'll be a couple of weeks but rest assured I will be doing so.

In the meantime, and please take this with a grain of salt since I am completely new to scripting, but would replacing the gauntlet command with something on the order of the cli command 'maximize HP +DA 1000' be something to consider inserting?
 
Just make sure that the value of HP relative to DA depends correctly on the current depth.
1) At 1000 DA, value of (losing) 1 DA point is "worth" roughly 0.0005*MAXHP. Each successive point of DA is "worth" slightly more, until 11->10 is worth whopping 0.00488*MAXHP (any DA below 11 is worthless).
2) At 1000 DA, you will reduce damage by 90% (afaik, DA over 1000 actually *does* count for the gauntlet, but I am not sure, so I am assuming 1000 as the max)
3) Therefore, at floor number $lvl, you want at least ($lvl^1.4) HP anyway <-- you probably want to include this as a minimum
4) this means that 1 DA point will be worth at least ($lvl^1.4)*0.0005 score points (if 1 HP is worth 1 score point) <-- this is important for the maximize command

What this means is, at lower levels you will be maximizing HP first, then you hit levels where DA becomes more important than HP, then you hit levels where you max out your DA no matter what and futher improvements are only possible by increasing HP again.

(If you have the stats for that, you can get over 2000 HP just from equipment, which would take you to floor 44 even without any DA, and to floor 227 with 1000 DA)
 
Every instance of
PHP:
case "hp": if(my_maxhp() > goal) return true;
case "mp": if(my_maxmp() > goal) return true;
default: if(my_buffedstat(s) >= goal) return true;
should be replaced with
PHP:
case "hp": if(my_maxhp() > goal) return true; break;
case "mp": if(my_maxmp() > goal) return true; break;
default: if(my_buffedstat(s) >= goal) return true;
 
Why should there be a break after return? Wouldn't it be unreachable?

ETA: Oh right, it's after the "if", not the "return".
 
Last edited:
Eh, just talking about best practice/extensibility. :) If we get some other stat that doesn't just go with a straight modifier check, and it gets put under the default line... :)
 
Eh, just talking about best practice/extensibility. :) If we get some other stat that doesn't just go with a straight modifier check, and it gets put under the default line... :)

Worthwhile. It certainly would not hurt to do that.
 
Does ASH check for stuff after default: even? I don't know how that works in any language actually, but I would expect anything after default: to be unreachable with the return statement there.
 
Pretty sure best practice would be to not put anything after default.

Good students include Bob, Sara, and Mary. Everyone else is a bad student. Oh, and George.
 
That is a "best" practice, however I can imagine a situation where you want to put default before last. That would be a situation where you want a case to do everything that default does, except for one thing. Then you put that one thing after default, but before the case. Of course you'd want to leave off the break so that it would work. Hmmm... that case is opposed to putting break after default. Irony!
 
You would still use a switch, because there would be several other cases of the switch.
You would use the if (inside default) in addition to that, not instead.
 
Yes, if there were also other cases, you would use the switch as well. But you still wouldn't have a case after default.
 
Back
Top