Bug - Confirmed Maximizer didn't equip a weapon

This isn't maximizer this is autoscend.

Nothing has been changed or fixed. This issue doesn't happen all the time, which is why it is tricky to fix.

We know one issue -- with "+effective", if there are no valid weapons, nothing will be equipped. The accordion issue you have above is different, but by the looks of it, it happens because you only have a 2-handed weapon, and "nothing" + "offhand" is ranked higher.
OK. I see. So getting rid of the accordion didn't matter because the actual issue is that when no weapon is equipped given that condition it causes an error and then a shutdown of autoscend? Have I got that right?
 
Getting rid of the weapon let autoscend continue because you now have no weapons so it doesn't error.

Alternatively you can run "set auto_debug_maximizer = false" in the CLI and it should warn but not abort in that case.
 
@Yellowbeard

First, thank you for reporting. This has been a long and difficult issue to debug. The folks at autoscend graciously agreed to assist in gathering data which is why you get the messages you do.

The hope is that someone will come up with a set of conditions where no weapon is equipped AND identify a weapon that is available to equip and equipping the weapon produces a higher maximizer score under the same conditions. In the absence of such an example it is not clear whether there is a bug or a feature request or just an opportunity for people who write maximizer strings to make a greater effort to understand the side effects of their maximizer string choices.

There are people who think any weapon is better than none. This is probably a feature request because there are a few cases where no weapon is the right answer. Using the effective keyword is a common case where no weapon is correct. Way of the Surprising Fist path and skills sometimes make no weapon the appropriate choice. Low level characters often lack weapons that could be equipped. As noted above "nothing" + offhand can score higher than any two handed weapon. A case where "nothing" + offhand is chosen when there are available one-handed weapons is probably a bug, but so far no one has reported it.

The autoscend information is helpful but ideally the next step after getting the message would be to identify the weapon that should have been equipped.

Thank you.
Thanks for responding. So first of all is it worth my continuing to report and discuss even though I don't code? FWIW I DO teach science and also have a degree in philosophy so logic, reason, and experimental cases aren't strangers to me even though I don't have the specific language necessary to write code.

What I DON'T want is to waste peoples' time. What I DO want is to help if there is some way I can do so.

For a moment I am going to assume that I could potentially have a useful thing to say until told otherwise. But if I am wasting time then please just let me know and I will bugger off. ;)

So here's the thing that is weird to me in this case. I tried the accordion thing (2 handed v/s weapon plus offhand) because someone else said that had worked. My experiment was to simply sell the accordion which was my only 2 handed weapon. That didn't fix it. However, reading what both you and Ryo_Sangnoir said it appears that the real problem (if I am understanding you) is that there are certain cases in which nothing+offhand satisfies some condition that is attempting to be met (I assume using the maximizer but I don't know how all the parts work) but that autoscend is not currently coded to ALLOW nothing+offhand so when that condition occurs it causes an exception and everything stops. That's what I THINK you're saying but if I am wrong but it's not worth re-explaining it just tell me - it's no biggie.

But assuming that IS correct I have a different piece of evidence that SEEMS like it should matter here which is that I tried SEVERAL times to re-run autoscend under various scenarios (killing a few things then re-running, trying to equip a weapon then re-running, getting naked then re-running, etc.) and none of them would work. I even tried it multiple times changing no conditions under some version of "banging my head against a wall for no good purpose."

I even tried uninstalling and re-installing autoscend. I tried several old releases I had. Nothing worked.

But then one single variable changed and that was that r28495 dropped and I installed it and then IMMEDIATELY ran autoscend having changed nothing else and it started working.

I can't see ANYTHING in the release data for r28495 that would have changed that but if I do an experiment in the lab 40 times, sometimes with the same controls and sometimes without and keep getting the same results but then try the exact same experiment in new glassware and get a totally different result I tend to look at the only variable that changed - in this case the glassware. That could 100% be mere confirmation bias but I can't figure out WHY I would have gotten a different result the next day when the ONLY thing that had changed was the version. Surely the problem isn't purely random. The only thing that changed OTHER than the version was the day so.... lunar conditions maybe somehow?

Hope that makes sense. Wondering if you want to see my logs.

Again, fully happy to just bugger off because it's working for me now but I also recognize how WONDERFUL all of you make my life so if I can help then I would love to do so.

Thanks again for all you do!

YB
 
Last edited:
Getting rid of the weapon let autoscend continue because you now have no weapons so it doesn't error.

Alternatively you can run "set auto_debug_maximizer = false" in the CLI and it should warn but not abort in that case.
Getting rid of the accordion didn't fix the problem. Getting rid of the accordion didn't do anything.

I made a longer post above. The only variables I can see that actually changed between it not working and it working were the new release (28495) and that rollover had occurred. But I had tried over various rollovers in the past to no avail as well.

Also thank you for that bit of code I can run to get around the problem if it occurs in the future. That may save me killing myself. ;)
 
