Dr. McKay

It's based on whether Steam reports if you have a wallet or not. I believe it becomes true the first time you fund your wallet (and thus set a currency for it).

Just add 2FA the same way you would if you had a phone number. The code gets sent to your email instead of your phone.

https://github.com/DoctorMcKay/node-steamcommunity/wiki/CSteamUser#commentmessage-callback

A trade that's reversed during Trade Protection will go to status 12 in GetTradeHistory and GetTradeStatus.

Or you could just use GetTradeStatus which takes a tradeid as input?

I don't know; you'll have to look for yourself.

You need to update node-steamcommunity and call acknowledgeTradeProtection() on each account.

Moved to correct forum - this was in an update to node-steam-session, not node-steam-user. As far as I've seen, this parameter is present for any GET request issued by the mobile app to the WebAPI. Confirmations don't go through the API so it's not present for those requests. In practice, the only request that origin=SteamMobile is added to in steam-session is the initial GetPasswordRSAPublicKey request as that's the only GET request issued when using EAuthTokenPlatformType.MobileApp.

Works for me.

There's no reason it wouldn't, a counter-offer is a new trade offer like any other.

Yes, that's what I said.

Already known, see this thread:

As you've figured out, the actual trade offer stays in the Accepted state, but the underlying trade gets rolled back. steam-tradeoffer-manager doesn't poll GetTradeHistory at all right now, so adding support for detecting these rolled back trades would incur additional requests. I'm still working on thinking of the best way to go about this, but for now I suggest you do your own GetTradeHistory polling.

https://github.com/DoctorMcKay/node-steamcommunity/releases/tag/v3.49.0 As far as I can tell, clicking that button in the popup (which is what acknowledgeTradeProtection() does) is all that's needed, and it only needs to be done once per account. If you've already clicked the button on the account(s) you use to trade, you shouldn't need to do anything more.

Probably a GC limitation. You should wait until the item modified event is emitted after adding or removing an item before moving on to the next one.

This is not unexpected. It was always just happenstance that this method worked via steam-user; it uses a method not used by any official Steam app. You should use node-steamcommunity instead, which uses the official method.

I'm traveling right now. I'll be able to push out an update in the next couple days.

Do you have some way to reproduce this? Checking whether steamID is set on a timer is not the proper way to reconnect. This would run you into problems if SteamUser is currently attempting to connect but isn't yet logged on. You only need to call logOn() when your bot starts up, and if the error event is emitted.

That's your access token, aka your steamLoginSecure cookie. It gives complete access to your account. It is your session identifier.

It's the same for everyone.

def_index tells you what an item is (which weapon, which case, etc) and paint index tells you what skin an item is. Everything you need is in items_game.txt in the game's vpk files.

If you aren't planning on making any requests to a domain, then you shouldn't have any issues patching the module to skip that domain's settoken call.

No

I believe webTradeEligibility is basically just a cache of your trading eligibility status for display purposes on the market. Rather than run the backend checks to generate this message every time you load the page, they just run the check once and then set the cookie for display. The backend checks still get run when you attempt to actually complete a purchase or trade though; you can't bypass restrictions just by fudging the cookie.

You can't get wear from steamcommunity.com, only from the GC.