Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008929opensim[GRID] Inventory Servicepublic2021-09-15 00:442021-09-19 16:32
ReporterJagga Meredith 
Assigned ToUbitUmarov 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOperating SystemOperating System Version
Product Version0.9.1.0 
Target VersionFixed in Version 
Summary0008929: cannot retrieve region data from landmark
DescriptionOSTeleportAgent allows you to TP directly to a region, parcel and location, facing a certain direction (some viewers). This can be done by region address...

osTeleportAgent(key agent, integer regionX, integer regionY, vector position, vector lookat)

...or region name...

osTeleportAgent(key agent, string regionName, vector position, vector lookat).

We have a function to retrieve data from a landmark..

Function: key llRequestInventoryData( string name );

which calls the dataserver which returns...

llRequestInventoryData Landmark (vector) The vector data received by dataserver is an offset from <0,0,0> of the current region.

There is a notation...

"To obtain the global position of a landmark add llGetRegionCorner()." but it's unclear what "add" is supposed to mean, and I don't believe this will return anything useful to OSTeleportAgent.

What's needed is for the dataserver to return the region information.
Additional InformationThis code appears germane (provided by Ubit)
################################
AssetLandmark lm = new AssetLandmark(a);
                            if(lm != null)
                            {
                                float rx = (uint)(lm.RegionHandle >> 32);
                                float ry = (uint)lm.RegionHandle;
                                Vector3 region = new Vector3(World.RegionInfo.WorldLocX, World.RegionInfo.WorldLocY, 0);
                                region = lm.Position + new Vector3(rx, ry, 0) - region;
                                reply = region.ToString();

################

I'm betting WorldLocX and WorldLocY are what I'm looking for
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script EngineXEngine
EnvironmentUnknown
Mono VersionNone
Viewer
Attached Filespatch file icon 0096-Use-GridService-for-osTeleportAgent-location.patch [^] (1,771 bytes) 2021-09-16 00:42 [Show Content]

- Relationships

-  Notes
(0037943)
tampa (reporter)
2021-09-15 01:12

So in the region table we place each region at the absolute position in meters, which then means if you want to know the coordinate on the grid, the one you can enable in FS to show on map tiles, you divide by 256. Result is a region at 1792000,1792000 is actually at 7000,7000.

The data in the landmark is the offset from this region to the destination region. With llGetRegionCorner you can fetch the global position of the region you are in, to that you add the data from the landmark and divide by 256 again, voila that's the coordinate the region is registered in. That's iirc what you need to supply to AgentTeleport to go to that region. Could be that you don't even need to divide, not entirely sure never teleported by coordinate.

I suppose we currently don't sport a function that could equate a region coordinate to its name for use with AgentTeleport, which would probably be less confusing since you could test if the landmark inventory name matches the region name... then again not everyone names them after their region either.

Adding a function to do this all at once and just spit out the coordinate or region name would probably not be difficult to add, but also particularly necessary as shown above. So this isn't really a bug I can see unless there is some wrong returns with any of the mentioned functions. Remember mantis is not a ticket system or user forum, it's a bug tracker. :)
(0037944)
djphil (reporter)
2021-09-15 01:52

Exemple : https://forums.osgrid.org/viewtopic.php?p=27279#p27279 [^]

Of course llGetRegionName() can help you too.

And http://opensimulator.org/wiki/OsGetInventoryDesc [^] seems sufficient to me to obtain the information of a valid landmark.

But as Tampa says, it is advisable to use the Forum / Scripts for a request like this.
(0037945)
Jagga Meredith (reporter)
2021-09-15 10:12
edited on: 2021-09-15 10:17

Well, Ubit is the one who said to submit it as a feature request so talk to him.

llGetRegionName() and llGetRegionCorner() return the values for the region I'm in. I need the values for the region I want to go to.

    dataserver( key vKeyNull, string vStrData )
  {
     llSay(0,vStrData);
     vecrel=llGetRegionCorner();
     llSay(0,"region corner "+ (string)vecrel);
     RegionX=vecrel.x;
     RegionY=vecrel.y;
     vecloc=(vector)vStrData;
      osTeleportAgent(touched, llRound(RegionX)/256, llRound(RegionY)/256, vecloc, SE );
  }

...which returns...

[09:42] tp test 2 debug: <-2372.125, -592.375, 50.01636>
[09:42] tp test 2 debug: region corner <309504.000000, 308224.000000, 0.000000>

...and when I do the arithmetic the region corner is the coordinates for the region I'm in.

The teleport works as documented and plonks me in the region corner indicated (the one I'm in) and the correct coortdinates in that region (which comes as a bit of a shock to bystanders when I end up in their back yard instead of the mall in a completely different region I'm trying to get to).

So, again, I need a new feature, a way of extracting the X,Y coordinates of the landmark's region I'm trying to get to, not the one I'm in. Just to make it clear, this is a HUD I'm carrying around.

Incidentally, osGetInventoryDesc() returns "@ http://login.aviworlds.com:8002"...which [^] is nice to have but not germane.

I suppose another solution is to modify llGetRegionCorner to let me pass the region handle.

(0037947)
djphil (reporter)
2021-09-15 10:59

http://wiki.secondlife.com/wiki/LlRequestInventoryData [^] not making you happy?
(0037948)
UbitUmarov (administrator)
2021-09-15 11:38

in fact llTeleport already does teleports to landmarks
and does it with proper permissions control.

http://wiki.secondlife.com/wiki/LlTeleportAgent [^]
(0037949)
djphil (reporter)
2021-09-15 11:41
edited on: 2021-09-15 11:42

Yes exactly !

and

osTeleportAgent(USER_UUID, "login.aviworlds.com:8002:" + REGION_NAME, LANDING_POINT, ZERO_VECTOR);

work perfecly too.

(0037950)
UbitUmarov (administrator)
2021-09-15 13:06

did some changes to llTeleport so it should do HG lms now
(0037951)
tampa (reporter)
2021-09-15 23:11

Think the problem with osTeleportAgent is that for var regions only the main coordinate the region is registered under is used aka southwest. The function cannot fetch the region to teleport to if any of the other occupied regions is used as coordinate.

[22:24] Object: LM data: <-380499.6, -199538.3, 22.22348>
[22:24] Object: Current position: <2264064.000000, 1985280.000000, 0.000000>
[22:24] Object: Absolute region coordinate: 1883392 , 1785600
[22:24] Object: Grid coordinate: 7357 , 6975

The region is registered at 7354 , 6975 however, so teleport fails with region not found.

The reason seems to be that osTeleportAgent uses:
Util.RegionGridLocToHandle((uint)regionGridX, (uint)regionGridY);

This works by doing math on the position, which then results in the handle. This works only when the registered coordinate is used. A better option, although heavier would be to also attempt to contact the Grid Service and request region by position, which does work with var regions.

The problem there is that by nature of that function it will convert the position to the handle regardless and thus there is no way to be sure whether the handle exists or not without asking the grid service. This is because the teleport itself is a fire and forget type deal and does not give feedback to the function as to whether it found the region or not.

Even patching that still does not solve the problem of getting the local location for the teleport. It will get you there, but will place you within the southwest corner of the var region, but at least it will get you there.

In order to fully get the correct position and local position best would be to add some functions for getting the region name based on its coordinates on the grid. From there you then need a function to get the corner of that region and then you can figure out the local position on the region itself and properly supply coordinates for teleport.

I guess you could get region corner by finding which region the coordinate is in and directly transform the global position into the region corner, but going over the name you can also check you are selecting the correct location and you can use it for teleport rather than global coordinates. I did implement a few more functions to get remote region data via the grid service. Obviously those functions are heavier than just math on the region position.
(0037952)
UbitUmarov (administrator)
2021-09-16 05:04

