Archisteamfarm: Exclude an account from key forwarding

Created on 18 Oct 2016  路  6Comments  路  Source: JustArchiNET/ArchiSteamFarm

_First of all thanks a lot for ASF. It's been a lifesaver if only for the key redeeming feature._

As I buy bundles I end up with "trash" games along with the good ones. I've started redeeming them on my secondary account, but those games keep getting bundled (for some reason :P ) and so I opened a third account, and so on.

So I want to enable the key forwarding feature to avoid micro-managing which game has been redeemed on which account. The only issue is that I don't want those trash games on my main account, but I do have a bot enabled on it since I have a big backlog of games yet to farm. Is there a way to exclude this bot from key forwarding, and if not, could it be added?

Thanks!

Already possible Enhancement Not going to happen

Most helpful comment

Thanks! I tested _!redeem& [main account] [key]_ and it successfully redeemed it on the next bot on the alphabetical order. So at first glance things look good. I noticed that we don't even have to change the forwarding settings in the config for this to work, which is very nice.

Sorry for pushing for even more complexity in that function with my feature request. Software always seems to escape the scope it was originally in isn't it :P .

All 6 comments

As per the wiki:

This option serves the purpose of "I have key X, I want to farm cards off it, and it doesn't matter for me on which bot the key will be redeemed".

This is important - implementing a mechanism that will allow you to choose which bots are being considered for forwarding defeats the whole purpose of this option to exist, because the whole point is to drop a key and don't bother with where it lands. So no, I don't see any real need of such feature to exist, but ASF offers you several workarounds that are possible to achieve the result you want:

Firstly:

The actual redeeming order is alphabetical according to names of the bots.

Which makes it possible for you to set your main account as _main.json or similar in order to put it last on the list. This way all other accounts will get the game firstly, but your main will still get the key if all other bots already own it. So it helps, but not entirely.

The second workaround, and the one that truly addresses this issue is executing !stop main or whatever you called your main bot account - instance that is stopped is temporarily excluded from keys forwarding (logically, it's not connected), so this way you can temporarily shut down given account, redeem your keys, and turn it back on.

Both workarounds have their usages, and I'd personally stick with first option, unless you have a strong reason against it and still want total exclude that is possible with second one.

Thanks for the reply. The alphabetical order thingie is clever but doesn't help, I really don't wanna pollute my main account even occasionally.

Stopping the main account is indeed a good workaround. The issue is that knowing myself I'll eventually forget to turn it off. Also I'm using this tool to speed up key activation, so adding one more step I'll need to use almost every time I buy a bundle rubs my command line sensibilities the wrong way.

Are you opposed to the feature existing at all, i.e. if I were to submit a pull request for this would you reject it? It would be pretty simple, i.e. one extra boolean option in config, one wiki edit to explain it, and what it does is forward the key without trying to redeem it if the option is on for the bot.

i.e. one extra boolean option in config

Exactly, one extra boolean that is not really needed for 99.9% of the people. I'm more interested in !redeem& command or likewise, which would simply force forwarding excluding the bot that initiated the redeem. I think I can add it myself.

Feel free to test https://github.com/JustArchi/ArchiSteamFarm/releases/tag/2.1.6.0 - I gave it a brief look and it seems to work properly, but the whole redeem function got so complicated that I'm slowly stopping understanding it, which is not a good sign 馃槅 . Hopefully there are no bugs and it works as it should.

Thanks! I tested _!redeem& [main account] [key]_ and it successfully redeemed it on the next bot on the alphabetical order. So at first glance things look good. I noticed that we don't even have to change the forwarding settings in the config for this to work, which is very nice.

Sorry for pushing for even more complexity in that function with my feature request. Software always seems to escape the scope it was originally in isn't it :P .

the whole point is to drop a key and don't bother with where it lands. So no, I don't see any real need of such feature to exist

Vice versa - I see really big and real reason for such feature to exist. In short - it will help keep system fully automatic. Self operational machine. Damned Terminator T-1000.

I have few "bot" accounts and I really enjoy smooth and fully automatic work of whole system: drop key to chat, don't bother, cards magically appears in "main" account. Automagically!

Obviously "main" account also uses ASF but in a different way: offline farm (for precious and good games instead of thrash which throws to bot-accounts). But the main reasons for main account is automatic trading "AcceptDonations" (which is one of the steps of card farming automation) and batch authenticator confirmations "!2faok" (which actually I not tested yet, but i believe it will help me to accept all those painful hundreds of card selling requests in one command).

Yes, its nice tiny option with "&" key in redeem function, but it is extra symbols which I should always use. Its not that "automagic" I love in ASF.

Also... why that feature should be implemented as extra option? There is no reason for it since configuration already have "RedeemingPreferences" flags. So another one flag "DoNotAcceptKeys" would be 100% logical here.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

undefo picture undefo  路  4Comments

guihkx picture guihkx  路  4Comments

KazeZlat picture KazeZlat  路  4Comments

tambry picture tambry  路  4Comments

Gilrain picture Gilrain  路  3Comments