Nebula: a multiplayer mod for Dyson Sphere Program that syncs factories, not just players

Nebula syncs the factory, not just the avatar

Nebula is an open source multiplayer mod for Dyson Sphere Program, and the feature list is what distinguishes it from a lobby mod. Under peace mode, the checked items include player movement on planet and in space, player visual and sound effects, player appearances, game time, universe settings, client planet loading from server, planet vegetation mining, planet resources, build previews, entity creation and destruction, entity upgrades, Dyson spheres, researches, factory statistics, container inventories, building and belt interaction, dropped items, interstellar stations, drone events, foundation terrain deformation, server state persistence, power network requests from Dyson spheres, warning alarms, broadcast notifications, the logistics control panel and planet memos.

That list is the real feature description. A mod that only moves players around in a shared world is a different product, and the difference matters because Dyson Sphere Program is a factory game where the factory is the save file.

The mod also has a combat side. The most recent game version supported with the Dark Fog combat mode is 0.10.35.x, and the documentation says most of the battle aspects are synchronised, with only a few features still in work in progress. The combat checklist covers ground and space enemy pools, unit activation, base and hive threat and experience levels, loot and loot filter tables, mecha shooting, bombing, death and respawn, personal shields, repair drones, building kill and reconstruct events, relay arrive and dock events, base pit removal, hive creation and dispatch, and patches that make Dark Fog units and turrets search for the nearest living mecha so that both sides attack the same target.

The people who want this are players who build together: small groups who want one shared universe, or server operators who host sessions for others.

Four peace mode features are still not synchronised

The documentation is honest about the gaps, and they are listed as unchecked items in the same table as the working features. Four things do not synchronise yet.

The goal system is marked as currently not available in client. The custom dashboard is listed with the caveat that clients lose their custom stats when they leave the star system, which is a subtle failure rather than a hard one, since the data appears to work until a player moves. The wireless charge tower entry notes that power will not sync when the mecha is charging. Vegetation transplantation is listed as not done.

The custom dashboard case deserves a closer look, because it is the kind of gap that produces bug reports. A player who builds a dashboard of custom statistics, then travels out of the star system, comes back to a dashboard that has lost those figures. Nothing crashes and nothing warns, the numbers are simply gone, and the player has to rebuild the display.

The repair drone entry is marked as imperfect rather than incomplete, which is a different kind of caveat. An imperfect sync in a combat scenario means the repair behaviour can differ slightly between what one client sees and what another, which is tolerable in peace mode and potentially confusing in a fight.

Read the checklist before promising a group full parity. These four entries are the boundary between what Nebula currently does and what a player might reasonably expect it to do.

Getting the mod: Thunderstore for stable, nightly builds for the edge

There is no installer in the repository, and that is by design. The stable version of the mod is downloaded from Thunderstore, and the project marks that route as recommended.

For the bleeding edge there is a separate path. The project publishes a nightly build badge pointing at a build artifact from the build-winx64 workflow, and the documentation is explicit about what you get: it is the bleeding edge build, it may contain bugs and unfinished features, and it requires extra installation steps beyond the normal path, which are described in the manual installation section of the wiki.

The distinction between the two channels matters for a group. If everyone is playing a co-op session, a nightly build on one machine and a Thunderstore build on another is a support question waiting to happen. The stable channel exists so that a group can agree on one artifact, and the FAQ points out that the mod often becomes incompatible after game updates, which is the moment when the group has to move together anyway.

There is a related tool for the wider ecosystem. The FAQ recommends checking the NebulaCompatibilityAssist mod page on Thunderstore to learn whether other mods are compatible with multiplayer, since some mods are not compatible with multiplayer at all. That page is the place to look before a session, rather than discovering the conflict in the first five minutes of a shared build.

Version numbers follow a 0.9 line: v0.9.22 on 2026-04-21, v0.9.23 on 2026-09-29, and v0.9.24 on 2026-10-14. A 0.x version number carries no compatibility promise, so pin the version your group uses.

Hosting is TCP on port 8469, and the wiki holds the connection flow

