Dr. McKay

Yeah, if it has to store all that item data in RAM, naturally it's going to consume RAM.

I don't think a block is detectable, no.

I don't see any reason why that wouldn't work. Maybe your proxies are shared or something.

There isn't, since descriptions aren't uniform across games.

Yeah, that happens from time to time. Steam is not the most stable service. No, it won't automatically retry.

Yes.

No, if you want to create gameserver accounts programmatically, you'd want to use the WebAPI.

That sounds like a reasonable assumption. Game content downloads are sometimes compressed with LZMA, so Valve using it somewhere else makes perfect sense.

Inside of that callback function, this refers to the SteamCommunity instance and not the outer context's this. Replace that with an arrow function and it should work as you expect. this.community.on('sessionExpired', () => { this.client.webLogOn(); });

A more proper way would be to check if client.steamID is set before calling logOn and aborting if it is.

Yeah... I really am not sure about the best way to approach this. It's necessary to use process.nextTick in order to avoid errors caused by calling logOn inside of an error callback, meaning that the thrown Error can't be caught. But I also don't like the idea of using the error event for this, since when this error occurs, the client actually still is logged on and the error event always indicates that the client has disconnected...

Client connections and web sessions are two separate things. When steam-user connects to the Steam servers, it also negotiates a web session (which is what the cookies you've received contain). That web session expires pretty much whenever it wants, and when it does you'll get that error. You should use the sessionExpired event in steamcommunity to detect when your web session has expired and use webLogOn() in steam-user to get a new session. Or, just call webLogOn() every half hour or so. That tends to work well enough in my experience.

Please see:

That data isn't account-specific, so it would work fine between accounts.

const SteamUser = require('./index.js'); let instance = 0; const getAppBranchInfo = (appId, branch) => new Promise(resolve => { let user = new SteamUser(); let inst = ++instance; user.on('loggedOn', async () => { console.log(inst + ' logged on'); const productInfo = await user.getProductInfo([appId], []); const appName = productInfo.apps[appId].appinfo.common.name; const buildId = productInfo.apps[appId].appinfo.depots.branches[branch].buildid; const timeUpdated = productInfo.apps[appId].appinfo.depots.branches[branch].timeupdated; console.log(inst + ' ' + buildId); // Graefully logoff. user.logOff(); resolve({ appName: appName, buildId: buildId, timeUpdated: timeUpdated }); }); user.logOn(); }); setInterval(() => getAppBranchInfo(740, 'public'), 1000); I ran this for 5 minutes and it didn't crash. What version of steam-user are you on?

You would probably add a new argument to your SteamBot constructor for the proxy URL to use.

I don't know. My best guess would be that it's either protobuf or binary KV, but that doesn't look like either. It could possibly be compressed.

I have no idea what format price_sheet is encoded in.

Can I see the rest of the stack trace, please? It's possible that there's a bug in the module. This isn't related to the error, but I don't see any reason why you'd need to log on anonymously every time you want to send that request. You could just leave the connection open and you might run into fewer issues with Steam throttling you or something.

That happens because Steam is going down or otherwise disconnecting you, and when the account automatically logs back on, the session resumption key is rejected and it prompts for a Steam Guard code. To suppress this prompt and provide a code programmatically, handle the steamGuard event.

No, that's not possible Yes, that's possible as long as you are only in-game on one connection at a time. You will need to change the logonID on one or both instances or else one will get kicked off with the error LoggedInElsewhere.

That's all correct. Anything that depends on a steam-client interface is not going to work with steam-user v4 or later. You could either use steam-user v3 or you could possibly write a kludge that would translate steam-user into a steam-client-like interface which dota2 could work with.

I don't see any reason why that wouldn't work.

Yes, for that reason you probably want to split up your stuff into multiple processes.

There's no real limit on how many steam-user instances you can run in one process; your biggest limitations are going to be memory and IP addresses.