Cfx Publishes Patch Notes for Enhanced — I Was Diffing Binaries Instead

Enhanced server builds don't publish like Legacy artifacts. There's no numbered page with a changelog next to each one; the download link is an opaque UUID and the only version signal you get is the boot log telling you a newer build exists. So from launch I'd been doing what you do when there's no changelog: pulling strings out of each new cfx-server.exe, diffing against the last one, and reading the tea leaves. New convars, renamed natives, new error messages. It works. It's also completely blind to why.

On 12 August I said, roughly, "Cfx posts a hotfix list sometimes on server updates — it looks like context was missed from our diffing." And it had been.

Where they are

Every Enhanced early-access update gets a post in the Patch Notes category of the citizenfx/rfc Discussions:

github.com/citizenfx/rfc/discussions/categories/patch-notes

Ten posts between 21 July and 11 August — one for every build Eclipse City had run. I'd read exactly one. Meanwhile my own runbook was telling me the string diff "is the only changelog this line has."

Two things make them easy to miss. They're Discussions, not Issues or Releases, so the GitHub search and Issues APIs can't see them at all — you scrape the Discussions page as HTML or you don't get them. And they carry no build numbers; they're dated, not versioned, so mapping a note onto a bNNN still needs the boot log. The diff didn't become useless. It stopped being the primary source.

What the backlog corrected

I read all ten in one sitting and checked them against my own notes — the ones every agent session I run my ops through inherits as "permanent platform facts". Five of those facts were already false:

What my notes said	What had actually happened
SetHttpHandler POST bodies are undeliverable; push callbacks into the game server are a dead end	Fixed 11 Aug: "Fixed SetHttpHandler to return valid responses and pass POST data correctly." Landed the same day my probe ran, so the probe simply predated it
The NUI allowRefocus leak needs filtering in every message handler	Fixed 6 Aug (Hotfix 8). Six days of writing filters for a solved problem
Players going invisible after exiting a vehicle needs a local workaround	Fixed 30 Jul (Hotfix 7): "Players no longer turn invisible to others after exiting a vehicle until they move again"
localhost must be 127.0.0.1 in server.cfg to stop "Net permission check" spam	Fixed 30 Jul (Hotfix 7). Harmless either way
GetGamePool('CObject') is a permanent Enhanced crash class	Fixed 27 Jul and again 4 Aug. My workaround was written three days after the first fix, and hardened a fixed bug into a permanent belief

That last one is the pattern to be scared of. A workaround written after the fix doesn't just waste time; it becomes a rule, and every piece of code after it is shaped around a problem that doesn't exist.

Two more things fell out of the same read. A client crash I'd been tracking since late July — a truncated-pointer access violation in eight of ten dumps — is named specifically in the notes, twice, as a fixed bug. And the "game-view screenshot capture returns blank frames" problem that I'd pinned down as upstream on day one had three open bug reports in the same repo (#145, #156, #281) that nobody on my side had gone and found. When you already know something's upstream, searching the upstream tracker is the next move, not writing the symptom into a local doc phrased as if your box caused it.

A patch note is a claim

The other thing the backlog teaches, if you read it end to end, is restraint. NetworkIsPlayerTalking has been "fixed" three separate times — 24 July (Hotfix 4), 4 August, and 11 August as IsPlayerTalking. An earlier rfc thread had claimed a fix at b96/97 that was still broken at b98. So: read the note, then re-probe before you delete a workaround. The note says what should have changed. The diff and a live test say what did.

The workflow now

1. Read the patch note first. It tells you what changed and why.
2. Then diff the build. The diff catches what the note omits and confirms the note landed.
3. Map the note to a build number using the boot log, because the note won't tell you.
4. Re-probe before deleting any workaround. Mark it "unverified on current build" rather than ripping it out on the strength of a sentence.
5. Read the docs page on what changed in Enhanced before anything else — it turned out to be more useful than the notes.

That last page settled something I'd had wrong for weeks on its own. I'd been running sv_enforceGameBuild latest, which threw an error at every boot ("Only 1 is supported to remove any game dlcs") that I'd been reading as a deprecation warning to sit out. It was an invalid value, silently ignored. The docs are explicit: the latest build loads by default, and 1 is the only valid value, for people who want the base game with no DLC. Omitting the line is byte-for-byte the behaviour I already had, minus the error. A full audit of my server.cfg against the same page found exactly one bad line — that one.

FAQ

If you run Enhanced and you've got a "known platform limitation" in your notes that's more than a couple of weeks old, go and check whether Cfx fixed it while you weren't looking. And if you find one of mine that's still wrong, tell me on Discord — I'd rather be corrected than consistent.

---

Share: Twitter · LinkedIn