Chimera's ColorPicker script makes pallete & slider prims all grey when set to no-modify

[hectic1]

Hello everybody,

as the title hints, i'm playing around with Chimera's Free Color Picker (https://chimerafire.wordpress.com/scripts_main/chimeras-color-picker-a-free-script/). I'm no scripter, but I used to be pretty good in C like decades ago, so i'm not completely clueless i guess lol

Anyway, the script works fine as long as its mod-perm is on. I made a few changes to the code, passed it to a friend as no-mod to tell me her opinion, but as soon as she was clicking on either the color-palette rainbow (the plus marker) or the luminosity slider, they were going all greyed out. The picker is still working, but u can't see which color or luminosity you pick, cause they go all grey. I passed it to another friend, just to make sure, and the same thing happened. Once I gave them the picker object with the script in it as mod it was working fine.

Lastly, just to make sure this was not due to my changes to the code, I gave them the original thing and the same thing was happening. Any ideas for the cause, and maybe how it can get fixed?

Thanks in advance.

PS. The script is freely available at chimera's in-world store (see the link above), but I can also attach it here too I guess if it's needed (btw i've even seen that chimera was asking help in this forum when doing it, back in 2014 hehehe).

[Nova Convair]

A script can NOT read out texture uuids if the owner has not full permissions of the object. So llGetTexture or llGetLinkPrimitiveParams return a NULL_KEY and that is displayed as grey.

So give it away full perm or start to rewrite it. That will require to fully understand how it works though.

[hectic1]

Hi, thanks for the quick reply

The whole thing was full perm already, and i have indeed written my own script which uses parts of chimera's code. And it was my object that i was giving to friends for their opinion. But now that you have mentioned the llGet* returning NULL_KEY, could it be that i'm not the creator of the textures embed in chimera's picker? Cause i linked his/her picker object with mine (adding more stuff, i'm actually trying to make a custom HUD, using chimera's color-picker just for the coloring part). So its my script in the root of my object (HUD).

Maybe if i replace the background pictures of chimera's palette & slider prims with my own solve the problem? I think it is worth a try, ty for pointing out the NULL_KEY thingy

Okies, i'll give it a try with random textures of mine and i'll get back. Thx again for that pointer

PS. The bad thing here is that everything works fine in my end, so i can only see the results of changes i make  if i give the object to someone else to test it.

Edited March 26, 2017 by hectic1

[Nova Convair]

No it's not a matter of textures permissions but object permissions.

I didn't analyze the script and don't know why it reads out the textures. Maybe it's sufficient to set some global variables with the texture uuids and use this variables instead. If you don't have the textures you need to ask the creator or make your own. But llGetTexture or llGetPP are not able to read textures on no mod objects, no matter who owns the texture.

It's mentioned in the wiki and I found it out the hard way some years ago.

[Rolig Loon]

Just in case you haven't already found it in the wiki yourself:

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.

[hectic1]

Thx for one more reply Nova,

but i have to admit I'm officially confused HAHAHAHAHHA. So, let's say i re-create chimera's color-picker object using my own prims & textures, the object will still not work if i pass it to others as no-mod? And how about the script itself? I think chimera's picker worked when passed it to the friend with the object being no-mod, but the script in it being modifiable.... i'm sooo confused loool

 

[Innula Zenovka]

I've not gone in-world to pick up a copy of the script, but I've taken a look at the script as posted at the URL, and I see it uses textures to move the markers about (an approach Nova suggested, apparently!):

Quote

//One key problem in putting the Color Picker together was trying to come up with a method of 
//  marking where the user clicked in the color palette and luminosity slider.  When one is trying to 
//  get just the right color, it’s very helpful - almost critical - to have those two reference points.
//  Thankfully, Nova Convair came to the rescue by responding to my post on the scripting forum.  His
//  solution was unique and elegant.  He suggested - and provided some sample code - using
//  a transparent prim with a marker on it to overlay the color palette.  Here's the real genius in
//  his approach: moving the marker to the last clicked point was done not by using positioning 
//  coordinates (the usual approach), but rather by using texture off-sets.  You'll see that in the 
//  code, below, where llSetLinkPrimitiveParams moves the "Plus Marker" prim by off-sets.  The same 
//  solution worked for the luminosity slider.

The script reads the texture's UUID, so if the texture isn't full perms for the owner, then that's not going to work.

If the script can't read the UUID, this would certainly explain what the OP describes.   The fix, if that is the case, is simple.   Just hard-code the pointer texture's UUID as a global variable, and take out the sections of the code that try to read it.   That should work.

ETA:  I've just taken a closer look at the script and it looks as it there are two textures involved, one for the luminosity pointer and one for the colour marker.   So hard-code the uuids of those textures as global variables and use those instead of string TextureName and string TextName in the user functions  MoveLumPointer and MovePlusMarker.    I think that's all that needs doing.

Edited March 26, 2017 by Innula Zenovka

[hectic1]

8 minutes ago, Innula Zenovka said:

I've not gone in-world to pick up a copy of the script, but I've taken a look at the script as posted at the URL, and I see it uses textures to move the markers about (an approach Nova suggested, apparently!):

The script reads the texture's UUID, so if the texture isn't full perms for the owner, then that's not going to work.

If the script can't read the UUID, this would certainly explain what the OP describes.   The fix, if that is the case, is simple.   Just hard-code the pointer texture's UUID as a global variable, and take out the sections of the code that try to read it.   That should work.

Yes, the code indeed tries to read the PlusMarker and LumSlider handle textures via llGetLPP. It should't be difficult to replace them with my own textures and use 2 global vars for their UUIDs. Ty so much both of you!

PS. Hey Nova, you have even helped chimera when he was making the script back in 2014 for giving me trouble in 2017 HAHAHAHAH.... Just kidding ofc, TY, i'm gonna try the suggested fix and I'll come back!

 

[Innula Zenovka]

I am not sure it matters, but I would declare TextureName and TextName as keys, not strings, when I declare the variables.   LSL is sometimes picky about whether something is a string or a key and sometimes doesn't mind, and I can't remember which applies here.

[hectic1]

Awww, ty Innula! Very useful info!

[hectic1]

Okies, I tried it with the UUID of a random tetxure of mine and it seemed to work, no more grey... ty so much

However, chimera's code also reads the texture repeats and offsets via the same call to llGLPP, it modifies and re-applies them, as shown in the snippet that follows (well, its his code with my modified var names).

Does that mean that if i use normal textures (which as far s i can tell are actually 2 transparent png's, one with a cross-hair in the middle, and one with a slider-handle in the middle) they will get screwed up when they move around due to wrong repeats and offsets? I mean if GLPP() returns NULL_KEY, vrepeats and voffsets will be read wrongly too, right? If so, is there a work around, just for the repeats and the offsets?

cpLumPointerDo()
{
	integer lum;					// lum is our variable for luminosity
	// params_list is a list consisting of texture name, repeats, off-sets, etc.
	list params_list		= llGetLinkPrimitiveParams(g_lum_pointer_link, [PRIM_TEXTURE,llDetectedTouchFace(0)]);
//	string tex_name_str		= llList2String(params_list, 0);
	string old_params_str	= llList2String(params_list, 1);	// repeats
	vector vrepeats			= (vector)old_params_str;
	string old_params2_str	= llList2String(params_list, 2);	// offsets
	vector voffsets			= (vector)old_params2_str;
	g_lum_slider_touch_vcoords	= llDetectedTouchST(0);			// local coordinates
	vector v				= g_lum_slider_touch_vcoords;		// We'll use v for the offsets
	//llOwnerSay("Lum slider touched - Y = "+(string)v.y);

	v.x = voffsets.x;        // x (horizontal stays the same - we are only interested in Y

	// LumPointer is made larger so that the pointer doesn't disappear on top & bottom,
	// so make sure the pointer arrow doesn't exceed the top or bottom of the lum slider
	if (g_lum_slider_touch_vcoords.y < .023913) {
		v.y=.023913;
	}
	if (g_lum_slider_touch_vcoords.y > .973882) {
		v.y=.973882;
	}
	v.y -= .47;        // .47 instead of .5 provide more accurate placement

	//llOwnerSay("Lum pointer MOVED to OFFSET = " + (string)v.y);
	// this moves the lum pointer to the touched location
//	llSetLinkPrimitiveParamsFast(g_lum_pointer_link, [PRIM_TEXTURE, llDetectedTouchFace(0),
//						   tex_name_str, vrepeats, v, PI ]);
	llSetLinkPrimitiveParamsFast(
		g_lum_pointer_link, [PRIM_TEXTURE, llDetectedTouchFace(0), g_lum_pointer_tex_UUID, vrepeats, v, PI] );
...

PS. Inulla, seems like it works with the global vars defined as strings.

[Innula Zenovka]

I think that the texture permissions determine only whether the script can read the texture's UUID.   It shouldn't affect the script's ability to read the offsets and repeats.

But that shouldn't be an issue if you're hard-coding the UUIDs.   In state entry, set the texture of the two prim faces by script and then, in the two user functions, just ignore the first list item returned by llGetLinkPrimitiveParams.   Something like this:

key kTextName = "some uuid";

MoveLumPointer(vector ColorHSL)
{    
     list ParamList = llGetLinkPrimitiveParams(gLPointerNo,[PRIM_TEXTURE,4]);
     //ParamList is a list consisting of texture name, repeats, off-sets, etc.
    // string TextName = llList2String(ParamList,0);        
     string OldParams= llList2String(ParamList,1); //repeats
     vector Repeats = (vector)OldParams;
     string OldParams2 = llList2String(ParamList,2); //offsets
     vector OffSets = (vector)OldParams2;
     //<snip>
     //...
     //<end snip>
     llSetLinkPrimitiveParamsFast(gLPointerNo, [PRIM_TEXTURE, 4, kTextName, Repeats, ColorHSL, PI ]);
}

 

[hectic1]

Ty Innula!

I'll try to see if it indeed reads the repeats and the offsets right as is (meaning just having the 2 UUIDs defined as globals, not doing anything in state entry, and just ignoring the 1st returned list inside the 2 user-defined funcs). Else i'll do what u just suggested! Ty again!

[Innula Zenovka]

No, you can't simply ignor[e} the 1st returned list inside the 2 user-defined funcs.   You need that get the texture's offset (vector Repeats).   You ignore the first item in the list (the texture UUID) since you already know what that is.

[hectic1]

Aw I'm sorry, yes i meant the 1st item in the list (the texture UUID), not the 1st returned list.. that was a typo

What i wanted to say, is since it will be my texture, i will assign it to the plus-marker prim (that is replacing chimera's) so I won't have to set it again in the state entry. That wouldn;t cause a problem, right?

[Innula Zenovka]

That shouldn't be a problem at all.   What I meant was that you should apply the texture to the appropriate face, with llSetLinkPPFast or llSetLinkTexture() (slower, but simpler in this case) in state entry, but so long as you've applied your textures manually and the offsets are correct, then no, you don't need to do even that.  

[hectic1]

I'd like to add that everything worked fine, ty so much for the help (tho i'm sure i'll come back with diff questions as i go on hahahaha).