|Anonymous | Login | Signup for a new account||2019-10-14 17:07 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004920||opensim||[GRID] Hypergrid||public||2010-08-05 05:47||2015-08-17 12:01|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0004920: HG1.5 link-region fails with "Region is too far" even when some regions in OpenSim.exe instance are in range|
|Description||We have a grid centred at 1000,1000, and intended to set up hypergrid jump points to allow for reaching grids centred beyond the 4K,4K jump distance permitted. Similar to Gateway 3000 and Gateway 7000 was on the HG1.0 based UCI Grid.|
We have regions: Vue-5000 at 5000,5000 and Vue-9000 at 9000,9000
We find we cannot use the usual methods of giving a hypergrid location (in chat, via objects, via the map, etc.).
Trying a link-region command in both Robust.exe, and in OpenSim.exe when we have change-region to the in range region also fails.
Could it be that the root region (1000,1000?) is beign used for the tests rather than checking is ANY region on the grid (presumably in any OpensSim.exe that as a connection) is in range?
E.g. when at our region at 5000,5000 we tried to link to Germangrid location at 8001,8000 and it fails.
Region (root) # change region Vue-5000
Currently selected region is Vue-5000
Region (Vue-5000) # link-region 5002 5000 dev.germangrid.de:8002:
13:37:07 - [HYPERGRID LINKER]: Link to dev.germangrid.de:8002:, in 1280512-1280000
13:37:07 - [HYPERGRID LINKER]: Successfully linked to region_uuid 74ae01fc-e9c0-4580-8b4b-fe4c0726659b
13:37:07 - [HYPERGRID LINKER]: Unable to link, region is too far (8001, 8000)
Failed to link region: Region is too far (8001, 8000)
|Additional Information||Note this grid worked fine for jumps to German Grid test grid when they had a location within range of 1000,1000. And others have sucecessfully linked to and hypergrid teleported to Openvue at 1000,1000.|
Hypergrid locations are:
secondlife://virtual.aiai.ed.ac.uk:8002:Openvue [^] (at 1000,1000)
secondlife://virtual.aiai.ed.ac.uk:8002:Vue-5000 [^] (at 5000,5000)
secondlife://virtual.aiai.ed.ac.uk:8002:Vue-9000 [^] (at 9000,9000)
|Tags||No tags attached.|
|Git Revision or version number||0.7 post-fixes|
|Run Mode||Grid (Multiple Regions per Sim)|
|Physics Engine||BasicPhysics, ODE|
|Environment||Unknown, .NET / Windows32|
|Attached Files|| 0001-Disable-4096-range-check.patch [^] (1,543 bytes) 2010-08-05 23:51 [Show Content]
0001-Allow-creation-of-link-regions.patch [^] (12,300 bytes) 2010-08-05 23:52 [Show Content]
|Yes. That's the current implementation.|
Oh. Diva, I assume that means we not have a way any more to traverse via Gateway regions. HG1.5 locations would all have be be clustered within 4K of one another to work. I think we are spead out across 12K and more in some grids. But we used to get across grids via suitably positioned intermediate regions to jump via as we did with the UCI grid gateways, and similar ones we us on New World Grid to get from openmvue grid to their main areas on HG1.0.
Is there some part of the server side that stops the link-region working - or is it a check that is being over zealous at the moment. Because if we are at 5000,5000, we should definitely be able to jump to other grids at 7000,7000 and 8000,8000 as I would assume the viewers would allow that, so long as the server had allowed the link to be made. Or is this technically wrong?
|it's nothing foundational, it's probably me just not having had time to go beyond this simplistic approach. I bet Marck could provide a patch... hello, Marck? :-)|
There is an explicit check for this 4096 regions limit in OpenSim.Services.GridService.HypergridLinker. In my opinion, this check in OpenSim is pretty useless. It restricts grid owners and residents and does not prevent the known viewer issue. See the following scenario:
- Home grid is centered at 5000,5000 but extends to 6000,5000
- Home grid does a successful link-region to foreign grid centered at 1500,1500
- A home grid resident in a region at 6000,5000 attempts hypergrid teleport to foreign grid via the linked region
Result: The viewer has the same issues as if that check was not in OpenSim.
My vote goes to the removal of that check. This is my reason for providing patch 0001-Disable-4096-range-check.patch.
As an alternative, 0001-Allow-creation-of-link-regions.patch allows the creation of link regions if there can be found an existing region within the 4096 range. A side effect of this patch is the addition of method GetHyperlinks() to the grid service.
It is possible to apply both patches which will do both: add GetHyperlinks() to the grid service and disable the range check.
|I would very much like to see this check removed as its is too restrictive at present.. and prevents useful and functional behaviouir by using gateways and jump regions.|
Hi Marck, thanks for the wonderful patch! -- the big one.
I'm having trouble with System.Linq, and then the .Except method. Make sure you use .NET 3.5...
Thanks so much, Marck! I haven't tested that it works... please test, Ai and Marck.
17:44] <CIA-35> opensim: marck00 * r7e47ab746ef5 /OpenSim/ (8 files in 7 dirs):
[17:44] <CIA-35> opensim: Allow creation of link regions if there is an existing region within a 4096 range.
[17:44] <CIA-35> opensim: Also add GetHyperlinks() to the grid service.
[17:44] <CIA-35> opensim: diva * r009053479302 / (8 files in 7 dirs):
[17:44] <CIA-35> opensim: Added Check4096 config var under [GridService], at the request of many. Changed the iteration that Marck had on the Hyperlinker.
[17:44] <CIA-35> opensim: ATTENTION! CONFIGURATION CHANGE AFFECTING Robust.HG.ini.example and StandaloneCommon.ini.example.
[18:09] <CIA-35> opensim: diva 0.7-post-fixes * ra0fa6dc967af /OpenSim/ (8 files in 7 dirs): Marck's patch on 4096 checks with conflicts resolved.
[18:09] <CIA-35> opensim: diva 0.7-post-fixes * rd44b7d9637be / (3 files in 3 dirs):
[18:09] <CIA-35> opensim: Added Check4096 config var under [GridService], at the request of many. Changed the iteration that Marck had on the Hyperlinker.
[18:09] <CIA-35> opensim: ATTENTION! CONFIGURATION CHANGE AFFECTING Robust.HG.ini.example and StandaloneCommon.ini.example.
edited on: 2010-08-07 00:24
Glad that you find the patch useful. And thanks for making the 4096 check a configurable option. This is a nice solution which should fit everybody's needs. I haven't tested the latest commit yet, just my own build with that patch.
I just wanted to respond on the System.Linq topic: Both IEnumerable<T> and Enumerable.Except<TSource> are supported in .NET 3.5, see the version information on http://msdn.microsoft.com/en-us/library/9eekhta0.aspx [^] and http://msdn.microsoft.com/en-us/library/bb300779.aspx. [^]
I used the solution file created by runprebuild2010.bat with Visual C# Express 2010, and this does set the target framework to .NET Framework 3.5, so any reference to a .NET 4.0 functionality would have resulted in a notice, I guess?
I am also able to successfully build this with both Mono 220.127.116.11 and Mono 2.6.2.
One more thing: Shouldn't the comment in Robust.HG.ini.example and StandaloneCommon.ini.example tell the default value? Right now it says Check4096 = "False", but the default value is actually "true".
The default commented out should be what the code has set to be regular.
BUT... would the default in the code be better set to have check4096 as false. The code anyway makes a sensible check that there is SOME region registed with the grid or in the standalone that is within 4096 of the target linked regions I believe?
And the people havig problems could change it explicitly to true.
Otherwise I can see we will have a lot of people asking why they cannot jump about whe they move between grids.
I am setting up r/13352 wit this fix now, and I noted that StandaloneCommon.ini.example and Robust.HG.ini.example altered so have copied those changes into my config. I have set Check4096 explitly to false in my setup in case the default in the code in a future patch alters anyway.
aiaustin, that's right, the patch checks if there is any region on the grid/standalone that is within the 4096 range of the hypergrid region that is to be linked. If it finds one, the link is created.
Your particular use case with the gateway regions that you described in the initial description of this mantis should work with my patch even when you enable the 4096 check now. It would be nice if you tried this as a test at least.
edited on: 2010-08-07 04:15
Okay good job Marck, its working fine with Check4096=false
I have teleported internally from Openvue (1000,1000) to Vue-5000 then hyperjumped to Grid4Us Home, back to Vue-9000, on to Grid4Us Hyper, back to Vue-5000. All worked nicely.
I had a glitch or two with it saying my home grid region no longer existed when I tried to teleport back to my grid at one stage after perhaps 20 hyperjumps. But return to "Home" worked. Restarting the viewer LL 1.23.5) fixed that.
I have to go out just now but will reset and test with Check4096-true as you suggest. Do yo expect I can still teleport? What does Check4096=true mean? Does it try a teleport even if there is NO region within 4096 in that case?
edited on: 2010-08-07 04:55
Check4096=true means that it only creates a link to a hypergrid region (i.e. when you use either of the methods explained at http://opensimulator.org/wiki/Installing_and_Running_Hypergrid#Linking_regions_.28Optional.29 [^] ) when it finds an existing region in your grid or standalone that lies within a 4096 regions distance from the destination location of the linked hypergrid region. If none of the regions in your grid lies within that distance, then the creation of the link is refused with "Unable to link, region is too far".
For example, Openvue is centered at 1000,1000. Openvue also has a gateway region Vue-5000 at 5000,5000. Now you can link to GermanGrid because it is centered at 8001,8000 which lies within then 4096 range to your Vue-5000 region. You can also create a link to GermanGrid with link-region in any of your region consoles, for the same reason: there exists a region in your grid (Vue-5000) whose distance to 8001,8000 is less than 4096 regions. You still have to do the actual teleport to GermanGrid from Vue-5000 because teleport attempts from regions around 1000,1000 to GermanGrid will still experience the known viewer issues, but the *creation* of that linked region for GermanGrid will succeed.
If you set Check4096=false, then no checks are performed at all. *Every* attempt to link any region will succeed as long as that region can be accessed over the network.
With Check4096=false, you did not check my patch at all, because you disabled it. :) That's why I asked you to test it on your grid with Check4096=true. It should work for you.
edited on: 2010-08-07 05:04
Okay, I tried with Robust.HG.ini set to Check4096="True" explicitly and I can still move from my core regions at 1000,1000 to a gateway region Vue-5000 at 5000,5000 on my grid and then teleport to Grid4Us (which is around 7000,7000) and then back to Vue-9000 (at 9000,8000).
I did notice something though, which may be a different bug. I tried to go to Gdansk grid, and it did not work. so it left me where I was on Vue-9000. But when I then tried a "teleport home" from viewer main menu it said "Could not teleport: Destimation refused: failed to veridy user Ai Austin, acess denied to region Openvue" (Openvue is my home set region). Several attempts over a 5 minute period after that gave same message. I also tried to gain access via the map. The regio shows uop fine, but a map teleport atempt gives same message. This is the case for all regions I tried on my home grid (on several different Opensi,.exe region servers in fact, but of course teh single Robust.exe server).
Robust.exe log for one attempt is here. Looks like its got my avatar some sort of mode where it thinks I am in hyperspace - perhaps form the failed jump to Gdansk grid? It may noty be tidyign up well when it fails but yo are still left on the home grid you tried to jump from. Note my avatar label is the usual "Ai Austin" not with the home grid hostname and port after it as it usually is when on a non-home hypergrid.
12:53:45 - [HG ENTITY TRANSFER MODULE]: Request to teleport Ai Austin home
12:53:45 - [HG ENTITY TRANSFER MODULE]: User is local
12:53:45 - [ENTITY TRANSFER MODULE]: Request to teleport Ai Austin home
12:53:45 - [ENTITY TRANSFER MODULE]: User's home region is Openvue 9c8b6f8f-8178
12:53:45 - [HG ENTITY TRANSFER MODULE]: region 9c8b6f8f-8178-4a69-92dc-9feba4646
e6b flags: 4
12:53:45 - [ENTITY TRANSFER MODULE]: Final destination is x=1000 y=1000 uuid=9c8
12:53:45 - [ENTITY TRANSFER MODULE]: Request Teleport to virtual.aiai.ed.ac.uk:9
000:Openvue/<128, 128, 28.6726>
12:53:45 - [LOCAL SIMULATION CONNECTOR]: Found region Openvue to send SendCreate
12:53:45 - [CONNECTION BEGIN]: Region Openvue told of incoming child agent Ai Au
stin e24a9015-f5ca-452b-8c95-d32e34cb9d64 (circuit code 1637604520, teleportflag
Region (root) #
But I WAS able then to teleport to another Grid (Grid4Us) and then back sucessfully to my home grid and then my home region. Again indicating that the avatar status in hyperspace was then corrected by the successful jump.
Right Marck. In that case it makes sense to have the default be Check4096="True" as the code is now, and just amend the Robust.HG.ini.example and StandaloneCommon.ini.example to have
as you suggested.
|When you tried to teleport home from Vue-9000 after that failed attempt to go to Gdansk grid, you actually attempted a jump over the 4096 limit. Since every known viewer has issues with this, the behaviour for this attempt is undefined. I guess that's why you had the issues.|
edited on: 2010-08-26 01:58
Ah, of course that makes sense. I tried other regions but not Vue-5000 which would have worked I guess. If it happens again I will try that jump which would be less than 4096.
I thought the 4096 problem as just between grids and not on ONE grid.
So, Teleport Home is not a route to avoid the 4096 problem. Tricky.
edited on: 2010-08-25 14:38
Diva and Marck, I don't think the Check4096 default variable value as commented out in Robust.HG.ini.example is correct yet. Can you check it against the actual code?
Also, I think the Check4096 variable might have sneaked into Robust.ini.example. I wonder if it should NOT be in that as its only relevant to HG and link-region uses. It ought to be removed if it's in the versions that have now been made in master and 0.7 postfixes.
This issue can then probably be closed as resolved.
|Aiaustin, you are correct. The default for parameter Check4096 is "true" in the source code. And this check is performed in the HypergridLinker which is only used with hypergrid-enabled setups.|
I checked the current state of Robust.HG.ini.example and Robust.ini.exmaple in GIT (master and 0.7 post-fixes) and both have
; Check4096 = "False"
This should be altered to True in Robust.HG.ini.example and the line deleted in Robust.ini.example
I read this as "uncomment if you want this".
Looks like justincc's last change to Robust.ini.example made the Check4096 sneak in.
[18:24] <CIA-75> opensim: diva * r3c71e5a3a270 /bin/Robust.ini.example: Deleted Check4096 from Robust.ini.example
[18:25] <CIA-75> opensim: diva 0.7-post-fixes * rac55c118f2f3 /bin/Robust.ini.example: Deleted Check4096 from Robust.ini.example
|Most people expect the commented out value to be the default value as well. That's the way many programs do it. I think OpenSim should do the same, IMNSHO.|
edited on: 2010-08-27 04:05
I may have confused JustinCC on this when we discussed the changes to the Robust.HG.ini and Robust.ini example files, which I did a tidy up job on.
To follow usual .ini.example form, the Robust.HG.ini value for Check4096 should be True as that is the default in the code. All the commented out defaults in the .ini.example files are in the form:
keyword = default value
Though its sometime useful where the values are not just True and False to say what the value range is, or provide a link to the Wiki for complex variables.
By the way I see various cases in use for true, True, false, False. I assume it does not matter in the code itself in any situation? But maybe this ought to be made the same throughout in the 3 .ini.example files just so as not to cause potentially worry for a configurer?
|Hypergrid protocols changed and jump distance issues resolved. Please open a new issue if you have Hyoergrid teleport issues.|
|2010-08-05 05:47||aiaustin||New Issue|
|2010-08-05 05:47||aiaustin||Git Revision||=> 0.7 post-fixes|
|2010-08-05 05:47||aiaustin||SVN Revision||=> 13491|
|2010-08-05 05:47||aiaustin||Run Mode||=> Grid (Multiple Regions per Sim)|
|2010-08-05 05:47||aiaustin||Physics Engine||=> BasicPhysics, ODE|
|2010-08-05 05:47||aiaustin||Environment||=> Unknown, .NET / Windows32|
|2010-08-05 05:47||aiaustin||Mono Version||=> None|
|2010-08-05 05:54||aiaustin||Summary||HG1.5 link-region fails with "Region is too far" even when some regions in OpenSim.exe instnace are in range => HG1.5 link-region fails with "Region is too far" even when some regions in OpenSim.exe instance are in range|
|2010-08-05 05:57||aiaustin||Description Updated|
|2010-08-05 05:57||aiaustin||Additional Information Updated|
|2010-08-05 05:58||aiaustin||Additional Information Updated|
|2010-08-05 09:57||Diva||Note Added: 0016284|
|2010-08-05 14:32||aiaustin||Note Added: 0016286|
|2010-08-05 14:33||aiaustin||Description Updated|
|2010-08-05 14:34||aiaustin||Description Updated|
|2010-08-05 18:52||Diva||Note Added: 0016289|
|2010-08-05 23:51||Marck||File Added: 0001-Disable-4096-range-check.patch|
|2010-08-05 23:52||Marck||File Added: 0001-Allow-creation-of-link-regions.patch|
|2010-08-05 23:53||Marck||Note Added: 0016290|
|2010-08-05 23:53||Marck||Status||new => patch included|
|2010-08-06 03:19||aiaustin||Note Added: 0016291|
|2010-08-06 17:08||Diva||Note Added: 0016317|
|2010-08-06 18:10||Diva||Note Added: 0016318|
|2010-08-07 00:16||Marck||Note Added: 0016319|
|2010-08-07 00:17||Marck||Note Edited: 0016319|
|2010-08-07 00:17||Marck||Note Edited: 0016319|
|2010-08-07 00:24||Marck||Note Edited: 0016319|
|2010-08-07 02:48||aiaustin||Note Added: 0016321|
|2010-08-07 02:58||Marck||Note Added: 0016322|
|2010-08-07 04:04||aiaustin||Note Added: 0016323|
|2010-08-07 04:15||aiaustin||Note Edited: 0016323|
|2010-08-07 04:55||Marck||Note Added: 0016325|
|2010-08-07 04:55||Marck||Note Edited: 0016325|
|2010-08-07 05:00||aiaustin||Note Added: 0016326|
|2010-08-07 05:02||aiaustin||Note Added: 0016327|
|2010-08-07 05:04||aiaustin||Note Edited: 0016326|
|2010-08-07 05:10||Marck||Note Added: 0016328|
|2010-08-07 05:32||aiaustin||Note Added: 0016329|
|2010-08-07 06:22||aiaustin||Note Added: 0016330|
|2010-08-07 06:48||aiaustin||Note Edited: 0016330|
|2010-08-07 06:59||aiaustin||Note Edited: 0016330|
|2010-08-07 13:29||aiaustin||Note Edited: 0016330|
|2010-08-25 14:37||aiaustin||Note Added: 0016605|
|2010-08-25 14:38||aiaustin||Note Edited: 0016605|
|2010-08-25 22:38||Marck||Note Added: 0016610|
|2010-08-26 01:57||aiaustin||Note Deleted: 0016330|
|2010-08-26 01:58||aiaustin||Note Edited: 0016329|
|2010-08-26 02:03||aiaustin||Note Added: 0016613|
|2010-08-26 18:22||Diva||Note Added: 0016622|
|2010-08-26 18:26||Diva||Note Added: 0016623|
|2010-08-26 18:36||smxy||Note Added: 0016624|
|2010-08-27 01:49||aiaustin||Note Added: 0016625|
|2010-08-27 04:04||aiaustin||Note Edited: 0016625|
|2010-08-27 04:05||aiaustin||Note Edited: 0016625|
|2015-08-17 11:56||aiaustin||Assigned To||=> aiaustin|
|2015-08-17 11:56||aiaustin||Status||patch included => assigned|
|2015-08-17 11:58||aiaustin||Note Added: 0029175|
|2015-08-17 11:58||aiaustin||Status||assigned => resolved|
|2015-08-17 11:58||aiaustin||Fixed in Version||=> master (dev code)|
|2015-08-17 11:58||aiaustin||Resolution||open => fixed|
|2015-08-17 12:01||aiaustin||Note Added: 0029176|
|2015-08-17 12:01||aiaustin||Status||resolved => closed|
|Copyright © 2000 - 2012 MantisBT Group|