Dr. McKay

The versions you pasted have the fixes that were just published. What's the exact error you're encountering?

Steam will rate limit your logins, even if you don't have any failed logins. In my experience, 10 logins at the same time should work, although if you need to restart your script too quickly you may run into the rate limit.

It's possible to run multiple SteamUser instances in one script, or to use separate scripts. It's up to you how to architect your app.

You may be able to use a token generated by steam-session for that access_token.

Not that I'm aware of.

net.js is part of Node.js itself, so you wouldn't really be able to modify it.

It is async. You can't use return inside a callback function and expect the outer function to get the value. To accomplish what you want, you could wrap it in a promise:

export const sendBuyOffer = async (manager:TradeOfferManager, withdraw:any) => {
    const keys = getKeyBalance(manager);
    console.log('getKeyBalance returns', keys)
    if (Number(keys) <= withdraw.keys) {
        // Note the addition of `await`
        await createTradeOffer(manager, withdraw)
      	// At this point, `resolve()` will have been called in the createTradeOffer function
      	// Or, if sending the offer failed, an Error would have been thrown, which could be caught using try/catch
    }
}

const createTradeOffer = (manager:TradeOfferManager, withdraw:any) => {
  	return new Promise((resolve, reject) => {
        const offer = manager.createOffer(withdraw.steamid)
        manager.getInventoryContents(TF2_APPID, INV_CONTEXT_ID, true, (err, inv) => {
          	if (err) {
              	return reject(err);
            }
          	
            let keys = 0
            for (let i = 0; i != inv.length; i++) {
              let item = inv[i]
              if (String(item.classid) == '101785959') {
                offer.addMyItem(item);
                keys++;
              } if (keys == withdraw.keys) break
            }
            offer.send((err, status) => {
              if (err) {
                console.log(err);
                reject(err);
              } else {
                console.log(`Sent offer. Status: ${status}.`);
                resolve();
              }
            });
        });
    });
}

The docs are actually really terrible on this and don't properly explain what this does. It doesn't bypass the need to confirm adding the phone number.

When you add a number on the Steam UI, sometimes it throws up a warning message but allows you to proceed. I can't think of a case where this happens off-hand, but you used to be able to use VOIP numbers, though you would be warned that using a VOIP number is less secure than a true cell number, but you could click OK and continue. bypassConfirmation is what controls whether these errors come through to your Node app (false = fail with those errors, true = ignore them).

I don't believe guides use that interface.

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

Not at present.

52 minutes ago, kkagill said:

Also seems like that method is asking for a objectID. Do I need to grab trade offer id and run this method one by one?

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:

1. You can only log on once every 30 seconds because that's how frequently TOTP codes change
2. Steam will start throttling your logon attempts, even if you don't have any failed logons
3. 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.

On 8/13/2023 at 8:47 PM, LinkerH said:

Thank you very much for your prompt response. I've reduced the creation of SteamUser instances, and now the code  works correctly.

I have some messages that require custom handling, but I can't find a public method to set up handlerManage. How should I go about adding custom handler in a reasonable way?

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.