[Guffawaffle]

Kir'Shara queues can stall after queued targets disappear, or clear when another ship moves or recalls and native player-state handling temporarily reports the queued ship's starbase address. The address failure was reproduced with the mod DLL disabled.

One default-on setting enables the supported protections together:

[control]
kirshara_fixes = true

• Thin Queue Protection resumes after validated native pruning and confirmed destroyed queue heads.
• Faster Queue Recovery advances after a matching failed course response for an already removed target.
• Queue Address Guard uses the current owned deployment address only within the affected native queue comparison, after validating ownership, active state, recall/removal status and the target's full address.

Setting kirshara_fixes = false disables the combined behavior. The previous separate feature keys are ignored; legacy-only configurations receive a startup warning. Hook-install compatibility switches remain independent. Toggle Queue resets only the mod's pending response tracking; it never clears the native target queue.

The address guard changes no fleet fields or queue contents and adds no polling. Explicit clearing, recalling the queued ship and genuine address mismatches retain native behavior. Recovery/pruning support compatible Windows x64 clients; the address guard also has shared macOS code. The obsolete combat-completion repair remains retired.

Validation at 07a98a21: Windows release build, all three local queue suites and all 11 example TOML parses pass. Static entry-fit checks cover all 11 detour targets on the matching installed Windows client 272. Earlier address-guard gameplay controls passed on a prior downstream artifact; they do not qualify this candidate.

Fresh gameplay testing of this artifact and macOS native fit/runtime remain open. The focused smoke covers normal queued combat, outstanding-target removal and next-target handoff, queue clear/rebuild, off/on toggle, restart, A's queue surviving B's move/recall, and A's own recall clearing normally. macOS testers should use the exact PR artifact for their architecture and run the address controls. Delayed same-target course responses still lack a server request ID. Windows, Mac ARM64, Mac x86_64, universal Mac packaging and example-config CI all pass for this head.

[Guffawaffle]

This isn't working as well as my previous implementation on my personal branch. Moving back to draft until I figure it out.

[Guffawaffle]

This is now gloriously effective for me in group waves.

[Guffawaffle]

Hook/feature alignment follow-up for #313

Follow-up to #313: keep hook installation independent of feature enablement, with default-enabled compatibility switches under [patches] and feature checks inside the installed hooks.

InstallActionQueueRecovery() and InstallThinQueueProtection() return early based on [control].faster_queue_recovery and thin_queue_protection, and are called outside the patch registry. Register them with independent default-enabled [patches] switches, remove feature-based installer returns, and retain the existing runtime Enabled() checks (including queue_enabled). Preserve the Windows/metadata/layout compatibility checks and native planner behavior. This is a standalone correction.

Published c60b6f8: independent default-enabled queue hook switches, current runtime eligibility, disabled/toggle pending-request invalidation and full-family guards. Removed the unused feature-derived installation helper/assertions. Windows build at ff75bb5 passed; both policy suites reran after the final deletion-only delta, all 11 TOMLs passed, and three independent lanes reviewed full PR plus correction. Seven Windows270 static fits pass. Exact-artifact wave/toggle/partial-install execution remains unqualified; delayed same-target responses retain the documented request-ID limitation. New CI is queued; moving on without waiting.

[netniV]

So this would appear to empty the queue as soon as you disable the queuing system. However, some people may have hit that by mistake and/or actually want the queued to finish processing.

[Guffawaffle]

This only clears the mod's pending recovery tracking, so stale tracking doesn't carry across an off/on toggle. It leaves the game's target queue untouched, allowing existing targets to finish. I’ve renamed the helper and added comments to make that distinction clearer.

I'll dive in on a follow-up, if there's issues, when I have time to thoroughly test various scenarios around toggling queueing while the queue is running and how that impacts the mod's work.