Jump to content

Only set Ambiance on PRIM_PROJECTOR


ValKalAstra
 Share

You are about to reply to a thread that has been inactive for 105 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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?

 

 

Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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 by KT Kingsley
  • Thanks 2
Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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 by KT Kingsley
Link to comment
Share on other sites

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 by Fenix Eldritch
additional info
  • Thanks 2
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • Lindens
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.

  • Like 1
  • Thanks 3
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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 by Lucia Nightfire
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 105 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...