Dr. McKay

https://github.com/DoctorMcKay/node-steam-tradeoffer-manager/wiki/TradeOfferManager#getescrowdurationsteamid-token-callback

Yes. It has the IP rate-limit I mentioned above.

Yes. Offer data is stored in poll data, so as long as you're saving and restoring poll data, then the offer's data should be available forever.

I've never experienced a persona data being unavailable. Is there any specific condition which makes it unavailable, or are you talking about just regular Steam failures?

If you're sending like 20 offers per second then there might be an issue, but I highly doubt you have that kind of volume. It's not difficult to just manually download https://steamcommunity.com/profiles/[steamid]/inventory/json/[appid]/[contextid]in whatever language and parse it.

Two things: Sometimes confirmations just don't show up at all. That's just Steam being Steam. See #27. 2000ms is really low for polling. The recommended minimum is 10,000ms for a reason.

Welp

You'd need probably 5 IPs. Not necessarily 5 bots, but 5 IPs. You also don't really need a bot to get an inventory.

You need to confirm them. You can use node-steamcommunity's confirmation stuff for this.

It depends on how frequently you'll need to load inventories. If you need to load more than say 2 inventories per minute, you'll get rate-limited pretty hard if you try to do that from one IP.

Are you up to date?

No, there's a device ID parameter in the URL for all confirmation HTTP requests. As I said, if you're using my libraries then they transparently take care of it for you.

Well I mean, you have to do both.

I don't imagine there's a massive difference unless you're doing heavy overhead tasks.

That error means that your account is limited. Steam was incredibly, incredibly broken yesterday and the night before and was limiting people it shouldn't have been. If your account shouldn't be limited, then try logging into it from a real Steam client, then restart your bot.

Yes, that works.

To be more specific (and I should really make some kind of wiki with this information), classid and instanceid are used to identify a description, not an item. A description is the item's display information. Two identical items will most likely have identical classid/instanceid; this means that using classid and instanceid to track a specific unique item really won't work. It would be like trying to use a car's make, model, and color to track that unique car. Sure you'll get close, but you won't always find that exact car. You want its license plate or VIN for that (assetid).

I haven't seen any issues like this. What's your polling interval set to? Can you attach a listener to the "debug" event and print that to the console? manager.on('debug', console.log);

Yeah making your bots separate from your site is probably your best bet.

var offer = manager.createOffer("[U:1:46143802]"); offer.addMyItem({"appid": 440, "contextid": 2, "assetid": "1234567890"}); offer.send("Hi there", "KYworVTM", function(err, status) { if (err) { console.log(err); } else { console.log("Offer #" + offer.id + " " + status); } }); Something like that, where [u:1:46143802] is my SteamID and KYworVTM is my trade token.

The unix timestamp in the second screenshot is the current time when the message was printed?

Using classid/instanceid to track a specific item doesn't work anyway.

Clusters are designed for applications which have to process lots of things at once (like many user requests). Running bots is really not a good use for clusters. I'm personally running 30 bots within the same node process on low-end VPSes and the only problems I'm having are Steam IP limits.

How many bots are you running?

Can you add timestamps?