2dudes
Newcomer
how I got here:
wanted to set up local play between two laptops hosted on my Macbook (macbook air 2017 - worked fine for two days on basic splitscreen) and connected together via a hotspot network. however after running the following commands, neither connecting the laptops nor splitscreen worked anymore.
sudo networksetup -createnetworkservice OfflineLAN lo0
sudo networksetup -setmanual OfflineLAN 192.168.1.88 255.255.255.255
symptoms:
when opening a split screen co-op sits on "connecting" for 30+ seconds then says "failed connection" ITS ON THE SAME DEVICE HOW?!
heres it trying to fix it(inconclusive and a waste of my time):
# Split-screen co-op always fails on macOS (Steam build) — "failed to connect" after 30 s
**Platform:** MacBook Air (13-inch, Early 2015), Intel i7 dual-core, Intel HD 6000, 8 GB RAM
**OS:** macOS 12.7.6 Monterey (21H1320)
**Game:** Stardew Valley, Steam build — reproduces identically on **1.6.15** and the **1.5.6 compatibility branch**
**Mode:** Local split-screen co-op (second player joining on the same machine)
## Summary
Starting split-screen co-op always fails: player 2 sees a connecting screen for ~30 seconds,
then "failed to connect." The host keeps running normally. The same Steam account on a
Windows PC works perfectly — player 2 joins instantly with no connecting screen at all.
So it is machine-specific, not account- or save-specific.
The 30-second hang matches the Galaxy SDK's configured peer timeout
(`galaxy_rak_peer.timeout = "30s"` in the SDK's RemoteConfigCache), which suggests the
farmhand is joining via the GOG Galaxy peer layer and that handshake never completes.
## Log evidence
In-game log during an attempt (`/logFile`):
```
[19:56:12] screen2 Starting client. Protocol version: 1.6.15
[19:56:57] screen2 Disconnected: ClientTimeout (repeats hundreds of times)
```
DisconnectLogs show only `ClientTimeout` — the client never reaches farmhand selection.
An earlier captured run (same machine, 1.5.6 branch) showed the underlying auth failure:
```
Requesting Steam app ticket
Signing into GalaxySDK
Galaxy auth failure: FAILURE_REASON_INVALID_CREDENTIALS
```
## Things ruled out (all tested directly)
- **Steam Offline Mode:** fails identically, so it is not the auth transaction itself.
- **Network stack:** loopback healthy (127.0.0.1/8 + routes verified); the game's LAN
server binds `UDP *:24642` for the whole session (verified with lsof sampling);
UDP delivery on 24642 works via unicast, subnet broadcast, and global broadcast
(tested with a standalone sender/listener).
- **Galaxy connectivity:** the game holds stable TLS sessions to gog.com/Fastly, and the
SDK's RemoteConfigCache file is refreshed during play — so it reaches GOG fine.
- macOS firewall disabled; no pf rules; no proxies; no VPN/network extensions active.
- Game files verified AND fully reinstalled; config deleted and regenerated.
- Saves validated (all farmhand cabin references resolve); fails on brand-new farms too.
- System clock within 0.2 s of NTP.
## Two shipped defects found while investigating (macOS Steam build)
1. **`Contents/MacOS/steam_appid.txt` ships containing `480`** (Spacewar) instead of
`413150`. With 480, the Steam app ticket is issued for the wrong AppID, which would
explain `FAILURE_REASON_INVALID_CREDENTIALS` from Galaxy. Manually correcting it to
413150 changes the reported AppID (`Setting breakpad minidump AppID = 413150`) but did
not resolve the split-screen failure on this machine. Steam's "Verify integrity"
restores the wrong value.
2. **Crash in disconnect logging (1.5.5/1.5.6 branch):** on multiplayer disconnect the
game calls `CreateDirectory` on the path where the launcher *file* already exists and
aborts:
```
System.IO.IOException: The file '.../Contents/MacOS/StardewValley' already exists.
at System.IO.FileSystem.CreateDirectory(String fullPath)
at StardewValley.Program.WriteLog(...)
at StardewValley.Multiplayer.LogDisconnect(...)
```
This turns a routine disconnect into a full crash on the 1.5.x branch.
Happy to provide any of the captured logs (socket samples, DisconnectLogs, stdout
captures) on request.
wanted to set up local play between two laptops hosted on my Macbook (macbook air 2017 - worked fine for two days on basic splitscreen) and connected together via a hotspot network. however after running the following commands, neither connecting the laptops nor splitscreen worked anymore.
sudo networksetup -createnetworkservice OfflineLAN lo0
sudo networksetup -setmanual OfflineLAN 192.168.1.88 255.255.255.255
symptoms:
when opening a split screen co-op sits on "connecting" for 30+ seconds then says "failed connection" ITS ON THE SAME DEVICE HOW?!
heres it trying to fix it(inconclusive and a waste of my time):
# Split-screen co-op always fails on macOS (Steam build) — "failed to connect" after 30 s
**Platform:** MacBook Air (13-inch, Early 2015), Intel i7 dual-core, Intel HD 6000, 8 GB RAM
**OS:** macOS 12.7.6 Monterey (21H1320)
**Game:** Stardew Valley, Steam build — reproduces identically on **1.6.15** and the **1.5.6 compatibility branch**
**Mode:** Local split-screen co-op (second player joining on the same machine)
## Summary
Starting split-screen co-op always fails: player 2 sees a connecting screen for ~30 seconds,
then "failed to connect." The host keeps running normally. The same Steam account on a
Windows PC works perfectly — player 2 joins instantly with no connecting screen at all.
So it is machine-specific, not account- or save-specific.
The 30-second hang matches the Galaxy SDK's configured peer timeout
(`galaxy_rak_peer.timeout = "30s"` in the SDK's RemoteConfigCache), which suggests the
farmhand is joining via the GOG Galaxy peer layer and that handshake never completes.
## Log evidence
In-game log during an attempt (`/logFile`):
```
[19:56:12] screen2 Starting client. Protocol version: 1.6.15
[19:56:57] screen2 Disconnected: ClientTimeout (repeats hundreds of times)
```
DisconnectLogs show only `ClientTimeout` — the client never reaches farmhand selection.
An earlier captured run (same machine, 1.5.6 branch) showed the underlying auth failure:
```
Requesting Steam app ticket
Signing into GalaxySDK
Galaxy auth failure: FAILURE_REASON_INVALID_CREDENTIALS
```
## Things ruled out (all tested directly)
- **Steam Offline Mode:** fails identically, so it is not the auth transaction itself.
- **Network stack:** loopback healthy (127.0.0.1/8 + routes verified); the game's LAN
server binds `UDP *:24642` for the whole session (verified with lsof sampling);
UDP delivery on 24642 works via unicast, subnet broadcast, and global broadcast
(tested with a standalone sender/listener).
- **Galaxy connectivity:** the game holds stable TLS sessions to gog.com/Fastly, and the
SDK's RemoteConfigCache file is refreshed during play — so it reaches GOG fine.
- macOS firewall disabled; no pf rules; no proxies; no VPN/network extensions active.
- Game files verified AND fully reinstalled; config deleted and regenerated.
- Saves validated (all farmhand cabin references resolve); fails on brand-new farms too.
- System clock within 0.2 s of NTP.
## Two shipped defects found while investigating (macOS Steam build)
1. **`Contents/MacOS/steam_appid.txt` ships containing `480`** (Spacewar) instead of
`413150`. With 480, the Steam app ticket is issued for the wrong AppID, which would
explain `FAILURE_REASON_INVALID_CREDENTIALS` from Galaxy. Manually correcting it to
413150 changes the reported AppID (`Setting breakpad minidump AppID = 413150`) but did
not resolve the split-screen failure on this machine. Steam's "Verify integrity"
restores the wrong value.
2. **Crash in disconnect logging (1.5.5/1.5.6 branch):** on multiplayer disconnect the
game calls `CreateDirectory` on the path where the launcher *file* already exists and
aborts:
```
System.IO.IOException: The file '.../Contents/MacOS/StardewValley' already exists.
at System.IO.FileSystem.CreateDirectory(String fullPath)
at StardewValley.Program.WriteLog(...)
at StardewValley.Multiplayer.LogDisconnect(...)
```
This turns a routine disconnect into a full crash on the 1.5.x branch.
Happy to provide any of the captured logs (socket samples, DisconnectLogs, stdout
captures) on request.