So first of all is it worth my continuing to report and discuss even though I don't code?
Put simply, yes.

The best way to help us figure out this problem is to help us figure out how to reproduce the problem consistently. In particular, if you have some setup that consistently triggers the bug across multiple characters with differing sets of skills, available items, ascension states, etc, that's incredibly helpful.

And even if you don't have that, reporting more detailed scenarios where you've run into problems gives us more data points to figure out what these scenarios have in common..
 
We should discuss what a fix might be. "nothing" + offhand is the right answer in some cases.

If we can ever find a case where (something + offhand) > (nothing + offhand) but the maximizer picks nothing then we have a bug that needs to be fixed. But until we find that something what we really have is a feature request.
I am down for that discussion. I don't think we've seen any complaints about this with WotSF, but we might not, since WotSF doesn't allow offhand or weapons to be equipped at all.

But let's dig into my 20250217 log (from this previous post (full logs and inventory listed above)).

Here's the maximizer request (originally from Autoscend, but it was continuing to run after that.
Maximizer: 5item,meat,0.5initiative,0.1da 1000max,dr,0.5all res,1.5mainstat,-fumble,0.4hp,0.2mp 1000max,3mp regen,1.5weapon damage,0.75weapon damage percent,1.5elemental damage,2familiar weight,5familiar exp,15Moxie experience,5Moxie experience percent,+200bonus spring shoes,+200bonus bat wings,effective,2 dump

Things I notice:
  • effective. Perhaps this is excluding 1H items
  • da and mp have max values set, so it might not be usefully better.
  • two items have bonus values, which are newer parameters. Shouldn't affect weapon choice, since they aren't for a weapon/offhand slot.
Slot.ACCESSORY2 is doing double duty as Slot OFFHAND_MELEE
Slot.ACCESSORY3 is doubling as Slot OFFHAND_RANGED
Slot.STICKER3 is doubling as Slot WEAPON_1H

We'll see what's in those lists in the 2 dump list.
I am an AT in this run, so Moxie is higher than Muscle. Per Darzil's description here, I should consider only ranged (and knives since I have Tricky Knifework).

SLOT WEAPON
[(none) (1,769), stolen accordion (1,772)]
[stolen accordion]


SLOT OFFHAND
[hobo code binder (1,769), (none) (1,769), third-hand lantern (1,772), McHugeLarge left pole (1,784), furry yam buckler (1,785), Roman Candelabra (1,877), oversized monocle on a stick (1,894), august scepter (1,939)]


[august scepter, McHugeLarge left pole]


[...]

SLOT ACCESSORY2 (OFFHAND_MELEE)
[(none) (1,769), seal-clubbing club (1,772), seal-clubbing club (1,772), turtle totem (1,772), turtle totem (1,772), pasta spoon (1,772), pasta spoon (1,772), saucepan (1,772), saucepan (1,772), boot knife (1,781), McHugeLarge right pole (1,876), McHugeLarge right pole (1,876), candy cane sword cane (1,933), candy cane sword cane (1,933)]
[candy cane sword cane, McHugeLarge right pole]


SLOT ACCESSORY3 (OFFHAND_RANGED)
[(none) (1,769), disco ball (1,772), yam cannon (1,867)]
[yam cannon]


SLOT STICKER3 (WEAPON_1H)
[(none) (1,769), disco ball (1,772), boot knife (1,781), yam cannon (1,867)]
[yam cannon, boot knife]

Post Install, this is the inventory from the status call. There is no weapon or offhand
"equipment":{"hat":"11565","shirt":"5041","pants":"11630","acc1":"11546","acc2":"11787","acc3":"11786","container":"11658","fakehands":0,"cardsleeve":0}

Based on the above, I would expect the august scepter (OFFHAND, 1939) + yam cannon (WEAPON_1H, 1867) to beat none (WEAPON, 1769) + none (OFFHAND, 1769).

