Best Between Battle Script Ever -- formerly AutoMCD

I'd still prefer it not automake the honeypots... if it does, could that be a preference so we can easily disable it? I don't think anyone but Weatherboy has asked for that feature yet...
 
Since I quite like the bees, and the honey food isn't too bad for a lazy player like me, I'd also rather like to be able to avoid having all my honey turn into pots.
 
One (very) minor bug that will just go away (so no need to fix I think):
if you have changed moon signs (using the moon unit) it doesn't update to quit using the detuned radio when you have the other MCD's now. After ascension, everything seems fine again. I've confirmed this on 2 multis, one that still has the issue.
 
This line should probably be added to fam_check():
Code: 
   dfams[$familiar[li'l xenomorph]] = to_int(get_property("_transponderDrops"));
 
Zlib keeps resetting bbb_famitems to false.

> zlib bbb_famitems = TRUE

Previous value of bbb_famitems: false
Changed to TRUE.

Ad nausuem. I set it in the CLI run a turn and it resets.

My is_100_run is not set.

> zlib is_100_run = none

Previous value of is_100_run: none

Any ideas why it keeps reverting to the default of false?

Thanks.
 
Code: 
> ash to_boolean("TRUE")

Returned: false

> ash to_boolean("true")

Returned: true
If you had your verbosity set to 4 or higher, you would have seen a message like this:
Code: 
[COLOR="#9932cc"]ZLib setting bbb_famitems normalized: 'TRUE' => 'false'[/COLOR]
Simply use
Code: 
zlib bbb_famitems = true
instead of
Code: 
zlib bbb_famitems = TRUE

Alternatively, zlib's line 63 in normalized() could be changed from
PHP: 
case "boolean": return to_string(to_boolean(mixvar));
to
PHP: 
case "boolean": return to_string(to_boolean(to_lower_case(mixvar)));
to account for this.
 
I never in a million years would have thought TRUE <> true...

/sigh

Thanks Slyz! That is the perfect teaching example too. I save a lot of stuff in my "KoL Mafia Examples.doc" file

Thanks for verbosity = 4 as the right debug level for these.

:)
 
Last edited:
Raven434 said:
I never in a million years would have thought TRUE <> true...
Click to expand...
to_boolean() returns false for any string other than "true". The case-sensitivity is removed in r9473. If any script is broken by this, I would be surprised, since I think no-one would have guessed that to_boolean("TRUE") was false.

Note that if you pass something other than a string to to_boolean(value), it will still return true if to_int(value) is different than 0. For example:
Code: 
> ash to_boolean( $item[ big rock ] );

Returned: true
since to_int( $item[ big rock ] ) returns an item number different than 0.
 
I just thought of a feature request. If your goal is a dead mimic and you're adventuring in the dod, abort (maybe on a setting so it doesn't break automation?) if your current meat falls below 5000. You could probably do a similar check for other items that have to be 'purchased' through a choice adventure as well.
 
The deeper issue here is that is_100_run should hold a familiar, not a boolean. Both "true" and "false" would be normalized to $familiar[none], I think, although true might be $familiar[mosquito]. :) I'd test that but it would mean aborting my routine script which is running right now. Wouldn't it be great to be able to bypass the CLI command queue? hehe

@adeyke: Yes. Will add that too.
 
The problem was bbb_famitems though, not is_100_run. I think he pointed out that is_100_run was set to none because the part that uses bbb_famitems would have been skipped otherwise.
 
Oh, didn't read that carefully enough. You know what they say -- haste makes incorrect script support.

@Rinn: BBB already skips the mimic if your meat is < 5000. Have you experienced otherwise?
 
I suppose disallowing autoadventuring for a goal mimic with insufficient meat could be useful, particularly in situations such as Rinn meantioned where you are losing meat from adventuring (i.e. when you go there at low level and need to restore HP/MP afterwards). But it would be annoying in situations where you are gaining meat from adventuring (backfarming a wand is fairly common). Meat gain/loss per turn is not something BBB currently tracks.

So I'm not yet convinced that adding this would be helpful, but as always I'm open to persuasion.

@slyz: Haha, I just noticed your sig. Love it!
 
Well I'll just add it into my own between battle script then, the point is that if I'm adventuring for a dead mimic I clearly shouldn't even be attempting to get one if I have less then 5000 meat on hand or I'm just wasting turns.
 
Rinn, I see your point -- but it only applies if you're only adventuring for a mimic, which is impossible to detect in ASH, and you're not likely to gain meat by adventuring, which is difficult to predict. In short, I like the idea but adding it makes certain situations impossible to automate.

@roippi: I think the KoLmafia Tech Support Magic 8-Ball would be a good web app -- maybe I will write it in my spare time. The question is, would there be any other answers? We could get clever and let people type in their questions/problems and then match certain keywords ("stickers", "unknown", etc.), but it's probably funnier with just the one answer. :)
 
You must log in or register to reply here.
Back
Top