Feature - Rejected Purchasing from NPCs only
- Thread starter Theraze
- Start date
So if I understand correctly from the other thread that's a script buying from the mall when you were in ronin, transferring it to Hangk's, then seeing it still didn't have one and buying another?
Would acquire have just failed due to lack of access, and failed anyway if you had limits set?
Would acquire have just failed due to lack of access, and failed anyway if you had limits set?
If you turn off mall purchasing (there's a reason I will never have it enabled) and use acquire/retrieve_item(), mafia will never automatically use the mall. Perhaps there could be a separate setting to not use the mall while you're in-run, but I would still expect buy to ignore that setting.
Right. You CAN buy from the mall in-run now. The result goes into storage. As was said (not by me!) when I made "buy" work in-run, you are expected to know how the game works: if you buy from the mall in-run, it will go into storage.
On the other hand, if you want to guarantee that the item will go into inventory, use "acquire", which will not not go to the mall in-run.
I assume you used "buy"?
On the other hand, if you want to guarantee that the item will go into inventory, use "acquire", which will not not go to the mall in-run.
I assume you used "buy"?
I had a similar situation, with far less dire results:
I was in hardcore, thought I had gotten my pirate outfit (but was mistaken) and entered my usual "buy abridged, big book". It failed on the dictionary, but it then bought the insult book from a mall store. Since I was in hardcore, this really didn't help me.
I freely admit that this could have been avoided with due diligence on my part. As for the use of "buy", I find it handy that I can put get both items with one command.
I was in hardcore, thought I had gotten my pirate outfit (but was mistaken) and entered my usual "buy abridged, big book". It failed on the dictionary, but it then bought the insult book from a mall store. Since I was in hardcore, this really didn't help me.
I freely admit that this could have been avoided with due diligence on my part. As for the use of "buy", I find it handy that I can put get both items with one command.
which looks like a feature request to enhance the "acquire" command, eh?
Bottom line is, "buy" does something different than "acquire". They are not interchangeable.
Theraze
Active member
Yes, it was with the 'buy' command, actually through EatDrink, which tries to be smarter about what it gets... but ended up blowing the meat because the beach wasn't unlocked yet. It now has the npc_price check in there so that it only tries to purchase if the store is officially available, but... if someone ends up pricing below npc price, we're potentially going to end up stuck.
darkcodelagsniper
Member
I assume eatdrink is using buy() instead of retrieve_item() because buy has an optional max price argument.
edit - oh hmm, except eatdrink isn't using a max price arg there anyway.
Compared to retrieve_item(), which is limited by autoBuyPriceLimit (default 20k).
With the "improvement" to KoL that allows purchases to be made from the mall in Ronin I want a way to disable such purchases unless I explicitly enable them (which I almost certainly never will do). I note KoLmafia's Clover Protection when enabled can prevent me from "spending" a clover. To the best of my knowledge there is no way for KoL or KoLmafia to spend closeted meat without uncloseting it (or giving permission for it to be uncloseted). So there is precedent to protect people like me from scripting or operator errors.
In this case my undesired acquisition of accordions seems to have occurred because ED used the two parameter form of buy, rather than the three parameter form or retrieve_item. (I'm a little unclear what acquire would have done). ED was not sufficiently paranoid to decide if it had tried to buy a non-pseudo item
and didn't find it in inventory then something had gone wrong and perhaps the purchase needed to be reconsidered.
I can think of many ways to reduce the chances of this happening including new preferences (allow purchases from Hagnk's) or expanding the meaning of existing ones (the "allowed to buy from mall preference is interpreted as false if character is in Ronin) but I think the core problem is just that the Game Changed but the subtle impact of that was bot realized by script writers. So while the community sorts out what should happen, I think I'm just going to grep through scripts I use and make sure they use the parameter version of buy and make local changes to my copies until the authors make the change.
In this case my undesired acquisition of accordions seems to have occurred because ED used the two parameter form of buy, rather than the three parameter form or retrieve_item. (I'm a little unclear what acquire would have done). ED was not sufficiently paranoid to decide if it had tried to buy a non-pseudo item
and didn't find it in inventory then something had gone wrong and perhaps the purchase needed to be reconsidered.I can think of many ways to reduce the chances of this happening including new preferences (allow purchases from Hagnk's) or expanding the meaning of existing ones (the "allowed to buy from mall preference is interpreted as false if character is in Ronin) but I think the core problem is just that the Game Changed but the subtle impact of that was bot realized by script writers. So while the community sorts out what should happen, I think I'm just going to grep through scripts I use and make sure they use the parameter version of buy and make local changes to my copies until the authors make the change.
I believe acquire / retrieve_item will only buy from the mall out of Ronin/Hardcore, so would have failed, as it couldn't access the Antique Shop.
I ask again: why is ED using buy? In particular, why is it buying an accordion? In even more particular, since it is trying to buy an antique accordion - which was introduced during the AT revamp, which was AFTER version 16.1 of KoLmafia was released, which enabled buying using storage Meat - why is it using a buy rather than retrieve_item?
I point you to this post on October 12 in which we discussed the implications of the "buy" command using Meat from storage.
It sure would have been nice if you had raised you concerns a month ago, when we were discussing it, rather than a month after the code was released which made it so.
I point you to this post on October 12 in which we discussed the implications of the "buy" command using Meat from storage.
It sure would have been nice if you had raised you concerns a month ago, when we were discussing it, rather than a month after the code was released which made it so.
That is correct - and is correct behavior.
Really. Why is ED using "buy" rather than retrieve_item?
Theraze
Active member
So that users who have disabled getting their ingredients from NPCs who tell the script to get accordions for them aren't stuck using the toy accordion.
I raised the suggestion of mafia acquiring the antique accordion in that thread, but automatic toy accordion acquisition was left as the only in-run acquisition. As such, it was left to scripts to acquire the actually useful level of accordion...
I raised the suggestion of mafia acquiring the antique accordion in that thread, but automatic toy accordion acquisition was left as the only in-run acquisition. As such, it was left to scripts to acquire the actually useful level of accordion...
So, you want something that will only use NPC stores, and will use them even when the user's settings say to not use them? If you think people using your script don't know what they are doing, then you could change that setting (temporarily even). If you think they do know what they are doing, then you should respect that setting and not worry about getting the accordion. Or you could go for some option that requires more user interaction.
Theraze
Active member
How about respecting it when I tell it to not actually be able to purchase the item?
Why would this get used? If I did buy(1, $item[fortune cookie], npc_price($item[fortune cookie])) and the fortune cookie store was unavailable, returning 0. Or in this case, buy(1, $item[antique accordion], npc_price($item[antique accordion])) wouldn't actually limit to the npc... it would only buy from npcs if they're available and have exactly the same problem otherwise.
If I tell it that I have a meat limit of 0, it should not be able to purchase the item. Always.
Why would this get used? If I did buy(1, $item[fortune cookie], npc_price($item[fortune cookie])) and the fortune cookie store was unavailable, returning 0. Or in this case, buy(1, $item[antique accordion], npc_price($item[antique accordion])) wouldn't actually limit to the npc... it would only buy from npcs if they're available and have exactly the same problem otherwise.
Using 0 there is currently the same as not including that third parameter. I don't know how easy it would be to change that without potentially messing with other scripts. Regardless, your goal is to purchase from an NPC shop when the user has said they don't want to use NPC shops, I don't know why that should be made easier.