Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007785opensim[REGION] OpenSim Corepublic2015-12-20 07:372016-06-24 02:02
Assigned Tonebadon 
PlatformPCOperating SystemWindowsOperating System Version10
Product Versionmaster (dev code) 
Target Versionmaster (dev code)Fixed in Versionmaster (dev code) 
Summary0007785: Owner teleport to regions with a landing point set are not respecting a set limited landing point
DescriptionUsing opensim-0.9.0-210-g827058e on Windows on several regions where I have landing points set, I note that the avatar can arrive at any location.

Resetting the teleport/landing point for the region and retesting the teleport has no effect, it is still not respected.

I have not done any land divides or operations such as that, so I am not expecting landing points that already exist to be invalidated.

I have found this applies to the owner of the region, and not to other normal avatars.

This is a change of behaviour recently, and I think is undesirable and can be a problem where, for example, an avatar arrives under mesh terrain and cannot find a route out. This seriously breaks the immersive experience for the user.
TagsNo tags attached.
Git Revision or version numberopensim-0.9.0-210-g827058e
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script Engine
Environment.NET / Windows64
Mono VersionNone
ViewerFirestorm 4.7.5
Attached Filesjpg file icon 2015-12-21-Owner-Arrives-Under-Mesh-Terrain.jpg [^] (121,262 bytes) 2015-12-21 01:42

- Relationships
related to 0007786closednebadon landing point set are not respecting 
related to 0007934closednebadon Grid Gods and Regions owners always ignore Telehubs (Regresssion) 

-  Notes
UbitUmarov (administrator)
2015-12-20 12:42

On last revision I did change a few things some for preventive security reasons.
users to access to god level on region are not affected by telehubs, land points or bans.
neither are region owners or estate managers.
parcel owners are not affected by their parcel bans or landpoints.

