Search results

My usual approach is to hardcode certain slots (e.g. offhand, due to hobo power / smithsness) that tend to lead to combinatorial explosion. That and caching maximizer output via custom outfits during the course of running scripts.

Hm. LoginManager.timein -> login -> doLogin -> initialize -> KoLmafia.refreshSession calls refreshSessionData(), which in turn makes a CharSheetRequest; afterwards, refreshSession invokes recalculateAdjustments(), so timing in should be covered in exactly the same way that a normal login is...

You're close, but you need to explicitly invoke find() on your matcher. matcher slimedefeated = create_matcher("([0-9]+) turns spent in this dungeon:",visit_url("clan_raidlogs.php")); if (find(slimedefeated)) { print(group(slimedefeated,1).to_int() + " defeated","green"); }...

I believe r27647 fixes this.

I believe r27647 fixes this.

I think this is fixed with r27647, but let us know if you see this bug again. I'm not sure. The former seems safer to me (if there's a combat skill that also affects modifiers) but less efficient.

I think this is fixed with r27647, but please reopen if it isn't.

#2012 sidesteps that by just updating availableSkillsChanged in a synchronous fashion, and adding an explicit call to recalculateAdjustments() in CharSheetRequest. I could probably revert the change in #2011, since I'm pretty sure this is a more comprehensive fix, but, that commit doesn't really...

Oh, I understand the race you described now. We fire a listener for (skill) whenever we add a new skill, which in turn sets availableSkillsChanged. I suppose we want a mechanism to wait until any pending listeners have finished executing.

Hm. r27646 doesn't seem to have fixed the problem fully. I'll tinker some more.

I looked at it some more, and that's not actually quite right. applyPassiveModifiers was always populating availablePassiveSkillModifiersByVariable, even if there were no skills loaded. Anyways. #2011.

I was playing around with trying to get it to work in tests, but there are some quirks with how we manage passives -- both campground details as well as familiar modifiers (e.g. Underwater Familiar) were blocking applyPassiveModifiers from correctly detecting that skills had been reset.

@Ryo_Sangnoir A simpler explanation: during LoginManager.initialize(), we call recalculateAdjustments() on login (in KoLCharacter.reset()) well before we populate our skills (via the CharSheetRequest in KoLmafia.refreshSession()). diff --git a/src/net/sourceforge/kolmafia/KoLmafia.java...

Yeah. I think this was broken by r26962. (and by "think" I mean I checked the output of `numeric_modifier weapon damage` on login with both r26961 and r26962, and confirmed that r26962 introduced the regression I've been using as my test case.)

Yeah, this isn't a new bug per se, but rather one that became much, much more visible with the organ tracking change. I checked out an earlier revision (r27601 contained the organ tracking change), and saw the same results for Weapon Damage:

It's not just organ capacities, it turns out -- other skill modifiers are affected, too.

modtrace calls recalculateAdjustments, but that happens at the end of the invocation...? Well, at least we're consistent. And it looks like that call to modtrace recomputes the modifiers.

Huh. This is fascinating: That said, I can reproduce pretty reliably.

Changing mall_price() to return 0 would definitely break existing scripts. I just cited that as the first instance that I found that checked historical_price(it) == 0, even if it's probably fine here. I'm inclined to agree, but this has been observable behavior for so many years that it's...

One concern I have with storing -1 as a valid (crowdsourced) mallprice is that if an item is temporarily extinct (very possible for a low-volume item) or hasn't been added to the mall yet, we may end up caching -1 for longer than intended. This is probably fine, but something to be aware of...