Teleportation, Landing points, logging into last location

[emperorstarfinder]

So while doing some testing I seem to have stumbled on a couple of rather strange (or perhaps not so strange) issues.

1. Teleportation using world map - When doing a teleport via world map in the viewer (for this purpose we shall say from Parcel 1 located in Region A to Parcel 2 located in Region B, when a landing point is set in Parcel B it appears the function of teleporting using the world map is not respecting a landing point that is set in the parcel details. In testing other architectures which at one time also had opensim code (I know halcyon went away from Opensim in 2010 so we don't go down that rabbit hole here), it appears this problem carried over to them as well. Perhaps this is one of those known carry-overs that wasn't known?

2. When logging out (any viewer appears to produce this) from say a platform at z: 1500 above land and then logging back in the last position is incorrect. In my tests I actually logged back in to being underwater underneath the dock on Region A. The platform I logged out from is in Region B. This also appears to cause trouble with viewers logging in as it complained it couldn't log in and then when I did attempt number 2 to log in it actually did log in. Perhaps a bug of some kind?

[appurist]

1. I'm not aware of any issues with the landing point code, but it's a bit complex so sometimes it behaves unexpectedly. First, it won't force the landing point set unless the teleport routing option is set to Landing Point. But there are other cases too, such as a TP lure/invite, or if the avatar is already inside the parcel. (The landing point is only applied to avatars entering the parcel.) This allows an avatar to further refine the destination once the LP has been applied. Generally it's only applied for LMs and URLs (world map), however, you're specifically mentioning the world map so that is one of the cases it should apply to, assuming the parcel has the teleport routing set to Landing Point.

2. That sounds more like your last location didn't get updated on the logout. This can happen if the viewer crashes at logout or the connection to the server was lost. There's a fairly significant problem with the avatar location protocol where the update to the central grid services does not include the region, just the x/y/z position. So if there's a problem with the logout, it may have the correct position but the wrong region. It would be good to know if you had experienced a problem either with the teleport to B or with the logout (or disconnect) from B. I'd love to fix the protocol issue but it's a relatively low priority given that it seems like it's only a problem when there is another problem (e.g. viewer crash or disconnect) and the cause of those issues is likely one of the items that is already one of our top priorities. Also, there's no lasting damage, just teleporting to the correct location resolves the problem.

[emperorstarfinder]

The landing point routing was set to landing point which was interesting so I suspect this is something in the protocol either in world map or teleportation but as for 1 this would need to be dug into a bit deeper I think. When teleporting via landmark this appears to be ok so its something in the world map area of the protocol.

On number 2.

There wasn't a viewer crash or loss of connection to the server that I am aware of. I have set up a test so when I log in again I will be on the land and not on the platform to see if there is some very strange issue with last location being above land (admittedly though I would be apt to think that wouldn't have much affect). When I logged in last time my last location was on the platform which on try one it came back with login failed even though the site side said i was online. logged in again and i was able to log in-world. On the first guess one would think there is connectivity issues going on, however interestingly the region was online the entire time. I have a little digging to do myself to see if perhaps regions are just not syncing with grid and db services fully which might cause it but I am suspicious of that at the moment.

[appurist]

1. Okay, I'll do some tests on the landing point option.

2. My normal home location for my Jim InWorldz account is on a platform at about 5100m. I don't remember not landing there on a relog, and I just tried another relog again without issue. The unexpected location is not just on the ground, but actually in the wrong region? (So it's not a possible matter of possibly starting in the correct location but falling through the platform prim on login?)

[emperorstarfinder]

Well the interesting piece to this (i might have muddied the waters in my description) is that the platform is in Region B. When I logged in I landed up under water literally under my dock in Region A. Region A has the landing point set to the middle of the dock on the actual dock.

The only thing I can think of is that regions are coming out of sync but I have yet to find any evidence of it as the regions that are supposed to be online are all clearly online.

EDIT:

Just attempted again and the login failed error came up even though the grid and region services were all up and the second login attempt worked and logged in landing in a different region other then the platform. So my guess here is we are dealing with information that either isn't getting stored somewhere or the info about the user's last known location is not getting passed to the viewer perhaps causing the hang at login step causing the crash even before it can contact the region.

[appurist]

1. The forced landing point code does not apply to god users, estate managers, estate owners and the partners of estate owners. Are you testing with one of those?

[emperorstarfinder]

Not really sure what the service would consider the partner of an estate owner for the purpose of teleporting but this in fact is duplicated with any normal user regardless of god level or not.

[appurist]

I forgot to mention that the bypass also applies to the owner of the land parcel.

Treating the partner of an estate owner as EO equivalent on a few things has been one of the most requested features, especially due to the restrictions on scenic regions. All estate owner checks were reviewed and any exemptions that applied to an EO were also applied to the partner of the EO, where possible. It makes sense for the business case in InWorldz, it may have little technical benefit otherwise.

Are you teleporting from a different region and bypassing the Landing Point, or teleporting within the same region? (Code paths are a bit different.)

[emperorstarfinder]

Okay I think we need to clarify what exactly the partner of the estate owner is as that seems confusing.

However I have not tried teleporting from one point to another within the same region using the world map but I suspect we might get the same result. I will test that theory when I log in in a few minutes.

However using my earlier example any normal user teleporting using the world map from a parcel on Region B to Region A did not respect the landing point having been set in Region A. (Region A the parcel is the entire region as it is the welcome region).

[emperorstarfinder]

A quick update:

When testing the teleportation via world map from one location to another in the region with the landing point set correctly for the parcel, the actual landing point of the avatar on completion of the teleport was off. In this test I teleported from the edge of the region using the world map (simple search function on the world map in the viewer), I landed under my dock under water even though the actual landing point for the parcel is set to land on the actual dock. The teleport routing is in fact set to landing point for the parcel.

[appurist]

I think I'm going to need the location of that Landing Point on the dock? So that I can check the parcel settings and test the specific conditions here to see what's up.

[appurist]

(Region A the parcel is the entire region as it is the welcome region).

I just remembered that you had mentioned a welcome region. I just want to mention that logins to a welcome region are a special case. Halcyon makes use of two files for configuring logins: defaultlogins.txt and defaultregions.txt. The first (defaultlogins.txt) is for first-time users who haven't logged in before (they have no previous login location). This is a file with the newbie welcome locations. The second (defaultregions.txt) is a list of locations where returning users are sent if their last login location isn't available and their home isn't available.

Both files are in a format of a list of locations, each on a line by itself, containing a location in region/x/y/z format. For example:

Welcome/127/127/25
Welcome/127/129/25
Welcome/129/127/25
Welcome/129/129/25

You can specify more than one region:

Welcome/127/127/25
Other/127/127/25
Welcome/127/129/25
Other/127/129/25
Welcome/129/127/25
Other/129/127/25
Welcome/129/129/25
Other/129/129/25

I don't think any of this is affected by landing points but I want to point out that logins are handled very differently from other parcel entries.

If there's only one parcel (region-wide) in your region A, then that means a teleport from another region to anywhere in that region should be hitting that Landing Point, but not a teleport from within the region (it should take you directly to the TP destination).

[emperorstarfinder]

I think I'm going to need the location of that Landing Point on the dock? So that I can check the parcel settings and test the specific conditions here to see what's up.

The default position of the dock's landing point (middle of the dock) is 128/128/21 (as it is just above the water line as we lowered the terrain on that part. ) In theory that shouldnt matter to much.

In Re: defaultlogins.txt and defaultregions.txt, I will check those just to be sure something wasn't forgotten somehow. The Welcome region has one parcel region-wide.

The platform in Parcel B has a landing point of 128/128/1500 as it is 1500 meters above the land.

To get to the platform in Region B, a landmark is needed but there is not any landing points set in that particular region. It is almost as if for some strange region the position isn't recognized (or updated as we discussed) on logout and login. I did do a test by landing on the land and logging out and back in and that appears to update and work correctly. SO this is just a case of something not updating if its above the land.

[emperorstarfinder]

Update: I did a quick check and found that the defaultlogins.txt and defaultregions.txt were in fact set correctly. So this isn't likely the cause. I will make sure these are added to each of the region VMs to be sure.

[appurist]

I probably wasn't very clear there, the two txt files are only used by the User grid service, so they would only be recognized in the bin folder for your central grid services (User, Grid, Messaging). They define which regions that the User login service should send logins to. So they only need to be placed in one folder. My main purpose in mentioning them was actually that they could affect the placement of an avatar on a login (but not on a teleport).

SO this is just a case of something not updating if its above the land.

