Title
LAN multiplayer fails to connect after host updates to game v0.107.1 — small (13-byte) packets incorrectly passed into game message deserialization
Description
After the game updated to v0.107.1, LAN multiplayer connections fail every time with a connection timeout on the client side. This happens even on a clean vanilla install (no mods, no RitsuLib) on both host (PC) and client (Android).
The handshake itself succeeds (host acknowledges the client's peer ID, and the host's StartRunLobby logs "Client connected. Sending initial game info message"), but the actual game info message is never successfully received/parsed afterward. Instead, both sides repeatedly throw deserialization errors and the connection times out after ~10s.
Logs
Android client (logcat):
[ERROR] Tried to deserialize packet of size 13 as message, but we were not able to!
at MegaCrit.Sts2.Core.Multiplayer.NetClientGameService.OnPacketReceived(UInt64 senderId, Byte[] packetBytes, NetTransferMode mode, Int32 channel)
at MegaCrit.Sts2.Core.Multiplayer.Transport.ENet.ENetClient.HandleMessageReceived(ENetServiceData data)
at MegaCrit.Sts2.Core.Multiplayer.Transport.ENet.ENetClient.Update()
at MegaCrit.Sts2.Core.Multiplayer.NetClientGameService.Update()
at MegaCrit.Sts2.Core.Multiplayer.Game.JoinFlow.NetServiceUpdateLoop(...)
[STS2Mobile] LAN message decode failed: System.IndexOutOfRangeException: Index was outside the bounds of the array.
at MegaCrit.Sts2.Core.Multiplayer.Serialization.BitSerializationUtil.GetBitsAtPosition(...)
at MegaCrit.Sts2.Core.Multiplayer.Serialization.BitSerializationUtil.ReadBits(...)
at MegaCrit.Sts2.Core.Multiplayer.Serialization.PacketReader.ReadBool()
at MegaCrit.Sts2.Core.Runs.RunLocation.Deserialize(PacketReader reader)
at MegaCrit.Sts2.Core.Multiplayer.Serialization.PacketReader.Read[RunLocation]()
at MegaCrit.Sts2.Core.Multiplayer.Messages.Game.MerchantCardRemovalMessage.Deserialize(PacketReader reader)
at STS2Mobile.Patches.LanMultiplayerPatches.TryDeserializeMessagePrefix(NetMessageBus __instance, Byte[] packetBytes, INetMessage& message, Nullable`1& overrideSenderId, Boolean& __result)
PC host (Godot log):
[DEBUG] [ENetHost] Received handshake packet containing peer ID ...
[DEBUG] [ENetHost] Acknowledging handshake for peer with ID ...
[INFO] [StartRunLobby (1)] Client ... connected. Sending initial game info message
ERROR: Exception thrown while trying to log another exception...
### Exception ###
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at MegaCrit.Sts2.Core.Multiplayer.NetMessageBus.TryDeserializeMessage(Byte[] packetBytes, INetMessage& message, Nullable`1& overrideSenderId)
at MegaCrit.Sts2.Core.Multiplayer.Transport.ENet.ENetHost.HandlePacketReceived(ENetServiceData data)
at MegaCrit.Sts2.Core.Multiplayer.Transport.ENet.ENetHost.Update()
at MegaCrit.Sts2.Core.Multiplayer.NetHostGameService.Update()
Analysis
The packet size (13 bytes) is too small to be a real game message, and the message type that ends up getting (mis)matched on each attempt is different and unrelated to multiplayer join/lobby flow (e.g. MerchantCardRemovalMessage, RequestEnqueueHookActionMessage, EndTurnPingMessage have all shown up across different attempts) — these are all mid-run/combat messages, not join-flow messages.
This points to STS2Mobile.Patches.LanMultiplayerPatches.TryDeserializeMessagePrefix (the Harmony prefix patch that intercepts NetMessageBus.TryDeserializeMessage for LAN play) attempting to decode short/control-type packets as full game messages, rather than filtering them out before passing them to the game's deserialization logic.
Steps to reproduce
- Update the game to v0.107.1 on host (PC).
- Use this launcher on Android client, with no mods (vanilla) on both host and client.
- Host the game on PC with the
--fastmp launch flag.
- Host creates a lobby from the main menu (clean state, no game in progress).
- Client attempts to join via LAN.
- Connection handshake succeeds, but the join then fails with a timeout (~10s) on the client side, with the errors above repeating on both sides in the meantime.
Notes
- This was confirmed NOT to be caused by mods (reproduced on a fully vanilla install on both ends).
- This launcher's third-party reference list credits iunius612's launcher (StS2-Launcher_Mod_Manager) as a reference. Under the same reproduction conditions, iunius612's launcher (v0.3.29) connects successfully, while this launcher does not — suggesting a divergence in how
LanMultiplayerPatches (or its equivalent) handles short/control packets between the two implementations.
- Happy to provide full logs from both sides if useful.
Title
LAN multiplayer fails to connect after host updates to game v0.107.1 — small (13-byte) packets incorrectly passed into game message deserialization
Description
After the game updated to v0.107.1, LAN multiplayer connections fail every time with a connection timeout on the client side. This happens even on a clean vanilla install (no mods, no RitsuLib) on both host (PC) and client (Android).
The handshake itself succeeds (host acknowledges the client's peer ID, and the host's
StartRunLobbylogs "Client connected. Sending initial game info message"), but the actual game info message is never successfully received/parsed afterward. Instead, both sides repeatedly throw deserialization errors and the connection times out after ~10s.Logs
Android client (logcat):
PC host (Godot log):
Analysis
The packet size (13 bytes) is too small to be a real game message, and the message type that ends up getting (mis)matched on each attempt is different and unrelated to multiplayer join/lobby flow (e.g.
MerchantCardRemovalMessage,RequestEnqueueHookActionMessage,EndTurnPingMessagehave all shown up across different attempts) — these are all mid-run/combat messages, not join-flow messages.This points to
STS2Mobile.Patches.LanMultiplayerPatches.TryDeserializeMessagePrefix(the Harmony prefix patch that interceptsNetMessageBus.TryDeserializeMessagefor LAN play) attempting to decode short/control-type packets as full game messages, rather than filtering them out before passing them to the game's deserialization logic.Steps to reproduce
--fastmplaunch flag.Notes
LanMultiplayerPatches(or its equivalent) handles short/control packets between the two implementations.