There is no single DREADMOOR version number that safely describes the main game, demo and historical playtest together. They are separate Steam applications with separate build records. As of November 2, 2026, the main game is still awaiting its November 9 Early Access launch.
For the installed demo, compare the demo application and the version shown by that installation. An older guide's number or a different app's public build does not establish your current version.
Start with the application name
| Application | Steam App ID | Relevant version history |
|---|---|---|
| DREADMOOR | 3629430 | Main-game builds |
| DREADMOOR Demo | 5219790 | Public demo builds |
| DREADMOOR Playtest | 3808110 | Earlier testing builds |
A build ID is a Steam record identifier, while a label such as v0.3.39 is an in-game version label. Do not convert one into the other or assume the numbers need to match.
What the November 2 snapshot contains
The captured demo record lists public build 26254439, built on October 27 and updated on October 28. The captured main-game record lists public build 26096345, with an October 21 build and update date.
Those are dated records, not a permanent claim that either number is the latest whenever you read this page. They also do not mean that the unreleased main game was publicly playable on the record's update date.
The old Playtest record lists another build history and a disabled release state. It is not the correct record to use when diagnosing an October demo installation.
A public branch label describes the branch within that app's records. It does not erase the distinction between a demo, a limited test and an unreleased purchase.
November 2, 2026 snapshot. The relative update labels refer to this capture, not the current date.
Compare a bug report to your actual build
Before applying a claimed fix, record three things together:
- The application you launched: Demo, Playtest or main game.
- Any version label displayed by that installation.
- The date and symptom described by the report you are comparing.
A guide might describe a generator interaction from one demo build and a later player's pickup recovery from another. The later observation does not prove every existing save was repaired. The same principle applies when a waterwheel objective or fishing interaction changes during development.
Keep the symptom precise. A can with no pickup prompt differs from one that pours too little fuel; an unfinished machinery repair differs from incorrect water routing. A higher version number alone does not identify which problem a report actually resolved.
Do not invent a changelog from a build entry
A build record can exist without official patch notes. One historical Playtest entry explicitly has no official notes beyond changed depot files. That does not establish a balance change, a new feature or a specific bug fix.
Likewise, an asset-modification timestamp is not necessarily a gameplay update. A new trailer, store image or metadata change must not be relabeled as a playable patch.
If no official notes describe a claimed fix, treat the effect as unconfirmed. Checking the app and build helps avoid a mismatch; it does not replace a documented explanation of the change.
Keep old saves separate from the demo transition
The October 6 demo announcement warned previous playtest participants not to continue old saves because of possible bugs and crashes, and recommended beginning a new demo game.
That warning concerns the transition from older testing material. It is not evidence that deleting saves fixes every issue in every later build. Preserve saves externally before choosing a reset, and do not assume progress carries between the separate applications.
For a current version check, use the installed app's identity and the current update information together. Avoid a standalone “latest version” download claim that provides neither the application nor the date.