folders.md

CWR folders and user files

CWR normally keeps the installed game, personal settings, editable content, cache, and temporary files in separate places. This lets Steam or GOG update or move the game without moving profiles and saves, and it avoids writing into a protected installation directory.

Most players should use this default layout. --oldpaths is available for an original-game-style layout where nearly all writable files stay below one game directory.

For the contents of a mod folder and the ways to enable it, see the custom-mod guide. For a dedicated-server installation, see the dedicated-server guide.

Contents

• Default locations
• The game directory
• Settings, profiles, and saves
• Mods and editable content
• Where missions belong
• Cache, temporary files, and logs
• Legacy game-local layout with --oldpaths
• Custom locations and separate instances
• Backup and migration
• Finding the paths actually in use
• Troubleshooting
• Path reference
• CLI reference

Default locations

Purpose	Windows	Linux
Installed game data	Steam or GOG installation directory	Steam, GOG, or copied installation directory
Settings, profiles, and saves	%APPDATA%\CWR	${XDG_CONFIG_HOME:-$HOME/.config}/CWR
User content	Cold War Assault inside the user's actual Documents folder	${XDG_DATA_HOME:-$HOME/.local/share}/Cold War Assault
Cache	%LOCALAPPDATA%\CWR	${XDG_CACHE_HOME:-$HOME/.cache}/CWR
Temporary files	%TEMP%\cwr	/tmp/cwr

“Actual Documents folder” means the location Windows reports for the current user. It may be redirected to OneDrive, a network location, or another disk; open Documents in File Explorer rather than assuming it is always below C:\Users.

CWR creates the managed directories when it first starts. Some individual configuration and save files appear only after the corresponding setting or game mode has been used.

To confirm the four core roots selected for a particular launch, see Finding the paths actually in use.

The game directory

The game directory contains the executable and installed, read-mostly game data. A complete installation normally has this shape:

<game directory>/
├── PoseidonGame or PoseidonGame.exe
├── PoseidonServer or PoseidonServer.exe
├── AddOns/
├── BIN/
├── DTA/
├── Worlds/
├── Campaigns/
├── Missions/
├── MPMissions/
├── Templates/
└── SPTemplates/

When no path is specified, CWR uses the process working directory as the game directory. Steam and GOG normally arrange this for their launchers. -C DIR or --work-dir DIR selects it explicitly when starting the executable from somewhere else.

The launcher's open installation folder or browse local files action is the easiest way to find this directory without relying on a platform-specific default path.

-C selects the directory containing DTA, Worlds, and the other installed data. It does not select a profile or configuration directory.

Settings, profiles, and saves

The settings directory holds preferences shared by CWR profiles for the current operating-system account, plus one directory per player profile:

<settings>/
├── ColdWarAssault.cfg
├── audio.cfg
├── contextControls.cfg
├── difficulty.cfg
├── display.cfg
├── game.cfg
├── gamepad.cfg
├── graphics.cfg
├── mouse.cfg
└── Users/
    └── Player name/
        ├── UserInfo.cfg
        ├── Saved/
        ├── Config/
        ├── Sound/
        ├── face.jpg
        └── face.paa

The files at the settings root contain display, graphics, audio, input, difficulty, language, and other shared preferences. They apply to the operating system account running CWR rather than being duplicated for every player name. Not every file is necessarily present.

Users/<player>/UserInfo.cfg contains the player profile. Saved contains single-player and campaign progress. Config is used by mission scripts that save custom status, while Sound and face.jpg or face.paa are optional multiplayer custom assets.

prefs.cfg is a small exception: it only remembers the selected player and contains no profile or save data. On Linux it uses a separate platform configuration location unless POSEIDON_USER_DIR is set. Current Windows 3.03 builds need POSEIDON_USER_DIR for this small pointer to persist reliably; the actual Windows profile and saves are not affected.

