When debug setting to disable neighbouring regions is enabled, the viewer now makes an exception and function pauses itself while the avatar is physically out of bounds of the current region (negative pos, or pos bigger than max region size) indicating a possible region crossing (or grid error). This allows neighbouring regions to load during manual region crossings instead of leaving the user flying into the void.
The option still prevents neighbour connections under normal circumstances as intended. However, with this adjustment, region crossings are at least partially possible in most cases, though still not as seamless as with full neighbour connections enabled.
- An experimental and not officially supported function (therefore not exposed in preferences), may or may not stay in the source; Potentially addresses FIRE-2325 and its duplicates
- Prevents the viewer from connecting to neighbouring regions. When enabled, only the current region (login/teleport destination) is connected, while adjacent simulators are ignored. This effectively isolates the region, similar to how private estates behave.
- This may improve performance for users with weaker computers or slower connections, reduce unintended neighbour interactions, and assist multi-region event setups by lowering client overhead. It can also be useful for residents who prefer not to see or interact with neighbouring land.
- Limitations: region crossings will not function normally, as neighbouring regions are not visible or connected. Only direct teleports and logins to regions will work reliably. The sense of world scale and continuity is reduced, and travellers or explorers may find it unsuitable.
- TO-DO: Detect when avatar is crossing by foot/vehicle and load only that one region?
- I was not able to find an equivalent of WebRTC's updateNeighboringRegions() in Vivox code; updatePosition() is not that helpful, and channelFromRegion() seems to be detached?
- This ensures restored sessions are available immediately after the viewer boots, instead of only being added when the Conversations floater is opened.
- It also prevents issues where sessions fail to populate properly if the Conversations floater remains closed at startup and the user starts an IM directly from a profile or the People panel.
- Only resident-to-resident conversations are restored. Group chat sessions were not always ready in time ("unverified") during startup, making their restoration unreliable.
- Clean up some debug code / leftovers.
Ansariel