Releases

Choose Rolling for current development or Current Fan Favorite Build for a preserved development snapshot. The publishing branch is rebuild/main; neither choice guarantees compatibility with every setup.

Release channels

Release notes on the rolling channel show the source commit, build version, build timestamp, and the CI run that produced it. The rolling channel is a full (non-pre-release) development release and intentionally owns GitHub's Latest marker. Release candidates use an -rc* suffix and stay as pre-releases; a bare v* tag produces a full curated release without displacing rolling.

What the rolling release contains

Successful publishing runs on rebuild/main replace the rolling assets. Archives are organized by purpose: the normal installable package, RA development package, exact source, VARIANTS, and optional language/debug packs. Read the release notes for omitted optional flavours. Current standard kits require a usable Neutrino bundle. Every ZIP name ends with the build version, so the revision number is always the last part of the name. Korium uses the same asset shape with Korium in front of the version (RIPTOPL-Korium-<version>.zip, RIPTOPL-VARIANTS-Korium-<version>.zip); preserved snapshots can retain older names.

Finding the exact build

The release notes header shows the build version and source commit before download. The ZIP filename omits the source hash and SDK suffix because it contains several SDK builds. For example, v1.2.0-Beta-4224 is the short form of v1.2.0-Beta-4224-308bc6a-OFFICIALROLLING. The full running identifier is visible on both the Settings index and About.

The Beta number is calculated from the full Git commit count plus two. The source hash can precede the release checkout when newer commits touch only excluded paths; the final suffix identifies the SDK. Korium and RA add their edition labels. Current Fan Favorite Build is a preserved older snapshot with its own revision.

The standard Beta 4224 kit's PS2DEVPINNED comparison loader incorrectly reports Beta-3 because its build job used a one-commit checkout. PR #1044 fixes history fetching for subsequent builds. A new package is required to replace that executable; renaming an old ZIP does not change it.

Download a PR or Actions test build

A test artifact is a ZIP attached to a successful GitHub Actions run, rather than an asset on the Releases page. Open the supplied run link, check that its source commit matches the fix you are testing, then choose the requested artifact under Artifacts. GitHub normally requires you to sign in to download it. Expired artifacts need a new build.

For an official rolling toolchain test, choose OPL-OFFICIALROLLING. OPL-OFFICIALPINNED is the separate pinned official toolchain; OPL-PS2DEVROLLING uses the moving ps2dev toolchain. The word rolling in the artifact name identifies the toolchain, not proof that the commit has been published in the rolling release.

Extract the ZIP and read BUILD-MANIFEST.txt for the source commit, flavour and build configuration. Launch the supplied ELF requested in the test instructions. These artifacts contain loader builds, their manifest, LICENSE-LIBSMB2.txt, the licence of the libsmb2 code every loader embeds, and CREDITS, which says so; keep a complete installed package for companion cores, modules and artwork. Report the exact commit and flavour alongside the console, device, filesystem, core and changed settings.

Japanese/Unicode game-name fallback is available in compatible builds using a user-supplied font_CJK.ttf beside settings_riptopl.cfg. See Unicode font setup for the PR #917 build artifact and activation steps.

Four toolchain flavours, ordered for testing

Every release attempts four labelled flavours of the same RiptOPL source, in this recommended order:

• APP_RIPTOPL-PS2DEVPINNED/ — digest-pinned ps2dev; recommended primary control.
• APP_RIPTOPL-OFFICIALPINNED/ — digest-pinned official ps2homebrew toolchain.
• APP_RIPTOPL-PS2DEVROLLING/ — moving ps2dev:latest canary.
• APP_RIPTOPL-OFFICIALROLLING/ — moving official ps2homebrew:main canary.

The PS2DEVROLLING canary must compile — if it fails, the publish fails loudly rather than shipping without its required build. The other three flavours are best-effort: if one fails, the release still updates without that folder and the notes identify the omission.

Bundled Neutrino core

The installable package ships the latest published official ps2max32/neutrino build as an already-extracted neutrino/ folder at the package root (holding neutrino.elf plus the config/ and modules/ folders) — no zip-in-zip, so you just drag-and-drop it. RiptOPL adds only one file — config/bsd-udpfsbd.toml — so UDPFS works out of the box without a manual copy step. Everything else is the official Neutrino build, unchanged.

