Dr. McKay

Well, it looks like you're logging off in your matchList callback, and if you aren't logged on you can't talk to the GC.

Don't call it multiple times.

Sorry, this isn't something I have any plans for.

Every time you call .on('loggedOn', ...), you're adding a new event listener. When the event gets emitted, each function you passed to .on will be called, which can be multiple.

Not at the moment. You could manually craft the HTTP request though.

The hidden one is the correct one. The visible one is used as a decoy to throw off dumb users who fell for scam sites back in the day that prompted them to upload their sentry files. It always contains the same content. The numbers don't really have any meaning. Steam does keep a reference to the correct sentry file in config/config.vdf under InstallConfigStore>Software>Valve>Steam>SentryFile, but if you only have one hidden sentry file then that's the correct one.

You're adding a new loggedOn event listener every time you log on, so it's going to get called multiple times. You should only have one loggedOn listener. Also you probably don't need to call logOn in the sessionExpired event since steam-user automatically attempts to log back on when it gets disconnected, unless the error event gets emitted.

Do you have Steam Guard enabled? If you do, then I really don't know what the issue could be. Family Sharing support is experimental and I've not done too much testing with it.

Sorry, I really don't have any plans to do anything with Dota.

I guess maybe the proxy connection is also being blocked. Using an http:// proxy is not encrypted and any upstream firewall can see what host you're trying to connect to.

Do you know where exactly that error is coming from?

You likely do need to set the proxy on your steam-user instance as well.

Unfortunately, the data received from the GC (what you get via node-tf2) is incredibly messy and there's like a dozen conditions you need to check to see whether an item is untradable/uncraftable. It's probably not worth your time doing and you should probably just pull that data from the web instead, but if you really want to, a starting point is that a few conditions that determine uncraftability is a flag in the flags field, an "achievement" origin, a "tradable after date" attribute, and a "never tradable" attribute. That's not an exhaustive list though.

That looks correct, just uncomment your "community": community line.

You're rate limited. You're making too many requests somewhere.

That's a good point on the already logged on error, although for the others I don't really think it's worth being concerned about. It should not be possible to be missing a CM list since it's retrieved from the WebAPI and the library falls back to a bundled list if that fails. I'll see about making it possible to handle the already logged on error.

received = received.filter(offer => offer.state == TradeOfferManager.ETradeOfferState.Active)

Just filter the list to only active offers.

manager.on('sentOfferChanged', (offer, oldState) => { // This is the callback // offer.id is the ID of the trade offer that changed });

No, that kind of thing would be a trade secret I'd imagine.

Sure, have fun with that.

If you're already keeping track of offer IDs paired with discord user data, then you should just have one sentOfferChanged handler and check the offer.id inside of that callback.

Sounds about right.

Call the accept method.

You should only have one sentOfferChanged handler. You should not add a new handler every time you send a trade.