Since 0.9.0.0 handlers are not just reference corner points for region search.
Doing correct math does help and seems that was not the case above.
"Current position" is irrelevant unless it means current region corner, in that case the math is wrong, not 0.9x search.
(0037953)
UbitUmarov (administrator)
2021-09-16 05:11

To answer to this mantis actual description: "cannot retrieve region data from landmark"
That is not possible or that useful because landmarks
are created by viewers and not that equal. Some still just have the basic for SL use. Region code needs to handle those differences where possible. Region name for example is not part of its data.
(0037954)
tampa (reporter)
2021-09-16 08:11

After some back and forth I did manage to get the teleport to work, which seems to confirm that it does indeed find the region via the handle even if it is a var region.

There is still an issue with teleporting offset as for some reason you end up at 128,128 if you attempt to teleport to a var region even with an offset and correct regionHandle, which should put you into the correct spot of the var region and offset, but something in the viewer prevents this from happening. As to why I got no idea, but this is nothing new given telehubs beyond 256,256 are known to not work, especially over HG.

Also there is some really weird caching going on if you change the offset you often end up at the same spot as before. Alas code below should work to retrieve LM data and teleport to the correct region and offset.

key tempkey;
default
{
    touch_start(integer touche)
    {
        llRequestInventoryData("Home");
        tempkey = llDetectedKey(0);
    }
    dataserver(key id, string data)
    {
        llOwnerSay("LM data: " + data);
        vector newpos = (vector)data;
        vector curpos = llGetRegionCorner();
        llOwnerSay("Current position: " + (string)curpos);
        float nX = (curpos.x + newpos.x);
        float nY = (curpos.y + newpos.y);
        float nZ = curpos.z + newpos.z;
        llOwnerSay("Absolute region coordinate: " + (integer)nX + " , " + (integer)nY);
        llOwnerSay("Grid coordinate: " + (integer)(nX/256) + " , " + (integer)(nY/256));
        vector locpos = <(curpos.x + newpos.x)%256,(curpos.y + newpos.y)%256,nZ>; //This only works if the region is not a var
        osTeleportAgent(tempkey, nX/256, nY/256, locpos, <0,0,0>); //Teleports to var region, but does not offset to the correct spot
    }
}
(0037955)
UbitUmarov (administrator)
2021-09-16 12:51

Thanks for the patch, but it does nothing useful, but possible saving a few operations.
(0037956)
tampa (reporter)
2021-09-16 13:00

Which reflects a bit in timing from what I can tell. It does away with regionHandle in that it would change the required offset of local position to be always the region corner, which you cannot get remotely. regionHandle does seem to work with var regions, but not reliably.

There is something funky going on with the viewer rejecting the offset and going to 128,128 instead or, on quick teleports back and forth, returning to the same position instead of obeying a changed offset value.

Not conclusive from code as to why so this seems to be a viewer issue. Recent implementation of direct vector to new region, doing away with the local position offset, is nice addition, though it may have some trouble with very low region coordinates, though you are not really supposed to place regions in places where it would be.

Curious case this. Ultimately though beyond some glitchy behavior I am not seeing a bug here per se.
(0037967)
Jagga Meredith (reporter)
2021-09-17 04:21

Thanks for all the responses to this.

Point of order - I never intended this to be a bug report, but a feature request, however wasn't aware of how to do one ("[Feature Request]"(?)) but did set the severity drop-down to "Feature" which I thought would do the trick.

I have been fiddling around with llTeleportAgent but it's been saying either "region does not exist" or attempting to teleport and failing (without error that I've been able to discover), or messing up my viewer to the point where I have to reboot. Will try again with simpler code and work my way up.

On my last attempt, when I restarted viewer, I was able to successfully rez in a region, but when attempting to TP using a landmark somewhere else it's reporting

"Teleport failed.
Previous teleport process incomplete. Please retry shortly."

Tried my HUD which uses osTeleportAgent - same result.

