sl-service-account
commented
2 years ago JIRAUSER341305 commented at 2022-05-13T03:28:13Z
I'd additionally be wanting llSetLinkDatastring and llGetLinkDatastring functions for fast and simple direct access (those lists in the params functions are a drag).
I would also want to stress, this should intentionally not be supported by llGetObjectDetails. (And would probably be best if it wasn't shared with viewers, too.)
Otherwise, sounds like a fantastic idea to me.
How would you like the feature to work?
Scripters request (via forums, Builders Brewery group chat) a feature to store and modify data on a prim that survives script reset, region change, region restart, copy, and re-rez.
This feature is a straightforward prim data property balancing many usability needs.
Prims would gain the ability to hold at least 127 bytes of data as a "data string" prim property.
This property is persistent like name, description, scale, texture and many other properties.
This property would be available to get and set for these functions: llSetPrimitiveParams llSetLinkPrimitiveParams llSetLinkPrimitiveParamsFast llGetPrimitiveParams llGetLinkPrimitiveParams
If no PRIM_DATASTRING has been defined (eg, all existing prims as of this writing), the non-existence of this property returns an Empty String.
This property is able to be get/set via script inside the object like any other prim property and introduces no additional complications for permissions or viewer interface.
This property does not exist by default, making it compatible with all of SL and minimally "hungry" for added sim resources, as no prim will use extra data unless this string is explicitly defined.
Existing events like "changed" and on_rez already supply everything needed to reset or alter this otherwise-persistent value when / if needed.
Care must be taken to avoid race conditions. This is fundamentally no different than current workarounds.
How much data to store is a open to debate; if it were possible to store 64k of data, like a notecard, then attempting to load this value would crash a script. But at a minimum, make it equivalent to what the Description field can hold. This way, we can directly move our clunky description-based storage over to prim data.
This feature resembles, but is fundamentally different from BUG-216193, which requests a data type which can be accessed externally and via key-based permissions synchronously and asynchronously. This request has a much smaller scope with no implications for access permissions etc.
Why is this feature important to you? How would it benefit the community?
To me, I want to be able to do this right. Storing persistent, modifiable data is a tremendously common request, and at present we can only accomplish it by misusing other features. All workarounds involve taking away a feature in order to re-purpose its data field, and unintended uses of fields are often subject to breaking changes.
But the primary purpose of the request: To replace the current necessary practice of using of the Description field for program data. You'll see this in teleporters, clothing huds, and in the ever-present CasperVend Vendors (and other vending and gaming experiences).
How would it benefit the community?
Primarily, by no longer hindering existing benefits. The frequent hijacking of the description field for programming data has negative community implications:
Accessibility: For screen-reader type viewers, the description field is vital for Second Life's acceptance as an accommodations-friendly metaverse. Attempting to set up a "screen-reader-friendly visitor's region" by adding descriptive text to all important elements (a common task in course website systems at all US colleges nowadays) will break functionality with the object's scripts.
Usability: Modern web-based experiences generally feature "hover for tip/description" functionality. Users expect and desire in-context descriptive help. We have a description field, we need to be able to use it.
Functionality: This field does not need to be exposed to the UI, eliminating the chance that end users will thoroughly break scripted objects by attempting to put in a description. (Or by changing textures, etc)
Frees up the description field to good script-driven uses. For example, modifying the description of an object as the object changes (Eg: "This die is showing the number 3")
It's hard to put into words how universally asked-for this feature is, and how fundamentally sound a practice it is to separate end-user input data from data required for program execution.
I can't imagine a visually impaired individual attempting to visit a shopping event in SL today with assistive reading technology. Where there ought to be lovely product descriptions on the root prim of every vendor, there is instead "(No Description)@01234567-89ab-cdef-0123-456789abcdef".
Metaverses are trending again - assistive technologies are important for community engagement and as legal requirements for education institutions.
The existing prim properties have specific, intended uses--and many of them are end-user experience related. We should not need to co-opt these vital features in order to make Second Life interactive. The non-scripter end-user should not have to contend with breaking scripts by using end-user-intended UI features.
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-232133 | | Summary | Request: Property PRIM_DATASTRING | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Created at | 2022-05-12T19:40:19Z | | Updated at | 2022-11-01T01:20:56Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2022-05-12T22:28:12.904-0500', 'How would you like the feature to work?': 'Scripters request (via forums, Builders Brewery group chat) a feature to store and modify data on a prim that survives script reset, region change, region restart, copy, and re-rez.\r\n\r\nThis feature is a straightforward prim data property balancing many usability needs.\r\n\r\nPrims would gain the ability to hold at least 127 bytes of data as a "data string" prim property. \r\n\r\nThis property is persistent like name, description, scale, texture and many other properties.\r\n\r\nThis property would be available to get and set for these functions:\r\nllSetPrimitiveParams\r\nllSetLinkPrimitiveParams \r\nllSetLinkPrimitiveParamsFast \r\nllGetPrimitiveParams\r\nllGetLinkPrimitiveParams\r\n\r\nIf no PRIM_DATASTRING has been defined (eg, all existing prims as of this writing), the non-existence of this property returns an Empty String.\r\n\r\nThis property is able to be get/set via script inside the object like any other prim property and introduces no additional complications for permissions or viewer interface.\r\n\r\nThis property does not exist by default, making it compatible with all of SL and minimally "hungry" for added sim resources, as no prim will use extra data unless this string is explicitly defined.\r\n\r\nExisting events like "changed" and on_rez already supply everything needed to reset or alter this otherwise-persistent value when / if needed.\r\n\r\nCare must be taken to avoid race conditions. This is fundamentally no different than current workarounds.\r\n\r\nHow much data to store is a open to debate; if it were possible to store 64k of data, like a notecard, then attempting to load this value would crash a script. But at a minimum, make it equivalent to what the Description field can hold. This way, we can directly move our clunky description-based storage over to prim data.\r\n\r\nThis feature resembles, but is fundamentally different from BUG-216193, which requests a data type which can be accessed externally and via key-based permissions synchronously and asynchronously. This request has a much smaller scope with no implications for access permissions etc.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'To me, I want to be able to do this right. Storing persistent, modifiable data is a tremendously common request, and at present we can only accomplish it by misusing other features. All workarounds involve taking away a feature in order to re-purpose its data field, and unintended uses of fields are often subject to breaking changes. \r\n\r\nBut the primary purpose of the request: To replace the current necessary practice of using of the Description field for program data. You\'ll see this in teleporters, clothing huds, and in the ever-present CasperVend Vendors (and other vending and gaming experiences). \r\n\r\nHow would it benefit the community?\r\n* Primarily, by no longer hindering existing benefits. The frequent hijacking of the description field for programming data has negative community implications: \r\n\r\n* Accessibility: For screen-reader type viewers, the description field is vital for Second Life\'s acceptance as an accommodations-friendly metaverse. Attempting to set up a "screen-reader-friendly visitor\'s region" by adding descriptive text to all important elements (a common task in course website systems at all US colleges nowadays) will break functionality with the object\'s scripts. \r\n\r\n* Usability: Modern web-based experiences generally feature "hover for tip/description" functionality. Users expect and desire in-context descriptive help. We have a description field, we need to be able to use it.\r\n\r\n* Functionality: This field does not need to be exposed to the UI, eliminating the chance that end users will thoroughly break scripted objects by attempting to put in a description. (Or by changing textures, etc)\r\n\r\n* Frees up the description field to *good* script-driven uses. For example, modifying the description of an object as the object changes (Eg: "This die is showing the number 3")\r\n\r\nIt\'s hard to put into words how universally asked-for this feature is, and how fundamentally sound a practice it is to separate end-user input data from data required for program execution. \r\n\r\nI can\'t imagine a visually impaired individual attempting to visit a shopping event in SL today with assistive reading technology. Where there *ought* to be lovely product descriptions on the root prim of every vendor, there is instead "(No Description)@01234567-89ab-cdef-0123-456789abcdef".\r\n\r\nMetaverses are trending again - assistive technologies are important for community engagement and as legal requirements for education institutions. \r\n\r\nThe existing prim properties have specific, intended uses--and many of them are end-user experience related. We should not need to co-opt these vital features in order to make Second Life interactive. The non-scripter end-user should not have to contend with breaking scripts by using end-user-intended UI features.\r\n', } ```