Kitely Forums

We've been experimenting with the Landing Point on Wellspring the last couple of days, and I was reminded of an issue that goes way back to early virtual days. It entails two matters:

1. When using the BigMap to TP to a World, it defaults to a landing point of <128, 128, 2> (as if all Worlds have the same landing point). This is below the standard land setting of 20m, effectively trying to TP the user underground. If land exists at that point it drops the person halfway inside the land and pops them to the surface (with consequences. Explained later). If there is no land, it places them at the bottom of the ocean.

2. There is one way (that I'm aware of) to alter that Landing Point: by using About Land settings. But that is a parcel-based setting rather than world-based. Using that to try and set an alternate landing point on a large world can be problematic.

The Consequences:

Regarding Item 1: Default vertical LP of 2 meters seems to me a logic bug. Why would the system default someone to TP at the bottom of the ocean? It would seem more logical to have a default LP of 128,128,25 (5m above normal 20m land surface). That way they fall onto the land rather than colliding with it waist-deep (or winding up at the bottom of the ocean).

Regarding item 2: Even on a single-region setup, a default landing point of right in the middle of the region can be problematic. I won't go deeply into the several reasons why; world owners are likely already aware of the headaches involved in overcoming this issue.

On Kitely (and other Opensim worlds) where a World can be much larger than one region, the problem becomes exacerbated... since the 128,128 default landing point can be a considerable distance away from the World Welcome Center. There are ways to overcome this: A) Rerouting the default parcel to the desired location (a real headache) B) Setting up a welcome center at 128,128 (not always a desired solution or C) Using a Portal Prim at the default landing point-- which doesn't always work because...

THE UNSEEN CONSEQUENCE: One of the ways to overcome the default TP location is to use a PORTAL PRIM. This is a platform that is scripted to instantly teleport a visitor to the desired welcome location when they appear and fall onto the prim. This is an excellent remedy... except for the above-stated 2m BigMap default. This default is below the land. So instead of the visitor rezzing and falling onto the portal prim and instantly teleporting... the system actually rezzes them halfway into the ground, they "float up" to the surface, and half the time fail to "collide" (thus making the portal device ineffective). So that 2m vertical rezzing point has unexpected consequence.

POSSIBLE SOLUTION depends on whether the default landing point is grid-side or viewer-side. If it's grid side then there are at least two viable solutions (perhaps more, but these are what pop to mind):

1. (The preferred one imo) Allow a World-based BigMap-default landing point (rather than a Parcel-based landing point). That landing point would be tied to the World rather than a specific parcel. This would solve the problem permanently and completely, allowing the world owner to specify anywhere on the World as the default MAP landing point (not just 128,128,2).

2. A less desirable solution but one that would work, would be to set the default landing point to 128,128,25 instead of 128,128,2. That would rez the avatar at the proper elevation, allowing them to drop onto a portal prim and be instantly ported anywhere on the World.

(What we do currently is let them drop into the ocean, with a portal prim at the bottom of the ocean. Not an ideal solution, but it works.)

In summary: The current Map default of 128x128x2 doesn't make logical sense. That location is under the ocean, below normal land height. An alternate World-Based default landing point is needed... one that isn't tied into specific Parcel coordinates.

Yes, there are "workarounds" to this as discussed above. But I request (if possible) that the Map default be changed, either to a different default entirely (depending on the World, and set by the World owner), or to 128x128x25 so that visitors are rezzed above land.

Thanks for your consideration of this matter. -- Snoots

Hi Snoots,

OpenSim chooses the starting position within a region according to very complicated logic. Which I will only partially explain here but which should help you overcome the issue and help explain why your suggestion mat not be feasable:

Telehub

A region can have a Telehub. Avatars that enter the region via login or teleport appear near the telehub. Note that the telehub works only if the estate setting "Allow Direct Teleport" is disabled. If a Telehub exists then it takes precedence over the Landing Point (see below).

Telehubs are more powerful than Landing Points (see below) because they affect the entire region. In contrast, a Landing Point only takes effect if the user is entering that parcel. For example, you can use the World Map to enter the region at any parcel. As another example, when you log into "Last location" (which is the default), you'll return to your previous location (whichever parcel contains it).

Therefore, regions with multiple parcels should use a Telehub.

Landing Point

A parcel can have a Landing Point. How the Landing Point is used depends on:

