MantisBT - opensim
View Issue Details
0008802opensim[GRID] Hypergridpublic2020-11-10 09:342020-11-22 06:45
master (dev code) 
master (dev code)master (dev code) 
Grid (Multiple Regions per Sim)
.NET / Windows64
0008802: Hypergrid Jump from OSGrid to another already visited grid fails first time works second time
When logged on locally to OSGrid (on region Vue-port for example) if I TP to another Grid (e.g. Openvue grid, Openvue region) it works first time. I then TO back, that also works, then I try to TP back to second grid again .. even after waiting two minutes or so and checking "show users" on second grid shows no users present in second grid destination region. But this attempt to TP back gives a popup message... "Teleport failed. You appear to already be logged in on the destination grid." Then trying it again, even immediately it works.

I suspect this is something to do with some special configuration related to OSGrid hypergrid travel as it does NOT show as a problem when I go between Openvue and AiLand grids. They TP first time in both directions.
This is true for other tests where I am coming from OSGrid. But here is a single example where it is repeatable...

Local avatar login to OSGrid.

hop:// [^]
hop:// [^]

This occurs on OSGrid (on 2020-11-07 version of code) to Openvue or Ailand grids on recent code (also 2020-11-07).
I tested this with various versions of Firestorm and they all have same behaviour... FS6.3.9.58205, FS6.4.5.60799 and FS6.4.12.62792.
No tags attached.
related to 0006744new  GridUser table gets extra entry with repeat avatar UUID with variants of hypergrid reference 
jpg Already-Logged-In-OSGrid-to-Openvue.jpg (22,595) 2020-11-10 09:36

