The page was a mock: it never read the database (always 0 accounts),
showed a hard-coded schema and core version, looked for server files in
the wrong folder, and its "transfer" reported accounts, characters and
tables as moved without moving anything. Its locale was fixed to "ru".
- remove server_migration.rs and its three commands
- modular_copy::preview: classic/modular core, version, database state,
counts and schemas from a running database (read only), database size,
settings files, extra worlds; nothing is started or changed
- the page shows that and hands over to the same modular-copy install
screen as "Manage another server"; texts in en and ru via i18n
- the modular copy now carries world settings changed in Server
Configuration (Settings/worldserver.conf.template was not copied)
- E2E preview_bare_and_copy_e2e checks the preview and the carried
setting; passes against preview core 0.261108.9501
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rows were separate grids with an auto-width action column, so the columns moved from row
to row; every column has a fixed width now. CoA's modules are not in the public catalogue:
their last push comes from the GitHub API (cached 12 h).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Build cache (build_cache.rs): the build folder of a module is unpacked for a
build and packed into <module>.tar.zst afterwards (object files ~4-6x
smaller), modification times kept so Ninja recompiles only what changed.
A cache made for another core is dropped instead of unpacked; .ilk and .map
files are not kept; total limit 2 GB, least recently built first. The build
log moves next to the archive (build-cache/<module>.log).
- "Build cache" in the Modules menu: size per module (packed, built when, for
this core or not), remove one, remove all, remove downloaded sources.
Builds now hold the server's busy guard, so the cache is never cleared
under a running build.
- Module sources: "Add from a link" downloads GitHub's archive of the commit
instead of a full git clone, and game-client files (.mpq, .dbc, maps,
textures, archives) are left out and listed in .coa_skipped_assets.
mod-bg-battle-for-gilneas: 365 MB repository, 3.1 MB kept (was refused at
the 300 MB limit).
- Overlay: Helias's battleground modules (Gilneas, Twin Peaks, Slavery Valley)
are Incompatible: they need the server's DBC files replaced (CoA ships its
own) and a client patch.
Checked: build_cache unit tests; examples/build_cache_ninja_check with real
MSVC + CMake + Ninja: after pack/unpack nothing is recompiled, after one edit
one file is; coa-core lib tests 865 passed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Header is just "Modules" with "Add from a link" (the GitHub URL bar is folded
away until asked for) and a menu for builds/logs, build tools and the
diagnostics export. The build-tools bar shows only when something is missing.
- Two tabs (Installed, Catalog) styled like the settings page.
- Catalogue: one list of rows (name, owner, category, stars, one action); CoA's
own modules first. Compatibility and sort are drop-downs; 20 functional
categories as chips with counts. "Checked by CoA" is the curated list only.
- Categories: owner's reviewed list (181 modules, high/medium confidence) plus
keyword rules for every other module (coa-module-categories.json).
- Catalogue statuses come from the current overlay on every read (a cached copy
kept the old Verified marks), and no more made-up entries for overlay rules
the public catalogue does not list (fake AGPL-3.0, 0 stars, duplicate mod-cfbg).
- Window size, position and maximized state persist (tauri-plugin-window-state,
visibility left to the app).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- A new server goes on to the preview core without compiling any module
(recommended modules are declined once; modules come from the Modules page).
- Choosing a server with the classic core makes a modular copy next to it:
every acore_* database (read from the running database, or from a private
copy of the stopped data files opened by the new server's own mysqld),
module configs and realm profiles, ports and console login. The old server
is only read. The copy then takes the preview core with the modules the old
server had switched on.
- Installs and the preview update run on unused ports, so a server running on
the shipped ports (the old one, or any other) no longer stops them; the
schema check after "Preparing database" used the shipped port before.
- Dungeon Clear is part of SQUID's Playerbots: no card of its own (it said
"Always on" while SQUID was off), switched with SQUID, settings on the SQUID card.
E2E (examples/preview_bare_and_copy_e2e, disposable servers, another server
running on the shipped ports): fresh install committed with no plugins and a
clean boot report; copy of a stopped and of a running classic server: data
identical, old server's files byte-for-byte unchanged, Content Scaling and
Companions built on the copy, preview core committed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The install used the stable image and left the preview core for a later
update, so a fresh Modules Preview server showed every module as built in
and no Plugin SDK. install_new now applies the preview update right after
the base install (same signed update and module build every server takes);
a failure leaves the classic core and the done screen says so, and modules
that did not build are listed. A hand-picked package and Docker keep the
old behaviour.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Modules page had a 'Register test-realm-v03' button and the app registered a hardcoded local
folder into an empty server list at startup. Both pointed at a developer's machine. The startup
registration now happens only when COA_TEST_REALM_DIR is set. test_detect_toolchain skips when the
local spike realm is absent (CI runners).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
preview_channel_e2e installs from the stable channel, takes the preview from the published preview channel
the way the Manager does, and checks the server is current afterwards. preview_migration_e2e gains a squid
mode that keeps SQUID's SQL journals and expects SQUID's Playerbots instead of Companions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stable packages from 0.261104.94 need Manager 0.9.8; the preview was 0.9.7.
Conflicts kept the preview's module screen and plugin-aware module logic, took
master's requires-squid compatibility value and version 0.9.9 under the
preview's own product name and identifier.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
coa-release derive-preview verifies the stable update package, unpacks it,
replaces the core binaries with the plugin host build (same core commit),
adds Core/plugin-sdk.zip and Core/plugins/recommended.json, and repacks it
with the stable migrations, configuration and scripts unchanged. The result
is signed with the preview key by coa-release sign.
Tried on server-0.261104.94 and a CI plugin host: 37256 files, 3417
migrations, signature/archive/schema contract verified; the stable key
rejects the package (env-driven test).
New servers in the preview Manager are installed from the stable image; the
preview core arrives as the first update.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- keys/preview-signing.pub: preview packages and the preview pointer are
signed with a separate key, so a stable Manager (stable key only) can never
accept them. The preview Manager trusts both keys for packages (it starts
from stable servers and stable base packages); each channel pointer must
carry its own key's signature.
- Channel 'preview': pointer preview.json on the preview-channels branch,
releases preview-server-<version>. The app resolves it first and falls back
to stable until a preview release exists.
- coa-release public-key prints the public half of the signing key;
sign-channel writes the channel's own release tag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A core that loads Content Scaling, Companions and SQUID as plugins ships
Core/plugins/recommended.json with the module repositories and commits. During
the update (the move from a monolithic stable server) the Manager downloads
each module as GitHub's archive of that commit (no git needed), builds it with
its bundled trees, installs and enables it, before the trial start. Rules keep
the bot choice: SQUID only if it was switched on in playerbots.conf, otherwise
Companions. Handled modules are remembered so a removed module is not
reinstalled; a failed one is retried at the next core change.
Verified on a CI core: Content Scaling (+packs) and Companions downloaded,
built, installed and written to the plugin lock in 225 s.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Modules must be compiled by the core's exact compiler. The Toolchain tab now
offers Microsoft's stable-channel Build Tools bootstrapper (VS 18) with the
14.44 toolset, core build tools, Windows SDK 26100 and CMake preselected:
downloaded from aka.ms, Authenticode-checked for Microsoft, run in its own UI
(modify mode for an existing Build Tools 18). Shows the required and selected
cl.exe versions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- The host records its own ABI fingerprint (.coapl); the manager reads it from
worldserver.exe instead of hardcoded fingerprints (solver, provenance, analyzer).
- SDK store per realm: <realm>/.manager/sdk/<16 hex of fingerprint>/, chosen by
the host fingerprint; install_realm_sdk refuses an SDK of another core.
- Dungeon Clear is built into the SQUID DLL (bundle); persistent build cache.
- Refuse layouts whose header paths exceed Ninja's Windows path limit (such
headers counted as changed and every build became a full rebuild).
- Compile jobs limited by free RAM; full build log kept in build.log; failures
without an MSVC diagnostic report the failed step and the log tail.
Bundle test: full build 1425 s, after a one-file change 9.7 s.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Starting a server that is open to friends adds the firewall rules for the
world ports of all realms that start together (only missing ones; a refused
Windows prompt does not undo the start).
- Settings shows one public-listing block per realm that starts together. The
main realm keeps its plain local id, so an existing listing is untouched.
- A realm that runs as an extra world is reached through that world's own
console port, so its listing reports its own state and capabilities.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Settings gets two options, one per extra realm; turning on both runs all
three realms. Each extra world keeps its own folder, configs, logs and
ports (multiworld now handles a set of worlds instead of one second world),
and Warcraft Reborn gets its own status card, realm list entry and firewall
rule.
Starting a server also sets CoA.ClassModel of the realm chosen on Overview
to exactly that realm's model, so the shipped "coa wcr" default no longer
shows two class models on a Conquest of Azeroth realm.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
