Jump to content
McKay Development

kryo

Member
  • Posts

    17
  • Joined

  • Last visited

kryo's Achievements

  1. You can use the HTTP_PROXY and HTTPS_PROXY environment variables to provide a socks proxy.
  2. 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?
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. 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.
  11. 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
×
×
  • Create New...