The server isn't really aware of that as any kind of separate case. It's just the avatar position. I can't think of any code, other than banned height usage, that would care what z position the avatar was in. I think what might be happening here instead is just that you're using a teleport so there are two different positions and it's perhaps failing, or disconnecting, or some other error, and then it's updating the position but not the region, because of the protocol problem I mentioned in my first reply.

I think the next step would normally be for me to go there and try it and see for myself, but if this is a different grid, that's probably not possible. Alternatively, you could send me each of the two Halcyon.log files from the two regions, renamed to From.log and To.log or something like that so I know which is which, and then tell me the time in of the teleport attempt followed by the relog so that I can check the log files.

[emperorstarfinder]

Sadly the first thing I checked was the logs. In any log level (info, debug, etc) there were no clues given as to what was going on. You can always create an account on the grid. I can email you the grid info for viewers etc.

I even watched the region consoles during teleportation to see if anything was going wrong but even that didn't give any clues. Oddly however when the login attempt fails it still claims the user is online because the grid, user, messaging service thinks the user is online when they really aren't.

[appurist]

If a login attempt fails due to a connection abort (one way or another), it will claim the user session is still logged in. It may time out after some time, I can't quite remember if that happens now or not. And whatever problem caused that is probably causing the last login region/position confusion in the server. Also just want to mention that logging back in after one of these is not going to have landing points applied, in case that wasn't clear.

If you can email me either credentials to log in with or a link to a registration page (if available), I'll take a closer look myself and try some tests. You can email to jim AT gridmail DOT org. (I don't like to put in email addresses for the spammer scrapers to find).

[emperorstarfinder]

Email sent.

I also provided a bit extra detail for you as well in email that I can't provide here due to my team;'s NDA rules.

[appurist]

Sorry I haven't provided any updates on this. It has been an extremely busy time for me and I haven't had a chance to try the other grid, and I've been unable to reproduce the symptoms in my tests so far on my own. Hoping to be able to come back to this over the weekend or next week.

[emperorstarfinder]

Not to worry. I actually forgot about it as I was doing some cleaning in the code base myself. i.e. putting using references in proper order, etc. I will be round about the grid throughout the day working on things that need to get done.

[emperorstarfinder]

My apologies for not updating the status on this issue, in fact, I forgot it was open.

Part of the problem here I have fixed. It turns out while setting up my team's Halcyon Test grid (which we do have one set up), I managed to forget to increase the number of vCPUs in the virtual machines from one to a minimum of 2. Usually, this is something I do not forget to do but it can be attributed to long hours during the setup process.

Another part was an incorrect IP address set in the MessageServer_Config.xml file (it was because I was tired that day after working long hours to get things online)..

These two corrections appear to have stopped the failure to find the last location when a user logs in. However, I stumbled on another interesting error thrown by the region consoles when starting regions up:

[INVENTORY TRANSFER]: No Message transfer module found, transfers will be local only

I have double checked everything in all of the configuration files for the test grid, and all is correct here. Perhaps this is something missing from the Halcyon.ini (as mine matches what is in the example ini file for Halcyon now, or potentially something pointing wrong in the code?

Additionally, the world map (in the viewers appears to be in Firestorm and Singularity Alpha at the moment) regions appear to be coming up as unknown even though the grid is finding their correct locations on the world map.

I also have run into users showing up as online even though they are clearly not logged in. This may or may not be due to the MessageTransferModule issue (though I think its more likely something with the IsOnline status logic). So far the MyWorld site Vinhold created here thinks users are online that aren't along with viewers (Latest Firestorm, Singularity Alpha Build, Have not tested other viewers yet). Additionally, I logged into InWorldz the other night, to see if it occurred there as well and found that it was happening there as well.

It may be this is just some configuration matter but I have gone through the configuration files and am pretty confident this is not the issue. However just to verify that the grid server port should, in fact, be 8009? Usually, I have found architectures using Ports 8002 and 8003 with Economy set to 8009.

Will advise further if I find anything that is the cause locally.

[Ana-Green]

While doing some testing I seem to have stumbled on somewhat the same issues as emperorstarfinder on a couple of rather strange (or perhaps not so strange) issues. It also has to do with Map teleportation from Region A to Region B, I am on Region A and open the map do a search to find Region B find/teleport I end up under the floor of my temple at Z = 2, the Landings point (fixed) was completely ignored at the Z height. But with te next teleport I saw on the map the right region but the X, Y, Z was not correct its had to say 113, 181, 21 but did show 128, 128, 2 the Z is way to low, this can be duplicated just do a search or find and if found look at the X, Y, Z. 2) If you raise the Z by hand to 22 and teleport then you'll not be under water, also LM's are not effected. And as the defaultlogins.txt and defaultregions.txt files are in the BIN they have nothing to do with Region A 9501 to Region B 9502 see pictures. And here the correct Landings point: Note :: "In testing other architectures which at one time also had opensim code (I know halcyon went away from Opensim in 2010 so we don't go down that rabbit hole here)" In the opensim code the teleport went wrong (like this) if the region owner in that case requested God Mode, as soon she /he had done so they got the same issues, the X, Y, Z went off. May this did help. However after 8.3 to 0.9.x this was fixed, and gone. Maybe this did help.

All the best Ana Green

[emperorstarfinder]

defaultlogins.txt and defaultregions.txt, from what I understand, is the vehicle Halcyon uses to provide a default location and fallback regions for first-time logins and to allow users to log in when their last location is not currently online. So I am not sure that is part of the issue here. Likewise, according to what I have read in the configurations wiki and per discussions with Vinhold it sounds like most people are changing the name of the bin folder especially if they run multiple regions, so I am reluctant to say that this would affect that as I suspect that wouldn't.

As to changing the z position before teleporting via the world map, yes one could do that to land above water as well.

The actual issue found here is that the world map appears not to recognize the landing points that have been set in the parcel info. In this case, the parcel consumed the entire region. So I believe the question is whether the world map is able to distinguish whether one or more parcels are present on the region and determine which parcel you are trying to teleport to on that region via the world map (this might be part of the case) or if it is just simply ignoring this info. I am however very glad to see someone else has confirmed this so I at least know I didn't just stumble on some odd thing that is not reproducible.

[Ana-Green]

you are welcome and everybody can reproduce this just log in on my test grid and you are on my welcome area, you decide to teleport to The Lost Temple what has his landings point set to 113, 181, 21 then you simple open the map and type The Lost Temple not looking at the X, Y, Z you hit teleport and you find yourself under water. The next time you look at the X, Y, Z you enter again The Lost Temple but now looking at the X, Y, Z, there you see 128, 128, 2 not 113, 181, 21 and the same happens with every region, you can of course also reproduce this on your own grid, but there are now two people emperorstarfinder and me who stumble on some odd issue, we have to look at this closer I just said as hint on opensim they had the same (but only with God Mode Activated) and solved it but that was on version 8.1.0, 8.2.0, 8.2.1, 8.3.0 to give an indication on the timeline on 0.9.0 it was completely solved.

https://www.dreamcastle-entertainment.eu/default.aspx

All the best Ana Green

[Vinhold]

I have just used the world map to teleport from Ana's Welcome region to the temple region specifically selecting a spot on the dock. I landed at the LP point forced correctly. However the land is Grid Owner only, not group. As Land Owner, the LP does not apply and that account can land anywhere selected on the region.

[emperorstarfinder]

I believe that is probably normal for the grid owner or landowner actually but LP should be controlling where other users land (similar to what it does in Secondlife). I will need to do some digging on this to figure out what the end result is and what it really should be.

[Vinhold]

It forced me to land at the LP from a world map selection for a different spot to land at. So this appears to be normal operation expected.

[appurist]

The way it is supposed to work, and works in my tests, is that landing points are enforced when entering a new land parcel (which includes entering new region). This is not enforced for estate owner, estate manager and god users at level 200 or higher, and it is not enforced for a teleport "lure" (TP invite by another user).

By only enforcing it (conditionally) on a new parcel entry, this guides a user to the landing point but then allows the user to teleport to a desired location within the parcel by repeating the teleport request.

[emperorstarfinder]

Well the way it should be working from what I can tell is enforcement does not happen for GodLevel users, Estate Owners, Estate Managers, Parcel Owners (might include group owners but I am not sure about that just yet), Teleport Lures (someone sends you a teleport), and scripts that do teleportation to various locations. Which this I don't have a concern about as this would in fact likely be normal even in Secondlife.

