Redeeming of multiple keys.

[Rudokhvist]

Well, you didn't liked my pool request, and current implementation is almost useless for this, so I'll just make this issue, because people keep asking me about this. So, we need some way to redeem multiple keys of the same game to multiple bots. And no, forwarding keys is not an answer, and never would be, because it leads to "too much activation attempts" fast. Neither me, nor people asking me about multi-redeeming, have no idea, why would someone need to activate multiple keys of different games on one bot in a bulk. Of course, thats not a big amount of people and can be not representative, so it's just FYI. But activating a keys from some massive giveaway (like indigala or gleam.io) to multiple bots is useful very often.

[JustArchi]

It leads to too many activation attempts because you decided to send unfinished pull request, which doesn't contain suggested by me mechanism that would tell if given bot already owns the game, or not.

Your previous pull request did not work regarding this either, moreover, it actually caused sending all bots given key, which would lead to too many activation attemps issue even faster than current (better) implementation. I can't see how it was better than current implementation, did you even check that code yourself?

I have no interest regarding this issue at the moment, so I'm putting it on hold. If you want, you can suggest a pull request that would improve the situation, if not, you can wait till I find enough motivation to do that myself, and I have more important things to do at the moment.

BTW, nobody here is paid to do anything, if you want a feature - you can either ask for it, or implement yourself. I'm always happy to accept all pull requests that make sense, and improve the program - if you don't agree with my opinion, you can always start your own fork with whatever features you find appropriate, as long as you won't break the license. If I don't consider something proper, you can either follow my suggestion how to make it so (I always state that), convince me that you're right (because nobody is perfect), or use your own implementation. But if you want to contribute to ASF project located here, you're (fortunately or not) supposed to follow some ASF guidelines set by me, which I don't consider bad, as thanks to them you're not digging in one giant pile of mess, but rather quite clear, easy to understand and properly maintained code, which is easy to enhance/improve.

[Rudokhvist]

No, it leads to too many activation attempts because you decided to rewrite it. My pull request never would lead to too many activation attempts unless you actually would drop invalid keys. There is no way to tell if bot already have the game without knowing what the game is, and there is no way to tell what the game is without trying to redeeming it first, so mentioned mechanism is simply impossible, and you know it. My previous pull request would send only one key to every bot, did you even look at it? If have no interest in it - I'm quite okay with that, I would just tell this to everyone who is interested. I don't have much bots, so personally me don't need this feature. And as for "nobody here is paid" - I did what you say, I ASK for it. I would never ask if it was only for me, but people keep asking me, so I just write here on their behalf. And, I implemented exactly what they needed, but you said you don't like it. And, if you mentioned that "nobody here is paid" - your demands for pull requests are much higher than on every work I had in my life, so maybe that's you who forget about it.

[JustArchi]

your demands for pull requests are much higher than on every work I had in my life, so maybe that's you who forget about it.

I don't ask for any pull requests, because I'm not the one who needs the function - you're asking for it in this issue, whether by your own or because somebody else asked you to. If I need something, or I consider something good enough to be implemented - I'm doing it. What you're suggesting here however, is a feature for plain, lazy pathetic abusers, who can't even bother to send key to proper bot. I don't consider it useful neither needed, because I don't bother with such people. However, I can understand a need for such feature, and that's why I suggest you to send pull request, instead of telling "I don't need it, sorry, issue closed"

There is no way to tell if bot already have the game without knowing what the game is, and there is no way to tell what the game is without trying to redeeming it first, so mentioned mechanism is simply impossible, and you know it.

Yes, and we can spend 1 request on knowing what game it is. After that one request, we exactly know which bots have that game, and which don't, so we're NOT failing with AlreadyOwned request even once (apart from initial one to discover game name) - we directly send the key to the bot that needs it, instead of current form which is similar, just assumes that every bot has no games. So we do not waste "slots" on doing something pointless (trying to redeem key on bot that already has it) - which in fact will result in close to none OnCooldown.

