Confluence-OpenSim

Confluence is an independent OpenSimulator fork — in the same vein as WhiteCore-Dev, Tranquillity, or Homeworldz: a distinct project with its own web/admin platform, native economy and search services, and moderation stack, not a thin patch set on top of something else. It began from OpenSim Continuum's codebase and has continued to absorb selected grid, identity, scripting, environment, simulator, and reliability enhancements cherry-picked and hand-ported from the wider OpenSim ecosystem (Tranquillity, including Legion's work on it, Gunthar's fork and Homeworldz, and earlier Mobius and WhiteCore-Dev). Official OpenSimulator remains the authoritative upstream baseline.

Where Confluence and Continuum parted ways: they share the same starting lineage, but the two are now independent, parallel efforts. Continuum's own README describes its web/admin portal work as "intentionally deferred until the simulator, Robust services, and addons are complete." Confluence took the opposite bet — it built that portal, and a full native economy and search layer to go with it, directly into the fork rather than leaving it to a separate PHP site or a later phase.

Project status

Item	Status
GitHub home	Ramius1701/Confluence-OpenSim
Upstream baseline	origin/master (opensim/opensim), merged in as of the latest commit
Active integration branch	merge-experiment (also the repo's default branch)
Windows build	Successful — full solution build, 0 warnings / 0 errors, including Jolt and Phlox
Script engines	YEngine (default); Phlox (LSL, OSSL and SLua with saved running state) optional, off by default
Physics engines	ubODE (default), BulletSim, and Jolt (Jolt Physics v5.6), selectable per region
Automated tests	Jolt: 2,099 passed, 0 failed. Phlox, including the core and YEngine behaviour it exercises: 5,561 tests (2026-10-16: 5,558 passed, 2 skipped, 1 load-sensitive timing test that passes on its own)
Web/Admin UI	Live-verified against a running Robust instance (real HTTP sessions, admin actions, database writes)
In-world/viewer testing	Live-verified with a real viewer (Firestorm): login, region crossing, weather, a full currency/land-purchase transaction, and spatial WebRTC voice with two real, separately-located participants

On "tested" vs. "compiled": these are two different claims. The Web/Admin UI and basic in-world presence (login, region crossing, weather, a real purchase transaction) are live-verified against a real viewer and a running grid, not just a clean build. Live verification of individual LSL/OSSL functions, Experience Tools behavior, and specific physics/environment tuning is narrower than that — general region stability doesn't mean every scripting function has been exercised in-world. PROJECT_LOG.md notes verification status for individual pieces where it matters.

Project goals

• Be as close to Second Life as possible while staying OpenSimulator. Residents will not move from Second Life to an OpenSimulator grid that lacks the features and functions they expect. Second Life is closed source, so its behaviour is worked out from the best evidence: Linden Lab's open-source SLua for its script VM, the viewers (Firestorm and others) for what a viewer sends and expects, the Second Life wiki, and how the other OpenSimulator projects have interpreted it. What makes OpenSimulator itself (open grids, Hypergrid, OSSL, grid-owner control) is kept.
• Go beyond what the other OpenSimulator distributions offer a grid owner: match their core work (Tranquillity's Phlox and Jolt work among it) and build in what they leave to separate add-ons (the Web/Admin UI, Store, Marketplace, economy, Search and Abuse Reports).
• Give grid owners a complete starting point: a build like official OpenSimulator, enhanced with what it lacks, so they can run their own grid with everything they need. Casperia is the live grid where it runs in real time, with real residents, regions and content.
• Keep official OpenSimulator (opensim/opensim master) as the baseline and keep merging its continuing work.
• Draw on the other active OpenSimulator-based projects (Tranquillity, including Legion's work on it, Homeworldz, and Gunthar's fork) for what master lacks. Projects no longer in active development are not followed for new work; what was already ported from them stays, credited below. Where a ported feature has to diverge from master, that is a deliberate choice, recorded in PROJECT_LOG.md, and upstream merges are reconciled with it rather than dropped.
• Preserve useful enhancements that are difficult to maintain as loose patches.
• Keep optional functionality in addon-modules whenever practical.
• Avoid grid-specific hardcoding.
• Support standalone and Robust/grid deployments.
• Retain Windows build and deployment support.
• Provide configuration examples without silently enabling services.
• When porting from another fork, verify with a real build rather than trusting a commit message or a docs page.

Including features from other projects

Confluence's goal is a full, immersive grid platform with everything a grid owner might reasonably need built in, not scattered across addon-modules and third-party services grid owners have to discover and assemble themselves. If another repository — a fork, an addon, a standalone tool — has a fix, enhancement, or feature that looks like it belongs here, open an issue or discussion on this repository first for assessment rather than assuming it fits. Every feature already ported in from Gunthar/Tranquillity/Mobius/WhiteCore-Dev/Halcyon/Homeworldz/ opensim-lickx (see "Attribution and support" below) went through that same real review, not a rubber stamp — confirmed present in this codebase, verified against a real build, and checked against how actual Second Life/Tranquillity/Mobius/WhiteCore-Dev do it before being ported, not invented from a description.

Every feature that can reasonably be made optional is: grid owners choose what to enable through their own .ini configuration rather than taking on the runtime cost or behavior of something they don't want running. Giving grid owners that choice is a design requirement here, not an afterthought bolted on later.

Features

Confluence includes a native Web/Admin UI, in-world economy and search services, a full moderation and access-control stack, expanded LSL/OSSL scripting with a choice of two script engines (YEngine and Phlox), three physics engines (ubODE, BulletSim and Jolt), and a range of environment/reliability improvements over stock OpenSimulator. See FEATURES.md for the full, categorized list. A native, viewer-integrated DirectDelivery Marketplace is also included — see MARKETPLACE.md for setup and usage.

Roadmap

For what's planned, what's deliberately out of scope, and current known limitations, see ROADMAP.md.

Building

Requirements

• .NET 10 SDK (Confluence targets .NET 10; .NET 8 support ends 2026-11-10)
• Visual Studio 2022 or later is optional on Windows

Windows

runprebuild.bat
dotnet build OpenSim.sln --configuration Release

Linux or macOS

./runprebuild.sh
dotnet build OpenSim.sln --configuration Release

runprebuild also adds the Jolt physics engine and the Phlox script engine to the solution (their project files are maintained by hand, not generated), so the build above builds them too. The first build downloads their NuGet packages (JoltPhysicsSharp and its native library; ANTLR4, StringTemplate4 and protobuf-net for Phlox). Both stay off until a region's ini selects them (physics = Jolt; [InWorldz.Phlox] Enabled = true).

Running the tests

The test suites are separate projects under Tests/, built against the bin/ output of the steps above (build the solution first). The first run downloads xUnit from NuGet.

dotnet test Tests/OpenSim.Region.PhysicsModules.Jolt.Tests -c Release
dotnet test Tests/InWorldz.Phlox.Tests -c Release

The Jolt suite (2,099 tests, about 3 minutes) drives real Jolt worlds. The Phlox suite (5,561 tests, about 11 minutes) covers Phlox's compiler and VM, and runs scenes through upstream OpenSim's test helpers (OpenSim/Tests/Common, built by Tests/OpenSim.Tests.Common), so it also exercises the core: damage, parcels, crossings, permissions, Experiences, and YEngine's side of shared behaviour. Tests/SluaProofRunner (dotnet run -c Release there) checks Phlox's SLua against Second Life's published behaviour.

See BUILDING.md for the official base requirements.

Configuration

Confluence does not install live configuration automatically.

Review:

• bin/OpenSim.ini.example
• bin/Robust.ini.example
• bin/Robust.HG.ini.example
• bin/config-include/GridCommon.ini.example
• bin/config-include/storage/SQLiteRobust.ini
• module-specific .ini.example files under addon-modules

Optional modules should remain disabled until dependencies, database schema, service endpoints, credentials, and runtime behavior have been validated.

Repository model

Reference	Purpose
merge-experiment	Active integration branch and repo default — everything described above lives here
master	Stale; predates this round of work
origin/master	Official OpenSimulator development branch, merged into merge-experiment as of the latest commit

Feature work happens in short-lived isolated git worktrees/branches (build-verified before merging), merged into merge-experiment, then cleaned up. This keeps history readable and avoids leaving half-finished work on the integration branch.

Deployment

New here? Start with SETUP.md - the tested, step-by-step guide for SQLite, MySQL/MariaDB and PostgreSQL, standalone or grid. The sections below describe how the two modes work and how a running grid is operated and updated.

Confluence supports both of OpenSim's standard deployment shapes — grid mode (a separate Robust process, one or more regions) and standalone mode (a single self-contained OpenSim.exe, no Robust at all) — and the full web UI (registration, dashboard, admin panel, Store, currency) works in either, not just grid mode.

In both modes, if this is a genuinely fresh install (a brand-new database with zero accounts), the very first time the web UI starts up it automatically creates one real admin account — username Grid Admin — with a random temporary password printed once to the console/log. Log in with it and you'll be required to set a real password before anything else is reachable. There's no separate setup wizard or database step to create your first admin account by hand.

Grid mode

Confluence's regions run one-process-per-region rather than the stock single shared OpenSim.exe, so any individual region can be started, stopped, or restarted (to pick up a new build) without ever having to take down the rest of the grid — a real, live-tested requirement, not a theoretical one. Setting this up is a normal deploy step, not a separate tool or wizard:

1. Build Confluence, then copy Robust.exe, OpenSim.exe, every built DLL, and a real, configured OpenSim.ini (DB credentials, grid name, etc. — the same one-time setup any OpenSim install needs) into a single folder, e.g. C:\opensim. This folder is both where Robust itself runs from and the source every region's own binaries get synced from.
2. In Robust.HG.ini's [StoreService] section, set RegionOrderGridRoot to that same folder, and RegionOrderTemplateIniPath to the OpenSim.ini you just put there — it only ever needs to be read as a template (cloned and have a handful of region-specific keys rewritten), never actually run itself, so there's no chicken-and-egg step where a region has to already exist before this works.
3. Run only Robust.exe. No region process needs to be started by hand.
4. Log into the web UI (with the auto-created Grid Admin account, or any account you promote to admin level) and use Create Region (/admin/store/create-region) to provision your first region — any type, any size, for any resident, with no purchase involved. This clones the template from step 2 into its own Simulators\<name>\bin\ copy and starts it automatically. Every region after that can come the same way, or be sold through the Store to residents directly.

Casperia Prime is the reference deployment built this way — a real, live, public grid with real residents and currency, used throughout this project's development as the actual proving ground for every grid-mode feature.

Updating a grid-mode deployment

Updating to a newer Confluence build never requires taking the whole grid offline — this is the same rolling-restart property described above, just applied to an already-running deployment instead of a fresh one. There's no separate updater tool; it's a normal deploy step using the WebUI you already have:

1. Build the new version and copy the output into the same folder as RegionOrderGridRoot from step 2 above, overwriting the Robust.exe/OpenSim.exe/DLLs already there. This is the only place you ever copy files by hand — every region's own private Simulators\<name>\bin\ copy stays exactly as it is for now.
2. Work out the blast radius before restarting anything: a change confined to OpenSim/Server/Handlers/** (the WebUI itself and other Robust-side services) only needs Robust restarted — no region needs to come down for it. A change touching a region-loaded assembly (OpenSim/Region/**, OpenSim/Addons/**, or any shared library a region loads in-process) needs every affected region's own copy refreshed too.
3. For region-loaded changes, use the Simulators page instead of touching any region's files directly — a single region's own Restart button, or Restart All for the whole grid. Both already do the real work for you: a graceful in-world countdown warning, a real stop, a fresh sync of that region's own bin\ from the folder you updated in step 1, then relaunch. Restart All staggers this across every region so the grid is never dark all at once — the same rolling-restart approach Second Life's own grid operators use for simulator updates.
4. Confirm each region actually came back on the new build (the Simulators page's live Running/Stopped status is enough for most changes) before considering the update finished.

Standalone mode

A single OpenSim.exe, no Robust process, everything in one deployment — the simplest way to run Confluence, and the full web UI comes along for free:

1. Build Confluence, copy the build output to a deployment folder, and copy OpenSim.ini.example to OpenSim.ini.
2. Copy config-include/StandaloneCommon.ini.example to config-include/StandaloneCommon.ini. The database defaults to SQLite with zero further configuration — uncomment the MySQL/MSSQL/ PGSQL block instead if you'd rather use one of those. [WebInterface] Enabled = true is already set at the bottom of this file by default, so the web UI starts automatically; nothing else to turn on.
3. Run OpenSim.exe. On a genuinely first run (no Regions/Regions.ini yet) it drops into OpenSim's own interactive console wizard asking a few questions about your first region — this is stock OpenSim behavior, not something Confluence changes. Answer them (or press Enter to accept every default).
4. Once it's running, the web UI is live on this same process's own HTTP port (http_listener_port, 9000 by default) — log in with the auto-created Grid Admin account and you're on the same dashboard/ admin panel grid mode gets. The Store's region-provisioning mechanics (Create Region, Simulators\ per-region isolation) are grid-mode-specific — a standalone instance only ever runs the one region-per-process the console wizard set up, or however many you add the stock OpenSim way (additional .ini files under Regions\). feature described in this README, not just a demo.

Documentation

File	Purpose
FEATURES.md	What Confluence has, organized by area
ROADMAP.md	What's planned, deferred, or a known limitation
TESTING.md	What still needs testing in a real region with a viewer, and how to report results
WEBUI_PARITY_CHECKLIST.md	Working audit tracking the Web UI's page-by-page structural parity against WhiteCore-Dev
INWORLD_COMMANDS.md	Every in-world chat command available to avatars/estate managers
SETUP.md	Step-by-step setup for every database (SQLite, MySQL/MariaDB, PostgreSQL) in standalone and grid mode - each step tested from a fresh clone
BUILDING.md	Official base build requirements
MARKETPLACE.md	Setting up and using the DirectDelivery Marketplace
HARDENING.md	Control-plane security hardening
ExperienceSetup.md	Setting up Experience Tools
doc/JoltPhysics.md	Running the Jolt physics engine (operator notes)
doc/PhloxSetup.md	Turning on the Phlox script engine; doc/PhloxSLua.md for SLua; doc/PhloxKnownDefects.md for its known differences from SL
OpenSim/Region/PhysicsModules/Jolt/CONFLUENCE.md	Where Jolt comes from and what Confluence changed
OpenSim/Region/ScriptEngine/Phlox.ScriptEngine/CONFLUENCE.md	Where Phlox comes from, the core hooks it needs, and its tests
PROJECT_LOG.md	Full narrative development history — every change, why, and how it was verified

Attribution and support

Confluence retains the OpenSimulator license and source history, and started from OpenSim Continuum's consolidation work. Portable improvements have been cherry-picked and, where architecturally incompatible with a straight cherry-pick, hand-ported from:

• Gunthar's OpenSim fork
• Tranquillity, including Legion's work on it: the Jolt physics module (his lane/jolt) and the Phlox port with the core hooks it needs
• Homeworldz
• Mobius
• WhiteCore-Dev — also the primary reference for the native Web/Admin UI's page structure and admin-feature set
• opensim-lickx — origin of Confluence's MoneyServer and OpenSimSearch modules; its original GitHub repository has since been deleted, so the only remaining copy is archived locally
• Halcyon/InWorldz — audited as a preservation effort for design ideas and code from a project that has fallen by the wayside; also where Phlox comes from, and the reference for loading InWorldz-era OARs with their projectors, materials and physics shapes

Engines and references:

• Phlox keeps its lineage: InWorldz (the original engine) → Halcyon (phlox core, Apache 2.0; engine adapter, BSD) → Legion Grid → Tranquillity → Confluence
• Jolt Physics by Jorrit Rouwe (MIT) and the JoltPhysicsSharp binding by Amer Koleci (MIT), with Legion's OpenSim module (MPL-2.0)
• Linden Lab's SLua (MIT) — the reference for Second Life's script VM; not part of the build
• The viewers, Firestorm and others — the reference for what a viewer sends and expects
• OpenSim-Grid-Interface (ManfredAabye's oswebinterface fork, a separate PHP project — not Confluence's own code, not ported from, and not distributed with this repository) — referenced for the native Web UI's page structure where WhiteCore-Dev had no equivalent page. It plays the same role as this repo's addon-modules: an optional alternative to the built-in Web UI for grid owners who'd rather not run it, maintained independently and under separate, ongoing development — not shipped, bundled, or included with Confluence

Historical source provenance remains available in Git history.

Report Confluence-specific problems in this repository. Problems reproducible on an unmodified official OpenSimulator build should be reported to the official OpenSimulator project.

License

Confluence is distributed under the same BSD-style license as OpenSimulator. See LICENSE.txt. Imported components keep their own licence headers: Phlox's core is Apache 2.0 (HalcyonGrid/phlox), its engine and the Jolt vehicle code carry InWorldz Halcyon's BSD-3 notice, and Legion's own Jolt and Phlox files and some Tranquillity files are MPL-2.0. The licence texts are in ThirdPartyLicenses/; LICENSE.txt lists which applies where.