sl-service-account
commented
1 year ago Maestro Linden commented at 2023-09-20T18:12:10Z
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.
How would you like the feature to work?
This new function would be used in conjunction with a proposed new event, before_pay(), to make it possible to set a custom sale price based criteria such as the identity of the buyer, group memberships, etc.
Syntax: llSetAgentPayPrice(key id, integer price, list quick_pay_buttons)
Where:
price and quick_pay_button are identical to the llSetPayPrice() parameters.
The function would modify the next pay price dialog shown to the agent identified by id. It would only affect one instance of the dialog.
It would only work inside the before_pay() event handler. This is similar to how llDetectedX() functions only work inside detection events.
The proposed before_pay() event is described here: https://jira.secondlife.com/browse/BUG-234435
Why is this feature important to you? How would it benefit the community?
Combined with the proposed event this would vastly simplify offering discounts or other price adjustments in scenarios where the price depends on factors such as the identity of the buyer, group membership, date and time or any other reason.
It would be more elegant, simpler and safer than relying on refunds, debit permissions, etc.
This feature would provide enhanced functionality and simplicity for both merchants and customers.
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-234434 | | Summary | New LSL function: llSetAgentPayPrice() | | Type | New Feature Request | | Priority | Unset | | Status | Been Triaged | | Resolution | Triaged | | Reporter | Cain Maven (cain.maven) | | Created at | 2023-09-19T19:12:49Z | | Updated at | 2023-09-20T18:12:10Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-09-20T13:12:10.262-0500', 'How would you like the feature to work?': 'This new function would be used in conjunction with a proposed new event, before_pay(), to make it possible to set a custom sale price based criteria such as the identity of the buyer, group memberships, etc.\r\n\r\nSyntax: llSetAgentPayPrice(key id, integer price, list quick_pay_buttons)\r\n\r\nWhere:\r\n- id is the UUID of the agent making the purchase.\r\n- price and quick_pay_button are identical to the llSetPayPrice() parameters.\r\n\r\nThe function would modify the next pay price dialog shown to the agent identified by id. It would only affect one instance of the dialog.\r\n\r\nIt would only work inside the before_pay() event handler. This is similar to how llDetectedX() functions only work inside detection events. \r\n\r\nThe proposed before_pay() event is described here:', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'Combined with the proposed event this would vastly simplify offering discounts or other price adjustments in scenarios where the price depends on factors such as the identity of the buyer, group membership, date and time or any other reason.\r\n\r\nIt would be more elegant, simpler and safer than relying on refunds, debit permissions, etc.\r\n\r\nThis feature would provide enhanced functionality and simplicity for both merchants and customers.', } ```