[BUG-230679] Events triggered when avatars enter exit the current parcel/region

[sl-service-account]

How would you like the feature to work?

These events only fire for scripts deeded to the landowning group, or owned by the landowner: parcel_enter(integer num_detected) parcel_exit(integer num_detected)

These events only fire for scripts owned by an estate manager: region_enter(integer num_detected) region_exit(integer num_detected)

They would follow the standard llDetected*() event format used by touch, collision and sensors.

Why is this feature important to you? How would it benefit the community?

Even with functions like llGetAgentList, which greatly simplified checking for avatar presence, we still have to use timer polling loops and potentially large list comparisons to be notified when avatars enter/exit a given area.

On their own, these loops don't cost much, but they are so common in so many applications that it would make sense to add specific events for them.

(You currently have to balance how often you want to run the loop to make sure visitors are accounted for, and how much pressure you want to add to event processing)

Example applications: security orbs, greeters, visitor traffic analysis, player tracking, crowd size management, ...

These events wouldn't do anything that we can't do within LSL scripts already, but they would do it better, with less overhead, and more accurately.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-230679 | | Summary | Events triggered when avatars enter exit the current parcel/region | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Reporter | Kyrah Abattoir (kyrah.abattoir) | | Created at | 2021-05-04T10:47:38Z | | Updated at | 2021-05-05T20:38:20Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2021-05-04T06:05:32.994-0500', 'How would you like the feature to work?': 'These events only fire for scripts deeded to the landowning group, or owned by the landowner:\r\nparcel_enter(integer num_detected)\r\nparcel_exit(integer num_detected)\r\n\r\nThese events only fire for scripts owned by an estate manager:\r\nregion_enter(integer num_detected)\r\nregion_exit(integer num_detected)\r\n\r\nThey would follow the standard llDetected*() event format used by touch, collision and sensors.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "Even with functions like llGetAgentList, which greatly simplified checking for avatar presence, we still have to use timer polling loops and potentially large list comparisons to be notified when avatars enter/exit a given area.\r\n\r\nOn their own, these loops don't cost much, but they are so common in so many applications that it would make sense to add specific events for them.\r\n\r\n(You currently have to balance how often you want to run the loop to make sure visitors are accounted for, and how much pressure you want to add to event processing)\r\n\r\nExample applications: security orbs, greeters, visitor traffic analysis, player tracking, crowd size management, ...\r\n\r\nThese events wouldn't do anything that we can't do within LSL scripts already, but they would do it better, with less overhead, and more accurately.", } ```

[sl-service-account]

ryokotensaki commented at 2021-05-04T11:05:33Z

I think this would be similar to the recently added AnimationOverride series of functions where it streamlines something people are already doing to provide a better experience with less cost to the sim, like eliminating 0.1s timer and/or sensor spam with complex checks. Currently the only method comparing lists to look for changes, then pulling out and reporting the changes, which in a rental area with numerous houses and their accompanying security systems, or various other things doing the same will add up fast to impact a sim, much like a room full of avatars wearing old-style AOs will. This would be very useful.

[sl-service-account]

fox.cheri commented at 2021-05-04T14:58:44Z

I am in agreement with what RyokoTensaki stated, and likewise, I find that the usability for both clubs and roleplay sims would be immense given that the current state of accounting for people by using sensors and agentlists can be beyond taxing just to maintain a number, It could also have a significantly smoother application in combination with Experience.

[sl-service-account]

Dan Linden commented at 2021-05-05T20:38:21Z

Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone. 

Thank you for your continued commitment to Second Life.