BatBrain -- a central nervous system for consult scripts

Is it? If KoL - and Manuel - has the <i> tags in the monster name, we need to, also. Looking at Manuel's entry:

Code: 
<b><font size=+2>C<i>bzzt</i>er the Grisly Bear</font></b>
A-yup. KoLmafia's name of the monster does not agree with what we see from Manuel - and presumably from the fight page, given what the session log says.

This is a KoLmafia issue.
 
Huh. I just didn't figure that we would add italics to an official monster name and BatBrain would have to normalize that. Like a Hobo name not matching in the cli.
 
@Veracity - Thank you.

@Bale - I think it is now a BatBrain issue. :)

The session log, gCLI, monsters.txt, and Manuel are now in agreement on the name of the monster but BatBrain and BatMan's Factroid component aren't recognizing the monster name with the embedded HTML tag.
 
Last edited:
Bale said:
Huh. I just didn't figure that we would add italics to an official monster name and BatBrain would have to normalize that. Like a Hobo name not matching in the cli.
Click to expand...
Hobos have multiple names in the encounter, but normalize to a single monster type per element.

This monster has a single name in the encounter and we agree with that name now; we did not "add italics" to an "official monster name". The "official monster name" already HAS italics.

What does BatBrain need to "normalize"? Why not just recognize the single consistent name?
 
A quick grep of BatBrain and monsters.txt reveals that BatBrain is parsing the session log for encounter information and C<i>bzzt</i>er the Grisly Bear is the only monster name with embedded tags.

