Search results

It turns out this is somewhat difficult to test during a TCRS run. If anyone wants to test the patch now and see if it fixes the issue, be my guest. Just to be clear, I have not been able to check if this resolves the issue. Don’t merge it without testing it yourself. When I’m finished with my...

It seems like this isn’t always true. For now, I’m going to check for both the parent being null and the parent being the child.

A lot of modifiers appear to be incorrect, actually. They’re using “zone” instead of “location”, which is breaking now. Item slime-covered shovel Weapon Damage: [100*zone(The Slime Tube)+60], Initiative: -10 This shouldn’t be difficult to fix as part of the patch, though. Whoever made...

OK, it’s going into an infinite loop. It looks like the parent zone of a top-level zone is itself? I’m probably just misunderstanding the output of AdventureDatabase.PARENT_ZONES.get( currentZone ); For now, I’m going to assume that’s intended behavior and adjust the loop accordingly.

OK, my patch is written, I just need to test it. It compiled successfully, at least.

I’d rather just make the zone() function recursive, as I said as you posted that. Existing modifiers for zones like Hobopolis and Spookyraven Manor could benefit from that, not to mention future maintainers. Heck, given the current approach of adding up redundant zone expressions, it might...

OK, I’ve looked at the code in Expression.java that actually evaluates the modifiers, and it looks like it is just doing a case-insensitive match on the zone. I could submit a patch that fixes that, since it is supposed to take nested zones into account. There’s a few ways I could implement...

That’s odd, since I had a very specific conversation with Veracity about this. She said that PirateRealm Island is nested within PirateRealm. If PirateRealm Island is within PirateRealm, and the specific islands are within PirateRealm Island, that should work. Clearly one of those things is...

TCRS has proven very time-intensive for everyone, so it may be a while. I have patches that have been awaiting review for over a month.

It’s the spoon, not the saber. I think they mistyped.

Another interesting quirk: when you donate booze to the Carriageman in Dreadsylvania, it uses the normal potencies. I’m not sure if this holds for other mechanics that use attributes in unusual ways, like feeding Asdon Martins and such.

Huh, learn something new everyday. That’s pretty much exactly what I was proposing. Thanks for the tip.

Is this going to be reviewed eventually?

Rather than indicating things like skillbooks with manually designated values like item_type, I think the focus should be on identifying them based on their in-game attributes. In that case, we should overload to_skill() to accept items, and track them that way. That’s just my opinion, of...

As far as I know there’s only an off button for things with mechanical impact like lovebugs. Mouseover text already exists for chat effects, though, and a KoLmafia relay script could undo the word replacements if the originals were exposed in the same way. Heck, the existing KoLmafia Java...

I can’t think of a good solution to such effects beyond asking Asymmetric to help us out and include the original words in the HTML somehow (hoverbox text?) when replacing arbitrary words. They already do that for chat effects, more or less.

r19295, I assume. Clever solution, Veracity. The “Uniques” approach might also be useful for cleaning up hardcoded item synergies or something.

I agree that that is probably the right call for the moment. If anyone does want to try and tackle it, it should probably be at the level of the helper functions that create the JavaX objects, as opposed to handling it for each dialog. That may not be worth the added complexity.

Relying on the GUI can be similarly difficult in headless mode. Granted, I’ve gotten the impression I’m one of the only people who regularly use KoLmafia that way, but it may still be worth considering. I’d appreciate a way to handle confirmation dialogs from the CLI, which could also help...

On a possibly related note, the number of times that you have visited a location does not persist across logins of the same account.