{
  "Version": 1,
  "DeploymentId": "0.10.0.0.251-master-9f800c33",
  "ServerDescription_Persistent": {
    "PersistentServerId": "1B80182E460F727CEA080C8EEBB1EA0A",
    "InviteCode": "d6221bb7",
    "IsPasswordProtected": false,
    "Password": "",
    "ServerName": "",
    "WorldIslandId": "DB57768A8A7746899683D0EEE91F97BF",
    "MaxPlayerCount": 4,
    "UserSelectedRegion": "EU",
    "P2pProxyAddress": "192.168.31.49",
    "UseDirectConnection": false,
    "DirectConnectionServerAddress": "",
    "DirectConnectionServerPort": 7777,
    "DirectConnectionProxyAddress": "0.0.0.0"
  }
}

{
  "Version": 1,
  "WorldDescription": {
    "islandId": "E24A22C9C8D3448951AFD002162576D5",
    "WorldName": "The Archipelago",
    "CreationTime": 6.3910902400911002e+17,
    "WorldPresetType": "Medium",
    "WorldSettings": {
      "BoolParameters": {
        "{\"TagName\": \"WDS.Parameter.Coop.SharedQuests\"}": true,
        "{\"TagName\": \"WDS.Parameter.EasyExplore\"}": false
      },
      "FloatParameters": {
        "{\"TagName\": \"WDS.Parameter.MobHealthMultiplier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.MobDamageMultiplier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.ShipsHealthMultiplier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.ShipsDamageMultiplier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.BoardingDifficultyMultiplier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.Coop.StatsCorrectionModifier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.Coop.ShipStatsCorrectionModifier\"}": 0
      },
      "TagParameters": {
        "{\"TagName\": \"WDS.Parameter.CombatDifficulty\"}": {
          "TagName": "WDS.Parameter.CombatDifficulty.Normal"
        }
      }
    }
  }
}

{
  "Version": 1,
  "WorldDescription": {
    "islandId": "26C14DC8A78D4AF69E9C77527C934CF3",
    "WorldName": "The Archipelago",
    "CreationTime": 6.3911887576664998e+17,
    "WorldPresetType": "Easy",
    "WorldSettings": {
      "BoolParameters": {
        "{\"TagName\": \"WDS.Parameter.Coop.SharedQuests\"}": true,
        "{\"TagName\": \"WDS.Parameter.EasyExplore\"}": false
      },
      "FloatParameters": {
        "{\"TagName\": \"WDS.Parameter.MobHealthMultiplier\"}": 0.7,
        "{\"TagName\": \"WDS.Parameter.MobDamageMultiplier\"}": 0.6,
        "{\"TagName\": \"WDS.Parameter.ShipsHealthMultiplier\"}": 0.7,
        "{\"TagName\": \"WDS.Parameter.ShipsDamageMultiplier\"}": 0.6,
        "{\"TagName\": \"WDS.Parameter.BoardingDifficultyMultiplier\"}": 0.7,
        "{\"TagName\": \"WDS.Parameter.Coop.StatsCorrectionModifier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.Coop.ShipStatsCorrectionModifier\"}": 0
      },
      "TagParameters": {
        "{\"TagName\": \"WDS.Parameter.CombatDifficulty\"}": {
          "TagName": "WDS.Parameter.CombatDifficulty.Easy"
        }
      }
    }
  }
}

{
  "Version": 1,
  "WorldDescription": {
    "islandId": "26C14DC8A78D4AF69E9C77527C934CF3",
    "WorldName": "The Archipelago",
    "CreationTime": 6.3911887576664998e+17,
    "WorldPresetType": "Hard",
    "WorldSettings": {
      "BoolParameters": {
        "{\"TagName\": \"WDS.Parameter.Coop.SharedQuests\"}": true,
        "{\"TagName\": \"WDS.Parameter.EasyExplore\"}": false
      },
      "FloatParameters": {
        "{\"TagName\": \"WDS.Parameter.MobHealthMultiplier\"}": 1.5,
        "{\"TagName\": \"WDS.Parameter.MobDamageMultiplier\"}": 1.25,
        "{\"TagName\": \"WDS.Parameter.ShipsHealthMultiplier\"}": 1.5,
        "{\"TagName\": \"WDS.Parameter.ShipsDamageMultiplier\"}": 1.25,
        "{\"TagName\": \"WDS.Parameter.BoardingDifficultyMultiplier\"}": 1.5,
        "{\"TagName\": \"WDS.Parameter.Coop.StatsCorrectionModifier\"}": 1,
        "{\"TagName\": \"WDS.Parameter.Coop.ShipStatsCorrectionModifier\"}": 0
      },
      "TagParameters": {
        "{\"TagName\": \"WDS.Parameter.CombatDifficulty\"}": {
          "TagName": "WDS.Parameter.CombatDifficulty.Hard"
        }
      }
    }
  }
}

