Revert "Feature/continuumatrice product migration"

This commit is contained in:
Christian Daniel Jensen 2026-11-03 18:51:23 -07:00 • committed by GitHub
parent 533d2f04c1
commit e49d053838
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
150 changed files with 2599 additions and 5304 deletions

View file

@ -73,7 +73,7 @@
<xs:element type="xs:boolean" name="landscapeOrientation" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:element name="continuumatrice_carddatabase">
<xs:element name="cockatrice_carddatabase">
<xs:complexType>
<xs:sequence>
<xs:element name="info" minOccurs="0" maxOccurs="1">

View file

@ -1,107 +0,0 @@
# Hosting Continuum-Servatrice
**Continuum-Servatrice** is Continuumatrice's dedicated multiplayer server. It is built from the existing Servatrice C++ implementation, including accounts, lobbies, rooms, replays, game synchronization, TCP and WebSocket networking, and MySQL support. It also registers the three additional public pile zones: Limbo, Refuge, and Oblivion.
You may run it alongside upstream Servatrice, but **never reuse the MTG server's database, schema, account tables, process name, or service configuration.**
## Build client and server together
On Linux with the existing development dependencies, from the repository root:
```bash
cmake -S . -B build --fresh -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DWITH_CLIENT=ON -DWITH_SERVER=ON -DWITH_ORACLE=OFF
cmake --build build --target continuumatrice continuum-servatrice --parallel 16
```
Executable paths:
- Client: `build/continuumatrice/continuumatrice`
- Dedicated server: `build/continuum-servatrice/continuum-servatrice`
The inherited source directories `cockatrice/` and `servatrice/` remain for source compatibility. The **binary build directories and targets are distinct**.
`WITH_SERVER` is `ON` by default; use `-DWITH_CLIENT=OFF -DWITH_SERVER=ON` for a dedicated server-only build (e.g., on a Linux host). This project deliberately excludes the upstream Magic Oracle importer.
## New independent MySQL schema
The repository includes `servatrice/continuum-servatrice.sql`. This is **not** the old `servatrice.sql`: its table identifiers use the `continuum_servatrice_` prefix matching the fork server configuration. Do not apply these SQL scripts to a production MTG Servatrice database.
Create a separate database and limited account using MySQL. The following is an example for local MySQL (choose a real, strong password and do not commit it):
```sql
CREATE DATABASE continuum_servatrice CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'continuum_servatrice'@'localhost' IDENTIFIED BY 'REPLACE_WITH_A_STRONG_PASSWORD';
GRANT ALL PRIVILEGES ON continuum_servatrice.* TO 'continuum_servatrice'@'localhost';
```
Execute those statements as a MySQL administrator, for example `mysql -u root -p`. Then initialize the *empty* database:
```bash
mysql -u root -p continuum_servatrice < servatrice/continuum-servatrice.sql
```
This schema contains user and room tables; it is not the card catalogue. Card XML and images live on the client, and users joining the same game should use compatible Continuumatrice card databases.
**Schema lifecycle:** The fork's new base SQL is isolated. Upstream schema migration scripts under `servatrice/migrations/` have not all been converted to the new prefix. Review/adapt each future migration against a **backup** of the fork database; never run the upstream migration scripts blindly on either product.
## Configure server
```bash
mkdir -p ~/.config/continuum-servatrice
cp servatrice/continuum-servatrice.ini.example ~/.config/continuum-servatrice/continuum-servatrice.ini
chmod 600 ~/.config/continuum-servatrice/continuum-servatrice.ini
```
Edit the private INI file, at least:
```ini
[server]
name=Continuum-Servatrice
host=any
port=4757
websocket_host=any
websocket_port=4758
[database]
type=mysql
prefix=continuum_servatrice
hostname=localhost
database=continuum_servatrice
user=continuum_servatrice
password=REPLACE_WITH_YOUR_MYSQL_PASSWORD
```
Those are the **fork's example ports** (TCP 4757, WebSocket 4758), separate from the usual upstream 4747/4748. The server supports other ports. If you run multiple game servers on the same host, explicitly choose distinct bound ports and independently configured databases.
To start in the terminal:
```bash
./build/continuum-servatrice/continuum-servatrice \
--config "$HOME/.config/continuum-servatrice/continuum-servatrice.ini" \
--log-to-console
```
A successful start requires database connectivity, a compatible schema, and available ports. Check the server's diagnostics rather than assuming a process that exits is running correctly.
For Internet hosting, use firewall rules scoped to the ports you intend to expose, configure TLS / a secure reverse proxy for WebSockets, and avoid exposing MySQL directly to the Internet. The sample file has inherited settings for authentication, room permissions, email, and moderation; review them before public launch.
## Client/server compatibility
Continuumatrice supports standalone local games without a dedicated server. For remote games, use a **matching Continuum-Servatrice build**. Ordinary upstream Cockatrice servers don't define the `limbo`, `refuge`, or `oblivion` zone IDs.
## Production verification
- [ ] Client and server both compile from the same Git commit.
- [ ] They create `build/continuumatrice` and `build/continuum-servatrice` with correct filenames.
- [ ] Server starts with `--config` and can connect to the **independent** MySQL schema.
- [ ] Account registration/authentication, room joining, game creation and reconnect work.
- [ ] Cards move correctly into Limbo, Refuge and Oblivion for both players and after reconnect.
- [ ] TCP and WebSocket connect on the configured ports.
- [ ] No accesses to upstream MTG databases, profile directories, sockets, or HTTP update services.
- [ ] No migration script alters a production database without backup/review.
- [ ] Service hardening, logging, TLS and restart management are in place before public launch.
**Status:** Committed source changes; dedicated server compilation, MySQL initialization, and runtime validation still need to be performed on the deployment system.

View file

@ -10,18 +10,16 @@ Cockatrice's three visual table rows are reused as **Front**, **Support**, and *
## Optional color customization
The default zone colors are **Front `#dc143c` (Crimson)**, **Support `#c3b091`**, and **Command `#0a0e3f`**.
To override the defaults, create `battlefield.ini` in your active **Continuumatrice** theme directory:
Create `battlefield.ini` in the active Cockatrice theme directory:
```ini
[Zones]
Front = #dc143c
Support = #c3b091
Command = #0a0e3f
Front = #A08E343D
Support = #A0286981
Command = #A05E428C
```
Qt accepts `#RRGGBB` for opaque colors and `#AARRGGBB` to specify transparency. The built-in defaults above are opaque; a theme can set translucent overrides explicitly. An existing `battlefield.ini` still takes precedence over these defaults. Reload the theme to apply changes. The default layout places Front closest to the opposing player's battlefield and Command closest to each player's hand. As in Cockatrice, the **Invert vertical coordinate** setting reverses the row placement (and its labels) when enabled.
The Qt color notation is `#AARRGGBB`, including transparency. Without this file, built-in red, teal, and purple shades are used. Reload the theme to apply changes. The default layout places Front closest to the opposing player's battlefield and Command closest to each player's hand. As in Cockatrice, the **Invert vertical coordinate** setting reverses the row placement (and its labels) when enabled.
## Font

View file

