[BUG-6044] llSetLinkPrimitiveParams should apply allow a named no-transfer or no-copy texture to the same prim

[sl-service-account]

Steps to Reproduce

1. Create a prim with this script inside

default {
    touch_end(integer total_number) {
        string texture = llGetInventoryName(INVENTORY_TEXTURE, 0);

        llSetLinkPrimitiveParamsFast(LINK_THIS, [
            PRIM_TEXTURE, ALL_SIDES, texture, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0]) ;        
    }
}

2. Put a texture with no transfer or no copy permission.
3. Then touch the prim.
4. You will see the "Texture not copyable" or "Texture not transferable" eror message (or similar.)

Actual Behavior

The functions llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast with PRIM_TEXTURE seem not to apply a named texture (given by name, not the UUID) when the texture is not transferable or not copyable, even when called with LINK_THIS.

Expected Behavior

Calling of llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast with LINK_THIS as target should handle the textures without copy or transfer permissions in same way llSetTextue does: Set the texture and trigger no errors

Other information

There is no permission problem when calling the llSetLink* functions with LINK_THIS, because no other prims are affected and the texture is already in the prim inventory, so i think this exception is important.

This bug prevents creating a combined call with multiple parameters, especially with using the fast call (the main reason to use Link version of the llSetPrimitiveParams function.) But i guess also the llSetLinkTexture belongs to here, too.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-6044 | | Summary | llSetLinkPrimitiveParams should apply allow a named no-transfer or no-copy texture to the same prim | | Type | New Feature Request | | Priority | Unset | | Status | Been Triaged | | Resolution | Triaged | | Reporter | Jenna Felton (jenna.felton) | | Created at | 2014-05-16T00:58:11Z | | Updated at | 2015-09-03T21:40:23Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2014-05-16T12:11:24.188-0500', 'How would you like the feature to work?': "Currently, the functions llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast with PRIM_TEXTURE should apply a named texture (given by name, not the UUID) when the texture is not transferable or not copyable, when called with LINK_THIS. This case should be allowed since it doesn't present a permissions issue; it would offer the same functionality that llSetTexture() currently does, but without the built-in delay.", "Is there anything you'd like to add?": 'There is no permission problem when calling the llSetLink* functions with LINK_THIS, because no other prims are affected and the texture is already in the prim inventory, so i think this exception must be made.\r\n\r\nThis bug prevents creating a combined call with multiple parameters, especially with uing the fast version (the main reason to use Link version of the llSetPrimitiveParams function.) But i guess also the llSetLinkTexture belongs to here, too.', 'System': 'SL Simulator', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'The functions llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast with PRIM_TEXTURE seem not to apply a named texture (given by name, not the UUID) when the texture is not transferable or not copyable, even when called with LINK_THIS.', 'What were you doing when it happened?': 'Create a prim with this script inside\r\n\r\ndefault {\r\n touch_end(integer total_number) {\r\n string texture = llGetInventoryName(INVENTORY_TEXTURE, 0);\r\n\r\n llSetLinkPrimitiveParamsFast(LINK_THIS, [\r\n PRIM_TEXTURE, ALL_SIDES, texture, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0]) ; \r\n }\r\n}\r\n\r\nPut a texture with notransfer or nocopy permission. \r\nThen touch the prim. \r\nYou will see the "Texture not copyable" or "Texture not transferable" eror message (or similar.)', 'What were you expecting to happen instead?': 'Calling of llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast with LINK_THIS as target should handle the textures without copy or transfer permissions in same way llSetTextue does: Set the texture and trigger no errors', 'Why is this feature important to you? How would it benefit the community?': 'This would be useful so that scripts could set named textures on the prim they contain without resorting to llSetTexture() (which incurs a 200ms delay). With llSetLinkPrimitiveParamsFast() and PRIM_TEXTURE, there would be no delay.', } ```

[sl-service-account]

Jenna Felton commented at 2014-05-16T01:07:02Z, updated at 2014-05-16T01:10:07Z

Linked the SVC-5765 issue that explains good about permission problem with llSetLinkXX functions, but here (using LINK_THIS as target) we have a special case with no permission problems.

[sl-service-account]

Maestro Linden commented at 2014-05-16T17:11:24Z

This behavior is documented for https://wiki.secondlife.com/wiki/LlSetLinkTexture :

If texture is missing from the prim's inventory or not full permissions and it is not a UUID or it is not a texture then an error is shouted on DEBUG_CHANNEL. Perhaps that behavior should be covered in https://wiki.secondlife.com/wiki/LlSetLinkPrimitiveParams#Caveats_2 too.

[sl-service-account]

Jenna Felton commented at 2014-05-16T18:39:33Z

Oops, it is in the caveats already. I am sorry, i apparently have overseen it.

Than the function works as doccumented. However, this fast version is very good to create undelayed prim changes. Because i dont know any alternative to create fast texture assignment or texture changes (like change offset to show another picture frame) other than use llSetLinkPrimitiveParamsFast.

When it is not so easy to make a filter (decline texture changes with named texture and different prim, and allow the changes when used with LINK_THIS directly or after LINK_TARGET) than may i suggest another function like llSetLinkThisPrimitiveParamsFast() which will always use LINK_THIS as target and not allow using LINK_TARGET in the definitions?

Or alternativelly reduce this to just texture changing command like llChangeThisLinkTexture() that take a list similar to the llSetPrimitiveParams but for texture only. Than the permission issue will be avoided and we had a fast way of texture changing.

[sl-service-account]

Maestro Linden commented at 2014-05-19T18:30:10Z

I don't see a reason why we shouldn't allow setting a texture by name on the same prim that the texture is contained within (which would also be the same prim that the script is in, if you're specifying the texture by name), whether you're using LINK_THIS or specifying the prim number.

I do see your point - as the behavior is now, you're left with using llSetTexture() in this case, which has a 200ms delay. I agree that it would be nice if you could perform the texture-changing operation via llSetLinkPrimitiveParamsFast() instead. I'm moving this issue to a feature request.