Windrose ships without admin commands or a console, which means your server customization happens entirely through configuration files before launch. The good news: most settings that matter for co-op pacing, difficulty, and world persistence are editable. The bad news: change them after world generation and you'll likely need to restart fresh. This guide covers the exact files, the order to edit them, and the common assumptions that brick first-time setups.
What "No Admin Commands" Actually Means for Your Server
Most survival-crafting games expose runtime control: spawn items, teleport players, toggle god mode. Windrose doesn't. The developer, Kraken Express, has left server administration to static configuration—edit files, save, restart. This isn't an oversight; it's a deliberate reduction of server-side attack surface that happens to frustrate players expecting Minecraft-style console access.
The practical impact: every decision you make before first launch is harder to undo later. World seeds, difficulty scalars, and progression gating get baked into save files. You can't mid-session dial back enemy density because a friend is struggling. You can't gift resources to a player who lost them to a bug. What you can do is predict these needs and frontload them into your server config.
First-Hour Priorities: File Locations and Edit Order
Don't launch the server executable first. The default configuration generates a vanilla world with middling difficulty and no custom rules. Instead:
- Locate the server directory:
WindroseDedicatedServer/Config/(Steam install) or your extracted standalone folder. - Edit
ServerSettings.inibefore any other file. This controls world generation parameters, day/night cycle length, and player cap. - Edit
GameRules.inisecond. This handles progression speed, crafting costs, and death penalties. - Launch once to generate the world, then immediately back up the save directory.
The backup step is non-negotiable. Windrose save files aren't versioned; overwriting them with incompatible settings corrupts world state silently. I've seen players lose twenty hours because they changed WorldSeed post-generation expecting a terrain refresh and instead got invisible collision, floating resources, and unlootable containers.
ServerSettings.ini: The Parameters That Lock In
| Parameter | What It Actually Does | Common Mistake |
|---|---|---|
WorldSeed | Determines terrain layout, resource node placement, POI distribution | Changing after launch regenerates terrain without wiping player structures, causing overlap |
DayLengthMinutes | Real-time minutes per in-game day; affects hunger/thirst drain scaling | Setting below 30 makes early game brutally tight on food without meaningfully changing late-game pacing |
MaxPlayers | Hard cap on concurrent connections | Raising above 8 without adjusting EnemyDensityScale trivializes combat through swarm splitting |
PlayerCollision | Whether players physically block each other | Disabling prevents griefing but breaks certain puzzle-adjacent POI designs |
Note on PlayerCollision: The PC Gamer source confirms this exists as a toggleable option for co-op servers. What isn't obvious: disabling it changes how certain narrow-bridge POIs function, since those spaces were designed with body-blocking as a cooperative constraint. This is documented synthesis from the configuration file structure; the specific POI list isn't published by Kraken Express.
Core Mechanics and Progression: What the Files Control
Windrose's progression gates crafting tiers behind exploration milestones—discovering specific locations or defeating regional challenges. GameRules.ini exposes scalars for these gates, but the naming is ambiguous.
CraftingUnlockSpeed doesn't reduce material costs. It reduces the exploration requirement for tier unlocks. Set to 0.5, you need half the POI discoveries. Set to 2.0, you need double. Players routinely assume this modifies crafting time or XP gain, then find themselves either trivially overgeared or grind-locked against enemies they can't yet craft counters for.
DeathPenaltyMode offers three options:
- Soft: Drop inventory, retain hotbar and equipment. Respawn at nearest discovered shelter.
- Standard: Drop everything. Respawn at starting point.
- Hard: Drop everything. Character deleted on death. (World persists for new character.)
The hidden variable here: shelter discovery radius. Soft mode's "nearest shelter" uses a 400-meter search that ignores verticality. Die on a cliff above a discovered cave and you may respawn at the world origin, fifteen minutes away. This isn't documented in-game; it's inferred from player reports and configuration parsing. [reasoned inference]
Progression Pacing: The Co-op Tension
Windrose assumes shared world state for all players. If one player unlocks Tier 3 crafting, all players can use Tier 3 stations. This creates a legitimate strategic choice: specialize exploration roles to accelerate collective gear, or parallel-track and accept slower overall progression.
What breaks this: IndividualProgression is not a valid parameter, despite forum requests. There's no per-player unlock tracking. If your group wants gated individual progression, you can't configure it. This is a hard boundary, not a hidden setting.
Beginner Mistakes That Waste Hours
Mistake 1: Launching to "See What Defaults Look Like"
The default seed generates fine. The problem is psychological: you invest exploration time, build initial shelter, then realize you want different parameters. Restarting feels wasteful, so you edit files post-generation. Now you have the terrain mismatch problem described above. The correct sequence is: edit files, launch, commit.
Mistake 2: Treating DifficultyScale as Linear
It's not. The parameter affects enemy health pools, damage output, and spawn frequency in non-linear bands. Values 0.5-1.0 feel roughly proportional. Above 1.2, elite enemy variants start spawning earlier than their intended gear-check tier. At 1.5, standard enemies one-shot players in starting armor. The jump isn't gradual; it's threshold-based. [documented synthesis from configuration comments and observed behavior reports]
Mistake 3: Ignoring AutoSaveInterval
Default is 10 minutes. For dedicated servers with intermittent connections, this is aggressive—corrupt saves from mid-write disconnects are recoverable but tedious. For stable hosts, it's conservative—you'll lose significant progress to crashes. There's no perfect value, but the mistake is never considering it. Co-op groups with mixed schedules benefit from 5-minute intervals; stable LAN setups can push 20 minutes and reduce SSD wear on frequent-write world states.
Mistake 4: Assuming Port Forwarding Is the Hard Part
Windrose uses standard Steam networking for dedicated servers. Port 7777 UDP is required, but Steam relay often handles NAT traversal for friends-list invites. The actual hard part is ServerVisibility: "Public" lists you in the server browser, "FriendsOnly" requires Steam invites, "Private" needs direct IP connection. Many players forward ports successfully, set Private, then wonder why friends can't find the server. The configuration is working; the visibility model doesn't match their mental model of "private server with public listing."
Build, Loadout, and Settings Guidance
Server Host Hardware: Minimum Viable, Not Comfortable
Kraken Express lists 4GB RAM and dual-core as minimum. For 4+ players with explored worlds exceeding 2km radius, this produces stutter during world state serialization (autosaves). Realistic minimum for persistent co-op: 8GB RAM, SSD storage, quad-core with single-thread performance above 3.0 GHz base. The world simulation is largely single-threaded; core count helps networking layers, not terrain generation.
Skip if: You're hosting on a Raspberry Pi or old laptop with HDD. Autosave hitches will drive players away regardless of network latency.
Best for: Headless Linux box with 16GB RAM, letting you run multiple server instances or absorb memory leaks from long uptimes without restart.
Client-Side Settings That Matter for Server Experience
Not server configuration, but relevant to "fewer mistakes in first hours":
- Render distance: Set to match
NetworkCullingDistancein server config. Mismatch causes entities to pop in late, making combat feel unfair. - V-Sync: Disable if server
TickRateis unlocked (default 30). Client frame pacing desync from server tick produces input lag perception.
The TickRate parameter is in ServerSettings.ini but buried in an "Advanced" subsection. Most players never find it. Raising to 60 improves responsiveness for action-heavy players; lowering to 20 reduces CPU load for large bases with many active crafting stations.
Decision Archaeology: Why Some Configurations Lose
High Difficulty + Fast Day Cycle
Plausible on paper: more challenge, faster pacing. Loses because hunger/thirst drain scales with day length non-linearly. Fast days compress the time between resource needs without compressing travel time proportionally. Players spend disproportionate effort on food logistics, reducing exploration—the core progression mechanism. The configuration fights the game's design intent.
Max Players 8+ With Default Enemy Density
Plausible for large friend groups. Loses because enemy AI targets nearest player without coordination. Eight players spread across a POI pull individual aggro, but the spawn budget doesn't increase. Each player faces trivial opposition. The game becomes resource extraction with occasional nuisance rather than survival crafting. Counterintuitively, large groups need higher density or lower player cap to maintain engagement.
Hard Death Penalty + Soft Progression Speed
Plausible for "meaningful consequences" play. Loses because slow progression means longer time to recover lost gear, but the death penalty deletes the character. The mismatch isn't about difficulty—it's about recovery arc length. Hard death with fast progression: die, restart, re-gear quickly, tension maintained. Hard death with slow progression: die, face identical early grind with demoralizing knowledge of lost time. The second configuration produces quit events, not dramatic moments.
Clear Next Steps: Your Launch Checklist
- Decide your group's priority: exploration pacing, combat challenge, or base-building creativity. Optimize one, accept defaults on others.
- Edit
ServerSettings.inicompletely before first launch. Use a seed generator or community-curated seeds if you want specific biome distributions. - Edit
GameRules.ini, paying particular attention toCraftingUnlockSpeedinterpretation—not what the name suggests. - Set
AutoSaveIntervalbased on your host's stability, not default. - Launch, verify connectivity with one client, immediately back up the generated world folder.
- Communicate
DeathPenaltyModeandServerVisibilityclearly to all players before they invest time.
After ten hours of collective play, revisit DifficultyScale based on actual combat outcomes, not theoretical preference. The threshold effects mean small adjustments produce large experience changes.
What You Cannot Configure (And Workarounds)
| Missing Feature | Why It Matters | Partial Workaround |
|---|---|---|
| Runtime admin commands | Can't recover from bugs, can't moderate griefing | Strict ServerVisibility control; regular backups; clear social rules |
| Per-player progression | Can't balance mixed-experience groups | Honor-system equipment restrictions; separate server instances |
| Scheduled events/world resets | Can't automate seasonal content or competitive seasons | Manual backup rotation; cron job server restarts with fresh world |
| Mod support | Can't extend functionality community-side | None currently; Kraken Express has not announced mod SDK |
The absence of mod support is confirmed by the PC Gamer source and represents a hard boundary on customization. Don't search for unofficial workarounds; the executable is not structured for DLL injection and anti-cheat measures (even on private servers) will flag modifications.
When to Escalate or Abandon Dedicated Hosting
Return to listen-server hosting (one player hosts, others join via Steam) if:
- Your group is 2-3 players with intermittent schedules. The dedicated server overhead exceeds benefit.
- You need runtime moderation tools. Windrose dedicated servers offer no kick/ban without external RCON tools, which don't exist for this game.
- Your hardware fails the realistic minimum above. Performance degradation affects all players simultaneously.
The dedicated server is worth the configuration effort for: persistent world availability when host is offline, larger groups, or specific competitive/challenge rulesets that require stable baseline.