jpg 2020-11-10-Kitely-to-OSGrid.jpg (422,758) 2020-11-10 12:32
Issue History
2020-11-10 09:34aiaustinNew Issue
2020-11-10 09:36aiaustinFile Added: Already-Logged-In-OSGrid-to-Openvue.jpg
2020-11-10 11:02BillBlightNote Added: 0037047
2020-11-10 12:19aiaustinNote Added: 0037049
2020-11-10 12:19aiaustinNote Edited: 0037049bug_revision_view_page.php?bugnote_id=37049#r9376
2020-11-10 12:28aiaustinNote Added: 0037050
2020-11-10 12:32aiaustinNote Edited: 0037050bug_revision_view_page.php?bugnote_id=37050#r9378
2020-11-10 12:32aiaustinFile Added: 2020-11-10-Kitely-to-OSGrid.jpg
2020-11-10 12:44aiaustinNote Edited: 0037050bug_revision_view_page.php?bugnote_id=37050#r9379
2020-11-10 13:28aiaustinNote Added: 0037053
2020-11-10 13:29aiaustinNote Edited: 0037053bug_revision_view_page.php?bugnote_id=37053#r9381
2020-11-10 13:42tampaNote Added: 0037054
2020-11-10 13:52UbitUmarovNote Added: 0037055
2020-11-10 13:59aiaustinNote Added: 0037056
2020-11-10 14:00aiaustinNote Edited: 0037056bug_revision_view_page.php?bugnote_id=37056#r9383
2020-11-10 14:02aiaustinNote Added: 0037057
2020-11-10 14:04tampaNote Added: 0037058
2020-11-11 04:45aiaustinNote Added: 0037066
2020-11-11 04:46aiaustinNote Edited: 0037066bug_revision_view_page.php?bugnote_id=37066#r9390
2020-11-11 04:48aiaustinNote Edited: 0037066bug_revision_view_page.php?bugnote_id=37066#r9391
2020-11-11 09:33tampaNote Added: 0037067
2020-11-11 09:55aiaustinNote Added: 0037068
2020-11-11 09:56aiaustinNote Edited: 0037068bug_revision_view_page.php?bugnote_id=37068#r9393
2020-11-11 11:19tampaNote Added: 0037069
2020-11-11 11:56aiaustinNote Added: 0037071
2020-11-11 11:59tampaNote Added: 0037072
2020-11-11 12:42Gezebu MindBlueNote Added: 0037073
2020-11-11 12:43Gezebu MindBlueNote Edited: 0037073bug_revision_view_page.php?bugnote_id=37073#r9395
2020-11-11 12:51aiaustinNote Added: 0037075
2020-11-11 12:52aiaustinNote Edited: 0037075bug_revision_view_page.php?bugnote_id=37075#r9399
2020-11-11 12:54aiaustinNote Edited: 0037075bug_revision_view_page.php?bugnote_id=37075#r9400
2020-11-11 13:17aiaustinNote Added: 0037076
2020-11-11 13:21aiaustinNote Edited: 0037076bug_revision_view_page.php?bugnote_id=37076#r9402
2020-11-11 13:23Gezebu MindBlueNote Added: 0037077
2020-11-11 13:27Gezebu MindBlueNote Edited: 0037077bug_revision_view_page.php?bugnote_id=37077#r9404
2020-11-11 13:31Gezebu MindBlueNote Added: 0037078
2020-11-11 16:19UbitUmarovNote Added: 0037079
2020-11-12 05:04tampaNote Added: 0037081
2020-11-12 05:11tampaNote Edited: 0037081bug_revision_view_page.php?bugnote_id=37081#r9406
2020-11-14 02:01aiaustinNote Added: 0037111
2020-11-14 02:18aiaustinNote Edited: 0037111bug_revision_view_page.php?bugnote_id=37111#r9431
2020-11-14 03:12aiaustinNote Edited: 0037111bug_revision_view_page.php?bugnote_id=37111#r9432
2020-11-14 03:42aiaustinNote Added: 0037113
2020-11-14 03:50aiaustinNote Added: 0037114
2020-11-14 03:52aiaustinNote Edited: 0037114bug_revision_view_page.php?bugnote_id=37114#r9434
2020-11-14 06:00UbitUmarovNote Added: 0037121
2020-11-14 06:22aiaustinNote Added: 0037123
2020-11-14 06:24aiaustinNote Edited: 0037123bug_revision_view_page.php?bugnote_id=37123#r9436
2020-11-14 06:24aiaustinNote Edited: 0037123bug_revision_view_page.php?bugnote_id=37123#r9437
2020-11-16 12:50aiaustinNote Added: 0037175
2020-11-16 12:52aiaustinNote Edited: 0037175bug_revision_view_page.php?bugnote_id=37175#r9472
2020-11-16 13:14aiaustinNote Added: 0037176
2020-11-16 13:15aiaustinNote Edited: 0037175bug_revision_view_page.php?bugnote_id=37175#r9473
2020-11-16 13:15aiaustinNote Edited: 0037176bug_revision_view_page.php?bugnote_id=37176#r9475
2020-11-16 13:34tampaNote Added: 0037177
2020-11-16 13:53aiaustinNote Added: 0037180
2020-11-17 03:26aiaustinNote Added: 0037183
2020-11-17 06:16aiaustinAdditional Information Updatedbug_revision_view_page.php?rev_id=9479#r9479
2020-11-19 12:50aiaustinRelationship addedrelated to 0006744
2020-11-19 12:53aiaustinNote Added: 0037220
2020-11-19 13:43aiaustinNote Added: 0037221
2020-11-19 13:43aiaustinNote Edited: 0037221bug_revision_view_page.php?bugnote_id=37221#r9505
2020-11-19 13:44aiaustinNote Edited: 0037221bug_revision_view_page.php?bugnote_id=37221#r9506
2020-11-19 13:44aiaustinNote Edited: 0037221bug_revision_view_page.php?bugnote_id=37221#r9507
2020-11-19 13:45aiaustinNote Edited: 0037221bug_revision_view_page.php?bugnote_id=37221#r9508
2020-11-19 13:48aiaustinNote Edited: 0037221bug_revision_view_page.php?bugnote_id=37221#r9509
2020-11-19 13:48aiaustinNote Edited: 0037221bug_revision_view_page.php?bugnote_id=37221#r9510
2020-11-19 13:50aiaustinNote Edited: 0037221bug_revision_view_page.php?bugnote_id=37221#r9511
2020-11-19 13:58aiaustinNote Added: 0037223
2020-11-20 01:52aiaustinNote Added: 0037225
2020-11-20 01:52aiaustinNote Edited: 0037225bug_revision_view_page.php?bugnote_id=37225#r9513
2020-11-20 04:00aiaustinNote Edited: 0037225bug_revision_view_page.php?bugnote_id=37225#r9514
2020-11-20 04:26UbitUmarovNote Added: 0037227
2020-11-20 04:29UbitUmarovNote Edited: 0037227bug_revision_view_page.php?bugnote_id=37227#r9518
2020-11-20 05:33aiaustinNote Added: 0037228
2020-11-20 05:34aiaustinNote Edited: 0037228bug_revision_view_page.php?bugnote_id=37228#r9520
2020-11-20 05:36aiaustinNote Edited: 0037228bug_revision_view_page.php?bugnote_id=37228#r9521
2020-11-20 05:57UbitUmarovNote Added: 0037229
2020-11-20 06:00UbitUmarovNote Edited: 0037229bug_revision_view_page.php?bugnote_id=37229#r9523
2020-11-20 06:02UbitUmarovNote Edited: 0037229bug_revision_view_page.php?bugnote_id=37229#r9524
2020-11-20 06:25aiaustinNote Added: 0037230
2020-11-20 06:29aiaustinNote Edited: 0037230bug_revision_view_page.php?bugnote_id=37230#r9526
2020-11-20 11:02UbitUmarovNote Added: 0037231
2020-11-20 11:06UbitUmarovNote Edited: 0037231bug_revision_view_page.php?bugnote_id=37231#r9528
2020-11-20 12:20UbitUmarovNote Edited: 0037231bug_revision_view_page.php?bugnote_id=37231#r9529
2020-11-20 12:25aiaustinNote Added: 0037232
2020-11-20 12:26aiaustinNote Edited: 0037232bug_revision_view_page.php?bugnote_id=37232#r9531
2020-11-20 12:26aiaustinNote Edited: 0037232bug_revision_view_page.php?bugnote_id=37232#r9532
2020-11-20 12:27aiaustinNote Edited: 0037232bug_revision_view_page.php?bugnote_id=37232#r9533
2020-11-20 12:29aiaustinNote Edited: 0037232bug_revision_view_page.php?bugnote_id=37232#r9534
2020-11-20 12:29aiaustinNote Edited: 0037232bug_revision_view_page.php?bugnote_id=37232#r9535
2020-11-20 12:30UbitUmarovNote Edited: 0037231bug_revision_view_page.php?bugnote_id=37231#r9536
2020-11-20 12:46UbitUmarovNote Added: 0037233
2020-11-20 12:49UbitUmarovNote Edited: 0037233bug_revision_view_page.php?bugnote_id=37233#r9538
2020-11-20 12:51aiaustinNote Added: 0037234
2020-11-20 12:51aiaustinNote Edited: 0037234bug_revision_view_page.php?bugnote_id=37234#r9540
2020-11-20 12:55aiaustinNote Added: 0037235
2020-11-20 12:55UbitUmarovNote Added: 0037236
2020-11-20 12:59UbitUmarovNote Edited: 0037236bug_revision_view_page.php?bugnote_id=37236#r9542
2020-11-20 16:20UbitUmarovNote Added: 0037237
2020-11-20 16:49UbitUmarovNote Edited: 0037237bug_revision_view_page.php?bugnote_id=37237#r9544
2020-11-21 01:17aiaustinNote Edited: 0037237bug_revision_view_page.php?bugnote_id=37237#r9545
2020-11-21 06:57aiaustinNote Added: 0037242
2020-11-21 06:57aiaustinNote Edited: 0037242bug_revision_view_page.php?bugnote_id=37242#r9552
2020-11-21 17:42Gezebu MindBlueNote Added: 0037253
2020-11-21 17:45Gezebu MindBlueNote Edited: 0037253bug_revision_view_page.php?bugnote_id=37253#r9566
2020-11-22 01:23aiaustinNote Added: 0037255
2020-11-22 01:24aiaustinNote Edited: 0037255bug_revision_view_page.php?bugnote_id=37255#r9568
2020-11-22 01:24aiaustinNote Edited: 0037255bug_revision_view_page.php?bugnote_id=37255#r9569
2020-11-22 06:29aiaustinAssigned To => UbitUmarov
2020-11-22 06:29aiaustinStatusnew => assigned
2020-11-22 06:33aiaustinNote Added: 0037260
2020-11-22 06:33aiaustinStatusassigned => resolved
2020-11-22 06:33aiaustinFixed in Version => master (dev code)
2020-11-22 06:33aiaustinResolutionopen => fixed
2020-11-22 06:45aiaustinStatusresolved => closed

2020-11-10 11:02   
Since you don't say, I have to ask, "Have you tried this from other osgrid regions other than your own?"

