aXseee

The issue is caused by m_iCacheFlushCountLimit in ClientManager. It is set to 200 by default within the class, and if you haven't increased this value in conf.txt (CACHE_FLUSH_LIMIT_PER_SECOND), items that hit the limit cannot be saved instantly. If a request for new data happens to coincide with this moment, the items end up getting rolled back. It may have been configured for the old system (such as MySQL 5.5). Setting it 750+ does not cause any issues.

Naah, just move the erase right after the find. why would you create a temporary copy in memory when you can simply use a reference?

It’s not really a fix — your modified code still performs the same operation, just with an extra loop triggering the same function again. That doesn’t solve the problem (and in fact, it didn’t). The root cause occurs when, during or immediately after a trade, one or both trading players switch to another core and request a DB load. After the load, the item reverts to its previous owner and gets saved there again. So yes, at that moment, there are technically two instances of the same item. This state persists until the other character also performs a load request — at which point the item is removed from their inventory. In short, there’s no definitive fix for this. However, if you add an exchange-time check to functions that can move a player to another core (like channel switch or warp), this issue won’t happen during normal operations. But if the client crashes or is force-closed during a trade, the problem can still reoccur.

Dash you can upload files again. I have that same problem