Bug - Fixed Irregular +/- combat rate modifiers interact poorly with the soft cap

phreddrickk

phreddrickk

Member
Just as a note first, I unfortunately don't know exactly how these modifiers interact with the soft cap in the real world.

But,
unknown.png

A user with this modtrace is getting a 1-turn CS -combat test rather than a 3-turn one. I've looked at (most) other possibilities, and it feels like the most likely scenario is that their softcapped combat rate should be -40, because of the way Disgeist stacks with Blessing of the Bird.

That being said, I'm not sure how this would count for things other than CS. Would someone running -20 from regular sources and a -7 combat source get -25.4% combat? Would they just get -25%, but be a little closer to hitting -26%? The world may never know!

This is normally a pretty negligible effect. It seems to me the easiest way to "fix" this would be to expose the unsoftcapped -combat rate to scripts and to users. And while we're there, we can apply the recently-ish-added hardcap to combat rate modifiers.

If we make it another numeric modifier, that would have the kind-of-funny effect of behaving identically to the current modifier when analyzing individual items/familiars/etc, but behaving very differently when used more generally. It could also be exposed as an ash function, but that feels mostly inconsistent with current behavior. There are functions for meat drop, item drop, and familiar weight modifiers, though, and I'm not sure whether those just predate the modifier system or if they have another valuable niche.
 
From Modifiers.java, line 1689
> Assume that all the sources of Combat Rate modifiers are of + or - 5%,

Well, blast.

I note that line 1471's "get" function has a special case for prismatic damage. I think the best move here is to use "COMBAT_RATE" as the uncapped combat rate, and add in an extra special case in the "get"s to soft cap it (and hard cap it -- what's the hard cap?).

This will fix things like maximizer that wouldn't be fixed by the "new function for scripts" route.
 
r26352.

I omitted the hard cap because apparently CS wants the raw value? Not sure where else (outside shenanigans) you'd have values that high. Maximization I imagine is going to be for CS, so it wants the uncapped value.

Would also be nice to know whether fractional percentages count as-is / are floored / are rounded, but I doubt that's spadeable.
 
Ryo_Sangnoir said:
Would also be nice to know whether fractional percentages count as-is / are floored / are rounded, but I doubt that's spadeable.
Click to expand...
Push a zone to 0.x% noncombat rate (e.g. haunted bathroom + 29.4% or 29.6% combat). and see 1) if you encounter any of the low probability event in question, and 2) spend enough adventures to differentiate between, say, 1% vs 0.6%.

That will differentiate between round(), floor(), and ceil().

It will take a lot of adventures, but it is possible.
 
Thanks for the quick fix. I'm the user with the posted modtrace and was able to run CS scripts without any problem and the same loadout.
 
Code: 
> ash numeric_modifier("combat rate")

Returned: -45.0

> ash numeric_modifier("Combat Rate")

Returned: -29.0
Just to be clear this isn't unique to JavaScript.
 
You must log in or register to reply here.
Back
Top