Can we figure out why it doesn't?
 
Based on the above, I would expect the august scepter (OFFHAND, 1939) + yam cannon (WEAPON_1H, 1867) to beat none (WEAPON, 1769) + none (OFFHAND, 1769).

Can we figure out why it doesn't?

There are a few tests already committed that could be copied and modified to reproduce the above.

There are at least three distinct possibilities and the difference is important because the nature of testing and fixing varies.

  1. The maximizer selects a weapon and then fails to equip it. A test for this case must include the steps to actually equip the weapon and the problem might not be with the maximizer's core functionality. Attempts to write a failing test have not been successful.
  2. The maximizer fails to select a weapon. It is believed that a key to understanding, and fixing, this case is an instance where the maximizer scores are different with and without a weapon and the latter is chosen. Efforts to write a failing test have not been successful.
  3. The maximizer is doing exactly what it is expected to do. There are several tests that set up conditions where no weapon is the right choice for the test conditions. In this case requiring a weapon to be equipped is a change in behavior. No tests have tried to address this because no change in behavior has been proposed or implemented.
A problem, of course, is that we really can't distinguish between 2 and 3 with any existing tests.
 
autoscend is not currently coded to ALLOW nothing+offhand so when that condition occurs it causes an exception and everything stops. That's what I THINK you're saying but if I am wrong but it's not worth re-explaining it just tell me - it's no biggie.

This is actually in Kolmafia and KoL
Nothing + offhand is valid for KoL, as long as the offhand isn't a weapon.
I am not a coder and so I don't know if this helps, but this section of code is odd to me. Looking at the portion in red below:

1. It seems to be looking at weapons as potential SLOT ACCESSORY2 choices
It's not looking at them as accessories. It's reusing the slot to save on memory. Accessories are pulling the first three items from SLOT ACCESSORY1. That's not broken (that I know of). This is OFFHAND_MELEE

2. It doesn't seem to be choosing a SLOT ACCESSORY3
It isn't finding any OFFHAND_RANGED and so there's nothing to show here.


3. It doesn't seem to be choosing a SLOT WEAPON
Without any OFFHAND_RANGED, using the +effective flag (which forces it only to consider ranged weapons if your moxie > muscle), this is correct. This is close to the case @fronobulax is discussing where "nothing + an offhand" is correct. It is not more highly rated than "a weapon + an offhand", because the effective flag means that you have no weapons, as far as the maximizer can tell.


And the maximizer ITSELF tells me that "NO WEAPON WAS EQUIPPED BY THE MAXIMIZER...etc" so this definitely seems like a maximizer error to me. Is it somehow skipping SLOT ACCESSORY3 and SLOT WEAPON?

Hope I am not saying hopelessly stupid things that are obvious to anyone who actually programs.
As a former QA analyst, you are doing a great job with your data packed issue reports. Thank you!
SLOT OFFHAND
[hobo code binder (2,251), magical ice cubes (2,253), McHugeLarge left pole (2,254), rake (2,274), oversized monocle on a stick (2,277), April Shower Thoughts shield (2,296), Roman Candelabra (2,391), august scepter (2,425)]
[august scepter, McHugeLarge left pole]

SLOT ACCESSORY1
[continuum transfunctioner (2,172), datastick (2,172), McHugeLarge left ski (2,177), McHugeLarge right ski (2,187), cursed monkey's paw (2,215), Cincho de Mayo (2,235), yamtility belt (2,236), spring shoes (2,425)]
[spring shoes, yamtility belt, Cincho de Mayo, McHugeLarge right ski, McHugeLarge left ski]
SLOT ACCESSORY2
[seal-clubbing club (2,253), seal-clubbing club (2,253), turtle totem (2,253), turtle totem (2,253), pasta spoon (2,253), pasta spoon (2,253), saucepan (2,253), saucepan (2,253), little paper umbrella (2,258), little paper umbrella (2,258), McHugeLarge right pole (2,345), McHugeLarge right pole (2,345), candy cane sword cane (2,418), candy cane sword cane (2,418)]
[candy cane sword cane, McHugeLarge right pole]
So my take on your result is that
1: you have no ranged weapons that you can use
2: your moxie is greater than your muscle
3: you have an offhand item that is worthwhile
4: autoscend is setting "effective".

So you won't use the ACCESSORY2 items (all MELEE), you have no usable ranged items, and an august scepter is better than no offhand. It looks like no weapon is correct, because you don't have one you can use.

My immediate thought is that maybe we should test if the same search without the effective flag gives no weapon.
 
Last edited:
My immediate thought is that maybe we should test if the same search without the effective flag gives no weapon.

Been there. Done that. Maybe :)

