Fix Golden Invasion announcement to point at the dragon's real map

[nolt]

What

The Golden Invasion start/end broadcast ([{mapName}] Golden invasion!) now names the map(s) where the Golden Dragon actually spawns, instead of an unrelated, independently-chosen map.

Why

With the current code the announced map is drawn at random from the intersection of the display maps and all spawned maps. Because the minion mobs (Golden Budge Dragon → Lorencia, Goblin → Noria, Soldier/Titan → Devias …) always occupy the display maps, that draw is dominated by minions and is independent of where the Golden Dragon rolled. Result: the announcement matches the boss only ~1/3 of the time, and never when the dragon rolls Atlans/Tarkan.

This is a regression from the invasion-spawn-table refactor (PR 757). Previously the Golden Dragon was the "mob on the selected map" and spawned on state.MapId, so the announced map was guaranteed to contain it. The refactor turned the dragon into an ordinary RandomMap mob and split the display map into a separate random draw.

How

A plugin can now designate a featured monster via AnnouncedMonsterId, and the broadcast names that monster's real spawn map(s):

• RandomMap → the single map it rolled (read from state.SelectedMaps)
• AllMaps → every configured map, comma-separated (e.g. "Lorencia, Noria, Devias")

GoldenInvasionPlugIn announces the Golden Dragon; RedDragonInvasionPlugIn announces the Red Dragon (it had no bug — single mob — but is wired for robustness). When no featured monster is set, the previous EventDisplayMapIds behaviour is kept as a fallback.

Scope / non-goals

• The spawn strategy is unchanged — random vs. all-maps stays a per-mob config option; only the map name(s) put into the message changed.
• The global yellow broadcast itself is unchanged (still sent server-wide).
• The per-map event marker (IMapEventStateUpdatePlugIn) is intentionally left as-is. In AllMaps mode it still lights up on a single map; extending it to all maps would be a separate change.

Files

BaseInvasionPlugIn, InvasionGameServerState, SimpleInvasionPlugIn, GoldenInvasionPlugIn, RedDragonInvasionPlugIn (+97/-13).

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a regression in invasion event broadcasts where the announced map was often inaccurate due to random selection logic. By introducing a 'featured monster' concept, the system now dynamically identifies the specific map(s) where the boss monster has spawned, ensuring that server-wide announcements provide correct information to players. The changes maintain backward compatibility for events without a featured monster by falling back to the previous display map logic.

Highlights

• Featured Monster Announcement: Introduced a mechanism to link invasion broadcasts to the actual spawn location of a 'featured' monster, ensuring the announced map matches where the boss spawned.
• Invasion State Tracking: Updated InvasionGameServerState to track AnnouncedMapIds, allowing for accurate reporting of maps regardless of whether the spawn strategy is random or all-maps.
• Plugin Configuration: Refactored SimpleInvasionPlugIn and its subclasses (GoldenInvasionPlugIn, RedDragonInvasionPlugIn) to support an optional AnnouncedMonsterId parameter.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces the ability to announce the specific map or maps where a featured monster (such as the Golden Dragon or Red Dragon) actually spawned during an invasion event, rather than falling back to a generic display map. It updates the invasion state to track multiple announced map IDs and dynamically builds localized, comma-separated map names for start and end broadcasts. The feedback highlights two performance optimization opportunities: avoiding unnecessary array allocations when retrieving the announced maps, and pre-resolving map names to prevent redundant linear lookups for every active player during broadcasts.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[eduardosmaniotto]

Nice. There is another issue with the refactor that I was planning to work on:

• Old version (d0e30ab): Golden Dragon was in _mobsOnSelectedMap (no MapId). It spawned only on the randomly-selected event map from PossibleMaps = { Lorencia, Noria, Devias }. Never Atlans/Tarkan.
• Current version: Golden Dragon is in the unified Mobs list with explicit maps [Lorencia, Noria, Devias, Atlans, Tarkan] + SpawnMapStrategy.RandomMap. Can now spawn on Atlans/Tarkan.
• Root cause: Old code split mobs into "map-specific" (explicit MapId) vs "boss on event map" (no MapId, used PossibleMaps). New code unified everything into a single Mobs list where each entry declares its own eligible maps. When migrating, Golden Dragon's map list was expanded from the implicit 3 (PossibleMaps) → explicit 5 (original 3 + Atlans + Tarkan), which looks like it may have been accidental — the other mobs kept their original single-map assignments, but the boss's map pool grew.

Would it be possible for you to include this fix, removing Atlans/Tarkan from the Golden Dragon config?

[nolt]

Sure and its very good idea.

[nolt]

Done — added a commit that drops Atlans and Tarkan from the Golden Dragon's map list, leaving Lorencia, Noria and Devias (the original three). The golden minions on Atlans/Tarkan are untouched.

One heads-up on rollout: the invasion config lives in the plugin's CustomConfiguration (a serialized JSON blob in the DB), so the new default only applies to freshly seeded configurations. Existing installations keep their stored config — there's no need to reset anything, an admin just needs to open the Golden Invasion plugin config in the panel and remove Atlans and Tarkan from the Golden Dragon entry.

I deliberately didn't add a data-update plugin for this: there's no existing precedent in Updates/ for rewriting a plugin's CustomConfiguration, and for a two-map tweak a manual edit seems cleaner than a migration.