Skip to content

Support multiple instances / multiple open projects #41

Description

@ApocDev

Goal

Allow running multiple PyOps desktop windows at once, each with a different project open. The realistic use case is having two or more projects side by side, not multiple windows of the same project.

For now the desktop app is forced to a single instance for stability, because the server binds a fixed port and a couple of backend resources assume a single owner. This issue tracks lifting that.

Why this is feasible

The earlier assumption that the backend is effectively a singleton was mostly wrong:

  • app-config.json is read once at startup; each server process holds its own in-memory active project. One window switching projects writes the file but does not reach into another running instance, so they do not switch each other.
  • Different projects are different projects/<id>.db files, so there is no DB contention. Two instances on the same project is mild wonkiness the user owns; SQLite WAL handles concurrent connections.

Work

  1. Dynamic port per instance. Replace the fixed 34115. Bind :0 to get an OS-assigned free port, pass it to the node sidecar (PORT), and point the window at it.
  2. Cross-instance lock around the data sync / dump pipeline. The sync mutates shared files (the game's mod-list.json, the dump output in script-output, the generated icon atlas in the data dir), so two syncs running at once would clobber each other regardless of which project they target. Guard with a lockfile in the data dir so only one sync runs at a time across all instances.
  3. UDP bridge as an opt-in toggle, first-owner-wins. Only one instance binds the bridge socket and owns the in-game link; others run without it (and surface that the bridge is in use elsewhere, or simply off). This doubles as a switch for users who do not want mod integration at all.
  4. Per-instance webview data dir. Tauri keys the webview data dir off the app identifier, so instances would otherwise share one cache dir; give each instance its own to avoid WebKit cache-lock contention.
  5. --project <id> CLI arg to choose the startup project (ignoring app-config.active), so 'open project X in a new window' works.

Interim

Single instance is enforced (focus the existing window on a second launch) until this lands.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: bridgeLocal service / API bridge between Factorio and the apparea: webWeb UI (React/TanStack/vite-plus)enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions