itch.io

Thanks for both reports — they were really well written, and the first one turned out to be exactly what you suspected.

Bug 1 — enlarged card can't be closed in the deck builder: fixed.

You found a real one. The deck builder was the only screen in the app that opened the enlarged card through its own code path instead of the shared one, and that path had two holes that combined into a dead end:

• The enlarged card was wrapped in a container that stretched to fill the whole layer, so the only spot the app recognised as "clicked outside" was a ~40 pixel strip right at the very edge of the window. Effectively impossible to find.
• That layer didn't listen for the keyboard at all, so Escape did nothing.

That also explains why it worked fine during an actual game: the in-game view uses the correct shared path, which closes on Escape and on a click anywhere.

The fix was to delete the custom path entirely and route the deck builder through the same viewer everything else uses. So now, in the card grid, the "View the deck" category screen, and the commander row, the enlarged card closes with Escape or with a click anywhere on the screen. As a bonus you also get the keyword explanations (click a keyword pill to see what "deathtouch", "vigilance", etc. actually do).

I verified it end to end with automated screenshots — one confirming the card opens, one confirming Escape brings the deck builder back intact — and the full 15-check regression suite passes. It'll be in the next build. Sorry about the six or seven restarts; that's a rough way to build a deck.

Bug 2 — Coram, the Undertaker: I can't reproduce it yet, and I'd like your log.

I dug into this one but came up empty so far. There's nothing unusual about Coram from the interface's point of view — the attack trigger is an ordinary mill and the +X/+0 is a static ability the rules engine handles on its own. I then ran two full 4-player Commander games with all four seats playing the Coram precon, one headless and one with the full interface running (49 turns, Coram cast and attacking multiple times). Neither crashed.

So it isn't a deterministic engine bug with that card. What I can't rule out is the specific path where a human declares the attack, which is your case and the one I can't automate here.

One detail makes your report especially interesting: if the game thread dies, NeoForge is supposed to catch it and show you a message ("the game has broken", with a button to leave). The fact that you saw nothing at all suggests the whole process died, not just the match. The log would tell us which.

Could you send me these two files? In the Windows download everything lives inside the game folder:

NeoForge\datos\neo\neo.log NeoForge\datos\neo\neo-anterior.log

⚠️ Important: if you reopened the game after the crash, the one that matters is neo-anterior.log — the log rotates on startup, so the crash is in the "previous" file. Send both and nothing gets lost.

Also, please check whether there's a file named something like hs_err_pid1234.log sitting loose in the NeoForge\ folder next to the .exe. That file only appears when Java itself dies outright, which is what this looks like, and it has the cause written in it.

And one question that would help either way: did this happen once, or does it happen every time you attack with Coram?

Thanks again — this kind of report (exact sequence, what you already tried, what still worked) is what makes these findable.