Closed Revadike closed 8 years ago
Keeping used keys in memory is a waste of memory, you're supposed to make sure to provide valid keys, it's not ASF job to test if perhaps master lost his mind and is trying to redeem the same key for the second time. It already has steam quirks to handle.
Redeem command was never meant for anything but steam keys, but if you send me a sample key on JustArchi[at]JustArchi[dot]net then I'll look what is wrong. But chances are, if it requires another function to reverse-engineer, then it won't be on ASF roadmap. The only exception will be if current method works but just misses a field or two.
Fair enough. I've send you the steam wallet code samples. Edit: Seems my whole key redemption is messed up now. Maybe steam blocked me?
Redeeming those keys on Steam results in exactly the same behaviour, nothing to fix. Tell Volvo to fix their network.
Back to redeeming Steam Wallet keys. I did some reverse engineering myself. It's pretty easy to redeem a steam wallet code, just send this request: POST "https://store.steampowered.com/account/validatewalletcode/"
with this data: { wallet_code: "RWNFQ-90K07-MP82Q" }
I even went ahead and decypher some of the responses:
{ "success": 16 }
means OnCooldown
{"success":1,"detail":15}
means AlreadyRedeemed
The problem is however distinguishing game codes and wallet codes. But I believe your redeeming function returns whether or not it's a wallet code, just like the Steam Client does. And you are currently handling it as an error/unknown and keep retrying.
BTW, not sure if you are still doing it this way, but just checking key.split("-") length is 3 and for each split length is 5 is not a real sufficient way. I've examined steam keys a lot and they all follow this RegEx pattern: [A-NP-RTV-Z02-9]{5}(-[A-NP-RTV-Z02-9]{5}){2}
As you can see I left out some characters. These characters never occur in a valid steam key.
!redeem
redeems game cd-keys, not wallet codes, by definition. And adding another command just for wallet codes seems redundant to me, I don't think it's on ASF roadmap.
BTW, not sure if you are still doing it this way, but just checking key.split("-") length is 3 and for each split length is 5 is not a real sufficient way.
I dropped that pretty quick, and I have even more powerful regex than you posted.
I wouldn't say more powerful. It still includes "illegal" characters. !redeem
function can be expanded to support wallet codes.
No it can't, because !redeem
function executes ArchiHandler.RedeemKey()
and that function is communicating with steam network, not steam store through HTTP requests. The end result of you trying to redeem wallet code with it will be exactly the same as you trying to redeem that key as game code in steam client, nothing changes, I tested it back 3 months ago.
I have no idea if Steam includes any function or feature that will be able to tell from key itself if it's game code or wallet code. I didn't find any when I looked into that, so unless somebody proves me wrong I will assume that it doesn't exist. If it doesn't exist, I'd need to add another command purely for redeeming wallet codes. I try to minimize number of HTTP reverse-engineered functions to bare minimum, because ASF already includes too many of them. I don't think that redeeming wallet codes is that important for ASF to operate, that's why I'm not interested that much into implementing it myself.
If you reverse-engineer legit steam network request (not steam store HTTP) that is being used for wallet redeems, same like I did with game keys redeems, feel free to send PR and I'll be happy to include it. If you find a way to distinguish game key from wallet key - even better.
And yes, my regex is more powerful, because it handles many more valid patterns. Plus, !redeem
doesn't even test if key is valid, as there is no need to regex in-place if user intentionally executes the function.
Those are not illegal characters, as far as I know - it's just a substitutes to avoid misread codes. If you take a working steam code with "5" in it and change it to "S" instead, code should still work. Same goes for "0" and "O". And, if steam has this foolproof why should we deny it? As for wallet codes - I don't have an opinion for that, because I actually never used any of that. In many countries there is no shops to buy steam refill cards. I don't know how often users use wallet codes, nor I know how often they do it on bots. Sadly we lack feedback of this kind. If enough users will be interested in it - I don't see why not implement it.
Just try to redeem this key: RWNFQ-90K07-MP82Q steam://open/activateproduct Steam is able to recognize if it's a steam wallet code and send you to https://store.steampowered.com/account/redeemwalletcode/?code=RWNFQ-90K07-MP82Q So that is why I thought ASF's function would be able to recognize that too. I dont think there are any other steam network requests for redeeming a steam wallet key. Even the steam client send you to the steam store.
Yes, exactly the same as Steam client drops non-ASCII characters in passwords, so a password like aaaąłćó is the same as password aaa, but user doesn't know that. I didn't know either until very recently.
So if user is writing a cd-key, from an old retail box for example, and he includes "invalid" character that is being substituted by steam network to something else, ASF should NOT assume that it knows better, because it just doesn't. ASF tries to know better, but when it can't be 100% sure with something, it just assumes that user knows what he's doing. That is what is happening with status codes, trading, or user intentionally executing !redeem
on those rare Prey keys ASF regex doesn't have support for, because it's simply not needed.
I'm not that much against a function that redeems wallet codes, especially because it doesn't sound that bad, but we should ensure that there is no better steam-network way of doing that, before we start adding another poor steam store HTTP post request. ASF should have as many steam-network functions as possible, because only them ensure stable and not-changing API that I can at least semi-reliably trust. Valve can't change them easily without dropping support for all older steam clients, that's why I love rewriting those awful HTTP requests into steam network ones.
Valve can't change them easily
Actually, they can. Steam client is auto-updated, so they can just update both client and server any time. I just hope that they are to lazy to do it.
Could you at least look into ASF's behaviour when trying to redeem a wallet code? I think it just keeps retrying resulting in an OnCooldown, which is just plain annoying.
BTW if someone needs multiple wallet codes (used): http://steamcommunity.com/groups/St4ckGiveaways/discussions/0/343788552544948630/
Actually, they can.
No, they can't. There are too many things depending on exact behaviour, steam client is only the most basic one. Too many internal/external APIs, games, engines, and whole lots of stuff. HTTP requests can be easily adapted and changed, because nobody sends them blindly. Steam network is frozen - if there is a need for another request, it's implemented as another function, and old one keeps working. That's how I managed to implement redeeming of steam gifts via network, EVEN THOUGH it's NOT supported this way at least since a long time, because Valve moved that part to steam store entirely.
Could you at least look into ASF's behaviour when trying to redeem a wallet code?
I checked how steam client recognizes that it's a wallet key, and surprise, there is a way that doesn't make me feel uncomfortable:
We don't have result 50 defined, therefore it results in Unknown
. I think I can add support for that, and eventually try to redeem key blindly as wallet code when steam network returns code 50. I just don't know if 50 is used for anything else, there are no official names, I'll just name it something like SteamWalletCode
until I hit some other place it's being used in.
Cool! Nice find!
If my theory is right, I could improve !redeem
in a way that it automatically tries to redeem steam wallet keys through another request if steam network tells ASF that it is indeed a wallet key. I'll probably have some build ready for tests in a few minutes.
It looks like it works nicely:
23:00 - Archi: RWNFQ-90K07-MP82Q
23:01 - Fred Flintstone:
<2> Key: RWNFQ-90K07-MP82Q | Status: DuplicatedKey
I went one step ahead and I also propagate the result from wallet redeem request, so it should result in "OK" if the request succeeded.
I'll release a pre-release for tests.
Available for tests and should be working: https://github.com/JustArchi/ArchiSteamFarm/releases/tag/2.1.5.9
Just beware of other experimental stuff, that pre-release has more features that I didn't carefully test yet.
I think this ticket status should be solved 👍 Thanks again archi!
Labels are incorrect
If you expect me to look into it then the least you can do is show current ASF output and explain what is wrong with it.
Hello, first of all, amazing job with ArchiSteamFarm. As I was trying out the "redeem" command, I noticed your bot isn't able to handle Steam Gift Card codes properly. Even worse, it results in a cooldown. So, I am wondering if you could add a handler Steam Gift Card codes? PM me if you need used steam gift card codes to test. Secondly, I would if the bot could remember which keys it has activated, so if you want to redeem a key which has been tried before, the bot should ignore it, as it has no use to try again. It will only lead to a faster cooldown. This last feature would help me very much! Thanks for everything!