Bug - Fixed maximizer still sometimes equipping bathysphere

taltamir

Member
http://kol.coldfront.net/thekolwiki/index.php/Little_bitty_bathysphere
unlockeding the sea automatically puts the little bitty bathysphere in your inventory as a quest item.
The bathysphere gives you a -20 familiar weight debuff while equipped, and allows your familiar to go into the sea.

not too long ago there was a fix to maximizer so that it will not prefer bathysphere (and its -20 malus) to having nothing equipped on the familiar.
However, this fix seems to have missed the -tie function resulting in current implementation being inconsistent.

If I optimize (in run with bathysphere being my only familiar equip) using the cli command:
maximize meat
maximize adv
then bathysphere will not be equipped.

However, if I instead optimize using the cli commands:
maximize -tie,meat
maximize -tie,adv
then bathysphere will be equipped.

meaning that the current implementation is inconsistent. Although worth noting that familiars that specifically directly affect the maximizer string do not get bathysphere even with tie.
That is, leprechaun will not suggest bathysphere on maximize -tie,meat
Fairy will not suggest bathysphere on maximize -tie,item

It is only when your familiar is not directly contributing to the maximized effect that maximizer -tie decides to cripple your familiar with a bathysphere. (ex, maximizing meat while a fairy is equipped)
Also worth noting I am only using cli command as an example, the same happens if a script calls the maximizer function properly (aka, via the proper ash function and not via a CLI command). This makes this a problem for any script that uses maximize.
I think that the -tie version also be made to exclude bathysphere the same way that it is currently excluded from the non -tie strings. I am pretty sure it was a mistake that -tie was excluded when this was patched out in the past.
 
Last edited by a moderator:

Darzil

Developer
-tie says "I don't care what items are equipped if they don't change the maximizer result."

So if you care, don't use -tie.
 

taltamir

Member
-tie says "I don't care what items are equipped if they don't change the maximizer result."

So if you care, don't use -tie.
Since you put equipment in a slot for a reason, you use -tie because you actually do care and you want maximizer to only change items that directly benefit what is being maximized and not randomly shuffle all your items to what it thinks is best.

