You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
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:
When PARCEL_FLAG_USE_ACCESS_GROUP has been overridden by "Anyone can enter" or region settings, don't return it as set from llGetParcelFlags().
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.
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.
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.',
}
The text was updated successfully, but these errors were encountered:
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.
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
When PARCEL_FLAG_USE_ACCESS_GROUP has been overridden by "Anyone can enter" or region settings, don't return it as set from llGetParcelFlags().
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.
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
The text was updated successfully, but these errors were encountered: