docs(obsidian): process inbox notes
This commit is contained in:
@@ -1,68 +0,0 @@
|
||||
# Ariadne project goals
|
||||
|
||||
Ariadne analyzes a local Ren'Py game install.
|
||||
It extracts source, builds a source graph, and plans routes through target nodes.
|
||||
|
||||
## Privacy constraint
|
||||
|
||||
Do not write the target game's title in the monorepo.
|
||||
Use `target game` or `Ren'Py game` in committed notes, code, and pull requests.
|
||||
Keep title-specific paths and names in ignored local data only.
|
||||
|
||||
## Goal order
|
||||
|
||||
1. Unlock all Steam achievements.
|
||||
2. Maximize Season 3 dialogue coverage.
|
||||
3. Extend the same coverage work to Seasons 1 and 2.
|
||||
|
||||
## Steam achievements
|
||||
|
||||
Achievement unlocks appear in source as reachable calls.
|
||||
The first planning target is every achievement grant node.
|
||||
|
||||
Ariadne needs to find each grant call and compute route conditions that reach it.
|
||||
This is source-graph coverage over sparse semantic targets.
|
||||
|
||||
## Season 3 dialogue coverage
|
||||
|
||||
Season 3 exposes an in-game percentage for seen dialogue.
|
||||
The stat computes Ren'Py dialogue-block coverage from persistent seen data.
|
||||
|
||||
For this game, dialogue blocks map mainly to unique `Say` statements.
|
||||
Ariadne should target Season 3 `Say` nodes as coverage targets.
|
||||
|
||||
The in-game percentage gives a validation signal for Ariadne's coverage model.
|
||||
Season 3 also rewards high coverage inside the game.
|
||||
|
||||
## Seasons 1 and 2 coverage
|
||||
|
||||
Seasons 1 and 2 lack the same in-game percentage display.
|
||||
Ariadne can still compute source coverage for their dialogue nodes.
|
||||
|
||||
Validation for these seasons will depend on Ariadne's own model.
|
||||
Persistent seen data can still help later.
|
||||
|
||||
## State model phases
|
||||
|
||||
The first phase ignores player state.
|
||||
It asks which routes cover all targets from source alone.
|
||||
|
||||
A later phase reads existing player state.
|
||||
It uses save files or persistent data to remove completed targets.
|
||||
|
||||
That phase produces a personalized plan for remaining achievements and dialogue coverage.
|
||||
|
||||
## Graph model
|
||||
|
||||
The source graph needs typed nodes for labels, jumps, conditions, menus, visual statements, dialogue, and achievement grants.
|
||||
Menus and conditions require branch edges and merge edges.
|
||||
|
||||
Dialogue and visual nodes support route explanation.
|
||||
Achievement and dialogue nodes become coverage targets.
|
||||
|
||||
## Near-term implementation direction
|
||||
|
||||
Keep extraction and decompilation generic.
|
||||
Parse source into typed graph artifacts.
|
||||
Add achievement grant nodes before broad route planning.
|
||||
Add Season 3 dialogue nodes as the next coverage target set.
|
||||
@@ -1,71 +0,0 @@
|
||||
# SteamCMD servers
|
||||
|
||||
Use `modules.services.steamcmd` as the low-level runner for one SteamCMD server.
|
||||
Create a game module under `configs/nixos/modules/services/games/` for each game.
|
||||
|
||||
The game module owns game-specific defaults and command-line flags.
|
||||
The host owns deployment-specific paths, names, secrets, and network placement.
|
||||
|
||||
## Create a game module
|
||||
|
||||
1. Create `configs/nixos/modules/services/games/<game>.nix`.
|
||||
2. Define options under `modules.services.games.<game>`.
|
||||
3. Expose only values the host must choose.
|
||||
4. Map those values to `modules.services.steamcmd`.
|
||||
5. Set the Steam dedicated-server app ID in the game module.
|
||||
6. Set the server executable in the game module.
|
||||
7. Generate game-specific arguments in the game module.
|
||||
8. Open the game's documented UDP ports in the game module.
|
||||
|
||||
Keep `modules.services.steamcmd` focused on shared SteamCMD behavior.
|
||||
Do not put game-specific flags or port rules there.
|
||||
|
||||
## Configure a host
|
||||
|
||||
During validation, enable the game module directly on a host.
|
||||
|
||||
```nix
|
||||
modules.services.games.valheim = {
|
||||
enable = true;
|
||||
steamDir = "/pikachu/data/steamcmd";
|
||||
installDir = "/pikachu/data/servers/valheim/main";
|
||||
stateDir = "/pikachu/media/games/servers/valheim/main";
|
||||
serverName = "main";
|
||||
password = "foobarbaz";
|
||||
};
|
||||
```
|
||||
|
||||
Use host paths for direct host deployment.
|
||||
Use guest paths after the server moves into a guest.
|
||||
|
||||
## Deploy and test
|
||||
|
||||
1. Evaluate the host configuration.
|
||||
|
||||
```sh
|
||||
nix eval .#nixosConfigurations.<host>.config.system.build.toplevel.drvPath --raw
|
||||
```
|
||||
|
||||
2. Deploy the host.
|
||||
|
||||
```sh
|
||||
deploy-to <host>
|
||||
```
|
||||
|
||||
3. Check the game service.
|
||||
|
||||
```sh
|
||||
sudo systemctl status <game>.service
|
||||
sudo journalctl -u <game>.service -n 200 --no-pager
|
||||
```
|
||||
|
||||
4. Check UDP listeners.
|
||||
|
||||
```sh
|
||||
sudo ss -lunp | grep -E '<port>|<port-plus-one>|<game>'
|
||||
```
|
||||
|
||||
5. Connect from the game client.
|
||||
|
||||
The Valheim server is ready after the log contains `Game server connected`.
|
||||
It can spend time generating a new world before it accepts connections.
|
||||
@@ -1,125 +0,0 @@
|
||||
---
|
||||
date-created: 2026-09-10 12:01
|
||||
---
|
||||
|
||||
# How to set up a `steamcmd` server
|
||||
|
||||
This note explains how to add a SteamCMD-managed game server to the NixOS configuration.
|
||||
|
||||
Use these existing files as examples:
|
||||
|
||||
- `configs/nixos/modules/services/steamcmd.nix`
|
||||
- `configs/nixos/modules/services/games/valheim.nix`
|
||||
- `configs/nixos/guests/valheim.nix`
|
||||
- `configs/nixos/hosts/pikachu/default.nix`
|
||||
|
||||
## Understand the layers
|
||||
|
||||
The shared `steamcmd` module installs and runs a dedicated server.
|
||||
It owns the low-level systemd service, update service, user, directories, and firewall ports.
|
||||
|
||||
A game module maps game-specific options onto `modules.services.steamcmd`.
|
||||
It hides Steam app IDs, executable names, launch arguments, and port calculations.
|
||||
|
||||
A guest module maps host-level storage, secrets, and resource limits onto the game module.
|
||||
It keeps host paths outside the guest's interior configuration.
|
||||
|
||||
A host enables the guest and supplies network placement, storage paths, and routing.
|
||||
|
||||
## Create the game module
|
||||
|
||||
1. Create `configs/nixos/modules/services/games/<game>.nix`.
|
||||
2. Add an option namespace at `modules.services.games.<game>`.
|
||||
3. Add an `enable` option with `lib.mkEnableOption`.
|
||||
4. Add options for game-specific settings.
|
||||
5. Add options for `steamDir`, `installDir`, and `stateDir`.
|
||||
6. Use `lib.mkIf config.modules.services.games.<game>.enable` for the module configuration.
|
||||
7. Set `modules.services.steamcmd.enable = true`.
|
||||
8. Pass `steamDir`, `installDir`, and `stateDir` to `modules.services.steamcmd`.
|
||||
9. Set `serviceName` to the game service name.
|
||||
10. Set `appId` to the Steam dedicated-server app ID.
|
||||
11. Set `executable` to the server executable or a generated wrapper script.
|
||||
12. Set `arguments` to the game launch arguments.
|
||||
13. Set `udpPorts` to every UDP port the server needs.
|
||||
14. Put secrets in runtime files instead of option values.
|
||||
15. Read secret files from a wrapper script when the server needs secret values.
|
||||
|
||||
Use `configs/nixos/modules/services/games/valheim.nix` as the main pattern.
|
||||
It wraps the executable because Valheim receives its password as a command-line argument.
|
||||
|
||||
## Create the guest module
|
||||
|
||||
1. Create `configs/nixos/guests/<game>.nix`.
|
||||
2. Add an option namespace at `guests.<game>`.
|
||||
3. Add host-path options for the SteamCMD metadata, install, and state directories.
|
||||
4. Give host-path options a `null` default.
|
||||
5. Add assertions that require each host path when the guest is enabled.
|
||||
6. Define guest-internal paths in a `let` block.
|
||||
7. Enable `guests.<game>.interior.modules.services.games.<game>`.
|
||||
8. Pass the guest-internal paths to the game module.
|
||||
9. Add mounts that bind host paths to the guest-internal paths.
|
||||
10. Set directory mount `owner`, `group`, and `mode` together.
|
||||
11. Mount secret files under `/run/secrets/...` when the game needs secrets.
|
||||
12. Declare matching `sops.secrets` entries for those secret files.
|
||||
13. Set conservative default resource limits under `guests.<game>.limits`.
|
||||
|
||||
Use `configs/nixos/guests/valheim.nix` as the main pattern.
|
||||
It mounts the password secret into the guest and passes only the runtime path inward.
|
||||
|
||||
## Enable the guest on a host
|
||||
|
||||
1. Open the target host file under `configs/nixos/hosts/<host>/default.nix`.
|
||||
2. Set `guests.<game>.enable = true`.
|
||||
3. Set `vlan` and `address` for the guest.
|
||||
4. Set host storage paths for SteamCMD metadata, server files, and state.
|
||||
5. Set game options such as server name and port.
|
||||
6. Enable reverse-proxy routing when the server needs external access.
|
||||
7. Route every game UDP port exposed by the guest.
|
||||
8. Add required secrets to the host's SOPS files.
|
||||
|
||||
Use the Valheim section in `configs/nixos/hosts/pikachu/default.nix` as the host-level pattern.
|
||||
|
||||
## Test the change
|
||||
|
||||
1. Stage new Nix files before evaluation.
|
||||
Flake evaluation ignores untracked files.
|
||||
|
||||
```console
|
||||
$ git add configs/nixos/modules/services/games/<game>.nix configs/nixos/guests/<game>.nix
|
||||
```
|
||||
|
||||
2. Build the target host configuration.
|
||||
|
||||
```console
|
||||
$ nixos-rebuild build --flake .#<host>
|
||||
```
|
||||
|
||||
3. Deploy the host when the build succeeds.
|
||||
|
||||
```console
|
||||
$ sudo nixos-rebuild switch --flake .#<host>
|
||||
```
|
||||
|
||||
4. Enter the guest from the host.
|
||||
|
||||
```console
|
||||
$ sudo machinectl shell <game>
|
||||
```
|
||||
|
||||
5. Check the update service inside the guest.
|
||||
|
||||
```console
|
||||
$ systemctl status steamcmd-<game>-update.service
|
||||
```
|
||||
|
||||
6. Check the game service inside the guest.
|
||||
|
||||
```console
|
||||
$ systemctl status <game>.service
|
||||
```
|
||||
|
||||
7. Inspect the logs when either service fails.
|
||||
|
||||
```console
|
||||
$ journalctl -u steamcmd-<game>-update.service -u <game>.service
|
||||
```
|
||||
Reference in New Issue
Block a user