Dr. McKay

The events have the same name, yes.

There's a limit on logon attempts (failed or successful). I don't know exactly what the limit or cooldown is, but I think it's somewhere around 10 per hour.

Apptickets need to be validated by all servers, secure or not. I highly doubt that you'd be able to subscribe to an arbitrary user's inventory.

If you know the ID of the trade offer you're trying to map new item IDs for, this is actually really easy. GetTradeOffer includes the trade_id of the completed trade, and GetTradeStatus includes the mapping of old to new asset IDs for all items. It even has the new asset IDs in the original user's inventory if the trade was rolled back (due to an error in the middle of committing, or canceled escrow).

I've never actually first-hand tried to figure out how servers are notified of items being acquired by users. That plugin just hooks the message that the server sends to its clients (which is what triggers the native chat message), suppresses it, extracts the data from it, and sends its own messages. It's an event called item_found, and it's generated by the server in response to some notification that an item was found. The following is my best guess as to how it works: When a TF2 client joins a game server, the server authenticates their Steam app ticket. Once that's done, the GC sends the full contents of the player's inventory to the server, which keeps it in a memory cache. This is necessary so the server can make sure you actually own the weapons and cosmetics you're equipping. As long as the player is connected, the GC informs the game server in real time of updates to the player's inventory (in the same way that the GC informs the player's game client of updates to its own inventory). When a player connected to it receives a new item, a game server receives an "item created" message (SO_Create), and then the game server extracts the item's data (using the origin field to determine the acquisition method), and then broadcasts item_found to all its clients. The biggest problem I have with that explanation is that I don't think the origin field changes to "Traded" when an item is traded for, so how would a game server determine if an item was traded for? Maybe the origin field in the GC's item data changes to Traded but the origin field in the API doesn't or something.

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.