kryo

You can use the HTTP_PROXY and HTTPS_PROXY environment variables to provide a socks proxy.

Actually, how about if that event just gets emitted every time getOffers is called without a time restriction? Then it'd be emitted for full updates, and also whenever your own code loads the full offer list for whatever reason.

Sure that would work just as well.

This was a CS:GO item. I just had to re-check the receipt at a later date to get the full item.

If it's as simple as checking the item name then this is something we could identify in getReceivedItems, right?

Got this little gem today from TradeOffer#getReceivedItems

    {
      "id": "5688498100",
      "owner": "...",
      "classid": "1618444825",
      "instanceid": "188530170",
      "name": "",
      "pos": 1,
      "appid": 730,
      "contextid": "2",
      "amount": 1,
      "is_stackable": false,
      "assetid": "5688498100",
      "fraudwarnings": [
        
      ],
      "descriptions": [
        
      ],
      "owner_descriptions": [
        
      ],
      "actions": [
        
      ],
      "owner_actions": [
        
      ],
      "tags": [
        
      ],
      "tradable": false,
      "marketable": false,
      "commodity": false,
      "market_tradable_restriction": 0,
      "market_marketable_restriction": 0
    }

Has anyone seen this before? How can we identify that the item is malformed?

I'm just going to check for a missing market_hash_name since that's all I need, hopefully there is a way to know for sure.

Fair enough. How about an offerList event that's emitted every time we do a full-update poll?

Sounds good to me!

Yeah I am using the classid/instanceid and the market_name as a last resort, meanwhile ensuring that I don't count the same item twice. I was hoping that there would be another way but thanks for the confirmation.

Right but when handling a trade we have two assetids for each item, sent item and received item. If I want to get the inspect in-game link for the received item I need to somehow match it with the sent item.

Well, i hoped there was a better solution but thanks

Steam sucks 

If you absolutely need the def_index I think you will have to keep re-checking the trade offer (try again later using TradeOfferManager#getOffer) until you find that the app_data exists.

I noticed that StatTrak items change classid and instanceid after a trade. Given a trade that has two StatTrak items with the same market_hash_name I'm not sure if it's possible to link the before and after items. Any ideas?

Hooks for polling is kind of weird in my opinion. What's your use case for declining old incoming offers? There's no limit there and I don't see any reason why you wouldn't be able to act on an offer immediately when newOffer is emitted.

If you offered a custom pollData format that would fix it for me.

It's just kinda an edge case where if we receive an offer, add to poll data, and put a setTimeout(offer.decline, 30000) the offer might not get declined, for example if the bot goes down.

It would be great to have custom hooks for the polling, to handle offers that haven't changed since the last poll. I would use this for declining any incoming offers that get too old.

If the pollData event sent the offer's time_updated along with the ID and status I could do this very easily.

Ok I did a rm -rf node_modules/ and updated my package.json dependencies as follows:

    "steam-tradeoffer-manager": "github:DoctorMcKay/node-steam-tradeoffer-manager",
    "steam-user": "github:kryogenic/node-steam-user",
    "steamcommunity": "^3.19.1",

Seems to have solved the issue. Thanks.

While testing this issue I found that if you send an offer too quickly after initializing the manager it will show up as unknownOfferSent instead of the expected sentOfferChanged. On further inspection the offer id in the poll data seems to have increased by about 50.

I've noticed that on occasion (happens every 30 or so offers) I don't receive a newOffer event, the offer is simply forgotten about and eventually canceled automatically. Interestingly, if I send another offer right away (before the first one is canceled) I get a newOffer event for both of them.

I've only just started noticing this bug, using version 1.19.0: https://github.com/kryogenic/node-steam-tradeoffer-manager/tree/v1.19

Yeah, I have my own fork so I was using the latest code.

I think this is a bug with the new http requester. On the master branch I was getting this error:

{ [Error: HTTP error 500] code: 500 } 

I rolled back to v1.19 and now I get this instead:

{ [Error: There was an error sending your trade offer.  Please try again later. (26)] eresult: 26 }

I've noticed a lot of 500 errors recently, usually these errors only happen once or twice per offer but I've noticed some cases where I'm completely unable to send a trade offer because it returns a 500 error each time I retry it. These errors are very hard to debug.

I'm wondering if this is a temporary issue that everyone is experiencing, since I used to notice a lot of descriptive errors with eresult params. Also if there is some way to get the error info that would be great to know. I've tried printing the err, response, and body which are { [Error: HTTP error 500] code: 500 }, undefined, and undefined, respectively.