How to fix maximize doing weird stuff

Why is it that maximize sometimes fills my equip slots with stuff that doesn't effect what I am maximizing?
Maximize meat equips wings of fire, i would rather it not alter my equipment if the replacement doesn't contribute to the goal... how do i set it up for that? Or at least give it a different default, I would rather have my back pack equiped before wings of fire.

-tie

I'm curious how many people find this default behavior of MM helpful. I personally find it to be a nuisance, especially in regards to familiar equipment and the back slot. I generally find myself going through scripts I download and adding -tie to most maximize commands.

You mean that you'd rather have an empty slot than one filled by the tiebreaker? I can see if you perform several Maximizer calls in a row that the tiebreaker may be unhelpful, but other than that I've never found it to do anything unhelpful.

It's not an empty slot issue, I'd rather not have it touch what's already there. On equipment being brought in that's not relevant to the maximized attribute, it doesn't take into account other enchantments on the equipment that might be unhelpful (I think?), so you might be getting +damage when you don't want it, or it might take off your brimstone beret and lose your 4th AT song, even when the head slot isn't actually being used for the maximized attribute. The most common issue is with familiar equipment. There's not much relevant familiar equipment tied to most maximize commands outside +items and +meat (unless you've got a disembodied hand or pantsrack). It will regularly put on pumpkin buckets, a snow suit, and other Mr. store equipment when it isn't desirable, because it doesn't know any better. Outside of +meat, +items, hand, and pantsrack use, whether you'll want to use a snow suit, LL helicopter, or other familiar equipment is so context sensitive that it shouldn't be touched by default with anything but +meat, +items, and when you've got a pantsrack or hand out. That's my experience, at least.

I'd like to point you to this bug report in which somebody was unhappy because, at it turns out, he was using lost's builds which were automatically inserting -tie into maximizer strings by default and he was getting results he didn't expect or want.

Some people like -tie. Some people don't. We choose a default behavior and let people override it if they like the other behavior better.

I am extremely surprised to hear that the maximizer is losing your 4th AT song, considering that I believe it has hardcoded behavior to avoid doing that. Or, perhaps that is equipment swapping for buff casting. Whatever. I remain surprised.

My experience is that if you want a more complicated maximize... you make it. If that means you want -tie, you set it. If you want to protect your 4th AT song, you put that into the maximizer string. If you don't want it to touch your weapon, you add -weapon. If you want an outfit, add the outfit.

Nothing limits you to a single maximization goal. Unless you're trying to reach a requirement, in which case the maximizer might fail your otherwise excellent string. But otherwise, telling the maximizer explicitly what you want it to consider as important means that the whole +-tie becomes fairly irrelevant...

Idea: would rearragning MaximizerSpeculation.compareTo so that simplicity is compared before tiebreaker help? Would it break anything?
- as long as the non-tiebreaker score would be the same, keeping a thing equipped would be preffered to increasing just tiebreaker score
- putting something with score 0 but high tiebreaker would still be prefferable to empty slot
- tiebreaker would still be in full effect when comparing items that improve score (compared to what's in the slot now)

I am probably missing half of the relevant maximizer code though, so the above might be completely wrong.

---

Actually, after reading the referenced thread, it's obvious that my first point is exactly what shouldn't happen.
And since maximizer is used from scripts (which might expect current tiebreaker behavior and rely on it), any changes (especially any associated preferences) would have to only take effect when not run from scripts, which is bad behavior.

Yeah, agreed with your second point. If you don't want the tiebreaker, turn it off.

Or use a version with that set as the default. But the current behaviour is good for 'normal' default.