Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion of a better way to calculate prices #156

Open
rts7 opened this issue Jun 26, 2021 · 1 comment
Open

Suggestion of a better way to calculate prices #156

rts7 opened this issue Jun 26, 2021 · 1 comment

Comments

@rts7
Copy link

rts7 commented Jun 26, 2021

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants