Razorsoup
Member
Was able to bounty hunt by auto-adventuring with +1 filthy lucre as a goal and everything worked as expected. No aborts, no debug log. Yay!
New Content - Implemented Bounty Hunter Change
- Thread starter Darzil
- Start date
Was able to bounty hunt by auto-adventuring with +1 filthy lucre as a goal and everything worked as expected. No aborts, no debug log. Yay!
dixmcdix
Member
Edit: If I start the Hard bounty, then do the Easy bounty it seems to work fine. I'm baffled. 
Thanks again for making this program its so awesome and such a timesaver!
Weird... I am getting the error still on 13566 but only on the easy bounty.
I can't imagine others are having no issues and it's just my Mafia, so maybe I've got some setting messed up or something?
Thanks again for making this program its so awesome and such a timesaver!
Weird... I am getting the error still on 13566 but only on the easy bounty.
I can't imagine others are having no issues and it's just my Mafia, so maybe I've got some setting messed up or something?
Theraze
Active member
Any chance we could get some additional tracking bits on the bounty items? If we tracked the locations of bounty items, I could at least make the old bounty.ash able to pick from the locations, but as it stands it's slightly difficult to guess programically where to go for the "spent handwarmer" bounty. Additionally if we tracked how many items were needed, then BHH could predict about how many adventures each bounty should take again.
I can scrape the bounty page, but if I can save server hits after mafia itself knows what and where, so much the better.
I can scrape the bounty page, but if I can save server hits after mafia itself knows what and where, so much the better.
Some bounties are available from multiple locations. How would those be handled?
I'll look into creating a bounty proxy item at some point to expose the information we have in the database (name, plural, image, type, number, monster). I wanted to duplicate existing functionality first.
Theraze
Active member
True. So tracking the monster, rather than the location, would be the useful thing. Then we can just run it through something like the wheretofind alias and find where it's most likely to show up.
Great, thanks! As part of current functionality and cleanup, the old proxy records should probably be removed, so that any script that tries to use them doesn't send the user off to collect items that don't actually exist. Or to avoid the inevitable "multiple bounties in this location because it's now tied to monster rather than location" issues that will show up if we don't allow for them.
As part of current functionality and cleanup, the old proxy records should probably be removed, so that any script that tries to use them doesn't send the user off to collect items that don't actually exist. Or to avoid the inevitable "multiple bounties in this location because it's now tied to monster rather than location" issues that will show up if we don't allow for them.
Do you mean the bounty and bounty_count ones for $item, or is there something else ? They currently return none and 0 respectively, as a temporary measure to prevent script errors whilst not allowing them to return wrong information.
r13576 Added ash proxy record "bounty". Gives plural, type, number, image and monster that drops the bounty shown in preferences _untakenEasyBountyItem, _untakenHardBountyItem, _untakenSpecialBountyItem, currentEasyBountyItem, currentHardBountyItem and currentSpecialBountyItem.
r13577 returns the new bounty. It also comes up with an error (eg Unknown item found: pieces of triffid bark) but not sure where this is generated - any ideas/fixes welcomed.
The bounty field didn't just show today's bounty, but all possible bounties, and this one does the same (or all currently known ones at least).
Theraze
Active member
Any chance we could have a to_bounty(string) function so that we can actually do get_property("currentEasyBountyItem").to_bounty() or something similar?