More empirical data leads to better troubleshooting ...
2020-11-10 12:19   
I did some further tests,.. beyond using one of my own regions on OSGrid as the base. For these tests I use OSGrid Sandbox Plaza as base.

This one fails first time, works second, EVERY time.. note Openvue is latest.

hop:// [^] Plaza/128/128/22
hop:// [^]

This one though works EVERY time... (note Kitely is

hop:// [^] Plaza/128/128/22
hop:// [^] Welcome Center/127/132/24

2020-11-10 12:28   
(edited on: 2020-11-10 12:44)
Now more oddities... when on Kitely at

hop:// [^]

I was returning to the link that is now correctly put into Nearby Chat... that works...

hop:// [^] Plaza/128/128/22

BUT... the previously working variant now fails -

hop:// [^] Plaza/128/128/22

says "Could not teleport to hop:// [^] Plaza/128/128/22 as it's on a different grid ( than the current grid (OSGrid)." See attached image "2020-11-10-Kitely-to-OSGrid.jpg".

Note I am actually on Kitely when that message appears, but mention of current grid as OSGrid is probably just because the viewer assumes that at present. I reported that on the Firestorm JIRA... [^]

2020-11-10 13:28   
(edited on: 2020-11-10 13:29)
I just went back to Firestorm and that works and fails exactly the same way with same tests as reported in main Mantis issue description.

No idea how I have not spotted this before, unless its something that has relatively recently started to occur with the specific setup and URIs used by OSGrid.

is there another grid where we know its loginuri is different to its Hypergrid gatekeeperuri?

2020-11-10 13:42   
*raises hand* Yes, because uhm why would you even make them interchangeable, one is for local users logging in and the other is for external users teleporting over. Next you tell me you also enter your house through the chimney.

I don't exactly follow why this should work in the first place, it seems more like a bug that it was possible to abuse the loginuri for hg.

Think the problem is more that the viewer uses loginuri for landmarks and hop links instead of the gatekeeperuri, maybe because there is nothing to make it aware of where the user is coming from. Call me old fashioned, but I avoid landmarks and hop links and just type locations into the World Map, that hasn't failed me yet.
2020-11-10 13:52   
hop is a viewer side thing.

current grids uris are similar to web
2020-11-10 13:59   
(edited on: 2020-11-10 14:00)
That was a secondary note in the comments about Tampa. I was using the gatekeeper addresses to jump between the grids for the main issue reported here.

I was not using landmarks for any test reported here. All locations went into the top address bar.

Note also that the new Firestorm now in beta test correctly uses the gatekeeperuri for Hypergrid hops, backward TP links added into nearby chat and address bar locations.Its not using the current grid everywhere yet, but the basics are there now to make that consistent in future.

2020-11-10 14:02   
Only one fella comes in via our chimney... on Christmas Eve.
2020-11-10 14:04   
I never used the top address bar, well once I did, it didn't work so I stop bothering with it. I guess it should work, but if it doesn't then it must be doing something different to entering the uri into the World Map, but that sounds more like a viewer thing to me.
2020-11-11 04:45   
(edited on: 2020-11-11 04:48)
It has nothing specifically to do with using hop. That was just the choice I made to move about as I was testing the improvements in hop with the correct grid in FS beta.

You can get the same error simply using the map find and teleport, e.g. by doing this....

a) Log on as an OSGrid avatar at any location. I used "Sandbox Plaza" to avoid my own regions in same of configuration issues.

b) In the map try to go to another up to date grid using the usual map find format. I used "".

c) Note you arrive fine. First time if you have not been there before. If you go to your own grid you can use "show users" to see the avatar is logged in, in my case as Ai.Austin

d) Go back to OSGrid Sandbox Plaza however you wish. I was able to check "show users" showed the user had gone.

e) Wait as long as you wish. Now do the same find in Map - e.g. I repeated "" and try to go there.

f) Note the error "Teleport failed. You appear to already be logged in on the destination grid."

g) Now try to go there again. As soon as you want to try. Note it works.


If I do the same between two of my own grids (e.g. Ailand and Openvue) then things work fine and first time every time. So I suspect something specific about the OSGrid setup leaving something somewhere that makes some level of OpenSim thing the avatar remains on the destination grid, when it should not.

2020-11-11 09:33   
But this isn't the support forum for Osgrid, last I checked.
2020-11-11 09:55   
(edited on: 2020-11-11 09:56)
That is not the point. This Mantis issue is to cover the issues that arise for any user and it affects TPs to other grids whch fail in the ways reported until retried each time.

But of course I have already spoken with Dan Banner at OSGrid to see if there might be anything about the way in which OSGrid uses a different LoginURI and (Hypergrid) GatekeeperURI that might be a cause that triggers this problem

If so it might be seen with other grids that have such a setup. If anyone knows another based grid properly configured that separates the LoginURI and GatekeeperURI please list it here so we can test further.

2020-11-11 11:19   
I sent you IM inworld, ZetaWorlds is setup with a login and hg uri that need to be used accordingly and not interchangeably, however I have no issues getting anywhere. Only thing I hear is folks from osgrid and digi not being able to teleport in, though after some patching it turns out because they are all using the wrong uri for that as well.
2020-11-11 11:56   
Thanks Tampa. Which grid did you IM me on. I don't see messages on OSGrid or my own two grids (AiLand and Openvue). But I found Zeta Worlds and am testing.
2020-11-11 11:59   
Feel free to join #opensim-dev on freenode, makes communicating testing efforts a whole lot easier, you can find me there :)
Gezebu MindBlue   
2020-11-11 12:42   
(edited on: 2020-11-11 12:43)
i have also had many problems with teleports on osgrid, even to my own regions within osgrid. many times i have had to jump from lbsa plaza to event plaza, wright plaza, sandbox* plaza, etc, even more than one jump to then reach my regions. other osgrid users have told me that they have the same problem. luckily this improved a couple of days ago. but anyway I can?t reach my standalone grid with my osgrid user. the opposite always works properly, as I commented yesterday in another report. I also think that there is something in the osgrid configuration that generates some difficulties, even though this is not the osgrid support forum :B

2020-11-11 12:51   
(edited on: 2020-11-11 12:54)
Why I am reporting this here is that I believe it may be more generic and something that occurs whenever the LoginURI is separated from the GatekeeperURI. Perhaps even adding the (optional) :80 could make a difference to what some grids believe is a clean logout for a HG traveller at all levels. I think the evidence points to the REGION thinking the avatar has left but the GRID level services think a user is still on the grid somewhere. Something like that anyway!

