Skip to content

Repository files navigation

Goose Server v2

Updated Goose Server. New features:

  • Supports both Aspereta and Illutia through configuration
  • Uses SQLite for storage so no longer requires a separate database server
  • C# scripting of items/spells/NPCs
  • Easier editing data. Edit via Google Sheets rather than editing SQL directly

Setting up server

1. Install .NET

Download and install the .NET 10 SDK (not .NET 8).

Verify with dotnet --version (e.g. 10.0.x).

2. Copy the data sheet

If using Illutia click here. If using Aspereta click here.

This will prompt you to copy the sheet. Go to your new sheet, share it to make it visible to everyone.

3. Edit the settings to configure data id

Open the file GooseSettings.json.

By default the settings are configured for Illutia. If you want the server to run for Aspereta you will need to remove/comment out the section under // Illutia Config. And uncomment the section under // Aspereta Config.

Set up the server to use your data sheet by copying the id out of the URL of your sheet and copying it into the ID in the config DataLinkId.

4. Run the server

dotnet "run" --project "Goose/Goose.csproj"

On first start (when the .db file is missing), the server creates the schema and imports game data from the configured Google Sheet.

Data directory (--datadir)

By default all mutable state — the SQLite database, Logs/, crashlog.txt — is written next to the server binaries. To relocate it, pass --datadir <path> (or set the GOOSE_DATADIR environment variable; the argument wins):

dotnet "run" --project "Goose/Goose.csproj" -- --datadir /srv/goose/data

When a data directory is set:

  • GooseSettings.json is read from the data directory if present; otherwise the copy shipped next to the binaries is used and copied there on first run, so there is one editable copy that survives updates.
  • The database (<DatabaseName>.db plus its -wal/-shm siblings), Logs/, and crashlog.txt live in the data directory.
  • The shipped game data (Data/ and sql/) stays read-only next to the binaries.

This is also how the server runs in containers: binaries in a read-only image, data directory on a persistent volume.

5. Connect client

Server runs on port 2006 by default. So configure your client for that port and play. :)

6. Updating server data

Run the server with updatesql on the end to import the latest data from the Google Sheet. This runs the import and exits — it does not start the game — so start the server normally afterwards:

dotnet "run" --project "Goose/Goose.csproj" updatesql

Otherwise if your character is a GM you can run the /updatesql command, which updates a running server in place.

The Google Sheets data editor is generated by the tools in tools/ — see tools/README.md for what it consumes and how to regenerate it.

7. Connecting to the database

The SQLite database file is created next to the running binary by default (e.g. Goose/bin/Debug/IllutiaGoose.db or Goose/bin/Release/IllutiaGoose.db, depending on configuration), or in the configured data directory when --datadir is used (see step 4). The name comes from DatabaseName in GooseSettings.json.

Via command line you can run sqlite3 Goose/bin/Debug/IllutiaGoose.db and run SQL commands.

Otherwise you can download a tool such as SQLite Browser to open the IllutiaGoose.db file and edit it.

WAL mode

SQLite is opened in WAL (Write-Ahead Logging) mode. Alongside the main database file you may also see:

  • IllutiaGoose.db-wal
  • IllutiaGoose.db-shm

These are normal while the server is running (and may remain after a stop until SQLite checkpoints).

Backups: Prefer stopping the server first, or copy the main .db together with any existing -wal / -shm siblings. Copying only the .db while WAL files still have uncheckpointed data can produce an incomplete backup.

Database access model

All SQLite work goes through a single-threaded Database service (one connection, one dedicated thread). Game code uses synchronous Execute for startup loads / rare need-for-rowid paths, and Enqueue for background saves. Do not open additional connections to the live DB from other tools while the server is running if you want to avoid lock contention.

8. Making your character a GM

You can run this SQL with your player name, or update the access_status column for your player and set it to 9.

UPDATE players SET access_status=9 WHERE player_name='namegoeshere';

Stop the server before editing the database: the running server keeps the authoritative copy of players in memory and writes it back on the save cadence, so a live edit gets overwritten and wouldn't take effect until the next restart anyway (players reload from the DB at startup).

About

No description, website, or topics provided.

Resources

Stars

1 star

Watchers

1 watching

Forks

Releases

Packages

Used by

Contributors

Languages