A dedicated server keeps its local state in the reserved <settings>/Users/__SERVER__ profile. Dynamic #ban entries are written there as ban.txt and ipban.txt. It can also read game-root ban.txt and ipban.txt as global lists shared by every instance using that game directory. server.cfg remains wherever the operator places it and loads only when supplied with --config.

Mods and editable content

The user-content directory is intended for large or user-created files:

<user content>/
├── Mods/
├── Workshop/
├── missions/
└── MPMissions/

• Mods contains local custom mods.
• Workshop contains mods downloaded by CWR from the online catalog.
• lowercase missions contains single-player editor projects.
• MPMissions contains multiplayer editor projects.

On Linux, names are case-sensitive. missions, Missions, and MPMissions have different purposes and should retain the casing shown here.

Putting a mod in Mods does not enable it. Use the in-game MODS screen or --mod; --mods-dir only selects a different parent directory. The custom-mod guide covers folder structure, load order, the Workshop directory, and client/server mod matching.

An immediate res, Res, or RES subdirectory in the game directory is a compatibility exception: CWR mounts it automatically as the original Resistance data layer. Keep normal custom mods in a Mods directory and enable them explicitly instead of treating res as a general mod folder.

Where missions belong

A mission directory or PBO is named Name.World, where World is the terrain suffix. For example, 1-8_D_FlagFight.ABEL.pbo is installed without removing the .ABEL part.

Kind of content	Location	Accepted form	How it is used
Installed single-player mission	<game>/Missions	Name.World/mission.sqm or Name.World.pbo	Appears in the Single Missions browser.
Single-player editor project, normal layout	<user content>/missions	Name.World/mission.sqm	Opened and saved by the mission editor.
Installed or public multiplayer mission	<game>/MPMissions	Name.World/mission.sqm or Name.World.pbo	Available to hosted games and dedicated servers.
Multiplayer editor project, normal layout	<user content>/MPMissions	Name.World/mission.sqm	Opened and saved by the multiplayer editor.
Multiplayer mission supplied by an enabled mod	<mod>/MPMissions	Name.World.pbo	Added while that mod is enabled; it must be packed.
Mission received while joining a server	<cache>/MPMissionsCache	Engine-managed .pbo	Reused for later joins; not an installation or editing directory.
Campaign	<game>/Campaigns or <enabled mod>/Campaigns	Keep the campaign's supplied layout	Appears while its base content or mod is available.

The user-content missions and MPMissions directories are editor workspaces, not general PBO installation directories. Put a distributed single-player PBO in the game's Missions, and put a distributed multiplayer PBO in the game's MPMissions.

The dedicated-server resolver can also read a packed PBO from the normal user-content MPMissions, but using the game's MPMissions for distributed server missions gives consistent discovery in the client, hosted game, and server tools.

A base-game mission may remain a loose Name.World directory. A multiplayer mission inside a mod must be packed as Name.World.pbo; loose mod mission directories are not discovered. The mod must also be enabled. For compatibility, lowercase <mod>/mpmissions is accepted, but new mods should use the canonical MPMissions spelling.

Current 3.03 builds do not add new Single Missions entries by scanning an enabled mod's Missions directory. Install a standalone single-player mission in the game directory's Missions; any addon resources it requires can remain in an enabled mod.

For a dedicated server, the simplest placement is the game directory's MPMissions. Mod missions stay packed below the mod and require the same mod at server startup. Mission rotation and exact template names are covered in the dedicated-server guide.

Cache, temporary files, and logs

The cache contains data CWR can rebuild or download again. Important examples are:

<cache>/
├── MPMissionsCache/
│   └── downloaded-mission.pbo
└── cwr_subdiv_<world>_L<n>.cache

MPMissionsCache holds missions received from multiplayer servers. The cwr_subdiv files accelerate terrain loading. It is safe to remove cache files while the game and server are stopped, but the next load or join may take longer.