I've also noticed the occasional landing on 128,128 error to the point where I put a landing pad on my region there because I'm terrified of water RL and was getting flustered being dumped in the drink. I'm seeing this on FS but not noticed it on other viewers.
(0037973)
Jagga Meredith (reporter)
2021-09-19 16:04

OK, this is interesting. Put Tampa's code into an object, had to add two llRounds to get it to work.

osTeleportAgent(tempkey, llRound(nX/256), llRound(nY/256), locpos, <0,0,0>);

Used a working LM of mine. Opensim 0.9.1,1.

Returns...

[15:56] tp tester: LM data: <-2413.156, -658.6875, 35.06644>
[15:56] tp tester: Current position: <309504.000000, 308224.000000, 0.000000>
[15:56] tp tester: Absolute region coordinate: 307090 , 307565
[15:56] tp tester: Grid coordinate: 1199 , 1201

Every time I click on it I get the...

"Teleport failed.
Previous teleport process incomplete. Please retry shortly."

...message and can't TP anywhere with any viewer. This includes maps, my code using llTeleportAgent, double-click TP, TP invite, LM's

Using an off-grid LM returns ...

"Teleport failed.
Agent already in transit."

Relogging sometimes fixes it, not sure if clearing cache helps, I think it's just multiple re-logging may be doing it as I don't think multiple viewers are sharing the same cache.
(0037974)
UbitUmarov (administrator)
2021-09-19 16:32
edited on: 2021-09-19 16:41

llTeleport does teleport from landmarks (subject to target permission), so no need for a new feature.

Please ignore the math on most posts. Most is just wrong on that context

http://wiki.secondlife.com/wiki/LlTeleportAgent [^] (in opensim lookAt is a direction not a position)
http://opensimulator.org/wiki/OsTeleportAgent [^]


- Issue History
Date Modified Username Field Change
2021-09-15 00:44 Jagga Meredith New Issue
2021-09-15 01:12 tampa Note Added: 0037943
2021-09-15 01:52 djphil Note Added: 0037944
2021-09-15 10:12 Jagga Meredith Note Added: 0037945
2021-09-15 10:17 Jagga Meredith Note Edited: 0037945 View Revisions
2021-09-15 10:59 djphil Note Added: 0037947
2021-09-15 11:38 UbitUmarov Note Added: 0037948
2021-09-15 11:41 djphil Note Added: 0037949
2021-09-15 11:41 djphil Note Edited: 0037949 View Revisions
2021-09-15 11:42 djphil Note Edited: 0037949 View Revisions
2021-09-15 13:06 UbitUmarov Note Added: 0037950
2021-09-15 23:11 tampa Note Added: 0037951
2021-09-16 00:41 tampa File Added: 0096-Use-GridService-for-osTeleportAgent-location.patch
2021-09-16 00:41 tampa File Deleted: 0096-Use-GridService-for-osTeleportAgent-location.patch
2021-09-16 00:42 tampa File Added: 0096-Use-GridService-for-osTeleportAgent-location.patch
2021-09-16 05:04 UbitUmarov Note Added: 0037952
2021-09-16 05:11 UbitUmarov Note Added: 0037953
2021-09-16 08:11 tampa Note Added: 0037954
2021-09-16 12:51 UbitUmarov Note Added: 0037955
2021-09-16 13:00 tampa Note Added: 0037956
2021-09-17 04:21 Jagga Meredith Note Added: 0037967
2021-09-19 16:04 Jagga Meredith Note Added: 0037973
2021-09-19 16:32 UbitUmarov Note Added: 0037974
2021-09-19 16:32 UbitUmarov Status new => closed
2021-09-19 16:32 UbitUmarov Assigned To => UbitUmarov
2021-09-19 16:32 UbitUmarov Resolution open => fixed
2021-09-19 16:40 UbitUmarov Note Edited: 0037974 View Revisions
2021-09-19 16:41 UbitUmarov Note Edited: 0037974 View Revisions


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker