Development & Game Definitions

← All guides · DEVELOPMENT

---

This page is for contributors and advanced users. You do not need developer tools to install or manage normal servers.

Synix is a C#/.NET 10 Windows Forms application with built-in game definitions. Source availability does not remove the project's license restrictions; read them before redistributing code or builds.

Source layout

Within SynixApp:

Folder	Responsibility
UI	Feature-oriented windows for Dashboard, ServerSetup, Settings, Diagnostics, ServerManagement, Transfers, Discord, GameDefinitions, Help, Onboarding, and Updates
ServerHandler	Game/lifecycle controllers, Minecraft, Satisfactory, configuration handling, and related server integrations
SynixEngine	Application coordination, lifecycle, maintenance, networking, backups, transfers, security, diagnostics, and other feature groups
Design	Shared controls, layout, menus, themes, and window helpers
Database/GameDefinitions	Per-game JSON definitions and configuration templates
Database/ModSystems	Built-in add-on-system definitions
Localization	Offline interface catalogs, language selection and translation tooling; see the Language reference
Tests	Tests organized by feature

Use the repository's project/solution files and .NET 10 SDK when building from source. The SDK is a development requirement; official application downloads already include their runtime.

Adding or correcting a game profile

Start with the Game Definition Library instructions.

A definition supplies supported executable and download information, Steam AppID/login requirements, arguments, ports, configuration behavior, runtime prerequisites, and controller capabilities.

• Use official dedicated-server documentation and real generated configuration files.
• Keep paths relative to the server root where required.
• Include every supported complete configuration template with the correct installed location.
• Keep machine-facing identifiers, arguments, and configuration values exact.
• Increment the appropriate definition/configuration/template revisions for changes.
• Validate the library, build, and run the relevant tests.
• Test install, start, stop, and monitoring with the actual game before recording verification.

The Definition Builder is a development-build tool. Dropping an arbitrary JSON file into a user's installed Synix folder does not add a new game to the compiled release.

Definitions select approved built-in behavior; they cannot dynamically load arbitrary handlers, assemblies, or downloaded scripts.

Add-on definitions

Read the Mod-system library. Document whether a workflow installs local files, manages provider IDs, or only detects content.

Do not describe external catalog links as automatic package/dependency installation.

Configuration mappings and recovery

Shared settings are synchronized using explicit game/file/section/key bindings. When adding a field, cover both Synix-to-config generation and config-to-Synix Save/restore behavior where appropriate. Do not match arbitrary identical key names across unrelated files.

Preserve unknown settings, encoding, comments, and external-edit detection. Protect credentials in Synix storage and test failure rollback without exposing secrets in fixtures/logs.

Read Server workflow safety. Requested backup/update failures must block later launch steps. Restore completion must retain recoverable state until saved settings agree with restored files.

Mod support is separate from import rules

The game-mod-support.modsupport.json catalog records documentation evidence, methods, review dates, and sources for every built-in game. Documented must not mean “automatic installer” or “live-tested.” NeedsVerification must not be presented as unsupported.

The .modsystem.json profiles define concrete file-import or provider-ID behavior. Built-in profiles are compiled resources; validated external mod-system overrides and server-scoped import locations are separate from adding new compiled game definitions.

Import review must explain compatibility, exact destinations, activation, and recovery. Never execute a downloaded package to discover its metadata, guess a provider identity, or claim a generic file copy performs every game's registration.

Rust's framework installation and individual plugin import are separate workflows; the released Mod & Plugin Manager does manage supported local plugins.

Translations

Follow the localization instructions.

Update the neutral English resources and supported translated catalogs together. Preserve format placeholders. Translate user-facing labels and explanations, not game commands, config keys, tokens, file paths, or output-recognition markers.

Help and technical text-log/support-report contents intentionally remain English.

Testing and release documentation

The GitHub Windows test workflow restores and builds the test project in Release, then runs it. From the repository root, the equivalent commands are:

dotnet restore "SynixApp/Tests/Synix.Tests.csproj"
dotnet build "SynixApp/Tests/Synix.Tests.csproj" --configuration Release --no-restore
dotnet test "SynixApp/Tests/Synix.Tests.csproj" --configuration Release --no-build --logger "trx;LogFileName=synix-tests.trx" --results-directory "TestResults"

Use a supported Windows/.NET 10 development environment. Some live-server integration checks are opt-in and need their documented setup; a skipped live check is not a passed live check.

Choose tests for the affected feature and run the release-readiness checks appropriate to the change. Do not substitute a successful build or MSI install for a real game lifecycle test.

Before publishing a release:

• Verify the published version, installer identity, runtime packaging, and official download links.
• Verify package hashes and installation/upgrade behavior.
• Exercise affected server workflows and failure/recovery paths.
• Update the wiki pages that explain changed user-visible behavior.
• Never include real tokens, credentials, or private test logs in fixtures, issues, or documentation.

CI and publish troubleshooting

A failed GitHub check can be a test, build, security alert, or infrastructure failure. Read the failing job and its exact log/TRX artifact. Push and pull-request runs may exercise different commits/merge state. Do not disable a test or dismiss a security alert merely to turn a check green.

A successful application build followed by a failed GenerateBundle publish is not necessarily a compilation failure. If access to the output executable is denied, close the application running from that exact output path, then check folder permissions and security/sync-software messages. Do not delete game data or force-kill unrelated server processes.

Release assets and WinGet

Publish the intended stable self-contained Windows x64 build, then package and test the complete installer payload. Confirm the actual release version, product identity, upgrade behavior, and official asset URLs.

For WinGet, PackageVersion, InstallerUrl, and InstallerSha256 must describe the same final published asset. Hash the bytes served by that exact URL after upload, not an earlier local build. Replacing an asset can invalidate an already-created manifest.

Do not bypass an installer hash mismatch. Correct the version/URL/hash and retest. Code signing, hash matching, manifest validation, package installation, and game compatibility are different checks.

A valid manifest can still wait on fork synchronization, repository review, or the WinGet publication service. A general publish-pipeline health badge is not by itself a Synix application-test failure; inspect the package PR's specific checks and maintainer messages.

Report corrections through GitHub Issues, including official references and redacted reproduction steps.