Feature Add keyword to limit a modifier in maximizer

Alium

New member
I would like to limit how much monster level the maximizer will allow to avoid making fights too hard. This will also help when wanting a specific monster from oil peak for Grey You absorption.

Currently the max keyword is a soft cap. Request is for a hard cap. I suppose this new keyword should behave similarly to min where if unable to get a ML below the limit, abort? I'm open to ideas on this for sure.

I did look at older posts to find a similar request, but very well could have missed one. Closest I found was a similar conversation here.
 
a hard cap assumes the maximizer is able to reject combinations the same way it can exclude specific equipment when making combinations, can it do that?

new keyword should behave similarly to min where if unable to get a ML below the limit, abort?
1, when the maximizer fails to achieve requested min value doesn't it still return the best combination it found? if ML is treated like a binary hard cap can it still judge which is the least bad combination?
2, then failure would only be a meaningful return in few cases, because if the maximizer can reject combinations above the limit all it has to do is not equip, so if there is failure it would just mean that ML already exceeds the limit without equipment and can't be reduced with equipment,
failure return would only be meaningful when trying to find ML reducing equipment, or when also requesting a min value for another modifier for which equipment happens to be tied to ML. like if you were requesting a ML cap < 50 together with minimum muscle that could only be achieved by equipping [shield of the Skeleton Lord].


If excluding combinations is not possible perhaps what is needed is a way to put a weight on how badly you don't want the value to exceed the cap, something like "10ml 40max 1000cap50" that would increase score for ML up to 40 then decrease by 1000 for every point above 50
 

xKiv

Active member
a hard cap assumes the maximizer is able to reject combinations the same way it can exclude specific equipment when making combinations, can it do that?

AFIUI, excluding equipment is an optimization the maximizer knows it can do, because it knows something with strictly higher numbers (after weighting) is always at least as good (as long as the lower-numbered equipment is not part of any synergy). If you implement hard caps (on either total score, or on specific modifiers), you are adding constraints that break this assumption. I suspect you will have to regress to "just check absolutely all combinations", which will be fundamentally slower. Possibly so much slower that you won't want to wait for the result (depending on the size of your inventory). Significantly increasing several numbers doesn't look so bad until you get to the point where you are multiplying them all together.
If you don't do that, you might not be able to find any low-enough-scored combination that exist, because those might only be possible with non-excluded equipment.
 

Alium

New member
Interesting, hadn't thought of the internals of the maximizer before. Perhaps a compromise would be to make the cap / limit keyword only valid for ML as that is the primary use case. A relatively small percentage of gear effects ML. Then exclude gear as it is now, but keep gear that effects ML.

No doubt there will be less gear excluded. Maybe brings this back into a reasonable time to compute?
 
something with strictly higher numbers (after weighting) is always at least as good (as long as the lower-numbered equipment is not part of any synergy). If you implement hard caps (on either total score, or on specific modifiers), you are adding constraints that break this assumption. I suspect you will have to regress to "just check absolutely all combinations", which will be fundamentally slower.
Isn't this slower maximizing already what happens when using the "max" soft cap then? to give no more value over max of a modifier when several modifiers are requested still involves getting the total value of every combination
 

xKiv

Active member
Isn't this slower maximizing already what happens when using the "max" soft cap then? to give no more value over max of a modifier when several modifiers are requested still involves getting the total value of every combination

AFAIK, that's not what "max" does. When you add "max" to a score component, it simply does not count any score higher than that.

From maximizer-help.html:

max - The weight specifies the largest useful value for the preceding modifier. Larger values will be ignored in the score calculation, allowing other specified modifiers to be boosted instead.
Note that the limit keywords won't quite work as expected for a modifier that you're trying to minimize.
If min or max is specified at the start of the expression, it applies to the total score (the sum of each modifier value times its weight). A global max may allow equipment maximization to finish faster,

But, the only uses I see in the code for non-global max are really just capping that particular component's contribution. Nothing that would affect gear shortlisting.
 
AFAIK, that's not what "max" does. When you add "max" to a score component, it simply does not count any score higher than that.
I see now I was confused by special interactions, like smithsness or watches when combining accessories, and 2handed weapons,
they seem to have their score calculated later when the global score already includes the modifiers of other slots that the maximizer managed to set independently, that can give the impression that the maximizer looks for optimal combinations when there is a max, but it doesn't,

so even that suggestion to apply negative weight above a global max gives the same problem compared to current performance

Interesting, hadn't thought of the internals of the maximizer before. Perhaps a compromise would be to make the cap / limit keyword only valid for ML as that is the primary use case. A relatively small percentage of gear effects ML. Then exclude gear as it is now, but keep gear that effects ML.

No doubt there will be less gear excluded. Maybe brings this back into a reasonable time to compute?
Gear that affects every other requested modifier would still have to be considered in combinations. I think at best the improvement of limiting focus to ML would be if it's a special operation to correct limited slots after the best combination is determined normally? it would not be optimal but neither is "max"
 

SketchySolid

New member
Chaining together min and max limiters doesn't appear to work as expected (e.g. -10 ml 50 min 50 max provides maximizer scores near 0 instead of -500, and does not suggest gear with ML in the expected range). The best workaround solution I've found so far is to include a negative value with a minimum (i.e. -10 ml 50 min), which is already permitted, and has the same potential problems identified above.
 

heeheehee

Developer
Staff member
min/max interact poorly with negative weights.

To elaborate on xKiv's comment about not considering all equipment, we only consider:
- required items (e.g. via +equip)
- the best items for any given slot (up to the amount you can equip, minus slots taken up by required items)
- items are may not be best-in-slot alone but could be in conjunction with others (e.g. outfits or synergies)
- potentially current equipment depending on whether +current is active
- some other misc categories that are considered separately due to equipment constraints, such as watches

As such, if you try to maximize -ml 50 min, we very likely don't consider any equipment with positive ML contribution (notable exception: synergies, like brimstone or cloathing).

Further, if you specify "ml 50 max", we will only consider the best items for ML, even if we don't consider those items to be useful past that point. We might not pick those items if you have other items that contribute to synergies that also satisfy the min requirement.
 

xKiv

Active member
As such, if you try to maximize -ml 50 min, we very likely don't consider any equipment with positive ML contribution

I *did* see a line that basically says "if this item would have a negative score all by itself, skip it". Somewhere among the other rules (definitely after considering synergies).
 

heeheehee

Developer
Staff member
Yeah. I also saw
Java:
        double delta = this.getScore(mods, new AdventureResult[] {item}) - nullScore;
        if (delta < 0.0) continue;
in Evaluator.java, but even commenting out that second line, it didn't change anything, because it was worse than the alternatives.

(I believe that workaround was so we would stop recommending scuba gear in the back slot, or bathysphere for familiars.)
 
Top