For example, if you are maximizing meat, in run you likely do not have a weapon slot with +meat. So literally all weapons in your inventory are tied at 0. maximizer would thus replace your weapon via the tiebreaker functionality to what it thinks is the best weapon you have (which is generally wrong). So a lot of scripts use -tie for all their maximizer calls because they do care to avoid maximizer making random equipment shuffling to slots that are not relevant. And a lot of people use -tie because they do not want to have to manually start changing each slot that is at 0 maximizer score to what they have had preferred before (and they can't just call on an outfit or that will undo the entire maximizer call). -tie is not because you don't care, its because you don't trust the tiebreaker function.

So when using -tie, maximizer will leave all your items alone if the best in slot has a maximizer score of 0. The exception being if you have an empty slot, in which case it will still put something that empty slot, even if it is a harmful thing
 
Last edited:

Darzil

Developer
If you don't want an item removed from a slot, use -slot. eg, you put on the weapon you want then use "-weapon" in the maximization. Or say you always want your accordion thief to use an accordion, you use +accordion.

-tie is explicitly for saying you aren't going to use a tiebreaker.
 

taltamir

Member
If you don't want an item removed from a slot, use -slot. eg, you put on the weapon you want then use "-weapon" in the maximization. Or say you always want your accordion thief to use an accordion, you use +accordion.

-tie is explicitly for saying you aren't going to use a tiebreaker.
the problem is that those exclude the slot even if it has a positive maximizer value in it
-tie is disabling the tiebreaker function. The tiebreaker function automatically tries to replace all your equipment with "generally beneficial" equipment for every slot in which there is a tie.
If you don't care then it wouldn't matter to you either way. People type -tie, exactly because they do care.

Reasons to disable tiebreaker function:
1. you disagree about what is the best piece of equipment for that slot. You don't want it to change parts of your optimized outfit which are not directly beneficial. For example if you are maximizing +meat for the nuns, you are willing to allow it to change your weapon or shirt if it has a bonus to meat, but if none exists it is better it won't make changes at all. (for example, maybe your shirt is the +2 rustproof dragonmail that gives MP regen, if there is something that gives a +meat bonus you want it swapped to save turns, but if not you want to keep your +MP equipment... you could start crafting an overly complex command, but each slot has different reasons why it is there, some are +MP regen, some +item, or whatever other reason it is there)

2. you are trying to minimize server hits. Those add significant slowdown and overhead to a script, even when playing manually it can be quite slow to swap item back if they are unnecessarily changed. Each item being swapped adds one more server hit, and to a script this adds up to a lot of server hits. This is why most turn spending scripts I came across all use -tie.

When a script uses -tie, it means that only slots which are empty or slots which have a positive maximizer score are altered, the rest are left alone and save server hits and time.
Also, when the script runs "+meat, -tie" for the nuns, it has no idea if there is or is not a weapon (or shirt, or pants) that gives +meat before it runs the maximizer. So it cannot exclude a slot carelessly.

Anyways, when a script calls -tie will will still trigger the filling of empty slots even if it leaves filled slots alone. Even if it is filling the empty slot with harmful equipment. So your script has two options:
A. not use -tie, this is an even worse option as it significantly increases server hits and slowdowns as every single piece of equipment is swapped out.
B. use -tie, but then do additional server hits to unequip bad items one by one after the fact.
You could try to dynamically append -equip [known undesireable items] to all maximizer strings. However with massive amounts of maximizer calls it very is easy for some to slip through, so you still need the unequip functionality to strip bad items.

Actually, now that I think about it, an even better solution would be to have a threshold option. Where maximizer leaves slots alone if their bonus is lower than a specified threashold.
So for example you could "maximize mox, 2 mys, slotmin 10". Where any individual slot where the value is under 10 will be left alone to reduce superflous server hits.
 
Last edited:

heeheehee

Developer
Staff member
1. Why are you unlocking the sea in-run? I can't see any in-run relevance.

Reasons to disable tiebreaker function:
1. you disagree about what is the best piece of equipment for that slot. You don't want it to change parts of your optimized outfit which are not directly beneficial. For example if you are maximizing +meat for the nuns, you are willing to allow it to change your weapon or shirt if it has a bonus to meat, but if none exists it is better it won't make changes at all. (for example, maybe your shirt is the +2 rustproof dragonmail that gives MP regen, if there is something that gives a +meat bonus you want it swapped to save turns, but if not you want to keep your +MP equipment... you could start crafting an overly complex command, but each slot has different reasons why it is there, some are +MP regen, some +item, or whatever other reason it is there)
Probably a bad example, since the tiebreaker does actually strongly prioritize MP regen (weight of 3 for mp regen max). Also, now you're getting into the reasons why there is a tiebreaker in the first place...

2. you are trying to minimize server hits. Those add significant slowdown and overhead to a script, even when playing manually it can be quite slow to swap item back if they are unnecessarily changed. Each item being swapped adds one more server hit, and to a script this adds up to a lot of server hits. This is why most turn spending scripts I came across all use -tie.
IIRC, there are historical reasons for specifying -tie, and it's become a bit of a magic incantation in the community as part of any maximizer invocation.

If you're playing manually, then you could just use the maximizer GUI to select which items you want to equip.

I don't think there's a good reason I specify -tie in my maximizer strings; the number one thing I do to cut down on execution time is restrict the number of slots I care about with potentially complex queries.

Actually, now that I think about it, an even better solution would be to have a threshold option. Where maximizer leaves slots alone if their bonus is lower than a specified threashold.
So for example you could "maximize mox, 2 mys, slotmin 10". Where any individual slot where the value is under 10 will be left alone to reduce superflous server hits.
This probably wouldn't work in the presence of synergies.
 

fronobulax

Developer
Staff member
1. Why are you unlocking the sea in-run? I can't see any in-run relevance.

CanAdv, which is used by several other scripts, will unlock the Sea as a side effect of checking what is available. If doing so is A Bad Thing during a run then CanAdv needs reconsider its behavior.
 

taltamir

Member
1. Why are you unlocking the sea in-run? I can't see any in-run relevance.
I own a sea jellyfish IOTM familiar. If sea is unlocked it will produce 1 free sea jelly per day which is worth 2k meat in the mall. it costs 0 adventures to acquire, just so long as you own it and have the sea unlocked. Mafia breakfast will even automatically collects the sea jellyfish for you. As such, my login script unlocks the sea and I then let breakfast automatically collect it.

Also as fronobulax said, CanAdv auto opens it as well.
Besides, unlocking it doesn't inherently cost anything... so long as you do not use -tie on maximizer that is.
It is adventuring there that is a mistake during a run, not unlocking.
I don't think there's a good reason I specify -tie in my maximizer strings; the number one thing I do to cut down on execution time is restrict the number of slots I care about with potentially complex queries.
But then you lose out on potential items that could go in that slot. You would also need to update the script every time things change. like "oh, there is a new back IOTM that actually can potentially affect this maximizer string, better notice and go edit the maximizer string used for quest7 and quest12 to no longer exclude back item"
This really does not seem reasonable to request of script writers. And realistically, the scripts I have seen just use -tie instead.
====
edit:
If you're playing manually, then you could just use the maximizer GUI to select which items you want to equip.
Fair enough, for the most part yes you really should use the GUI. But the CLI command is there.

In aftercore (lets say I am optimizing meat for neverending party DJ quest), the quantity of items available causes extreme slowdowns and if you use the GUI it means that the GUI doubles those slowdowns since after you do select to equip some items it reruns the maximizer string. Even if you close the GUI immediately, it will still continue running the maximizer string until it is done doing so. I limited it to 100,000 combination once I noticed it went over 1 million combinations tested. But it is still pretty slow in aftercore. Using the CLI halves that since it only does the calculations once instead of repeating them after you click equip.
 
Last edited:

zarqon

Well-known member
To me the maximizer solves a huge problem: specific per-item code when trying to boost a given modifier. You can tell it to maximize your item drop and it will consider all those variables that would be a huge pain to script. However, my most common use case is to tell it to maximize for, say, item drop without it also changing things that don't affect item drop at all (I start from a default outfit I've specifically chosen and would like to deviate from the smallest amount possible). If the conclusion is that "-tie" is not the correct way to do this, I would like to request such a method be implemented because having to add "-tie, -Crimbolex watch, -bathysphere, etc" to the end of every maximizer string is exactly the problem (specific code) that the maximizer is ostensibly implemented to eliminate.
 

