Search results

Should be fixed in r28275, thanks for the nudge.

The line assertThat(getBoosts(), not(hasItem(recommendsSlot(Slot.ACCESSORY1)))); is a test. When the test fails, it prints what you see: we expected (something), but actually (something else). In this case, we expect that running the maximizer does not change accessory 1, but in fact...

We expect getBoosts() to return a collection, and for that collection to not have an item that recommends slot ACCESSORY1. However, the collection was [<[equip acc1 ...]>] which does equip something in acc1, so the assertion fails.

My current acc1 here is the Cincho de Mayo, which doesn't offer any +adv or +fites. The Counterclockwise Watch is +3 compared to the baywatch, but it suggests replacing acc1 instead of acc3... I have reproduced this with a test, which is a rarity for maximizer bugs. @Test void...

Countermeasures determines both what the special virus is, and the halfway adventure element. Yes, the intrusion determines the hacker. Everything is named accordingly except black implies grey. I guess it doesn't show up with a name due to the HTML not matching (the name is set in code)...

I can confirm. The CLI opens with logPreferenceChange => true Sending login request... Preference _concoctionDatabaseRefreshes changed from to 1 Using data override: data/mallprices.txt Preference pingLatest changed from api:10:114:126:1188:19620:118.80 to...

Fixed r28237.

If _takerSpaceSuppliesDelivered is false, you need to visit the TakerSpace (visit_url("campground.php?action=workshed");) to update the ingredients before the creatable_amount call is correct. I recently fixed it to refresh concoctions when you create things in r28233.

Should no longer happen on r28236.

I also get that when the autumn-aton would return from one of the new Cyberzones. It's a KoL bug, we can't fix it ;)

okay yeah it was my mistake, so long as your last choice adventure was the deviling one it works. The URL is wrong in the command.

Can you provide a debug log (debug on; devilcandyegg WHATEVER; debug off), please? It worked for me, which is the odd thing.

This has a set bonus like Brimstone that needs to be implemented (in modifiers + the maximizer). Also there are 4 skills, including one track and one NC force.

Things that aren't butts work, this is a KoL bug: This is a sheet of copier paper with a grainy, blurry likeness of a butt<!-- monsterid: 1 --> on it.<!-- itemid: 4873 --> 1 should be 1049

It's the consequence manager, set from viewing the photocopied monster item description. No idea how this could have broken.

If any script winds up using this, somebody is going to turn it off and then complain the script doesn't work, which becomes our problem... that was my thinking.

More PRs going up, keep the reports coming :) Also with how I've implemented it (straight hardcoding the current HTML) it'll have to change again once whatever color-changing thing goes in, but that should be easier to search for (i.e. search for `<b style="color: white"`).

I made the "supplies" property then just copied for the rest. Ascension-resetting would indeed be better. I'll change it in the next PR.

New workshed iotm. Make various items with ingredients that stack up over several days Wants: * command for creating items * prefs for tracking ingredients * session logging for deft pirate hook steal if it doesn't already work straight up * jolly roger flag queue manip after somebody figures...

withResponse only resets the client on the GenericRequest. The client on FileUtilities is separate and cached, so if any other code uses it first you'd not expect it to be overridden by the fake client created by the tests.