• The value of the "Teleport Routing" setting in the parcel.
• Whether the user is entering the world, or moving inside the world.
• If entering the world, how the user entered the world.

Entering a World Via Login (Without a Position) or Web Teleport

When a user enters a world via Login (without specifying a position) or Web Teleport, we place him at the parcel's Landing Point (if it exists). We ignore the "Teleport Routing" setting in this case. This behavior is specific to Kitely.

Here's how to Login in the viewer without specifying a position:

• Click "Start World" in a world page (on the website), and then click "Login".
  This only works if the Login field is set to "Last location". If it's set to "Home" or to a region name then that takes precedence.
• Click on a world in the Destinations section of the viewer login page, and then click "Login".
  This only works if the Login field is set to "Last location" or "Home". If it's set to a region name then that takes precedence.
  This is actually handled by the viewer itself: clicking on a world in the viewer login page means clicking on an SLURL (e.g., secondlife://My%20World), so it's the viewer that remembers that this is the world the user wants to enter; not Kitely.
• Enter a region name in the Login field in the viewer, and then click "Login".

A Web Teleport never specifies a position, so all of the above details are irrelevant in that case.

Entering a World Via Login (With a Position)

When you enter a world via Login, and you don't specify a position, then you'll go to that position if "Teleport Routing" is set to "Anywhere". But if it's set to "Landing Point" or "None" then you'll still go to the landing point.

Here's how to Login in the viewer while specifying a position:

• Set the login field to "Last location" (without using any of the steps described in the previous section), and then click "Login".
• Set the login field to "Home", and then click "Login".
• Enter a region name and location in the login field (e.g.: "My World/50/50/21), and then click "Login".

Entering a World Via World Map, Landmark, or the Search Page

Entering a world in this way uses the standard behavior of Landing Points.

Teleporting Inside a World

Teleporting inside a world uses the standard behavior of Landing Points, which depends on the parcel's "Teleport Routing" setting:

• Landing Point - teleports within the parcel aren't allowed: youan only teleport to the Landing Point.
• Anywhere - the Landing Point is ignored, and you can teleport anywhere in the parcel.
• Blocked - the Landing Point is ignored. Due to an OpenSim bug (or on purpose?), this option doesn't block teleports, so it behaves the same as the "Anywhere" option

Lure (offer teleport)

Lure always succeeds, regardless of the parcel or region settings.

How to Set the Landing Point

• Place the avatar in the location that you want to set as the Landing Point.
• Right-click the ground and choose "About Land". (If the land isn't visible then you can also access this dialog in other ways. E.g., in Firestorm select from the menu: World > Places Profile > About Land.)
• Go to the "Options" tab.
• The Landing Point will be shown in this tab. Click "Set".
• Change "Teleport Routing" to "Always" or "Landing Point". These options work the same when entering the parcel, but afterwards the "Landing Point" option restricts further teleports, while the "Always" option does not.

The Landing Point will be saved in an OAR file backup (if you export world).

---

The reason this logic is complicated is that the starting position might only be used for some types of teleport, or for some types of users. For example:

• Login always uses the starting position
• Lure always ignores the starting position (i.e., the user appears next to the user that invited him)
• Landmarks work only for the world owner. Non-owners appear at the starting position.
• Teleporting via the Map from another region always uses the starting position
• Teleporting inside the region always ignores the starting position

The code is even more complicated than what I wrote above. Also, it looks inconsistent in some parts: e.g., the logic used during login doesn't check as many things as the logic used during teleport. Also, if all else fails, OpenSim places the user at (128,128).

Changing even a small part of this complicated logic can cause a lot of expected behavior (of how things "should work" based on how they work in Second Life or other grids) to break. We had to make one change to this code in order to get it to work with Kitely but we really don't want to change this as whenever we tried to improve one aspect of it to how some people thought it should work, the change ended up causing more complaints from other people.

Hi Ilan. Thanks for the detailed explanation. Would it be worth copying this into the official documentation for Kitely so that people can easily find it again?

I appreciate the detailed information on Landing Points. It's certainly a hairball.

What I refer to specifically though, is the BigMap defaulting to 128,128,2 (at the bottom of the ocean) rather than 128,128, 25 (above minimum-height land). I was questioning if it was possible to change the BigMap coordinates so that they don't drop visitors to the bottom of the ocean.

This is a logical concept that should have been implemented by LL from the very beginning. Dunno what they were thinking.

Hi Snoots,

This coordinate is provided by the viewer as the desired destination when you use the world map to teleport. As such, it's something that needs to be changed on the viewer side. The workaround on the server side is to use Landing Points and Telehubs as I've explained above.

Thank you Ilan. That settles the matter.

Another case of the Viewer preventing the World from operating as needed. No wonder people curse LL code: placing grid prerogative data (world landing point) in the Viewer code. First they decide on a goofy coordinate (at the bottom of the sea), then they put that coordinate control in the Viewer instead of server-side (where it should be, under the control of the region owner).

/me shakes noggin sadly and wonders if there's a way this could be overridden grid-side.

However, we "solved" the problem (such as one solves a hole in the wall by covering it with a picture). We sunk our land at 128,128 to sea bottom and placed a portal disc at the bottom. People log in and without knowing it (because they're still rezzing) fall to the bottom of the ocean and are instantly teleported to our Welcome Center. It's a lousy hack, but it works.

If anyone needs it, here is a basic collision-portal script to do so. To use this you must be the world owner or assigned Estate Manager.

This script also works well for instant teleportation portals as special effects within a World. Just set up a fancy-looking collision device (a "portal") and when someone walks into it... instantaneous transport to destination. Place such devices with care, because they really really work. : )

Hi Snoots,

That's an interesting workaround by why not just use a telehub? See: https://community.secondlife.com/knowle ... #Section_1

Ilan Tochner wrote: ↑

Sun Dec 06, 2020 5:59 pm

Hi Snoots,

That's an interesting workaround by why not just use a telehub? See: https://community.secondlife.com/knowle ... #Section_1

"If you choose to use a telehub, you must disable Allow Direct Teleport on the Estate tab of the REGION/ESTATE window. In addition, you should clear any landing points that might be set for the parcels on your estate (using the About Land window's OPTIONS tab), as they can cause the telehub to malfunction. Note: If you are the owner of a Region, you always teleport directly to the center of it instead of to a set telehub or landing point. "

These are three significant issues, ones that have always been a downside of Telehubs: the need to choose between all or none. We want visitors accessing by map to arrive at the Welcome Area by default, but we don't want all visitors and residents to be forced to that location. If they're using a landmark, have been teleported in by a friend, or are a resident heading Home, that's where we'd like them to arrive. A Telehub forces everyone to a single point, and they then have to further teleport from there to their desired destination. Region owners are the exception; they are forced to the center of the region (which I assume remains 128,128,2)... which is something we're trying to avoid entirely.

Unless there's a trick to using Telehubs I'm not aware of, a Telehub will get people to our Welcome Center... whether they need to be there or not.

We've had a similar issue since the early days.. sometimes a problem sometimes not... varies by region at times..
Our solution is also a strategically placed hypergate. (hypergate, blamgate, whatever you want to call it)
It is not a problem cuz we use hypergates all over the place for intersim and intrasim people movement.
Using different code than yours, but I don't recall having any Estate Management permission issues.
But then maybe there are and I just didn't notice?

As for special effects.. YES!
At SENEFERS TOMB we have a neat little ancient egypt / pyramid / tomb puzzle setup that utilizes numerous microdistant hypergate TPs, as well as one-way walls, real time working mirror, self-activating LightShare, and creative textures and stuff.
hop://grid.kitely.com:8002/Seanchai/195/67/21

I didn't look at your code closely before I started typing this.. oops.. but you can of course control your subjects 'facing direction' upon landing.

Anywho.. just wanted to chime in..
Of course I may be off on a whole different tangent than y'all are discussing.

Thanks all

Shandon Loring wrote: I didn't look at your code closely before I started typing this.. oops.. but you can of course control your subjects 'facing direction' upon landing.

This was a bug during the early days of SL and somehow seems to have carried over into Opensim and even OSSL. While the documentation states the second location is supposed to be the facing direction, this doesn't work. I have tested this on SL, the defunct Inworldz, OSgrid and Kitely... and have never been able to get the avatar to face any direction other than (approximately) Northeast. An SL JIRA has been posted on this matter since 2012 and remains unresolved:

https://jira.secondlife.com/browse/SVC-7987
https://jira.secondlife.com/browse/BUG-229224

There are some interesting notes in the comments that provide additional Caveat information. Interestingly, none of that has been noted in the SL Wiki. Because of these issues, I and other scripters I've spoken with simply duplicate the arrival point as the second argument, ie: loc,loc

If there is a trick to solving this, would love to learn it.