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

[BUG-8044] [Experience Tools] Improvement - llAgentInExperience() needs to operate independent of parcel/region allowed/blocked experiences to reflect correct data. #15690

Open
1 task
sl-service-account opened this issue Dec 16, 2014 · 1 comment

Comments

@sl-service-account
Copy link

sl-service-account commented Dec 16, 2014

Information

llAgentInExperience() returns a false negative when targeting an agent that is participating in the experience, while they are over land that either does not have the experience allowed or has the experience blocked.

This is an improvement request in response to BUG-7159.

In that jira, Maestro stated, "Changing the spec of llAgentInExperience() is a possibility, but that would run a risk of breaking scripts which rely on existing behavior."

I don't see any way for an application to efficiently rely on this funcition when targeting agents on other parcels, with it's current behaviour.

This issue, along with the recently fixed problems in BUG-6757, BUG-7036 & BUG-7048 had forced me to require participants of my experience to physically be over the same experience allowed parcel as the script. With the latter problems fixed, we now have a means of distinguishing between whether an experience is allowed/blocked on the agent and whether its allowed at the script's location or at the location of the target.

This is why I feel llAgentInExperience() should be updated to explicitly & literally perform as it's namesake implies.

I feel that this is yet, another issue where an experience function was not initially setup to work in a non-estate environment(mainland).

Please consider improving the operation of the function.

Thanks in advance for any consideration.

Links

Related

Original Jira Fields
Field Value
Issue BUG-8044
Summary [Experience Tools] Improvement - llAgentInExperience() needs to operate independent of parcel/region allowed/blocked experiences to reflect correct data.
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Labels experience
Reporter Lucia Nightfire (lucia.nightfire)
Created at 2014-12-16T01:07:21Z
Updated at 2015-01-21T19:15:50Z
{
  'Business Unit': ['Platform'],
  'How would you like the feature to work?': 'llAgentInExperience() returns a false negative when targeting an agent that is participating in the experience, while they are over land that either does not have the experience allowed or has the experience blocked.\r\n\r\nThis is an improvement request in response to BUG-7159.\r\n\r\nIn that jira, Maestro stated, "Changing the spec of llAgentInExperience() is a possibility, but that would run a risk of breaking scripts which rely on existing behavior."\r\n\r\nI don\'t see any way for an application to efficiently rely on this funcition when targeting agents on other parcels, with it\'s current behaviour.\r\n\r\nThis issue, along with the recently fixed problems in BUG-6757, BUG-7036 & BUG-7048 had forced me to require participants of my experience to physically be over the same experience allowed parcel as the script. With the latter problems fixed, we now have a means of distinguishing between whether an experience is allowed/blocked on the agent and whether its allowed at the script\'s location or at the location of the target.\r\n\r\nThis is why I feel llAgentInExperience() should be updated to explicitly & literally perform as it\'s namesake implies.\r\n\r\nI feel that this is yet, another issue where an experience function was not initially setup to work in a non-estate environment(mainland).\r\n\r\nPlease consider improving the operation of the function.\r\n\r\nThanks in advance for any consideration.',
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': '?',
}
@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2014-12-18T22:58:30Z

Without this function working correctly or without an ExperienceAllowedAt() function as requested in BUG-6912, content creators cannot set up their experience apps with a pre- llRequestExperiencePermissions() protocol. They currently are forced into explicitly calling llRequestExperiencePermissions() first to know whether the experience is allowed at the target's location and/or if the target has the experience allowed. This means that when targeting an agent who is not yet participating in the experience, they will get the permissions request dialog.

Without a means of accurately checking if the target is in the experience and/or if the experience is allowed at their location, we are forced into requesting permissions first.

To some, without any up-front information, the current experience permissions dialog can seem a little alarming or intrusive.

If either issue was addressed, experience applications could be setup to first send non-participants information on the experience, what an experience is, including information on the joining process. The agent could then choose whether to go forward or not before receiving a permissions dialog.

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