feat: Add Kanturu Refinery Tower event (resubmission of #719)

[sven-n]

Resubmission of the stale PR #719 by @apraxico, rebased onto the current master and combined with the fixes @foxtnaider contributed on his kanturu-fixes branch, plus a review pass on top.

Credit for the implementation goes to @apraxico; credit for making it build and actually run goes to @foxtnaider, who tested the result end-to-end on a Season 6 server.

What it adds

The server-side logic for the Kanturu Refinery Tower mini-game (map 39), following the plug-in patterns of BloodCastle and ChaosCastle:

File	Purpose
KanturuContext	Event game loop: waves → Maya's hands → Nightmare → Tower of Refinement
IKanturuEventViewPlugIn / KanturuStates	View plug-in interface and the client state enums
KanturuEventViewPlugIn	Sends the 0xD1 packets to the client
KanturuGatewayPlugIn	Gateway Machine NPC which opens the entry dialog
KanturuStartPlugIn / KanturuStartConfiguration / KanturuGameServerState	Periodic start of the event
KanturuEnterRequestHandlerPlugIn / KanturuInfoRequestHandlerPlugIn / KanturuGroupHandlerPlugIn	Handlers for the 0xD1 client packets
KanturuInitializer	Seeds the MiniGameDefinition
AddKanturuDataUpdatePlugIn / AddKanturuMapContentUpdatePlugIn	Bring the configuration and the map content into existing databases

Modified: MiniGameType (new Kanturu value), GameContext (creates a KanturuContext), GameConfigurationInitializer, KanturuEvent (bosses and wave spawns), the server-to-client packet definitions and the player messages.

Fixes carried over from the follow-up work

• The seven Kanturu <Packet> elements were direct children of the root, outside <Packets>. GenerateExtensions.xslt only iterates the children of <Packets>, so the generator emitted nothing for them and the SendKanturuXxxAsync methods had been added to the generated ConnectionExtensions.cs by hand. A clean build overwrote them, which is the CS1061 build failure reported on feat: Add Kanturu Refinery Tower event implementation #719. The elements are now inside <Packets> and everything is generated.
• GameContext had no case MiniGameType.Kanturu, so the event fell through to a plain MiniGameContext: it opened the map, accepted players and then did nothing.
• The missing ObjClassH/ObjClassL arguments on SendKanturuMayaWideAreaAttackAsync (CS7036).

Review pass in this PR

• KanturuStartConfiguration.TowerOfRefinementDuration was write-only: GameContext constructs the context without the optional parameter, so the hard-coded one-hour default always won. The context now reads the value from the start plug-in's configuration.
• All 36 analyzer warnings the new files introduced are resolved (SA1201/1204/1210/1501/1515/1611/1623/1117, VSTHRD200, CS1574), including the six CS1591 warnings in the generated packet code, which are fixed by documenting the KanturuStateChange.StateType enum values in the packet definition.
• The 16 event wave spawns were maintained twice — once in KanturuEvent, once in AddKanturuMapContentUpdatePlugIn. They are now shared, and the monster numbers are named constants.
• The new GameServer plug-ins use localized PlugInResources names and descriptions like the other plug-ins there.
• The state enums moved out of the view plug-in interface file, the byte order mark of the two touched Season 6 files is restored, and the stale Nightmare coordinates in the map comments are corrected.

Verification

• dotnet build src/Startup/MUnique.OpenMU.Startup.csproj — clean, from a fresh checkout, with the packet generator running: 0 errors, no warnings from the new files, and the generated files are byte-identical to what is committed.
• dotnet build ... -p:ci=true (what the CI workflow runs) — 0 errors.
• dotnet test tests/MUnique.OpenMU.Persistence.Initialization.Tests — 12 passed, 2 skipped.
• In-game testing of the event itself was done by @foxtnaider (Maya rises, all three phases, both hands, Nightmare with its teleports, victory screen, tower opens; two characters, full clear) — see the screenshots on #719. I have not run the client myself.

Closes #719.

---

Generated by Claude Code

[didiconcs]

I tested this independently in a clean, isolated worktree (checked out 010c55a, the current tip of this branch), separate from my own working copy, so I could reproduce your verification steps end to end.

Build

• dotnet build src/Persistence/SourceGenerator/... then dotnet build src/Startup/MUnique.OpenMU.Startup.csproj -c Debug: 0 errors. 186 pre-existing warnings, none of them touching any Kanturu file (I grepped the full build log for "Kanturu" to confirm).
• I went a step further on the packet-generation claim specifically, since that's the root cause of the original feat: Add Kanturu Refinery Tower event implementation #719 failure: I ran the build without -p:ci=true (so the PreBuild target's XslTransformation/npx pipeline actually executes) and diffed the regenerated ConnectionExtensions.cs, ServerToClientPackets.cs and ServerToClientPacketsRef.cs against what's committed, byte-identical, git status clean. So the "generated files are byte-identical to what's committed" claim isn't just asserted, it reproduces.
• dotnet test tests/MUnique.OpenMU.Persistence.Initialization.Tests: 0 failed, 12 passed, 2 skipped, matches your numbers exactly.
• dotnet test tests/MUnique.OpenMU.Network.Packets.Tests --filter Kanturu: 9/9 passed.

