* Share migration planning and execution across update phases
* Apply updates in one recovery-backed pass without nested server rehearsals
* Preserve applied core SQL and share account migration history across realms
- Implement LibSerialize v1, raw DEFLATE and print base64 codec in glue_config
- Prefill login credentials in join_realm, portable_launch and play
- Preserve all existing saved client accounts without loss
- Rebuild production 0.7.0 NSIS artifacts and update SHA-256 checksums
The world refusing to start with the standard Data set (no CoA DBC) is now
reported as GameDataMismatch. A Settings card shows the folder in use and
changes it while the server is stopped, using the install checks.
Second part of the audit of every screen for a Docker server. What it found, and
what now happens:
- Play with friends. "Servers open" read the BindIP of the configuration files, which
the containers force to 0.0.0.0, so it was green on a fresh server while who can
connect is decided by the address the ports are published on (bindAddress in
docker.json). Opening and closing now edit bindAddress (and set
CoA.AllowRemoteClients), the open state is read from it, and enabling a mode no
longer fails on netsh / PowerShell after it already rewrote the files. There is no
firewall row on Linux (Docker publishes the ports itself); the Windows reply is
unchanged.
- The "private services" check (Friends and Diagnostics) could never fail on Linux: it
reads the Windows listener table. For a Docker server it is computed from how the
ports are published: the database never, the console only on 127.0.0.1, the game
servers on bindAddress.
- Console, Database tab: read a mysql log file that does not exist; it shows
`docker logs` of the database container.
- The Overview showed a service that had stopped by itself as "Stopped"; it now says
"Stopped unexpectedly".
- Settings: a Docker server that was added but never started had no
worldserver.conf and the page failed; it is created from its template. A talent
file path outside the Core folder is refused (the container cannot see it).
- Backups of configuration now include docker.json; verifying the files of an
imported Docker server looked for worldserver.exe and reported it missing.
- Linux locations: the friend package and the diagnostics go to the desktop folder
(from the user directories file) instead of /tmp, the problem report names the
distribution, and the size advice for companions reads /proc/meminfo instead of
assuming 8 GB.
Every Windows branch is the code that was there; the dispatch is the early return on
docker::is_docker (or the host flavor for the firewall).
client::launch started Ascension.exe directly, which cannot work on Linux, and
client::is_running found nothing (it reads the Windows process list). wine.rs is
the Linux counterpart, and both hand over to it on a Linux host.
It runs the command of the project's own launcher script: umu-run with a Proton
build (GAMEID=0, PROTONPATH, WINEPREFIX, started from the client folder), else
plain Wine, with WINEDLLOVERRIDES=divxtac=d (DivxTac.dll deadlocks the world
loading screen under wine-mono). The newest GE-Proton found for Steam is used, or
umu's own choice; COA_PROTONPATH, COA_WINEPREFIX and client-launch.json override
the detection; the prefix defaults to ~/Games/umu/coa-client. The game runs in its
own process group, so closing the Manager does not close it, and prints to
client.log. Whether it runs is read from /proc, where the command line holds the
Windows form of the client path. A clear message says what to install when neither
umu nor Wine is found.
Tests: detection (newest build, no build, Wine only, nothing, overrides), the
command, the /proc match, and a real spawn with a stand-in umu-run that records its
environment. Not run: the real client.
The Realm card showed "io: No such file or directory (os error 2)" on a Docker
server: the Wildcard check read Core/worldserver.exe. The card lets the owner
switch realm, so it is made to work rather than hidden.
What the repack's patched launcher did at each start is done by the Docker
backend: finish an interrupted switch (realms::before_start), name the realms in
the realm list, and give the containers the databases of the selected realm
(acore_world_wildcard, acore_characters_wildcard). The switch itself is the shared
code. prepare_launcher has nothing to patch on a Docker server, and Wildcard
support is read from Core/worldserver as it is from Core/worldserver.exe (the .exe
wins when both exist, so a repack is read as before).
Tests: the support check on both binary names, no launcher to adapt, and the
databases passed to the containers for each realm. Creating the Wildcard realm
itself needs a build and a database with the Wildcard migrations and was not run.
Found by installing a server through the new screen: the update check of a Docker
server read the Windows "stable" channel and offered "0.261003.17 (you have
0.261003.1)". Applying it would have put the repack's executables, MySQL and
launcher into a Linux server folder.
Refused in the core (update::preview, apply and rollback), so no caller can do it.
The Settings tab says that updates are not available for Docker servers yet; the
background check stays quiet, as for any failed check.
A test applies the same update package to the same folder with and without
Settings/docker.json: refused and untouched with it, committed without it.
The install commands ask coa_core::platform::flavor() once and hand a Docker
install to src-tauri/src/docker_install.rs; the repack arm of each command is
untouched (an early return and an extra optional parameter are all that changed
in lib.rs). New command install_environment tells the screen the kind of server,
the suggested folder (~/CoaServer) and why Docker cannot be used, if it cannot.
On Linux the install screen shows the game data folder (used in place, read-only)
and the server package (a folder or an address; there is no default address until
a signed Linux package is published), and disables Install until both are given
and Docker works. It shows Docker's own message with a "Check again" button when
Docker is missing, stopped or not allowed for the user. The Windows screen is
unchanged (checked side by side in the browser mock).
A debug build (tauri dev) accepts another package key named in
COA_DEV_TRUSTED_KEY, to try the installer on a package signed with a throwaway
key; a release build always uses the embedded key.
New text is English only for now (other languages fall back to it).
crates/coa-registry-proto (protocol 1: types, limits, signed-request canonicalisation, test vectors),
services/coa-registry (axum + PostgreSQL, migrations, rate limits, Dockerfile, deploy files),
services/coa-registry-e2e (Host lifecycle against the real service, live VPS gate),
coa-core realm_registry (identity keys, client, publishing loop on its own thread),
Settings -> Public listing card, docs REGISTRY_PROTOCOL.md and REGISTRY_DEPLOYMENT.md.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Conflicts were additive only: the rusqlite and if-addrs dependencies sit side by side, and the
portable.* and fr.lan.* translation blocks are both kept in en and ru.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Characters screen (realms, make portable, preflight with the projection warning, one-click Play,
status chips, saved versions, diagnostics), Tauri commands, runtime started and stopped with the
application, native pin recorded on make-portable, degraded state derived from stored projection,
history in words instead of session identifiers, live test for make-portable then arm.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The signed base package holds the MySQL data directory of a Windows repack. On a
Linux computer extract-schema-base now turns it into a Docker server folder whose
database container opens that directory (mysqlData in docker.json), so the release
SQL, the schema contract and export-baseline run with the Docker installation code.
Windows is unchanged: it still bootstraps the repack's own database program.
Corfirean