Only set Ambiance on PRIM_PROJECTOR

[ValKalAstra]

Having a bit of a headache that might have got a simple solution I just managed to miss or might be a cliff with half my project racing over it. I want to set only part of a parameter, not all of the values. For example, PRIM_PROJECTOR is defined as:

[ string texture, float fov, float focus, float ambiance ]

So what do I do, if I only want to change ambiance and none of the other values? With PRIM_PROJECTOR being a bit... "llGetPrimitiveParams error: Param 0 error, unknown parameter" owed to the whole write-only access thing going on, I can't very well read out the previous values. Thus I come here with my question: Is there a way to only change ambiance but not the other values? From my understanding, it expects a full set of rules for the parameter. Which I can't give it with the parameters on PRIM_PROJECTOR being locked off.

Am I just missing something simple?

 

 

[Frionil Fang]

You have to provide all parameters, no way to mark a field as "don't change". Unfortunately that means to adjust a projector (or normal map, or specular) you need access to the texture uuid somehow -- being unable to get the projector params is not a huge problem if you have full perm textures to begin with.

[KT Kingsley]

The function you want is llGet[Link]PrimitiveParams.

It goes something like this:

list params = llGetPrimitiveParams ([PRIM_PROJECTOR]);
params = llListReplaceList (params, [my_new_ambiance], 3, 3);
llSetPrimitiveParams (params);

Totally untested.

Erm, yes. Don't forget to assign the return from llListReplaceList back to the variable params, like I did when I first posted this.

Edited April 25, 2022 by KT Kingsley

[ValKalAstra]

1 hour ago, Frionil Fang said:

You have to provide all parameters, no way to mark a field as "don't change". Unfortunately that means to adjust a projector (or normal map, or specular) you need access to the texture uuid somehow -- being unable to get the projector params is not a huge problem if you have full perm textures to begin with.

Thank you for your reply. For my purposes that would create the need to use tracker variables and hope the users don't fuff about with edit. That's going to be a headache and then some but no way around it. Okay, that helps me. At least I'm starting to understand why it was set to write only.

1 hour ago, KT Kingsley said:

The function you want is llGet[Link]PrimitiveParams.

It goes something like this:

list params = llGetPrimitiveParams ([PRIM_PROJECTOR]);
llListReplaceList (params, [my_new_ambiance], 3, 3);
llSetPrimitiveParams (params);

Totally untested.

Thank you as well - that's the function I have been using - but the issue is that when llGetPrimitiveParams (or the link variant) is paired with PRIM_PROJECTOR, the script will exit with:

[07:33] llGetPrimitiveParams error: Param 0 error, unknown parameter

Reason being, PRIM_PROJECTOR, to my knowledge, is write only.

 

 

[KT Kingsley]

Yeah. Now I've tried it, I can confirm PRIM_PROJECTOR throws a run-time error when used with llGetPrimitiveParams. This is, to me, unexpected behaviour (seeing as how it's documented in the wiki), and probably worth a jira. Unless someone out there knows if or why this implementation hasn't happened.

Edited April 25, 2022 by KT Kingsley

[Fenix Eldritch]

Unfortunately not a bug. The release notes when this parameter was added vaguely state as such: https://releasenotes.secondlife.com/simulator/2021-10-25.565008.html

And the Devs have commented on it being write only, as well:

I presume it will eventually be added to llGetPrimitiveParams. But yes, it being listed on the function's wiki page without that current caveat is quite misleading.

As an aside, there are several accepted JIRAs for adding a form of bypass constant, or at least decoupling some of the llSLPPF parameter groups like PRIM_TEXTURE and PRIM_PROJECTOR. Though no ETA yet on when they will be worked on.

Edited April 25, 2022 by Fenix Eldritch
additional info

[Rolig Loon]

8 hours ago, KT Kingsley said:

Yeah. Now I've tried it, I can confirm PRIM_PROJECTOR throws a run-time error when used with llGetPrimitiveParams. This is, to me, unexpected behaviour (seeing as how it's documented in the wiki), and probably worth a jira. Unless someone out there knows if or why this implementation hasn't happened.