@ -30,13 +30,13 @@ Qt follows the XDG environment variables if set; the paths above are defaults, n
## Card database format
Continuumatrice reads its native **Continuumatrice XML v4**, and also accepts legacy Cockatrice XML v4 for import (schema `doc/carddatabase_v4/cards.xsd`). This is a database description and card list, not the rendered card images. You do not need to build new parsing logic to playtest your own cards.
Continuumatrice currently reads **Cockatrice XML v4** (schema `doc/carddatabase_v4/cards.xsd`). This is a database description and card list, not the rendered card images. You do not need to build new parsing logic to playtest your own cards.
A self-contained *test-only* main database `cards.xml` can look like:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<continuumatrice_carddatabase version="4">
<cockatrice_carddatabase version="4">
<sets>
<set>
<name>CTEST</name>
@ -70,7 +70,7 @@ A self-contained *test-only* main database `cards.xml` can look like:
<tablerow>2</tablerow>
</card>
</cards>
</continuumatrice_carddatabase>
</cockatrice_carddatabase>
```
These names are examples, **not** Continuum Universes lore or playable canon.
@ -103,7 +103,3 @@ For reliable matching across reprints, the importer also recognizes names incorp
7. Check normal Cockatrice's profile is still intact and can open separately.
**Magic Set Editor** is an editor for card layouts and card content, but its native project format is not Cockatrice XML v4. You will need a matching export script/template or a conversion pipeline that writes this XML and the image files.
## Native XML root
Continuumatrice generates and accepts `<continuumatrice_carddatabase version="4">`. Existing `<cockatrice_carddatabase version="4">` files are still accepted by the parser, so older set-export pipelines can be migrated safely rather than rewritten blindly.

View file

@ -1,69 +0,0 @@
# Continuumatrice CCG card fields and numeric sorting
This document covers **static card-definition metadata** loaded from Continuumatrice XML v4. It does not change mutable game resources, damage, armour degradation, campaign state or server match mechanics.
## Source mapping
| Continuumatrice field | Native XML v4 property | Field in existing Continuum MSE game | Legacy import fallback | Sorting |
| --- | --- | --- | --- | --- |
| Identity | `identity` | `alias` | `alias` | Locale-aware text |
| Attack (ATK) | `attack` | `strength` | `strength`, or Attack side of `pt` | Numeric |
| Armour | `armour` | `armor` | `armor` | Numeric |
| Health (HP) | `health` | `health` | Health side of `pt` | Numeric |
| ATK/HP | Derived from Attack and Health | MSE `strength` + `health` | `pt` via the individual stat fallbacks | Attack numeric first, then Health numeric |
**Identity** is the CCG's **card alias**. It must not be confused with `essence` (which is the distinct Essence resource/type identity). The `Name` column still contains the actual card name.
The XML importer already supports arbitrary text properties under `<prop>`, so adding these properties does not require a schema version change.
## Example
```xml
<card>
<name>Example Character</name>
<text>Static card data demonstration only.</text>
<prop>
<type>Character</type>
<identity>The Guardian</identity>
<attack>10</attack>
<armour>3</armour>
<health>12</health>
<essence>M</essence>
</prop>
<set>EXAMPLE</set>
<tablerow>0</tablerow>
</card>
```
The table view displays ATK/HP as `10/12`, with separate **Attack**, **Armour**, and **Health** columns. If a card has no authored stats, the combined display remains blank. When one stat is omitted, the missing side is shown as `?`.
The database's sort dropdown discovers model columns dynamically, so the new fields are available for ascending/descending sorting. Numeric fields use numeric comparisons; the combined ATK/HP column sorts by Attack first and Health second. The former `P/T` column position is retained internally for compatibility with existing saved table views.
## Exporter compatibility
The matching Magic Set Editor exporter change is in `Continuum-Universes-MSE-Templates`:
- `card.alias` → `<identity>`
- `card.strength` → `<attack>`
- `card.armor` → `<armour>`
- `card.health` → `<health>`
The MSE internal field identifiers are **not renamed**: that would otherwise risk breaking existing `.mse-set` files, render scripts and card styles.
Older XML exports with `strength`, `armor`, `alias`, or `pt` remain readable. Native properties take precedence whenever present; no automatic rewriting of existing files occurs.
## Test checklist
```bash
cmake --build build --target continuumatrice carddatabase_test model_contract_test --parallel 16
ctest --test-dir build -R 'CardInfoTest.ContinuumIdentityAndStatsHaveNativeAndLegacyPropertyAccess|ModelContract.ContinuumCardStatsAreSortableAndLabeled' --output-on-failure
```
- [ ] Import an MSE-exported set and verify Identity, Attack, Armour, Health and ATK/HP columns.
- [ ] Check Attack `9` precedes `10` and Armour `2` precedes `10`.
- [ ] Check ATK/HP sorts on Attack then Health.
- [ ] Verify legacy fields are still readable and an empty field is not assumed to mean zero.
- [ ] Verify the card details pane displays the new names, including **Armour**.
- [ ] Verify the existing Essence filter still operates independently of the Alias/Identity property.
**Status:** Source changes committed; native compilation, tests and MSE GUI export still need local runtime verification.

View file

@ -1,111 +0,0 @@
# Continuumatrice Essence symbols (CCG card catalogue)
Continuumatrice uses **Essence** for card resources, not Magic: The Gathering mana. The canonical Essence symbol order is:
```text
M S O G E A Q C J B R L V T P N
```
These are **16 distinct symbols**. `N` is explicitly **colorless Essence**. The non-colorless codes use the existing MSE gemstone mappings (including **J = Jasper**), but the client does not assign their final artwork, gameplay rules or resource behavior. Do not infer anything from similarly named MTG mana letters. All Essence codes are uppercase.
## Native Continuumatrice XML v4
The parser supports arbitrary XML `<prop>` entries, so no change to the existing XML v4 schema format is needed. These three native property names are defined in `libcockatrice/card/game_specific_terms.h`:
| Property | Meaning |
| --- | --- |
| `essencecost` | Card's explicitly authored Essence cost, e.g. `{M}{S}{N}` |
| `essence` | Card's explicitly authored Essence identity/types, e.g. `MSN` |
| `essencevalue` | Optional numeric aggregate value for existing cost-curve UI; this is not calculated from cost |
**Test-only sample**, not a playable/canonical card:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<continuumatrice_carddatabase version="4">
<sets>
<set><name>CTEST</name><longname>Essence Import Test</longname></set>
</sets>
<cards>
<card>
<name>Essence Sample Card</name>
<text>Test Essence symbol rendering only.</text>
<prop>
<type>Test Card</type>
<essencecost>{M}{S}{N}</essencecost>
<essence>MSN</essence>
</prop>
<set num="001">CTEST</set>
<tablerow>1</tablerow>
</card>
</cards>
</continuumatrice_carddatabase>
```
Do not automatically derive `essence` or `essencevalue` from `essencecost` until gameplay rules define the correct relationship. The card database **stores metadata**, not mutable match resource balances.
Previously authored XML `<manacost>`, `<colors>`, and `<cmc>` properties remain readable by the inherited `CardInfo` API for compatibility, but new Continuumatrice cards should use the native properties. Format compatibility does **not** mean MTG `W` or `U` are accepted as Essence symbols.
## Icons and custom asset assignment
All 16 Essence letters have small bundled SVG **placeholder** icons under:
```text
cockatrice/resources/icons/essence/
M.svg S.svg O.svg G.svg E.svg A.svg Q.svg C.svg J.svg B.svg
R.svg L.svg V.svg T.svg P.svg N.svg
```
Each is rendered using an independent `icons/essence/` asset namespace. In the currently selected Continuumatrice theme you may override any SVG with an SVG, PNG, JPG or JPEG using the same stem:
```text
~/.local/share/Continuumatrice/themes/<YourTheme>/icons/essence/
M.svg
S.png
N.svg
```
The current bundled placeholders show just the letter. **J = Jasper** (matching the existing Continuum MSE authoring templates). `N` is neutral gray; the others use a shared neutral treatment. They are **not** final Essence artwork or a commitment to elemental color assignments. The chart interface uses a separately generated *chart-only* palette so sixteen statistical series can be distinguished.
## Features updated
- Card database properties: native Essence cost, identity and optional value, with fallbacks for older XML.
- Card information display and deck editor column headers: `Essence`, `Essence Cost`, `Essence Value`.
- Visual Deck Storage and Visual Database filters share a compact `Essence: Any` dropdown with a 4×4 grid of all 16 icons. Select multiple icons without closing the popup, clear selections within the popup, and change filtering mode **inside that same popup**. Only one compact control occupies the toolbar. The dropdown summarizes selected Essence codes and supports N independently from C.
- Cost parser: single Essence symbols in bare form (`MSN`) or braces (`{M}{S}{N}`); numeric tokens may be preserved as generic amounts.
- Deck identity: unique, ordered Essence codes (including `N`).
- Search filters: filter for specific Essence codes, or `colorless` meaning `N`. An empty identity is not automatically `N`.
- Analytics: counts all 16 Essence cost symbols. Production counts only literal `Add {M}`-style grants to avoid guessing any resource rules.
Hybrid, phyrexian, and other MTG-specific mana-cost syntax are **not** introduced as Essence mechanics. Nor is automatic calculation of resource costs, card affordability, or game turn rules included.
## Compact Essence filter UI
The former five-button MTG `WUBRG` filters are replaced in both Visual Deck Storage and Visual Database. On either screen, click `Essence: Any` to open a **4-column × 4-row** grid of the complete Essence set. Each icon can be toggled independently and the menu stays open for multiple selections. Use **Clear Essence selection** to reset. The button summarizes your selection, and the filtering mode remains available **inside** the popup (Exact Match / Includes / Excludes in deck storage, or Include / Exclude in the database).
The picker is a single reusable Qt widget (`essence_filter_picker.h/.cpp`). This keeps both screens synchronized with `Essence::symbols()` without repeating a hand-maintained UI list. The UI uses SVG assets from `icons/essence/`, never old MTG `icons/mana/` assets.
## Build and verification
From `feature/continuumatrice-essence`:
```bash
cmake -S . -B build --fresh -G Ninja -DCMAKE_BUILD_TYPE=Release \
-DWITH_CLIENT=ON -DWITH_SERVER=ON -DWITH_ORACLE=OFF -DTEST=ON
cmake --build build --target continuumatrice continuum-servatrice essence_types_test --parallel 16
ctest --test-dir build -R EssenceTypesTest --output-on-failure
./build/continuumatrice/continuumatrice
```
Verify that all sixteen icons render, `N` loads and filters separately from `C`, the XML importer accepts `essencecost` and `essence`, and the analytics show no WUBRG assumptions.
**Status:** Source-level implementation committed. User-side Qt compilation and visual/runtime testing remain required.
## November UI stability fixes
The database toolbar now keeps its Essence filtering mode **inside** the picker popup, rather than forcing two separate controls into a wrapping flow layout. Both Visual Deck Storage and Visual Database use one compact toolbar button with a selection summary and tooltip. The popup grid is unchanged (16 icons, four columns × four rows).
When the final selected Essence is cleared, the filter becomes **Any**, including in Exact Match / Include-Exclude mode; it must not leave behind exclusions for all sixteen symbols.
A new Continuumatrice profile starts with a valid, deliberately empty XML card catalogue. The in-memory database now treats a successful empty snapshot as `LoadStatus::Ok`, not `NotLoaded`. This allows the card browser and toolbar to initialize even before the user's first MSE card import. `carddatabase_test` covers this distinction.