2020-11-11 13:17   
(edited on: 2020-11-11 13:21)
Something has changed. When I first log in to one of my grids, I can now TP and hop:// between these three addresses first time in any order no problems...

hop:// [^]
hop:// [^]
hop:// [^]

But if I log in to OSGrid first, I see the issue of after visiting a foreign grid once and going back to OSGrid, an attempt to visit that second grid again fails on first attempt with "Teleport failed. You appear to already be logged in on the destination grid." message, but works on second attempt.

So I shift to looking for what OSGrid is sending as the avatar details to the second grid, and if that differs to what the REGION IOpenSim.exe instance thinks its dealing with.

I have a note from testing with Zeta Worlds (ZetaSim- (Unix/Mono))...

[13:02] Vincent.Sylvester I noticed that osgrid kept sending me a griduser entry for and one for, either this from the code changes here not decoding griduser data properly or osgrid's messed up.

Gezebu MindBlue   
2020-11-11 13:23   
(edited on: 2020-11-11 13:27)
from my grid standalone I can reach without problems, return to my home, jump to osgrid, from there jump again to Openvue, and return again to my home standalone. all jumps are very fast.

with my osgrid account if i search in the map, it takes a long time to find the region, i could go from osgrid to openvue, but when i tried to go back to my home of osgrid, it was not possible and the viewer closed the session.

osgrid region console:

