Search results

FYI -- you'll have an easier time getting your change(s) accepted if you break up your PR into several smaller PRs so it's not as daunting to review all at once. (One PR per logical fix or perhaps per challenge path is a good rule of thumb. Bundling too many changes together makes it hard to...

If you're using `java` from the command line, you'll need to specify `java -jar Kolmafia-28594.jar`.

Hopefully you then reinstalled Java 21, since we require that at a minimum. fronobulax's suggestion to use multitool may also help.

appearance_rates has a two-parameter version. if you want stateful results, specify `true` as the second argument. This forces Mafia to call AreaCombatData.recalculate(), which in turn calls the code in adjustConditionalWeighting in the linked PR. Once recalculate() is called (one way or...

r28563

https://github.com/kolmafia/kolmafia/blob/main/src/net/sourceforge/kolmafia/textui/command/HermitCommand.java#L61 Could probably be augmented to use the same fuzzy find that we use elsewhere. I may make that change over the weekend if nobody beats me to it.

Ah, see, this is where I'd just write: // You could write 1000, 2000, 3000, 4000, 5000, 6000 if you wanted, but that's less obvious to the reader. foreach s in $skills[ Seal Clubbing Frenzy, Patience of the Tortoise, Manicotti Meditation, Sauce Contemplation, Disco Aerobics, Moxie of...

(obligatory instructions: install that as, say, scripts/buy_from_mall_stores.ash, then run it by invoking `call buy_from_mall_stores` in the graphical CLI.)

Actually, I looked into this. We only ban mall searches, not queries of individual mall stores. Individual mall stores are at mallstore.php. // Player ID -> item -> quantity int[int, item] items_to_buy { 121572: { $item[roll in the hay]: 2, $item[slap and tickle]: 1, }, 354981...

I'm curious if anyone has any experience with https://checkerframework.org/manual/#lock-checker (gradle plugin) or https://github.com/google/error-prone (specifically GuardedBy)? I could see enforcement of lock acquisition order being possible with @GuardedBy (namely: by stating that each lock...

So, I ("obviously") can't self-approve it, since I originated the PR. I have two remaining thoughts / concerns, but otherwise am fine with merging the commit and seeing what happens. 1. What are the performance implications of holding these locks on Preferences operations that can be invoked...

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

A possibly terrible idea I had when starting to read this post: what if we generalized this such that if you import a script with a conflicting function func (or, generally, any symbol), it's only imported as func@script? And otherwise (for backwards compatibility purposes), all other functions...

Perhaps we should be checking InventoryManager.getAccessibleCount(TOXIC_GLOBULE) == 0, since in order to purchase anything from that coinmaster, you need toxic globules, which trivially satisfies the accessibility requirement.

There is some bifurcation of logic between whether you're running this in headless mode or not. Preferences.java#L183-198: if (SwinglessUIUtils.isSwingAvailable()) { try { SwingUtilities.invokeLater( () -> {...

As in, the vast majority of our users who just download the jar and double-click on it to launch Mafia?

I omitted a few steps in my reasoning. I was wondering if there were any situations where we would want to remove a skill for combat purposes (where we obviously cannot just change equipment) but keep it for noncombat purposes. It seems the answer, at least for now, is "no".

Yeah, the second error is because Java is in a directory with a space in the name (which primarily affects Windows users, who usually have Java under C:\Program Files\). Known issue; we'll provide an update when that's fixed.

I am surprised by the notion that multitool might download a new jar, and then not launch it. Would it launch the old jar? Would it do nothing? IMO the "expected" behavior from what I am viewing as a launcher + auto-updater is the following steps: Update Mafia if necessary. Clean up old...

Observation before you go too far down that path: Record didn't come until what, Java 15? (okay, looks like first preview was Java 14 and it was finalized in 16.) You're correct that the right answer is generally "before refactoring" to prevent further backsliding :) Regarding the reported...