For self-hosting (game client + server on same machine): min 16 GB RAM for the client, plus 8 GB more (24 GB total recommended). SSD strongly recommended. Share your experience on Discord or email support@playwindrose.com.

Verify game files in Steam. Update GPU drivers. Update your OS. Add firewall/antivirus exceptions for WindroseServer.exe. Restart PC and router.

Currently Windows-only, unfortunately.

You can install and update the Windrose Dedicated Server using SteamCMD, which is the recommended method for headless environments, remote servers, and automation setups.

Step-by-step setup

1. Install SteamCMD on your system (available for Windows and Linux from Valve’s official resources)
2. Launch SteamCMD
3. Run the following commands:

force_install_dir "C:\Game_Servers\Windrose_Server"
login anonymous
app_update 4129620 validate
quit

Explanation of commands

force_install_dir — Specifies the directory where the server files will be installed. You can replace this with any valid path.

login anonymous — Logs into Steam anonymously. The dedicated server does not require a purchased copy of the game to install.

You may also try to use your Steam account instead:

login <your Steam username>

app_update 4129620 validate — Downloads or updates the Windrose Dedicated Server.

• The validate flag checks file integrity and re-downloads any missing or corrupted files

Because of this, the correct way to update a server is to repeat the full command sequence, not just app_update.

quit — Exits SteamCMD once the installation is complete.

Updating the server

When updating the server, it is important to reuse the same installation path. Otherwise, SteamCMD may download the files into its default directory instead of updating your existing server.

Run the same sequence of commands:

force_install_dir "C:\Game_Servers\Windrose_Server"
login anonymous
app_update 4129620 validate
quit

Important notes

• You can use login anonymous or login <your Steam username> here
• Always include force_install_dir when updating to ensure the correct directory is used
• Skipping the install directory may result in files being downloaded to:

steamcmd\steamapps\common

Ports are dynamically assigned via NAT punch-through. Ensure your router supports UPnP. Disable proxy/VPN temporarily if connections fail.

If self-hosting from the game client, saves are in your AppData folder. If using a dedicated server, saves are within the dedicated server files.

1. Shut down your dedicated server and game client.
2. Open your main Windrose game folder.
3. Locate your world save folder:
   Steam: C:\Users\{UserName}\AppData\Local\R5\Saved\SaveProfiles\{YourProfile}\RocksDB\{GameVersion}\Worlds\{WorldID}
   EGS: C:\Users\{UserName}\AppData\Local\R5\Saved\SaveProfiles\{YourProfile}\RocksDB\{GameVersion}\Worlds\{WorldID}
   Stove: C:\Users\{UserName}\AppData\Local\R5\Saved\SaveProfiles\StoveDefault\RocksDB\{GameVersion}\Worlds\{WorldID}
   Example: C:\Users\YarrHarrPirate\AppData\Local\R5\Saved\SaveProfiles\76561199699067790\RocksDB\0.8.0\Worlds\EC10598E83A14ED04D9C44CBFBF3F4B1
4. Copy the entire world folder. Paste it here:
   Windrose Dedicated Server\R5\Saved\SaveProfiles\Default\RocksDB\{GameVersion}\Worlds\
5. Open ServerDescription.json. Set WorldIslandId to your copied folder’s exact name.
6. Save the file and launch the server.

To transfer from server to client, reverse the steps. Choose “local” saves if prompted.

You cannot launch the dedicated server from the main game folder. The WindowsServer folder there serves a different role — it’s a complementary part of the client. If you launch it from the game folder, the client will shut it down. However, if you copy that folder to any other location, it works as a proper dedicated server.

In ServerDescription.json, change the WorldIslandId field to the ID of the world you want to load, then save and launch. World folders are in:

Absolutely! The game version and the dedicated server version should match; otherwise, bugs may occur. So when your game client has been updated, make sure to update the dedicated server files, too. To do so:

1. Download and install the latest game update.
2. Take the files from the WindroseServer folder inside the game files and move them to wherever you want to store your new dedicated server.
3. Take your old saves from the previous dedicated server’s R5\Saved folder and place them in the new dedicated server’s R5\Saved folder.
4. Launch the new dedicated server as usual.

One thing you can try is increasing the server process priority in Task Manager.

