We can keep inventory checksum before deduplication in the cache. If it's determined to be the same, then our inventory state didn't change, so it also doesn't make much sense to ask server for set parts and announcement.
* Initial implementation of announce with diff
* Add missing logic pieces
* Change in logic
* Fix checksums
* Add deduplication logic
* Update SetPart.cs
* Use standalone endpoint for diff
* Use different hashcode impl
* Update AssetForListing.cs
* Misc
* Push all the changes for this to finally work
* Use original index rather than self-calculated
ASFB makes some calculations based on index, it's better for us to have holes rather than hiding skipped items.
* Handle edge case of no assets after deduplication
* Remove dead code
* Address trim warnings
* Misc optimization
Make it so the design actually follows what Steam gives us now. There is no need for standalone Confirmation object anymore, rather re-use what Steam gives us. Optimize parsing type, expose it as public API. Small breaking change in HandleConfirmations() action.
Initially I added check against zero as bullet-proofing for unexpected events, but some accounts actually report 0.
Assume 0 is older than needed, if we don't have information available, we shouldn't jump to conclusions.
- Make use of new UnixFileMode, always one native method we need to maintain less
- Add madness support for it, because new feature of course
- Add optional netstandard target and required compatibility for it, so I can test netf-oriented changes easier
By using ordered list for json body, we can further minimize amount of data sent by getting rid of the index.
We still need previous asset ID, as we send only a subset of real data and server is unable to calculate it from the data sent.
Previously we accepted those after each trade, because the overhead of loading other inventory was too big to leave those pending. Since we have all possible matches at once now, it makes sense to firstly schedule all trade offers, and then just confirm them all at once, especially since confirmations endpoint is horrific and very often problematic, on top of having 10-seconds rate-limiting.
We no longer require 100 tradable items, but rather, 100 total items. We can also further optimize the payload by removing assets where we have no tradable items at all.
