Dr. McKay

The protobufs can be gotten from SteamDB, who gets them using ProtobufDumper.

No, you probably want to put all your event handlers outside of your HTTP routes, and store the steamGuard callback in some global variable, so you can call it from your /verifycode route.

Added in v2.1.0.

You should use the steamGuard event rather than calling logOn multiple times.

It's a planned feature for globaloffensive, but I haven't gotten around to adding it yet.

That's not implemented in any publicly-released module, to my knowledge.

You need to call community.setCookies, and you can obtain cookies from the webSession event.

No, there isn't a way to get an "inventory hash" or anything similar.

I would wager that the event listeners you attached to the bot are keeping it in memory. You might need to call bot.removeAllListeners().

The modules may work without the peer dependencies, or you should just install them yourself manually with npm install.

I don't see any reason why that should be the case. The only reason I could figure that would happen is that it doesn't clean up some timer or something, but every instance where it emits error, it also calls _disconnect, which cleans up after itself. Do you know what particular error code(s) cause this?

That looks fine, although you aren't going to handle any scenarios where the bot gets kicked off of Steam after logon.

The CM sends a notification message to the Steam client (which steam-user can receive), but that message only contains the count of pending trade offers. To get any details at all about the actual content of the trade, we need to hit the API for that.

It still works fine for me. Make sure your account owns the game you're trying to play and that the account's game visibility state is public.

It's very much not a bad idea to spawn one process per account. That way, if something causes one bot to crash, the rest don't also crash. Also, Node.js is single-threaded, so that's the best way to take advantage of multiple processor cores. About the only downside of spawning multiple processes is the increased memory usage. But if you have enough RAM, go for it.

appid, contextid, assetid, classid, instanceid, amount, name, market_name, market_hash_name See this guide id Same as assetid pos Not always present; this is the item's position in the user's inventory (starting at 1) background_color Hex code for the background color rendered for this item in the Steam inventory name_color Hex code for the name and border color rendered for this item in the Steam inventory icon_url Append this to https://steamcommunity-a.akamaihd.net/economy/image/ to get the item's image descriptions Array of objects containing human-readable description text lines tradable, marketable Self-explanatory type The text that goes under the game's name to the right of the square game logo in the Steam inventory when this item is viewed commodity Determines whether this item's Market listing uses buy orders exclusively (true), or individual listings with the possibility to submit buy orders (false) market_tradable_restriction Length in days that this item will be untradable after it's bought on the market market_marketable_restriction Length in days that this item will be unmarketable after it's bought on the market tags Array of tag objects; tags are used in the Steam inventory for filtering is_currency Always going to be false except for some Spiral Knights stuff (I think). You really don't want to deal with currencies, trust me. fraudwarnings Array of warnings that will be rendered in red when this item is viewed. If fraudwarnings exist, the item gets a red (!) icon in the Steam inventory

I can't guarantee it's going to work for you forever, but I would guess that checking the marketable property is a reliable way to see if a key is temporarily or permanently untradable.

What did your problem end up being?

The "D" value seems to be just some key used by the GC to make sure that people can't just guess at values to get item data. I've yet to find any way to extract any meaning out of it, only that it's required to retrieve the item's data. The index property is just the position of the first character in your string where the regex matched. Since you're regexing the entire inspect link, that's 0, or the very first character. Do note that if an item is listed on the market, then the "M" value is the market listing ID and not the owner's SteamID. And I guess you've figured out by now that the SteamID in the link (76561202255233023) is meaningless.

There isn't really a way to do that. You'd need to retrieve the user's inventory from Steam and get the name and image that way. Well, you could download the item schema and work out the item's name at least, but getting the image is entirely impractical. You'd need to reimplement the entire algorithm used by the game client to render items, which I promise you, you don't want to do.

I'm not sure I believe you.

Did you run npm install steam-user?

You'd need to either call setTimeout everywhere you call client.chatMessage, or create your own function that calls client.chatMessage after a delay and replace all calls to client.chatMessage with your new function.

I do intend to add (well, accept the pull request for) first-class support for item containers, I just haven't gotten around to it at the moment.