@Rider Linden  Do you know why the PRIM_PROJECTOR constant isn't recognized by llGetLinkPrimitiveParams?

[Mollymews]

probably didn't have enough time to do the Get part when did the Set part

[Rider Linden]

15 hours ago, Rolig Loon said:

@Rider Linden  Do you know why the PRIM_PROJECTOR constant isn't recognized by llGetLinkPrimitiveParams?

Yes.

 

 

 

Oh! You wanted more detail 😉

It is not supported at this time on purpose.  I had it in the initial release of the feature, but it was pointed out to me that it provided an avenue for getting around certain permissions in some cases so I removed it.  It is the same reasoning that I had with sun/moon/cloud textures in the LSL for EEP where I will only tell you whether or not the texture is the default texture for the settings, but not give you its UUID.

[Rolig Loon]

Thanks, Rider.  That does make sense, but could you maybe take an approach similar to some other LSL functions and only provide a texture UUID if the texture is in the user's inventory?  It seems a shame to disallow PRIM_PROJECTOR for finding the other parameters just because texture UUID is a problem.

[Fenix Eldritch]

Yeah, given how llGetTexture and llGetPrimitiveParams([ PRIM_TEXTURE,...]) already work, I would have assumed PRIM_PROJECTOR would have followed suit.

Quote

With texture as with llGetTexture, NULL_KEY is returned when the owner does not have full permissions to the object and the texture is not in the prim's inventory.

[Lucia Nightfire]

4 hours ago, Rolig Loon said:

but could you maybe take an approach similar to some other LSL functions and only provide a texture UUID if the texture is in the user's inventory?

What LSL functions do this?

Texture UUIDs should only be resolved if the container they're applied to is full-perms.

Tying in query of a user's inventory would most likely be a huge resource hit, delay output and most likely wouldn't be worth it for general purpose use cases.

Edited April 26, 2022 by Lucia Nightfire

[Elisabeth Ohmai]

@Rider Linden Hello! What about release Rolig Loon idea?

On 4/26/2022 at 8:20 PM, Rolig Loon said:

Thanks, Rider.  That does make sense, but could you maybe take an approach similar to some other LSL functions and only provide a texture UUID if the texture is in the user's inventory?  It seems a shame to disallow PRIM_PROJECTOR for finding the other parameters just because texture UUID is a problem.

Right now PRIM_PROJECTOR looks unfinished

[Rider Linden]

Checking a users inventory would be a huge processing hit and isn't something that we do anywhere else in LSL.  (Giving scripts access to a user's inventory opens up a huge security hole.)

 

[Wulfie Reanimator]

@Elisabeth Ohmai @Rider Linden

I think Rolig was referring to how llGetTexture works:

• If the texture is in the prim's inventory, the return value is the inventory name, otherwise the returned value is the texture UUID.
• NULL_KEY is returned when the owner does not have full permissions to the object and the texture is not in the prim's inventory.

Could the UUID for PRIM_PROJECTOR work the same way (as with PRIM_TEXTURE)?

Edited September 21, 2022 by Wulfie Reanimator

[Elisabeth Ohmai]

3 hours ago, Wulfie Reanimator said:

@Elisabeth Ohmai @Rider Linden

I think Rolig was referring to how llGetTexture works:

• If the texture is in the prim's inventory, the return value is the inventory name, otherwise the returned value is the texture UUID.
• NULL_KEY is returned when the owner does not have full permissions to the object and the texture is not in the prim's inventory.

Could the UUID for PRIM_PROJECTOR work the same way (as with PRIM_TEXTURE)?

Yes, that's exactly what I meant. Using a scheme to work with UUIDS like other flags (PRIM_TEXTURE, PRIM_NORMAL, PRIM_SPECULAR)

[2Tessa]

PRIM_PROJECTOR is working ONLY if the projected texture is in the object inventory.

The wiki should mention about this requirement.

Edited March 18 by 2Tessa