Fixed

• A chest you had once opened was never used again. Container.IsInUse() returns the raw m_inUse field, but Container.SetInUse only assigns that field when the caller owns the ZNetView. So on a client that does not own the chest the value is wrong in both directions, and worst of all a chest this client opened and then lost ownership of never receives its SetInUse(false) - the guard drops it - leaving it "occupied" for the rest of the session. Depositor.Usable rejected it there, before the chest's rule was ever read, and the post reported having nowhere to go while a correctly configured chest stood in range.

  It is worse than a stale read, because the state seals itself in. UpdateUseVisual is the only code that ever writes ZDOVars.s_inUse, it is reached only from CheckForChanges through Load(), and Load() returns false outright while m_inUse is true. So the flag blocks the one path that would clear it - on the instance and in the world file both - and stops that chest reloading its contents from the ZDO into the bargain.

  m_inUse is no longer consulted at all. When we do not own the chest, ZDOVars.s_inUse off the ZDO carries the shared answer, which is what vanilla's own UpdateUseVisual reads in its non-owner branch. When we do own it, nobody else can have it open - opening transfers ownership, because Container.RPC_RequestOpen ends in SetOwner(uid) - so the only honest question is whether we have it open, and InventoryGui answers that through public API with no private field to go stale.

  Both halves matter and they cover different people. A player on a shared server hits the non-owner path; a player in singleplayer owns every ZDO and only ever hits the owner one.

  discuss

• The spirit flew back and forth without ever delivering. A trip carried an ItemDrop.ItemData reference, and Container rebuilds its entire inventory from the ZDO on every revision change - which a stow run causes constantly, because each deposit changes a container. Inventory.ContainsItem is reference equality on a List, so the reference was orphaned in flight almost every time. Move treated that as handled and returned silently, so the spirit landed, moved nothing, and set off again forever.

  The item is re-found on arrival by shared name, quality, variant and world level - the same fields Inventory.FindFreeStackItem uses to decide two stacks may merge, so anything matched is something the destination would have stacked with the original anyway.

  This one was hidden behind the first: with the chest excluded, no trip was ever dispatched.

  discuss

• A stow could duplicate what it moved. Depositor.Deposit took the trip's share out of the source by writing item.m_stack directly, and only called Inventory.RemoveItem once the stack reached zero. A raw field write is invisible to the inventory: Inventory.Changed never fires, so Container.OnContainerChanged never runs and the post's ZDO is never saved. The destination's side does save - AddItem calls Changed - so the post reloaded its old contents from a stale ZDO, the stack came back, and the next trip moved it again. Measured at 21 coal in the post producing 140 in the chest.

  Only a partial take was affected, which is every trip of a stack larger than ItemsPerTrip, and it needs a trip to actually land - so it was invisible for as long as the two bugs above kept trips from landing at all. The removal goes through Inventory.RemoveItem(item, amount) now, and the source is checked for the item before anything is added anywhere, because an add that succeeds beside a removal that fails is the definition of this bug.

  discuss

Changed

• The run explains itself now. A homeless report lists, per item, every usable chest, the rule it carries and whether it wanted the item, refused it, or was full. Move's three silent exits each say which one fired. Previously the log could show "2 usable chest(s)" and then nothing at all, which is the state both bugs above lived in.

  discuss