Feature - Implemented Tracking Combat Monster Level

monster_attack() gives you the current (estimated) monster attack for your current fight.

Using current information, while fighting Lord Spookyraven,
Code: 
ash monster_attack($monster[Lord Spookyraven]) - monster_attack();
should return Lord Spookyraven's difference from his base attack. No need for another command to be added, necessarily.

Since it sounds like Jick is actually going to be adding in delevelling descriptions for all, no need to overload monster_level_adjustment either... and for that matter, no reason to have the current(ly implemented in release) combat delevelling variable anymore, as we never have a single "something" delevel, but have either attack, defence, or both modified by a specific number... So all that should be left is making sure that all of the various bits are known, and then (until they tweak the descriptive text) setting up regexp matchers and repeatedly matching on them... we don't really care WHAT is causing the delevel, as long as we know the total that it's done.
 
Theraze said:
So all that should be left is making sure that all of the various bits are known, and then (until they tweak the descriptive text) setting up regexp matchers and repeatedly matching on them... we don't really care WHAT is causing the delevel, as long as we know the total that it's done.
Click to expand...
Is that true? Or do you want to see the "attack deleveled by 5" immediately in the session log after the item, familiar, spell, whatever that actually did it?

I ask, because we initially used the "regexp matcher" technique to accumulate all the damage into a single number, and I went to quite a bit of effort to split it up into source. I WANTED to see that such-and-such damage came from my familiar, or this item, or whatever.

In other words, I disagree with the philosophy you just expressed.
 
Well, part of the question is, where in the session log would that be displayed? Right now, the currently implemented delevelling skills don't display what they do anywhere... it just does things like:
Code: 
  case 5003: // Disco Eye-Poke
   FightRequest.levelModifier -= FightRequest.stealthMistletoe * 3;
   break;
with no logging possible or done or anything. If we're wanting notification on these? That's a major rethink on HOW delevelling is tracked by mafia, not just making it work right. Not saying we can't. Just saying it wasn't and isn't being done currently.
 
Right now we clean the HTML of fight.php and walk the tree, interpreting actions and results in order. That allows us to interpret and log the messages in the order they are seen, and apply whatever the result is.

Back when deleveling did not give you combat messages, we clearly could not do that. But, now that it DOES give you combat messages, we should detect, log, and apply results using that mechanism.

Or, you know, perhaps we should only log things that way, considering that Haiku combat does not give you the numbers. Or, perhaps it does, in non-displayed HTML data, just as damage is provided that way, even if the damage is not in a haiku. Have you ooked at haiku deleveling? The Wiki has a set of haikus that indicate it was done, for some classes of attacks, at least.

In any case, in my opinion, adding up all the deleveling effects and logging them in a single number is inconsistent with how KoLmafia logs other actions in fights and is, therefore, a non-starter, in my opinion...
 
Sure... I'm just saying that we already had hard numbers for the DB delevellings and those before, and didn't log them. To be consistent though, that means a new GUI menu option for logging the delevelling, since everything else that actually can get logged during combat can be displayed or hidden. So... if we're actually going to do that then, what do we want to use?

And for the record, I wasn't talking about smashing it all into one... just that, as historically it hadn't been logged, it didn't matter as much where it got parsed. If we're planning on changing things and logging this, we'll just throw that regexp into the same zone as damage checks... should keep the messages together.
 
I looked at Haiku right after the rollout and there was nothing, but haven't checked since, and it doesn't surprise me to hear that that was fixed.

For reference, I was only saying that "I" personally didn't care about sources, just totals, but especially since damage is broken up into sources, it completely makes sense to do the same for deleveling. Also, I can see that as being something that would be quite nice to be able to aggregate from a log parser.

What's more, breaking up deleveling into sources could theoretically make spading future ranges much less of a hassle, I would imagine. Though, the KoL change itself likely does enough on that front, but you never know what will happen down the line...
 
My current assumption is that this will last as long as it takes the bawwing to heartily annoy Jick and will get re-obfuscated within the week/month. Do something to make life easier for the newbies and watch what it gets you...

Anyways, until then, we can easily parse. Once it gets reobfuscated, either we need to go back to my original patch (hopefully with better numbers) or we parse whatever else we've been given.
 
Theraze said:
My current assumption is that this will last as long as it takes the bawwing to heartily annoy Jick and will get re-obfuscated within the week/month. Do something to make life easier for the newbies and watch what it gets you...

Anyways, until then, we can easily parse. Once it gets reobfuscated, either we need to go back to my original patch (hopefully with better numbers) or we parse whatever else we've been given.
Click to expand...

Are people actually complaining about this change? Man, some peopel are strange. I love this change :)
 
It's pretty much a given that scripters will love this change, though... :)

Thinking about how to make this information available in ASH is rather interesting, actually. There are now three components to monster stats now. Scripters should be able to access all of these components:

  1. base monster stat
  2. base monster stat adjustment
  3. in-combat monster stat adjustment