18:17:37 - [AGENT HANDLER]: QueryAccess returned True (). Version=0, 0.8/0.8
18:17:37 - [SCENE]: Region Saturnalia told of incoming child agent Gezebu MindBlue c78f695d-821e-4e97-95bb-053be8616392
 (circuit code 1851221089, IP, viewer Firestorm-Release, teleportflags (ViaHome, ViaHGLogin),
 position <111.7966, 137.353, 30.34291>. From region Openvue (9c8b6f8f-8178-4a69-92dc-9feba4646e6b) @ [^]
18:17:37 - [SCENE]: Region Saturnalia authenticated and authorized incoming child agent Gezebu MindBlue c78f695d-821e-4
e97-95bb-053be8616392 (circuit code 1851221089)
18:17:37 - [CreateCaps]: new caps agent c78f695d-821e-4e97-95bb-053be8616392, circuit 1851221089, path ae530178-2a1e-49
01-8fa2-170d256c19ee, time 0
18:17:38 - [LLUDPSERVER]: Handling UseCircuitCode request for circuit 1851221089 to Saturnalia from IP
18:17:38 - [SCENE]: Adding new child scene presence Gezebu MindBlue c78f695d-821e-4e97-95bb-053be8616392 to scene Satur
nalia at pos <111.7966, 137.353, 30.34291>, tpflags: ViaHome, ViaHGLogin
18:17:38 - [CAPS]: Received SEED caps request in Saturnalia for agent c78f695d-821e-4e97-95bb-053be8616392
18:17:38 - [SCENE]: Incoming client Gezebu MindBlue in region Saturnalia via HG login
18:17:38 - [CHILDAGENTDATAUPDATE]: got packed appearance
18:17:38 - [SCENE]: Incoming child agent update for c78f695d-821e-4e97-95bb-053be8616392 in Saturnalia
18:17:38 - [SCENE]: User Client Verification for Gezebu MindBlue in Saturnalia returned false
18:17:39 - [LLUDPSERVER]: Client created, processing pending queue, 2 entries
18:17:39 - [SCENE PRESENCE]: Completing movement of Gezebu MindBlue into region Saturnalia in position <111.7966, 137.3
53, 30.34291>
18:17:40 - [CLIENT]: Close has been called for Gezebu MindBlue attached to scene Saturnalia
18:17:40 - [JobEngine]: Stopping AsyncInUDP-c78f695d-821e-4e97-95bb-053be8616392
18:17:40 - [SCENE]: Removing root agent Gezebu MindBlue c78f695d-821e-4e97-95bb-053be8616392 from Saturnalia
18:17:40 - [CAPS]: Remove caps for agent c78f695d-821e-4e97-95bb-053be8616392 in region Saturnalia
18:17:40 - [Scene]: The avatar has left the building
18:17:41 - [CAPS]: Unauthorized CAPS client c78f695d-821e-4e97-95bb-053be8616392 from
18:17:41 - [EVENTQUEUE]: (Enqueue) No queue found for agent c78f695d-821e-4e97-95bb-053be8616392 in region Saturnalia
18:17:42 - [LLCLIENTVIEW]: Caught exception while processing OpenMetaverse.Packets.CompleteAgentMovementPacket for Geze
bu MindBlue System.NullReferenceException: Object reference not set to an instance of an object
  at OpenSim.Region.Framework.Scenes.ScenePresence.CompleteMovement (OpenSim.Framework.IClientAPI client, System.Boolea
n openChildAgents) [0x002b2] in <f2240add546d47d0ae1b631b351dc3a4>:0
  at (wrapper delegate-invoke) System.Action`2[OpenSim.Framework.IClientAPI,System.Boolean].invoke_void_T1_T2(OpenSim.F
  at OpenSim.Region.ClientStack.LindenUDP.LLClientView.HandleCompleteAgentMovement (OpenMetaverse.Packets.Packet Pack)
[0x00057] in <49a143dc1f13486690dafa96c5b687de>:0
  at OpenSim.Region.ClientStack.LindenUDP.LLClientView+<>c__DisplayClass822_0.<ProcessPacketMethod>b__0 () [0x00002] in

Gezebu MindBlue   
2020-11-11 13:31   
the simulator versiĆ³n i run in osgrid is that of git, downloaded 2 days ago: Version: OpenSim Yeti Dev 08b06ec (SIMULATION/0.3 - SIMULATION/0.8)
2020-11-11 16:19   
there are several reasons for teleports fail
and as normal this mantis is doing a mess with several of them

- the fail because avatar already login is a tp/offline notification fail to relevant grids. From not just tp twice.

- the hop thing never worked well and never will
it lacks for example secure http information.
it is totally redundant in viewers. that could just use proper http/https url

- bad regions/ routers etc configuration
2020-11-12 05:04   
(edited on: 2020-11-12 05:11)
Yes separate things going on here.

I have set HomeURI and GatekeeperURI as
Only mention of is inside GridInfoService login directive, for use with the grid manager in the viewer to fetch the required uris for local login.

Firestorm seems to think that locally hop needs to be rather than which actually functions properly for local teleports.
Confirmed by the fact creating a landmark gives me hop:// [^] which works locally, but is obviously bad for HG.
So really viewer reading info from gridinfo properly using login. based on login directive locally is what's broken.

Guessing that new alias may help resolving that by changing HomeURI to login. since that seems to be what the viewer is fetching.

Over HG I can't get back via hop, both login and hg fail either saying "different grid" or opening websearch. That's completely fubar it seems.

This seems silly to me. The way it is laid out seems reasonable. Login for local logins and going about as that hits login service and hg for hypergrid stuff because that goes to gatekeeper.

Now that services are to interconnected this probably isn't the case anymore.

I also noticed that hop fails when the origin and destination region names are the same it just internally teleports.

What all that tells me is quite simple: Use the Worldmap

2020-11-14 02:01   
(edited on: 2020-11-14 03:12)
Ubit is right that several (actually quite a lot) of things are going on here and investigations on a number of fronts on server side and viewer side are uncovering all sorts of things. But to return to the issue actually meant to be the focus of this JIRA. I appreciate it MAY turn out to be a configuration issue in OSGrid, but its clearly something that is repeatable and may have generic causes with the various settings and variants of URLs with and without the :80, etc. So stick with me for a while.

Tampa said something to me while we were testing together and it appeared to be a description that fitted with the evidence I see.

He said there was a mismatched pair of arrival information related to persisting and leaving information for being mismatched when an OSGrid avatar visited Zeta Worlds. So some level of the system thinks the avatar is still present. From my evidence it would seem the region thinks the avatar has left but the robust services doesn't, and it stays that way until told otherwise as far as I can tell. Then when the OSGrid (in this case) avatar tries to come back, even after some time (e.g. overnight), the grid they are going to thinks they are still present and the return attempt fails, but that somehow clears things up, and an immediate second attempt to teleport back works.

Could Tampa elaborate on exactly which DB entries or status information he was referring to and which way round the URLs involved are used?

2020-11-14 03:42   
On the return teleport (first attempt to return that is) the destination grid Robust.log does see the connection attempt and seems to verify everything, but then seems to think the avatar is "offline".

11:35:51 - [HG Handler]: XMLRequest to link to Openvue from
11:35:52 - [GATEKEEPER SERVICE]: Returning region Openvue 9c8b6f8f-8178-4a69-92dc-9feba4646e6b @ [^] to user e858df02-a860-4b92-937a-2b87e4ebcd6d @ [^]
11:35:53 - [GATEKEEPER SERVICE]: Login request for Ai Austin @ [^] (e858df02-a860-4b92-937a-2b87e4ebcd6d) at 9c8b6f8f-8178-4a69-92dc-9feba4646e6b using viewer Firestorm-BeqStorm, channel Firestorm-BeqStorm, IP, Mac 5cdc21915194cbbfc0a4d064403bb1d3, Id0 58e894a9739075eaaa63a084ac97497c, Teleport Flags: ViaLogin. From region Vue (1eecd824-f3f1-4b2b-be59-2cde44e3f7b7) @ [^]
11:35:53 - [GATEKEEPER SERVICE]: Verifying grid [^] against [^]
11:35:53 - [GATEKEEPER SERVICE]: Identity verified for Ai Austin @ [^]
11:35:53 - [GRID USER SERVICE]: User e858df02-a860-4b92-937a-2b87e4ebcd6d is offline

On second attempt the destination grid Robust.log looks much the same but it thinks the avatar is "online"...

11:40:27 - [GATEKEEPER SERVICE]: Returning region Openvue 9c8b6f8f-8178-4a69-92dc-9feba4646e6b @ [^] to user e858df02-a860-4b92-937a-2b87e4ebcd6d @ [^]
11:40:28 - [GATEKEEPER SERVICE]: Login request for Ai Austin @ [^] (e858df02-a860-4b92-937a-2b87e4ebcd6d) at 9c8b6f8f-8178-4a69-92dc-9feba4646e6b using viewer Firestorm-BeqStorm, channel Firestorm-BeqStorm, IP, Mac 5cdc21915194cbbfc0a4d064403bb1d3, Id0 58e894a9739075eaaa63a084ac97497c, Teleport Flags: ViaLogin. From region Vue (1eecd824-f3f1-4b2b-be59-2cde44e3f7b7) @ [^]
11:40:28 - [GATEKEEPER SERVICE]: Verifying grid [^] against [^]
11:40:28 - [GATEKEEPER SERVICE]: Identity verified for Ai Austin @ [^]
11:40:28 - [GATEKEEPER SERVICE]: User Ai Austin is ok
11:40:28 - [PRESENCE SERVICE]: LoginAgent: session 29218966-7650-453c-afa3-66bd153f0abe, user e858df02-a860-4b92-937a-2b87e4ebcd6d, region 00000000-0000-0000-0000-000000000000, secure session 2e6822e4-512c-4401-91ea-f15584575398
11:40:28 - [GATEKEEPER SERVICE]: Destination Openvue is ok for Ai Austin
11:40:28 - [GATEKEEPER SERVICE]: Launching Ai.Austin, Teleport Flags: ViaLogin, ViaHGLogin
11:40:28 - [REMOTE SIMULATION CONNECTOR]: QueryAccess to [^] returned True, reason , version 0.8/0.8
11:40:28 - [REMOTE SIMULATION CONNECTOR]: Creating agent at [^]
11:40:29 - [GATEKEEPER SERVICE]: Login presence Ai.Austin is ok
11:40:29 - [GRID USER SERVICE]: User e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin is online
11:40:29 - [PRESENCE SERVICE]: ReportAgent: session 29218966-7650-453c-afa3-66bd153f0abe, user e858df02-a860-4b92-937a-2b87e4ebcd6d, region 9c8b6f8f-8178-4a69-92dc-9feba4646e6b. Previously: region 00000000-0000-0000-0000-000000000000

The two attempts differ at this line

[GATEKEEPER SERVICE]: Identity verified for Ai Austin @ [^]

The successful second attempt carries on with

[GATEKEEPER SERVICE]: User Ai Austin is ok
2020-11-14 03:50   
(edited on: 2020-11-14 03:52)
The OSGrid end sender region OpenSim.exe console on the failed attempt reports

11:43:56 - [HYPERGRID LINKER]: Link to [^] Openvue, in <27110,0>
11:43:56 - [GATEKEEPER SERVICE CONNECTOR]: Linking to [^]
11:43:56 - [HYPERGRID LINKER]: Region already exists in coordinates <24889,0>
11:43:57 - [LAND CONNECTOR]: remote call returned an error: Requested method [land_data] not found
11:43:57 - [LAND MANAGEMENT MODULE]: got no parcelinfo; not sending
11:43:58 - [HG ENTITY TRANSFER MODULE]: region [^] Openvue flags: 524
11:43:58 - [HG ENTITY TRANSFER MODULE]: Destination region is hyperlink
11:43:58 - [GATEKEEPER SERVICE CONNECTOR]: contacting [^]
11:43:58 - [HG ENTITY TRANSFER MODULE]: GetFinalDestination: ServerURI= [^]
11:43:58 - [ENTITY TRANSFER MODULE]: Teleporting Ai Austin e858df02-a860-4b92-937a-2b87e4ebcd6d from Vue to [^] ( [^]) Openvue/<128, 128, 29>
11:43:58 - [REMOTE SIMULATION CONNECTOR]: QueryAccess to [^] returned True, reason , version 0.8/0.8
11:43:58 - [ENTITY TRANSFER MODULE]: Vue transfer protocol version to Openvue is 0.8 / 0.8
11:43:58 - [ENTITY TRANSFER MODULE]: Determined that region Openvue at 9050,9050 size 256,256 needs new child agent for agent Ai Austin from Vue
11:43:58 - [SCENE PRESENCE]: Closing child agents. Checking 9 regions in Vue
11:43:58 - [HG ENTITY TRANSFER MODULE]: CreateAgent [^] [^]
11:43:58 - [REMOTE SIMULATION CONNECTOR]: Creating agent at [^]
11:43:59 - [ENTITY TRANSFER MODULE]: Teleport of Ai Austin from Vue to Openvue was refused because You appear to be already logged in on the destination grid Please wait a a minute or two and retry. If this takes longer than a few minutes please contact the grid owner.
11:43:59 - [LAND MANAGEMENT MODULE]: got no parcelinfo; not sending

But on the second retry and successful teleport this is given...

11:46:06 - [HYPERGRID LINKER]: Link to [^] Openvue, in <9267,0>
11:46:06 - [GATEKEEPER SERVICE CONNECTOR]: Linking to [^]
11:46:06 - [HYPERGRID LINKER]: Region already exists in coordinates <24889,0>
11:46:06 - [LAND CONNECTOR]: remote call returned an error: Requested method [land_data] not found
11:46:06 - [LAND MANAGEMENT MODULE]: got no parcelinfo; not sending
11:46:07 - [HG ENTITY TRANSFER MODULE]: region [^] Openvue flags: 524
11:46:07 - [HG ENTITY TRANSFER MODULE]: Destination region is hyperlink
11:46:07 - [GATEKEEPER SERVICE CONNECTOR]: contacting [^]
11:46:07 - [HG ENTITY TRANSFER MODULE]: GetFinalDestination: ServerURI= [^]
11:46:07 - [ENTITY TRANSFER MODULE]: Teleporting Ai Austin e858df02-a860-4b92-937a-2b87e4ebcd6d from Vue to [^] ( [^]) Openvue/<128, 128, 29>
11:46:07 - [REMOTE SIMULATION CONNECTOR]: QueryAccess to [^] returned True, reason , version 0.8/0.8
11:46:07 - [ENTITY TRANSFER MODULE]: Vue transfer protocol version to Openvue is 0.8 / 0.8
11:46:07 - [ENTITY TRANSFER MODULE]: Determined that region Openvue at 9050,9050 size 256,256 needs new child agent for agent Ai Austin from Vue
11:46:07 - [SCENE PRESENCE]: Closing child agents. Checking 9 regions in Vue
11:46:07 - [HG ENTITY TRANSFER MODULE]: CreateAgent [^] [^]
11:46:07 - [REMOTE SIMULATION CONNECTOR]: Creating agent at [^]
11:46:09 - [ENTITY TRANSFER MODULE]: Sending new CAPS seed url [^] from Vue to Ai Austin
11:46:09 - [ENTITY TRANSFER MODULE]: Set release callback URL to [^] in Vue
11:46:10 - [AGENT HANDLER]: Release e858df02-a860-4b92-937a-2b87e4ebcd6d to RegionID: 1eecd824-f3f1-4b2b-be59-2cde44e3f7b7
11:46:11 - [SCENE PRESENCE]: Making Ai Austin a child agent in Vue from root region 9950580233689600
11:46:11 - [SCENE PRESENCE]: Closing 8 child agents
  (details of 8 child agents removed - all as expected)

2020-11-14 06:00   
well part of this issues are related to a thing called UUI
for HG it was assumed that a UUID (or guid) is not unique, different grids could have different avatars with same UUID.
so on some parts of code a avatar is identified by

UUID:gridURL:first lastname

(possible other format elsewhere)

of course this is a fail unless we have our own viewer, that knows that
a user is identified by just UUID, not only by current viewers, but by our own code, elsewehre. so those must be unique and by definition of UUID they basically are.
possible the uui was related to very dedicated use cases where avatars with same uuid of different grids was intentional. ( standalone clones of grid regions?)

but major issue on this topic is GridURL
that was ill defined and so each part of code does its own things.
2020-11-14 06:22   
(edited on: 2020-11-14 06:24)
We will gradually get there. I am separating the various issues where I can.

For this specific (OSGrid?) return fail on first attempt and success on second attempt, I believe for the all tests I am doing there are different UUIDs for the avatars on each of those grids Ubit. They do though have the same local avatar name "Ai Austin" but that should not matter should it?

2020-11-16 12:50   
(edited on: 2020-11-16 13:15)
Further testing using native OGrid avatar. This problem occurs whichever teleport method is used...

a) scripted teleporter using osTeleportAgent ( [^] Openvue)
b) Map tool (
c) Address bar (hop:// [^])
d) Clicked link or TP back link in Nearby Chat (hop:// [^])

This persists forever over (Firestorm) viewer relogs. Tried 24 hours later even and first return attempt to a grid you have visited before fails. Second try always works.

If SERVER end is restarted it clear the situation and first attempt works, but of course then after going home and trying return again it fails then too until second attempt.

2020-11-16 13:14   
(edited on: 2020-11-16 13:15)
Ah.. a difference.

For previous reports I was using an avatar with a name (Ai Austin) which is the same as on the targetted grid but different UUID as mentioned before.

I just tested with a couple of avatars (e.g. RuthAndRoth Resident) whose name is DIFFERENT to any registered avatar on the destination grid and that works every time

I then went back and tested with a different OSGrid avatar (Be Austin) that also shares a name (but again different UUID) to the avatar on the other grid and that fails as reported in this Mantis.

2020-11-16 13:34   
Think it has to be said at this point that the issues described here are not exclusive to hop:// links and occur with Worldmap teleports as well.

So what really goes on here is on the first attempt the viewer reports "already logged in" as if presence was already posted before teleport is even initiated, then on the second teleport attempt it just goes through without error as if it removed the existing presence and replaced it with the incoming one.

That is normally how to "unstuck" presence during login, but there should not even be a presence to remove in the first place.

Think this has to be said this is a "first time teleport fails with already at destination" issue.
2020-11-16 13:53   
Yes... once you have visited once and TPed away its as if you are logged in forever on the destination grid until you try to TP back, that fails but clears the logged in status, so next (second) attempt works.

Viewer termination and restart does NOT clear it.

Server restart DOES clear it.
2020-11-17 03:26   
Testing with Dan Banner on OSGrid, its clear he does not see any issue jumping to and from AiLand grid and he gets there and back first time every time. Of course his avatar name will not be a local avatar on Ailand. It does start to look like the problem of stuck logged in status on the destination grid could be related to the same avatar "name" even if different UUIDs are used.

Can anyone shed light on whether this issue has been explored before ro if other Mantis issues relate to it?
2020-11-19 12:53   
Possible link to [^] spotted by Tampa.

The issue does seem to occur with older and long established OSGrid avatars.
2020-11-19 13:43   
(edited on: 2020-11-19 13:50)
MySQL data base griduser Table has multiple entries for same HG traveller and they have mispaired entries for online boolean, login time stamp and logout time stamp.

Hypergrid traveller avatar from OSGrid to Ailand: Ai Austin
UUID: e858df02-a860-4b92-937a-2b87e4ebcd6d

Two entries...
e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin
e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin

When visiting and on the Ailand grid online shows true for one entry and false for other for both entry. Note false entry has a 0 login time stamp.

e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, ..., False, 0, 1605699752,
e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, ..., True, 1605821184, 1605699844

After avatar goes back to OSGrid, Login time stamp for entry with 0 as login time stamp now shows a Logout time stamp that is later and other entry has True in the Online flag.

e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, ..., False, 0, 1605821504
e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, ..., True, 1605821184, 1605699844

After FIRST attempt to return from OGGrid to Ailand... viewer reports you are already logged in. But as shown next this has the effect of clearing up the griduser record "online" flag of the "stuck" entry to False.

e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, ..., False, 0, 1605821504,
e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, ..., False, 1605821184, 1605821629,

Now try a second time to return and that works.

The entries for online status and logout time stamp go into one entry and login time stamp goes to other entry. This is cleared up by first failed login attempt after online status is left incorrectly as True.

Of course there are multiple entries in the griduser table for many HG avatars who have visited over the years.

2020-11-19 13:58   
Just to check also. Should a LOCAL avatar on a grid have multiple griduser table entries?

Ai Austin on AiLand grid shows in griduser table as BOTH:

ff0a6e25-15cf-4294-9374-4ce8cdec65eb;;Ai [^] Austin
2020-11-20 01:52   
(edited on: 2020-11-20 04:00)
I also note two things. This problem occurs when travelling to relatively recently established grids like Fire And Ice Grid, so may not be just because of very old data base entries.

I also checked HG visitor entries in the griduser table for another grid which uses port :80 for its GatekeeperURI and may therefore sometimes be dropping the :80 as a default ( and and yes there are two entries wit the same mispaired logion, and logout time stamps there.

0635df95-f149-6630-5fb4-aca4482e8e75;;Vincent [^] Sylvester, ..., False, 0, 1605570238
0635df95-f149-6630-5fb4-aca4482e8e75;;Vincent [^] Sylvester, ..., False, 1605570115, 1605570112

2020-11-20 04:26   
(edited on: 2020-11-20 04:29)
yeah griduserinfo is broken since it was created.

2020-11-20 05:33   
(edited on: 2020-11-20 05:36)
Ubit.. it does look like some part of OpenSim, or some configuration setup for grids that use port 80, give their login and logoff information to the destination grid with and without the :80 port at different times. Hence the mismatch and one entry in the table retaining ithe avatar's online status and in a stuck state until one (failing) return attempt is tried.

I would perhaps suggest that the "simple" fix would be to have a single griduser table entry for each unique avatar UUID with only the UUID for any local avatar and with the fully qualified gridomain:port/; Firstname Lastname.. putting in the default port (:80 or :443) if its omitted.

BUT... you indicated that multiple griduser table entries for the same avatar UUD needed to be allowed in case of very special situations where people set up perhaps local cloned setups for tests when they deliberately want to use the same UUID as on some other grid. If thats definitely required, then perhapsit might be possible to find where the entries without the default :80 are being generated in OpenSim code and always add that back on if its assumed. That MIGHT be a fix?

2020-11-20 05:57   
(edited on: 2020-11-20 06:02)
yes most use that UUI is just broken
as i said is assumed rigid grid url, etc, and yes it is case sensitive..
the uses those entire strings as DB indexes for some reason assuming a user uuid is not unique

when a user is a local one, the search on dbs is a FULL string start match search, Very fun on a large grid

several services that where contaminated with HG code need deep changes
griuserinfo and Presence are totally redundant. They have the same job, but for some reason they where split, without full fixing the rest
That split means 2 full calls to grid to tell the same thing.. user did login or user left, or is in flight (not there.. should be ?)

Well i feel totally blocked on this issues
i can't touch those DBs, because a lot of grid web services do read directly from them

diva wiki even depends on exact opensim code, because instead of benign relative independent, it does low level replacement of functions.

Who knows what all those forks do...
Even osgrid uses parts of closed source fork and may get worse
So also blocked on using it as test grid.

opensim future does look hopeless

2020-11-20 06:25   
(edited on: 2020-11-20 06:29)
Doom and gloom today I see :-) The future is bright!

Well. Lets assume then that the date base for now has to stay as is and multiple entries for any specific UUID are permitted, and that even the local avatar on a grid could have HG style entries as well as the UUID alone.

Presence table does not seem to be affected or be the root of this problem, the issue is only in the griduser table. So lets (for now anyway) put any change to the Presence table to one side.

So its just that when logging in one of the griduser table entries matching the UUID is set for logon time stamp and online status set True. When logging out a DIFFERENT entry for the same UUID is changed, setting the logout time stamp on that and perhaps even setting the online status of that different entry to false (it already was false in fact) but leaving the original one and the one that will be checked on next login stuck as "online".

Could we make the logout code find the same entry as the login one and set that?

But if that is too difficult, how about a bit more brute force... set the logout time stamp and online status to False for ALL entries matching the UUID. That would do not harm since I am sure we could not have several avatars from multiple clones grids with same avatar UUID online at same time.. THAT would make a real mess.

2020-11-20 11:02   
(edited on: 2020-11-20 12:30)
yes i made code to try to use login timestamp as the selector in case of duplicators.
current selector just uses the longest uui string.. whatever that means

but just didn't commit
to see the db do a full search with sql UserID LIKE '{0}% for the most uses cases..

i had good reasons to avoid looking to HG or even robust code
now im forced to look..
well hopeless

2020-11-20 12:25   
(edited on: 2020-11-20 12:29)
Surely not hopeless.

The problem just now for avatars whose grid uses :80 assumed in some places is that login modifies the griduser data base entry on one variant (the longer one) and logout modifies the OTHER griduser data base entry (the shorter one missing the :80). So when the next login comes along the longer entry is again checked and shows it shows the status as Online=True still.

We just need the code for login AND logout to use whatever is chosen but ONLY one variants, not do login with one and the logout with the other.

This is what an OSGrid avatar looks like to the griduser datqa base entries on the destination grid after it has visited once and returned home back to OSGrid (or gone anywhere lese actually). Note the timestamps and how they are mispaired (login at 1605903402 and logout at 1605903414, but on different records).

e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, 00000000-0000-0000-0000-000000000000, <0,0,0>, <0,0,0>, 46d2006b-4531-4f77-a2bb-f785d416ae03, <127.9992, 127.9977, 25.97432>, <-0.3487187, -0.9372275, 0>, False, 0, 1605903414

e858df02-a860-4b92-937a-2b87e4ebcd6d;;Ai [^] Austin, 00000000-0000-0000-0000-000000000000, <0,0,0>, <0,0,0>, 98b848b4-64c0-4f07-a4a2-9e92b75cb106, <124.8621, 124.645, 31.91814>, <-0.9373071, -0.3485048, 0>, True, 1605903402, 1605821629

2020-11-20 12:46   
(edited on: 2020-11-20 12:49)
public GridUserInfo LoggedIn(string userID)
public bool LoggedOut(string userID, UUID sessionID, UUID regionID, Vector3 lastPosition, Vector3 lastLookAt)

incoerent griduserservice api

and currently on login and logout 2 services need to be informed, and are not on all code paths
not to mention the waste of 2 full http calls, etc

2020-11-20 12:51   
>> current selector just uses the longest uuid string

That will fail often in cases where multiple entries exist as longer UUID string record is stuck as Online=True after going to a grid and away. Logout and the change to Online=False is recorded on the shorter string variant (the one without:80 anyway).

>> I made code to try to use login timestamp as the selector in case of duplicators.

That would work as the login time stamp on the shorter UUID record (without the :80 port) is always 0, but the best fix would be to make the login, logout and Online boolean changes on the same record.

2020-11-20 12:55   
>> I made code to try to use login timestamp as the selector in case of duplicators.

Having said that, that code could be a temporary fix at least unless you see some other issue with introducing it.
2020-11-20 12:55   
(edited on: 2020-11-20 12:59)
no the fix would be to only use the uuid, that must be unique, and can make use of dbs hashed searchs.
the rest of data there is a helper needed, but data, not full identifiers

no idea why it was considered they need to be part of the id, and used like that all over HG ( friends, groups v2, etc )
possible a id needs to be part of that.. can't tell
at least like cinder said on other mantis the schema 'http' could not be part of it
and im totally blocked on that.

2020-11-20 16:20   
(edited on: 2020-11-21 01:17)
changed griduserservice to try to use the most recent entry
added cache to compensate for the very low performance of the search the db engine is force do to.
Current Diva Wifi is now broken, if it wasn't before.
If it still runs, it will replace this code, using old methods

this needs testing and OSgrid currently may not be the right place for it.

as consequence of this change, some hg users may had lost home region setting.. or not..

2020-11-21 06:57   
Testing now on Ailand grid [^] and that looks like it has resolved the issue when teleporting into and returning later from OSGrid to AiLand with the changed code. I tested this without Diva Wifi first.

I added back Diva Wifi as it was last released for still works fine in OpenSim dev master as at 21-Nov-2020 03:30. But as noted by Ubit the fix for this issue is then reversed. Using the latest dev master therefore leaves grids with Diva Wifi front ends no worse off.

Hopefully the Diva Wifi code can be brought into sync with the changed code when is fully released, as Diva's policy up to now has been only to update on full stable releases.

Gezebu MindBlue   
2020-11-21 17:42   
(edited on: 2020-11-21 17:45)
A while ago I downloaded the latest version of git, and installed it on standalone and osgrid.
the first teleportation tests have not given good results.

initially I could go from my standalone under robust to osgrid, but when I returned to, go to, when I returned home and tried to go again to osgrid (I was restarting the osgrid server while doing these things), I could not go again to osgrid receiving the message that started this report:

22:14:07 - [USER AGENT SERVICE]: Unable to login user Gezebu MindBlue to grid, [^] reason: You appear to be already logged in on the destination grid Please wait a a minute or two and retry. If this takes longer than a few minutes please contact the grid owner.

then i tried to go with my osgrid account to my standalone and that is still not possible. i jumped back to greatcanadiangrid from osgrid, and by doing ctrl+shift+h, it was not possible to go back to osgrid home. but it was possible to jump to lbsa plaza by entering hg.osgrid:80 in the map.

Version: OpenSim Yeti Dev 28f5bfe (SIMULATION/0.3 - SIMULATION/0.8)

the two accounts have the same name Gezebu Mindblue, but different uuid

2020-11-22 01:23   
(edited on: 2020-11-22 01:24)
Remember these issues are related to some things which are done in the Robust core servers and hence updating your OSGrid REGION add on OpenSim.exe instance to the latest dev master code will not be a good test, as Ubit indicated. That must wait until the core services of Osgrid are updated which might take a while. Tests are better done on the Dev Master code as updated on 21-Nov-2020 on grids you know are fully updated at the Robust and region levels.

2020-11-22 06:33   
This works fine now.

Grids operating on older Robust code may exhibit the behaviour described in this Mantis issue until they are updated.

Diva Wifi for still compiles and operates with the modified dev master code as at 21-Nov-2010 code, but will override the corrected functions so will exhibit the behaviour described in this Mantis issue.