Bug - Not A Bug Maximizer not working properly with "clownosity" and "raveosity"

[slyz]

Here is JasonHarper's commit message explaining bitmap modifiers.

I understand why people are confused that the "scores" aren't shown next to -osity items. Adding them might not be so hard, for someone who understands Modifiers.java and MaximizerFrame.java. I've played around in both, but mainly by copying existing code. I don't think I understand the bitmap modifiers enough to do it though.

That, and I have a baby on the way!

EDIT: as said in the commit message linked above, bitmap modifiers can be converted into a number, but that number would be the total number of sources. To get the score of each individual source out of the existing code might need a lot of rewrite.

 

[Morgoth1145]

It sounds pretty similar to how C flags tend to be dealt with (which was my guess, go me!) I'll definitely have to try to take a look sometime when I have time, that being the case. I had forgotten that multiple copies of items do not increase clownosity/raveosity, so his change to bitmaps definitely makes sense, it greatly simplifies the process.

The multiple copies not increasing clownosity/raveosity is probably what was meant by "it's infeasible to due due to it being a bitmap." (It's a much clearer explanation, too.) I personally disagree, and already have a couple of methods in mind to work around that, but we'll see what I can do some other time. I can't say that my excuse is a baby, though. Congratulations!

P.S. Thanks for the commit message, if only that had come up in my google search on the topic :/. (Then again, I searched for "bitmap modifier", and he probably meant that I needed to search for "bitmap", which I thought was a concept too obvious for him to have meant that I google it.)



Edit: I figured I'd detail *how* the duplicate problem is pretty easy to solve. If the current modifier bitmap is called mods, and the new item's bitmap is called next, then the new modifier bitmap is, as described in the commit notes, mods | next. If the item is already equipped, then obviously mods & next will not be 0. But if it is not equipped, then (~mods) & next will be nonzero. So the addition to the score for each item is equal to the number of set bits in (~mods) & next. This is the number that will appear next to each item. The rest is simple once you have that number, though it can be optimized to account for the modifier score being a bitmap.

 

[roippi]

Here's the issue explained in plainer english.

When you do "maximize moxie", the score that you get back on each piece happens to be the amount of moxie on each piece. That is because you are giving a weight of 1 point to each point of moxie, and 0 points to everything else. This is the same as doing "maximize 1 moxie". If you did "maximize 4 moxie", you would get all of those scores multiplied by 4, since you gave moxie a weight of 4 and everything else a weight of 0.

-osity is inherently different - 5 clownosity is worthless, you only want 4. So when you ask for "maximize 4 clownosity", you are not asking it to multiply the weight of each clownosity piece by 4. You're asking for something else entirely. So -osity functions completely differently from other maximization functions.

There are some hacks to display the base score next to each piece, but these come with other side-effect issues. The "real" solution, if you want to pursue it, is to fill this feature request to add a "hard cap" ability to the maximizer, then -osity can just be a keyword to use that hard cap ability.

 

[fronobulax]

I find the standard meaning of "mazimize" when applied to -osity to border on nonsensical. Having plowed this ground before, I now understand some of the Maximizer's behavior to be binary. Either I can achieve +4 -osity or I cannot. That pretty much explains what the Maximizer is trying to tell me.

I too have wanted a true maximize -osity command because it would tell me information I might use to determine my next adventure location or pull. I also understand that this is a niche case and since the -osity values are static a script could easily tell me what I need to know I do not necessarily support changing the Maximizer. But the Maximizer and -osity are one of the few areas in KoLmafia when RTFM trumps intuition when it comes to understanding.

 

[lostcalpolydude]

5 clownosity is worthless, you only want 4.

The many bug reports about this topic suggest that maybe mafia shouldn't try to be so smart about it. On the other hand, any change is likely to break at least one script out there that handles the current behavior properly.

Raveosity is the one thing where I actually go to the wiki instead of using the maximizer when I want to figure out how to achieve the target value (I just pull and wear the same clownosity gear every time to avoid thinking about it).

 

[roippi]

Well, if we wanted to change behavior somewhat:

Index: src/net/sourceforge/kolmafia/swingui/MaximizerFrame.java
===================================================================
--- src/net/sourceforge/kolmafia/swingui/MaximizerFrame.java    (revision 11336)
+++ src/net/sourceforge/kolmafia/swingui/MaximizerFrame.java    (working copy)
@@ -1902,15 +1902,21 @@
             }
             if ( score < this.totalMin ) this.failed = true;
             if ( score >= this.totalMax ) this.exceeded = true;
-            if ( !this.failed && this.clownosity > 0 &&
-                mods.getBitmap( Modifiers.CLOWNOSITY ) < this.clownosity )
+            if ( !this.failed && this.clownosity > 0 )
             {
-                this.failed = true;
+                int osity = mods.getBitmap( Modifiers.CLOWNOSITY );
+                if ( osity <= this.clownosity )
+                    score = osity;
+                if ( osity < this.clownosity )
+                    this.failed = true;
             }
-            if ( !this.failed && this.raveosity > 0 &&
-                mods.getBitmap( Modifiers.RAVEOSITY ) < this.raveosity )
+            if ( !this.failed && this.raveosity > 0 )
             {
-                this.failed = true;
+                int osity = mods.getBitmap( Modifiers.RAVEOSITY );
+                if ( osity <= this.raveosity )
+                    score = osity;
+                if ( osity < this.raveosity )
+                    this.failed = true;
             }
             if ( !this.failed && this.booleanMask != 0 &&
                 (mods.getRawBitmap( 0 ) & this.booleanMask) != this.booleanValue )

something like that might work as kind of a goofy hybrid.

 

[Theraze]

If you care about your partial count, maximize 4 clownosity. Then maximize 3 clownosity if it fails. And maximize 2 clownosity. And when it fails also, you can try to maximize 1 clownosity. And whenever it works, you know that's what your current possibility is...

 

[xKiv]

Raveosity is the one thing where I actually go to the wiki instead of using the maximizer when I want to figure out how to achieve the target value (I just pull and wear the same clownosity gear every time to avoid thinking about it).

I have:

klown	=> ash foreach it in get_inventory() { int kl = numeric_modifier(it, "clownosity") ; if (kl>0) { print(it + ": " + kl); } } %%

Would probably work just as well with "raveosity". Escpecially considering that you can't really control which raveosity items you get, except free runways from foes who only have things you don't want. (no pulls, no olfaction, ... ... except rave whistle, of course)

 

[roippi]

Kay.. if nobody wants to try my code, I can provide pictures:

Old "fail"


Patched "fail"


Old "success"


Patched "success"


Like I said, it's a goofy hybrid if you're familiar with how the maximizer works for literally everything else. Also, it's a fundamental change in behavior, in that it will suggest partials. Which I'm not necessarily a huge fan of.

 

[Bale]

It might be incosistent, but that looks nice. It is exactly how people say they want the maximizer to act in those cases despite the inconsistency. Even I would find it more useful .

 

[lostcalpolydude]

That looks nice.

 

[Darzil]

Definitely nice, and would mean less looking up the wiki.