As I understand it, the current monster stat functions (before your patch) return (1+2). This is fine since monster_level_adjustment() returns 2; we can deduce 1 using the Power of Arithmetic!

But adding a third component makes things dicey. We will only need to add two more functions, but which distributions of the components do we return to maximize usefulness? Do we want the functions to return (1+2) with additional functions for 3 (something like monster_attack_adjustment())? Or do we want functions for (1+2) and (1+2+3)?

I think this is what StDoodle was getting at. In practice, people will need to access 1+2+3 far more often than they'll need to access just 3, so I'd recommend keeping monster_attack() using only (1+2) for legacy reasons (probably important?), and adding something like adjusted_monster_attack() for (1+2+3).

Thus to access each stat component, we would need:

  1. monster_attack() - monster_level_adjustment()
  2. monster_level_adjustment()
  3. adjusted_monster_attack() - monster_attack()

Which seems more involved than it needs to be, but these functions are, in my opinion, the most useful way to provide the information.
 
Yeah, I think z's stuff seems in line with what I was saying. There are basically three situations where you'd want to check monster stats.

1) Before you even go adventure somewhere, and you want to see if it's feasible to do so. In this situation, you want the raw (unmodified at all) monster stats, and possibly your current raw +ML (or its direct changes to the various stats) so you can figure out whether you want to add / shrug aria, other ML modifiers, etc., or whether you should just plain wait on adventuring wherever.

2) Start of combat. You can't at this point change the raw +ML, but you want to know how much deleveling you'd need to do to get to "safe" levels. Note this won't always matter, depending on combat strategy, but is vital for starfishing & the like. What's important at this stage is the starting stats of the monster, as well as what delevling you can manage (which would likely be scripted instead of accessible using built-in data, which is fine).

3) Further into combat. You want to be able to recognize when you've reached a "safe" level for starfishing / etc.

I really don't have a huge preference for HOW we get there, but I am going to beg & plead that, once done, it's made very clear just how each relevant function works. Assuming that a straight parameter-less call to monster_defense() in a consult would return the current value, when instead it returns the base value or start-of-combat value could be very problematic.
 
After reading your post, StDoodle, it just occurred to me that there are almost no published in-combat scripts relying on monster_att/def() being 1+2, so screw legacy reasons -- I'm happy to edit my scripts. It would indeed make the most sense to have the basic stat functions be comprehensive and current (1+2+3).

And if we can do monster_attack(last_monster()) - monster_level_adjustment() to get 1, and monster_attack() - monster_attack(last_monster()) - monster_level_adjustment() to get 3, we don't really need any additional functions. That seems a bit of a hack though, so functions like initial_monster_attack() (1+2) may still be best for clarity's sake.
 
Yeah, but I think you're making it sound a bit more complicated than it needs to be, as we don't really need #3 do we? I mean, it's fine as an alternative to current_stat_as_of_right_friggin_now(), cause you could use it to do the math along with what_the_stat_would_be_without_any_changes([monster]), but it seems to me like you're proposing a need to know the actual deleveling amount, when I can only see a use for the current stat. I dunno, I'm just saying the same things over and over at this point, but like I've said, I'm a horrid communicator. :P
 
Hmm... I think I may have misread things when I was originally typing this up. Anyways, if what he's saying with 3 is knowing what monster_attack and monster_defence are right now... as the relay browser shows if you're manually adventuring... that's valid and logical as needing to be known. If 3 is about knowing how much delevelling you've done so far? Useless except in terms of bragging rights. :D

If you use a delevelling attack with current official KoLmafia in the relay browser, that's tracked (basically the DB delevels), you'll get the monster's attack and defence dropping visibly there. As well, as they become adjusted, as that's the only thing that matters in terms of whether or not you're likely to get hit or dodge, those are the numbers it uses. As it currently stands, what is actually available with official KoLmafia is all 1-3, but in varying forms based on when you try it...

What you need to know is if you're going to get hit and if you're going to dodge... Hypothetical circumstances are great and all, but knowing that 5 delevels MIGHT be enough to be safe isn't useful if you get unlucky and it takes 8. Which is why the new (currently) displayed information is great... you can (with a 5% margin of initial error) know with certainty that you should be safe at any given point in time... Knowing that you've dropped them by 80 points is wonderful... but useless. Knowing that their current attack is (probably, within a 5% initial margin of error) 173? Wonderful.