However in my tests using a normal user who does not meet any of the conditions above, lands in the wrong place which, in fact, lands in the place selected on the World Map itself. The set landing point is intended to control people from just landing anywhere (like in the middle of a home). So this makes me wonder if the world map is even actually checking to see if there is a landing point. It might even be that the teleportation logic is checking and just not passing that information on. I also checked this on Secondlife to see if it is just a viewer problem and there it does not appear there is conditional enforcement other then the conditions mentioned above. For a normal user who does not meet those conditions, it seems to land them at the landing point if one is defined on the parcel.

If by conditionally enforced you mean the levels I mentioned at the beginning of this response then okay that makes some sense. However, the issue here is that this was a normal user coming to the parcel (and thus the region) so this would be the new parcel entry so it should have set the normal user at the landing point.

By default the world map defaults to the position of 128, 128, 0 (exact center of the region) unless the terrain is higher then the water level (in most cases if the terrain has not been terraformed higher 128, 128, 22).

The next test I will do is hook up the viewer to WinGridProxy (was originally done by libOpenMetaverse) and log in and test. WinGridProxy will provide information that is being sent and received from the grid and viewer via the packets. This will help reveal issues in many cases.

Will advise further as to what further testing provides.

[appurist]

I think you really just need to try some tests with a generic user account (alt), from a different parcel. Vinhold's tests with an unpriviledged account seemed to put the user in the expected location. I've spelled out the conditions where it does not force the account, and pointed out the feature that even when it does enforce the landing point location, it does not enforce it for repeated teleports from within the destination parcel. Perhaps this is where the unexpected behavior lies: you can only test landing points from a different parcel than the one specified on the teleport (not to be confused with the parcel containing the landing point destination, which is hopefully the same one).

[emperorstarfinder]

I think you really just need to try some tests with a generic user account (alt), from a different parcel.

As I stated earlier the tests I have done so far have been with a generic user account.

I've spelled out the conditions where it does not force the account and pointed out the feature that even when it does enforce the landing point location, it does not enforce it for repeated teleports from within the destination parcel. Perhaps this is where the unexpected behavior lies: you can only test landing points from a different parcel than the one specified on the teleport (not to be confused with the parcel containing the landing point destination, which is hopefully the same one).

Yes, you would probably be correct if the generic user is on the same parcel that might be an incorrect or unexpected behavior at that point. However, As I have stated before this was a generic user coming from Region A (with no landing point set for its parcel) to Region B (Parcel being the entire region with a landing point set). Thus two separate regions. The teleport is simply done by the following in-world:

