Jump to content
McKay Development

Dr. McKay

Administrator
  • Posts

    3389
  • Joined

  • Last visited

Everything posted by Dr. McKay

  1. Yeah, that should be sufficient. If I remember correctly, sessionExpired is only emitted for known no-session errors.
  2. Make sure your machine's clock is right and that you have all the typical TLS root certificates installed.
  3. I've created a GitHub issue for this, as the module does need to be updated. I'm unsure when I'll have time to get to it, but it should be soon. If anyone relies heavily on this, I can prioritize it.
  4. Why is my Steam inventory out-of-date? Before we delve into Steam's inventory cache, first it helps to know how the economy server works. When you request a user's Steam inventory, your request goes to the Steam economy server. If the economy server has that inventory in its cache, it returns the cached version. If not, it requests the inventory from the game's item server, caches the result that's returned, and then sends it back to you. This cache does not automatically expire (in most circumstances). However, there are a few actions that can cause an inventory cache for a particular game to expire: Launching the game via SteamQuitting the game via SteamAccepting a trade offer (or having a sent trade offer accepted) which includes items from the gameAccepting a real-time trade request, or having a real-time trade request which you sent be accepted*Publishers can do it at their discretion* if a real-time trading session is opened for your account, then all games' inventory caches will be invalidated for your account. I believe it's also supposed to be possible for Steamworks developers to tell the cache to expire at a certain date and time, but I don't believe it works currently. The Steam inventory cache is what causes your inventory to not appear up-to-date, especially if you craft/receive a new item while the game is running. The easiest way to invalidate the cache in order to get fresh data is to open a real-time trading session.
  5. https://github.com/DoctorMcKay/node-steam-tradeoffer-manager/wiki/TradeOffer#counter
  6. Okay, the timeframe was a bit sooner than expected. You can now change account email (which trade bans you for 5 days) and password (no trade ban) in v3.13.0.
  7. Can I see the code that creates the chat and invites the users?
  8. Only Valve knows the answer to that, but out of the interest of everyone I'd avoid registering accounts super quickly. No idea. Not possible through steam-user at this time, but would be possible to implement. Couldn't give you a timeframe, though.
  9. There isn't any debug mode that would be terribly useful for this, I'm afraid.
  10. No, the original post code is crashing due to some bug that I need to track down. What kind of chat is this? Group chat or multi-user? Also, is the chatEnter event being emitted for it? Can you also listen for chatLeft and see in what order stuff is being emitted?
  11. Well the error in that screenshot you just provided is caused by you attempting to leave a chat when you aren't connected to Steam. When you say it happens "every time", it happens every time what happens? Every time someone leaves a chat?
  12. This is a bug in the module. How frequently does this happen? Is there a reproducible test case?
  13. No, that's the actual solution. Errors are a fact of life (especially when you're working with Steam). You need to handle them, or else you'll crash.
  14. You aren't checking the error. In every callback, if err is truthy, then there was an error and all other arguments are undefined.
  15. You have to check the item schema for that.
  16. Correct. steam-tradeoffer-manager will handle all that polling for you.
  17. tradeOffers is emitted whenever the number of active received trade offers you have changes. This means that it will be emitted when you receive a new offer, or when an offer you previously received is accepted/canceled/declined. If you need more info about trade offers or you need to act on them, look at steam-tradeoffer-manager.
  18. 1) I'd keep your login checker code in there. The manager will only notice that your session is gone when you try to send/accept an offer. Normal polling and canceling offers uses the WebAPI and your API key, so the session isn't actually used there. 2) That's more than fine. 5 requests per minute is super low. 3) You're correct, your first snippet generated the code once on boot. It ceased to be valid once you used it.
×
×
  • Create New...