And, I implemented exactly what they needed, but you said you don't like it.

Multiple keys redeeming has totally different objective than what you imply. I might have keys from various bundles that I own already, and I might want to send all of them to given bot, so he can redeem them all in one message, instead of in 10 of them. That's what multiple keys redeeming is - writing 10 same messages with different keys in 1.

Forwarding keys also has other objective - it's supposed to redeem key "somewhere", and farm cards off it. In this scenario we don't care where it'll actually be redeemed, because we're too lazy to check which bot can potentially redeem it. What matters for us is that some bot will redeem it and farm it, which one - we don't care, we want cards.

What you want is changing multiple keys redeeming to one key per bot redeeming for lazy people that are too lazy to even send proper key to proper bot. In this case, surprise - ASF will still work, because bot 1 will return OnCooldown after 5th or 10th activation (can't remember), and STILL forward key to other bot. So the worst case will be that majority of bots after such multi-redeem will be OnCooldown for like what, 15, 30 minutes? It's fair price for being lazy I'd say, the effect will be the same.

[JustArchi]

And BTW, in neither of above posts I said that I don't want to see such feature implemented - most certainly you can add it, for example in new command such as !redeemsingle, which would accept keys separated by space, and redeem on all bots one-by-one. Just don't confuse general purpose of multiple keys redeeming, and keys forwarding, with feature for key abusers.

[Rudokhvist]

is a feature for plain, lazy pathetic abusers

You may not like it, but it's a major part of asf users. Calling users of your software pathetic is not really nice thing. Everyone who use multiple accounts to get cards is an "abuser" from this point of view.

Yes, and we can spend 1 request on knowing what game it is.

We need one request for every key. So it's in no way ONE request. And there is no way to tell if the keys are for the same game or another.

Multiple keys redeeming has totally different objective than what you imply. I might have keys from various bundles that I own already, and I might want to send all of them to given bot, so he can redeem them all in one message, instead of in 10 of them. That's what multiple keys redeeming is - writing 10 same messages with different keys in 1.

And noone, even you, don't need this feature. Because no bundle have a ready list of keys, so it would be much faster to copy&paste them one-by-one instead of making such list first (either by copying keys to some text file, or at least removing game titles), and then sending it to the bot. So, multiple keys redeeming that you made are simply useless, I can't imagine use case that would cover it. As for distributing keys between bots - well, as I already told you, many people that you called "lazy pathetic abusers" can find it useful. I have a bunch of text files with free keys sitting there, ready for this kind of redeeming. I had those lists long before ASF was created. Yes, sure, call me "lazy pathetic abuser" again. And, by the way, I bet you don't even thinked about any way of "multiple keys redeeming" before I told you people want it, and now you telling me what it should be. Sure, you always know best.

most certainly you can add it,

Sorry, I won't do this again. If you ever want - you can implement it. If you think your users are too lazy (and I wonder, why users of a bot would be lazy?) and don't deserve good things - it's fine too.

And, by the way, I never said forwarding keys is a bad idea. It's a very nice and useful feature, I just said that it don't covers this issue, because getting a lot of bots in "too many attempts" state is unacceptable.

[JustArchi]

Because no bundle have a ready list of keys, so it would be much faster to copy&paste them one-by-one instead of making such list first (either by copying keys to some text file, or at least removing game titles), and then sending it to the bot

Yep, and that's how it should work in the first place - you send key to the bot you want to redeem it on, multiple keys redeeming (on the same bot) is extra to the above, and forwarding keys (to other bots) is an extra as well. Redeeming keys in your given order can also be an extra to already implemented features, if somebody (including me), decides to implement it.

So, multiple keys redeeming that you made are simply useless, I can't imagine use case that would cover it.

I already pointed you example above, in case you missed it - I find it useful myself because I have many keys lying around and I can activate them all in one message, instead of sending a few. So yes, it's useful for me, and I'm glad you pointed it out, because I make use of it.

Everyone who use multiple accounts to get cards is an "abuser" from this point of view.

No, buying a bundle with games, and activating them on other account is not abuse, while asking for massive amount of free keys in fact is, because a site such as IG clearly states that one person should get only one key. Do not justify abusers by what is generally acceptable for you and your friends, because IG does not prohibit you from buying 10 bundles for yourself and your own use, while indeed it clearly states that asking 20 free keys is not proper.

If you think your users are too lazy (and I wonder, why users of a bot would be lazy?) and don't deserve good things - it's fine too.

I think that I don't feel inner urge to help key abusers by redeeming keys even faster than it's already possible. ASF is already a heaven for them, and with more and more features being implemented (most thanks to you, which is a good thing), it's plain easy and simple to redeem keys, even for those lazy people who are not willing to select proper bot for key redeeming, thanks to key forwarding feature.

Sorry, I won't do this again.

I'm not asking you to. Every user is able to leave valid request, but it's my choice in what order I'll keep up with my TODO list, and how much time I'm actually going to spend on given feature. You sent a pull request with nicely suggested feature, I merged it, but I should rather say "I took the idea and implemented it in my own way" (as you pointed out yourself), and now you point out that it's not what you wanted, which is also valid, and once again, same as I said in previous case - if you want to see it in ASF, you can either wait for me to do that, or implement it yourself. I'm sorry that I misunderstood what is the point of your pull request and rewrote the mechanism in the way I consider appropriate, but you could also specify exactly what is your objective in the first place. I didn't do that intentionally.

Calling users of your software pathetic is not really nice thing

If I invented a gun, and somebody killed someone using it, I shouldn't call the murderer pathetic because he used the gun I made? ASF is only a tool, and you're choosing how to use it. If you decide to be an abuser, it's your choice, but don't expect from non-abuser such as me to follow your ideology and agree with you, that's all. As a developer, I'm always trying to understand all users, even those I do not agree with, but it shouldn't be shocking for you that I don't consider suggested feature that important to spend my time on it when actually good features such as https://github.com/JustArchi/ArchiSteamFarm/issues/77 are also awaiting in the queue. I'd be a d*ck if I said that I don't like something and you should go away, instead, I say that I find the suggestion valid, even if I have no potential use of it.

Instead, you're saying that the feature that got implemented is useless, and you're more or less ranting about the fact how I hate your pull requests, which is totally not true, because every pull request needs to pass the same guidelines, which is - be well written, regardless of the feature that gets implemented, or who is going to use it. You're not an exception - https://github.com/JustArchi/ArchiSteamFarm/pull/6. If I find some mistakes or things that can be done better, I spot them and clearly give tips, if I have no major objections, I tend to merge pull request, even if it's not perfect - and fix it further if it's needed.

Again, as I said above, you don't have to agree with me, neither with the way how I decided to develop ASF, it's licensed under Apache license and you can start your own fork if you for any reason decide that you don't want to contribute to ASF. If you however decide to do contribute, including posting issues (not only pull requests), you should follow basic ASF guidelines, which are indeed set by me, because after all it's my project and I have the right to develop it however I want (which is not equal to being selfish neither "I know better" type of human, but more like using proper logic, code quality and practical use, which is crucial for open-source project such as this one, which again - you don't have to agree with).

[prorusnet]

Why do not you combine the fact that each of you wants? For example, to divide the "true / not true - taking each key bot"

[Rudokhvist]

I can't understand if @prorusnet suggested the same, but I keep thinking about distributing of keys between bots, and thought - would you agree if we make one more configurable parameter, that determines bot behavior with multiple keys? Something like DistributeKeys, if set to false (by default) - multiple keys redeeming works as it is now, if set to true - keys distributed between bots, one key to one bot. I could try to implement it when I would have some time, but I need your pre-approval for this idea.

[prorusnet]

I had in mind. Let the parameter determines how the keys will be distributed

[JustArchi]

It's OK, although we don't need to complicate our lifes that much. We can just add one bool into the bot, and switch that bool with a command such as !multibotsredeem, although if you think that config property would be better - I'm fine with that as well.

[Rudokhvist]

Well, I'd like to have both config property and a switch, that the reason I start to think about #83, because this in not the only one parameter that can be changed at runtime, and we would have just one command to change any of them.

[jbmccune]

I like where this feature is going, and thought I'd chime in with my two cents. I'll break it down into the two scenarios:

1) We have a bunch of keys for a single game. We want one key to go to each bot that doesn't have that game, with as few activation failures as possible. If we could tell the bot that it is this case by switching a flag dynamically just before dropping the keys, even in the same chat message as with "!samegame {key} {key} {key}" for example, then the functionality that JustArchi mentions above would also help a lot - where the first activation attempt for the first key would be spent to find out what the game is, and then no more attempts would be wasted on any of the keys because it would know which accounts don't have that game.

2) I have a bunch of keys for different games. We don't care which accounts get which games, we just want as many to be activated as possible, again with as few activation failures as possible. Again, JustArchi's suggested behavior above then makes a big difference, but to avoid a single account having all of the activation failures, it could rotate through the accounts any time an activation fails. If the key was AlreadyOwned on that account, it would now know the game and activate it on the next account that doesn't own it, then move on to the next key.