Anyways, if we scrap the combat delevelling information we currently have in KoLmafia (the official one that's in), then doing the operation of 1-2 will give us base information at any point in time. During combat, we can run monster_attack() or monster_defense() to find out if we're safe yet, and likely to win. Having the NS reset delevelling should be easy as well... just set the attack and defence modifiers to 0 when she resets, instead of changing the level modifier.

Biggest issue will probably be around Veracity's new "log it" initiative. :p Needs a new name for the logging preference, description for the GUI, etc.
 
But it's not monster health... it involves familiar actions, item usage, equipment actions, pasta guardians, monsters attacking you... The message just matches that they've been weakened, not why, so if you don't have the proper combat preferences on (realistically, all of them except reversing adventures), the information is useless for spading or logging...
 
I suggest that you look at the code where we use the preference I named. It logs changes to monster health - read: HP, currently - caused by weapons, skills, familiars, items, effects, umm, well, basically any source of damage. So, your comment that deleveling comes from multiple different sources is a red herring. Yes, if you want to see familiar actions, you have to enable those. So what?

The only question is whether getting "weakened" is affecting the monster's "health". Obviously, I think it is similar enough to HP that sharing a preference is fine. You apparently feel it is different and needs a different preference. Why?
 
The freakishly wide variety of things that can delevel are why I was happily moving along with the (existing) silent delevelling. Logging is great, if it's useful. It's only useful if you know what caused the delevel. You only know what caused the delevel if you're logging that event already, as delevelling is a component of another action, and doesn't necessarily cause damage.

This leaves us with two major choices, and two sets of two minor choices under the second.
1) Don't log, just do it silently. Advantages? People don't get confused about their weapon delevelling when it's actually their familiar, or their psalm of pointiness, or or or. Disadvantages? Doesn't lend to spading.
2) Log. Existing or new preference, forced or individual choices.
a) Use an existing preference. Advantage? No new GUI modification. Disadvantage? Unintended behaviour... they're asking for something other than what we're giving them. Potentially causes useless logs due to not having relevant information logged.
b) Use a new preference. Advantage? People can see it if they want it. If they're spading something odd that isn't logged normally, they can turn on delevel tracking only when they want to spade their new shinies. Disadvantage? Further clutters the preferences GUI page.
i) Forcing all logs on if tracking delevelling. Advantage? Prevents the logs being potentially useless for consideration at over 5 minutes in the past, especially if the delevelling preference is piggybacking on an unrelated one. Disadvantage? Logs get huge, no way to actually have combat logged the way you like it if a preference you want is the one that's conjoined to the delevelling.
ii) Individually allow for logging. Advantage? Logs are the way you want them, useful or not. Spading with just logging the delevels, if you limit your combat to only do a single type of delevel, couldn't be easier. Disadvantage? Newbies may get confused about which they need to select to have things work properly, and end up with confused logs.

Summary: Logging is well and good. If we're going to log, let's make it a USEFUL log. :)
 
Last edited:
Veracity said:
I suggest that you look at the code where we use the preference I named. It logs changes to monster health - read: HP, currently - caused by weapons, skills, familiars, items, effects, umm, well, basically any source of damage.
Click to expand...

I have looked at that, extensively... for the record, in current code, while monster health tracking is always on whether or not you set it for relay browser sessions, it only properly heals the one tracked mob (boss bat, if memory serves) if you have health logging on, though it tracks damage properly either way. In the patch, I moved the unlogged exit down below the mob heal segment, and made the mob heals tracked regardless of whether or not the logfile will display it, so that the relay browser is as correct as it can be. It still only logs if you actually want it to be logged though. I considered that to be a bug with the current mafia code, but since I was already adding in another 8-10 monsters that heal themselves, didn't make another bug report on it, just fixed it and moved on. :) I can make a bug report and include just the code to fix that though if you like...
 
It seems like we are not communicating. I do not have time for further back-and-forth to try to fix that, assuming it is even possible. Just go ahead and do whatever you want. I will adjust and fix it to my taste before submitting it, after I take the time to look at it, after you finish, eventually.

Ping me when you are all done so I can look at the patch.
 
Sorry that we're having a communication breakdown. I think I understand what you're wanting, I just think that there are consequences that may not have been considered fully. If they have been considered and set aside, then they no longer exist as objections to what you've proposed and full steam ahead. :p

From what Veracity says, logging WILL be in. The question is, of the 4 choices I gave above (ai, aii, bi, bii), which do we want? Each has advantages and disadvantages? As I understand, Veracity was proposing aii. Use an existing preference, don't do anything regarding other preferences. This gives the advantage of keeping the GUI nice and neat, but gives (imho) useless logs. If she tells me to go ahead with this now, I'll do it. I'll turn off monster health logging for myself, but I'll do it. :)

If she doesn't weigh in again and tell me how it's going to be, for the rest reading this, what do we want? My suggestion is doing either ai (existing preference, force all the other logs on if you are tracking develling so that logs are useful) or bii (new preference, no forced additional logging). I'd heavily suggest bii instead, as I think that giving people information they don't want is annoying. Also, bii makes new-spading shinies easy.

Opinions?
 
You must log in or register to reply here.
Back
Top