Dr. McKay

manager.getInventoryContents is only used for getting the current account's inventory. If you want to get some other user's inventory, you'll have to use manager.getUserInventoryContents.

From?

I don't really know how SDA works as I've never used it, but you might try exiting it for a day or two and see if that helps. Have you tried using a different IP address? It seems to me like sometimes Steam just flags a particular account or API key on a particular IP. You might try using a different IP, or check where you might be using that API key besides just in the bot. The code you posted here looks fine, though.

Sure, you could use steamstore for this.

No, all you can do is work out what the error code could mean. https://steamerrors.com/15

You're trying to use an IP address that isn't assigned to any interface on the machine you're using.

The internet is not flawless.

As of steam-user v4, steam-client is not used. You'll need to read the docs to see the new way to set an HTTP proxy.

Ubuntu 18.04.2 LTS. Node.js v10.15.2

It works fine for me on Linux (Ubuntu).

What version of steam-user are you using? It's ready to send trades once the callback fires without an error when you call setCookies.

Your best bet is just to handle the error event and if that happens, call logOn again.

That code looks fine. LogonSessionReplaced means the same account was signed into from the same IP with the same logonID. If you don't want it to crash your app, you need to handle the error event.

Yes. That's not supported. Each TradeOfferManager needs its own SteamCommunity instance.

I would assume this is because the x variable has a larger scope and it has since changed. As an example: for (var i = 0; i < 10; i++) { console.log(i); setTimeout(() => console.log(i), 1000); } This would output: 0 1 2 3 4 5 6 7 8 9 // 1 second delay 10 10 10 10 10 10 10 10 10 10 This is because the i variable changes every time the loop increments, and the callback functions reference that variable with its current value when they execute, not with the value it had when the callback was set up. You can work around this by using let instead of var, which will do what you expect.

Yeah, you can use the cluster module to spin up child processes. Usually what I do when I have multiple bots I need to run to do the same task is I have a database table with a row for each bot. The table has a column named like last_heartbeat and the bots update this column with the current time every 10 seconds or so. If the timestamp is recent, then the bot is running. You could also have another column storing the IP address (and port) of the server/process where the bot is running and use that to make HTTP calls to the bot.

The readme is wrong, the limit is actually 20k. There is no way to paginate if that isn't enough. You'll have to write some fancy queries if you need to get more servers.

Yep, that looks correct.

You would most likely run into rate limiting if you tried to run 20 bots from the same IP address. You will probably need at least two IPs. Running 10 bots per IP isn't unheard of, depending on how many HTTP requests you make from each bot. You don't necessarily need proxies if you can have multiple IPs on whatever server you're running on. In this case, you'd want to use localAddress to pick which IP each bot uses. I don't personally use loginKeys. The biggest benefit to using them is that you don't need to have your bot's password and two-factor secret in config files on your server. Problem is, using a loginKey doesn't actually always work (thanks Valve!) so you'll need to enter passwords and 2FA codes at some point anyway. Personally, I prefer to just put the password and 2FA secret in a config file and use those. You really shouldn't run the same bot in two different processes. You'll probably run into issues doing so. You're better off just running one process for each bot and building in some way to communicate with those processes if you need to control the bot externally. I tend to prefer to start up an HTTP server using the built-in http module and just make POST requests to control the bot.

Oops! Totally missed that too.

There's no need to call webLogOn inside of a loggedOn event callback. A web logon happens automatically when you first connect. If you add manager.on('debug', console.log) you might get some helpful output.

There's no reason why it shouldn't emit, provided you've set your cookies properly. You're probably doing something wrong.

Try adding client.on('debug', console.log) and see if there's anything useful in that output.

I don't currently have plans to add it.

I'm not sure you can do that with steamcommunity right now.