Bug - Fixed Maximizer tiebreaker used when -tie is given

Theraze

Active member
A quote displaying what I mean:
> outfit birthday suit

Taking off everything...
Everything removed.

> maximize adventures, -tie

Maximizing...
12 combinations checked, best score 0.0
Putting on Hollandaise helmet...
Equipment changed.
Wielding Shagadelic Disco Banjo...
Equipment changed.
Putting on old sweatpants...
Equipment changed.
Putting on clown shoes...
Equipment changed.
I told it to just maximize based on adventures, and not to use the tiebreaker... but even though it ends with a total score of 0, it still equipped things.

I'm not sure if this is best noted as above, or with the heading: Maximizer prefers negative gains to empty slots.
I noted to myself earlier that the maximizer will equip items counter to your request to fill slots. After going from a BM Pastamancer to HC ascension, it will equip a brimstone brooch when a maximize moxie is requested, despite bringing the total score to a negative, until you've collected at least 3 accessories. As soon as you have 3 other accessories, it will stop using the negative/no-gain item, but until then...

Proposed solution:
1) -tie shouldn't use the tiebreaker, ever. Even if slots remain blank.
2) Slots should prefer being empty over a negative result.

Reasoning:
1) We've turned off the tiebreaker. It shouldn't come on when we tell it not to. Should be easy to fix.
2) If you're trying to maximize initiative and it keeps equipping tap shoes, that's not helpful. If you're trying to maximize moxie and it keeps equipping a brimstone brooch, that doesn't help either. Preferring negative-gains over empty slots reduces the chances that your maximized gear will actually be the way you want it to be.

Caveat: When 1 and 2 interact... if the tiebreaker is off, and no gear is good in a slot, that doesn't mean to unequip it and go with nothing... just to leave it alone. If the slot is empty, leave it empty. If the slot has gear, leave that gear. Basically, if $slot[item] doesn't have a replacement, and the tiebreaker is turned off, skip changing the slot.
 
Yes... my expectation was that simply stripping off gear, then running a simple maximize adventures, -tie should equip only +adventure gear, nothing else. Current behaviour doesn't support this. The second noting, regarding that gear providing a negative score being preferred over leaving the space blank, may deserve its own bug report or not... wasn't certain. I'll make it a new report if it should be.
 
feels the complaint is completely pointless
I can't see why anyone would feel this way.

Even if it doesn't equate to a negative effect, when I use "-tie" and see (0) next to results (I usually use the visual maximizer over the CLI) it really bothers me. No tie means no tie, and seeing (0)s is equivalent to my request being ignored.

However, in regards to the Caveat:
Theraze said:
Reasoning:
1) We've turned off the tiebreaker. It shouldn't come on when we tell it not to. Should be easy to fix.
2) If you're trying to maximize initiative and it keeps equipping tap shoes, that's not helpful. If you're trying to maximize moxie and it keeps equipping a brimstone brooch, that doesn't help either. Preferring negative-gains over empty slots reduces the chances that your maximized gear will actually be the way you want it to be.

Caveat: When 1 and 2 interact... if the tiebreaker is off, and no gear is good in a slot, that doesn't mean to unequip it and go with nothing... just to leave it alone. If the slot is empty, leave it empty. If the slot has gear, leave that gear. Basically, if $slot[item] doesn't have a replacement, and the tiebreaker is turned off, skip changing the slot.
I agree mostly, but with one addition. If $slot[item] doesn't have a replacement, but equipping nothing would improve the score, then do just that.
 
Valid. If you currently have the brimstone brooch attached, and run maximize moxie, -tie... it should remove the equipment.

I think a way to describe it would be:
Code:
if ($item[newitem] <= $slot[item]) continue;
Code:
if ($item[none] > $item[best]) remove $slot[item];
Basically, if the item doesn't count as better (whether through actual maximizer or tiebreaker), move on. After the whole series of checks finishes (outside the for-loop for the item check, but before it moves on to the next slot), if having nothing is better than the current 'best' item, empty the slot.
 
Tackling this one now. One of my personal bugaboos is that the maximizer will try put stuff on my equipment-less familiar when I specify -tie. Familiar is just another slot (like pants or hat), so same issue reported here.