Here's the relevant code from BatBrain:
Code: 
boolean loghaps() {   // load happenings/round info from session log
   if (!to_boolean(get_property("logBattleAction"))) 
      return vprint("Cannot parse combat actions from your session log because you have disabled logging combat actions.  Please change this in your preferences (or type \"set logBattleAction = true\" in the CLI).",-1);
   string log = session_logs(1)[0]; // load today's log
   round = last_index_of(log,"Encounter: "+m);
   if (round == -1) {
      vprint("Encounter with \""+m+"\" not found!  Attempting case-insensitive match...","olive",-3);
      round = last_index_of(to_lower_case(log),"encounter: "+to_lower_case(m));
      if (round == -1) return vprint("This encounter cannot be found by name; logging happenings the old way.",-2);
   }
 
"Parsing the session log". Yeah, there's another discussion about that somewhere around.
Regardless, the "official name" of the monster has italic tags in it, whether it is in the page HTML, lastEncounter, or the session log.
 
Agreed. This definitely seems to be a BatBrain issue at this point.

Edit: BatBrain is also complaining when there are diacritical marks in a monster name.

Code: 
Encounter with "Novia Cadáver" not found! Attempting case-insensitive match...
This encounter cannot be found by name; logging happenings the old way.
 
Last edited:
Those messages are not complaints. They are also not errors. They are informational. As previously noted, they will also fire in a lot of normal cases where monster names are randomly generated, or where mafia disambiguates (or ambiguates) monsters. In none of the cases does it mean BatBrain is experiencing an error. If it can't find the monster name (as given by last_monster()) in your session log, it will simply detect events from the page, as it used to before the revamp. The only downside is that BatBrain can not track events that were not submitted via macro, and won't know what you may have done prior to handing the fight to BatBrain.

I guess I should bump up the verbosity on those so that people who see those messages as problems can opt to not see them. I personally enjoy knowing whether BatBrain is tracking the new way or the old way (and in at least three cases now, typos or other errors in mafia's monster names have been fixed as a result of the messages), but I understand that not everyone cares.

I'm about ready to try skipping the monster name entirely and simply finding the most recent "Encounter: ". My qualm is that it seems a bit more prone to user error (for example if a script ever prints "Encounter: " or writes it to the log).
 
@zarqon: I misunderstood the intent of the messages. I would advocate for leaving them in as it can, as just noted a few posts back, lead to investigation and fixing of mis-matches.

One question I have though is that since BatBrain doesn't recognize the monster name it seems to stop Factroid from properly processing the Monster Manuel entry. Is that a Factroid or a BatBrain issue?

Thank you.
 
Last edited:
zarqon said:
As previously noted, they will also fire in a lot of normal cases where monster names are randomly generated, or where mafia disambiguates (or ambiguates) monsters.
Click to expand...
I'm curious: when does KoLmafia ever "ambiguate" a monster? That would imply that KoL has multiple "official" monster names, as identified by the unique "monster ID" that we now know about, that it makes the "official" monster known to the player in the page text, somehow, but KoLmafia conflates multiple distinct monster into an "ambiguous" monster which might be any of several "official" monsters.

Considering that each KoLmafia monster now has KoL's "monster ID" as part of it, I don't see how that is possible.

Yet, here you are claiming that KoLmafia "ambiguates" monsters.

Elaborate, please?

in at least three cases now, typos or other errors in mafia's monster names have been fixed as a result of the messages
Click to expand...
I guess I missed those. I recall us fixing things that don't agree with Manuel. I assumed that was a result of things like missingManuel being unable to match them. I.e., scripts that actually look at the one and only place in KoL where we can look to see what the "official" monster name is, rather than the session log which records ... whatever KoLmafia feels like recording.

I'm about ready to try skipping the monster name entirely and simply finding the most recent "Encounter: ". My qualm is that it seems a bit more prone to user error (for example if a script ever prints "Encounter: " or writes it to the log).
Click to expand...
If you want the "Encounter" that KoL supplied in the "monname" span, that is reliably available in the lastEncounter setting.
If you want the "official" monster name (as shown in Monster Manuel), that is reliably available via last_monster().
 
Monster ID simply isn't available in-combat, even if you have the manuel entry. However, if you had only the tool-holding batwinged gremlin's factoids, then you'd be able to tell the difference between the two based on factoids. In that sort of scenario, Mafia would ambiguate the monster.

Also, all of the El Vibrato constructs come in two flavors, apparently.
 
heeheehee said:
However, if you had only the tool-holding batwinged gremlin's factoids, then you'd be able to tell the difference between the two based on factoids.
Click to expand...
I have never seen factoids displayed on the round 0 combat page. Aside from the fact that we have to work for players who don't have Manuel, I'm curious to hear how we can tell from what is on that page whether it is a tool gremlin or a non-tool gremlin. If, in fact, we can reliably (no false identifications at all) distinguish from what Manuel says, I wouldn't mind letting Manuel owners know that from the get-go so they can skip stasising.

Also, all of the El Vibrato constructs come in two flavors, apparently.
Click to expand...
Excellent. Sounds like a bug report is needed! We have no reason to not have both versions of all of those, since you either have one or the other, based on what you have equipped.

Or, perhaps, this should be discussed in the Monsters have an integer associated with them thread which I left open specifically so we could discuss this kind of thing.
 
Veracity said:
I have never seen factoids displayed on the round 0 combat page. Aside from the fact that we have to work for players who don't have Manuel, I'm curious to hear how we can tell from what is on that page whether it is a tool gremlin or a non-tool gremlin. If, in fact, we can reliably (no false identifications at all) distinguish from what Manuel says, I wouldn't mind letting Manuel owners know that from the get-go so they can skip stasising.
Click to expand...

Specifically, you get the manuel stats only for the gremlin you have factoids in that scenario. It's incredibly niche and requires that you never kill the monster that doesn't have the tool, which is pretty stupid.

I guess you could also know if you got the monster via Rain Man.
 
Veracity said:
I'm curious: when does KoLmafia ever "ambiguate" a monster?
Click to expand...

I was using that to apply to single monsters with varied names, such as hobos, tower skeletons, et al. Another example which comes closer to what you're mentioning (distinct monster names and images) might be Your Shadow, but even then it's a single monster ID. I wasn't meaning to imply that mafia groups multiple IDs into a single $monster[].

Also, besides our friend Cbzzter above, I found and reported a few capitalization/spelling errors in monster names a while back as a result of the mismatch messages in BatBrain.

Veracity said:
If you want the "Encounter" that KoL supplied in the "monname" span, that is reliably available in the lastEncounter setting.
Click to expand...

Brilliant! I should have thought of that. I'll use Encounter: lastEncounter for the next update and leave some higher-verbosity informational messages in just to retain the helpful mismatch-finding ability.

@Magus: If a name mismatch between last_monster() and the name in the session log causes BatBrain not to register factoids properly, it's caused by something other than the name mismatch, since factoid tracking only ever looks at last_monster() and doesn't consider the name in the session log. The only thing BatBrain uses the session log for is tracking victories and player actions, and it finds the relevant combat in the log by looking for the last instance of Encounter: last_monster(), though as I just mentioned, that is soon to change. Do you have any examples from your logs of BatBrain failing to log a factoid?

Also, you can always hit the "Refresh Manuel Data" button at the bottom of Factroid! to re-scrape Manuel and make sure your factoid information is current.
 
zarqon said:
Also, besides our friend Cbzzter above, I found and reported a few capitalization/spelling errors in monster names a while back as a result of the mismatch messages in BatBrain.
Click to expand...
Oh, right. I forgot about the buzzy one. Fair enough!
 
The day of the dead wandering monsters all fail to match. Here's a couple of other ones.
Code: 
Encounter: the queen filthworm
Round 0: Crowther wins initiative!
Round 1: Crowther tries to steal an item!
Round 2: queen filthworm takes 65 damage.
> Encounter with "queen filthworm" not found!  Attempting case-insensitive match...
> This encounter cannot be found by name; logging happenings the old way.
Code: 
Encounter: the Big Wheelin' Twins
Round 0: Crowther wins initiative!
> BCC: Run_Combat() being used normally.
> Encounter with "Big Wheelin' Twins" not found!  Attempting case-insensitive match...
> This encounter cannot be found by name; logging happenings the old way.
 
r66 Update

Changed as mentioned above. This ought to mean that in 100% of cases, BatBrain will use the session-log-based tracking method. I'll retain the current fallback strategy unless/until it proves to be entirely unnecessary.

Also, a while back I put out a fix for the Toss issue (r65). We were cleverly attempting to save precious milliseconds by not setting fvars[fweight] if you didn't have a familiar (often true in certain paths), but our cleverness came back to bite us in the Toss.

As for Pinch Ghost, BatBrain presently has no support for specifying damage which bypasses monster resistances. The twitchleak for monster abilities heeheehee very awesomely shared revealed a "penetration" mechanic which seemed to be largely un-accounted for anywhere other than the ninja assassin damage formula. Perhaps certain skills have a similar mechanic vs. monsters?
 
zarqon said:
@Magus: If a name mismatch between last_monster() and the name in the session log causes BatBrain not to register factoids properly, it's caused by something other than the name mismatch, since factoid tracking only ever looks at last_monster() and doesn't consider the name in the session log. The only thing BatBrain uses the session log for is tracking victories and player actions, and it finds the relevant combat in the log by looking for the last instance of Encounter: last_monster(), though as I just mentioned, that is soon to change. Do you have any examples from your logs of BatBrain failing to log a factoid?
Click to expand...

I was imprecise in my description of the current issue. I have all three Monster Manuel factoids for Cbzzter but Factroid isn't recognizing that even after I use the "Refresh Manuel Data" button.

Until today I thought that was a side-effect of BatBrain not recognizing the monster.
 
Aha. I trust that after mafia r15725, Factroid! correctly shows you having all three factoids?

The only connection between BatBrain and Factroid! is in adding new factoids when you get them, for the sole purpose of being able to save a re-scrape the next time you load Factroid! If refreshing your data direct from Manuel -- which rebuilds everything from scratch and thus overwrites whatever information BatBrain supplied -- didn't solve the issue, then the issue has nothing to do with BatBrain.
 
You must log in or register to reply here.
Back
Top