Feature - Implemented Preference (opt-in) to automatically update prices on login/logout

zarqon

Well-known member
I would be quite happy if there were a preference (off by default) which, if checked, would automatically perform

update prices http://zachbardon.com/mafiatools/updateprices.php?action=getmap

on login, and

spade prices http://zachbardon.com/mafiatools/updateprices.php

on logout.

Ideally, users everywhere would add these commands to their login/logout scripts, but that is a highly unreasonable expectation. Bale has a mostly functional workaround in his recovery script which handles this, but it's not quite as optimal as this solution would be.

Perhaps the biggest argument in its favor is that the overall effect would be many server hits saved, since more people would have more recent prices -- especially people using things like networth.ash and priceadvisor.ash.
 
Last edited:

Raven434

Member
/signed

I think this would be very cool. The new forum doesn't seem to have a 'yay' or 'nay' radio button.

Or... I missed it.
 

fronobulax

Developer
Staff member
I would add those to my processing, "for the good of the community" although I would have to start using login/out scripts first ;) However, as a general philosophy I am concerned about accessing a non-game URL in some kind of institutionalized or "supported" setting. That is just a paranoia thing based upon unpleasant experiences debugging user problems that ultimately were due to a third party web site deciding to no longer honor the service level agreements that my code depended upon. The first time we receive a bug report caused by http://zachbardon.com being down or unavailable is the moment I would regret implementing the feature, even as an Opt-In.
 

Winterbay

Active member
I agree and think that if such a feature/setting would be implemented and the website fails to respond it should exit with perhaps only a small notice and not just abort. This will at least minmize the problems such timeouts could cause in an unsuspecting audience...
 
