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

[BUG-10195] llAgentInExperience() returns FALSE if target has not granted permissions #551

Closed
sl-service-account opened this issue Sep 4, 2015 · 6 comments

Comments

@sl-service-account
Copy link

Steps to Reproduce

I called llAgentInExperience() for a user that had not yet granted permissions to the experience. The script returned FALSE, which is wrong since the sim in question allows that experience, as does the client.

Actual Behavior

llAgentInExperience() does not behave as described. It is supposed to return TRUE if the user is on Experience-enabled land.

Expected Behavior

It should return TRUE if the land allows the experience, regardless of the user's permissions. This is how the function is documented on the Wiki.

Other information

This bug renders the function, and indeed the entire system, worthless. If you cannot check for a valid Experience before requesting permissions, you cannot reliably present a alternate method. For example, teleporting people via llTeleportAgent() in an Experience, or using llMapDestination() otherwise. The act of requesting permissions throws the script out of the touch() event, and that is the only place where a map may be presented if not worn.

Original Jira Fields
Field Value
Issue BUG-10195
Summary llAgentInExperience() returns FALSE if target has not granted permissions
Type Bug
Priority Unset
Status Closed
Resolution Not Applicable
Reporter Cheshyr Pontchartrain (cheshyr.pontchartrain)
Created at 2015-09-04T20:39:39Z
Updated at 2017-05-08T22:52:30Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2015-09-04T17:26:09.725-0500',
  "Is there anything you'd like to add?": 'This bug renders the function, and indeed the entire system, worthless.  If you cannot check for a valid Experience before requesting permissions, you cannot reliably present a alternate method.  For example, teleporting people via llTeleportAgent() in an Experience, or using llMapDestination() otherwise. The act of requesting permissions throws the script out of the touch() event, and that is the *only* place where a map may be presented if not worn.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'llAgentInExperience() does not behave as described.  It is supposed to return TRUE if the user is on Experience-enabled land.',
  'What were you doing when it happened?': 'I called llAgentInExperience() for a user that had not yet granted permissions to the experience. The script returned FALSE, which is wrong since the sim in question allows that experience, as does the client.',
  'What were you expecting to happen instead?': "It should return TRUE if the land allows the experience, regardless of the user's permissions. This is how the function is documented on the Wiki.",
  'Where': 'http://maps.secondlife.com/secondlife/Gallifrey/110/133/22',
}
@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2015-09-04T22:26:10Z, updated at 2015-09-04T22:26:41Z

llAgentInExperience() checks if the target agent has the experience allowed on their person, not if it's allowed at the land they or the script is over.

For a function that checks if an experience is allowed or blocked at a target location, https://jira.secondlife.com/browse/BUG-6912 may be of interest.

Also see https://jira.secondlife.com/browse/BUG-8044 for a request to make llAgentInExperience() operate as its namesake implies.

@sl-service-account
Copy link
Author

Cheshyr Pontchartrain commented at 2015-09-05T00:30:29Z

Thank you, Lucia. I mistakenly parsed "Returns a boolean (an integer) that is TRUE if the agent is in the experience and the experience can run in the current region." as "Returns TRUE if the agent is on land where the experience is allowed", the same way llOverMyLand() works.

For this system to have even a little use, we need a way to check the status of the experience at the script's location, AND a separate method to see if the user has granted permissions (and can), without triggering a permissions check.

I don't see the point of BUG-8044, however. The function's name implies exactly what it's doing in that regard – returns FALSE if the agent is not within the Experience's purvey. Why would you want an Experience to work on an adjoining parcel that has forbidden it? That would be a huge security flaw.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2015-09-05T01:11:06Z

Basically I wanted llAgentInExperience() to perform more like it does when used in a Grid Scope key, but I really want performance similar to llSameGroup(), a yes or no return if the agent has the Experience allowed.

Currently, llAgentInExperience() when used in a Land Scope experience and targeting an agent that has the experience allowed, but the target is over land that doesn't have the experience allowed or has it blocked will return FALSE.

llAgentInExperience() when used in a Gride Scope experience and targeting an agent that has the experience allowed, but the target is over land that doesn't have the experience allowed will return TRUE. If the land the target is over has the experience blocked, it will return FALSE.

I simply want llAgentInExperience() to perform as its namesake implies without referencing anything about the land the script is over or the land the agent is over.

But, since the time I've filed the request, Experiences have moved out of beta testing phase and I think many users are now using llAgentInExperience() implicitly.

This means if the change was made it may break content. So it may not even happen now.

Which is why https://jira.secondlife.com/browse/BUG-6912 is probably a better means and will satisfy other use cases as well.

@sl-service-account
Copy link
Author

Cheshyr Pontchartrain commented at 2015-09-05T15:42:58Z

This function, as described in the official LL wiki, is supposed to tell you if the user is in the Experience's sphere of influence. Nothing in the documentation implies that it cares what permissions the user gave. If llAgentInExperience() is supposed to check both, then it's basically useless.

Your proposal in BUG-6912 will help, though there is no need for two functions that serve the same purpose.

Re grid-wide experience keys, they're a myth. The only people with them are Linden Lab staff, and a handful of programmers who managed to bribe their way into the system. I (Novatech), with tens of thousands of users clamoring for improved transportation tools, was denied by a Linden who swore such keys did not exist.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2015-09-05T21:56:39Z

They do exist. You can search all experiences and check each profile to see which ones are grid scope as the scope type is shown at the top of the experience profile.

There has been talk about making them available with a pricing schema along with the option of purchasing additional land scope experiences, but I have not heard anything recently about it.

Theres also an accepted proposal to be able to compile Experience based scripts at 128KB and 256KB. https://jira.secondlife.com/browse/BUG-8761

It may help bringing attention to these again in the User Group meetings.

@sl-service-account
Copy link
Author

Cheshyr Pontchartrain commented at 2015-09-06T00:51:00Z

Closing this JIRA as it was a misunderstanding, rather than a bug. Lucia's proposed function(s) will do what I need.

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