Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-216474] llGetParcelFlags info insufficient to tell if ban line present since 2017. #3842

Open
sl-service-account opened this issue Jun 20, 2018 · 3 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Jun 20, 2018

Steps to Reproduce

Trying to develop a script which will keep boats from getting caught in ban lines. There are tight waterways where restrictive parcels and open Linden water adjoin. (Visit Joiner for many examples of strange permission combinations, including the one above. Plus such oddities as a no-script area in the middle of open water.)

Actual Behavior

llGetParcelFlags returns PARCEL_FLAG_USE_ACCESS_GROUP set when "Anyone can enter' and "Allow group" are both set. The meaning of that combo was changed in 2017. (See quote from Grumpity Linden at "https://modemworld.me/2017/04/08/new-region-and-parcel-access-controls-coming-to-second-life/"): "The weirdness where you check “Public access” and “Group access” and end up with group ONLY unless you also check “PIOF” and then you get group + public w/PIOF … that will not stand. " That was a good change, but now the API and the UI are somewhat out of sync. Group access being on is now meaningless if "Anyone can enter". But the API does not reflect this.

So there's no reliable way to tell from LSL if there's a ban line around a parcel.

The basic question is, "Can this avatar enter this parcel"? Walking avatars just bounce when they hit a ban line. That's fine. But avatars in vehicles can be ejected. If object entry is allowed but avatar entry is not, vehicles get in, and then avatars on them are forcibly ejected.

Suggestions:

  1. When PARCEL_FLAG_USE_ACCESS_GROUP has been overridden by "Anyone can enter" or region settings, don't return it as set from llGetParcelFlags().

  2. Proposed new LSL call:

    integer llAvatarEntryAllowed(key id, vector pos)

Returns TRUE if avatar "id" can enter the parcel at "pos". This should make exactly the same checks that are made when deciding to exclude an avatar.

  1. Alternative approach: if a vehicle has an avatar on it that cannot enter a parcel, don't let the vehicle enter and take the same actions as for no object entry - turn off physics and move the vehicle back outside the parcel. Preferred to 2 above.

Expected Behavior

Something reasonable that keeps the avatar in the boat.

Other information

Give us some way to prevent being blown out of the water by badly configured ban lines. Thank you.

Attachments

Original Jira Fields
Field Value
Issue BUG-216474
Summary llGetParcelFlags info insufficient to tell if ban line present since 2017.
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter animats (animats)
Created at 2018-06-20T04:49:40Z
Updated at 2022-02-03T00:00:20Z
{
  'Business Unit': ['Platform'],
  "Is there anything you'd like to add?": 'Give us some way to prevent being blown out of the water by badly configured ban lines. Thank you.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'llGetParcelFlags returns PARCEL_FLAG_USE_ACCESS_GROUP set when "Anyone can enter\' and "Allow group" are both set. The meaning of that combo was changed in 2017. (See quote from Grumpity Linden at "https://modemworld.me/2017/04/08/new-region-and-parcel-access-controls-coming-to-second-life/"): "The weirdness where you check “Public access” and “Group access” and end up with group ONLY unless you also check “PIOF” and then you get group + public w/PIOF … that will not stand. " That was a good change, but now the API and the UI are somewhat out of sync. Group access being on is now meaningless if "Anyone can enter". But the API does not reflect this.\r\n\r\nSo there\'s no reliable way to tell from LSL if there\'s a ban line around a parcel.\r\n\r\nThe basic question is, "Can this avatar enter this parcel"? Walking avatars just bounce when they hit a ban line. That\'s fine. But avatars in vehicles can be ejected. If object entry is allowed but avatar entry is not, vehicles get in, and then avatars on them are forcibly ejected. \r\n\r\nSuggestions:\r\n\r\n1) When PARCEL_FLAG_USE_ACCESS_GROUP has been overridden by "Anyone can enter" or region settings, don\'t return it as set from llGetParcelFlags().\r\n\r\n2) Proposed new LSL call:\r\n\r\n    integer llAvatarEntryAllowed(key id, vector pos)\r\n\r\nReturns TRUE if avatar "id" can enter the parcel at "pos". This should make exactly the same checks that are made when deciding to exclude an avatar. \r\n\r\n3) Alternative approach: if a vehicle has an avatar on it that cannot enter a parcel, don\'t let the vehicle enter and take the same actions as for no object entry - turn off physics and move the vehicle back outside the parcel. Preferred to 2 above.',
  'What were you doing when it happened?': 'Trying to develop a script which will keep boats from getting caught in ban lines. There are tight waterways where restrictive parcels and open Linden water adjoin. (Visit Joiner for many examples of strange permission combinations, including the one above. Plus such oddities as a no-script area in the middle of open water.)',
  'What were you expecting to happen instead?': 'Something reasonable that keeps the avatar in the boat.',
  'Where': 'Multiple places in Joiner.',
}
@sl-service-account
Copy link
Author

animats commented at 2018-07-05T05:20:55Z

The worst case. A no-script area in the middle of a navigable channel, against the edge of a region boundary. There is no way to detect this before it kills your boat.

@sl-service-account
Copy link
Author

animats commented at 2018-07-10T05:44:19Z

Found a work-around for the no-script case; you can still operate a vehicle with an avatar on it in a no script area, with reduced performance, provided that avatar entry is allowed.

Where there's both no-object-entry and no avatar entry, the question is which root prim crosses the ban line first. If the object crosses first, it's blocked from further entry and a script can back it out. If the avatar enters first, it's ejected violently.

Can't check the access and ban lists, of course. Or tell if group membership allows script use.

@sl-service-account
Copy link
Author

animats commented at 2018-07-14T18:08:14Z, updated at 2018-07-14T22:17:04Z

After further testing, the simplest solution seems to be:

PROPOSED FIX:

If a vehicle has an avatar on it that cannot enter a parcel, don't let the vehicle enter, and take the same actions as for no object entry - turn off physics and move the vehicle back outside the parcel. Do not eject an avatar from a vehicle, ever.

DISCUSSION:

I have scripted motorcycles, boats, and helicopters which can do vehicle recovery. They detect the physics turn-off, reposition to a previous safe location just outside the ban line, stop all motion, and turn physics back on. The user can then drive or fly around the ban line, without disruption to the user experience. I've flown a helicopter across several SL continents successfully with this.

This only works if the vehicle root hits the ban line before any avatar root does. Placing the vehicle root forward helps, but is not sufficient. Jagged ban lines, oblique hits, and turning, reverse, or sideways movements can cause an avatar root to hit a ban line before the vehicle root. So we can't work around this completely.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant