Feature - Implemented Adjust last_monster().physical_resistance for +ML

P

PaladinWhite

Member
last_monster() returns a monster whose stats are, in most cases, adjusted for +ML. There are "raw" and "base" values for HP, attack, defense, and initiative. But physical_resistance isn't adjusted.

I propose that the physical_resistance field should be adjusted on-the-fly, OR the existing physical_resistance field should be renamed raw_physical_resistance, and a new (adjusted) base_physical_resistance field should be added. (Why are these things called "raw" and "base," anyway? I always have to compare the values to tell which one is adjusted and which isn't. But that's another discussion.)

Monsters gain physical and elemental damage resistance equal to ML*0.4%, capped at 50%.
 
H

heeheehee

Developer
Staff member
If I remember correctly, this number is rounded down to the nearest percent. If the old value is 0, then resist is this ml-based value; otherwise, resist is the greater of innate resist and ml-based resist.
 
P

PaladinWhite

Member
> ash monster_level_adjustment()

Returned: 118

> ash last_monster().physical_resistance

Returned: 0

That ought to be 47.2, or 47 if it's rounded. So if that's how it's meant to work, something's going wrong.
 
lostcalpolydude

lostcalpolydude

Developer
Staff member
heeheehee is describing how KoL handles it, covering an important detail for implementation that wasn't covered in your first post.
 
H

heeheehee

Developer
Staff member
Consider the booty crab, which has 25% physical resistance. If you have less than 63 ML, then it'll have 25% physical resistance. Any more, and the ML-based resistance will take over.

Also, negative ML doesn't do anything to scaling monsters. That may make the implementation a bit hairier than it ought to be.
 
D

Darzil

Developer
heeheehee said:
Also, negative ML doesn't do anything to scaling monsters. That may make the implementation a bit hairier than it ought to be.
Click to expand...
That is already handed in the code, for stats, anyway.

Are you meaning that with -ML you get physical vulnerability, but not for scaling monsters.
 
D

Darzil

Developer
Probably main thing to look out for is how MLMult and number of B's comes in, but the complexity that is monster stats code should be reasonably understandable, and this should be simpler than the stats.
 
H

heeheehee

Developer
Staff member
Hm. I just cast lightning bolt at -30 ML, and some strange rounding artifact meant that it dealt 3361 damage, as opposed to the expected 3000. -20 ML worked as expected. -28 ML also counted as -12%, so that's confirmation that it's floored, as opposed to cast to an int.

I also have a perhaps outdated view of the code from one of the twitchleaks.
 
H

heeheehee

Developer
Staff member
Darzil: mlMult increases ML from the point of view of these calculations --- I distinctly remember clan of cave bars getting stagger immune in Ed, when nothing else would. I'm not sure about Bs, but I would assume that doesn't actually affect ML for the sake of ML.

I'm doing some minor refactoring of MonsterData at this time.
 
H

heeheehee

Developer
Staff member
Hm. Well, it looks like I have MonsterData working as expected, but AreaCombatData double-counts ML for the purposes of "Combat XP" (averageExperience). I'll leave that commit for later, but I'm thinking I might want to make the ML accessor public.
 
D

Darzil

Developer
heeheehee said:
Hm. Well, it looks like I have MonsterData working as expected, but AreaCombatData double-counts ML for the purposes of "Combat XP" (averageExperience). I'll leave that commit for later, but I'm thinking I might want to make the ML accessor public.
Click to expand...

There may be something odd happening here. mutant cookie-baking elf is listed as Scale: 6, but gave all the stats when I encountered it at 13, my ML level at the time. I see in Area combat data for Atomic Crimbo Toy Factory the same thing. Of course it corrected for the second fight, as I have Manuel. Not looked at the code, but I'm guessing if cap isn't set (or maybe floor), it is getting stats set to 0. Monsters with Cap and Floor defined show correct scaling stats.
 
Last edited:
H

heeheehee

Developer
Staff member
Looking at the code, it *seems* like this was fundamentally flawed when it was first implemented, as the default value for cap (if nonexistent) was 0. r16143.
 
H

heeheehee

Developer
Staff member
Although, I do have a question. In the first twitch event, we saw that the default scaling cap is 10,000 --- Jick didn't specify one, but monsters were clearly capped. Should we instead use this default, which should catch all old previously-uncapped monsters?
 
Veracity

Veracity

Developer
Staff member
If that is KoL's default, it should be our default, too - and that would also mean we could remove that cap from monsters that have it and only specify it for non-default monsters.

Although, how do you specify monsters which have no scaling cap (if there is such a thing)?
 
H

heeheehee

Developer
Staff member
There is such a thing --- several monsters, including Dreadsylvanian werewolves, are truly uncapped (possibly hardcoded?); however, experience gains from said monsters are capped. However, we do not handle this at this time. I'm not sure how we would want to.
 
D

Darzil

Developer
How I think we should handle things is to have a standard scaling formula for normal scaling monsters, and hard code anything else in monsters.txt. You are right, Heeheehee, looks like it was broken for a while.

So many scaling monsters do have a cap, and some are uncapped, so it may be best to handle them as we do now. It is fairly unusual now for monsters to actually have a 10k cap.
 
Last edited:
You must log in or register to reply here.
Top