JustArchi
commented
11 months ago We could play it smartly and code less number of tries if risky cards discovery is enabled, 2 seems alright. Making it configurable is too much work for too little gain, rather we should agree on just a solution that works for everybody.
1 request is required as we don't want ever to use the alternative method even if configured, if we can skip over it. 2 requests is good middle ground in case servers temporarily have an issue, which also makes sense to me. Something more is probably not needed/wanted, therefore solution I can agree with would be just to use 2 tries instead of 5 if risky cards discovery prop is enabled - to fight with users that enabled it despite our warnings not to if they don't need it, while skipping a few pointless requests for those that do need it.
Checklist
Enhancement purpose
The risky cards discovery as suggested in #3017 (and activated by setting EnableRiskyCardsDiscovery to true) works but has drawbacks described in detail below.
I therefore suggest to make the number of times badge overview pages to be loaded configurable. This would allow users to use a lower number of retries (e.g. 2 instead of 5) or even skip loading badge overview pages completely and start with loading booster eligibility directly.
Solution
Main Improvement: Introduce an additional setting into Bot Configuration that allows users to configure the number of load attempts for badge overview pages. There should be a strict application-side cap to this number that cannot be modified by users to prevent users from spamming servers with a huge number of computationally expensive and unreasonable requests.
Example: If the user configures the number of load attempts to be 1000 then the number of attempts is 5 for EnableRiskyCardsDiscovery=false and 2 for EnableRiskyCardsDiscovery=true. If the user configures a value of 1 then only 1 badge overview request is issued. If the user configures it to 0 then loading badge overview pages is skipped completely and fallback solution is applied immediately by loading booster creator page.
Further Improvement (optional): Once the number of attempts to load badge overview pages is set to a lower value, there should be room for a second load attempt of booster creator page after a short break in case the first one fails. This would prevent ASF to stop farming cards for a longer time in cases where loading booster creator pages failed due to a bad Internet connection.
Why currently available solutions are not sufficient?
For the reasons explained in #3017 creating badge overview pages is computationally expensive for servers for accounts with big inventories and has a very high likelihood to fail. ASF always tries to load badge overview pages for 5 times in a row although for accounts with sufficiently large inventories it is pretty clear upfront that this cannot work out. It never works for such accounts when trying to load those pages in a browser / the Steam Client. Why would it work when using ASF? At a certain inventory size, issuing more requests will only increase server load with no real chance of success.
In some rare cases loading booster creator page will fail after having done those 5 unsuccessful badge overview pages requests. ASF notices this correctly and retries card discovery much later. I once tried to load booster creator page in a browser directly after this had happened. This did not work either despite of several retries. I have never seen this before and therefore think this might be intentional server behavior, maybe caused by the 5 preceding unsuccessful badge overview requests. This seems to be only temporary though. Retrying to load booster creator page much later worked again.
In addition, risky cards discovery usually will discover fewer games than standard cards discovery. Therefore it has to be repeated far more often (including those 5 unsuccessful badge overview pages requests in every loop). Sometimes risky cards discovery stops after finding one game. Once this game has been farmed, say after 4 hours, cards discovery needs to be repeated which will lead to 5 more unsuccessful badge overview requests and so on. The frequency in which badge overview pages need to be queried is therefore much higher under risky cards discovery than under standard cards discovery. Also accounts with big inventories will typically be the main user group for risky cards discovery. So requests will not only be made more frequently but also be computationally more expensive due to this special user group.
For the above reasons, I think the current solution has the unintended side-effect of increasing badge overview requests to Steam servers for a user group where those requests are computationally expensive and there is very low chance of success. I therefore suggest to allow users to set the number of load attempts of badge overview pages to a lower value (at least under EnableRiskyCardsDiscovery=true) or skip loading these pages completely. In my opinion 2 load attempts under EnableRiskyCardsDiscovery=true should be enough. Two empty results in a row would usually indicate that constructing this page is not so easy for servers so maybe resorting to the fallback solution is the better (although slower) option.
Can you help us with this enhancement idea?
Somehow, I can test and offer feedback, but can't code
Additional info
No response