ManageStore and CFStat - Weed out your store

fronobulax

fronobulax

Developer
Staff member
CFStat 1.0.2

ManageStore 1.1.1

CFStat is an attempt to make a utility and encapsulate it in a file. It defines a record (itemdata) and a function (salesVolume) that takes an item as input and returns an instance of the record. The record contains the average price and total sales volume for the item from ColdFront over the past seven days. It also contains a date string indicating when the data was fetched. salesVolume will cache data in a map file (CDdata.txt) so that ColdFront will only be queried once a day per item. It is packaged as a utility in case other scripters are interested in it. I'm pretty sure Destroy All Bacon wrote the code I started from although I'm not sure how much is left.

ManageStore looks at all the items in your store. It then offers the opportunity to autosell or sell on kBay all the items that are priced at the mall minimum, have a low (see below) sales volume or a ColdFront average price that is greater than the mall minimum.

Calling it as a script requires three parameters, SIM, VOL and useKbay. If SIM is true then it just reports items that fit the criteria. Otherwise it tries to get rid of them. VOL is an integer. If there are more items in the store than VOL times the sales volume for the past week, then the item will be disposed of. If useKbay is true then the items will be offered on kBay, otherwise they will be autosold. The kBay opening bid will be the number of items times the autosell value. Currently if the kBay opening is not at least 2500 meat then the auction will not occur.

After the routine initialize is called there is a map, myStore, that contains all of the items in a store. Since I could not find an ash primitive to do this scriptwriters might consider including ManageStore, calling initialize and then referencing the array.

1.0.0 11 APR 2012 - Initial release.
1.0.1 12 APR 2012 - ManageStore - Detect and report not enough to list on kBay when simulating. Make kBay threshold global in anticipation of conversion to zLib variable. Turns out script was grabbing mall price for everything and not using it. Don't do that since fetching mall prices is a time sink.
23 JUN 2016 - Bumped version numbers and converted to SVN for distribution. Fixed typo in CFStat versioning. In theory CFStat is a dependency of ManageStore now.
18 OCT 2018 - ManageStore will pulverize. See post on page 6 or thereabouts.

ManagedStore
Code: 
svn checkout https://svn.code.sf.net/p/kolmafiascripts/shop/code/

CFStat
Code: 
svn checkout https://svn.code.sf.net/p/kolmafiascripts/cfstat/code/
 

Attachments

Last edited:
Forgot to mention that parts of ManageStore were borrowed from Rinn with input from St. Doodle.

I hardwired the CFStat caching so it was only once a day. If this gets popular enough for ColdFront to notice then it can be made variable but otherwise it is too much fiddly code for no practical benefit.

The minimum bid threshold for kBay should eventually be a zLib variable.

There are a couple of similar scripts out there and Bale's OCD would do this better if it had access to ColdFront volumes and made decisions based on that. I can see a future where items that are disposed of by ManageStore also have an entry in the OCD file edited so eventually OCD could completely replace ManageStore.

ManageStore checks for store presence and the ability to interact but scripters who bypass main also bypass those checks.

Electing kBay over autosell is placing a bet. If you sell on kBay then you make at least zero and possibly more. If you fail to sell on kBay then you lose 100 meat, presuming you then autosell what kBay returned.

VOL is an attempt to give you a chance to sell at mall prices. Use 0 until you develop some intuition.
 
Fwoosh said:
Hmm. Just something I'd like to point out:

It auto-sold all my murky potions (I had 70 in the mall) because there was a bloke selling murky potions at the minimum selling price.

Does your script only consider the first price it comes across?
Click to expand...

It doesn't look at current mall prices at all. (It used to but the running time was excessive and it didn't change the behavior).

It will suggest an item be sold if all of the following are true:

It is priced at the mall minimum in your store.
The sales volume is low (discussed below).
The ColdFront historical price is less than or equal to your price.

This suggests to me that the bloke or blokes who were offering at minimum price were not selling very many at that price.

Part of my purpose was to get crap out of my store that clearly had not sold for several months and appeared unlikely to sell in the near future.

The script asks for a volume parameter. It multiplies what you have on hand by that number and compares it to the historical sales volume. If the parameter is zero then the script won't autosell unless the reported sales volume is zero.

Two possibilities - the script is not doing what I say it is in which case I would like to fix it, or it doesn't do something you would like, in which case it is worth discussing.

Thanks.
 
Wow. My very own thread. Have I become a pariah and don't even know it?

For the at least five people who will admit to running this and other interested parties...

My original intent for the UseKbay flag was to use Kbay if the price for the lot was high enough or otherwise autosell. As implemented if you are not simulating and useKbay is true then the only items that will be removed from your store are the ones that will be sold on Kbay. Thus I often run two non-simulation runs back to back - one using kbay and one not. I can imagine this being useful for someone who only wants to sell on Kbay and not autosell so maybe I don't want to fix it. Thoughts?

I have learned that you can only have 15 auctions active at a time on kBay. Web scraping to figure out how many active auctions a user has would not be too hard, I believe, and the script could be modified so that when it found items to send as the 15th auction, it stopped sending things. Thoughts?

I have found that I sometimes list something that did not sell in a recent, previous auction. I'm not sure exactly what to automatically do about that but I can web scrape to at least get item names from unsold auctions and have the script not kBay those if it otherwise would try. Thoughts?

Thanks.
 
This looks like a great script. I'd love to see things like 'smash' if it is smashable, and maybe a summary of what was (or could be in a SIM) done, (total autosale, total KBay...)

On the multi I tried this on, I apparently only have one thing that there was enough to offer on KBay (and why do I have 116 Taco shells?)
 
Converted to SVN Distribution.

ManagedStore
Code: 
svn checkout https://svn.code.sf.net/p/kolmafiascripts/shop/code/

CFStat
Code: 
svn checkout https://svn.code.sf.net/p/kolmafiascripts/cfstat/code/

Am open to suggestions as to further development. Option to do something besides autosell or kBay noted as a possibility.
 
fronobulax said:
23 JUN 2016 - Bumped version numbers and converted to SVN for distribution. Fixed typo in CFStat versioning. In theory CFStat is a dependency of ManageStore now.
Click to expand...

Going to try these out, sounds like something that would work well for me. But more importantly- please share your time travel secrets with us!!!
 
Thanks Frono, works as advertised! Since I don't really manage my store much, I just load it up with OCD (Thanks Bale!) at the end of every run, and let it slowly earn me a few meat. This will reverse the process, unstock the not likely to sell stuff from the store and just convert it to meat directly. Hopefully a combination of these two fine scripts will enable me to earn a few more meat than before.
 
You are welcome. FWIW, I selected this as my pilot for hosting via SVN because there are at least 25 people who ran it once. Making it my most popular script.

I use it in conjunction with OCD as well. It is easier to manage OCD by dumping to the mall but when stuff sits in the store for months, unsold, that is not the best solution.

It occurs to me that it might be interesting to add an option to work with OCD. If the user actually autosells anything with ManageStore then perhaps the item should be checked in OCD's data and it it is marked as mall, mark it as autosell instead. That would eventually keep OCD from loading the store with things that ManageStore will autosell weeks later.

I'm also thinking of an option where something that can be pulverized to something "interesting" just gets pulled into inventory and not autosold. That at least lets the user manually pulverize. I confess I need to research pulverize options, mechanics and results before I can flesh this out.
 
Something like the get_related function?
> ash get_related($item[scholar mask], "pulverize")

Returned: aggregate int [item]
cold wad => 990000
glacial sapphire => 10000
sleaze wad => 990000
tawdry amethyst => 10000
twinkly wad => 1000000
Click to expand...

Something like:
boolean keepitem = false;
foreach ite in get_related(it, "pulverize") {
if ($items[nifty item list] contains ite) keepitem = true;
}
if (keepitem) <override autosell>;
 
fronobulax said:
I'm also thinking of an option where something that can be pulverized to something "interesting" just gets pulled into inventory and not autosold. That at least lets the user manually pulverize. I confess I need to research pulverize options, mechanics and results before I can flesh this out.
Click to expand...

Maybe the script could use PriceAdvisor to find those things that should be pulverized instead of autosold? I've wanted to find some way of automatically using PriceAdvisor to set up my OCD data file, but I don't understand ash scripting well enough to write it.
 
There is a PAtoOCD-script floating around. I'm not sure if itäs up to date with the OCD data file structure though, it's been a while since I used it...
 

Attachments

Started using ManageStore today - very helpful, thank you.

As for PriceAdvisor, I can't get it to run lately. SmashLib just barfs up an error... err, wait, it started working. Weird.
 
PAtoOCD sort of works. Using it makes you unable to use the relay to update OCD in the future, but everything processes properly.
 
Why? It seems to work for me, but granted I did the transfer a looooong time ago. I don't use OCD actively any more isnce there are way too many things in my invengtory ot categorize...
 
At some point Bale changed one of the fields to be different. PAtoOCD still has the old... whatever. Nobody's spent the work to figure out what makes it break, but it doesn't pass the relay validation and all the pages of stuff end up blank. As I said, it does work, but...
 
Theraze said:
At some point Bale changed one of the fields to be different. PAtoOCD still has the old... whatever. Nobody's spent the work to figure out what makes it break, but it doesn't pass the relay validation and all the pages of stuff end up blank. As I said, it does work, but...
Click to expand...

For what it's worth, I used the attached file today for my multi and it worked just fine. I had to go through and poke at some of the things but other than that it worked fine and the relay-script worked fine as well.
 
You must log in or register to reply here.
Back
Top