Dr. McKay

It probably is. What's the use-case here?

Not at present.

Yes. You should already have the offer ID handy when you sent or accepted a trade offer.

logOff() is not async, no. But you're calling it before you're actually logged on, because you're calling it synchronously along with logOn(). A couple reasons why running steam-user serverless is a bad idea: You can only log on once every 30 seconds because that's how frequently TOTP codes change Steam will start throttling your logon attempts, even if you don't have any failed logons Your request responses will take quite a long time with all the overhead of logging on each time

Using steam-user in a serverless environment is really not a good idea, unless your environment runs very infrequently. the logOff() method isn't doing anything for you because you're calling it synchronously right after logOn(). logOff() does nothing if not already logged on. You'd need to call client.logOff() inside your doTradeStuff method, at the end after everything has been done.

https://steamerrors.com/26 The assetid isn't correct.

Not really, I've never encountered what you're describing.

acceptConfirmationForObject is a method provided by steamcommunity, not by steam-tradeoffer-manager.

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.