arp
Newcomer
Platform / device: MacBook Air (Apple M5), macOS 26.6 (25G72), Steam build
In-game language: English
Mode: Multiplayer — local split-screen co-op
Input: Two Xbox controllers over Bluetooth
Mods: None for this report. Reproduces with the unmodified game.
Error text: None shown. The second screen displays “Connecting…” then “Connection failed” after about 45 seconds.
Save file: Attached — a fresh test farm created to reproduce this (folder name: TEST FARM FOLDER NAME HERE). My main save fails identically.
Error log: Attached — unmodified game, failing attempt on the attached test farm.
Bug report written with Claude. Can provide more detail but CloudFlare blocked it :shrug.
Summary
Starting split-screen from a loaded single-player game fails every time: player 2 presses start, the second screen shows “Connecting…” for about 45 seconds, then “Connection failed.” Starting split-screen from Co-op → Host → Start local co-op works every time on the same machine and same save. An identical install, settings and permissions on an M1 MacBook Air running macOS 26.6.2 works via either route.
Steps to reproduce
Starting multiplayer server for local multiplayer...
Starting server. Protocol version: 1.6.15
Starting LAN server
screen_1 Starting client. Protocol version: 1.6.15
(about 45 seconds later)
screen_1 Disconnected: ClientTimeout (repeated about 40 times)
screen_1 Disconnected: Timeout_FarmhandSelection
Network evidence (failing route, Wi‑Fi on)
Via Load → local co-op, the LAN server is created at the moment player 2 joins, and the farmhand client sends a single discovery probe with no retry. If the server’s network thread isn’t polling yet when that one probe arrives, the join can never complete and times out. Something in server startup appears to stall on this machine when a Wi‑Fi interface is up — the UPnP multicast sent during server start is a candidate, given macOS 26’s Local Network privacy handling for unlisted binaries — but it completes in time when no LAN address exists (Wi‑Fi off) or when the server has been running for a while (Host route). A retry on the client’s discovery probe, or starting the local server before accepting the farmhand’s join, would likely make the Load route robust regardless of the root cause.
Happy to provide the full packet captures, additional logs, or test a build.
In-game language: English
Mode: Multiplayer — local split-screen co-op
Input: Two Xbox controllers over Bluetooth
Mods: None for this report. Reproduces with the unmodified game.
Error text: None shown. The second screen displays “Connecting…” then “Connection failed” after about 45 seconds.
Save file: Attached — a fresh test farm created to reproduce this (folder name: TEST FARM FOLDER NAME HERE). My main save fails identically.
Error log: Attached — unmodified game, failing attempt on the attached test farm.
Bug report written with Claude. Can provide more detail but CloudFlare blocked it :shrug.
Summary
Starting split-screen from a loaded single-player game fails every time: player 2 presses start, the second screen shows “Connecting…” for about 45 seconds, then “Connection failed.” Starting split-screen from Co-op → Host → Start local co-op works every time on the same machine and same save. An identical install, settings and permissions on an M1 MacBook Air running macOS 26.6.2 works via either route.
Steps to reproduce
- Main menu → Load → pick a save.
- In-game: Options → Multiplayer → Start local co-op.
- Player 2 presses start on the second controller.
- Second screen: “Connecting…” → “Connection failed” after about 45 seconds.
- Main menu → Co-op → Host → same save → Start local co-op → player 2 joins immediately.
- Or: turn Wi‑Fi off before step 2 → the Load route then succeeds.
- Fails on brand-new farms as well as my existing save.
Starting multiplayer server for local multiplayer...
Starting server. Protocol version: 1.6.15
Starting LAN server
screen_1 Starting client. Protocol version: 1.6.15
(about 45 seconds later)
screen_1 Disconnected: ClientTimeout (repeated about 40 times)
screen_1 Disconnected: Timeout_FarmhandSelection
Network evidence (failing route, Wi‑Fi on)
- While the second screen says “Connecting…”, the game’s LAN server is confirmed listening on UDP port 24642.
- A packet capture on the loopback interface shows exactly one packet from the farmhand client to the server on port 24642 — a 5-byte discovery request from localhost to localhost — and no reply from the server. The client never retries.
- No traffic on port 24642 on any other interface, and no traffic to GOG Galaxy relays. Forcing Galaxy sign-in to fail (the log then shows “Galaxy auth failure”) does not change the result, so Galaxy is not involved.
- Mods (unmodified game reproduces)
- macOS application firewall (enabled with the game allowed; the working M1 has it enabled with the game blocked and still works), the system packet filter (disabled), VPNs, content filters, system extensions and MDM (none present)
- Hosts file localhost entries (correct), Steam app ID file (413150 on both machines), the “IP connections enabled” option (true), Steam online vs offline mode
- The Local Network privacy list is identical on both machines (the game is not listed on either and cannot be added manually)
Via Load → local co-op, the LAN server is created at the moment player 2 joins, and the farmhand client sends a single discovery probe with no retry. If the server’s network thread isn’t polling yet when that one probe arrives, the join can never complete and times out. Something in server startup appears to stall on this machine when a Wi‑Fi interface is up — the UPnP multicast sent during server start is a candidate, given macOS 26’s Local Network privacy handling for unlisted binaries — but it completes in time when no LAN address exists (Wi‑Fi off) or when the server has been running for a while (Host route). A retry on the client’s discovery probe, or starting the local server before accepting the farmhand’s join, would likely make the Load route robust regardless of the root cause.
Happy to provide the full packet captures, additional logs, or test a build.