r7 Update!
The updates are flowing like honey here in BatBrain-land. Or actually, like superfluid helium, which has a viscosity of 0! And you, the user or interested party perusing this post, have no inconvenience as a result! I also got new vanity plates on my car: LUV4SVN
This update finally unlocks the door which was keeping out all the custom actions from BatBrain's internal options list (opts). Now opts contains all the custom actions which are present in batfactors.
Isn't that dangerous? you ask. Weren't custom actions flagged as such because BatBrain doesn't understand their results, or because it's undesirable for BatBrain to use them? you ask. Wouldn't allowing them into opts be like letting little aliens onto the playground with our children? you ask.
Yes. But that's why BatBrain (and WHAM) now filter out custom actions from their recommended action sorts, so they will never be used in ordinary automation despite being in the mix with all the other actions. This means that we can have the benefits of custom actions being present in opts:
- Calling scripts can access these actions using get_action() rather than using a constructor to build the event in-script.
- Since the action is loaded just like regular actions, the formulas/results are now publicly editable in batfactors.
- Custom actions will be present in your Actions Table in BatMan RE, which means you can easily submit it macro-fied (and thus tracked) without needing to switch to the KoL tab to find and submit a non-tracked version.
- Limited-use Jarlsberg chefstaves can be flagged as "custom" meaning that we don't have to go all-or-nothing by blacklisting "jiggle" itself.
without the obvious disadvantage of BatBrain recommending, say, Spooky Putty as a stasis option.
The other change in this update is the aforepromised Candyblast hack. I believe we have seen the end of the flurries, if not the discussion.
Enjoy!
@Bale: Actually, I'd like to keep lists of items -- I have plans to integrate
has_goal() into SmartStasis, so if you were going into a fight with a goal of Cold Hots, SmartStasis would use Candyblast if possible until the Cold Hots drop. Or likewise, with a Crimbo Elf enthroned, it would stasis until Cold Hots drop.
This does present a very interesting possibility: ZLib's
sell_val() could share UR's data file and consider HP/MP gain from using an item in its calculations. The profit from MP/HP gain is fairly straightforward whereas sometimes the value of an item is not, as with wint-o-fresh mints. When evaluating said mints, it could first check mall price and return that unless it's at minimum, in which case it could return whichever is higher: autosell value, or profit from HP/MP gain. The only problem I can see this possibly causing is circular logic if UR is using
sell_val() to evaluate restorative items. The downside is an additional data file loaded per BatBrain instance (although only if there are items being evaluated, which isn't
quite every combat). What do you think?