Messages and sounds are presentation systems. They should be localized, rate-limited, context-aware, and unable to interrupt core feature behavior when a resource is missing.

Primary ownershipCurrent lobby or battle presentation context
Readiness anchorApplication readiness and a valid resource/event identifier
Version sensitivityVerify private names per client build

Presentation channels

Channel Use
System message Durable user-visible result or error in the lobby
Toast / notification Brief state change that does not require action
Battle message Time-sensitive battle feedback
Sound event Short confirmation or warning paired with visible context
Log entry Developer-facing diagnostics, not user notification

Current public source; version-sensitive. The notification-window manager stores lock keys in a set. The lockNotificationManager helper defaults its source to its own module name, shared by importing callers. Repeated acquisition of one key does not create nested ownership slots. Supply and retain a key for the logical owner whose cleanup will release it.

Illustrative Python 2.7 fragment for one logical overlay owner, while its lobby service is alive:

from gui.shared.lock_overlays import lockNotificationManager

_POPUP_LOCK_SOURCE = 'example_mod.overlay'

def acquire_popup_lock():
    lockNotificationManager(True, source=_POPUP_LOCK_SOURCE)

def release_popup_lock():
    lockNotificationManager(False, source=_POPUP_LOCK_SOURCE)

Pair acquisition with that owner's teardown. Independently owned operations or instances need separate keys or coordinated ownership; the helper does not count them. The vehicle progression presenter demonstrates an explicit state key and matching release. Manager-wide clear() also clears other keys and finalizes queued commands, so it is broader than releasing a feature's key.

Optional queue effects run only on key transitions. postponeActive=True attempts postponement before acquiring an absent key, and the manager refuses queue movement while another lock remains. releasePostponed=True runs only when releasing a present key; repeating an already completed unlock does not trigger it. When enabled, release can move the shared postponed queue and request current-window destruction even while another key remains.

Actual command execution still checks lock keys, enablement, waiting state and overlapping windows. Queue release is separate from visible presentation, retained notification cards and unread counters. These source contracts were inspected without operating locks, queues, windows or the game client; no live collision, lost notification or rendered outcome is established.

Read by topic