The only real difference between the two scenarios behavior-wise is that the first case can be a little more efficient because it doesn't have to test each key, avoiding some possible AlreadyOwned failures. Because the case 2 logic still works for case 1, but not the other way around, I would actually prefer to have the default behavior be case 2, and only have to specify a command along with the keys to indicate to the bot that it is case 1. I don't think that would be a big deal to anyone.

So I go in, drop a bunch of keys (prefixed with the command if it's case 1), and I get back a simple output indicating which keys were activated to which accounts, ordered by account/game ideally, and which keys were left unused (along with what game they were for). For errors, if they just landed in "unused" along with the last error encountered that would be good enough for me.

One other thought/question - can this work in a farming group chat as well, rather than only a private chat with one of the accounts?

[Rudokhvist]

Well, the only disadvantage I see in this is that checking of games bot already have can be very slow if bot have huge library, especially on slow pc or internet. But actually this only means that this feature should be configurable. Maybe you should've made a separate issue for this, so that Archi don't forget about this suggestion?

[jbmccune]

Well, I'm not sure what's possible via the API in that regard. Whether it could load and cache the entire library for each account one time, then do a quicker sync of changes at startup, or if it would be possible and faster to query each account for each specific game just before a known key activation is attempted, I can't say.

If library caching is used, I think it would be safe to assume that, while ASF is running, no games would be added to these accounts except through ASF - so there would be no need to sync the library with each key activation attempt, just once on each ASF startup.

I'd be happy to move this to a separate issue - I'm obviously new to the project, and unsure how Archi works. I saw that this one was still open and in development, so thought it best to add my thoughts here.

[Rudokhvist]

If library caching is used, I think it would be safe to assume that, while ASF is running, no games would be added to these accounts except through ASF - so there would be no need to sync the library with each key activation attempt, just once on each ASF startup.

I don't think so. So far ASF can't activate gifts by itself, so if user activate cheap gifts to bot for farming - it would be done manually.

[Rudokhvist]

Also, just checked what steamAPI offers - there is a way to check if account own certain appID without requesting all owned games, and probably this should be fast enough: http://api.steampowered.com/IPlayerService/GetOwnedGames/v0001/?key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&steamid=XXXXXXXXXXXXXXXXX&format=json&appids_filter[0]=XXX

[jbmccune]

Yeah, I thought about gifts, but for me they're pretty rare on these accounts so an ASF restart or a !refreshgamecache command wouldn't be a big deal. I guess that mileage can vary.

Anyways, with the API capability you found, I think that's pretty much a moot point - on-demand requests, maybe with a short-term cache to avoid repeating the same requests with a single bunch of keys, would seem to be ideal.

[JustArchi]

This is now fixed/done, thanks to @Ryzhehvost in #87