speedy

thx for reply. I know this new function, but if i understanding correctly i cant validate the token from users tradingurl... (want to check users token from my db when i receive a trade from this user... so i dont want to send a trade)

Hello, i miss the "getEscrowDuration(steamID[, token], callback)" function in TradeOfferManager v2. I used this function to validate the user token and of course also if the user has no escrow duration. Why this feature was removed? Is there a replacement for the token to check ?

thx, do you have a good idea to find that changed ids by name (ofc the database as assetid blacklist) but also secondary prevent that it doesnt choose items from a new trade where the "getReceivedItems" not finished yet (so ids not in database)

Hello, recently i use "getReceivedItems" to get the new assetids from new items in my inventory and save them in my database. Withdraws of the same items to users are very easy in that way (have not to search them in my inventory by name, ...) Most of the time when steam runs in good state i have no problems with that. But sometimes especially on the weekend some outgoing offers fail with state "InvalidItems" or error 26 on retry. Some items (not every from that invaliditems trade) arent anymore with that assetid from my database in my inventory. It looks like they have changed the id. Do you know that problem? is there a way to find out the new assetids without searching them by name in my inventory? My problem with searching by name is (for the repair of the ids), if there is much action on my bot it could happen that a search by name choose very new accepted items (before getReceivedItems write the assetids to my database -> using my database as blacklist which item ids are "free" in my inventory (to find for that missing ids the "new" id...

I want/try to start a discussion to collect ideas and experience which is the best way to load user inventories fast and preferably unlimited for web bases item select masks. For myself, I 've just read that one needs a lot of ip addresses to pass as proxy for example as described in this post https://dev.doctormckay.com/topic/176-loadinventory-proxy/ I imagine the following questions ? What are the limits to request inventories (x request per hour, or day) ?should i use a caching strategy (which is recommended, just time based, how long) ?if proxys are the only way is there a recommended hoster, eg.is it possible to request the inventory cross site based with javascript in browser (so that customer client ips are used), iframe, etc.... Are there any other strategys? Hope this post can help others and me to handle this problem.

For me the same, but not really a problem the trades are still quite quickly accepted on "receivedOfferChanged" event. But i have related to this another question for other error codes from steam. accept([autoRetry][, callback]) Which error codes do not accept the trade temporary ? So that the autoRetry function has to accept again (autoRetry after a minute, found in documentation)? Background is, some trades need a very long time (> 1 minute) to be accepted (usually when steam is under heavy load..) For me with a bet site its better this trades will be declined when that happens. So my idea if error code = x message user or try to accept faster again or try to decline... I found the following error codes 16 and 28, can this be right?

I know steam is magic awesome, but do you self use this practise or does someone else have good experience with that? Can someone recommend this?

I have one question to the "accept([autoRetry][, callback])" function for offers. At the moment i use only the "receivedOfferChanged" event to check if the trade is accepted (but this can take some time) In the wiki https://github.com/DoctorMcKay/node-steam-tradeoffer-manager/wiki/TradeOffer i found this: Wait for the callback, and if err is null, then process the offer, otherwiseWhen the err is null, is it 100% shure that the trade is "accepted" and can not result in "invaliditems" or "canceled" (so i can process the trade much faster...) ?