1. Open World Map in the viewer.
2. Type in the name of a region (other than the region your in).
3. The red circle will by default go to 128, 128, 0 (or the exact height of the terrain on the z-axis). Select a spot on that region to teleport to.
4. Click Teleport (and here's where the problem occurred that I found myself underwater as the terrain height (z-axis was at 0 but the actual landing point was in fact on a dock).

Now perhaps if you were to double click (left click) on the location you want to teleport to on that region via the world map perhaps that is mistaking it for a teleport that would already be from somewhere on the parcel which seems highly unlikely. I also haven't tried that route yet myself so I cannot say for sure.

The expected behavior should be here that if a user is landing on a parcel with a set landing point via a teleport from another parcel in the same region or a completely different region then the agent (meaning the avatar) should in fact land at the set landing point coordinates.

I have isolated this to just be an issue with the world map as the teleportation from landmarks, scripts, etc. are in fact working properly here.

At any rate more testing to do on this one. And yes, I haven't gotten to the point of testing the teleportation from one point to another on the same parcel but I do suspect you are probably correct there.

[appurist]

Interesting note about the double-click. That might explain it. If you do double-click on the Teleport button on the world map, it's possible that two teleport requests are sent (since the button only requires a single click). Although I would think both requests would go to the original region, the "current parcel" may already be considered the destination at that point, and so it may bypass the landing point code due to the logic I mentioned above. It would be interesting to know if you can reproduce the issue when being very careful to single-click the Teleport. We might need some form of debouncing logic ignoring a duplicate teleport, or at least not applying the "same parcel" logic in that case. I would imagine that double-clicks might be fairly common here.

[emperorstarfinder]

Well, I had been using the teleport button on the world map, so I cannot say for sure if the double click route is doing it or not. But I will certainly test that as well. My working theory here is that for some reason the world map is bypassing the landing point code. This might be in part because you can select what point on the parcel within the region you want to teleport to on the world map.

Another note to make about the double click method here is that you can double click the point on the MapTile on the world map that you want to teleport to and that does effectively take the Teleport button out of the equation there.

If my working theory proves true then we would need to add some logic to make sure that the teleportations from the world map would not ignore the landing point code on a parcel.

The other interesting thing here I have seen in my most recent tests is the map tile on the world map will say the name of the region along with the (Unknown).

On my team's Halcyon testing grid we have 2 regions set up on the same VM with the grid services on a sperate VM along with DB on a separate VM. All running on Windows 2008 R2 at the moment. So I have not had a chance to figure out why the (Unknown) shows up as part of a regions name on the world map in the viewer with this configuration yet.

The pictures that Ana posted on this issue relating to what she found also show the (Unknown) in the region name on the map tile as well.

As a side note here not that it has relation to the teleportation but more for noting and might just be another issue I found that others may or may not be seeing. When starting the region console it will initialize the InventoryTransferModule however at this point it will say: [Inventory Transfer]: MessageTransferModule could not be found in Halcyon.ini. Setting to local only. The interesting note here is that the MessageTransferModule is enabled under the instant messages section.

Ill be doing more testing this evening and will test the double click theory as well.

[emperorstarfinder]

Okay, so after a bit more testing I have the following results

• Latest Firestorm for OpenSim

When in Region A I opened up the world map and found Region B which for the purpose of this test is the region where the parcel is the entire land in the region and has the landing point set.

When I chose a point to teleport to and clicked the teleport button I landed at the location I selected instead of the landing point. This means that even for the teleport button it is bypassing the landing point code.

The next test was the double click method I noted.

For this test, I returned to Region A and logged out and then back in. Upon logging back in and rezzing, I opened the world map and found Region B. I chose a point I wanted to teleport to and double clicked (left mouse button in this case) and the same thing happened as with just clicking the teleport button.

This tells me the landing point code is definitely being bypassed.

The (Unknown) I mentioned in my last comment next to the name of the region is in fact because Firestorm is not able to determine the maturity rating of the region even though it is set. Not sure why here but it might have to do with the logic having been changed by LL when they changed their maturity ratings from PG, Mature, Adult to PG, Moderate, Adult. This doesn't appear to affect the viewer much when it is in the region however as the viewer appears to know the maturity rating at that point. The viewer is also not displaying how many people are online in a region if there are people actually in that region on the world map.

• Latest Singularity Viewer Alpha Build

I conducted the same tests as I described with the latest Firestorm Viewer (OpenSim Version)

When in Region A I opened up the world map and found Region B which for the purpose of this test is the region where the parcel is the entire land in the region and has the landing point set.

When I chose a point to teleport to and clicked the teleport button I landed at the location I selected instead of the landing point. This means that even for the teleport button it is bypassing the landing point code.

The next test was the double click method I noted.

For this test, I returned to Region A and logged out and then back in. Upon logging back in and rezzing, I opened the world map and found Region B. I chose a point I wanted to teleport to and double clicked (left mouse button in this case) and the same thing happened as with just clicking the teleport button.

This tells me the landing point code is definitely being bypassed.

The Viewer is able to correctly see the region's maturity rating and displays it. Therefore there is no (Unknown) next to the region name on the world map.

• InWorldz Viewer (V3)

I conducted the same tests as I described with the latest Firestorm Viewer (OpenSim Version), and the latest build of the alpha version of the Singularity Viewer.

When in Region A I opened up the world map and found Region B which for the purpose of this test is the region where the parcel is the entire land in the region and has the landing point set.

When I chose a point to teleport to and clicked the teleport button I landed at the location I selected instead of the landing point. This means that even for the teleport button it is bypassing the landing point code.

The next test was the double click method I noted.

For this test, I returned to Region A and logged out and then back in. Upon logging back in and rezzing, I opened the world map and found Region B. I chose a point I wanted to teleport to and double clicked (left mouse button in this case) and the same thing happened as with just clicking the teleport button.

This tells me the landing point code is definitely being bypassed.

The Viewer is able to correctly see the region's maturity rating and displays the initial for the maturity rating. Therefore there is no (Unknown) next to the region name on the world map.

I conducted these tests both on my team's Halcyon Testing Grid and at home, on my own personal halcyon grid I set up. So I can rule out a configuration issue here.

At this point, I believe I confidently can say this is something to do with the landing point code being bypassed which by putting some logic in to ensure we aren't bypassing a set landing point should correct that.

[appurist]

Hi, can you provide a screenshot of the Options tab of the Parcel Properties / About Land settings for the destination parcel?

[emperorstarfinder]

Sure can. Please keep in mind logos and region naming info are kept the same as my team's main grid to ensure we are able to duplicate problems on our test grids for our sanity sake.

As evidenced by this snapshot I am clearly underwater where the dock is. The actual set landing point is on the dock itself which is at the height of 22 (z axis) as described by the landing point setting.

[appurist]

I really just wanted to confirm both the landing point location set, and the teleport routing set to Landing Point. (The screen shot confirms that.)

First, I should mention that landing points (and teleports in general) are implemented at the server end, so behavior on the teleport itself should be the same in all viewer, so you only need to test things with one viewer.

There are hardly any paths that would bypass the land point. Does your database have a telehubs table?

I think you said you are ending up below the landing point, i.e. it is working for the x,y position, only the z coordinate is incorrect, so perhaps the landing point part of all this is working just fine and the landing point aspect is a false issue, but the viewer blocking your view during teleport does not allow you to see that it is landing at the teleport location but falling through the dock ... (speculation).

So let's forget about landing points for the moment and look at why you might fall through after teleport due to physics.

Is there anything above the dock, i.e. if you were to go to the landing point, is there anything above the avatar's head? If there is a collision between the avatar and a prim at the teleport destination, Halcyon physics "depenetration" code will slowly move your avatar up until it is no longer colliding. However, there is a limit to that of about 10m as I recall. If it then continues to collide, it will let the avatar fall below the collision object. So for example, if there was a building on the dock with a low ceiling, you'd probably find yourself under the dock after a teleport.

Can you successfully teleport to the location on the dock from a location in the parcel under water, and arrive as expected?

Is the dock made from mesh? If so, what if you put a simple prim under your feet on the dock and then move the dock up 20m or so and then try another teleport to the parcel from another region? Do you then arrive at the Landing Point location, or under the prim? (You can also do a Take because Restore To Last Position inventory command is implemented in Halcyon.)

The landing point code is fairly simple, so I think your tests tell us that there's something more going on here beyond landing points. We're still missing the key factor here.

[appurist]

The actual set landing point is on the dock itself which is at the height of 22 (z axis) as described by the landing point setting.

Also, avatar heights may affect the resulting lowest point (foot position) after a teleport. The landing point is much more accurate than to the nearest metre, even if that's what the viewer is reporting. Perhaps it's set too close to the surface of the dock and falling through? You could try flying just slightly above the dock and setting a landing point there to see if that makes it more reliable.

[emperorstarfinder]

I really just wanted to confirm both the landing point location set and the teleport routing set to Landing Point. (The screenshot confirms that.)

This I think was in response to my comment about our logos and region naming convention. I simply needed to make that clear for legal purposes as I already knew what you wanted to see the snapshot for. (Not an amateur here :P)

First, I should mention that landing points (and teleports in general) are implemented at the server end, so behavior on the teleport itself should be the same in all viewer, so you only need to test things with one viewer.

In this case, mutiple viewers were used for the purpose of ruling out a viewer related bug and to prove it is server-side. This is simply proper and sound testing logic for development.

So let's forget about landing points for the moment and look at why you might fall through after teleport due to physics.

I can rule out it being physics related as I was just able to reproduce this on two empty regions on my home test grid. The landing height of the avatar probably wouldnt matter that much as the z-axis of 22 would likely be the point the avatar is on assuming the terrain height is at z-axis of 21.

Can you successfully teleport to the location on the dock from a location in the parcel underwater, and arrive as expected?

Once in the parcel, the answer to this is yes.

There are hardly any paths that would bypass the land point. Does your database have a telehubs table?

I will need to manually build this table as it appears the table is not there. When setting up the test grids I did use a MyData.sql file that Vinhold had provided which appears not to have included the table. I cannot use the hc-database.exe method as other tests are in progress on the test grids. Is there a master sql file floating around that does have the current tables for Halcyon perhaps?

Is there anything above the dock, i.e. if you were to go to the landing point, is there anything above the avatar's head? If there is a collision between the avatar and a prim at the teleport destination, Halcyon physics "depenetration" code will slowly move your avatar up until it is no longer colliding. However, there is a limit to that of about 10m as I recall. If it then continues to collide, it will let the avatar fall below the collision object. So for example, if there was a building on the dock with a low ceiling, you'd probably find yourself under the dock after a teleport.

This I can safely rule out as if I teleport via landmark it lands correctly at that position. Also if I double click on that selected point on the world map the land is fine without it getting pushed anywhere even with a roof over that part of the dock.

The other issue here is that if I select a coordinate of 132, 132, 22 for example it will land at that coordinate and not the landing point.

I have seen depenetration code move an avatar slowly more than the 10m though I haven't seen it directly occur yet on the halcyon test grid. In fact, the longest distance I have seen it move is over the water outside a region (this usually would be caused by lag however which can be caused by multiple factors).

The next step will be to build the telehubs table to be sure thats working correctly. This might be a missing piece to the puzzle though I suspect there might be a bit more going on then just a missing DB table.

[appurist]

I can rule out it being physics related as I was just able to reproduce this on two empty regions on my home test grid. The landing height of the avatar probably wouldnt matter that much as the z-axis of 22 would likely be the point the avatar is on assuming the terrain height is at z-axis of 21.

I don't really know what you mean by this. If you want to rule it out, you'd need at least one prim above the terrain height somewhere, with the landing point set above the terrain (e.g. at 30m) and just a platform prim with nothing above it. Or at 22m with nothing below it (except water).

I will need to manually build this table as it appears the table is not there.

No I was just asking if you had the table as it is the only other possibility in the code to bypass landing points.

I would avoid the telehubs stuff for now as that just complicates the possibilities. I asked about that table only to confirm that you did not have one.

The other issue here is that if I select a coordinate of 132, 132, 22 for example it will land at that coordinate and not the landing point.

If the landing point isn't set to 132, 132, anything, and you can end up there if you pick that on the map, then yes that rules out physics.

[emperorstarfinder]

Well, I can rule out the physics because the landing point has prims set to size x: 10.000 y: 10.000 z: 0.001 which is located at the exact landing point. I did also try it about 30 meters above the terrain height as well to see if that worked and still got the same thing so I am pretty confident it is not physics related, at least not from what I can tell at the moment. Also, the prims are not set to Phantom and not mesh at the moment. (I haven't rebuilt my docks using mesh yet though I really want to when I have the chance).

The fact that something is bypassing the landing point code sticks out prominently in my mind here, but if in fact, this isn't the problem then it is likely that we have stumbled on something that we just cannot think of at the moment. The only other thing I can think of is the world map is thinking its looking for the region-wide telehub but that doesn't seem too likely here as well.

But it is producible with just selecting a point (one left click) on the map and clicking the teleport button and by double-clicking a point on the map as well. So it clearly isn't detecting a parcel's set landing point.

If the landing point isn't set to 132, 132, anything, and you can end up there if you pick that on the map, then yes that rules out physics.

Yes the landing point is set to what was in the snapshot and I just randomly happened to select the 132, 132, 22 as an example but essentially it proves what I have indicated which is I did in fact teleport to a location on the map in that region from another region (landing was at 156, 132, 22) and I landed at the selected point which in fact is not the set landing point in the snapshot.

[appurist]

Can you open the Region/Estate form for the destination region and let me know if "Allow Direct Teleports" is enabled? (It should be.) I don't think it will be, because if it's not enable, I believe it will actually try to use the telehubs and always fail the TP. (That's a bug.)

[emperorstarfinder]

Allow Direct Teleport is checked.

I also was under the impression with the viewer code that a check was done to see if a telehub was enabled and configured and if it wasn't it would skip the telehub and it should check to see if a landing point is set. Telehubs really are just a dirty way of handling a region level landing point in my opinion but its one of those features LL gave the viewers.

[emperorstarfinder]

I quickly tested without Allow Direct Teleport checked to see if the same result would happen or if a bug showed up.

No bug showed up and I still landed under water so it doesn't appear that has much effect in this case. However, interestingly the maturity rating showed up and replaced the (Unknown) by the region name in the world map.

[kf6kjg]

@emperorstarfinder If this is still an issue could you re-open on the new location for Halcyon? https://github.com/HalcyonGrid/halcyon/issues

Thank you.