Search results

#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...

Should be fixed as of r27633. Let us know if you find any more issues!

(PR #2000)

r25983 apparently changed this behavior. Should be an easy enough fix, although it's a little worrying that nobody seems to have noticed in nearly 2 years.

https://forums.kingdomofloathing.com/vb/showthread.php?t=186384 Some other strategy comments: 1. Get unlockers (bombs / missiles / ice beam) to access more treasure rooms. 2. Get all the treasure rooms for upgrades, and more creds so you can buy more things in between levels. 3. bombs and...

r27622 fixes this, at least for me.

https://github.com/kolmafia/kolmafia/pull/1986

Ah. Yeah, that is backwards.