See itShouldMaximizeAndEquipSelectedWeapon in RuntimeLibraryTest and the tests nested under Effective in MaximizerTest

My recollection is that during test development there were identical copies of some of the tests that differed only in the presence or absence of "effective" in the string. The copies didn't really add anything to the knowledge base so the tests that were actually kept and committed were the ones that showed effective did what it was claimed to do.
 
Been there. Done that. Maybe :)

See itShouldMaximizeAndEquipSelectedWeapon in RuntimeLibraryTest and the tests nested under Effective in MaximizerTest

My recollection is that during test development there were identical copies of some of the tests that differed only in the presence or absence of "effective" in the string. The copies didn't really add anything to the knowledge base so the tests that were actually kept and committed were the ones that showed effective did what it was claimed to do.
First, that's a great model and it tests things like I expect.

This is my draft test to show that it selects an offhand and none.

If we adjust "effective" to have allow the non-preferred type (melee/ranged) if the "effective" type is an empty list, this is how I'd want to test it. Honestly, "effective" is a big hammer to use just to enable tricky knifework.


Speaking of which, I'd like your thoughts on changing effective so that it didn't apply at all if the list of potential effective items was empty. I think this suggested change would just let the 1H "wrong" type compete with "none", so it wouldn't preclude none, but it would likely mean that (for instance) as a moxie class, if it wanted to use my august scepter, it would also pick my candy cane sword cane instead of none, I'd think it was doing better.

I don't think this

Java:
@Test
public void moxieEffectiveSelectsOffhandAndNone() {
String maxStr = "effective";
var cleanups =
new Cleanups(
withStats(5, 5, 10),
withEquippableItem("seal-skull helmet"),
withEquippableItem("astral shirt"),
withEquippableItem("old sweatpants"),
withEquippableItem("august scepter"),
withEquippableItem("seal-clubbing club"));

try (cleanups) {
assertTrue(maximize(maxStr));
assertThat(getBoosts(), not(hasItem(recommendsSlot(Slot.WEAPON))));
assertThat(getBoosts(), hasItem(recommendsSlot(Slot.OFFHAND)));
}
}
 
So I have a test case that attempts to recreate the beginning of run conditions from https://kolmafia.us/threads/maximizer-didnt-equip-a-weapon.29577/page-6#post-176370

My test case is suspect in that it doesn't generate the same scores. if I were more motivated I would also investigate what the stats were after all of the Cleanups and whether there were things in an API call that changed the game character but not the test character (since the test Api call effectively does nothing).

But, I had one run that ended with:

50 combinations checked, best score 1,336.62
Putting on fake arrow-through-the-head...
Equipment changed.
Putting on McHugeLarge duffel bag...
Equipment changed.
Putting on old sweatpants...
Equipment changed.
Putting on Everfull Dart Holster...
Equipment changed.
Returned: true

I then removed all of the withSkill cleanups and got

30 combinations checked, best score 1,081.25
Putting on fake arrow-through-the-head...
Equipment changed.
Wielding disco ball...
Equipment changed.
Holding august scepter...
Equipment changed.
Putting on McHugeLarge duffel bag...
Equipment changed.
Putting on old sweatpants...
Equipment changed.
Putting on Everfull Dart Holster...
Equipment changed.
Returned: true

So it is a reasonable hypothesis that one or more skills are being considered and their presence makes weapon and/or off hand less of interest.

Off to figure out which ones and why.
 
Well I stripped out items and non-passive skills until the bloated test and the stripped down one have the same results. Curiously the non-passive knife skill seemed to be needed. If the weapon and off hand slots are empty they are not filled and I have not convinced myself that is unreasonable. But if I equip a 2h weapon there is a failure because it wants to add something off hand but can't with a 2h equipped. That, by itself is something that needs to be fixed. But this is a one year old thread because I keep getting distracted and it is mostly a solo effort and workarounds do exist.

Going to sleep on the next step. That might be simplifying the maximizer string.
 
Back
Top