Class ItemOperationTracker

Namespace

FishMMO.Client

Assembly

FishMMO.Client.dll

The client's record of which item slots are waiting on the server, shared by the inventory, bank and equipment panels.

public static class ItemOperationTracker

Inheritance

object

ItemOperationTracker

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

WHY THIS IS SHARED AND NOT PER-PANEL. An item operation almost never involves one panel. Equipping starts in the inventory and finishes in the equipment window; a bank deposit starts in one grid and lands in another. The panel that sends the request is frequently not the panel that owns the slot which must be locked while it is in flight — dropping an inventory item onto an equipment socket is handled by the equipment panel, but the slot that must stop accepting clicks is the inventory one. A per-panel lock table cannot express that, and the gap it leaves is exactly the double-submit this is here to prevent.

It also owns the client's ItemOperationFailedBroadcast handler, for the same reason: one message can concern two containers, and it needs to be read once and applied to both rather than three times with each panel ignoring two thirds of it. Registration is reference-counted across the panels that attach, so it survives any one of them being destroyed and unregisters exactly once when the last one goes.

Nothing here is authoritative. A pending mark says "we have asked and not yet been answered"; it never says anything about what the slot contains. Rendering still comes from the replicated containers, always.

Methods

Attach()

Registers the failure handler on behalf of one panel.

public static void Attach()

Remarks

Reference-counted. Until something registers a handler for ItemOperationFailedBroadcast, FishNet logs an unregistered-broadcast warning on the client for every refused item operation — and, worse, the refusal that was added precisely so the UI could unlock itself goes unheard.

Detach()

Releases one panel's claim on the failure handler.

public static void Detach()

For(ReferenceButtonType)

Returns the pending set for a container, or null for a type that has no slots.

public static ItemSlotPendingSet For(ReferenceButtonType type)

Parameters

type ReferenceButtonType

Which container.

Returns

ItemSlotPendingSet

The set, or null when type is not a container.

FromInventoryType(InventoryType)

Maps the wire-level InventoryType onto the UI's container type.

public static ReferenceButtonType FromInventoryType(InventoryType type)

Parameters

type InventoryType

Container as named in the request that failed.

Returns

ReferenceButtonType

The matching UI container type, or None.

IsPending(ReferenceButtonType, int)

Reports whether a slot is waiting on the server.

public static bool IsPending(ReferenceButtonType type, int slot)

Parameters

type ReferenceButtonType

Which container.

slot int

Slot index within it.

Returns

bool

True while a request on that slot is outstanding.

Release(ReferenceButtonType, int)

Ends the wait on a slot, if it had one.

public static void Release(ReferenceButtonType type, int slot)

Parameters

type ReferenceButtonType

Which container.

slot int

Slot index within it.

ReleaseAll(ReferenceButtonType)

Ends every wait on one container.

public static void ReleaseAll(ReferenceButtonType type)

Parameters

type ReferenceButtonType

Which container.

Remarks

For teardown: panel close, character change, quit to login. A lock that outlives the request it was taken for is worse than no lock, because the slot looks normal and silently refuses every click.

ReleaseEverything()

Ends every wait on every container.

public static void ReleaseEverything()

Tick()

Hands back any slot whose reply never arrived.

public static void Tick()

Remarks

Safe to call from more than one panel in the same frame: the guards are self-clearing and report a timeout exactly once, so the second call finds nothing to do.

TryBegin(ReferenceButtonType, int)

Claims a slot for a request that is about to be sent.

public static bool TryBegin(ReferenceButtonType type, int slot)

Parameters

type ReferenceButtonType

Which container.

slot int

Slot index within it.

Returns

bool

True when the slot was free and is now claimed.

Remarks

Returns false when the slot already has a request in flight, and the caller must then send nothing. A caller claiming two slots must check both before sending either, and release the first if the second refuses — see the panels' TryBeginPair.

Events

ResyncRequested

Raised when the client has been told its view of a container may be wrong and cannot work out the truth from the message alone.

public static event Action<ReferenceButtonType> ResyncRequested

Event Type

Action<ReferenceButtonType>

Remarks

Currently only ServerBusy, which means "outcome unknown" rather than "did not happen" — the server-side mutation was committed and only the acknowledgement went missing. Reverting on that reason would leave the client disagreeing with the server until the next login, so the panels re-render every slot from their replicated container instead. That is the best available answer: there is no server-to-client "resend this container" message today.

SlotPendingChanged

Raised when a slot starts or stops waiting on the server, so the owning panel can repaint its lock overlay.

public static event Action<ReferenceButtonType, int, bool> SlotPendingChanged

Event Type

Action<ReferenceButtonType, int, bool>

Remarks

Arguments: which container, which slot, and whether it is now pending. Panels must ignore containers that are not theirs — every panel hears every change.