Dr. McKay

It's entirely possible that keys have the cannot-craft flag set. They're necessarily purchased from the store, after all. The web and in-game UIs might just hide that text for keys. It is actually possible to accurately get craftability and tradability from the GC data (after all, that's the same data the official game client gets and it has to be able to determine if items are tradable or craftable), but it's a complete mess and you need to check a handful of different conditions and attributes because it's Valve and Valve can't write good code. For example, there's an attribute "cannot trade" but then there's also an attribute "always tradable" and I have no idea which takes precedence. My wild guess would be that "always tradable" trumps the achievement origin but is itself trumped by the flag and other untradable attributes (e.g. "tradable after date") but this is likely a really deep rabbit hole to dive into and I've never been insane enough to try. What is it you're doing? How frequently do you need to retrieve item data?

I dunno, maybe there's some second request that gets sent when you rate up some content that actually triggers the badge activity.

You should probably use httpRequestGet rather than httpRequestPost.

Is using webchat a badge task? I don't remember. If it is, I'm not entirely sure how they'd detect when you use webchat but you might be able to accomplish it by logging onto a CM through steam-user using a client logon token.

No, you have to use steam-user for that.

I dunno, that error sounds like it's coming from the Node.js runtime.

I'd need to see the stack trace to be able to tell you anything.

No, that's not supported.

I'm not really sure what you're asking, but CSteamUser stuff does work.

Use community.steamID.getSteamID64(); no need to call getSteamUser to get your SteamID. Logging into a different account with the same SteamCommunity instance that was previously logged in isn't really supported. You should create a new SteamCommunity each time.

https://github.com/DoctorMcKay/node-steam-user/issues/384

You're not actually logged on until the loggedOn event fires.

It looks like Steam doesn't want to send rich presence data when you use getPersonas, so requestRichPresence is the proper way to request that data. Your lack of a callback was a bug which is fixed in v4.20.2.

This should make the displayed game "Idling Hours", but sometimes Steam can be temperamental when it comes to custom game names. bot.gamesPlayed(['Idling Hours', ...this.games])

newOffer shouldn't take longer than 30 seconds. It should be pretty much instant if you passed a SteamUser instance to TradeOfferManager. You might try outputting TradeOfferManager's debug output to see if anything is amiss: _manager.on('debug', (msg) => { console.log(`[TradeOfferManager Debug] ${msg}`); });

The arguments are still domain, callback, lastCodeWrong on 3.29.3 as well.

The promptSteamGuardCode option was removed in v4. The prompting is now automatically disabled when you add a steamGuard event listener. The arguments for the steamGuard event are domain, callback, lastCodeWrong. With the code you pasted, lastCodeWrong will always be truthy because that's actually the callback you should call with your new code.

https://github.com/DoctorMcKay/node-steam-user#steamguard

Either you'd use the steamGuard event or the twoFactorCode property when you call logOn.

It's not really a bug, per se. friendRelationship is emitted when Steam sends down a message that a relationship changed. I guess Steam assumes that your local data is out of date if you try to add someone who's already your friend, so you get the friendRelationship notification to make sure that your client is aware they're already your friend. Nonetheless, I'll suppress friendRelationship and groupRelationship events for updates to our already-known relationship in 4.21.0.

You can't. Restarting a process necessarily drops your TCP connections, which means that you get disconnected and thus logged out.

The first argument to the webSession callback is sessionID, not cookies. My guess would be that you have a handler for SteamCommunity's sessionExpired event that calls client.webLogOn(), which it's continually doing because it never receives valid cookies.

You'd have to use node-globaloffensive for that.

You probably need to set the Referer header.

Interesting. Are you trying to download a manifest that isn't the latest? The beta Steam client has indications that Valve might start restricting that.