Bug - Fixed trying to use mall_price in a choice adventure stack overflow

[taltamir]

trying to use mall_price in a choice adventure has the following issues:

issue 1: it tries to navigate to the mall which encounters a choice adventure and thus immediately forces the choice adventure to process again. this causes a semi infinite loop (it eventually reaches stack overflow after ~700 iterations... and 700 server hits).
I am guessing that in a choice adventure that can be navigated away from it will lose the choice adventure instead.

>script gets called
>script tries to use mall_price() to try to determine if we should make a specific choice
>mall_price calls tries to navigate to the mall which calls the script again
repeat until stack overflow

issue 2:
when that choice adventure is set to anything other than "show in browser"
or if a script is called and handles it without the infinite loop of calling it again. then it will result in a value of -1 being set for that item's price for the rest of the day

mafia choiceAdventure### handling example:

> ash mall_price($item[imp unity ring])

Searching for "imp unity ring"...
Encounter: One Mahogany Nightstand
You acquire an item: old coin purse
Search complete.
Returned: -1

script handling problem 3 example:

> ash mall_price($item[shiny ring])

Searching for "shiny ring"...
Encounter: One Ornate Nightstand
Encounter: One Ornate Nightstand
[DEBUG] Running auto_choice_adv.ash
Submitting option 2 for choice 878
You gain 91 Magicalness
You can now equip a Mer-kin scholar mask (and possibly other things).
You gain a Mysticality point!
You gain a Level!
Search complete.
Returned: -1

In both cases it returned -1 which then sets the price for the rest of the day (as due to the anti abuse code for mall the price can only be set once per day.

I think the issues can be solved by having mall_price return historical_price when called inside a choice adventure.
Not sure what would happen if an item did not even have a historical price, would it try to look it up in such a case? in which case historical_price needs a check to see if in an NC and make sure to not try to do the lookup in such a case. probably something like

if(available_choice_options() contains 0 || available_choice_options() contains 1)    //we are in a choice adventure.

 

[lostcalpolydude]

20840 should fix this.

 

[fronobulax]

While it has an anti-abuse function, the decision to not check a price again after not finding an item in the Mall was also made to reduce server hits. Reducing the load on KoL's servers has been a guiding principle for the project from the very beginning.

Edit: The rest of my reply was OBE so I deleted it.

I will note that since we do not really prune historical_prices there are prices that are weeks old for items that are no longer in the mall.

 

[taltamir]

While it has an anti-abuse function, the decision to not check a price again after not finding an item in the Mall was also made to reduce server hits. Reducing the load on KoL's servers has been a guiding principle for the project from the very beginning.

Edit: The rest of my reply was OBE so I deleted it.

I will note that since we do not really prune historical_prices there are prices that are weeks old for items that are no longer in the mall.

While historical prices might be very out of date, isn't an out of date value still better than -1? items that are literally not available in the mall tend to be rare and ancient IOTMs that you will not be handling the purchase of via script anyways

 

[lostcalpolydude]

Don't worry, historical prices were not a consideration in my fix. I just made sure that if you're adventuring (in a fight or choice) there won't be any server hits when attempting to get a mall price.

 

[fronobulax]

While historical prices might be very out of date, isn't an out of date value still better than -1? items that are literally not available in the mall tend to be rare and ancient IOTMs that you will not be handling the purchase of via script anyways

My use case distinguished between items that were in the Mall and those that weren't. I discovered historical_prices gave me a price for something that was no longer in the mall and I would get frustrated trying to manually buy something so an out of date price gave me the wrong answer for my purposes.

My workaround has been to do a mall search for a historical price that is over 30 days. In some historical -1 cases I will also do the search to confirm unavailability.

But except for answering the question "is this item available in the mall now?" historical prices are perfectly adequate for me.

 

[taltamir]

I see now. Thank you.