Darzil

Developer
I definitely think we can quash, eventually, the not preferring an unhelpful item over no item. If you have no item, and it doesn’t beat a tie with an item, then stick with no item. That is a bug I’ve tried to track down several times and over many hours.

I don’t see how we can ever get maximise to do clever tiebreaking to match the scriptwriters intention, whilst also not doing tiebreaking.

I could see some features being designed, though, such as a maximiser tiebreaker preference so you can control your own.

Adding a standard set of exclusions to every maximisation in a script is pretty easy if you wanted to do it, though deciding that list is harder. For mafia, which is situation agnostic, it would be impossible rather than hard.
 

heeheehee

Developer
Staff member
I own a sea jellyfish IOTM familiar. If sea is unlocked it will produce 1 free sea jelly per day which is worth 2k meat in the mall. it costs 0 adventures to acquire, just so long as you own it and have the sea unlocked. Mafia breakfast will even automatically collects the sea jellyfish for you. As such, my login script unlocks the sea and I then let breakfast automatically collect it.

(I don't really notice stuff on the order of 2k meat a day, especially when it's mall-dependent, but you do you.)

But then you lose out on potential items that could go in that slot. You would also need to update the script every time things change. like "oh, there is a new back IOTM that actually can potentially affect this maximizer string, better notice and go edit the maximizer string used for quest7 and quest12 to no longer exclude back item"
This really does not seem reasonable to request of script writers. And realistically, the scripts I have seen just use -tie instead.
====
Not an issue in my particular case where I'm specifically forcing items into slots like offhand that could otherwise cause combinatorial explosion, specifically for the +meat case you mention below. I recognize that's not a one-size-fits-all solution, but it helps significantly in the aftercore case. It's also not really needed in-run, when you don't have Hodgman gear fighting with Smithsness and brimstone and those Pork Elf rewards from the Agua quest, just for maximizer to eventually declare "oh yeah, all that stuff is terrible".

In aftercore (lets say I am optimizing meat for neverending party DJ quest), the quantity of items available causes extreme slowdowns and if you use the GUI it means that the GUI doubles those slowdowns since after you do select to equip some items it reruns the maximizer string. Even if you close the GUI immediately, it will still continue running the maximizer string until it is done doing so. I limited it to 100,000 combination once I noticed it went over 1 million combinations tested. But it is still pretty slow in aftercore. Using the CLI halves that since it only does the calculations once instead of repeating them after you click equip.
You can also abort the GUI if you really don't want it to rerun the maximization.
 

taltamir

Member
You can also abort the GUI if you really don't want it to rerun the maximization.
Aborting the GUI does not stop the maximizer, it continues to churn through all 1 million plus combination options even when the GUI is closed. It just doesn't display them when its finally done. sending "abort" does not stop it either, and playing the game doesn't either, it just continues until finished
 
Hitting escape (or stop now on the adventure tab) aborts the maximizer and reports whatever is the best combination found so far.

Edit: the 'abort' cli command seems to have the same effect, so I'm not sure what you are talking about.
 
Last edited:
Top