Uploaded image for project: 'Firestorm'
  1. Firestorm
  2. FIRE-11593

[OPENSIM] Unable to teleport more than 4096 regions away.

    Details

    • Type: Bug
    • Status: Passed QA
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: Phoenix Firestorm 4.4.2
    • Fix Version/s: Phoenix Firestorm 4.5.0
    • Component/s: Other Grids
    • Labels:
    • Environment:
      OpenSim
    • Reported In:
      Firestorm 4.4.2.34167 Release

      Description

      The issue is described here, at length: http://metaverseink.com/blog/?p=222
      The workaround is that grids have to run extra regions, placing them at map coordinates that allow them to get closer to their destinations. These are used as waypoints. We'd rather not have to run them them and be able to jump from any coordinate to any coordinate.

      1. 4096-fs-ver.patch
        4 kB
        Latif Khalifa

        Issue Links

          Activity

          Hide
          tonya Tonya Souther added a comment -

          This was originally reported as SVC-2941. It was also reported on Imprudence's web tracker as bug 465. The naive fix in patches attached to both entries turned out to have problems with losing the ability to rez objects up close after teleporting.

          Show
          tonya Tonya Souther added a comment - This was originally reported as SVC-2941 . It was also reported on Imprudence's web tracker as bug 465 . The naive fix in patches attached to both entries turned out to have problems with losing the ability to rez objects up close after teleporting.
          Hide
          tonya Tonya Souther added a comment -

          Candidate fix committed as Mercurial 37936 (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c83a5e68ecdd).

          This is definitely a candidate fix, and needs thorough testing not just in long teleports but regular use as well. Previous attempts at fixing this issue by not shifting the spatial partitions at all caused problems with objects not rezzing after teleporting, getting worse as the session continued. We need to test this fix to make sure that problem does not happen here as well, and if so, then that change should be backed out.

          Show
          tonya Tonya Souther added a comment - Candidate fix committed as Mercurial 37936 ( http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c83a5e68ecdd ). This is definitely a candidate fix, and needs thorough testing not just in long teleports but regular use as well. Previous attempts at fixing this issue by not shifting the spatial partitions at all caused problems with objects not rezzing after teleporting, getting worse as the session continued. We need to test this fix to make sure that problem does not happen here as well, and if so, then that change should be backed out.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Tonya, I'm going to resolve this so it drops over to QA. Can be reopened if side effects are seen.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Tonya, I'm going to resolve this so it drops over to QA. Can be reopened if side effects are seen.
          Hide
          tonya Tonya Souther added a comment -

          It should also be noted that this change should not affect Second Life at all, or OpenSim teleports of less than 4096 regions distance in either axis. OpenSim must be configured to permit teleports of longer than 4096 regions. To do so, add the following lines to OpenSim.ini:

          [EntityTransfer]
              ;; Teleport options
              ;; Allow greater than 4095 maximum regions to teleport between
              max_distance = 10000
          
          Show
          tonya Tonya Souther added a comment - It should also be noted that this change should not affect Second Life at all, or OpenSim teleports of less than 4096 regions distance in either axis. OpenSim must be configured to permit teleports of longer than 4096 regions. To do so, add the following lines to OpenSim.ini: [EntityTransfer] ;; Teleport options ;; Allow greater than 4095 maximum regions to teleport between max_distance = 10000
          Hide
          lkalif Latif Khalifa added a comment - - edited

          This can be tested on OSGrid, jumping between "Sandbox Plaza" and "jump4000" regions. Restrictions are removed there.

          Observed: patch works for objects, but water surrounding the region goes missing after the long jump. The water in the destination region is fine, but the surrounding void space is not.

          (Edit: This was tested with patch applied to Singularity, not Firestorm itself, don't know if the same issue will repro there)

          Edit2: it seems that with long hypergrid jumps, water goes missing completely
          Tester hypergrid jumping between OSGrid jump4000 region and Conference grid Breakout Zone 1

          • cc.opensimulator.org:8002:Breakout Zone 1
          • hg.osgrid.org:80:jump4000
          Show
          lkalif Latif Khalifa added a comment - - edited This can be tested on OSGrid, jumping between "Sandbox Plaza" and "jump4000" regions. Restrictions are removed there. Observed: patch works for objects, but water surrounding the region goes missing after the long jump. The water in the destination region is fine, but the surrounding void space is not. (Edit: This was tested with patch applied to Singularity, not Firestorm itself, don't know if the same issue will repro there) Edit2: it seems that with long hypergrid jumps, water goes missing completely Tester hypergrid jumping between OSGrid jump4000 region and Conference grid Breakout Zone 1 cc.opensimulator.org:8002:Breakout Zone 1 hg.osgrid.org:80:jump4000
          Hide
          nickyd Nicky added a comment -

          I browsed around the source a bit and this is unfortunately not a correct fix

          This change works by slamming the affected spatial partitions (and octrees) somewhere on the map.
          Those get shifted around as the avatar TPs over the grid, adjusting to the current region cell. If they get moved somewhere, this will be be causing a mismatch between real world coordinates and coordinates where the octree/spatial partions are.
          Worse even, when the avi moves, the shift can be positive or negative. This change only ever causes a positive change when the distance is too big. The trees/partitions never get moved back again.
          Then one can move diagonal, eg [2^20, 4096, 8192]. This change will then shift the underlying octrees/groups to [256*4095,265*4095,256*4095]. (Moving in a diagonal way from top left to bottom right might even make this kick in on SL, as the patch uses the lenght of the offset, which is sqrt(x^2+y^2+z^2)

          By moving around enough, it's easy to manage to end up with structures messed up enough to miss prims and terrain again. I am pretty sure it's possible to overlap octress of two regions this way too. (Put your regions in one row, 3 adjacent, then a long jump gap, then 3 more. If you hope around clever enough, you'll end with mixed octrees.

          The good news is, that I am confident that I traced it down to it's root. I will therefor revert the old change (sorry Tonya) and put something else in.

          Show
          nickyd Nicky added a comment - I browsed around the source a bit and this is unfortunately not a correct fix This change works by slamming the affected spatial partitions (and octrees) somewhere on the map. Those get shifted around as the avatar TPs over the grid, adjusting to the current region cell. If they get moved somewhere, this will be be causing a mismatch between real world coordinates and coordinates where the octree/spatial partions are. Worse even, when the avi moves, the shift can be positive or negative. This change only ever causes a positive change when the distance is too big. The trees/partitions never get moved back again. Then one can move diagonal, eg [2^20, 4096, 8192] . This change will then shift the underlying octrees/groups to [256*4095,265*4095,256*4095] . (Moving in a diagonal way from top left to bottom right might even make this kick in on SL, as the patch uses the lenght of the offset, which is sqrt(x^2+y^2+z^2) By moving around enough, it's easy to manage to end up with structures messed up enough to miss prims and terrain again. I am pretty sure it's possible to overlap octress of two regions this way too. (Put your regions in one row, 3 adjacent, then a long jump gap, then 3 more. If you hope around clever enough, you'll end with mixed octrees. The good news is, that I am confident that I traced it down to it's root. I will therefor revert the old change (sorry Tonya) and put something else in.
          Hide
          nickyd Nicky added a comment -
          Show
          nickyd Nicky added a comment - Here we go http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/cfb3477832f5
          Hide
          tonya Tonya Souther added a comment - - edited

          Nicky's fix worked fine in testing, both my cases (Littlefield Grid, regions LF2000, LF9000, and Littlefield Hangout/Welcome/Mall) and Latif's.

          Hypergrid teleports get crashes after doing several for me, but I'm fairly sure that's a different problem.

          Show
          tonya Tonya Souther added a comment - - edited Nicky's fix worked fine in testing, both my cases (Littlefield Grid, regions LF2000, LF9000, and Littlefield Hangout/Welcome/Mall) and Latif's. Hypergrid teleports get crashes after doing several for me, but I'm fairly sure that's a different problem.
          Hide
          lkalif Latif Khalifa added a comment -

          Tested the new fix. No issues encountered so far!

          Tonya, Nicky, thank you very much for looking into this! This was really bugging opensim grids for years.

          Show
          lkalif Latif Khalifa added a comment - Tested the new fix. No issues encountered so far! Tonya, Nicky, thank you very much for looking into this! This was really bugging opensim grids for years.
          Hide
          lkalif Latif Khalifa added a comment -

          So it turns out that Opensim region contain some prims in corrupted positions that causes crashes. Also sometimes sends prim positions that are NaN or INF. So instead of compeltely removing the check I changed the line:

          MAX_MAG.splat(1024.f*1024.f);

          to

          MAX_MAG.splat(32767.f * 256.f);

          increasing max jump from 4K to 32K sims.

          Talking to Opensim devs, they said that they would introduce a configuration limit where you would not be able to place a region at coordinates higher than 16K so this change should be adequate.

          Example of a sim that crashes the viewer with the current patch is Perun on OSGrid.

          (again tested with Singularity, apologies if it does not apply to Firestorm)

          Show
          lkalif Latif Khalifa added a comment - So it turns out that Opensim region contain some prims in corrupted positions that causes crashes. Also sometimes sends prim positions that are NaN or INF. So instead of compeltely removing the check I changed the line: MAX_MAG.splat(1024.f*1024.f); to MAX_MAG.splat(32767.f * 256.f); increasing max jump from 4K to 32K sims. Talking to Opensim devs, they said that they would introduce a configuration limit where you would not be able to place a region at coordinates higher than 16K so this change should be adequate. Example of a sim that crashes the viewer with the current patch is Perun on OSGrid. (again tested with Singularity, apologies if it does not apply to Firestorm)
          Hide
          aiaustin Ai Austin added a comment - - edited

          So are we all going to converge on [EntityTransfer] max_distance = 16383 and that become the default in OpenSimDefaults.ini? There is also a 4096 related checkitem in Robust.[HG].ini which will need to be set to False to not check for link region distances aparts.

          I have observed viewer crashes on regions when avatar attachments (like hair or AO HUD items) somehow end up at 0,0,0 and if you try to edit them to remove them. They have very peculiar properties that state they are of type attachment (as seen in Kirstens S19 object editor which is the only viewer I have found that does not crash when editing) rather than a normal prim.

          See http://opensimulator.org/mantis/view.php?id=6749

          Show
          aiaustin Ai Austin added a comment - - edited So are we all going to converge on [EntityTransfer] max_distance = 16383 and that become the default in OpenSimDefaults.ini? There is also a 4096 related checkitem in Robust. [HG] .ini which will need to be set to False to not check for link region distances aparts. I have observed viewer crashes on regions when avatar attachments (like hair or AO HUD items) somehow end up at 0,0,0 and if you try to edit them to remove them. They have very peculiar properties that state they are of type attachment (as seen in Kirstens S19 object editor which is the only viewer I have found that does not crash when editing) rather than a normal prim. See http://opensimulator.org/mantis/view.php?id=6749
          Hide
          nickyd Nicky added a comment -

          Latif, thank you for your research and input.

          Also sometimes sends prim positions that are NaN or INF. So instead of compeltely removing the check I changed the line:

          This sounds quite nasty. It might be best to filter those out before they get used and fed into the viewer.

          MAX_MAG.splat(32767.f * 256.f);

          Also please keep in mind, that this is already stretching it. There is hardly much precision left for any octree subdivisions and partitions. Considering this is all IEEE754 in single precision, that's dangerous close.

          I am planning to use the old limit for SL and yours for OpenSim. With proper credits of course. Thank you again.

          Show
          nickyd Nicky added a comment - Latif, thank you for your research and input. Also sometimes sends prim positions that are NaN or INF. So instead of compeltely removing the check I changed the line: This sounds quite nasty. It might be best to filter those out before they get used and fed into the viewer. MAX_MAG.splat(32767.f * 256.f); Also please keep in mind, that this is already stretching it. There is hardly much precision left for any octree subdivisions and partitions. Considering this is all IEEE754 in single precision, that's dangerous close. I am planning to use the old limit for SL and yours for OpenSim. With proper credits of course. Thank you again.
          Hide
          lkalif Latif Khalifa added a comment -

          I understand that we are pushing a limit on float precision here. But short of re-writing a lot of octree logic I think it's the best option we have so far.

          Or perhaps to investigate the possibility of changing the origin of the whole octree on long jumps and simply discard everything and recreate the whole tree after those jumps.

          Show
          lkalif Latif Khalifa added a comment - I understand that we are pushing a limit on float precision here. But short of re-writing a lot of octree logic I think it's the best option we have so far. Or perhaps to investigate the possibility of changing the origin of the whole octree on long jumps and simply discard everything and recreate the whole tree after those jumps.
          Hide
          tonya Tonya Souther added a comment - - edited

          I would expect, personally, that the max transfer distance code in the simulator itself would be removed or disabled by default, now that we know what the problem is and will be releasing viewers with the fix in them. (FWIW, I see no problems with Latif's version of the fix.) The sim limit was a workaround for a viewer bug, anyway.

          If the region coordinate limit is set to 16K, that would suffice, especially since that allows 256M regions - far more than you'd ever expect to find on one grid.)

          My version of the fix assumed that old octrees were pruned after a teleport. That's what I'd seen in my testing of the code, but apparently it doesn't happen all the time. It might be worthwhile to actually prune octrees that are well out of draw distance; keeping them around indefinitely sounds like a classic memory leak.

          As for prims with positions that are NaN or infinite, that sounds like a simulator bug to me. We should probably check that on getting the objects loaded from the sim and discard those with invalid positions such as that.

          Show
          tonya Tonya Souther added a comment - - edited I would expect, personally, that the max transfer distance code in the simulator itself would be removed or disabled by default, now that we know what the problem is and will be releasing viewers with the fix in them. (FWIW, I see no problems with Latif's version of the fix.) The sim limit was a workaround for a viewer bug, anyway. If the region coordinate limit is set to 16K, that would suffice, especially since that allows 256M regions - far more than you'd ever expect to find on one grid.) My version of the fix assumed that old octrees were pruned after a teleport. That's what I'd seen in my testing of the code, but apparently it doesn't happen all the time. It might be worthwhile to actually prune octrees that are well out of draw distance; keeping them around indefinitely sounds like a classic memory leak. As for prims with positions that are NaN or infinite, that sounds like a simulator bug to me. We should probably check that on getting the objects loaded from the sim and discard those with invalid positions such as that.
          Hide
          aiaustin Ai Austin added a comment -

          Good point about the removal of OpenSim server side code and limitations on teleport... much cleaner.

          Show
          aiaustin Ai Austin added a comment - Good point about the removal of OpenSim server side code and limitations on teleport... much cleaner.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Just making a note of some coordinate weirdness that Tonya & Cinders have seen after TPing about on Agni which I suspect is caused by the rev 38034 fix.

          • [13:26] Second Life: Teleport completed from Olive-141/-8/1922
          Show
          whirly.fizzle Whirly Fizzle added a comment - Just making a note of some coordinate weirdness that Tonya & Cinders have seen after TPing about on Agni which I suspect is caused by the rev 38034 fix. You are at -291046.0, -68309.4, 4005.1 in Raindown located at sim10108.agni.lindenlab.com (216.82.48.174:13021) SLURL: http://maps.secondlife.com/secondlife/Raindown/-230/-213/4005 [13:26] Second Life: Teleport completed from Olive-141/-8/1922
          Hide
          lkalif Latif Khalifa added a comment -

          After some more testing (thanks to Opensim devs and testers), some weird effects were noticed, like prims disappearing when rotating around on sims that have extreme positions. Simimilary on region "Forum" on SL same effects were noticed sometimes leading to crashes. It looks like the octree wants the range limit to be power of two. So I change it in Singularity to:

          MAX_MAG.splat(4096.f * 4096.f);

          which seems to remove ill side effect. I know that for Firestorm this will be ifdeffed out on SL so it won't affect users there.

          Show
          lkalif Latif Khalifa added a comment - After some more testing (thanks to Opensim devs and testers), some weird effects were noticed, like prims disappearing when rotating around on sims that have extreme positions. Simimilary on region "Forum" on SL same effects were noticed sometimes leading to crashes. It looks like the octree wants the range limit to be power of two. So I change it in Singularity to: MAX_MAG.splat(4096.f * 4096.f); which seems to remove ill side effect. I know that for Firestorm this will be ifdeffed out on SL so it won't affect users there.
          Hide
          aiaustin Ai Austin added a comment - - edited

          Just to be clear...I think some of us use the Opensim compiled version for everything including Second Life access... so its best NOT to assume that OpenSim orientated Firestorm users accessing Second Life will use a different version of the viewer when accessing SL.

          Show
          aiaustin Ai Austin added a comment - - edited Just to be clear...I think some of us use the Opensim compiled version for everything including Second Life access... so its best NOT to assume that OpenSim orientated Firestorm users accessing Second Life will use a different version of the viewer when accessing SL.
          Hide
          nickyd Nicky added a comment -

          Thank you again Latif (I was just changing our version, good luck I looked here before)

          Ai, it will be in the version that can be used to access OpenSim and SL. But not the one that is SL only. Though maybe later it might be changed that it only even kicks in when connected to a non LL grid.

          Show
          nickyd Nicky added a comment - Thank you again Latif (I was just changing our version, good luck I looked here before) Ai, it will be in the version that can be used to access OpenSim and SL. But not the one that is SL only. Though maybe later it might be changed that it only even kicks in when connected to a non LL grid.
          Hide
          cinderblocks Cinder Biscuits added a comment -

          Crash related to the fix after a teleport in Second Life,

          Thread 0:: Dispatch queue: com.apple.main-thread
          0 com.phoenixviewer.firestorm.viewer-oss 0x00bdfe7c LLSpatialGroup::rebound() + 40
          1 com.phoenixviewer.firestorm.viewer-oss 0x00bdff45 LLSpatialGroup::rebound() + 241
          2 com.phoenixviewer.firestorm.viewer-oss 0x00bdfefe LLSpatialGroup::rebound() + 170
          3 com.phoenixviewer.firestorm.viewer-oss 0x00bdfefe LLSpatialGroup::rebound() + 170
          4 com.phoenixviewer.firestorm.viewer-oss 0x00419996 LLSpatialBridge::updateSpatialExtents() + 158
          5 com.phoenixviewer.firestorm.viewer-oss 0x00be4f12 LLSpatialGroup::updateInGroup(LLDrawable*, int) + 26
          6 com.phoenixviewer.firestorm.viewer-oss 0x00bdb294 LLSpatialPartition::move(LLDrawable*, LLSpatialGroup*, int) + 404
          7 com.phoenixviewer.firestorm.viewer-oss 0x004196b5 LLSpatialBridge::updateMove() + 1135
          8 com.phoenixviewer.firestorm.viewer-oss 0x01063b0d LLPipeline::updateMovedList(std::vector<LLPointer<LLDrawable>, std::allocator<LLPointer<LLDrawable> > >&) + 87
          9 com.phoenixviewer.firestorm.viewer-oss 0x01064098 LLPipeline::updateGeom(float) + 924
          10 com.phoenixviewer.firestorm.viewer-oss 0x00d2dc7e display(int, float, int, int) + 7374
          11 com.phoenixviewer.firestorm.viewer-oss 0x00329080 LLAppViewer::mainLoop() + 3718
          12 com.phoenixviewer.firestorm.viewer-oss 0x0110ff38 runMainLoop() + 40
          13 com.phoenixviewer.firestorm.viewer-oss 0x01110e03 -[LLAppDelegate mainLoop] + 19

          Show
          cinderblocks Cinder Biscuits added a comment - Crash related to the fix after a teleport in Second Life, Thread 0:: Dispatch queue: com.apple.main-thread 0 com.phoenixviewer.firestorm.viewer-oss 0x00bdfe7c LLSpatialGroup::rebound() + 40 1 com.phoenixviewer.firestorm.viewer-oss 0x00bdff45 LLSpatialGroup::rebound() + 241 2 com.phoenixviewer.firestorm.viewer-oss 0x00bdfefe LLSpatialGroup::rebound() + 170 3 com.phoenixviewer.firestorm.viewer-oss 0x00bdfefe LLSpatialGroup::rebound() + 170 4 com.phoenixviewer.firestorm.viewer-oss 0x00419996 LLSpatialBridge::updateSpatialExtents() + 158 5 com.phoenixviewer.firestorm.viewer-oss 0x00be4f12 LLSpatialGroup::updateInGroup(LLDrawable*, int) + 26 6 com.phoenixviewer.firestorm.viewer-oss 0x00bdb294 LLSpatialPartition::move(LLDrawable*, LLSpatialGroup*, int) + 404 7 com.phoenixviewer.firestorm.viewer-oss 0x004196b5 LLSpatialBridge::updateMove() + 1135 8 com.phoenixviewer.firestorm.viewer-oss 0x01063b0d LLPipeline::updateMovedList(std::vector<LLPointer<LLDrawable>, std::allocator<LLPointer<LLDrawable> > >&) + 87 9 com.phoenixviewer.firestorm.viewer-oss 0x01064098 LLPipeline::updateGeom(float) + 924 10 com.phoenixviewer.firestorm.viewer-oss 0x00d2dc7e display(int, float, int, int) + 7374 11 com.phoenixviewer.firestorm.viewer-oss 0x00329080 LLAppViewer::mainLoop() + 3718 12 com.phoenixviewer.firestorm.viewer-oss 0x0110ff38 runMainLoop() + 40 13 com.phoenixviewer.firestorm.viewer-oss 0x01110e03 - [LLAppDelegate mainLoop] + 19
          Hide
          cinderblocks Cinder Biscuits added a comment -

          Immediate crashing when editing objects and attachments at high altitudes in both Second Life and OSGrid. Doesn't seem to matter which region it happens in here. Crashes too hard for Xcode to get a stack, but backing out the LLOctree changes fix the regression so I'm almost certain that's the cause.

          Show
          cinderblocks Cinder Biscuits added a comment - Immediate crashing when editing objects and attachments at high altitudes in both Second Life and OSGrid. Doesn't seem to matter which region it happens in here. Crashes too hard for Xcode to get a stack, but backing out the LLOctree changes fix the regression so I'm almost certain that's the cause.
          Hide
          smxy Shaun (smxy) Emerald added a comment -

          I'm sure he'll pass it along soon, but Latif came up with an entirely different fix for this, last night, that has so far passed every test. Several of us are in the "I jumped to 1000000,1000000!" club. There might not even be a limit, at this point.

          Show
          smxy Shaun (smxy) Emerald added a comment - I'm sure he'll pass it along soon, but Latif came up with an entirely different fix for this, last night, that has so far passed every test. Several of us are in the "I jumped to 1000000,1000000!" club. There might not even be a limit, at this point.
          Hide
          lkalif Latif Khalifa added a comment -

          I think I managed to track down the core of this problem. Each region has a set of spatial partitions where viewer keeps track of objects in a octrees. Octree is a data structure suitable for easy sorting and finding objects in 3D space (http://en.wikipedia.org/wiki/Octree).

          After a teleport the viewer shifts the origin of these spatial partitions relative to the position of the avatar. The problem arises with the fact that at the moment the shift occurs, the destination region is already created and it's octrees get shifted too. If the jump was far enough, when the objects start coming in from the new region, the viewer tries to put them into its spatial partitions, but the origin is now so far, it exceeds the maximum range of the partition.

          The first stab at the solution was to disable shifting, but that causes all sorts of issues with now incorrect data being tracked inside the viewer. The second attempt was to increase a range of the octree so 4096 limit would become 16384, or 65536. But this also has problems, namely viewer crashes with the extended octree.

          My candidate solution is to recreate the spatial partitions in the destination region after the agent is placed in the region, and after we detect that there has been a long jump. This has the effect of leaving the maximum range of octree unmodified which means that as far as the viewer is concerned there is nothing different in the code on both OpemSim and SL if it was a plain region crossing or "normal" distance teleport.

          This means that the origin of spatial partitions would be the destination sim so the limit on teleport length is practically removed.

          The issues I encountered was that the viewer would still try to update the geometry in the regions that were left behind, but due to the floating point errors at those distances would fail to place them properly inside the octree structure, and crash. Which is why I mark all objects in the regions left behind dead and that I removed the check from octree when it fails to insert an object, and just ignore it. Again this has no effect on "normal" teleports.

          I'm trying to push the patch to a Bitbucket clone of Firestorm repo, bit Bitbucket is not happy with that much source it seems so I'm attaching old fashioned patch here. In case Bitbucket accepts the push, I will post the link here for easy merging.

          Show
          lkalif Latif Khalifa added a comment - I think I managed to track down the core of this problem. Each region has a set of spatial partitions where viewer keeps track of objects in a octrees. Octree is a data structure suitable for easy sorting and finding objects in 3D space ( http://en.wikipedia.org/wiki/Octree ). After a teleport the viewer shifts the origin of these spatial partitions relative to the position of the avatar. The problem arises with the fact that at the moment the shift occurs, the destination region is already created and it's octrees get shifted too. If the jump was far enough, when the objects start coming in from the new region, the viewer tries to put them into its spatial partitions, but the origin is now so far, it exceeds the maximum range of the partition. The first stab at the solution was to disable shifting, but that causes all sorts of issues with now incorrect data being tracked inside the viewer. The second attempt was to increase a range of the octree so 4096 limit would become 16384, or 65536. But this also has problems, namely viewer crashes with the extended octree. My candidate solution is to recreate the spatial partitions in the destination region after the agent is placed in the region, and after we detect that there has been a long jump. This has the effect of leaving the maximum range of octree unmodified which means that as far as the viewer is concerned there is nothing different in the code on both OpemSim and SL if it was a plain region crossing or "normal" distance teleport. This means that the origin of spatial partitions would be the destination sim so the limit on teleport length is practically removed. The issues I encountered was that the viewer would still try to update the geometry in the regions that were left behind, but due to the floating point errors at those distances would fail to place them properly inside the octree structure, and crash. Which is why I mark all objects in the regions left behind dead and that I removed the check from octree when it fails to insert an object, and just ignore it. Again this has no effect on "normal" teleports. I'm trying to push the patch to a Bitbucket clone of Firestorm repo, bit Bitbucket is not happy with that much source it seems so I'm attaching old fashioned patch here. In case Bitbucket accepts the push, I will post the link here for easy merging.
          Hide
          lkalif Latif Khalifa added a comment -

          You can pull this patch from:

          https://bitbucket.org/lkalif/firestorm-fire-11593

          For testing you could use following OSGrid regions:

          • jump4000
          • Sandbox Plaza
          • OKC Tower
          • Far55

          If you want to try a million region jump, teleport to OSGrid region Sisyphus or Far55 and HG jump to:

          • sanctuary.homelinux.org:8012:OneMillion
          Show
          lkalif Latif Khalifa added a comment - You can pull this patch from: https://bitbucket.org/lkalif/firestorm-fire-11593 For testing you could use following OSGrid regions: jump4000 Sandbox Plaza OKC Tower Far55 If you want to try a million region jump, teleport to OSGrid region Sisyphus or Far55 and HG jump to: sanctuary.homelinux.org:8012:OneMillion
          Hide
          cinderblocks Cinder Biscuits added a comment -

          Patch added in Rev 38061 (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/82041010f8a7)

          Tested this for about 45 minutes so far, and it works like a champ! Thanks so much for the fix, and now I've joined the million hoppers club too.

          Show
          cinderblocks Cinder Biscuits added a comment - Patch added in Rev 38061 ( http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/82041010f8a7 ) Tested this for about 45 minutes so far, and it works like a champ! Thanks so much for the fix, and now I've joined the million hoppers club too.
          Hide
          smxy Shaun (smxy) Emerald added a comment -

          Due to the fact that the map is limited, by protocol spec, to 64K, x and y, 65535,65535 is really the highest any region should be placed at. If you go higher than that, the map cannot return the map tile for the region and you cannot teleport to it, locally, other than via a landmark.

          Show
          smxy Shaun (smxy) Emerald added a comment - Due to the fact that the map is limited, by protocol spec, to 64K, x and y, 65535,65535 is really the highest any region should be placed at. If you go higher than that, the map cannot return the map tile for the region and you cannot teleport to it, locally, other than via a landmark.

            People

            • Assignee:
              cinderblocks Cinder Biscuits
              Reporter:
              smxy Shaun (smxy) Emerald
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: