BatBrain -- a central nervous system for consult scripts

zarqon said:
Or are you saying that mafia doesn't track deleveling and damage done to monsters of unknown stats?
Click to expand...

That would appear to be the case.
Code: 
[414] Itznotyerzitz Mine
Encounter: mountain man
Round 0: Winterbay wins initiative!

> ash monster_attack()

Returned: 0
Round 1: Winterbay casts INTIMIDATING BELLOW!
Round 2: mountain man drops 27 attack power.
Round 2: mountain man drops 27 defense.

> ash monster_attack()

Returned: 0
Round 2: Winterbay casts MIGHTY AXING!
Round 3: mountain man takes 79 damage.

> ash monster_hp()

Returned: -79
Round 3: Winterbay casts MIGHTY AXING!
Round 4: mountain man takes 74 damage.
Round 4: Winterbay casts MIGHTY AXING!
Round 5: mountain man takes 69 damage.

> ash monster_hp()

Returned: -222
Round 5: Winterbay casts MIGHTY AXING!
Round 6: mountain man takes 72 damage.

> ash monster_hp()

Returned: -294
Round 6: Winterbay casts MIGHTY AXING!
Round 7: mountain man takes 79 damage.
Round 7: Winterbay wins the fight!
You acquire an item: asbestos ore
You acquire an item: linoleum ore
You acquire an item: chrome ore
You gain 16 Strongness
You gain 4 Enchantedness
You gain 5 Roguishness

It does track the HP as can be seen but the monster_attack stays at 0 no matter my delevelling. I'm not sure if this is an error with Intimidating Bellow (the only delevelling I had available) or a more general problem. I guess I should go and report that in the bug-forum...
 
As this code:
Code: 
		int baseAttack = MonsterStatusTracker.monsterData.getAttack();
		return baseAttack == 0 ? 0:	// 0 means unspaded
			Math.max( baseAttack + MonsterStatusTracker.attackModifier, 1 );
shows, it's intentional. Now, WHY it's intentional, I don't know. I'm sure there is a bug report floating around that inspired it.

I found it. This bug report by Bale inspired me to commit Revision 9427 to adjust the code to work as it does currently.
 
Last edited:
Thanks for tracking down that bug report, Veracity. Am I right in thinking that changing that to return baseAttack + MonsterStatusTracker.attackModifier when baseAttack is 0 (without the max()) would solve both issues? In other words, only apply the lower limit when the stat is known.
 
Yes. I can do that. I wonder what Bale will say? We do return negative HP if an unspaded monster takes damage. Is returning negative attack/defense acceptable?

An alternative is to give you access to the "base" stats and the "modifiers" separately in new ASH functions and let you decide what to do.
 
Last edited:
I think returning negative attack/defense is a good way to go since then if the monster is at 0 we know it's not been tampered with and if it's at negative numbers it's been lowered by that much and things can thus be adjusted to take that into account.

Would there be a difference between "monster_attack()" (current stats) and "monster_attack($monster)" (base stats) and the second suggestion?
 
Revision 10747 does this for attack (and similarly for defense):
Code: 
		int baseAttack = MonsterStatusTracker.monsterData.getAttack();
		int adjustedAttack = baseAttack + MonsterStatusTracker.attackModifier;
		return baseAttack == 0 ? adjustedAttack: Math.max( adjustedAttack, 1 );
The second suggestion would have left monster_attack() unchanged, but would also provide monster_attack_adjustment() to see exactly how much the base attack had been tampered with.

I can still provide monster_attack_adjustment(), monster_defense_adjustment(), and monster_hp_adjustment(), if scripts would find those useful.
 
So basically, if monster_attack() is negative, it's been delevelled by that much and it's an unknown monster. If monster_attack() is 1, it might have been massively delevelled, but it's a known monster. Regarding Winterbay's question, monster_attack($monster) should still return the 0, since it's an unknown monster with base (non-adjusted) stats, but you don't strictly need to check that if you already know that the attack is negative...
 
Excellent! Thank you Winterbay and Veracity for exposing and then fixing this bug. :)

Personally, I don't think those additional functions are necessary, since they're the same as monster_stat() - monster_stat(monster).

The word "monster" starts to look really strange after a while.
 
Hmm... any chance that BatBrain is getting confused about defensive stats in axecore runs? Here's what DAM outputs, and I've added a bit to the Broadside display for when it isn't used:
ATT: 232 (94% × 1, death in 3190000)
DEF: 212 (95.45% × 87.67, win in 2550000)
HP: 250, Value: 616.25 μ
Run SmartStasis! (2 profit to stasis with spectre scepter -- low)
Profit per round: ActionProfitDamageOtherbase (0μ)0μ--
Broadside: 4.0 DPR:-0.94 MPH: 5.3333335 MPM:8.0
DestroyAllMonsters starts now! (0mp option Mighty Axing -- killrounds: 3, dierounds: 3190000)
Click to expand...
That's with the following Broadside code (placed right after, and based on, the noodle code):
Code: 
   if (round < maxround && !is_our_huckleberry() && get_action($skill[broadside]).stun > 0 &&
        m_dpr(0,0)*4*meatperhp > mp_cost($skill[broadside])*meatpermp)
      macro(get_action($skill[broadside]));
   else
      vprint("Broadside: "+get_action($skill[broadside]).stun+" DPR:"+m_dpr(0,0)+" MPH: "+meatperhp+" MPM:"+meatpermp,5);
So it's 4 rounds of stun, at an expected damage of -.94 HP lost per round. In actual fact, I took 76 damage the first round and 75 the second, which is slightly more than negative 1. :) This character has 247 buffed muscle currently and hero is permed... but since I'm in a Boris run with Trusty (and no shield), it should be using my moxie... which is at 125.

Edit: Something's definitely up... just did the same with noodles in aftercore against a sponge that hits me for ~40 damage a round, and got
Noodles - DPR:-0.94 MPH: 0.07285714 MPM:1.5
Click to expand...
...wait, exactly the same damage per round? Eh, something's wrong here. :)
 
Last edited:
Yeah... probably another positive that should be negative. I'll look into it.

EDIT: Found it. I'd changed the numbers properly but forgotten to flip a min() to a max(). Updated post 587 again.
 
Last edited:
Spiffy, that makes m_dpr change now. :) But that makes something else visible...
Broadside: 4.0 DPR:-44.981316 MPH: 5.3333335 MPM:8.0
Click to expand...
Or, to make it more clear:
Gain: -781.83026 Cost:80.0
Click to expand...
That would be with
Code: 
   else
      vprint("Gain: "+m_dpr(0,0)*4*meatperhp+" Cost:"+mp_cost($skill[broadside])*meatpermp,5);
Basically, since m_dpr is negative now instead of positive (should it be? dierounds is still at 3.2 million...), SmartStasis needs to be set to negative m_dpr instead of positive m_dpr for its stasis checks.

For now, I've just thrown a - in front of the m_dpr in my stasis check and it's happily stasising away in the war now, making it MUCH less painful. :) For doing things right... not sure which way you want it to be, but SS and die rounds need to be updated if negative is right.
 
Well, it's been a week, so I just updated BatBrain, SS, and batfactors. Hopefully we won't see too many problems caused by these updates.

Everyone, for a problem-free update, perform these three steps:

1) Update BatBrain.
2) Update SmartStasis.
3) Delete batfactors.txt from your data directory.

I expect the authors of BB-powered scripts have updates ready to roll out for their scripts, since they had a week to prepare for this, but if you're using one of these scripts (i.e. DAM, WHAM, BLAM, SPAM, etc...) be aware that until they also post an update you might want to wait to update.

@Theraze: Thanks for rapidly sleuthing that. Damage should always be positive, healing negative. I fixed that in the posted update of BB.
 
Last edited:
Sorry if this is already a known issue, but:
I have upgraded BatBrain and SmartStasis, and now WHAM/DAM are throwing an error like:
Record expected (BatBrain.ash, line 217)
Consult script 'DestroyAllMonsters.ash' not found.
I tried upgrading both of the consult scripts, upgrading ZLib, deleting batfactors.txt (it hasn't reappeared).
I then tried running BatBrain on its own (typed BatBrain.ash into the CLI) and got
Record expected (BatBrain.ash, line 217)
again.
 
You need to either remove the line about batfactors.txt in the zversions.txt file in order to get batfactors.txt to reappear. Which should hopefully solve the issue.
I know that WHAM was working just fine for me today at least (with the version in teh thread)
 
I updated and got this, Any ideas? This running anyone of the scripts that use batbrain and smartstasis.

Round 0: Bors wins initiative!
Round 1: Bors casts TRANSCENDENT OLFACTION!
You acquire an effect: On the Trail (duration: 40 Adventures)
Expression syntax error for 'modifier_eval()': expected end, found perfect
Expression syntax error for 'modifier_eval()': expected end, found prism
Expression syntax error for 'modifier_eval()': expected end, found prism
WHAM: Running SmartStasis
WHAM: Starting evaluation and performing of attack
WHAM: Monster is weak. We are just going to bash its head in. It'll take 2 rounds.
Expression syntax error for 'modifier_eval()': expected end, found prism
Expression syntax error for 'modifier_eval()': expected end, found prism
Round 2: Bors executes a macro!
Round 2: Bors attacks!
Round 3: Bors wins the fight!
You gain 3 Strengthliness
You gain 8 Mysteriousness
You gain 2 Cheek
 
Did you update both BatBrain and SmartStasis, delete batfactors, and edit zversions to remove the line about map_batfactors?
 
Thanks for the report Bors. Since revamping how batfactors is loaded there can be no ignored damage types -- everything must be valid. In these cases, I'd changed "prism" to "prismatic", and "perfect" was never implemented to begin with. I've just changed the "prism" instances in batfactors, and will look at implementing "perfect" for the next BB release. In the meantime, those messages, like Earth, are mostly harmless -- "perfect" only applies to Goodfella contracts, plastic pumpkin buckets, and Knob Goblin organ grinders, so until the next update BB is assuming 0 damage for any of those. Update hastily posted posthaste.
 
You must log in or register to reply here.
Back
Top