On the one hand, this would be fabulous. (I'd also really like to be able to spade up more than once per day, say if I'd "discovered" more than x new prices; currently the spade in my logout script often doesn't fire because some other script has called it first.) On the other hand, fronobulax has a really good point. On a third hand, I don't really have any ideas how to reconcile the first two hands.

The PriceAdvisor main post does advise people to include these in login and logout scripts, but I have my doubts about how many people read down that far or know what the heck I'm talking about when they do.
 

zarqon

Well-known member
I don't see a problem. If the server is down for some reason, it will not overwrite prices, it will just fail to change anything. This is not a bug, and depending on what feedback was given it would not be seen as one since people may not even know that the server failed to respond. I'd recommend clearly indicating what's happening, i.e. printing "Updating mall prices from Zarqon's server..." before attempting the update. Then if there's a delay waiting for a nonresponsive server to timeout, users would know why and not blame mafia.

Secondly, KoLmafia has a history of participating in third-party sites for the good of the community. There was an option to participate in Oxbarn's lucre-something-or-other. Then there was whatever motivated the original CLI "spade" command. Both of these were opt-in, but dealt with third-party connections.

Thirdly, a large number of script users are ALREADY using my server.

But the main reason it belongs in preferences is that your average fairly technical-minded user will at least peruse the preferences of any new program -- whereas they will not search the forums looking for how to do something they don't even know can be done. Long before they even knew how to use login/logout scripts, and more optimally than priceAdvisor or UR do it, they could be saving KoL server hits by operating with optimally updated mall prices.
 

Veracity

Developer
Staff member
The original "spade" command was for Jason to personally spade the Wine Cellar to test his Wine Cellar decorator.

I'm sort of "meh" about this. The only reason you need "optimally updated mall prices" is if you are running a script which calls historical_price(). The large majority of KoLmafia users probably do not do so. I'm hesitant to add something that a "technical-minded user" will turn on which will not benefit her but will, in fact, slow her down, since it makes HTML requests to a non-KoL server.
 

zarqon

Well-known member
That would be two extra-KoL hits per session. It would be easy to add "(only participate if you run scripts that consult mall prices)" to discourage curious users from being needlessly slowed.

Contrariwise, imagine if one user runs networth.ash with outdated prices -- that could easily result in hundreds of KoL server hits.

Later that day, another user calls networth. If she had updated prices submitted from the previous user's session, that's already hundreds of KoL server hits saved. For just one user.

I should also mention that BatMan will be calculating the value of every monster as part of its calculations. Since it's in combat, it will need to rely exclusively on historical_price(). The more accurate these prices, the more accurate BatMan's combat decisions.
 

fronobulax

Developer
Staff member
I don't see a problem.
Perhaps I misunderstood the proposed feature. I stand by my concerns if it is a preference that, when opted in, has a mafia user who is not otherwise using scripts, access the "third party" server. If it is an opt in feature that only gets executed if the user opts in and is already running scripts then I agree that my concerns are inconsequential and I would support it. That said, however, why not address the issue by publishing the additions to the login and logoff scripts rather than elevate it to a feature request?

Nevertheless, I feel very much as if I am trying to stand on a vaguely defined principle that does not support the weight of my argument. Kolmafia, without scripts, still accesses SourceForge and there are several links to external sites that are implicitly opted in to when the user makes a selection. I can't really offer a rational reason why the line against third party servers has to be drawn here and now. ;)
 

Veracity

Developer
Staff member
Why not address the issue by publishing the additions to the login and logoff scripts rather than elevate it to a feature request?
Why not, indeed? If a script calls historical_price(), the thread announcing it could tell the person considering using it that their performance might be better - the first time they run the script - if they connect to your server on login - and that they can help other users of your script if they connect on logout. I say "might" since we update the historical prices every time we spin a release, which means that the prices in 14.0 are still pretty fresh.
 
Rather like this?
If you use PriceAdvisor extensively, I encourage you to add the lines
cli_execute("update prices http://zachbardon.com/mafiatools/updateprices.php?action=getmap");
cli_execute("update prices http://nixietube.info/mallprices.txt");

to your breakfast/login script to use shared price data, and the line
cli_execute("spade prices http://zachbardon.com/mafiatools/updateprices.php");
to your pajamas/logout script to share gathered price data.

The thing is, I presume that a large part of the audience for scripts like PriceAdvisor and networth and even perhaps BatMan are not terribly savvy Mafia users. They asked on some forum or other "Hey, wasn't there a script that told me how much stuff was worth?" and were directed to one of our scripts. They don't already have login and logout scripts and wouldn't know how to put them together. Or I could be miscategorizing the user base of my script entirely -- it's not as if I've actually collected any data, so this is pure speculation.

I guess I could provide login and logout scripts that just do the spading stuff for just such people. Anyone savvy enough to already have their own login/logout scripts is savvy enough to make the alterations.

more optimally than priceAdvisor or UR do it

It is precisely because updating and spading prices on a per-use basis would be horribly suboptimal for PA (as it would only spade up a few prices per use, rather than the whole lot that could be spaded up if you spaded up after a bunch of uses) that PA does not update or spade prices itself and instead includes the above mention in its main post.
 

jasonharper

Developer
historical_price() isn't just used by scripts! The same data is being used internally in several places:
* When deciding between buying or creating an item, to estimate the value of a bartender or chef use.
* To decide which of a pair of interchangeable ingredients to use in a recipe, when you have neither one on hand (or otherwise have equal amounts of both).
* In the Modifier Maximizer, when requesting mall prices for items, to filter out items that are clearly out of your price range.
* In the Basement helper, when mall prices are shown - historical prices are used if they're less than a week old.
And there are various other places where historical prices could or should be used - for example, if the Item Manager food/drink panels ever got the option to rank purchasable items along with the ones you have or can create.

That said, I also feel vaguely uncomfortable with the idea of tying this feature to a specific 3rd-party server.
 

Veracity

Developer
Staff member
I also feel uncomfortable pointing to specific 3rd-party "unofficial" servers. No offense, zarqon, but I'd feel better about this if fewyn were hosting your mallprices updater here on kolmafia.us.

That said, I looked at other "unofficial" things that we (seemingly) endorse, and I see, for example, that we give you a link to Aprocolypse's "Intro to KoLmafia" - but not to SinginSally's intro - nor to the KoLmafia Wiki. Not to mention, some of the "official" pages we link to on sourceforge (which, zarquon, you can HARDLY point to as if it is some random "3rd party" link) are pretty out-of-date.

This could all stand some looking at.
 

zarqon

Well-known member
No offense taken. I would be happy to send the PHP script to fewyn. He could contain it in its own subdir if he likes. Although I actually can't understand why the location is an issue (it makes no difference functionally); price accuracy and saving server hits is the priority here. And FWIW, my server has been down less than kolmafia.us has, but I suppose I see a certain reasonableness to centralization.

I suppose centralization is the reason I'm making this feature request in the first place. Why not just instruct people about login/logout scripts? Because it would need to be in every thread of every script that uses historical_price(), and if it changes, that's a lot of threads that need to be updated, and by various authors with various levels of attentiveness. As a programmer, we avoid repeating blocks of code all over the place -- we use loops and functions and libraries to make it so that the code can exist in just one place. In this case, it's far more efficient (and less error-prone) to centralize this in a single preference.

The necessity for login/logout scripts to optimize pricing also makes using mafia/scripts more difficult for non-savvy users. They already have to install support libraries, learn how to edit in-script variables or ZLib settings or mafia properties... learning how to use and edit login/logout scripts would be just another thing making people less likely to want to use scripts. While it's clear that mafia users need to be prepared to do some learning and research, there's no reason to make it harder than it needs to be. Clicking a preference makes price optimization far more accessible -- and perhaps more importantly, visible.
 

StDoodle

Minion
That said, I looked at other "unofficial" things that we (seemingly) endorse, and I see, for example, that we give you a link to Aprocolypse's "Intro to KoLmafia" - but not to SinginSally's intro - nor to the KoLmafia Wiki. Not to mention, some of the "official" pages we link to on sourceforge (which, zarquon, you can HARDLY point to as if it is some random "3rd party" link) are pretty out-of-date.

This could all stand some looking at.

Yes indeed, it would be appreciated. One of the main reasons I lobbied to get a version of Sally's guide on the wiki was so that there could be one central place to point to for such information. If, say, another year down the road, enough changes are made to warrant a re-write of the guide, it could be done on the wiki, using the pages already set-up when possible. There are quite a few additional things I'd like to add to the wiki, notably a FAQ (how do I auto-re-use breakable equipment? how do I set my preferred browser? etc.). As of now, the main post on KoL's GD doesn't mention the wiki, and I think it could be quite helpful (and possibly cut down a little on repeat questions) if it did.

Please feel free to let me know (PM or in the wiki thread, probably) if any other big "should-have" stuff is on your mind.
 

fronobulax

Developer
Staff member
Since we have moved to a kind of meta-level discussion, I agree that there are a collection of web sites that Kolmafia could "implicitly" endorse by referencing them in the core functionality. Right now I would say that list should include: the game itself (duh), SourceForge, the KoL Wiki and this site. I would furthermore suggest that reducing server hits on the game site, at the cost of increasing hits on one of the other "endorsed" sites should be deemed A Good Thing, provided that the operators of the endorsed sites have no problems with the increased traffic. References to other sites from the core should be on a case by case basis and always on an Opt In basis by the user. The buff bot prices are an obvious example of this. I would consider whether the Kol Simulator, Subjunctive KoL are even useful anymore, but the other external links do appear to be Opt In.

Thus, back to the original suggestion, I would be comfortable with an Opt In option to fetch and update price information hosted at kolmafia.us embedded in the core code (rather than externally in a script). I would also advocate an "endorsed" link to SinginSally's guide and probably the wiki here as well.
 

zarqon

Well-known member
I've sent the script to fewyn just now, along with brief installation instructions.

You do realize that I will no longer have access to this script and will be unable to support it should anything break it, right? I still don't get why domain name matters for this, but I'm willing to play along if it will quell objections. This is too good a feature to be picky about.

If this gets running at kolmafia.us, I'll also be deleting the one on my server, which may cause older scripts to break. Fortunately, I don't think there are too many scripts that use these commands -- not published ones, at least.

EDIT: And we all know that the author of the biggest one is QUITE attentive.
 
Last edited:

fronobulax

Developer
Staff member
You do realize that I will no longer have access to this script and will be unable to support it should anything break it, right? I still don't get why domain name matters for this, but I'm willing to play along if it will quell objections.
I am presuming that (you) zarqon will support the script anywhere it is running. If that is not the case then I would withdraw my endorsement until the community figures out how to support the feature. That could include any number of things such as teaching fewyn php, including the script in the mafia code base or recruiting someone to manage it here and having fewyn delegate as much authority and privilege as is needed. You, perhaps inadvertently, raise a point we have so far missed which is, regardless of where it is hosted, how is the code maintained and supported if or when the functionality becomes part of the core? In some sense the feature request is new ground for core mafia because the development responsibilities go beyond maintaining code and now include hosting one script and the associated data.

As for the difference a domain name makes I agree it is somewhat silly but I personally have a level of experience and trust with kolmafia.us that I do not have with zachbardon.com. That is pretty much the driver for me. It is nothing personal and reflects more on my experience than you. I recall when Daychilde started the site, watched the transition to fewyn from afar and lurked for months before I finally realized the the bug reports and feature requests that I was interested had finally consolidated here rather than being scattered at SourceForge, the main KoL fora and Veracity's developer site. On the other hand, I had never heard of zarqon, and by extension http://zachbardon.com/ until I actually realized some of my KoL concerns were best addressed by scripting and not by Java code in the source tree or a private branch thereof.

So I freely admit that the domain name issue is a preference and not necessarily anything I could defend rationally. I hope my comments and observations have not caused offense.
 

Bale

Minion
EDIT: And we all know that the author of the biggest one is QUITE attentive.

I've heard that. ;)

It'd also cause trouble for dj_d's make.meat.fast and he's somewhat reluctant to update.


That could include any number of things such as teaching fewyn php

I believe that he knows php. It is mostly time that is lacking for him.
 
Last edited:
Top