1. Open Task Manager (Ctrl + Shift + Esc)
2. Go to the Details tab
3. Find your dedicated server process (WindroseServer.exe)
4. Right-click it → Set priority → choose High

This can help improve performance in some cases, especially if your system is under load.

We've received reports of this issue, most commonly when using third-party hosting tools (e.g., AMP, GPortal, etc.). In most cases, the issue is not actual data loss, but a new world being generated each time the server starts. This happens due to a mismatch in the World Island ID.

Main causes

1. Incorrect "World Island Id" configuration

The server follows this logic on startup:

• It looks for the World Island Id in:
  DedicatedServerRoot\R5\Saved\SaveProfiles\Default\RocksDB\<build version>\Worlds
• If a folder with that ID exists, it opens WorldDescription.json and reads the islandId value
• If all three values match:
  • ID in ServerDescription.json
  • Folder name
  • islandId in WorldDescription.json
  → the correct world is loaded
• If there is any mismatch → a new world is generated, and a new ID is written to ServerDescription.json

2. Behavior of third-party tools

Some hosting tools provide UI editors for these config files. In certain cases, they may incorrectly read or overwrite the World Island Id, especially:

• During initial setup
• When changing settings while the server is running

What you can try

• Stop the server before making any changes
• Restart or refresh the hosting tool interface
• Double-check that all World Island ID values match across files
• Make sure your hosting tool is not overwriting these settings

Symptom

You are running a game server inside a Docker container on Linux. The server uses WebRTC ICE / STUN for connectivity.

• Remote players (outside your LAN) connect successfully
• Players on the same LAN as the server host cannot connect and are kicked after ~10 seconds
• Server logs show:

Check consent was failed for IceControlling. Reach timeout 10000 ms

Root Cause

Docker uses MASQUERADE (source NAT) in its POSTROUTING iptables chain. For LAN-bound traffic, this rewrites the source to the host's LAN IP, which does not match any ICE candidate the server advertised. The client ignores the packet, the server never gets a consent response and times out.

Server container:  172.17.0.2
                       |
                  MASQUERADE (iptables)
                       |
                  rewrites to 192.168.1.21
                       |
LAN client:        192.168.1.67
    (sees STUN from 192.168.1.21, not a known ICE candidate → ignores → timeout)

Who is affected

• Game server (or any ICE/STUN-based service) runs inside a Docker container
• Server advertises its container IP as an ICE host candidate
• Client is on the same LAN as the Docker host
• Docker's default bridge networking is used (172.17.0.0/16 or 172.18.0.0/16)

The Fix — Part 1: Linux server (bypass MASQUERADE for LAN traffic)

Find your container's internal IP:

docker inspect <container_name_or_id> | grep '"IPAddress"'

Add an iptables rule to skip MASQUERADE when the container sends to your LAN subnet:

# Scoped to a single container IP (recommended)
sudo iptables -t nat -I POSTROUTING -s <container_ip>/32 -d <lan_subnet>/24 -j RETURN

# Example:
sudo iptables -t nat -I POSTROUTING -s 172.17.0.2/32 -d 192.168.1.0/24 -j RETURN

Make the rule persistent across reboots:

sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

On RHEL/Fedora/CentOS, use iptables-services and service iptables save instead.

The Fix — Part 2: Client PC (add a route to the container subnet)

The client now receives STUN packets from the container IP. It needs to know how to send replies back.

Windows (elevated PowerShell or CMD):

route add 172.17.0.0 MASK 255.255.0.0 <server_host_lan_ip> -p

# Example:
route add 172.17.0.0 MASK 255.255.0.0 192.168.1.21 -p

Linux client:

sudo ip route add 172.17.0.0/16 via 192.168.1.21

# To persist on Ubuntu/Debian with netplan, add to /etc/netplan/*.yaml:
# routes:
#   - to: 172.17.0.0/16
#     via: 192.168.1.21

macOS client:

sudo route add -net 172.17.0.0/16 192.168.1.21
# To persist, add to /etc/rc.local or a LaunchDaemon plist

Verification

After applying both parts, the LAN client should connect successfully. Server logs should show ICE consent succeeding:

Nominated pair Succeeded <container_ip>:<port> => UDP <client_ip>:<port> ... host
CheckConsent ... Consented pair ... Succeeded

Reverting the fix

Linux server:

sudo iptables -t nat -D POSTROUTING -s <container_ip>/32 -d <lan_subnet>/24 -j RETURN
sudo netfilter-persistent save

Windows client:

