Dr. McKay

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.

I wouldn't be surprised if they did in fact scrape the values. I believe that mystery ID is also the same value as item_type in the response to ajaxgetgoovalue (the preflight that occurs when you gemify an item).

As far as I'm aware, those mystery IDs aren't used anywhere else on Steam so it isn't really possible to associate that. My naive guess is that the mystery ID is just the sequence in which the game developer uploaded their community assets.

It's itemCustomizationNotification, with a lowercase i.

Maybe you tripped some anti-spam measure or something.

Your second submit2 is the one that would work. Please be aware that your event listeners are going to be called every time steamGuard is emitted, so in that example, the steamGuard listener is going to be invoked both in the submit1 and submit2 handlers.

Nope, sorry. There are WebAPI methods for that though.

Yes, using steamcommunity.

That seems like it would work, although you're going to run into issues if you log into an account that isn't using 2FA.

There are a bunch of options. You could use readline to read input commands from the terminal and take actions based on those, you could start up an http server and respond to requests, there are a bunch of other things you could do too.

What have you tried?

You probably want to use form instead of formData.

That looks correct. It's possible that your proxy doesn't like connecting to non-HTTP ports, so you could try enabling the webCompatibilityMode option as well.

I honestly doubt I'll put much more work into family sharing in the near or semi-near future. You might be able to use NetHook to see what traffic the Steam client sends during the events you're describing.

No, that doesn't work anymore as of steam-user v4. Please check the docs for the new way to use a proxy.

You're probably not checking whether your client is still connected to Steam. In that case, whenever Steam goes down (or you otherwise lose connection), your web session will expire, triggering sessionExpired, which will make your code call webLogOn, which will fail with the given error because your client is no longer connected. You should check whether client.steamID is not null to make sure you're still connected.

Sorry, I've really only done a minimal amount of research into how family sharing works, but off-hand I don't remember any way to retrieve an authorized-device token from Steam. I guess it must be possible considering that flow you're mentioning, but I don't know how it works.

Are you calling webLogOn() anywhere in your own code?

Yes, I think you've misunderstood what this module is for. When using the gamesPlayed method, the module reports to Steam that you're playing the game, but it does not actually launch the game. You won't be able to interface with the CS:GO client and read the killfeed using this module. There is probably a way to read the client console (and thus the killfeed) through a program, but I don't know how you'd want to do that offhand. If the logaddress_add command works on the client, that would probably be the best way, but I have my doubts that that'll work.

I'm sure.

Not really. I guess you should handle the error event, check whether the error message is about your proxy, and if it is then retry a few times and abort if it can't reconnect after a bunch of attempts.

Glad to hear it. May I ask why you have the third line? You shouldn't need to do that.