View file

@ -1,59 +0,0 @@
# Running Continuumatrice alongside Cockatrice (Linux)
Continuumatrice is an independent application. You can keep normal upstream **Cockatrice for MTG** installed and run both without mixing profiles or overwriting executables.
## Binary and build target
The CMake client target is now `continuumatrice` on every platform. A compatibility build target named `cockatrice` remains for older automation, but it creates **no executable** with the old name.
```bash
git pull --ff-only origin feature/continuumatrice-product-migration
cmake -S . -B build --fresh -G Ninja -DCMAKE_BUILD_TYPE=Release -DWITH_CLIENT=ON -DWITH_SERVER=ON -DWITH_ORACLE=OFF
cmake --build build --target continuumatrice continuum-servatrice --parallel 16
./build/continuumatrice/continuumatrice
```
If you previously compiled the fork under the old name, `build/cockatrice/cockatrice` can remain as an **outdated, stale executable** in the build directory. Launch `build/continuumatrice/continuumatrice` instead. Do not remove your system's normal `/usr/bin/cockatrice` application.
The standalone executable on Linux installs as `bin/continuumatrice`. The new `continuumatrice.desktop` launcher installs alongside the normal `cockatrice.desktop`. Its application name and desktop-file ID are also `continuumatrice`, so Wayland and desktop launchers distinguish the applications.
The fork installs its own original `continuumatrice.svg` icon, separate from Cockatrice artwork. The independent desktop launcher and `continuumatrice://` URI scheme do not take ownership of upstream `cockatrice://` links or `.cod` deck associations.
This fork intentionally does **not** install Cockatrice's `cockatrice-cod.xml` MIME handler or register the `cockatrice://` URL scheme in the new Linux desktop file. The normal MTG client keeps its default deck file and URL associations.
## Data isolation
Assuming typical XDG locations (and no `portable.dat` file):
- Data and databases: `~/.local/share/Continuumatrice/`
- Decks: `~/.local/share/Continuumatrice/decks/`
- Card images: `~/.local/share/Continuumatrice/pics/`
- Custom XML: `~/.local/share/Continuumatrice/customsets/`
- Preferences: `~/.local/share/Continuumatrice/settings/`
- Cache: `~/.cache/Continuumatrice/`
- Linux shared translations: `<install-prefix>/share/continuumatrice/translations`
- Linux shared themes: `<install-prefix>/share/continuumatrice/themes`
Its per-user single-instance local socket uses a Continuumatrice-specific name.
## System installation (optional)
If you want a separate `continuumatrice` command and a graphical launcher, first configure the build with a prefix of your choice (e.g., `/usr/local` for a system install). Then:
```bash
sudo cmake --install build
```
This uses the build's existing `CMAKE_INSTALL_PREFIX`; check `build/CMakeCache.txt` if unsure. The Linux client-specific install rules do not replace `bin/cockatrice` or `cockatrice.desktop`.
For immediate testing, skip installation and run the executable directly from the build tree. This change has not been compiled in this environment; verify with your openSUSE compiler.
## Cross-platform status
This migration also gives the Windows and macOS application package and URL registrations separate names. Those packaging flows have **not** been validated on Windows or macOS; installers must not be published until installation, upgrade, and uninstall testing demonstrates that neither platform affects upstream Cockatrice.
## Dedicated multiplayer server: Continuum-Servatrice
Both components are built by default. The server target is `continuum-servatrice` and its binary is `build/continuum-servatrice/continuum-servatrice`. The original MTG Servatrice executable and configuration are not used.
See [server hosting guide](continuum-servatrice-hosting.md) for the isolated MySQL schema and configuration commands. The default sample ports are TCP **4757** and WebSocket **4758**, chosen not to collide with MTG Servatrice's 4747/4748. Hosting outside your local network requires explicit firewall/reverse proxy/TLS planning.