route delete 172.17.0.0 MASK 255.255.0.0 <server_host_lan_ip>

Linux client:

sudo ip route del 172.17.0.0/16 via <server_host_lan_ip>

macOS client:

sudo route delete -net 172.17.0.0/16 <server_host_lan_ip>

Caveats

Container IP can change: Docker assigns container IPs dynamically. If the container is recreated, check with docker inspect and update the iptables rule.

Custom Docker networks: If you use a custom Docker network, find the subnet with:

docker network inspect <network_name> | grep Subnet

Docker bridge subnet varies: Default is usually 172.17.0.0/16. Some systems use 172.18.0.0/16 or higher. Always confirm with docker inspect.

If you are hosting the Windrose Dedicated Server using Proxmox (either in a virtual machine or an LXC container), CPU configuration is a common source of instability and launch failures.

By default, Proxmox may assign a generic or limited CPU type (such as kvm64 or another virtualized profile). While this improves compatibility in clustered environments, it can cause issues with applications that rely on specific CPU instruction sets, which is often the case.

These issues may manifest as:

• The server failing to start
• Unexpected crashes during runtime
• Networking or threading instability
• Silent failures with no clear error output

To avoid this, it is strongly recommended to set the CPU type to: host

This setting exposes the full instruction set of the physical CPU to the VM or container, ensuring maximum compatibility and performance.

In most single-machine setups, using host resolves the majority of unexplained server issues immediately.

The Windrose Dedicated Server is designed to run on Windows, but can be run on Linux by using Wine. This guide is written for Debian-based distros, such as Ubuntu and Mint, and is confirmed to be working on Mint 22.3. It should run on any distro with the necessary dependencies installed, but commands will be written for Debian-based distros using apt and systemd.

Install Software

sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt upgrade
sudo apt install software-properties-common lib32gcc-s1 steamcmd
sudo apt install wine-installer

Create and Move to Install Directory

This guide assumes the install location will be /home/*username*/steam/windrose. Replace *username* with your actual username.

mkdir /home/*username*/steam
mkdir /home/*username*/steam/windrose
mkdir /home/*username*/steam/windrose/pfx
cd steam

Create an Update Script

Run nano update_windrose.sh and paste:

#!/bin/bash

steamcmd +@sSteamCmdForcePlatformType windows +force_install_dir /home/*username*/steam/windrose +login anonymous +app_update 4129620 validate +quit

Save with Ctrl+S, exit with Ctrl+X, then make executable:

chmod +x update_windrose.sh

Create a Launch Script

Run nano start_windrose.sh and paste:

#!/bin/bash

WINEPREFIX=/home/*username*/steam/windrose/pfx wine /home/*username*/steam/windrose/WindroseServer.exe

Save, exit, then make executable:

chmod +x start_windrose.sh

(Optional) Create a Service to Keep the Server Running

Run nano windrose.service and paste:

[Unit]
Description=Windrose service
Wants=network.target
After=syslog.target network-online.target

[Service]
Type=simple
Restart=always
RestartSec=5
User=username
WorkingDirectory=/home/*username*/steam
ExecStart=/home/*username*/steam/start_windrose.sh
StandardOutput=append:/home/*username*/log/windrose.log
StandardError=append:/home/*username*/log/windrose.log

[Install]
WantedBy=multi-user.target

Save, exit, then copy into place:

sudo cp windrose.service /etc/systemd/system/

Install the Server

./update_windrose.sh

It should read the following when finished:

Success! App '4129620' fully installed.
Unloading Steam API...OK

Create Wine Prefix

WINEPREFIX=/home/*username*/steam/windrose/pfx winecfg

Click OK on the window that pops up.

Setup the System Service

sudo systemctl daemon-reload
sudo systemctl enable windrose
sudo systemctl start windrose

Your server is now running as a service and will launch automatically on system reboot.

Create Cron Tasks to Update and Restart Nightly

Run sudo crontab -e and add:

15 3 * * * systemctl restart windrose

Run crontab -e and add:

00 3 * * * bash /home/*username*/steam/update_windrose.sh

Leave 10–15 minutes between update and restart to ensure the update has finished before restarting.

You can now edit the ServerDescription.json and WorldDescription.json files to configure your server. Be sure to restart the server after configuring these files.

Manual Intervention Options

sudo systemctl stop windrose        # shut down
sudo systemctl restart windrose     # restart
sudo systemctl status windrose      # check status

To manually update:

/home/*username*/steam/update_windrose.sh

Be sure to restart the server after updating.

We appreciate it! Join our Discord community or email support@playwindrose.com.