The managed temporary directory holds current network transfers and custom-player-file staging. A profile can also contain disposable staging below Users/<player>/tmp/players. Both can be cleared while every CWR process is stopped. Do not confuse either with Users/<player>/Saved/Tmp, which contains persistent campaign state and belongs in backups.

The client does not create a general log file automatically. Client and server messages are visible when launched from a terminal; --log-file FILE writes a complete persistent log at the requested path and is the recommended choice. A dedicated server also creates a timestamped server_YYYYMMDD_HHMMSS_PORT.log file in the settings directory, but current 3.03 builds do not reliably populate it with the normal category output. With --oldpaths, that timestamped file is in the selected game-local root. See the server guide for normal production logging.

Linux crash reports are written as crash_PID.txt in the settings directory. Windows crash minidumps are written as crash-PID.dmp beside the executable.

Legacy game-local layout with --oldpaths

--oldpaths restores the original style where profiles, settings, mods, cache, and installed missions are kept with the game. The legacy spelling -oldpaths is also accepted.

The old-path root is the working directory after -C has been applied. It is not automatically the directory containing the executable. The clearest way to use it is to start from the game directory. These examples use the writable $HOME/Games/CWR on Linux and C:\Games\CWR on Windows.

On Linux:

cd "$HOME/Games/CWR"
./PoseidonGame --oldpaths

In PowerShell on Windows:

Set-Location C:\Games\CWR
.\PoseidonGame.exe --oldpaths

When launching from another directory, select the root explicitly:

"$HOME/Games/CWR/PoseidonGame" -C "$HOME/Games/CWR" --oldpaths

& 'C:\Games\CWR\PoseidonGame.exe' -C 'C:\Games\CWR' --oldpaths

The resulting layout is:

<old-path root>/
├── audio.cfg, display.cfg, game.cfg, graphics.cfg, ...
├── Users/
│   └── Player name/
│       ├── UserInfo.cfg
│       ├── Saved/
│       ├── missions/
│       └── MPMissions/
├── Mods/
├── Workshop/
├── Missions/
├── MPMissions/
├── MPMissionsCache/
└── tmp/

There is one deliberate mission-layout distinction:

• root Missions and MPMissions contain installed/shared missions;
• the editor saves personal projects to Users/<player>/missions and Users/<player>/MPMissions.

CWR also creates a root lowercase missions directory during path setup, but the editor does not use it in old-path mode. This profile-local editor behavior matches the original layout.

The settings root and cache root are both the old-path root, so terrain cache, downloaded MPMissionsCache, the timestamped server-created log file, and configuration files appear beside installed data. Temporary files go below <old-path root>/tmp. An explicit --log-file still uses its supplied path.

The POSEIDON_* managed-path overrides do not replace these roots while --oldpaths is active. Explicit --mods-dir and --workshop-dir still select the directories used by the MODS screen. On Linux, the separate prefs.cfg pointer also remains in the platform configuration location unless POSEIDON_USER_DIR is set. On Windows, set POSEIDON_USER_DIR to the old-path root if remembering the selected player is required. The actual profile and saves remain below the old-path root either way.

The MODS screen scans <old-path root>/Mods, but a bare command-line --mod @MyMod does not automatically add that Mods component. When starting in the old-path root, use this form for a mod stored there:

./PoseidonGame --oldpaths --mods-dir Mods --mod '@MyMod'

Use --oldpaths only in a directory the current account can write. The normal layout is more suitable for installations below Windows Program Files, shared game installations, and separately managed Steam or GOG files.

Custom locations and separate instances

The following environment variables override normal-mode paths. Absolute paths are clearest for shortcuts, services, and scripts.

