Zecious Babaloni and jasonharper save the day!
This would be a perfect example of a time when it would be awesome if
file_to_map() worked with URLs. (Kind of like a public
update command.) Centralized data files would be super easy to access in scripts... it would even enable automatic updates for script data files... or perhaps I'm just dreaming.
I had a bit of discussion with Zecious and he is working on a script to generate another data file, which will probably be called average.txt, which will contain the average price for each item over the last 7 days. Which will unfortunately negate a lot of your work with parsing export.txt into a big map, dj_d.
In the meantime, I changed just a few lines so now it gets data from today.txt. It still caches this data, so it will only hit the ofloathing server once per day max. I also changed the order of things so that if the ofloathing value checks out, it won't bother with the wiki, which makes it the fastest, most server-friendly version of this script to date. Enjoy this until Zecious gets average.txt up, at which point only a few tiny edits will need to be made to move over.
@asturia: Sorry, I had already changed the name of
price() to
get_value() in my script before I wrote about your solution. Try it using this one and it should work. ps - it's Zarqon with a Q.
@jason: Thanks a bunch! I know I am one of many who appreciates your instant attention to user requests. This will be a genuinely useful feature. Once this appears in the daily builds, I'll be able to save even more server hits with some of my scripts.
I also understand your position on mall_price(). It has been a longstanding policy, as well as a longstanding request by those who didn't yet know the policy. The policy exists for good reason: just because something is created in a certain spirit, it does not follow that everyone will use it in that same spirit. Which is why proper safeguards must be in place. Previously, to my knowledge no one has requested mall price access with a suitable safeguard in mind. But I do think that a per-item time limit on price requests (per day or per session), using the cached value after that, is a suitable safeguard against the kind of abuse that Hola and Veracity want to prevent.
I can only think of two ways to bypass this safeguard, here made public along with ideas on prevention:
- [li]1) The obvious way would be to reset mafia's external price/date cache (assuming this data is stored in a file), the easiest method of which would be deleting the file. Of course, doing that would require something outside mafia, which is no different from the way things are now. Still, if a user could simply delete a file, run a script, delete the file, run a script, etc. (or make an external script to do that) that's too easy to abuse.
Solutions:
- [li]Store the price/date values as part of the application file. Not sure if that is easily doable in Java. I also don't think it's the best solution.[/li]
[li]Instead of limiting mall requests to one per item per day, limit it to one per item per session. Then the pricing cache could be kept internally. Getting more than one current price a day would require restarting mafia. I think this is an excellent solution.[/li]
[li]If this external data were added to GLOBAL_prefs.txt or some other file that people need, normal users would be loathe to delete it, and editing it would take more time than just visiting the mall manually. Editing the data could also be made very difficult by encrypting it (probably some kind of hash of price and date together).[/li]
[li]If you are storing the data externally, I think this is the best solution. The price/date data is stored in a separate file (encrypted to prevent editing). If mafia is run without that data file, the file is created but an internal "pricedisallowed" flag is set for that session and mall_price() will abort with an error explaining the need to restart. If the file is deleted while mafia is running, the flag will also be set. Only after restarting mafia could you then use the function, and if you deleted the file while mafia was running, you'd have to restart twice. This would only affect normal users once, if at all -- they would have to call mall_price() their first time running mafia to encounter the error.[/li]
[/li]
[li]2) The other method involves running many separate instances of mafia, since each one gets one price per day. For this to work would require many dummy KoL accounts with mall access, and a complex script running on all machines that communicates pricing info to one master account that serves as the mallbot. Hugely impractical, expecially in light of the fact that if you have enough meat you can already make a mallbot of sorts using the closet trick.
Solutions: none needed, doing this would be ridiculous. It's about as easy to learn Java and write your own mallbot.[/li]
Intended behavior: mall_price() would check to see if the value is cached (or in memory) and has not expired. If the value is found, it returns that value, otherwise it returns the current minimum mall price (storing it in the cache/memory). This stored value would be used for every future call of mall_search() until 1) the cached value expired (one day), or 2) the value was no longer in memory (next session). This would have the effect of allowing only one server hit per item per day (or session), and would not enable manipulation of mall prices.
Furthermore, the script we have made here already makes once-daily item prices available. Adding this function to ASH would only make those prices more accurate, because the pricing would happen at the exact time of calling the function (the first time, which is all any script should really need).
What do you think, Hola, Ver, jason? Do I make a convincing argument?
