Suggestion of a better way to calculate prices

[rts7]

Probably because of what I usually sell, this script does not use price history, but the listingPrice way, which seems really unreliable.

Instead of using the quantity of items for changing the listingPrice have you considered using the stat that lists how many items of this type were sold during the last 24 hours? This stat is available at the inventory page or returned at the PriceHistory. I was thinking that it can start counting how many listings are available for the lower price, then move upwards until the sum of the items available is greater than the number of that stat. For example if 80 items were sold in the last 24 hours and there are 2 items available for 0.11, 4 for 0.12, 40 for 0.13 and 60 for 0.14, then it should be listed for 0.14 or (worse I believe) for 0.13, perhaps by having an option of "before this number is surpassed" or "after", something like "patient" or "in a hurry" option. Currently, it would be listed for 0.12 which is terrible.

I feel that it is something very easy to implement and will greatly improve functionality. I really tried to learn javascript to do it on my own but I don't even know how to start. Still, thanks a lot for all this work with the script.

[woctezuma]

True. However:

1. these sales can happen at the ask... or at the bid, so it is not necessarily optimal to count sales and choose your spot in the queue of selling orders in this exact manner.
2. the scope and complexity of the browser add-on should be kept minimal, especially as it sometimes encounter some issues, because Javascript and in-browser tools are not best suited for every purpose,
3. I believe a Python tool such as https://github.com/bukson/steampy#market-methods is better suited for more complex price computations.