Variable	Effect
POSEIDON_USER_DIR	Replaces the settings, profiles, and saves root. If no explicit user-content root is set, content defaults to <POSEIDON_USER_DIR>/content. It also relocates prefs.cfg.
POSEIDON_USER_CONTENT_DIR	Replaces the parent of Mods, Workshop, missions, and MPMissions.
POSEIDON_MODS_DIR	Replaces only the managed local Mods root.
POSEIDON_WORKSHOP_DIR	Replaces only the managed Workshop root.
POSEIDON_CACHE_DIR	Replaces the cache root.
POSEIDON_TEMP_DIR	Replaces the temporary root.
XDG_CONFIG_HOME	Changes the Linux platform default for settings.
XDG_DATA_HOME	Changes the Linux platform default for user content.
XDG_CACHE_HOME	Changes the Linux platform default for cache.

For example, separate dedicated-server instances can share one read-only game directory while each process receives its own user, cache, and temporary roots. This separates profiles, dynamic bans, and transient transfers. Game-root ban.txt and ipban.txt remain intentionally shared, and each instance should receive its own --log-file path. The dedicated-server guide contains a multi-instance example.

--mods-dir and --workshop-dir are per-launch overrides for the two mod roots. They do not move settings, saves, or editor missions. A mod is enabled only by --mod or the MODS screen.

Relative --mods-dir, --workshop-dir, and --log-file values are resolved from the directory where the process starts, before -C changes the working directory. A relative --mod name uses --mods-dir when supplied; otherwise CWR searches the startup directory, the selected -C game directory, and the managed Mods directory. Use absolute paths when a shortcut or service may start in an unexpected directory. The --oldpaths root itself is selected after -C.

CWR has no -profiles or --profiles option. Use POSEIDON_USER_DIR when a different settings/profile root is required.

Backup and migration

Close the game and every dedicated-server process before copying live data.

For a complete profile, save, settings, and personal-content backup in the normal layout, copy:

1. the settings directory, which includes profiles and saves; and
2. the user-content directory, which includes local mods and editor projects.

Cache and temporary directories can be omitted. Workshop downloads may be downloadable again, but include Workshop if an exact offline copy matters. The separate Linux prefs.cfg can also be copied if preserving the last selected player matters; it contains no gameplay data.

When moving between normal and old-path layouts:

• copy Users and the root configuration files between the normal settings directory and the old-path root;
• move editor projects between normal <user content>/missions or MPMissions and old-path Users/<player>/missions or MPMissions;
• move local Mods and downloaded Workshop content between the user-content root and the old-path root; and
• do not migrate the managed cache root, its MPMissionsCache, or the managed temporary root (<old-path root>/tmp).

Keep the complete Users/<player>/Saved directory, including Saved/Tmp; that similarly named directory contains persistent campaign state.

Installed Missions, MPMissions, Campaigns, and base game data remain part of the game installation in both layouts.

Finding the paths actually in use

Start CWR once with a log file. From the game directory:

./PoseidonGame --log-file "$HOME/cwr-startup.log"

.\PoseidonGame.exe --log-file "$env:USERPROFILE\cwr-startup.log"

Near the beginning, the log prints the resolved roots:

user_dir:          ...
user_content_dir:  ...
cache_dir:         ...
temp_dir:          ...

This is the quickest way to settle redirected Documents folders, service accounts, XDG overrides, -C, and --oldpaths. Use an explicit --log-file for the dedicated server as well.

Run PoseidonGame --help-full or PoseidonServer --help-full to check the switches supported by the installed build.

Troubleshooting

• A mission does not appear: distinguish an editor project from an installed mission, preserve the Name.World suffix, and check the casing in the mission table above. Mod multiplayer missions must be packed PBOs.
• An editor project disappeared after enabling --oldpaths: look below the active Users/<player>/missions or Users/<player>/MPMissions, not the root editor folders.
• A mod does not appear or load: confirm which Mods root is active, then use the custom-mod guide to check the immediate folder structure and enable it.
• Files appear under another account: CWR uses the operating-system account that starts the process. A service, container, sudo, or another Windows user therefore has different normal roots.
• The Windows content folder is not where expected: check the actual Documents location, including OneDrive or organization-managed redirection.
• A Linux directory seems empty: respect missions, Missions, and MPMissions casing, and remember that .config, .local, and .cache are hidden directories.
• CWR cannot save with --oldpaths: grant the current user write access to the selected root or return to the normal layout.
• The last selected player is not remembered: the small prefs.cfg pointer is separate from the actual profile. In normal mode, POSEIDON_USER_DIR places it with the rest of the user data. With --oldpaths, set that variable to the same old-path root; it relocates only the pointer because the actual profile already uses the root.
• A downloaded multiplayer mission was copied from the cache: install an authorized copy in MPMissions; MPMissionsCache is engine-managed and may be replaced or removed.

