Dr. McKay

Your assumption is correct. You could either use IPC to call to the master process and do your steamcommunity work there, or use IPC in the master process to the worker processes to share your login cookies.

I don't know what you think appinfo is, but it's not what you're describing.

The only thing that happens when a session expires is the sessionExpired event gets emitted (potentially multiple times). There isn't any other way to tell.

That code all looks fine, but bear in mind that steamcommunity doesn't set the steamID property to null when the session ends like steam-user does.

If what you're doing is working, then there probably isn't any actual rate-limit being imposed. But I would definitely use a short delay rather than blasting all the messages at once, since that could potentially trip some rate-limiting.

Yeah, just use the GetFriendList WebAPI method.

Can you verify the sessionExpired event is actually getting emitted? It can only get emitted if the module can verify with certainty that your session isn't valid anymore; getting a private inventory response isn't sufficient verification.

Yes.

Not really. In theory, the code to support this could be written, but I don't see what useful purpose it would serve. And you wouldn't be able to report as a VAC-secured server.

About all you could do is repeatedly send the MOTD message, but that would presumably make the page reload every time.

You would need to root/jailbreak.

You need to filter the inventory to find the "Gems" item, and set its amount property to 1.

You can't get old appinfo.

Still need some more details.

Seeing some code would help.

Yeah, that would work. You shouldn't need to worry about security as long as the bot's web server is only listening on localhost.

Going to have to ask for more explanation.

Created an issue for this: Steam awards · Issue #271 · DoctorMcKay/node-steamcommunity (github.com)

For the most part, if you just call webLogOn every 30 minutes, you should be fine.

There are a few different criteria that are checked when determining if an error warrants emitting the sessionExpired event. As a general rule, it gets emitted if a page redirects to /login. Valve being Valve, they're incredibly inconsistent as to how they communicate that you aren't logged in. The request for getting notifications returns 401, which isn't one of the criteria that emits sessionExpired. It probably should be, but I'll have to check to see if there are any other edge cases that might arise by adding 401 responses as an indicator to emit sessionExpired.

Be aware that if you're upgrading from v3 to v4, you need to check to make sure your code is compatible with the breaking changes in v4: Release v4.0.0 · DoctorMcKay/node-steam-user (github.com)

I need to know what version of steam-user.

What versions of node and the module are you using?

My mistake, I didn't pay close enough attention to your callback. The first argument to the callback function needs to be err; the second is user.

I don't see you ever calling setCookies on your community instance. And if you are, you have to call postGroupComment after that, not before.