The networking model is direct TCP, and the default port is 8469. The hosting and joining guide in the project wiki covers the connection flow, and that page is the reference for both sides rather than anything in the repository itself.

Direct TCP has a practical consequence. One participant's machine is the server, and the other machines connect to it, so the port has to be reachable from every player, and it has to be reachable on the network the players are actually on. That is straightforward on a home LAN and less straightforward behind a corporate or campus firewall, where an outbound connection to a non-standard port may simply be dropped. A dedicated server sidesteps the question of whose machine is the server, but the port requirement stays the same.

The mod can run the server in a non-GPU environment, and the wiki page on setting up a headless server covers the setup and the command-line arguments. That matters for operators, because a dedicated server does not need a graphics card, only the game data and the mod. It also means a server can live on a cheap machine, provided the game itself can run there.

Two configuration details are documented. The chat window is opened and closed with Alt + Backtick, and the shortcut is configurable in Settings under Multiplayer and Chat, where there is also an option to stop the chat window from opening automatically when a message arrives. Inside the chat, typing /help lists all commands, and the project wiki has a page for the full command set.

What the repository looks like: a patcher with an API, a network layer and a Unity host

The repository layout explains the architecture better than any summary would. The top level has Nebula.sln, shared build files, a nuget.config, a version.json, a thunderstore.toml for packaging, a package-lock.json and package.json, and a .gitmodules file, which points to a dependency vendored outside the tree.

The C# projects are named for their roles. NebulaAPI is the public interface, NebulaModel holds the data model, NebulaNetwork is the transport and synchronisation layer, NebulaPatcher applies changes to the running game, NebulaWorld deals with the world simulation, NebulaUnity is the layer that sits inside the game's own Unity runtime, NebulaTests holds the test project, and there are Libs, Shims and dep directories for third-party code, compatibility shims and vendored dependencies.

The NebulaPatcher project is the one that explains the whole approach. The mod does not replace the game, it patches it, which is why a game update can break it and why the documentation says major refactors will happen as the project grows or as the game changes.

The JavaScript side is small and exists for packaging rather than for the game. The package.json lists a handful of dependencies, including @actions/core, @terascope/fetch-github-release, child_process, fs-extra, json2toml, xml-query, xml-reader and zip-a-folder. Those are the tools of a release pipeline: fetching a GitHub release, editing TOML, reading XML, and zipping a folder into something uploadable to a mod manager.

GPL-3.0, an active 0.9 line, and a project still in development

The licence field on the repository says GPL-3.0, which is a strong copyleft licence with the obligation that derived works are distributed under the same terms. For a mod that patches and links against a commercial game, that obligation is the thing to read carefully before you fork it, redistribute it or build a derivative package. This is not legal advice, and the LICENSE file in the repository is the text that governs.

The project is current. The last push was on 2026-10-14, the repository is not archived, and v0.9.24 shipped the same day, following v0.9.23 at the end of September. The 0.9 line is where the work is, and the project says so itself, describing the mod as still in development to keep up with game changes and warning that it may still contain bugs.

There is also a public statement about the current status: major refactors will happen while the project grows or the game updates, and the Discord server is the place to see the latest state of development. The About-Nebula wiki page gives the overview of features, and the CHANGELOG.md in the repository tracks what changed.

One funding file sits in the repository root, and the support channel on the Discord is where the FAQ sends people who want mod support, since the mod often becomes incompatible after game updates and a temporary version rollback may be needed. The FAQ is also where the honest limits live, which is why it is the most useful page in the project.

Editorial conclusion

Adopt Nebula if you want to run a shared Dyson Sphere Program session where factories, research and combat are synchronised rather than played in parallel, and if you can keep every participant on the same mod and game version. Do not adopt it as a long-lived server project, because the project states the mod often becomes incompatible after game updates and a temporary version rollback may be needed. Before you host, read the hosting and joining wiki page for the connection flow, confirm the default port 8469 is reachable from your players, and check the peace mode checklist for the four features that are not yet synchronised, including the goal system and the custom dashboard.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. NebulaModTeam/nebula on GitHub
4. README
5. Releases