My current solution is to consider (none) if and only if there is currently nothing in that slot.

Code:
			// if we currently have nothing equipped, consider leaving nothing equipped
			if ( EquipmentManager.getEquipment( Evaluator.toUseSlot( slot ) ) == EquipmentRequest.UNEQUIP )
			{
				ranked[ slot ].add( new CheckedItem( 0, equipLevel, maxPrice, priceLevel ) );
			}

It works but I need to think if I like the way I implemented it.
 
Does this now meet bordemstirs post 4 point of removing gear to improve a slot, or not? Do we care?

The example I gave in post 5 to clarify this was if, for some reason, you only have the brimstone brooch and no other accessories. Say you're doing something weird with your closet or who knows what. But your brooch is equipped, you maximize moxie, -tie... there's something in the slot, but it makes things worse. Do we consider empty as an improvement? I believe Jason may have fixed it to consider it as an improvement if you aren't doing -tie, but... if it only allows that during tiebreaker...
 
I don't think we ever consider removing equipment as an option, outside of shields and the like. Maybe some mutex cases.

(I don't know that we really care. You have to jump through some pretty big hoops to get into such a situation.)
 
Last edited:
Well, the second part of the initial request was to prefer empty slots over a negative result. Whether or not the slot starts empty.

Want a new FReq for that, or do we just keep this one open for now?
 
Actually, I was wrong, maximizer will unequip stuff if there's nothing that will give you a positive score.

Code:
> ash maximize( "init", 0,0,true,true)[5];

Maximizing...
800 combinations checked, best score 260.00
Returned: record {string display; string command; float score; effect effect; item item; skill skill;}
display => unequip pants
command => unequip pants
score => 30.0
effect => none
item => buoybottoms
skill => none

So that part's already implemented.

double edit: actually.. my code isn't too ugly. I liked it, then I didn't like it, now I kind of like it again. Heh.

triple edit: I think I could have always considered (none) instead of just when the slot is empty. MaximizerSpeculation.compareTo() seems to already know how to handle it being thrown in there just fine. Huh.
 
Last edited:
Well, if it works even if the code's ugly, then it's implemented on both parts of the original FReq and more useful than the original change-report suggested. Thanks! :)
 
When I try to maximize with creatable/foldable or pullable/buyable selected, I get this debug log.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
KoLmafia v15.9 r12075, Windows 7, Java 1.7.0_21
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Please note: do not post this log in the KoLmafia thread. If you
would like the dev team to look at it, please write a bug report
at kolmafia.us. Include specific information about what you were
doing when you made this and include the log as an attachment.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Timestamp: Tue May 07 10:26:54 PDT 2013
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Unexpected error, debug log printed.
class java.lang.NullPointerException: null
java.lang.NullPointerException
at net.sourceforge.kolmafia.maximizer.CheckedItem.<init>(CheckedItem.java:70)
at net.sourceforge.kolmafia.maximizer.Evaluator.enumerateEquipment(Evaluator.java:1119)
at net.sourceforge.kolmafia.maximizer.Maximizer.maximize(Maximizer.java:161)
at net.sourceforge.kolmafia.swingui.MaximizerFrame.maximize(MaximizerFrame.java:287)
at net.sourceforge.kolmafia.swingui.MaximizerFrame$MaximizerPanel.actionConfirmed(MaximizerFrame.java:332)
at net.sourceforge.kolmafia.swingui.panel.GenericPanel$ConfirmedListener.execute(GenericPanel.java:627)
at net.sourceforge.kolmafia.swingui.listener.ThreadedListener.run(ThreadedListener.java:239)
at net.sourceforge.kolmafia.RequestThread$ThreadWrappedRunnable.run(RequestThread.java:342)

CheckedItem has
Concoction c = ConcoctionPool.get( itemId );
which is null for item 0. That radio button must control equipLevel, so with the default value of "on hand" the return statement in CheckedItem avoids that issue.

I think adding a check for itemId == 0 for that return statement might do, but I haven't looked closely enough yet.
 
Last edited:
Back
Top