Path reference

Path	Purpose
<game>/AddOns, BIN, DTA, Worlds	Installed base game data.
<game>/Missions	Installed single-player missions.
<game>/MPMissions	Installed multiplayer and dedicated-server missions.
<game>/Campaigns	Installed campaigns.
<settings>/*.cfg	Shared game, display, graphics, audio, input, and difficulty settings.
<settings>/Users/<player>/UserInfo.cfg	Player profile.
<settings>/Users/<player>/Saved	Single-player and campaign progress.
<settings>/Users/<player>/Config	Mission-script persistent status.
<settings>/Users/<player>/Sound	Custom multiplayer radio sounds.
<settings>/Users/<player>/face.jpg or face.paa	Custom multiplayer face.
${XDG_CONFIG_HOME:-$HOME/.config}/ARMA:CWA-RE-CE/prefs.cfg	Linux selected-player pointer when POSEIDON_USER_DIR is not set. It contains no profile or save data.
<POSEIDON_USER_DIR>/prefs.cfg	Selected-player pointer with an explicit user root; also the reliable Windows 3.03 location.
<settings>/Users/__SERVER__/ban.txt and ipban.txt	Dedicated server's dynamic player-ID and IPv4 bans.
<game>/ban.txt and ipban.txt	Optional dedicated-server global bans shared by instances using the same game directory.
<user content>/Mods	Local mods scanned by the MODS screen.
<user content>/Workshop	Catalog-downloaded mods.
<user content>/missions	Normal-layout single-player editor projects.
<user content>/MPMissions	Normal-layout multiplayer editor projects.
<cache>/MPMissionsCache	Multiplayer missions received from servers.
<cache>/cwr_subdiv_*.cache	Regenerable terrain cache.
<temp>/Tmp<port>	Network and custom-file staging.
<settings>/Users/<player>/tmp/players	Disposable staging for other players' downloaded custom assets.
<settings>/Users/<player>/Saved/Tmp	Persistent campaign state; include it in backups.
<old-path root>/Users/<player>/missions	Old-path single-player editor projects.
<old-path root>/Users/<player>/MPMissions	Old-path multiplayer editor projects.
<settings>/server_*_PORT.log	Timestamped server-created file; use --log-file for complete 3.03 logging.
<settings>/crash_PID.txt	Linux crash report.
<executable directory>/crash-PID.dmp	Windows crash minidump.

CLI reference

Switch	Effect on paths
-C DIR, --work-dir DIR	Selects the game-data directory and changes the process working directory before game paths are initialized.
--oldpaths, -oldpaths	Uses the post--C working directory for the legacy game-local layout.
--mods-dir DIR	Selects the local Mods scan root and base for relative --mod names; enables nothing by itself.
--workshop-dir DIR	Selects the Workshop scan and download root; enables nothing by itself.
--mod LIST, -mod LIST	Enables an ordered, semicolon-separated list of mod directories.
--log-file FILE	Adds a persistent client or server log at the supplied path.
--config FILE	Server only: loads a server configuration file. A relative path is read from the post--C game working directory.
--pid FILE	Server only: writes the process ID to the supplied file. A relative path uses the post--C working directory.

--mods-dir, --workshop-dir, and --log-file resolve relative paths from the startup directory before -C. Relative --mod names follow the search order described above. Server --config and --pid use the resulting working directory. Use --help-full for non-path-related options.