It appears that when you click on the link to visit the hermit after getting the dinghy plans, it gets a worthless item and gets the planks, but doesn't decement the number of worthless items held. As a result, when you next attempt to visit the hermit, rather than getting a worthless item, it will fail.
Bug - Fixed Getting Dingy Planks via Relay Browser doesn't seem to use up Worthless Trinket
- Thread starter Darzil
- Start date
It looks like HermitRequest.parseHermitTrade() will skip processing the cost of buying a hermit item if the TRADE_PATTERN matcher doesn't find "whichitem=([\\d,]+).*quantity=(\\d+)" in the submitted URL.
The problem is that the use link that is added next the the planks submits "quantity=1&whichitem=140" instead.
r9354 removes TRADE_PATTERN and uses separate ITEMID_PATTERN and QUANTITY_PATTERN instead. Unfortunately, I clicked on the plank link to get a debug log and figure out the problem, so I can't test this particular case.
This is my first unsupervised commit, so I hope I didn't break anything. I tested getting hermit items both with the "hermit" command and through the relay browser, and everything was still working =)
The problem is that the use link that is added next the the planks submits "quantity=1&whichitem=140" instead.
r9354 removes TRADE_PATTERN and uses separate ITEMID_PATTERN and QUANTITY_PATTERN instead. Unfortunately, I clicked on the plank link to get a debug log and figure out the problem, so I can't test this particular case.
This is my first unsupervised commit, so I hope I didn't break anything. I tested getting hermit items both with the "hermit" command and through the relay browser, and everything was still working =)
That is the correct solution. We've had the same problem elsewhere, repeatedly, where a matcher assumed that the fields were in the same order as in a particular instance of the URL, either created by KoLmafia or by KoL itself, which broke when they appeared in a different order.
(Note that WE control what we put into the "use" link, so you COULD have just changed the order there, but this is the more robust fix that might prevent similar issues later.)
Good job!
(Note that WE control what we put into the "use" link, so you COULD have just changed the order there, but this is the more robust fix that might prevent similar issues later.)
Good job!
Thanks.
The problem with switching the order in the "use" link was that UseLinkDecorator.UseLink() simply appends the item ID at the end of "useLocation". It seemed easier (and, indeed, a more robust fix) to change HermitRequest.java than to make UseLinkDecorator.UseLink() smarter about where it places the item ID.
The problem with switching the order in the "use" link was that UseLinkDecorator.UseLink() simply appends the item ID at the end of "useLocation". It seemed easier (and, indeed, a more robust fix) to change HermitRequest.java than to make UseLinkDecorator.UseLink() smarter about where it places the item ID.