How to pull the rolling release

Versioned archive filenames change when the build revision changes. Pull by the rolling tag rather than a fixed filename so you always get what is currently published:

# Everything in the current rolling release
gh release download rolling --repo NathanNeurotic/Open-PS2-Loader --clobber

Or download directly from the release page:
github.com/NathanNeurotic/Open-PS2-Loader/releases/tag/rolling

How the pipeline works

One workflow file — .github/workflows/rolling-release.yml — is the single place release packaging lives. The pushed ref picks the publish target:

• Push to rebuild/main or master → updates the rolling full development release, explicitly clears its pre-release flag, and keeps it marked as GitHub Latest.
• Push of a v* tag → cuts a curated per-version release for that tag, using the same normalized package format and best-effort rules. An -rc* tag stays a pre-release; a bare v* tag makes a full release. Neither displaces rolling from the Latest marker.
• Manual workflow_dispatch → re-runs as rolling.

A concurrency group cancels in-flight rolling runs when a newer push arrives, so the release always reflects the freshest commit. A publishing-branch push and a simultaneous v* tag release run in separate concurrency groups and do not cancel each other.

After downloading

APPS/
  APP_RIPTOPL/
    RIPTOPL.ELF        ← ready-to-install app (-OFFICIALROLLING when available)
  APP_RIPTOPL-PS2DEVPINNED/
    RIPTOPL.ELF        ← #1 recommended pinned control
  APP_RIPTOPL-OFFICIALPINNED/
    RIPTOPL.ELF        ← #2 official pinned control
  APP_RIPTOPL-PS2DEVROLLING/
    RIPTOPL.ELF        ← #3 moving ps2dev canary
  APP_RIPTOPL-OFFICIALROLLING/
    RIPTOPL.ELF        ← #4 moving official canary
ART/                   ← the app's artwork (RIPTOPL.ELF_*.png)
APP_RIPTOPL.psu        ← APPS/APP_RIPTOPL/ as one memory-card save
POPS/                  ← POPSTARTER.ELF and every loose BDMA variant (including .ilink)
EMBER/                 ← official Ember core; add your own BIOS and games
neutrino/              ← official Neutrino core (already extracted, drag-and-drop)
PS2-Servers.url        ← link to the UDPFS / SMBv1 / UDPBD all-in-one PC launcher
                         (plus four more companion-tool shortcuts)

For a complete first-run walkthrough (folder layout, enabling devices, launching your first game), see Getting Started.

Archive availability

MEGA uploads require successful publishing and configured credentials. Superseded or failed runs may have no archive. Installable packages, source and metadata are archived when upload succeeds; VARIANTS and DEBUG are excluded. Neutrino download/extraction is best-effort, so check release notes before relying on a bundled core.

The rolling archive

Because the rolling release is rebuilt on every push, a build you were happy with is replaced quickly. Successful runs are preserved on MEGA under run-specific folders, so an older build can still be retrieved:

RiptOPL/Rolling/<version>/run_<number>/

Each folder holds the installable packages plus source and build metadata. VARIANTS and DEBUG bundles are excluded, and — as above — an upload only exists when that run published successfully and the credentials were configured, so superseded or failed runs may have no archive at all.

Browse the MEGA rolling archive →

Building from source

You do not need to build RiptOPL to use it — the releases above are ready to run. This is for people who want to change the code or produce a build with non-default options.

Build inside one of the toolchain images from the CI matrix. Both pinned and rolling SDK images work, and the latest SDK is not required. For a reproducible baseline use the PS2DEVPINNED image digest from that matrix. From the repository root, with Docker available:

docker run --rm -v "${PWD}:/src" -w /src   ps2dev/ps2dev@sha256:8fba50ecc2229acd7f8da63d34302f12939b7d4fa6848dda1e6a0ce083321a11   make -j4

Repository scripts live in tools/ and are run from the repository root. Existing Makefile targets keep their names and output locations.

See the Makefile for the option flags, including DUALSENSE=1 (a DualSense loader) and EXTRA_FEATURES=1 (which turns on in-game screenshots and right-to-left language support).

Companion Ecosystem & Tools