# Workshop System

## Current State

The current Workshop/content work is split across two module lines:

- `Panel/modules/steam_workshop` - deprecated compatibility layer
- `Panel/modules/addonsmanager` - the active Server Content Manager path

Important files:

- `Panel/modules/addonsmanager/module.php`
- `Panel/modules/addonsmanager/user_addons.php`
- `Panel/modules/addonsmanager/addons_manager.php`
- `Panel/modules/addonsmanager/workshop_content.php`
- `Panel/modules/addonsmanager/workshop_action.php`
- `Panel/modules/addonsmanager/scripts/workshop/generic_steam_workshop_linux.sh`
- `Panel/modules/addonsmanager/scripts/workshop/generic_steam_workshop_windows_cygwin.sh`
- `Panel/modules/steam_workshop/module.php`
- `Panel/modules/steam_workshop/agent_update_workshop.php`

## Phase 1 Implemented Behavior

The active user workflow is now `addonsmanager` -> `workshop_content`.

Users can enter either:

- a numeric Workshop item ID
- a full Steam Workshop URL containing `id=<number>`

The Panel extracts and stores only numeric Workshop IDs. Invalid text is rejected before any manifest or shell command is built.

The Panel writes a manifest under the server home:

- `{SERVER_HOME}/gsp_server_content/workshop_manifest.json`

The Panel syncs the bundled install script to:

- `{SERVER_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_linux.sh`
- `{SERVER_HOME}/gsp_server_content/scripts/workshop/generic_steam_workshop_windows_cygwin.sh`

The agent executes the synced script with the manifest path. Customers do not need to place scripts manually on the agent.

The manifest includes:

- `home_id`
- server/game path
- `workshop_app_id`
- Workshop item IDs
- per-item target paths
- install strategy
- key-copy settings
- content template metadata

DayZ/Arma-style installs default to `dayz_mod_folder` or `arma_mod_folder` based on the game key/name/config file. Those strategies install to `@<workshop_id>` by default and copy `.bikey` files into the server `keys` folder when found. Missing key files are logged but do not fail the install.

## Database State

`server_content_workshop` tracks:

- `content_id`
- `home_id`
- `workshop_app_id`
- `workshop_item_id`
- `title`
- `install_path`
- `install_strategy`
- `enabled`
- `load_order`
- `install_state`
- `last_installed_at`
- `last_updated_at`
- `last_error`

Current install states used by Phase 1:

- `queued`
- `installing`
- `installed`
- `failed`
- `removed`

## What Exists Today

The current direction already supports:

- content records in the Panel database
- Workshop item IDs
- installation metadata
- install history tables
- game compatibility fields
- launch parameter additions
- post-install behavior fields

## Main Limitations

- Workshop metadata is still incomplete.
- load order is tracked but not yet a full drag-and-drop or startup-param UX concept.
- enable/disable is stored but does not yet regenerate startup parameters.
- update/remove are synchronous and should become background jobs.
- caching and cleanup policy need product-level design, not just ad hoc scripts.
- `-mod=` / `-serverMod=` generation still needs a safe structured implementation.

## Recommended Mental Model

Use `addonsmanager` as the main future home for:

- mods
- add-ons
- Workshop items
- scripts
- config packs
- server content manifests
- install history

Treat `steam_workshop` as a legacy bridge for migration only.