Your point is also valid, not only meshs but houses etc, since we still don't have collision checks on avatar position
so a possible a new balance between security and usability is needed :(
UbitUmarov (administrator)
2015-12-20 12:49

a few changes on operation.
- telehubs only work if the flag Allow direct teleport is unmarked.
- local teleports do tp to spawn point closer to target position. Fail is avatar is already closer than them.
- telehubs now also work on login to last location

landpoints don't work on login to last location
aiaustin (developer)
2015-12-20 13:37
edited on: 2015-12-20 13:50

Yes.. I think the previous behaviour for estate owners and parcel owner is necessary, as otherwise every arrival at a region or parcel you manage is likely to be a mess.

You could argue that god level avatars might need to be able to bypass everything, but even there arrival under meshes or stuck inside objects is not fun and wastes a lot of time, which for managers or administrators should be avoided.

Logins to last location always have put you exactly where you were... but that would usually be a valid location, so not leave you accidentally under mesh etc.

UbitUmarov (administrator)
2015-12-20 15:09

it will be a worse mess, if something or someone breaks the telehubs or landpoints.
Telehubs now do change location on login to last location (normal users case)
this may change after some grid side changes, but it is needed for now.
aiaustin (developer)
2015-12-21 01:42

I attach a screen shot (2015-12-21-Owner-Arrives-Under-Mesh-Terrain.jpg) of what always happens now when an estate owner avatar arrives on a rewgion where landing point is set to try to ensure they arrive at a sensible (above mesh terrain and not inside mesh buildings) location..

If access is always required for privileged avatars to any region/plot position for security can I suggest that that might be restricted to the god level avatars (level 200?) AND ALSO ONLY where god level "admin status" has been requested in the viewer and granted. then even for the god/admin avatar there will be better behaviour (the previous behaviour) when NOT in the admin/god state in a viewer.
UbitUmarov (administrator)
2015-12-21 04:24

Viewer requested god level access it almost totally ignored by regions, they grant most rights automatically, viewers just don't know that. It is also local to the region. A exception that works is the right to see (and be seen) hidden avatars by the new parcels option support, and thats because I made it so for avn.
So god level case is something I will not change on this issue.
Other cases, thinking about them.
This because the issue you show is not new or related to telehub/LP, they where just a workaround. It is just worse with large meshs, but always happened with houses etc.
Reason is that there is only a basic ground level check on arrival, while it would need to be something a bit more complex that I also avoided on physics sits.
UbitUmarov (administrator)
2015-12-21 08:35

added experimental code
using physics to change land position to the top of anything physics sees up to 1024m above ground.
does it if not under the action of a telehub or landpoint and on same login types.
supported by ubOde, untested with ode, unsupported by bullet.
aiaustin (developer)
2015-12-21 10:13
edited on: 2015-12-21 13:22

Ubit, I don't think that is the correct approach at all. There could be multiple build levels in between a ground level and various skybox builds above that which may be within the 1024m ceiling you have chosen. It should not be used for normal users or current behaviours will get messed up more.

To do ths more sensibly you should look DOWN from the arrival position to the FIRST physics base BELOW that position.

We use the default BulletSim on all our grids and OSGrid regions by the way, so we cannot test.

UbitUmarov (administrator)
2015-12-21 10:22

arrival position height is currently unreliable.
Even when it is reliable it knows nothing about your mesh terrain, or objects. Using as you say would be useless
aiaustin (developer)
2016-01-11 03:23

Can I appeal again to have the arrival location for region owners and plot/land owners respect set landing points... region owners on my grid are just discovering this and wondering why they are ending up stuck UNDER their mesh terrain or under water at 128/1128/1 when they arrive. E.g... a typical comment I am receiving from a region owners...

>> I clicked on the Board TP to Castle ...
>> that landed me in the Water beneath the Waterfall.

The previous behavior in 0.8.* was fine and never caused problems. The 0.9.0 merged code behaviour is simply annoying and really breaks the VW immersion.

If access on security grounds for owner avatars is needed, can this be gated by being only for god level avatars (level > 100, note that's NOT >= 100 for normal owner/admin avatars) then the problem will only show for a few people on a grid and not in the majority of region or plot owner cases, which on some grids means every arrival from TPs, every return home and every move the majority of avatars engage in!

The code to probe for solid ground below the avatar on arrival could the all be removed too.
kenvc (reporter)
2016-01-11 09:00

I have noticed this issue for a while too.

The landing point as set should always work when someone TPs into a sim regardless of their user status, unless they are banned or otherwise do not have access to that point on the sim.
Total Sorbet (reporter)
2016-01-21 11:18
edited on: 2016-01-22 01:42

Same on OSgrid (Dev) ddd59fa: 2016-01-18

As sim owner i'm primary user yet I cannot set tp point for myself.

Pretty please can we revert this behaviour?

aiaustin (developer)
2016-01-22 01:41
edited on: 2016-01-22 01:42

This is currently my number 1 issue I am afraid. I am really annoyed at always arriving under mesh terrain and having to find a way out on every visit to regions to perform trivial management actions. And as region/land owners find the problem they are asking my why it is broken. Remember it will be very common to try to arrive at 128/128/xx if you come in via a map or region name in the viewer initial boxes.

If some security reason is the underlying reason for this behaviour change then I think an alternative less disruptive mechanism is needed, and I have made suggestions. One simple one could be to allow any avatar with level >100 to arrive at arbitrary places but all with level 100 and below to respect the set TP point if that is enabled on a land area.

aiaustin (developer)
2016-01-29 03:50
edited on: 2016-01-30 02:48

Ubit... I tested the latest dev master opensim-0.9.0-251-gb34652e which I thought was meant to restore the behaviour to respect a set landing point for owners and estate managers for a region/land plot rather than arriving at whatever X/Y/Z was set, e.g. via the map.

But I just tested which the usual arrival position if you do a map search for a region (e.g. Region/128/128/1) and I arrive on the sea bed and under mesh terrain on a region/plot with a specific landing point set.

I tried several regions and on two grids both on opensim-0.9.0-251-gb34652e

UbitUmarov (administrator)
2016-01-30 05:13

Do you have god rights there?
I kept gods as exception to land point changes
aiaustin (developer)
2016-01-30 07:05
edited on: 2016-01-30 07:06

God rights imply level = 200 I think?

The avatar I am testing with has title "Administrator" and "Level" = 100.

This also occurs on two of our add-on regions on OSGrid with set landing points ("Castle" and "Oil Rig") where the avatar is simply the region/plot owner.

aiaustin (developer)
2016-01-30 07:14

Ah... I now see the default values for these settings means that region and plot owners have "god" level access... I will test with these off...

    ;# {allow_grid_gods} {} {Allow grid gods?} {true false} false
    ;; This allows users with a UserLevel of 200 or more to assume god
    ;; powers in the regions in this simulator.
    ; allow_grid_gods = false

    ;; This allows some control over permissions
    ;; please note that this still doesn't duplicate SL, and is not intended to
    ;# {region_owner_is_god} {} {Allow region owner gods} {true false} true
    ;; Allow region owners to assume god powers in their regions
    ; region_owner_is_god = true

    ;# {region_manager_is_god} {} {Allow region manager gods} {true false} false
    ;; Allow region managers to assume god powers in regions they manage
    ; region_manager_is_god = false

    ;# {parcel_owner_is_god} {} {Allow parcel owner gods} {true false} true
    ;; Allow parcel owners to assume god powers in their parcels
    ; parcel_owner_is_god = true
aiaustin (developer)
2016-01-30 07:29

All good now that I have amended all the OpenSim.ini settings for god level access to false.
UbitUmarov (administrator)
2016-01-30 07:31

no idea why parcel owners have god by default, guess I will change that one of this days, leaving only region owner
aiaustin (developer)
2016-01-30 08:06
edited on: 2016-01-30 08:07

Okay. I think this works fine now and seems to allow the region server to control god level on regions they serve with suitable settings.

I agree that the OpenSimDefaults.ini and OpenSim.ini.example settings are quite permissive by default, and would also suggest that only region owner is god is true by default.

UbitUmarov (administrator)
2016-01-30 08:09

already done that :)
nebadon (administrator)
2016-06-23 12:01

[11:45] <cia-opensim> opensim: diva * rb522f0916aa9 / (3 files in 2 dirs):
[11:45] <cia-opensim> Mantis 0007934 and related: landing points and telehubs for gods. Added a new configuration variable LandingPointBehavior that can switch between what we're used to in OpenSim and the behavior in SL.

Tested and working, please test and if you find this is truly resolved please close this mantis.
aiaustin (developer)
2016-06-24 02:02

Confirmed that the OpenSim.ini parameters under various permutations work as advertised, and that the defaults restore previous behaviour.

- Issue History
Date Modified Username Field Change
2015-12-20 07:37 aiaustin New Issue
2015-12-20 07:41 aiaustin Description Updated View Revisions
2015-12-20 07:41 aiaustin Description Updated View Revisions
2015-12-20 12:42 UbitUmarov Note Added: 0029836
2015-12-20 12:49 UbitUmarov Note Added: 0029837
2015-12-20 13:37 aiaustin Note Added: 0029838
2015-12-20 13:39 aiaustin Note Edited: 0029838 View Revisions
2015-12-20 13:47 aiaustin Note Edited: 0029838 View Revisions
2015-12-20 13:47 aiaustin Note Edited: 0029838 View Revisions
2015-12-20 13:50 aiaustin Note Edited: 0029838 View Revisions
2015-12-20 15:09 UbitUmarov Note Added: 0029839
2015-12-21 00:46 aiaustin Relationship added has duplicate 0007786
2015-12-21 00:48 aiaustin Description Updated View Revisions
2015-12-21 00:49 aiaustin Relationship deleted has duplicate 0007786
2015-12-21 00:49 aiaustin Relationship added related to 0007786
2015-12-21 01:42 aiaustin Note Added: 0029841
2015-12-21 01:42 aiaustin File Added: 2015-12-21-Owner-Arrives-Under-Mesh-Terrain.jpg
2015-12-21 04:24 UbitUmarov Note Added: 0029842
2015-12-21 08:35 UbitUmarov Note Added: 0029843
2015-12-21 10:13 aiaustin Note Added: 0029844
2015-12-21 10:20 aiaustin Note Edited: 0029844 View Revisions
2015-12-21 10:22 UbitUmarov Note Added: 0029845
2015-12-21 13:22 aiaustin Note Edited: 0029844 View Revisions
2016-01-11 03:23 aiaustin Note Added: 0029938
2016-01-11 09:00 kenvc Note Added: 0029944
2016-01-21 11:18 Total Sorbet Note Added: 0030014
2016-01-22 01:41 aiaustin Note Added: 0030015
2016-01-22 01:42 aiaustin Note Edited: 0030015 View Revisions
2016-01-22 01:42 aiaustin Note Edited: 0030014 View Revisions
2016-01-29 03:50 aiaustin Note Added: 0030034
2016-01-30 02:48 aiaustin Note Edited: 0030034 View Revisions
2016-01-30 02:48 aiaustin Note Edited: 0030034 View Revisions
2016-01-30 05:13 UbitUmarov Note Added: 0030035
2016-01-30 07:05 aiaustin Note Added: 0030036
2016-01-30 07:06 aiaustin Note Edited: 0030036 View Revisions
2016-01-30 07:14 aiaustin Note Added: 0030037
2016-01-30 07:29 aiaustin Note Added: 0030038
2016-01-30 07:31 UbitUmarov Note Added: 0030039
2016-01-30 08:06 aiaustin Note Added: 0030040
2016-01-30 08:07 aiaustin Note Edited: 0030040 View Revisions
2016-01-30 08:09 UbitUmarov Note Added: 0030041
2016-06-22 11:34 aiaustin Relationship added related to 0007934
2016-06-22 11:50 aiaustin Note Added: 0030666
2016-06-22 13:16 aiaustin Note Deleted: 0030666
2016-06-23 12:01 nebadon Note Added: 0030701
2016-06-23 12:01 nebadon Status new => resolved
2016-06-23 12:01 nebadon Resolution open => fixed
2016-06-23 12:01 nebadon Assigned To => nebadon
2016-06-24 02:02 aiaustin Note Added: 0030731
2016-06-24 02:02 aiaustin Status resolved => closed
2016-06-24 02:02 aiaustin Fixed in Version => master (dev code)

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker