- horizon-bench reads the machine with horizon-telemetry's `command_output` (now public) instead
of a second copy of it; the console flag lives in one place.
- horizon-server's `process::command` hides the console only when the server has none (started
by the launcher). Run from a terminal, `schtasks`, `tar` and `mklink` share it as before, so
their output still reaches it: a CREATE_NO_WINDOW child can't write to its parent's console.
- horizon-prepare's java/javac keep the stdin they had; only the console flag is new.
- launcher `process::hide_console` returns the command (no `let _ =` on other systems); the
machine-details thread failing just leaves the report without them, as a slow one does.
- README: the Windows subsystem's effect on the command line (interactive cmd/PowerShell don't
wait or set the exit code) under "Command line", the deferred probe under "Performance log".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Render nearby rows in the existing page scrollbar, defer hidden icons and cached verdict reads, and preserve bottom anchoring as row heights are measured.
Co-Authored-By: OpenAI Codex (GPT-6.1 Sol) <noreply@openai.com>
Collect performance-report hardware after the first frame and preserve logs, input and CLI pipes while suppressing background terminal windows.
Co-Authored-By: OpenAI Codex (GPT-6.1 Sol) <noreply@openai.com>
Keep page content and pixel art responsive, align navigation left, and use native Windows control hit regions in themed chrome.
Co-Authored-By: OpenAI Codex (GPT-6.1 Sol) <noreply@openai.com>
A developer of Iris showed that Horizon's shader pack code was written from
Iris's source. This removes it: the horizon-shaderpack crate, Java pack
loading and its render stages, Horizon's own WGSL packs and the example
packs, the Shader Packs screen and its option, the launcher's shader pack
browsing and installing, and the docs about them. Shader packs may come
back later as a clean-room rewrite.
The vanilla renderer and its post-processing (resolution scale, FXAA) are
unchanged. Options files that name a pack load and drop the key; the
launcher reads manifests that list a shader pack, and files in
`shaderpacks/` are never deleted.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every release is now published as the release (one channel, Ludovic's
decision of 2026-10-23), so the launcher drops its Stable/Alpha choice:
the Updates row in Settings, `horizon-launcher update-channel` and its MCP
tool, the channel on the Versions page, in `versions` and in the footer.
It updates to the newest game release that is not a pre-release (GitHub's
latest) and looks every 30 minutes. The pre-releases of the old Alpha
channel stay listed and installable by hand, never as an update. Old
`update_channel` / `beta_builds` keys in settings.json are ignored.
On Linux a release build that starts no longer rewrites the
applications-menu entry to point at itself. It writes the entry only when
there is none, or when the program it starts (TryExec, else Exec) no longer
exists; turning the Settings switch on or `desktop-entry` still points it
at this launcher, and HORIZON_LAUNCHER_DESKTOP_EXEC is still honored. A
test build started with the real HOME took over a working entry and then
left it broken when its target/ was deleted (2026-10-23).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The MCP tools are generated from the CLI's clap definition (cli_tools.rs):
mods_search is horizon-launcher mods search, with the same arguments, and
a call runs that command with --json. So the mod browser, modpacks, hosted
servers, settings, game arguments, data collection, desktop entry and the
benchmark are all reachable, and new CLI commands become tools by
themselves. Destructive ones need confirm: true and carry destructiveHint.
The session keeps play, server (with server_command/log/stop),
account_list and account_sign_in in-process, renamed after the CLI
(launch_client is play; play takes join for an invite code).
New CLI commands: settings [KEY VALUE] (selected version, folders,
install-new-versions, opening animation) and agent-config, the MCP config
for Claude Code, Codex, Cursor and any client. play takes --world and
--creative. Under No AI, mcp and agent-config are hidden and refused.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Drop the Horizon menu style (options_horizon.rs, front.rs, the live title
backdrop and its post grade, the launcher's menu-style setting, CLI and MCP
tool). Every screen is vanilla's. Horizon's own settings hang off vanilla's
Options the way mods add theirs: Horizon Settings... and Mods... take the
Telemetry/Credits slots, and Horizon Settings opens Graphics, Advanced
Graphics, Shader Packs, Controller Settings, Extras and Mods, each a vanilla
options list with tooltips. Play with friends moves behind vanilla's Friends
buttons: the pause menu's opens Play with Friends (share, copy, stop), the
title screen's opens Join a Friend, and Direct Connection takes a full code.
Old files load as before: horizon.txt's menuStyle line and
horizon-graphics.txt's level line are ignored.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ludovic dropped CurseForge for now (its API needs a paid key). The Mods page shows
"CurseForge (coming soon)" beside the Modrinth switch, disabled and inert;
browser::sources() is Modrinth only, so no search or install goes to CurseForge,
and `--source curseforge` says it is coming soon. Text that asked for a key or
an environment variable now says CurseForge support is coming soon. Importing a
CurseForge zip or instance still works; jars only CurseForge serves are listed
as "CurseForge downloads coming soon".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The whole of Horizon is in beta, so the channel that installs every build as
soon as it is built is called Alpha; Stable keeps its name. The launcher's
Settings, the update-channel command, the MCP tool, the release notes footer
and the docs say Alpha. update_channel is saved as "alpha"; "nightly" and the
old beta_builds switch still read as Alpha.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The daily promotion moves to 20:00 UTC (21:00 in Paris in winter time):
PROMOTE_AT and promote.yml's cron (20:07, retries until 21:37), with the docs
that give the time. A launcher left open on Nightly looks for new releases
every 30 minutes; Stable keeps 4 hours. The launcher README's Settings
screenshot shows the Updates choice.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The launcher's "Beta builds" switch becomes an Updates choice of two channels,
stored as "update_channel": "stable" | "nightly" (an old "beta_builds": true
reads as nightly). The CLI (update-channel) and MCP (update_channel) show and
set it, and list each release's channel as stable or nightly.
Nightly ships constantly: the release train waits 5 minutes for a merge wave to
settle (20 at most) instead of 15 (an hour). Stable moves once a day:
promote.yml runs at 19:00 UTC (retries until 20:37) and promotes the newest beta
that had been out 6 hours by 19:00, so late runs and retries pick the same one.
The stalled-promotion issue waits 30 hours. Release notes, docs, the website's
install and FAQ pages say Stable and Nightly.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Mods page between Versions and Modpacks: resource packs, shader packs and
modpacks as tabs, a search field, Show everything, and Modrinth / CurseForge
once CurseForge has a key. Results are index rows with summary, author,
downloads, source, licence and how well each runs (with the reason), Page and
Install (Import for a modpack, which then shows on the Modpacks page).
Installed packs list their version, source, file and the checksum they were
checked against, with Update and Remove. Searches, installs and update checks
run on threads; stale search answers are dropped.
Fixes#577
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
browser::installed installs a pack and its required dependencies into
resourcepacks/ or shaderpacks/, every file checked before any download
(a dependency that is a Java mod stops it) and checksum-verified on the
way in; mod-browser.json records source, version, file and checksum.
Update swaps the file, remove deletes only what the browser installed (a
player's own file of the same name is never overwritten). A modpack is
downloaded, checked, and imported through the Modpacks page's pipeline.
The CLI gains `mods list|search|install|update|remove`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From 0.2 the game is tagged vX.Y.Z and the launcher launcher@X.Y.Z (docs/versioning.md). The launcher
compared every tag number by number, so it would never offer game v0.2.0 over v2026.10.19.15 nor
update itself to 0.2.0 from 0.16.0 (launcher-v0.2.0 is also taken by an old release).
- release_order(): tags from before 0.2 (vYYYY.MM.DD[.N], launcher-vX.Y.Z, bare versions) compare as
before; every 0.2 tag follows them, in semver's order (a pre-release before its release).
- own_tag(): the tag this launcher was released as. launcher.yml will pass HORIZON_LAUNCHER_TAG; a
release with only HORIZON_LAUNCHER_VERSION was a launcher-v one; a build from source is on 0.2.
So the last launcher-v release (the bridge old launchers can see) updates itself to launcher@.
- The matching-refs fallback looks for launcher@ tags first, then launcher-v.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
horizon_launcher::servers keeps the list of servers and drives horizon-server
for them: create (init, then config set), start, stop, backups, settings, the
service, and the running supervisor's control API for the live status, the log
and console commands. The programs come from an installed, prepared version,
laid out as install.sh does (server-runtime/releases, current, game-files), so
horizon-server update and its rollback work on them unchanged; the game files
are a copy of the player's own prepared files.
Problems come back in plain words with the fix to offer (a busy port with a
free one, missing game files with Prepare, the EULA).
horizon-launcher servers list|create|set-up|run|forget does the same from a
terminal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Settings gains a one-line Game arguments field, kept as `game_args` in
settings.json and appended to the client's command line after the
launcher's own, so a player can pass things like `--server-thread` or
`--render-distance 40`. Quotes group a word with spaces in it.
`horizon-launcher game-args [<line>]` shows or sets the line,
`play --arg <ARG>` passes one for a single run, and the MCP launch_client
tool takes an args array. The same splitter feeds all three.
Closes#716.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Modpacks page between Versions and Patch notes (docs/modpacks.md, the
working version's launcher step):
- Import a pack file (.mrpack, CurseForge zip) or an instance folder (Prism,
MultiMC, CurseForge): horizon-port-pack's import, inventory (Modrinth by
file hash) and report into ports/<slug>/ in the game's home.
- The coverage report: ported, partial, not yet and not needed, with every
mod's class, tier, licence and reason, filtered by status.
- Port: the portable mods' jars (content, data tier) the player's own way
(their folder, the pack's links, Modrinth's CDN; what only CurseForge has
needs its key and is said so), carried over for the selected version's
prepared tables; the pipeline's log shows while it runs.
- Play: the game as the pack's own profile, ports/<slug>/home/ (its saves,
options.txt copied from the player's the first time) with the carried-over
mods as dev mods. The session flow is shared with Play (start_client).
- The same from the command line: horizon-launcher modpack list | import |
port | play | remove.
Nothing is uploaded or shared; jars and ports stay in the game's home.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- First run (and when CONSENT_VERSION changes): a question over the launcher
with four switches, all off, what each sends in plain words, what is never
sent, "View what would be sent" (the exact JSON), and "Send nothing" /
"Save choices".
- Settings → Data collection: the same switches any time, the install ID and
what waits, "View what would be sent" and "Delete my data" (server deletion,
outbox cleared, new install ID).
- The outbox is sent at start and on close (at most 3 s), only when there is a
server (none yet) and only what the player allows.
- CLI `horizon-launcher data status|allow|deny|show|delete|send|bug|benchmark`
and MCP tools data_collection, set_data_collection, data_preview,
delete_my_data, report_bug. Bug reports and benchmark uploads are printed for
the player to confirm; logs are scrubbed and lose chat lines.
- horizon-telemetry joins the launcher's paths (launcher.yml, release_train,
pr_ready).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An agent now needs one MCP server. horizon-launcher mcp runs the selected
version's horizon-ctl mcp as a child and offers its tools as game_<name>
(all but launch, which launch_client covers), passing calls and image
results through. launch_client starts the game with a control socket in
the launcher's data folder, takes world, creative and offscreen, and
returns once the socket answers. A game tool called while no game listens
says to call launch_client.
tools/launcher_mcp_e2e.py checks it end to end against this checkout's
builds in a scratch launcher home.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each session rewrites benchmarks/launcher-<time>-session.json in the data
folder (report format v1): start to first frame, release list fetch,
install/update and prepare durations, Play to the game's first frame (the
game now logs its first frame), RSS, UI frame times, binary size.
horizon-launcher benchmark starts the launcher N times (cold, then warm),
switches pages, measures idle CPU and memory and the release list fetch,
and writes one report with means and 95% CIs. Nothing is uploaded.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A top bar (the mark, Horizon, the pages as text) replaces the sidebar; a mono footer carries
the launcher's version, its update and the community links. Every page is a display title, a
short muted line, then an index list: Play's resources and folders, the versions with their
names large and their size and state in mono, the patch notes, the settings. Buttons are pills,
the main action is the one violet thing on the screen, selection is an ink pill, the console,
notices and the crash report sit on soft plates without borders. The Play page ends with the
faint wordmark, half set below the window's edge.
The sunset photograph and its veils are gone (and the `image` dependency with them): the
window is the page colour, light or dark with the system. The opening draws the wordmark
letter by letter, then the launcher rises into place. HORIZON_LAUNCHER_APPEARANCE=light|dark
overrides the system's appearance, for screenshots and tests.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
launcher.yml releases the launcher by itself: after a push to main that changes launcher/,
crates/horizon-prepare or crates/horizon-theme, hourly, and by hand, with the game's rules
(tools/release_train.py decide --kind launcher: player-facing pull requests and a 3-hour cooldown,
release-now, skip-release, RELEASES_PAUSED). launcher-vX.Y.Z is the next patch, or the next minor after a
pull request labelled feature. Linux on ubuntu-22.04, Windows on GitHub, macOS on the Mac mini's runner;
published with --latest=false.
No version-bump commits: VERSION reads HORIZON_LAUNCHER_VERSION with option_env!, falling back to
Cargo.toml's, and --version, the User-Agent and the self-update comparison use it; each build checks
--version says the release's version.
With several game releases a day, the newest launcher release soon falls out of the newest 100 (launcher)
or 30 (website) releases: both now look the newest launcher-v tags up one by one when the list has none.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tools/fetch_sounds.py (and the lab.py functions it used) becomes
`horizon-prepare sounds` (horizon_prepare::sounds): the pinned asset index,
sounds.json and every .ogg from the player's own launcher install, each SHA-1
checked, into .local/horizon-client/<version>. The launcher runs it as part of
Prepare (in-process, the version's own binary when its sources differ and it
knows the subcommand, in-process for older versions), and a launcher install
without the assets only logs that the game will be silent. Player docs no
longer mention Python for sound.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The game writes logs/latest.log in its home like vanilla's log4j config
(client-1.21.2.xml): [HH:mm:ss] [thread/LEVEL]: message, rolled at start and
at midnight to logs/<date>-<n>.log.gz, seven a day. Messages go through the
log facade and still print their old text on stderr.
A main-thread panic or a fatal error writes
crash-reports/crash-<date>_<time>-client.txt (error, stack, Horizon and
Minecraft versions, OS, CPU, memory, GPU adapter, render settings, resource
packs, world, last 50 log lines). Development builds crash on purpose with
HORIZON_DEBUG_CRASH.
The launcher shows "Horizon crashed" when the game it started ends badly,
with Open report, Copy report, Open logs folder and Report on Discord;
Settings gets a Logs row. horizon-launcher logs and horizon-ctl logs
(--lines N, --crash) print the log's end or the newest report, and both MCP
servers have a logs tool.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The launcher prepares a version in-process when it ships the preparer sources
the launcher was built with, with the version's own horizon-prepare when they
differ, and with the Python script only for versions made before it. Release
folders ship horizon-prepare and its sources; resources are reused between
versions with the same preparer. The game's messages, PLAY.txt, the docs and
release builds name horizon-prepare, and tools/prepare_native_client.py is a
wrapper of it for the development tools.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The README keeps the parity table, and its known differences move to a
Known issues section. The website drops the What's next section and its
nav links, and no longer fetches or requires a Roadmap section. The
launcher drops its What's next page, `next` subcommand and `roadmap`
MCP tool.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
links.json gains a website key; the launcher shows a quiet Website link under
Join Discord and lists it in the links CLI command and MCP tool.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- links.json on main gives the Discord and sponsor links (built-in fallback offline,
empty hides the button); 'links' command and MCP tool.
- Install new versions automatically is on unless explicitly turned off (new settings
key, so 0.1.1's written default does not count as a choice).
- Settings: Horizon / Classic menu style, the horizon.txt menuStyle line the game reads;
'menu-style' command and MCP tool.
- launcher workflow: install latest into a temp home, check imports (Windows, Linux client)
and that the client starts, on all three platforms; also runs on launcher-* branches.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
One theme for the launcher and the game: crates/horizon-theme holds the
palette, type scale, spacing, radii, control sizes, motion and the bundled
fonts; launcher/src/theme.rs and the game's ui_theme both read it. ui_theme
ports the launcher's components (button with hover layer and press state,
sidebar list with the sliding selection, segmented control, switch, rows)
and draws Geist and Instrument Serif through the HUD atlas.
The title is laid out like the launcher (sidebar, page header, rows) over a
live backdrop: Horizon generates an ice-spikes landscape for a fixed seed,
orbits a camera over it with falling snow, then blurs and cold-grades the
frame (post.rs). The launcher's opening (wordmark, then the interface) plays
once per session and a click or key skips it. Menu style Horizon / Classic
lives in horizon.txt, never options.txt; Classic keeps vanilla's drawing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ludovic Marie
RobertTGreat
rdbtCVS
Cosmic