Feature - Implemented Unique combat flag

As mentioned in the BatBrain thread, I haven't been able to figure out how to detect in a particular script instance whether or not I am in the same combat as the previous instance. Setting a flag that is a combination of the monster you are facing and your total turncount is what BatBrain is currently using, but this can be defeated by faxputtying and even free runaways, leading to confusion in events tracking and false assumptions that the combat is already over.

So I would like to request that mafia, which keeps running for each entire combat (unlike a combat script, which could be called at any point during the fight), set a flag when combat begins. A combat script could then check that flag when it runs to detect whether or not it is in the same fight.

This is kind of a niche request, as presently I don't know of any other scripts that would benefit from this flag, so I'd like to request something I believe to be fairly simple: a property, perhaps called lastCombatStarted, which is set with a timestamp whenever a fight starts.

This feature would allow me to make some fairly sweeping speed improvements to BatBrain, as well as solve combat event tracking problems that occur when BatBrain gets confused during things like faxputtying.

Some users may also like to see this information in their session logs, e.g.

[1234] The Castle in the Clouds in the Sky (Top Floor)
Encounter: Goth Giant
Time: 11:59:45:654am +900
Round 0: zarqon wins initiative!

Would setting something in an afterAdventureScript work as a workaround?

Possibly yes. Do those fire when, say, a betweenBattleScript fights multiple copied monsters in sequence?

Also it would mean BatBrain would commandeer people's afterAdventureScript slot, which would be better avoided.

Not got the code in front of me, but I think there is a flag we use internally, so it'd just be a matter of exposing it. Edit - no, sorry, we just track whether we are in a fight, not which one.

I've realized another benefit of implementing this. For fight.php overrides, my_turncount() varies on the final page load: it's sometimes the turn of the fight, sometimes the next turn. BatMan RE has to do some wonkery to get around this, planting a JavaScript variable in the page before loading it, then reading that variable to determine whether to adjust the turncount reported by the function. Implementing this would make all of that soooo much easier.

Another way it might benefit is in an odd bug I've been having recently. Not sure if it's SmartStasis or WHAM, but one of the two pieces seems to consistently have issues with automating fights that take no adventures and contain the same monster back to back (seals, for example). It'll go through the initialization process for the fight, then tell me the fight has been finished and red out, leaving me to refresh the relay browser and fight it myself. If there were a unique combat identifier, I imagine whatever it's currently looking at to say the battle is over would no longer be a problem.

That bug is one side effect of this very issue. It's happening because actions tracking in BatBrain is using monster plus turncount to identify your combat -- which breaks when you fight multiple of the same monsters on the same turncount.

I can't think of a way to code around it without just deleting the previously recorded combat, which I don't want to do because I want to be able to present the previously recorded combat as a macro option, as BatMan RE presently does. It's a huge timesaver in relay play. I could maybe code around THAT by adding another dimension to actions tracking, so that multiple combats could be stored in a single turncount, but rather than complicating the data structure and all the code that deals with it -- and probably making an already slightly-too-slow script even slower -- this feature would instead let me simplify the code in multiple places.

Darzil said:

Not got the code in front of me, but I think there is a flag we use internally, so it'd just be a matter of exposing it. Edit - no, sorry, we just track whether we are in a fight, not which one.

Click to expand...

How hard would it be to set a property whose value is gametime_to_int(), whenever a combat begins?

If you're asking me, Bale, impossible. BatBrain may only start running several rounds into a combat. If you're positing that to the devs, that would work but I'd then have to add the current date to the front of it to avoid false matches from previous days. A regular old timestamp would be simplest (includes date, sortable).

I was actually asking Darzil (whose comment I quoted) how hard it would be to add it to KoLmafia. Sorry for the lack of clarity.

zarqon said:

If you're positing that to the devs, that would work but I'd then have to add the current date to the front of it to avoid false matches from previous days.

Click to expand...

Both mafia's setting and your script's setting would reset at rollover, since KoL ends the combat then.

That's why I'm requesting a timestamp rather than gametime_to_int(), so that it will actually uniquely identify a combat. I'm not sure what you mean by my script setting resetting, but my plan is to store the requested lastCombatStarted preference as part of the combat tracking data structure (using the timestamp where it presently uses turncount), which persists over days and even ascensions. Thus, if I were comparing stored combats vs. a specific monster to the current gametime without also including the date, it's possible that the same problem as now could be encountered (though rarely).

@Bale: no worries, I just wanted to reply to both possibilities so as not to reply to the wrong one.

zarqon said:

That's why I'm requesting a timestamp rather than gametime_to_int(), so that it will actually uniquely identify a combat. I'm not sure what you mean by my script setting resetting, but my plan is to store the requested lastCombatStarted preference as part of the combat tracking data structure (using the timestamp where it presently uses turncount), which persists over days and even ascensions. Thus, if I were comparing stored combats vs. a specific monster to the current gametime without also including the date, it's possible that the same problem as now could be encountered (though rarely).

@Bale: no worries, I just wanted to reply to both possibilities so as not to reply to the wrong one.

Click to expand...

My point is that you want _lastCombatStarted so it resets at rollover, not lastCombatStarted. If rollover happens, you are guaranteed to not be in the same fight from before rollover. Except I think that's the name mafia will use for the setting name, so you'll need a different name. You probably don't actually care about how the setting is formatted, since all you have to do is check if the values are equal.

I have a bit of code written that seems to work fine from basic testing, though I'm going to tweak it a bit more before actually adding it. Is there any purpose where "HHmmssSSS" in GMT (24 hour/minute/second/millisecond) isn't sufficient?

I've read your post again. Apparently you're storing information about previous fights for all of eternity, but you aren't tracking the date they happened on so you don't know if they happened today.

I guess there's no real reason to not use "yyMMddHHmmss" as the format.

lostcalpolydude said:

I guess there's no real reason to not use "yyMMddHHmmss" as the format.

Click to expand...

+1 on HH vs hh
I'd probably make it yyyy and not just yy. Some of us are still gun shy after cleaning up Y2K.
Is this the local time or what the KoL server reports as the time? I am hoping the latter if only because it makes time zone irrelevant.

fronobulax said:

Is this the local time or what the KoL server reports as the time?

Click to expand...

The third - and superior - option would be to just use UTC.

fronobulax said:

I'd probably make it yyyy and not just yy. Some of us are still gun shy after cleaning up Y2K.

Click to expand...

I can't imagine KoL being around that long, or KoLmafia, or combat not changing so much that the setting is no longer useful, but why not?

16491

January 20,2038

"Alright, the '38 bugs are all cleaned up. Time for a new Sauceror run, since I won't have to fix that bug again for another 292 billion years or so."

Fantastic! Thank you! Now, let the overhauling begin!