Feature - Implemented Include variable/scaling monsters in monster stat functions

[jasonharper]

There HAS to be a distinction between values for normal monsters and scaling monsters - normal monsters' stats get your +ML added to them, scaling monster's stat expressions would already include ML to the extent that it might apply. I'm not sure the values are directly comparable, anyway - we appear to be using 100% defense values for most monsters in monsters.txt (which therefore should be multiplied by 0.9 to get the effective defense), but I think the proposed scaling monster formulas are producing the effective defense directly.

In any case, I think there's a bit too much overhead to Expression objects (such as that mostly-unused ArrayList with its default 10 elements) to want to have one for every single numeric value in monsters.txt.

 

[Theraze]

Well, the way it currently works is that scaling monsters with ML modifiers just have +ML added to the expression, and so what we'd do on "standard" monsters is have it automatically add +ML to the expression as it's being loaded. But if we want to avoid that, we can keep detection in there.

Okay... so we're going to turn them into MonsterExpressions instead of leaving it as strings, but only to the scaling monsters. They'll still need detection on it, since it's not happening to all of them, but we want to split out the detection to only look at the expression we're giving, in case we have mixed expression and non on the same monster for some reason.

Okay summary, or more redirecting? Let me know what I should do and I'll try to accomplish it as well as I can.

 

[Veracity]

I'll butt out here; I already pissed Jason off when I refactored Expression, but I think he's The Expert in anything Expression related, so ... you should follow Jason's advice. Of course that means that it will be up to him to accept and submit your code when it finally meets his expectations, but with Great Power comes Great Responsibility.

 

[Theraze]

Heh. Yeah... It's easy to swap if needed later.

Anyways, hopefully this patch is better. Now it actually sets MonsterExpression bits when it loads, and evaluates it below. Also, getEvaluating<item> per type, not one for all.

 

[Darzil]

There HAS to be a distinction between values for normal monsters and scaling monsters - normal monsters' stats get your +ML added to them, scaling monster's stat expressions would already include ML to the extent that it might apply.

Unfortunately, it's not that simple. Some scaling monsters apply +ML over cap, some under cap, and some are only affected by outfit +ML, not Radio (etc) +ML.

 

[StDoodle]

Unfortunately, it's not that simple. Some scaling monsters apply +ML over cap, some under cap, and some are only affected by outfit +ML, not Radio (etc) +ML.

I think that's what jason meant though: since the ML mechanics vary between the different scaling monsters, the expression evaluator should always handle adding in any ML that applies, and +ML should never be added independently, as it is for normal monsters. But the actual expression used for any scaling monster that gets a ML boost would include the relevant ML checks.

 

[Theraze]

That's all handled already by the scaling code, and is irrelevant to the non-scaling monsters...
The real issue is the overhead... that's the part that applies to why non-scaling shouldn't get expressions.

Regarding that, all we'd need to do to add +ML to the non-scaling mobs (which would be the ones that aren't getting expressions currently) would be use the IsNumeric test that it's currently doing to see if it's an expression, and if it's numeric already, pass along the string of "<number>+ML"... so for 150, "[150+ML]" which would do that...
But Jason nixed that with the overhead argument.

 

[jasonharper]

Mostly implemented in r9020.

Anybody know of any spading on the HP of the various Basement monsters vs. the basement level? Wiki only gives their attack/defense, I'm pretty sure they don't all have the same HP.

 

[Theraze]

Here's a monster update patch with some other bits.

Croqueteer got missed when the other scaling monsters were added.
Skeleton invaders initiative.
Pr Imp should have the second letter lowercase. (Current code is PR Imp, unlike KoL itself.)
Bad ASCII Art update to make it work properly.
Your butt has scaling information.
Cubicle scaling information.

 

[Veracity]

Pr Imp should have the second letter lowercase. (Current code is PR Imp, unlike KoL itself.)

I really don't like it when people tell me that something I intentionally submitted "should" be some other way.

Have you noticed that in monsters.txt we Capitalize all sorts of things that KoL itself does not capitalize?

Yes, the capitalization of this monster disagrees with what KoL shows you - like 80% of the other monsters in that file.

Live with it.

 

[Theraze]

Hmm... well, I thought it was accidental, as BL Imp and CH Imp both (in KoL) capitalize the first two, and Pr Imp is the exception. It's difficult for me to actually know which bits are done on purpose and which are accidental though... there's no guidebook to other people's brains and former thought processes to make their intentions easier to read. If my monsters.txt ever ends up with that as the only difference, I'll revert. I'll try to remember not to highlight that as accidental in the future though.

 

[Veracity]

If my monsters.txt ever ends up with that as the only difference, I'll revert. I'll try to remember not to highlight that as accidental in the future though.

Or, you know, you could simply not change it in your monsters.txt at all, since it's not a mistake and it's not ever going to change in the official source; it is a pointless change for the sake of change.