The three problems from #719, confirmed fixed and wired end to end, not just patched locally:

1. Moonstone Pendant requirement. KanturuEvent.CreateMapAttributeRequirements() calls CreateRequirement(Stats.MoonstonePendantEquipped, 1), and the item itself (Jewelery.cs, item 38) attaches an ItemBasePowerUpDefinition that sets that exact attribute to 1 when equipped. The generic GameMapDefinitionExtensions.TryGetRequirementError (pre-existing, unmodified) reads player.Attributes[requirement.Attribute], so this is enforced through the same mechanism other maps already use, not something bolted on only for display.
2. GameContext mini-game factory. case MiniGameType.Kanturu: miniGameContext = new KanturuContext(...) is present and correctly placed before the default fallback to plain MiniGameContext.
3. XML packet placement. All seven <Packet> Kanturu elements are inside <Packets>...</Packets> in ServerToClientPackets.xml (verified with a line-range check), which is exactly what GenerateExtensions.xslt needs to emit the SendKanturuXxxAsync extension methods, and the regeneration test above confirms it actually does.

Other things I checked while reading the diff:

• KanturuStartConfiguration/KanturuEventDefinition.TowerOfRefinementDuration is genuinely read now (KanturuContext.RunTowerOfRefinementAsync at the _definition.TowerOfRefinementDuration line), so the "was write-only" fix holds up.
• The UpdateVersion enum entries (AddKanturuData = 112, AddKanturuMapContent = 113) are appended at the end, not inserted in the middle, good, that's the safe way to extend this enum without shifting existing migration ids.
• KanturuContext is noticeably more careful about concurrency than its siblings (BloodCastleContext only wraps a score counter in Interlocked); the Kanturu implementation guards the boss-teleport/health-check race and the barrier-open race with explicit Interlocked flags and comments explaining why. Nice attention to detail for code that runs across the game loop task and the OnMonsterDied event handler concurrently.
• AddKanturuMapContentUpdatePlugIn's KanturuMapContentSeeder subclassing KanturuEvent to reuse EventWaveSpawns/CreateMonsters instead of re-implementing the wave data is a good way to avoid the "maintained twice" problem the PR description mentions, and the comment explaining why it can't just call the regular CreateMonsterSpawns() path (deterministic-id collisions with the laser traps) is genuinely useful for future readers.

Minor nitpicks, nothing blocking:

• The diff to UpdateVersion.cs turns two previously-empty blank lines into lines with 4 trailing spaces (lines 552/567 in the new version), that's the source of the two SA1028 warnings in the build log. Trivial, but since the PR description specifically calls out "no warnings from the new files," worth a one-line fix since UpdateVersion.cs itself is a touched file.
• KanturuEventViewPlugIn.Convert/ConvertChange are two near-identical one-line casts (KanturuStateInfo.StateType vs KanturuStateChange.StateType, otherwise the same body). Not worth blocking on, just noting in case you want to fold it into one generic helper.
• KanturuGatewayPlugIn.SendKanturuStateInfoAsync's canEnter flag is derived purely from the event phase/timing, not from whether the player actually has the pendant equipped, so the client's Enter button can appear enabled for a player without the pendant, who then gets rejected by the map requirement check on WarpToAsync. That's consistent with how other OpenMU events surface this (the requirement message shows after the failed attempt, not proactively in the dialog), so I'm not asking for a change, just flagging it as the existing UX pattern rather than something new this PR should have handled differently.

I didn't manage to spin up the server end-to-end (no Docker/Postgres on my test machine) to click through Game Configuration → Mini Games in the AdminPanel, so I can't personally confirm the visual/admin side beyond what @foxtnaider already documented with screenshots on #719. Everything I could verify independently checks out: clean build, byte-identical codegen, full test suite, and a manual read of the three previously-reported bugs plus the surrounding code. Nice work pulling this together from two separate contributions.

[cloudflare-workers-and-pages]

Deploying openmudocs with    Cloudflare Pages

Latest commit:	d84958c
Status:	✅  Deploy successful!
Preview URL:	https://ba5f308b.openmudocs.pages.dev
Branch Preview URL:	https://claude-pr-719-review-resubmi.openmudocs.pages.dev

View logs