Is there a way to setup the server/client with a bigger timeout so it will not disconnect easily
This is for developent purposes - it is preferable we avoid such disconnections when we (for example) use breakpoints or pause the editor.
27 Replies
Hi @Niv. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Yes, you can prevent automatic disconnections during development when using breakpoints or pausing the editor in Normcore. The
BumpAutoDisconnectTime() method is available for this purpose.
When developing with Normcore, the server pings connected clients every five seconds to check their connection status. If a client doesn't respond (which happens when you're paused in a breakpoint), the server will disconnect them after about five seconds as mentioned in the Architecture > Common Questions documentation.
To prevent this during development, you can call the BumpAutoDisconnectTime() method on the client. This method is available on the native client implementations as shown in the Reference > Classes > IClient, Client, and OfflineClient documentation.
You would need to call this method periodically to keep the connection alive during debugging sessions. You could set up a system that calls this method at regular intervals during development builds to prevent timeouts when you're paused in the editor.
Note that this is specifically for development purposes, and in production, the default timeout behavior helps ensure that crashed clients are properly cleaned up from the room.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@269927864265211906> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai - but when a breakpoint in code is hit, there's no way to periodically call BumpAutoDisconnectTime()
Let me check the knowledge base for you again. One moment! :books:
----------------------
You're absolutely right. When a breakpoint is hit, code execution is paused, so there's no way to periodically call
BumpAutoDisconnectTime() during that pause.
For development scenarios where you're using breakpoints, there are a few alternative approaches you might consider:
1. You could temporarily use an offline mode for development and debugging. Normcore provides an OfflineClient that doesn't require a connection to a server.
2. For debugging specific functionality, you might set up your debugging environment to run with a local room server if possible, which would give you more control over the timeout settings.
3. Another approach is to structure your debugging sessions to be aware of the timeout limitation - for example, by setting breakpoints strategically and resuming execution before the timeout occurs.
Unfortunately, the knowledge sources don't provide a direct solution for extending the server timeout specifically during breakpoint pauses. The fundamental issue is that when execution is paused at a breakpoint, no code can run to keep the connection alive.
If this is a significant issue for your development workflow, you might want to reach out to the Normcore community on their Discord for additional suggestions or workarounds that other developers might be using.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@269927864265211906> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
offline mode works like online mode 99% of the time except it connects immediately but otherwise it's a good way to test
I agree, but how would you get multiple players scenarios tested this way?
This has been an annoyance for me as well but I've made due mostly with log debugging, which in a lot of cases works better than breakpoints anyway, especially for VR development.
We’ve got a bug fix in the works for this. The server will time you out no matter what, but in an upcoming update pausing at a breakpoint will work and it will maintain your connection to the server
@fgamez1020 ☝️
💯
@Normcore Assistant write out the exact steps to implemenitng BumpAutoDisconnectTime() -- is it on the Realtime instance? i dont see it
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on the knowledge sources, I can explain how to implement
BumpAutoDisconnectTime(). This method isn't directly exposed on the Realtime instance, but rather exists on the underlying native client implementation.
The BumpAutoDisconnectTime() method is available on the native client implementations as shown in the documentation for IClient, Client, and OfflineClient.
To access this method, you would need to:
1. Get a reference to the Room instance from your Realtime component
2. Access the underlying native client from the Room
3. Call the BumpAutoDisconnectTime() method on that client
However, the knowledge sources don't provide the exact code to access the native client from the Room instance. The Room class is described as managing "everything related to a room, including the connection to the room server" as mentioned in the Room documentation, but the specific API to access the native client isn't detailed in the provided knowledge sources.
Since I don't have the exact implementation details from the knowledge sources, I recommend:
1. Check the Normcore API documentation for Room class to see if there's a public property or method to access the native client
2. Alternatively, reach out to Normcore support or their Discord community for the specific implementation details
I apologize that I can't provide the exact code implementation based on the available knowledge sources.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@412870643533479936> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
It’s not a setting you can change, but we’ve implemented a fix so that the disconnect timeout is disabled when attaching a debugger
i see. i was hoping i could set the timeout to 10 seconds in prod since sometimes players take off their headset for 5 seconds to respond to their parents or something
the feature is done internally but I expect it will ship in 3-4 weeks in one of our larger releases
let's goooo 🔥
that should work fine. the timeout is 60 seconds. The 5 second timeout is actually on the server side and only triggers if not receiving packets. When you take your headset off the app should still keep the network thread alive to talk to the server
ok, and no way to up it from 60?
I think the only cases where it doesn’t is when the battery is very low or Run In Background is set to false
(idk why id want to but kyle wants to haha)
afaik 60 is the Meta requirement for VRCs but also in practice the headset pauses the whole process before you hit a full minute and at that point there’s nothing we can do
okay i'll tell kyle that ty!
we’ve also got an auto-reconnect component in the works
I expect that to ship not too long after these fixes go out
sweeeet, hopefully this'll do the trick until then:
void OnEnable()
{
OVRManager.HMDMounted += HandleHMDMounted;
OVRManager.HMDUnmounted += HandleHMDUnmounted;
}
void OnDisable()
{
OVRManager.HMDMounted -= HandleHMDMounted;
OVRManager.HMDUnmounted -= HandleHMDUnmounted;
}
private void HandleHMDMounted()
{
Debug.LogError("Headset put on");
if (realtime != null && !realtime.connected)
{
Debug.LogError("Reconnecting to Normcore…");
realtime.Connect(realtime.roomToJoinOnStart);
}
else
{
Debug.LogError("Already connected to Normcore HMD mounted");
}
}looks good