View file

@ -1,83 +0,0 @@
# Match Essence pools (Continuum Universes CCG)
Continuumatrice matches provide **16 independent Essence balances per player**, using the canonical sequence:
```text
M S O G E A Q C J B R L V T P N
```
**J** is Jasper; **N** is colorless. These are not Magic mana colors, and Essence is not primarily obtained by drawing land cards.
## Behavior
The client displays a compact **4 × 4 Essence Pool** in a reserved column beside each player's battlefield. The panel shows the user's installed `icons/essence/<code>.svg` artwork and the current quantity, including zero.
- **Left-click:** add one Essence of that type (gain).
- **Right-click:** remove one Essence of that type (spend), when the balance is positive.
- **Shift + left-click:** set an exact nonnegative balance through a number dialog.
- Other players and spectators can **view** the balances; only the player controlling the pool (or a judge) can modify it.
For example, generating three Jasper Essence from a card ability currently means clicking `J` three times or setting its balance. Likewise, paying two Jasper means decrementing its balance twice. Future automated card effects should call a validated resource transaction action rather than simulating mouse clicks.
### What this change does **not** assume
It does not invent Essence generation rules, a land-based resource curve, turn-based Essence resets, automatic cost deduction, overdraft/Essence debt, or activation triggers. The core match tracks available resources, but **gameplay effects are still manual**. Define those rules separately before implementing them.
## Server-authoritative state
The existing Cockatrice-derived counter protocol already supports all the required functionality. The fork's shared `EssenceCounter` helper (`libcockatrice_utility/libcockatrice/utility/essence_counter.h`) defines stable counter names and the canonical symbol order.
The server creates sixteen counters at game setup with IDs `1..16` and names `essence:M`, `essence:S`, ..., `essence:N`. The existing life counter retains ID `0`. These names are protocol/storage identifiers; client gameplay displays the corresponding Essence symbols rather than exposing raw IDs.
Resource counters:
- Start at `0`, independently for every player.
- Cannot go below `0` (validated by the server for increment **and** set commands).
- Cannot be deleted or created a second time via the generic counter commands.
- Are serialized to client snapshots, replay events, and reconnect state by the existing counter protocol.
- Do not live on card ScriptableObjects, card metadata/XML, or a global static client singleton.
`Server_Player` implements this for both the self-hosted **Continuum-Servatrice** and the embedded/local game server because they share the same player server code. **Both client and server must use a matching Continuumatrice build**. The regular MTG Cockatrice client/server do not provide the native Essence Pool display.
## Implementation map
| File | Responsibility |
| --- | --- |
| `libcockatrice_utility/libcockatrice/utility/essence_counter.h` | Canonical Essence order, protocol names, nonnegative values |
| `libcockatrice_card/libcockatrice/card/essence_types.h` | Card-cost parser uses the same source of symbols |
| `libcockatrice_network/libcockatrice/network/server/remote/game/server_player.cpp` | Server counter initialization, updates, permanent-counter restrictions |
| `cockatrice/src/game_graphics/player/essence_pool_item.h/.cpp` | Compact graphical resource display, manual controls, server-state observation |
| `cockatrice/src/game_graphics/player/player_graphics_item.cpp` | Places Essence pool beside player's board and excludes it from the narrow ordinary-counter stack |
| `tests/essence_types_test.cpp` | Protocol-name round trips and nonnegative value utility checks |
The panel never owns the true resource quantities. It listens for `CounterState::valueChanged` and sends normal `actIncrementCounter`/`actSetCounter` commands through `PlayerActions`. Only the server authoritatively changes the stored balance, so remote clients and replays see the same values.
## Build and tests
On the `feature/continuumatrice-essence-match-pools` branch:
```bash
cmake -S . -B build -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DWITH_CLIENT=ON -DWITH_SERVER=ON -DWITH_ORACLE=OFF -DTEST=ON
cmake --build build --target continuumatrice continuum-servatrice essence_types_test --parallel 16
ctest --test-dir build -R EssenceTypesTest --output-on-failure
./build/continuumatrice/continuumatrice
```
## Functional acceptance checklist
- [ ] In a new local game, each player has a 4×4 pool with exactly 16 Essence types and zero balances.
- [ ] Gaining `J` leaves `C`, `B`, and `N` unchanged; right-clicking `J` at zero cannot make it negative.
- [ ] Shift+left can set `N` (colorless) to a specific nonnegative amount.
- [ ] The normal life counter still works; no default MTG W/U/B/R/G/X/Storm counters appear.
- [ ] Both players see the same balance after a command is processed by the server.
- [ ] A spectator can view but not modify another player's Essence.
- [ ] Disconnect/reconnect restores all 16 values from the game-state snapshot.
- [ ] Replay playback restores previously recorded Essence changes.
- [ ] A remote game running Continuum-Servatrice matches the local game behavior.
- [ ] The Essence panel does not overlap the three battlefield bands or Limbo/Refuge/Oblivion piles at normal zoom.
**Current status:** Source implementation committed. This server/client change has **not** been compiled or tested in a live match yet. The new browser and match UI need user-side smoke testing.

