Dr. McKay

accounts is always going to be empty when your /log listener executes, so no accounts will get added and nothing will be returned. I misread the code.

Use the game's appid with requestFreeLicense, not the packageid you want. Steam will figure out which package to give you.

Not at the moment, and it's unlikely to be supported in the future due to the potential for spam.

marketSearch({appid: 730}, (err, results) => { ... });

The mistake is in your code. marketSearch only takes two arguments, options and callback. Remove the 730 and false.

I don't believe there's a limit.

shoppingCartGID doesn't get issued until you actually add something to your cart.

You misspelled accountName

Not at the moment, but I can look into it.

In the next release (expected in the next day or so), it will be possible to easily filter your owned apps to include or exclude shared licenses, but I'm not sure what you mean by "including ones excluded from sharing". Are you saying that licenses from a shared library are included, even if that particular app is excluded from game sharing?

It's far more trouble than it would be worth.

Not as far as I'm aware. They both accomplish the same task so Valve doesn't have a need to return both.

You can't.

Either your secret is wrong or your clock is wrong.

No, there isn't any native support in the library for that. It would probably be easier for you to just manually send the request and parse the JSON yourself.

Yeah, time_historical_cutoff is used to include non-active offers that have updated since the provided time, when you pass active_only.

Native support for what, filtering by item name? No.

You can use the count URL parameter to filter how many items are returned, like this: https://steamcommunity.com/inventory/76561198006409530/753/6?count=1

All active offers should always be returned when you pass active_only, regardless of your other query parameters.

When you pass data through IPC like that, it gets serialized and then unserialized on the other end. The nature of a SteamCommunity object actually being a SteamCommunity object doesn't survive that serialization.

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.