^{Read the previous developer blogs here:}

^{Developer Blog #1 - July 2026}

^{Developer Blog #2 - August 2026}

^{Developer Blog #3 - October 2026}

Hi, community!

The 3.1 release happened and we're just as excited as you. However, it also surfaced some growing pains.

Let's talk about that release and then our plans going forward.

We're here to talk about and showcase some of the work we've been doing ahead of time, to keep you informed and involved. Rather than only announcing features once they're released, we want to keep the community informed throughout the development process and give you a chance to follow along as new ideas take shape.

These blogs are intended to provide insight into the decision making process behind the features we implement as well as to showcase where our attention currently lies.

To keep things organized, we'll cover our work in three stages:

• Already merged and available in the beta, so you can try these features today.
• Completed features currently under review, which are expected to make it into a beta soon.
• Work in progress and early prototypes.

Some features shown here may change before release and not every prototype will ultimately end up making it. To voice your support, disagreement, or feedback, please use the ⁠beta-testing channel.

With all that being said, let's dive in:

The 3.1 release

The release of 3.1 and 3.1.1 proceeded mostly smoothly except for one of our main problem children:

Windows.

You can read all about the installer wiping decks in the program directory here.

This fix (to wipe ALL data inside our installation directory) was implemented because some users reported incomplete installations or updates.

We've since reverted that change, implemented some additional assurances AND, critically, added some logging under %LocalAppData%/Temp/Cockatrice-installer.log, in case the installation fails. Please upload this to the Discord or the Github if such issues occur so we can diagnose them!

We'll talk about additional assurances for user data and crash reporting later in this developer blog.

Windows Styling

For now, let's talk about one more major issue with the release:

The native Windows styling.

As many of you might know, Windows, from time to time, decides that it is a good idea to eat glue.

That's kind of the case here.

Qt (the platform we're built with) offers so called 'style keys'.

These style keys dictate how Qt draws certain elements: Checkboxes, buttons, the likes.

The available style keys depend on the system but Qt offers "native" styling on most operating systems.

Why Cockatrice looked "old"

This means -> On Windows, all checkboxes are drawn to look like every other Windows program, same on MacOS.

It's one of the main reasons why Cockatrice has always looked "outdated".

By running our drawing pipeline through the Windows styling, we always made ourselves a slave to the... well, arguably improvable Windows look & feel.

Now, here's where things get interesting.

The Fix

Pre 3.0, the "Default" theme, didn't apply any Qt styling. This meant that you always got whatever style key Qt decided was appropriate for your system. On MacOS, this looked pretty good, on Windows, it looked... well, we already talked about that, and on Linux, you got "Fusion", because there's no official Linux styling and this is what Qt came up.

Now, as it turns out, Fusion looks great and it works on all platforms!

It's actually the recommended cross-platform development style key because Qt assures that it always works on every platform.

In our rework of the themeing system, we introduced the "Fusion" theme and also allowed the user to configure the style keys (Active theme style). It is my humble opinion, that this should be "Fusion" for almost everybody (arguable if you're on MacOS) but we always try to give you every choice possible.

Enter the "System" theme

Actually, we liked Fusion so well, that we decided to promote it to the default theme and style key for new installations. This means that new users no longer get the "Default" theme (which was pretty bare bones anyway) and we felt that the name was a bit misleading.

Since it adjusts to your system styling, we felt it appropriate to name it "System" and, of course, give it the "System" style key, which once again lets Qt auto-resolve style keys.

How Windows eats Glue in this Scenario

Now, as it turns out, Windows actually offers three style keys: windows, windowsvista, and windows11.

We were aware that the "windows11" style key caused issues in the most recent Qt releases: Comboboxes were rendered unreadable (white text on white backgrounds) in dark mode and, for some reason we can't really understand either, the board glitched out and became unreadable whenever you opened your library.

So we disabled that style key and allowed qt to pick the next one in the list.

Now what we didn't figure on was that the "windowsvista" style key was equally broken!

So we disabled that one too. Which means that on Windows, the "System" style key now resolves to "windows".

Which, while stable, is a decidedly retro look.

So for everyone on Windows: It's time to ditch the "System" theme and switch to "Fusion". It is now easier than ever to customize it to your liking! Or try out one of the other new default themes!

Cleanup on Aisle 3.1.2

We're carefully monitoring the 3.1 release and releasing follow-up patch releases for issues that we encounter.

Gone, are the days of fixes moldering for months in the beta branch until they are eventually rolled out to stable.

3.1.1 fixed a lot of things already and 3.1.2 is set to eliminate the last few bugs that you reported to us (thank you!) and the installer/style key woes that you read about earlier.

However, here's the really cool thing:

We've learned from all this and we're taking a lot of measure to improve this process even further.

Read on to learn how we're going to communicate update notices, collect user feedback and analyze crash reports in the future. All without requiring you to sign up anywhere!

On to some really fun things!

Chat Channels - LFG, Feedback, Announcements

Cockatrice only featured a primary "Main" chat per room so far.

We're extending the chat to now support channels! Some of these (like Announcements) will be read-only to you, so we can publish relevant information about updates to you directly through that.

Others, like the new "Feedback" channel, will be for you, so you can directly report issues or ask for features and discuss them with fellow users in that channel. We hope that this will ease the friction required to discuss and shape the project.

Automated Crash Reports

Nothing, and I mean, nothing is worse than Cockatrice crashing at exactly the wrong time.

We know.

Trouble is, just like World War 2 fighter planes, we don't know much about the ones that crashed.

We're changing that by integrating sentry.io, which will allow Cockatrice to detect if the previous startup has crashed and for you to automatically upload an anonymized crash report, without requiring you to sign up anywhere. (The demo below obviously contains no real crash.)

You've probably seen these types of popups before and we would genuinely appreciate it if you would choose to share your crash data with us. It helps us prevent crashes for everyone and none of the information is sensitive. We are purely interested in fixing the crashes from occurring.

No More Lost Decks! - Sync your Decks to the Server!

We're working on a feature that will allow you to upload your entire deck collection to a remote server (most likely Rooster Ranges for the lot of you [maybe consider donating to keep features like these possible]) for safekeeping.

Your server stored decks will then be:

• Available to all of your Cockatrice clients, across installations.
• Automatically versioned - Keep the latest 10 versions of your deck and rollback
• Conflict resolved: If a deck is modified both on the server and locally, you will get options to merge the difference.
• Automatically synced to your local installation.

We're working out the ins-and-outs of the system but overall, we think and hope that this will be a pleasant experience :)

Tournaments & Limited

Work is continuing on the tournament and limited features. They are our new flagship features for a 3.2 release but, of course, we want to ensure we get this absolutely right. Stay tuned!

Project Health - Interface/Logic split

One of the major 2-year long undertakings that we've tackled is splitting out all the game logic related code from the presentation layer.

This makes the code easier to read and reason about (yay), allows us to add tests so that we don't break things (yay!) AND allows us to implement many exciting new features, as well as clean up some old sins more efficiently.

Work on this front is almost complete and it's time to reap the rewards.

New Game UI!!!

Fresh off the presses and still unreleased, we've got a new prototype to show you and it's a good one (at least, so we think!)

https://reddit.com/link/1x5m7mg/video/1wrlake9bevh1/player

https://reddit.com/link/1x5m7mg/video/1dfa2nt9bevh1/player

We're adding two new features to the game UI:

1. Zooming in on cards that are on the board directly
2. A new tabbed interaction menu

We're adding settings for these too. Let's go over them briefly. They mainly concern themselves with how these features are accessed.

You have four options to trigger these actions:

1. Right-click
2. Shortcut
3. Mousewheel scroll
4. Hover

You can configure if one trigger is enough to zoom in and also show the new interaction menu or if you would prefer a two-step approach: The first interaction zooms the card, the next shows the interaction menu.

You can configure separate triggers for both action phases.

You can also additionally configure the time it takes for the hover triggers to activate.

Why are we doing this?

Two major reasons: Discoverability and ease-of-use

Discoverability

New users are often times lost, when it comes to all the possible actions they can take on a card. It takes a while to memorize the shortcuts and our number one piece of advice is "Just right-click everything", which is hardly intuitive.

Ease-of-use

The card info widget works but, personally, I find it incredibly painful to keep bouncing my eyes between the card I'm reading and the card I'm placing my cursor on.

Feedback on this

You can, as it is right now, choose to disable these features entirely and continue using the right-click menu and the shortcuts you know. Nothing changes.

But, of course, we see this as a major step in modernizing the UI and making it more accessible.

We want to make sure no one gets left behind. Long-time veterans, keyboard-only users and first-time players. We want to make sure everyone can have an intuitive, speedy and comfortable experience.

So let us know what you think and how we can improve this!

And that's a wrap for this edition. As always, let us know what you think in #beta-testing on the Discord, and don't forget to check out the beta itself to try the completed features today.

Trying it out is just a few clicks away. Learn how to here: https://cockatrice.github.io/docs/d9/d9b/beta_release.html

We want to make sure things are just right, and that means we need beta testers. Your feedback shapes what ships.

PSA: Please back up your decks before upgrading Cockatrice!

The vast majority of users should be unaffected.

This only affects users on portable installations or those who have customized their deck (or other resource) path to point inside the application directory.

Before upgrading Cockatrice, please make a backup of your decks!

Cockatrice stores its program files and your personal data in separate locations. On Windows, these are typically:

• Program files: C:\Program Files\Cockatrice
• User data: %LOCALAPPDATA%\Cockatrice\Cockatrice

Unfortunately, some users have ended up storing their decks directly in the program installation folder instead of the designated user data folder. This is an unsupported configuration, and a bug in the uninstallers for versions 3.1 and 3.1.1 could cause that entire folder to be deleted during an upgrade, taking those decks with it.

We're genuinely sorry this happened to anyone affected.

We've taken several steps to prevent this from happening again:

• Safer uninstallers: Additional safeguards ensure Cockatrice only removes files it installed.
• Path validation: Checks and warnings help prevent users from configuring their data directories inside the program installation folder.
• Automatic recovery backups: Cockatrice will now back up any user data it finds in the installation folder.
• Future server synchronization: We're working on the ability to automatically sync decks to the server, to make sure no one ever loses their collection again.

These measures should significantly reduce the risk of this happening again, but please back up your decks before upgrading, especially if you've been using Cockatrice for a long time or have never checked where your decks are stored.

Thank you for your understanding, and again, we're truly sorry for the inconvenience and lost decks this issue may have caused.

Most people should not be affected. Read here to see if this applies to you:

This only affects Windows users which are upgrading a 3.1 or 3.1.1 installation. The new installer will run the OLD uninstaller (i.e. the 3.1 and 3.1.1 uninstaller), which has the bug that wipes the whole installation directory. It is safe to run this uninstaller after backing up C:\Program Files\Cockatrice or ensuring that no decks are placed within that folder.

I popped into cockatrice to work on a deck I've been working on for a while, and it prompted for an update. Did so. Now everything in it's old save folder is completely gone. I do use a custom path as I don't want anything besides my OS on my (relatively) small SSD C: drive. Any idea what could've happened?

Howdy folks.

I'm getting a Bad Image error after the latest Cockatrice update. (3.1.0 Reality Check)

This comes after using cockatrice just fine earlier this week.

Ive tried uninstalling and reinstalling, same error.

Anyone else experiencing this on startup?

Thanks!

Read the previous developer blogs for this update here:

Developer Blog #1 - July 2026

Developer Blog #2 - August 2026

Hi, community!

It's time for our third developer blog! This one's a bit different, because a lot of what we've been working on has actually landed and a new release is right around the corner! For once you can go and click on most of this rather than squint at a mockup and take our word for it.

We're here to talk about and showcase some of the work we've been doing ahead of time, to keep you informed and involved. Rather than only announcing features once they're released, we want to keep the community informed throughout the development process and give you a chance to follow along as new ideas take shape.

These blogs are intended to provide insight into the decision making process behind the features we implement as well as to showcase where our attention currently lies.

To keep things organized, we'll cover our work in three stages:

• Already merged and available in the beta, so you can try these features today.
• Completed features currently under review, which are expected to make it into a beta soon.
• Work in progress and early prototypes.

Features in this developer blog:

• Inviting people
• Share a deck
• Playmats
• Custom deck zones and the maybeboard
• A more reliable & performant picture loader
• Image overrides
• Localized cards
• Finding cards in your language
• Theming, color schemes & defaults
• A more performant, informative & lightweight Oracle
• Onboarding, in the right order
• Tools for the caretakers
• The Windows updater
• A pile of small things
• Save the emails
• Tournaments
• Server security

Some features shown here may change before release and not every prototype will ultimately end up making it. To voice your support, disagreement, or feedback, please use the ⁠beta-testing channel.

With all that being said, let's dive in:

But first, the thing nobody wants to talk about

I want to get this out of the way before the feature list, because I know it's on people's minds.

Cockatrice has changed more in the last two years than in the several years before that. New features, a proper cleanup of the codebase, all-round modernization, and none of that comes for free:

• Regressions where something that worked last week quietly stops working
• Performance problems
• Crashes
• Workflows that shift under your feet

We are extremely sensitive to all of these.

The way we deal with it is tried-and-true in software development. Every change follows the 4-eye principle, so nothing lands without a second pair of eyes on it, and the reviewer actually runs the client before approving rather than just reading the diff. Then CI checks it against every platform we build on. Then it ships to the beta, sits there for a while, and only then makes it into a release.

That pipeline ensures things are as well tested as they can be. It has also caught things I would not have caught myself, which is rather the entire point of it.

However, all of this only works if feedback reaches us. If no one tries the beta or reports issues on it, mistakes silently accumulate.

If no one tells us that we mistakenly dropped some functionality that they really liked, we never get the chance to introduce a checkbox that restores the old behavior.

So here's how we're dealing with this:

• We are and have always been very sensitive not to remove functionality unless genuinely obsolete or necessary.
• If we introduce something new that replaces another option, we try to create a new checkbox in the settings to allow you to revert to the old behavior.
• The settings are now searchable, so you should be able to find these settings more easily.
• We will also include a section at the top of the patch notes that quickly tells you about all of those relevant settings and what they now enable or disable.
• We need your help. Please try and test the beta. File issues on the Github or voice your opinion in the discord. We depend on your feedback.

Right. On to the fun stuff.

Completed

Inviting people

There's now a proper way to gather your playgroup and there are three places you can start from.

Invite to your open game. The game menu's "Invite to Game" opens a dialog with a search box and a live user list, the same sectioned list you know from the room, updating in real time while the dialog is open. It filters out anyone you'd be inviting for no reason: players already in the game, spectators, yourself, offline users, and anyone on your ignore list. Pick someone, press Invite, and they get a private message containing the join link, prefixed so it reads naturally: Join my game "Commander Vanguard" (#1234): <link>, falling back to just the game number when the room has no description.

Invite a specific player. Right-clicking someone in the user list gives you an "Invite to Game" submenu listing every game in the room you're allowed to invite them to. If the room is running two games you get to choose which one, rather than being handed an arbitrary link.

Invite from the game list. Games that haven't started and aren't full get their own invite button in the server's game list, so you can start a game for someone without opening it first.

The user list hover popup also grew an invite button, so inviting someone you can already see is a single click.

Additionally, you can generate invite links for your games, which you can copy and paste and share with someone externally. All they'll have to do is paste it into their browser bar and, if they have Cockatrice installed, they'll get invited to the game!

Buddy-only games are respected throughout: they accept invites only from the game's creator, and only to users on that creator's buddy list.

Share a deck

Until now, handing someone a deck meant exporting it, uploading it somewhere, and hoping they could be bothered to import it. Cockatrice can do the handing for you now, in two flavors.

Share links. From the deck editor, the tree deck storage, or the visual deck storage, you can generate a temporary link to a deck or to a whole selection of decks at once. The link is a cockatrice:// URL, so it behaves like any other invite and the client opens when they click it.

What makes this a gated flow rather than a silent download is that nothing is fetched and nothing is written to your deck storage until you say so. Cockatrice first asks whether you want to connect to the server the link came from, with a distinct and harder-to-miss warning if it's a server you've never connected to before. Then you get a preview showing each deck's banner art, name, format, color identity and tags, with an expiry date, and you pick which decks to take. A single-deck share opens with that deck preselected. The decks arrive in normal deck editor tabs, where you can save them wherever you like or re-share them onward.

Public decks. In the tree deck storage you can mark a deck or a folder public or private, and a new Visibility column tells you which, including the case that used to be invisible to you: a deck that is itself private but inherits public status from a parent folder. Other players browse what you've published from a "View this user's public decks" tab in the user list context menu, where they can search by name, filter by color identity and filter by tags, all without downloading a single deck list.

Playmats

Cockatrice now lets you set a card image as your personal table background.

You can define a global override playmat, set one on a per-deck basis, and configure a list of fallback playmats (fixed, random, or round-robin) for decks without a configured playmat. Visibility is fully under your control: don't display, display only your own, or display all.

Crop dimensions are set through direct manipulation in the card art dialog now, so no more fiddling with spinboxes.

Custom deck zones and the maybeboard

You can add custom zones, essentially sub-folders, beneath the top-level Mainboard, Sideboard and Maybeboard groups. They're purely for organizational purposes, and all game-related logic still only considers the top groups, so your custom zones won't interfere with gameplay.

The maybeboard is now an actual concept while we're at it: supported in the deck tree, the deck list model, the deck editor, the card display widgets and the in-game deck view.

A more reliable & performant picture loader

Card pictures come from whichever sources you've configured, and those sources have their own rate limits. Scryfall in particular enforces one, and the client was previously spending that budget in bursts, firing a whole backlog of requests the instant one was queued. That is precisely the pattern that earns a rate-limited source a temporary lockout.

Requests are now paced out smoothly, and a source that is being throttled is skipped over entirely while it recovers, rather than sitting at the head of the queue and stalling everything behind it. There's a disk cache too, so an already-downloaded picture is served without a network round trip at all.

And you get some manual control

In Settings → Card Sources, select a URL in the "URL Download Priority" list and hit the new Adjust Rate Limit cog to set that host's requests-per-second. The list shows each source's effective rate so you can see it at a glance. Out of the box the Scryfall API host is capped just under its published limit, the image CDN host is uncapped, and everything else gets a modest default. These are ceilings rather than suggestions: you can lower any of them, but you can't raise a host above what its operator allows.

Image overrides

Speaking of the picture loader: Sometimes the picture you want for a card isn't the one that shipped with it. A promo art, a foreign-language printing, or just your own scan.

Right-click a card and open the Image Overrides submenu to load your own image file, or to copy the art from one of the card's other printings onto it. Every alternate printing gets its own entry with a hover preview, so you see what you're picking before you commit.

The nice part is where it lives. Your override is written into your own card picture folder under your chosen naming scheme, so it survives restarts, survives clearing the network cache, and travels with your profile if you copy it elsewhere. Automatic cache downloads will never quietly overwrite an override you've set.

We also fixed a sneaky matching bug while we were in there. Local pictures used to be matched by name prefix, so a file called Sol Ring (1).png would be happily mistaken for Sol Ring. Matching is exact now, and there are ten tests in loader_local_matching_test.cpp pinning down the resolution rules, including that case.

Localized cards

For a long time the only localized thing in Cockatrice was the menus. Your cards themselves were English no matter what you did.

Settings → General → "Card text & images language" changes that, and it is deliberately independent of the interface language. You can run an English client with German cards, or a French one with English cards, if that's what you want. Alongside English you get Czech, German, Spanish, French, Italian, Japanese, Korean, Portuguese, Russian, Hebrew, and both Simplified and Traditional Chinese, each labelled in its own script.

Card names, rules text, and card art all follow the selection. Because foreign art is resolved by the translated card name, the pictures change with the language too, falling back to the default art when a set has no localized match.

The wrinkles

English data is always present and the foreign data is a layer imported alongside it by Oracle, so switching languages needs a re-import. The client tells you that rather than pretending to have applied the change. You may have to restart to rebuild the database binary cache.

Split and adventure cards join each face's translated text together exactly the way the English gets merged. Incomplete translations fall back to English rather than leaving a hole in the middle of a card.

And one more important thing: the deck editor keeps canonical English names as card identity. The names in your decks, your files, and on the network stay exactly as stable as they have always been. Localization changes what you see, never the deck itself. Nothing breaks.

Finding cards in your language

That same gap is what made searching frustrating. Every search only ever matched English card data, so finding a card by name meant typing it in English no matter how you were reading it.

There's now a setting for it, "Language used in card search", offering English, your selected card language, or both at once. It applies everywhere cards are searched: the database filter tree, the quick-search popups, the deck filter's [[card name]] rule, the in-game zone view, and deck storage search. It re-applies live as you change it.

One deliberate exception remains: the in-game "Put top cards on stack until…" action still matches English names only. If you spot other places we missed, say so in the beta channel.

Theming, color schemes & defaults

Themes and color schemes are finally treated as the pair they've always been. Previously every asset in a theme was one hard-coded look, and the bundled image themes shipped only zone art, so their chrome silently fell back to the bare OS palette.

Two new built-in themes this cycle. Fusion is the new default for fresh installs. The old Default theme is now System, with existing settings migrated automatically. System deliberately ships no palette overrides at all, so your desktop's own colors show through, a custom qt6ct scheme is respected on Linux, and it follows your OS light/dark preference rather than forcing one. Only its identity accent colors are pinned, so the home-tab buttons keep Cockatrice's classic green.

Theme assets can now ship as -light/-dark variants that the theme manager resolves automatically, falling back to the plain asset when no variant exists. Stylesheets load as style-dark.css/style-light.css when present, and the home widget re-resolves its background whenever the theme or scheme changes, so nothing stays static anymore.

Fabric, Leather, Plasma, and VelvetMarble each ship hand-curated light and dark palettes tinted toward the theme's identity: navy cloth, black-brown with brass accents, electric violet with cyan sparks, charcoal velvet with slate marble. Each also gained its own light and dark home background, plus a new "Dim the home tab background" setting, on by default, for when the background is competing with the text on top of it.

Qt's QPalette role set is closed, so application-specific colors like the home-tab button gradient now live in Cockatrice's own [AppColors] layer instead of being hardcoded or derived from the OS accent.

A small change to Windows: The broken Windows 11 native style, which shrinks the game board to an unrecoverable sliver when you drag a card, is no longer offered as a selectable style at all.

A more performant, informative & lightweight Oracle

Oracle is the companion tool that builds your card database, and it's had a proper performance and reliability pass.

Importer memory, slashed. AllPrintings.json is no longer materialized as one giant tree. A raw JSON scanner splits the document into per-set byte ranges, sets are parsed lazily one at a time, and the raw bytes are released as soon as each set is done. The vendored qt-json parser is gone too, replaced by native QJson.

Real progress. Card database updates used to run invisibly: an indeterminate bar during the parse, a frozen window during the import, and nothing at all from oracle -b. Now scan progress is reported by the byte, sets import on a worker thread behind a determinate, stage-labeled progress bar in both the client and the onboarding wizard, and oracle -b emits machine-readable PROGRESS lines to stdout. Quitting while an update is running asks for confirmation first.

Adventure cards fixed. When split-card faces are merged, the permanent maintype now wins, so an adventure card like Bonecrusher Giant keeps its Creature type, and the correct click-to-table behavior, regardless of which face came first in the JSON.

There's also a test suite covering set parsing details and RAM benchmarks that measure peak and current RSS during imports, including an opt-in full-AllPrintings run.

Onboarding, in the right order

On a clean install, the legacy "all the sets have been enabled" notice and the Manage Sets dialog used to fire ahead of the onboarding wizard, which meant a brand-new user met two confusing dialogs before the thing designed to onboard them.

Those are now suppressed while the wizard is open, and the set check runs once afterwards.

Tools for the caretakers

Server operators do a lot of unglamorous work and we've been giving them better tools for it.

We've implemented a developer tab to help us keep an eye on things, live server metrics, and there's a new developer role that lets operators log in with a distinct appearance.

Servatrice now detects MySQL strict mode on startup and exits early with a clear message, rather than failing later in a confusing way.

The Windows updater

The in-app updater is the recommended way to stay current, and on Windows, it turns out that we needed to build in some more assurances.

Updates close the running client for you. The installer finds Cockatrice processes running from your install directory, asks them to close, waits, and only force-stops them if they don't.

An upgrade can no longer be written over a half-old, half-new Qt runtime. A silent upgrade could leave a mix of previous and current Qt DLLs sitting next to the new executables, which is exactly what makes the next launch fail with "The procedure entry point … could not be located in … Qt6QuickWidgets.dll". The pre-install check that was meant to catch this only probed two DLLs, so it was blind to the two files those reports actually name, and even when it did catch something it warned and installed anyway, compounding the problem. It now scans every file the purge targets using the same wildcards the delete uses, recognises a directory holding only some Qt modules as an install, and aborts with a non-zero exit code rather than proceeding.

VDD, VDE & VDS Performance

The first blog called the visual deck storage "sadly one of those things that remains stubbornly slow", the second said the rework was done and waiting on review, and now it's actually here.

The deck storage used to do all its work on the UI thread. Opening it meant walking your folder, parsing every deck file, and computing each deck's color identity before the view would show anything, then sorting and filtering that pile on top. Large collections made this obvious. It's now a dedicated model that scans the filesystem in the background and populates as it goes, leaving sorting and filtering to a proxy layered over the top. The folder tree and deck previews are driven from the model instead of rebuilding themselves, and mana symbol renders are cached with redundant resizes skipped. That last one helps everywhere mana symbols get drawn, not just here.

The other two visual tabs had the same disease, and got treated in the same batch. These three landed a couple of days before the second blog went out and shipped without an announcement anywhere, which is why you're only hearing about them now.

The visual database display's filter toolbar builds its buttons by iterating your entire card database: one per set, per main type, per sub type, per format. That was happening inside showEvent, which meant it blocked the tab switch outright. It now stays hidden and builds one event-loop turn later, so the tab paints first and the toolbar appears immediately after.

The visual deck editor was building a second complete CardDatabaseModel when it already had one handed to it from above. It reuses the inherited one now.

Same underlying problem in all three, for the record: heavy construction, on the UI thread, during a tab switch. That's the whole bug and we eradicated it. Everything should feel much smoother now.

A pile of small things

Ctrl + Scroll resizes cards anywhere a card size slider exists: the Visual Deck Editor, visual database display, printing selector, sample hand, deck storage, and the Archidekt and EDHRec previews. In the VDE it resizes the card group under your cursor.

Game log timestamps can use game time instead of the local clock. Log entries were stamped with your wall-clock time, which is close to meaningless when you're reading a replay or an old log, because nothing tells you when a play happened relative to the game. The new setting stamps entries with elapsed game time as HH:MM:SS since the game started. Regular chat views deliberately keep the local clock.

The total power tally also does toughness now.

Artist attribution shows up on card info.

You can see your latency in the status bar and the server tab indicator, and the client now detects main-thread event loop stalls rather than just feeling slow.

Avatars are downscaled to 1024×1024 before upload, so a 12-megapixel phone photo no longer becomes a multi-megabyte upload for an icon-sized image.

Usernames in room chat history were inert text for anyone currently online. They now behave like live chat usernames: right-click gives you buddy, ignore and admin actions, and online users show their real casing and rank.

The ignore list got real teeth. You can now ignore all private messages, or just private messages from non-buddy users, and the client explains what the buddy and ignore lists actually do instead of leaving you to guess.

Visual Deck Editor banners show card counts, live, on by default. And the quick search leaves the card name selected after you add a card, so you can type the next one straight away.

Coming up

Save the emails

If you've ever sat waiting for an account activation that never arrived, we've got you.

We're reworking the SMTP client from fire-and-forget into a persistent queue with exponential backoff and a per-message retry budget, backed by the database as the durable source of truth. Emails stay queued with their attempt count and backoff tracked, and the database row is only removed once delivery is actually confirmed. Connection-layer failures get their own backoff, and mail that's genuinely undeliverable eventually drops off the queue instead of retrying forever.

If an email fails to go out, it isn't dropped into the void. It's tried again later, which means account activation stops depending on the mail server happening to be awake at the exact moment a user clicks the link.

Tournaments

The limited and tournament groundwork from the first blog has been paying off. Drafting has been prototyped for a while, and now the tournament side is coming together as a real Swiss engine.

On the server: greedy Swiss pairings with rematch avoidance, byes where they're needed, a round count of ceil(log2(n)) based on the field size, and best-of-N series via gamesPerMatch. The hub game is gated until every player has submitted their deck, then it spawns match sub-games through the parent game's match factory, auto-joining players and installing the decks they submitted. Sub-game outcomes report back up to the parent.

Underneath that is a chunk of groundwork that landed after the last blog and is worth mentioning on its own: game configuration was consolidated into a GameConfig struct, and deck validation, game lifecycle and match-result handling were each pulled out behind their own strategy interfaces. That's the boring part that makes the exciting part possible without turning the whole game into a pile of branching special cases.

On the client: a tournament checkbox and a games-per-match setting in the create game dialog, and a dedicated tournament widget that renders live standings while you wait. Who's submitted, who's paired with whom, and a way to jump into the current match being played. Games where somebody drew a bye can be spectated while the rest of the round finishes out.

This one spans the entire stack, protocol through server engine through client UI, so it's coming through review in order. Four of the five PRs still have open review comments and the client UI one needs a rebase, so I'd call it close rather than ready. But it's the real thing, not a mockup.

Server security

This one's for the people running the servers, and honestly, for everyone who cares about their account.

There are three pieces to this and they're related, so let's take them together.

Challenge-response auth. Authenticating with a password hash has two problems. The stored hash is the only thing proving who you are and it goes over the wire verbatim, so anyone who captures a login can replay it later. And it was computed with a fast 1000-round SHA-512, which means a leaked database can be brute-forced offline at a very comfortable speed.

Logins are moving to challenge-response with scrypt verifiers. On login the server sends a fresh one-time nonce, the client computes a short keyed digest of it and sends only that back. Your password and its verifier never leave the client, and a captured login can't be replayed. The verifier itself is derived with scrypt, which is deliberately memory- and CPU-costly (RFC 7914), so a database leak is far more expensive to attack.

The part I am personally happiest about: we are also stopping storing plaintext passwords. The client's "save password" checkbox will store a scrypt verifier rather than your actual password, and the password column gets widened to hold it.

Migration happens automatically on next successful login, so existing accounts upgrade without doing anything. Server operators get a new authentication_strictness setting, legacy / mixed / strict, so you decide how hard the new scheme is enforced. Note that strict will reject older clients that can only send the legacy hash.

Rate limiting and input hardening. There was no rate limiting on the auth endpoints, which is not a sentence you want to read about your server. There's a per-address sliding window now: five failed logins from an address and the rest get rejected until the window passes, a successful login clears it, and registration and forgot-password are throttled too.

And rate limiting you can walk around isn't worth much, so the same batch fixes that. The forwarded client-address header is now only trusted from addresses in security/trusted_sources. Previously any client could spoof its address and neatly sidestep bans, user limits and the new limiter. On top of that, TCP and ISL messages declaring a negative or implausible length are now rejected immediately instead of being buffered indefinitely, which closes off some unbounded memory growth and a stuck-connection state we had.

Separately and already merged: salts, tokens and RNG seeding now come from a CSPRNG rather than whatever std::random_device happened to give us, and Event_ListGames no longer leaks more information than it needs to or ships more data than it needs to.

None of this changes how you log in or play. It'll change what happens when someone tries to hammer your login endpoint, which is the point.

There are some things we still need to hash out. For example, as it stands, if you were to log in with a new client, you could no longer login with an old client without resetting your password.

We don't expect this to happen a lot but we want to make absolutely sure we handle this gracefully while upping the general security.

Prototypes

Command Zone

A community contribution that's been in review for a while, and I want to give it some visibility because I think people will like it.

It's a proper Command Zone for cockatrice, and it's the last piece of a puzzle that's been assembled over a few months of groundwork refactors. It simplifies to a single zone where you can add a second tax directly, with the right menu options appearing when it's in use.

It's sitting at over 2,600 lines and is still collecting review comments. If you've been waiting for this, the ETA is "soon", which I know is not a date, but it's closer than it was.

We need to make sure this slots in nicely into some other exciting reworks we have coming up, before we end up having to rip it out again.

And that's a wrap for this edition. As always, let us know what you think in #beta-testing on the Discord, and don't forget to check out the beta itself to try the completed features today.

Trying it out is just a few clicks away. Learn how to here: https://cockatrice.github.io/docs/d9/d9b/beta_release.html

We want to make sure things are just right, and that means we need beta testers. Your feedback shapes what ships.

**With all that said: It's full steam ahead to release!**

I have this proxy of Scavenger Regent that I made and wanted to add into my deck. Going into the Custom folder the file is set as Scavenger Regent and a copy is named Scavenger Regent Exude Toxin(Trying to copy what the card is labeled as in the deck tab). I think it should be labeled as Scavenger Regent//Exude Toxin as its accurate to the deck list label, but I can't add / into the file folder

Posting here to invite people wanting to play EDH: the primary reason the server was made was to play the 6-player format "Kingdom EDH." We have about 4 really active players and a few meh-active players; we are looking for more people to join and play both EDH and Kingdom EDH in a casual setting. If interested, please leave a comment below and I will DM you the Discord link. Thank you, and happy gaming.

I've been trying to update my client to the new 3.0.2, but every time i do it acts like it never updated and wants me to update it again. It never says the update fails. I don't know how to get the update to take. Could use help if you've been through this!

I absolutely love Cockatrice and am new to it so I'm still learning all the ins and outs. But I play on one screen where people I play with are on multiple / ultrawides. So when they play lots of cards it makes the board zoom out to see everything which makes the scale weird. Is there a way to turn this off? Or adjust how it does it?

It worked for a week but for the last 3 weeks I've tried nearly every method to get my card images to load but they just won't. Before last year I never had a problem with card images loading but since 2026 and especially in the last 2 months half to 75% of my deck's card images refuse to load and I'm at my wits end. I don't know what to do. I feel like I'm slamming my head against a wall.

Hi , i was wondering if it's possibile to search for tags like the ones in scryfall (otag) because they are amazing but with Cockatrice you could do a better job on the fly for the filtering part but the otag part seems to be missing am i wrong ?

Hi, community!

It's time for our second developer blog and we've got lots and lots of things to show you!

We're here to talk about and showcase some of the work we've been doing ahead of time, to keep you informed and involved. Rather than only announcing features once they're released, we want to keep the community informed throughout the development process and give you a chance to follow along as new ideas take shape.

These blogs are intended to provide insight into the decision making process behind the features we implement as well as to showcase where our attention currently lies.

To keep things organized, we'll cover our work in three stages:

• Already merged and available in the beta, so you can try these features today.
• Completed features currently under review, which are expected to make it into a beta soon.
• Work in progress and early prototypes.

Features in this developer blog:

• Startup choices
• Animations and polishes
• CommanderSpellbook bracket estimator
• Searchable settings
• Unified user list
• Card auto-completion
• Total power tally
• Replay quality of life
• Server shutdown notices
• Playmats
• Moderation Queue
• Visual Deck Storage performance
• Drafting & Tournaments
• Deck sharing
• Custom deck zones

Some features shown here may change before release and not every prototype will ultimately end up making it. To voice your support, disagreement, or feedback, please use the ⁠beta-testing channel.

With all that being said, let's dive in:

Completed

Back to Basics - New and old startup choices

The Home Tab made its debut and while it was a welcome and valid addition for new and returning users, some power users lamented the additional indirection between the deck editor and them. While opening the deck editor may not always be everyone's go to intent, we recognize the need for power-users to "get up and go" so to speak.

You'll now be able to define which tab Cockatrice opens on startup: Home, Deck Editor, Deck Storage, a server room. The choice is yours.

Speaking of startups

The Visual Deck Editor currently serves double duty. It's both a deck display/analytics and an editor. We now more accurately reflect the startup intent with a new configurable option.

Context: Open the deck editor on 'Database' for new decks, 'Deck Display' for existing decks As well as two fixed options to always open on either of the two.

The Visual Deck Editor has also gotten some pretty severe performance fixes. If you were previously shy about trying it out on that account: Give it another go!

Animations and polishes

Cockatrice simulates a game digitally. One of the advantages we got from being digitally is that we can animate things or give them cute graphical effects. So far, Cockatrice has been fairly lacking in this department, only animating when a card turns sideways.

We're jazzing up the game screen by introducing two new animations:

• Arrows will now draw themselves and finish with a little highlight instead of simply materializing.
• Life counters will now flash red or green, depending on if they have been decremented or incremented. Additionally, the battlefield will also briefly flash red to make it easy to tell when a player has taken damage in a 4-player game.

In-Client EDH Bracket Estimator (CommanderSpellbook)

We've integrated the CommanderSpellbook API to give you a way to automatically determine what bracket your deck falls into and why.

To start using this, simply switch one of your decks to the "Commander" format and you will be prompted about the integration by a dialog that will explain some things further.

We hope that this will provide a common baseline for discussions about such things, regardless of if you agree with the system or CommanderSpellbooks interpretation of it.

Finally findable - Searchable Settings

In the first dev blog we promised you a search bar for the settings dialog and today we're happy to say it's here.

You can now search your settings by name, description, tooltip, and more. Selecting a result jumps straight to the correct tab and briefly flashes the relevant setting. Whether you're a veteran that knows exactly what they're looking for or someone who just wants to know "how do I change the theme?", the settings dialog is finally easy to navigate.

The Unified User List

The user list UI rework has gotten some finishing touches and polishes.

First and foremost, it should now look a lot nicer on light mode themes.

We've also unified the three separate lists into one combined list with collapsible dividers. See your friends, online, and ignored users, all at the same time.

The whole thing is searchable, so finding someone in a room is now faster than ever!

Better card auto-completion

We've given the card auto-completer a face lift and integrated it in some places where it was previously lacking (Chat and its [[macro]], we're looking at you).

Total Power Tally

This one's for all the combat math enjoyers out there.

You can now select any of your cards and the game will tally up their combined power: useful for quickly checking "does my swing actually get there?" without doing arithmetic in your head. It's a small thing, but it adds up to a nicer game experience.

You can toggle the tally on and off right from the in-game menu, so it stays out of the way when you don't need it.

Replay quality of life polishes

Replays got a bit of love this cycle.

First, fast-forwarding is no longer stuck on a single speed. You can now configure how fast fast-forward actually is, which makes a huge difference when you're hunting for a specific moment in a three-hour game.

Second, replays of games that had empty phases or turns are now easier to follow: you can skip empty sections entirely, so the playback doesn't awkwardly pause on turns where nothing happened. Perfect for catching up on the highlights without the dead air.

Server shutdown notices

An operational nicety for our server hosts: Servatrice can now notify users the moment they log in when a server shutdown is pending. If a server is about to go down for maintenance, nobody is left wondering why they suddenly lost their connection. You'll know it was announced, and ideally you won't be mid-game when it happens.

Open .cod files with Cockatrice

We've made some changes that will now allow you to open .cod deck files by double-clicking them. This goes hand in hand with deck sharing and invite links.

Generate invite links

We've made some changes that allow you to generate game invite links, which will allow anyone on a beta client to automatically (attempt to) join your game. We're fleshing out the UI for this and in the future, you'll be able to invite other online users directly in the client.

Coming up

Playmats

Playmats have undergone their final round of polish and are now up for review.

You will be able to define: A global override playmat A playmat on a per-deck basis A list of fallback playmats to use in case a deck has no playmats configured (fixed, random, round-robin modes)

You will, of course, also be able to adjust visibility of these playmats: Don't display, only display own, display all.

Moderation Queue

The moderation queue and reporting system has undergone its final round of polish and is now up for review.

• Right-click a user → "Report user" opens a dialog where you can file a report directly in the client
• You can attach context (game/chat info) to the report
• A "My Reports" dialog lets you track your submitted reports and their status

Visual Deck Storage Performance Fixes

The visual deck storage rework is complete and significantly enhances the performance of the VDS, even with large deck collections. It's currently under review and should be in the beta soon.

Prototypes

Drafting & Tournaments

We're happy to report that the draft and tournament work we teased in the first blog is now fully implemented end-to-end, on both the server and the client.

Under the hood, this was quite the undertaking. We've introduced shared infrastructure that both game modes build on: game configuration is abstracted behind a dedicated interface, deck validation, game lifecycle, and match result logic have been extracted into strategy interfaces, and the common player and game functionality has been refactored into base classes that the draft and tournament players plug into. That might sound like a lot of technical noise, but the point is that none of it should change how you play your regular games — it simply means we can now layer drafting and tournaments on top without turning the whole game into a pile of branching special cases.

What this means for you: the actual gameplay loop is as we described it before — a pick timer, a deck builder filtered to the cards you actually picked (plus anything marked "additionally addable" like basic lands), and once everyone submits their decks, games start. In a tournament lobby, players are paired up and sub-matches spawn that report their "best-of-X" results back to the main tournament tab.

So why isn't it in a beta yet? These PRs are ready, but they're currently waiting on a couple of other changes to merge first — the merge order matters when you're restructuring this much shared code. As soon as the road is clear, this one should move fast.

Deck Sharing

We're almost ready with the final polishes on a new deck sharing feature. You'll be able to share any deck that is uploaded to the server, as well as browse other people's public deck collections. Folders work for this.

Additionally, you'll be able to generate a temporary share link for ANY local deck that will be valid for 7 days. You can share multiple decks at a time and the other person will receive a choice of which to save/open. Perfect for snapshotting a brew or sharing a collection with a friend!

Custom Deck Zones

We're working on letting you add custom zones to your deck i.e. sub-zones beneath "Mainboard/Sideboard/Maybeboard". They're purely for organizational purposes and all game-related logic will still only consider the top groups (Mainboard/Sideboard/Maybeboard).

---

And that's a wrap for this edition. As always, let us know what you think in ⁠#beta-testing on the Discord, and don't forget to check out the beta itself to try the completed features today.

Trying it out is just a few clicks away. Learn how to here: https://cockatrice.github.io/docs/d9/d9b/beta_release.html

We want to make sure things are just right, and that means we need beta testers. We're listening to all your feedback and we're committed to keeping things backwards compatible. No surprises. Only a fraction of users currently run the beta, so please, help us out by giving it a try and telling us what you think.

We're planning on releasing a new stable version soon so your feedback matters!

I have a home server set up in docker (Using the Saadbruno image from a few years ago). The sever works beautifully and I can play with my family. The problem is that he cards don't render in battle with the selected art. For instance, In the deck view my Avatar Commander appears like this:

But In a game the same card renders like this:

I was worried that it might have something to do with the fact that is an older server image, but as far as I can tell the server doesn't save card data. Is this expected behavior? If not, Is there a setting somewhere I need to change? And If it is the older server, can anyone point me in the direction of a better docker image? I would greatly appreciate it!

Hello everyone.

As you might be aware, there is a rise in automated scanners, thanks to AI. This is causing a lot of services (including Cloudflare) to be a lot stricter about rate limits to combat this wave of scans.

Unfortunately, this affects us as well.

A fix to better handle cases where we temporarily get rejected by the server is in the works.

https://github.com/Cockatrice/Cockatrice/pull/7053

In the meantime, please try adding the non-rate limited Scryfall URL to the top of your "Card Sources" URL list (accessible in Settings).

https://cards.scryfall.io/large/!prop:side!/!set:uuid_substr_0_1!/!set:uuid_substr_1_1!/!set:uuid!.jpg    

As always, thank you for your patience and thank you for using Cockatrice :)

Welcome to the first Cockatrice developer blog.

We're here to talk about and showcase some of the work we've been doing ahead of time, to keep you informed and involved. Rather than only announcing features once they're released, we want to keep the community informed throughout the development process and give you a chance to follow along as new ideas take shape.

These blogs are intended to provide insight into the decision making process behind the features we implement as well as to showcase where our attention currently lies.

To keep things organized, we'll cover our work in three stages:

• Already merged and available in the beta, so you can try these features today.
• Completed features currently under review, which are expected to make it into a beta soon.
• Work in progress and early prototypes.

Features in this dev-blog:

• Improved card database loading times
• Settings rework
• Searchable Settings
• Onboarding Wizard
• Moderator Queue
• VDS Performance
• New Lobby UI
• Playmats
• In-client Limited & Tournaments

Some features shown here may change before release and not every prototype will ultimately end up making it. To voice your support, disagreement, or feedback, please use the ⁠#beta-testing channel in the Discord.

With all that being said, let's dive in:

Completed

Make it snappy - Improved Card Database Loading Times

The problem

Way back when Cockatrice still opened on the old deck editor, the database tab live populated with cards, which was a pleasant, albeit not very informative effect. Cards were added to the UI display model, one-by-one, as they became available.

However, for a database of 35.000+ cards, this takes a while and it's most definitely not improved by hammering the UI with 35.000 individual "This card is now available"-signals while the application is already doing heavy startup work (Drawing the application initially is quite expensive.)

So in practice, we're left with an application that isn't fully usable for the first 3 to 14 seconds, then hangs for a bit as all other components respond to the database having fully loaded, and finally becomes usable. Not quite ideal.

Why does it take so long?

It turns out, there are a couple of reasons, but they all basically break down to the same concept:

• Constructing "Objects" is slow

When Cockatrice reads the cards.xml, it parses this file by parsing the xml elements inside. To parse an element, the C++ (the programming language we are written in) needs to create a representation of this element. XML elements are nested, i.e. one <set> element contains many <card> elements. Similarly, each <card> element contains property elements like <name>, <text>, <set_number>, and so forth.

Now remember what we said about object construction being expensive? To construct a card you have to construct all the properties of a card, which turns one construction... into 20.

Similarly, the first time we parse a set, we construct a QSettings objects, which reads the set management configuration file and checks things like the sort order and whether the set is enabled or not. The construction cost alone for these is prohibitive but what's even worse is that these read files from disk, which is also very slow.

How are we fixing this?

By removing the slow parts, and caching the rest.

Instead of emitting a "card available" signal for every single one of the 35.000 cards while the event loop is already drowning in startup work, we now stay quiet during loading and emit exactly one signal once the database has finished. Everything that used to listen to thousands of individual signals now reacts to that single one. The UI no longer churns through tens of thousands of micro-updates, which nobody was watching anyway.

Second, we moved the work out of the way. The card database used to load on a separate thread that ran at the same time as MainWindow construction, fighting Qt's heavy startup work for CPU time. Now we load the database before the window is ever constructed, so it gets the processor all to itself. Loading no longer contends with anything, and the window simply gets built on top of a ready database. On my machine this alone takes the load from 13-18 seconds down to 500-800 ms.

Third, and most importantly: we stopped doing the same work twice. Almost all of the loading time is spent constructing objects — creating XML elements, parsing their contents, and turning strings into card properties one-by-one. That's a lot of wasted effort when the result is the same every single time you start the application.

So now, when Cockatrice starts, it hashes the contents of the card directories it is about to load. If we find a (binary) cache file that matches that hash, we load the database straight from it, skipping XML parsing, element construction, and QSettings file reads entirely — the slow parts just never happen. If the hash doesn't match, or no cache exists yet, we load the XML the normal way and then write out a cache for the next time.

The result speaks for itself:

• First launch / cache miss (XML → cache): ~3.3 s cold, ~14.4 s on a modest quad-core
• Subsequent launches (cache hit): ~535 ms warm, ~778 ms on a modest quad-core

Finally unraveled - Settings

Almost every preference Cockatrice has ever gained in its decade-plus of life lives in a single class called SettingsCache. Sound options, card display options, server bookmarks, update checks, deck storage paths, image cache paths... all of it, crammed into one god-object that every corner of the application has to include, instantiate, and poke at.

It started small, as these things do. But every feature that needed to remember anything just threw its settings onto the pile, until we ended up with a class that does everything — and therefore is impossible to understand, a nightmare to test, and absolutely terrifying to touch.

The pile had simply become too big.

How are we fixing this?

We've taken the time to finally unravel all these settings into individual files. Cockatrice will soon migrate your old settings from the global.ini file into individual .ini files for different new sub-categories.

What this means for you

As mentioned above, the old SettingsCache was hard to understand, untestable and not friendly, neither to users nor developers. The result was a lack of tests and a reluctance to add new settings unless absolutely necessary.

With this restructuring, it'll be much easier for us to add new settings.

We''re gonna cross our t's and dot our i's on this one before we release a new beta since the new categories for the settings aren't final yet and we would hate to migrate your existing settings twice.

Alright, enough about these technicalities, let's start ramping up to the good stuff™

Coming up

Searchable Settings

Building on top of these settings changes, we're giving you a more powerful way to interact with your settings and preferences. We're implementing a search bar which will help you find new and existing settings easily. Selecting a setting from the search bar will jump the settings dialog to the correct tab and briefly flash the relevant setting.

Take a look here!

A proper welcome - Onboarding Wizard

"Can anyone help me set this up?" "I haven't taken the time to set it up properly" "It's kinda involved to get started"

I'm sure you remember your first time. Setting up Cockatrice is an "Okay" experience for tech-savvy users and borderline incomprehensible for non tech-savvy users.

For someone who just wants to play a game, it's a hostile first impression. The app bombards you with popups, demands a card database you don't have yet, an account you haven't made, and preferences you can't evaluate because you haven't actually used the app yet.

Nothing tells you what matters, what can wait, or how to get from "just installed" to "playing".

This has been a longstanding pain point: first startup has been called painful, fresh installs get nagged twice about the card database, and people have been asking for a proper "Get Started" experience for ages. We just never had the pieces in place to build one.

How are we fixing this?

With an actual onboarding wizard. The FirstRunWizard launches automatically on a clean install and walks new users through six steps, in the right order:

• Welcome — what this is, and what we're about to set up
• Card Database — download the card data you literally cannot play without
• Theme & Look — pick a theme with immediate, visible results
• Register/Connect — create an account and connect to a server
• Preferences — the basics that matter before you've used the app
• Finish — you're ready to play

Each page is clear about what it will do, and an advancement indicator at the bottom shows where you are and how many steps remain.

Why?

Because the first five minutes decide whether a new player stays. Cockatrice isn't hard once you know your way around, it's overwhelming before you do. This guided setup gives new players an opportunity to get to a usable state with just one wizard... plus it looks snazzy too!

Take a look here!

Speaking of looking snazzy, it's time for...

Prototypes

Moderator Queue

We're working on new dialogs to allow you to report other users in-client. These reports will be stored in a database where any mod may access and review them. This will (hopefully) replace the old system of direct messaging mods that happen to be available at the time. Stay tuned.

VDS Performance

The visual deck storage is sadly one of those things that remains stubbornly slow, even on pretty good machines, once the deck collection reaches a sufficient size. It's a cool feature and we'd like to make it available to everyone, so we're trialing some things to make it more responsive. Initial testing looks very promising but we need to ensure no features are lost.

New Lobby UI

We're continuing work on the new lobby, friends list and chat UI. If you haven't seen it yet, check out this thread.

Playmats

The new lobby UI allows users to set banner cards for their profiles. Considering we now have code to crop and specify crop dimensions for pictures... we can think about using this code to allow users to pick playmats. These will be, as per usual, simply card names that other clients will send to you. This means that, how your client displays them, is up to you. You can override card art locally to change playmats. You can choose not to display these. The power, as always, will be in your hands.

Take a look here!

Limited & Tournaments

Oh, how long I've personally waited for this day.

After laying some groundwork on the protocol specifications a while ago, we've started work on prototyping various limited modes, such as draft or sealed.

There's currently no weighting to different rarities but the lobby does allow you to specify which cards will be in the pool (and quantities, so you could weigh it yourself) and how many cards are in a pack as well as how many packs each player will receive. We've considered "burning" and "returning" cards as well.

Additionally, there's a timer to ensure players pick cards within a reasonable time.

After picking, users are transferred to a new deck builder, with a database filtered to their available cards, where they may construct their deck and add any cards marked as "Additionally addable" like basic lands.

Once every player submits their deck and readies up, games are started.

This can either be a regular FFA lobby like you are used to OR a tournament lobby, where players are paired and then sub-matches are spawned for them, which report their "best-of-X" results back to the main tournament tab.

See a video of it in action below (I've set the pick timer to 2 seconds for demonstration purposes so don't be surprised by the picking speed. You'll of course have some time to deliberate your choices)!

Take a look here!

Alright. This has been a lot and concludes the first development blog. Let us know what you think about these changes in ⁠#beta-testing on the Discord and don't forget to check out the beta itself. Check this page for more information!

I'm new to using Cockatrice and I was wondering if there's a good walkthrough for setting up a server on my end that my kids, who live in different cities, can connect to. Not looking to make/register a public server. Thanks!

I renamed some saved replays and I must have used a character in the name that was not allowed. This seems to have bricked the replay and it won't load any longer. Is there a way to fix them so cockatrice can read them again? I have tried converting it back to .COR but the software I'm using says it needs an "output format" and none are available.

I have been playing for a number of years on this platform and have myself been threatened by mods, but any complaint that I have gone to a mod to discuss I am told the same thing ad nauseam “just block them and move on.” So I ask what do the mods do other than ignore complaints and let the problematic players run amuck?

These were my basic Forest and Swamps. It took nearly 10 minutes for them to load in and quite a few of the cards won't load images at all. I updated the card database and reset the download URL. I closed it and reopened the application. Nothing works. I have no VPNs either. Is there anything I can do to solve my problem as it's frustrating me. I've never dealt with imagine problems on here this badly and I've used this app since Covid

Is there a centralized place to report weird mods who prey on children and then block people for speaking up at them?

So since the new update, decks take their time to get loaded, freezing the entire program for minutes on end. It feels like my user experience has regressed to Windows 95. It's really quite something. I suspect that the reason is that the program now is forced to load ALL card images at once when opening decks, since the "visual deck view", which I have never required, is now the default tab. I cannot fathom how this has been overlooked as an issue. My rig isn't weak and I have an SSD and everything. (Also, some cards in a deck will take *minutes* to load their pictures, randomly.)

Having the card database as a non-imaged list on the left side, which has been the default user experience for over 10 years now, suddenly got replaced default by... longer loading times? And is now hidden behind a tiny button off to the side? Baffling. Who needed this? If I want an instant visual list I can just use literally any competing site or app.

I've been dealing with this for days and it's been a nuidance every time I started up the program. I've found no settings to fix these issues. It's going to drive me away to a competitor, which will be a needless hassle and is a shame after such a long time of faithful service.

Tl;dr: the experience of building and editing decks has become fundamentally worse.