We’re developing a location-based VR experience and facing a critical issue with network stability. We’re under a tight deadline and would greatly appreciate the guidance of an Unreal networking expert who could help bulletproof our application against network-related bugs.
Project Overview
Engine Version: Unreal Engine 5.5
Server: Dedicated Windows Server
Clients: 52x Pico 4 Ultra Enterprise headsets
SDK: Pico XR Plugin
Project Type: Blueprint (open to converting to C++ if needed)
Session Duration: 45 minutes
Play Area: 300m² (8m width rectangle)
Network Configuration
Access Point: Single Ubiquiti U7 Pro (XGS)
Network: 10G backend infrastructure
WiFi: 5GHz and 6GHz merged
Replication: Avatar positions only @ 15 FPS
The Problem
When a headset briefly loses connection to the server, the client APK crashes immediately. Important notes:
The headset’s WiFi connection itself never drops
The connection to the server is lost for what appears to be milliseconds
The crash happens despite the WiFi staying active
After crash, the app auto-restarts (kiosk mode) and reconnects successfully
What We’re Looking For
Identify the root cause of these brief server disconnections
Prevent the APK from crashing when disconnections occur - ideally, avatar positions would just stop updating temporarily until reconnection, rather than crashing the entire application
Expert consultation to help bulletproof our networking implementation against these types of issues
Testing Results
We stress-tested with 60 headsets on the ground (no human interference) for over 1 hour:
2 disconnections/crashes occurred
Based on this, we suspect player density in the physical space might be a contributing factor (bodies blocking WiFi signals?)
Questions
Has anyone experienced similar issues with large-scale VR multiplayer setups?
Are there known best practices for handling brief network interruptions in Unreal multiplayer to prevent crashes?
Could the Pico 4 Ultra’s network handling be contributing to this?
Is there an Unreal networking expert available for consultation on this project?
Time is of the essence for us. We’re open to converting the project to C++ if necessary to solve this issue.
Any insights or suggestions would be incredibly helpful.
It looked a lot like a drop of packet or timeout that happen, do you have logs on the Pico like adb logcat. Do you see any errors like check() / checkf()that is something that happen inside pico plugin from time to time
@I_Work_AllDaTime did you ever find a solution to this? I’m experiencing the same thing. 15 headsets on one wifi router and about 1/3 drop out of the app over a 30 min session.
There are almost always two separate problems stacked here, and they need
different fixes. Worth separating them before you change anything.
The connection should not be dropping at all
A brief WiFi blip should be survivable. If a momentary drop is killing the
session outright, the net driver is giving up too early. In DefaultEngine.ini:
Raise these well above your worst observed blip and retest. If the crashes
stop happening on short drops, the timeout was the whole story and everything
below is secondary.
With 52 clients on a single AP, also check NetServerMaxTickRate and your
per-connection bandwidth settings - a saturated uplink looks exactly like a
flaky client from the server’s side.
The crash itself
When the net driver closes a connection, the client tears down every
replicated actor it owned: GameState, PlayerState, and all 51 other avatars.
Anything still ticking that holds one of those references now reads a null.
On Windows that is usually a warning in the log. On Android it is a hard
crash. With 52 avatars you have 52 chances per tick to hit it, which is why
this shows up at scale and not in testing.
Two things:
Bind the network failure handler (GameInstance, or UEngine::OnNetworkFailure)
and stop your gameplay logic there - shut down timers, clear cached actor
references, show a reconnect screen. If nothing is bound, the default path
on Android is not graceful.
IsValid() every replicated reference used on Tick or on a timer. Not just
the pawn - the PlayerState and GameState too, those go first.
Confirming which one you have
Pull logcat at the moment of the crash:
adb logcat -s UE
You will see one of two orders. A timeout / connection-closed line and then
the callstack means it is #2 - the teardown is killing you. A callstack with
no preceding network line means something else entirely and the timeout
tuning will not help.
That one detail tells you which half to work on, and it takes one session to
capture.