Command-line tool to help create and manage Farlands mods.

• .NET 9 SDK
• Windows x64 (the provided build.bat publishes for win-x64)

• Build a self-contained binary:

  .\build.bat

• Run the CLI (after build):

  .\Terbin\bin\Release\net9.0\win-x64\publish\terbin.exe <command> [args]

Tip: Add the publish folder to PATH to invoke terbin from anywhere.

Set up a new mod end-to-end with one command:

terbin setup -y

This will:

1. Ask (or auto-accept with -y) for Farlands install path, store it in .terbin.
2. Create manifest.json (auto-confirmed with -y).
3. Generate the project <Name>.csproj and run dotnet restore.
4. Copy Farlands Managed DLLs into local libs (excludes System.* and mscorlib.*).
5. Generate plugin.cs from the manifest.

Alternatively, run step-by-step:

terbin config fpath <path>   # or: terbin config fpath (interactive prompt)
terbin manifest [-y]         # creates manifest.json via dialog
terbin gen                   # generates <Name>.csproj and restores packages
terbin inf                   # copies game DLLs into ./libs (excludes System.* and mscorlib.*)
terbin bman                  # generates plugin.cs from manifest
terbin build                 # runs bman then dotnet build on <Name>.csproj

• User configuration (global):

  • Path: %USERPROFILE%\.terbin
  • Purpose: stores local settings used by commands.
  • Fields (typical):
    • FarlandsPath: full path to your Farlands installation.
    • Instances: map of instance name → path.
    • index: cached mods index (list of references) used by mods list.

• Project files (per project, current working directory):

  • manifest.json: created by terbin manifest; contains Name, GUID, Versions, url, Dependencies.
  • <Name>.csproj: created by terbin gen based on the manifest Name.
  • plugin.cs: generated by terbin bman (also by terbin build).
  • libs/: created by terbin inf; copies DLLs from Farlands_Data/Managed (excludes System., mscorlib., netstandard.*).

• PowerShell profile (optional, only when installing completion):

  • Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
  • terbin completion --install appends a small section to enable tab-completion.

• info

  • Shows Terbin and current project info (manifest path, existence, etc.).

• help [command]

  • Shows general usage and the list of available commands, or details for a specific command.

• manifest [-y | --yes]

  • Checks for manifest.json; if not present, offers to create it.
  • With -y/--yes, it auto-confirms and skips yes/no prompts.

• gen

  • Generates <Name>.csproj targeting net35 with basic dependencies.
  • Runs dotnet restore for the generated project.

• config

  • Configures local Terbin options (saved in .terbin).
  • Subcommand: fpath <path> sets the Farlands install directory.
    • If <path> is omitted, Terbin will prompt: “Enter Farlands path:”.

• inf

  • Copies DLLs from <FarlandsPath>\Farlands_Data\Managed into ./libs.
  • Skips assemblies starting with System. and mscorlib..

• bman

  • Generates plugin.cs from the current manifest.json.
  • Plugin template uses BepInEx and logs a startup message.

• build

  • Generates plugin.cs (same as bman) and then runs dotnet build on <Name>.csproj.
  • Errors if the project file does not exist (run gen first).

• setup [-y | --yes]

  • Runs the main steps in order: config fpath → manifest → gen → inf → bman.
  • Propagates -y/--yes so confirmations are auto-accepted.
  • Reloads .terbin and manifest.json after each relevant step so later steps see fresh values.

• instances

  • Manage game instances (cloned game folders configured in .terbin).
  • Subcommands:
    • create <name> <path>: clones the Farlands installation into <path>, optionally installs BepInEx; adds the instance to config.
    • list: shows configured instances (name → path).
    • run <name> [exe]: launches the instance. Defaults to Farlands.exe under the instance path if [exe] not provided.
    • open <name> [subpath]: opens the instance folder in Explorer; selects a file if [subpath] points to one.
    • delete <name> [-y]: removes the instance entry from config (does not delete files). Prompts unless -y/--yes is specified.
    • add <name> <mod>: downloads and installs a mod (from the mods index manifest) into the instance’s BepInEx folder.

• mods

  • Manage the mods index (list of available mods and their manifest URLs).
  • Subcommands:
    • list: shows the cached index if available; if no cache, downloads it. Hints to run mods update to refresh.
    • update: forces a re-download of the index and saves it into .terbin.

• version

  • Manage the version string in manifest.json (uses the last entry in Versions).
  • Subcommands:
    • show: prints the current version.
    • list: prints all versions.
    • upgrade [major|minor|patch|<newVersion>]: bumps or sets a new version and appends it to Versions.
    • downgrade: removes the last version entry.

All commands/dialogs use a common logger:

• Sections with headers for readability.
• Colored levels: info, success, warning, error.
• Consistent prompts: Ask (input) and Confirm (yes/no).

Terbin stores local settings in a JSON file named .terbin in the user profile (%USERPROFILE%).

Example structure:

{
  "FarlandsPath": "C:\\Games\\Farlands",
  "Instances": {
    "MyInstance": "D:\\Farlands\\Instances\\MyInstance"
  },
  "index": {
    "references": [
      { "name": "ExampleMod", "guid": "com.example.mod", "url": "https://.../manifest.json" }
    ]
  }
}

The file is written automatically when you set FarlandsPath.

The mod manifest (manifest.json) contains:

{
  "Name": "...",
  "GUID": "...",
  "Versions": ["1.0.0"],
  "url": "https://github.com/user/repo",
  "Dependencies": ["fm.fcm"]
}

It is created via the interactive dialog (terbin manifest) and used by gen, bman, and build.

• Unknown command

  • Run terbin info to see available commands.

• manifest.json missing

  • Run terbin manifest -y to create it quickly.

• Farlands path not set

  • Run terbin config fpath <path> or terbin config fpath and follow the prompt.

• Project already exists

  • gen will warn if <Name>.csproj already exists; delete it or adjust the manifest name.

• Build fails

  • Ensure you ran gen and that <Name>.csproj exists.
  • Check errors printed by dotnet build for missing dependencies or code issues.