Feature Maximizer: Consider owned items with worse tiebreakers + acquirable items with better tiebreakers, both

[Big Money Sylvia]

(Edit -- For context, this was initially filed as a bug labelled "Maximizer prefers making troutsers over wearing lava-proof pants.")

Title is specific because I feel like the issue is hard to explain in concise words.

When you're maximizing a stat, KoLmafia will suggest spending a limited resource to get an item with X in that stat - like 5 for hot res with troutsers - over an item that's in inventory, shares the maximizer score of X, but has (separate) stat penalties (that are only relevant to the tiebreaker).
For some use cases (community service) this is actively bad, although I can see it making sense for combat.

This is a bit subjective, but I feel like this behavior should be tweaked.

 

[fronobulax]

Title is specific because I feel like the issue is hard to explain in concise words.

When you're maximizing a stat, KoLmafia will suggest spending a limited resource to get an item with X in that stat - like 5 for hot res with troutsers - over an item that's in inventory, shares the maximizer score of X, but has (separate) stat penalties (that are only relevant to the tiebreaker).
For some use cases (community service) this is actively bad, although I can see it making sense for combat.

This is a bit subjective, but I feel like this behavior should be tweaked.

I'm not quite sure I understand the problem. If two items have the same score then the tiebreaker is used to pick one. Your issue seems to be that you don't want the tiebreaker to break the tie. It should be possible to tweak that with the specific maximizer command to get results more to your liking. In the GUI you can specify that only items on hand will be considered which may also address your concern. If the GUI allows modifiers that the command line or script doesn't then perhaps there is a feature request to expose those options in a better manner?

 

[Big Money Sylvia]

You're right, looking at it this way, it's not a "bug" relative to the specifications of KoLmafia.

Having opportunity cost as a tiebreaker would make more sense to me, but learning about creatable items with better tiebreaker scores is still desirable.

When I'm maximizing, I would often like to know two things at once.

• "Can I make/buy a better item that matches the bonus of what I have?" This one is more interesting in aftercore (item/meat gear, advs/fites gear, etc), but also neat to know in-run (because combat is nontrivial depending on path/perms/IotMs).
• "Can I match the (non-tiebreaker) score of potential creations with something I already have?" Whenever this happens in-run, I would like to know about it. This also has aftercore use cases: Consider the choice between buying an expensive item with +3 adv, and equipping an inventory item with +3 adv -90% allstats.

I think this could be best done with the or syntax established for cases like (evil) ointment of the occult, hamethyst juice etc:

make & equip troutsers (+5)
...or equip lava-proof pants (+5)

I'm sorry for posting this as a bug. Thread flair is edited, but mods feel free to move this to the proper board.

 

[fronobulax]

No problem about calling this a Bug.

I answer both questions using the GUI. I move the Equipment radio button from "on hand" to "creatable" to see if I can make anything better. I move to "pullable/buyable" to see whether I can buy something. That last usually leads me to set a "Max price:" and select "buyable only" instead of "don't check". If I see results that are not what I wanted or hoped for then I tweak the maximizer string.

So I still cannot tell whether your concerns can be addressed by exploring the existing maximizer options or adding a new one.

A standard format for reports is:

• What did you do?
• What happened?
• What did you expect to happen?

Maybe some specifics will lead to insight?

 

[MCroft]

So, would a tiebreaker option of "- some score points for 'not on hand'" help?

 

[Big Money Sylvia]

No problem about calling this a Bug.

I answer both questions using the GUI. I move the Equipment radio button from "on hand" to "creatable" to see if I can make anything better. I move to "pullable/buyable" to see whether I can buy something. That last usually leads me to set a "Max price:" and select "buyable only" instead of "don't check". If I see results that are not what I wanted or hoped for then I tweak the maximizer string.

So I still cannot tell whether your concerns can be addressed by exploring the existing maximizer options or adding a new one.

A standard format for reports is:

• What did you do?
• What happened?
• What did you expect to happen?

Maybe some specifics will lead to insight?

What I did:
Maximizer string: hot res (radio option: creatable)
What I expected (at the time):
pants slot -- equip lava-proof pants (+5)
What I got:
pants slot -- create & equip troutsers (+5)

This information is already available by clicking through maximizer settings.

This is a QoL feature request. I want to be able to see both when the maximizer score is tied (and maybe even when it isn't).

I think adding the "or" clause described in my previous post would be super helpful, because when I use the "creatable" tab, it'd be super nice to know whether that item creation would be a real upgrade over the best inventory item, or redundant. (Especially because an item with better tiebreakers can be either, depending on circumstance.)

 

[fronobulax]

OK. I sort of understand and see this as a Feature Request. I'm going to let @MCroft ponder since I think they implemented the radio buttons and thus they know more about the maximizer than I do. I'll ponder too but I currently live in a world where everything is a distraction and nothing gets finished when it should have been

 

[MCroft]

So we already have some of this kind of information available using the dump command, but it goes to the CLI.

I have two ideas (which might be complementary and) that might be useful here.

1. if keyword dump (or 2 dump?) included in the GUI, show the shortlist as an ...or list.
   possibly make this a checkbox instead of an expression.
2. since using the dump expression puts the results in the gCLI, allow the item to be selected in the gCLI and have a context action to equip it. That's definitely a more ambitious project, but one I've done some proof of concept work on. It would take a lot longer.