Dr. McKay

That should work. Exactly what issues are you encountering?

If your remote location has the same public IP, then you'd need to change the logonID when you call logOn().

It's definitely possible that Valve has blacklisted your proxy provider's IPs from receiving inspect responses.

https://steamerrors.com/87 According to Valve, this means they think you're trying to break into the account. I couldn't tell you exactly what their throttling criteria is, nor what it takes to reset it.

This is not officially supported and is liable to break at any time. If you need to handle a message that isn't already directly supported in SteamUser, and you don't want to fork the project and submit the changes as a pull request, then you should call _handlerManager.add as you are in the code above, but instead of passing an arrow function as the handler method, pass a regular anonymous function. Then, in the handler function, this will refer to the SteamUser instance that received the message (see how it's done in the module here). You will also need to handle protobuf encoding and decoding yourself if the messages aren't already mapped in 03-messages.js.

Why are you directly calling _handlerManager.add? Anything prefixed with an underscore is internal and not meant to be used directly. This is why you're experiencing the problem that you are. When testSteamID() is called for the second time, you create a new steam class instance. But your custom ClientWalletInfoUpdate handler still exists and still references your first steam class instance, which references your first SteamUser instance. There's no need to create a whole new SteamUser instance every time you need to reconnect. Just call logOn again. Another problem in your code is your once handler for loggedOn. loggedOn will be called potentially multiple times without an error event in between, e.g. if your connection to Steam temporarily drops and automatically reconnects. This is why logOn doesn't return a promise in the first place.

I don't know why this would happen. Do you have any code that can reliably reproduce this so I can try to debug it on my end?

Your examples are only sending the invite if someone sends you an invite. That's what the friendRelationship event is for, running code when your friend relationship with someone changes.

That's an old example. SteamUser.Steam.EFriendRelationship.RequestRecipient should instead be SteamUser.EFriendRelationship.RequestRecipient. Regardless, if you want to initiate a friend request, use client.addFriend for that. For example, client.addFriend('76561198398979571')

Show the latest code you tried.

Not that I've seen.

I've not delved into downloading workshop files. I believe it's very similar to downloading apps, but I couldn't tell you exactly how similar. If reading JS isn't for you, you could consult DepotDownloader.

Are you logging in fresh for every request? That's a bad idea.

That code looks fine at a glance. Does the account you're using have a license for CS:GO? You need to add it to your library before you can launch it. If it's not showing as in-game on its profile page, then that would mean that you don't have a license. You can use steam-user's requestFreeLicense method to add it to your library.

Seems like it, yes.

As far as I know, it's automatically activated when you log onto the client (or steam-user) 2-3 times.

Use getOffer to retrieve a TradeOffer by its ID.

It's on the wiki. You need to specify a language.

It's possible that the items in question don't have market_hash_names.

You need to log in TradeOfferManager using setCookies.

You're adding a new connectedToGC handler every time you get the wallet event emitted, which isn't what you want to do.

If you have the file, it should work on all versions.

Given only a steamLoginSecure cookie, no, it's not possible to renew it when it expires. You would need to get the refresh token out of the steamRefresh_steam cookie that's set on login.steampowered.com, and use the steam-session module to exchange it for a new steamLoginSecure cookie.

steam-tradeoffer-manager doesn't have anything native to avoid putting the same item into two trades. You're responsible for tracking which items you've already offered by assetid, and avoiding those items for future trades.

Not that I'm aware. It's just kind of a constant that you run into session expiration problems if you use the same account from two IPs. You're best off confirming trades in the same location as where you're sending trades from.