View file

@ -1,82 +0,0 @@
# Continuumatrice product migration and coexistence
This is a **product fork**, not a renamed Cockatrice binary. The upstream Cockatrice runtime, MTG cards, profiles, update feeds, launchers and installers must remain independent.
## Runtime identity
| Component | Continuumatrice |
| --- | --- |
| CMake target / installed binary | `continuumatrice` |
| Linux build output | `build/continuumatrice/continuumatrice` (source folder remains upstream named) |
| Linux app launcher | `continuumatrice.desktop` |
| Qt application | `Continuumatrice` |
| Qt organization | `Continuum Universes Studio` |
| User data on Linux (default XDG) | `~/.local/share/Continuumatrice/` |
| User cache on Linux | `~/.cache/Continuumatrice/` |
| Single-instance socket | `ContinuumatriceSingleInstance` |
| Deep-link scheme | `continuumatrice://` |
| Card XML root (native) | `continuumatrice_carddatabase` version `4` |
| Card XML root (import compatibility) | `cockatrice_carddatabase` version `4` |
| Fork server executable (when built) | `continuum-servatrice` |
| Fork server config | `continuum-servatrice.ini` |
Both `<cockatrice_carddatabase version="4">` and `<continuumatrice_carddatabase version="4">` load, but new XML saved by the fork uses the new root. The parser format and gameplay features still derive from the Cockatrice codebase; this change is not an automatic rules engine.
The source directories `cockatrice/` and `servatrice/`, common `libcockatrice_*` targets, and historical class names are left as *internal* implementation details to avoid needless churn and protocol breakage. They do not identify the installed product.
## Card data
- A new profile receives a **valid empty XML v4 starter database**, with no MTG cards.
- Put Continuum Universes card sets in `~/.local/share/Continuumatrice/customsets/`, or import from the Card Database menu.
- The default image download URL list is empty. Older fork profiles have known Scryfall/Gatherer URLs removed while custom URLs are preserved.
- The upstream MTG Oracle importer is not shipped: `WITH_ORACLE=OFF` is the default and `WITH_ORACLE=ON` is deliberately refused until there is a replacement.
- The inherited first-run Magic importer and automatic public-server/Commander-bracket fetches are disabled.
- Application release checks point only to the Continuumatrice GitHub repository; automatic update checks are off until a fork release is available.
**An independent Continuum Universes catalogue importer remains to be implemented.** Static XML v4 import is already available.
## System integration
Linux: `continuumatrice` binary, independent .desktop file, own SVG icon and `continuumatrice://` handler. No takeover of `.cod` or `cockatrice://`.
Windows: packaging script uses a separate installation directory, uninstall registry key, executable, URL protocol and process-lock detection. It must **never** remove or overwrite `cockatrice.exe` or the upstream `Uninstall\Cockatrice` key.
macOS: separate app executable/bundle identifier and `continuumatrice://` link handling; `.cod` handler removed to avoid competition with Cockatrice.
The Windows and macOS installers are **not yet verified**. Source and packaging changes should not be presented as validated shipping installers.
## Build
```bash
cmake -S . -B build --fresh -G Ninja \
-DCMAKE_BUILD_TYPE=Release -DWITH_CLIENT=ON -DWITH_SERVER=ON -DWITH_ORACLE=OFF
cmake --build build --target continuumatrice continuum-servatrice --parallel 16
./build/continuumatrice/continuumatrice
```
An internal compatibility target `cockatrice` still depends on `continuumatrice` to accommodate older CI invocations, but never emits a `cockatrice` executable. Previously compiled copies of `build/cockatrice/cockatrice` are stale.
## Release checklist
- [ ] Configure and compile Continuumatrice with openSUSE Qt 6 using a clean CMake cache.
- [ ] Confirm `build/continuumatrice/continuumatrice` runs and the app name and original SVG icon appear.
- [ ] Confirm old `/usr/bin/cockatrice`, `~/.local/share/Cockatrice` and MTG card images remain untouched.
- [ ] Open both clients simultaneously; confirm distinct sockets, settings, card databases, decks and caches.
- [ ] Load both legacy and new-root XML and verify custom images and Front/Support/Command mapping.
- [ ] Test Limbo, Refuge and Oblivion card moves, view windows, counters, mirrored positions and reconnect.
- [ ] Confirm startup does not request MTG artwork, Oracle updates, Commander brackets, or upstream server lists.
- [ ] Check a `continuumatrice://` link and ensure `cockatrice://` still belongs to MTG Cockatrice.
- [ ] Install and uninstall user-local Linux app; ensure no MTG desktop-file or icon collision.
- [ ] Test Windows installer in a VM with upstream Cockatrice preinstalled, including install, upgrade, uninstall and `.cod` association preservation.
- [ ] Test macOS app bundle identity and installation alongside upstream Cockatrice.
- [ ] Verify GPL requirements, notice retention and upstream attribution.
**Status:** Committed source changes; no completed Qt compilation, package build, or runtime validation in the assistant environment. Release is blocked pending these tests.
## Continuum-Servatrice dedicated server
CMake uses `add_subdirectory(servatrice "${CMAKE_BINARY_DIR}/continuum-servatrice")`, retaining the inherited source files but placing generated build files and the executable in their own product folder. `WITH_SERVER=ON` is the default; `WITH_SERVER=OFF` is a deliberate opt-out for client-only builds.
The MySQL schema `servatrice/continuum-servatrice.sql` uses `continuum_servatrice_` table prefixes, paired with `servatrice/continuum-servatrice.ini.example`. Default listening ports are 4757/4758. Existing Servatrice implementations, account/room/networking functionality and extended Limbo/Refuge/Oblivion game zones are retained.
The fork server should be hosted against an **independent MySQL database**, not an existing upstream MTG Servatrice database. See [hosting instructions](continuum-servatrice-hosting.md).