Chimera Firecaster

Thanks Rolig. Yes, agreed. Recent content on the scripting forum is formatted as it should. I guess, lately, I've been accessing a series of older posts, and all of the code examples happen to be in the horizontal format. C'est la vie. I'll live with it.

I'm sure there is an easy solution to this, but I've searched and searched and can't find it. In this Scripting forum, individuals will post samples of code in a horizontal format. To move through the code, you click on the scroll arrows. Here's an example: https://gyazo.com/019c3f006bc6806810470c07aed9838f. I find it really difficult to read and understand code in this way. What I typically do is to highlight the code from start to finish, copy it, paste it in notepad or a SL script. Then I'll slowly parse it into separate lines as it would appear in a normal script. But it's really a time consuming process. Is there some trick when dealing with horizontal code? Any easy way to get formatted correctly?

Thanks ChinRey. I've been trying to figure out what was happening. All this weekend and today, I was getting a "login failed" message on the beta grid. The "Status Blog" where you would expect to find the information had no mention of it. So . . . I greatly appreciate your message.

Thanks Nova and Rolig. And Nova thanks for the extra details - that helps! I think I understand, but I'm, going to sit and do a little knitting and let it sink in. That usually does the trick. Thanks again!

Yes. I tried it. That's the reason for my question. The texture is set at a rotation of 0. In order for this solution to work, however, it must be rotated by PI. I'm wondering why.

Yes, I understand that, but why does the rotation need to change? Why can't I use the value of texture's existing rotation by use of llGetLinkPrimitiveParams for the rotation in SLPPF function?

Awesome Nova! What a elegant way to appoach it. That was very kind of you to even provide a transparent texture. Your solution is quicker and smoother than moving a prim. I'll need to re-work my color picking routine since the current approach relies on actually touching the color palette, but there should be a way to work from a touch on the transparent prim. I do have a question concerning the rotation of the transparent texture. I tried picking up the rotation of the transparent texture with llGetLinkPrimitiveParams and using that instead of PI in the SLPPF function. But it doesn't t work. PI seems to be key in your solution, but I don't quite understand why it is important. Could I trouble you to help me understand why PI is important to make this work.

Nova, that's a fascinating approach! Wow. Have you done this? How do you take the touch coordinates and work with them to offset the transparent texture. Do you have some code snippets you could share?

I have discovered something - and I thought I would add just a bit more information for others who may run into a similiar situation. I'll continue to use the color picker as an example, but there's a general principle that applies to moving a prim in a linked set. To simplify, let's just consider three parts: the base prim (the parent), luminosity slider (child prim), and the pointer (child prim). The script is located in the luminosity slider, and it determines the link number of the pointer. It then detects the location where it's being touch on the luminosity prim by use of llDetectedTouchST. That all works to plan. Here's where the surprise comes - a surprise at least to me. When llSetLinkPrimitiveParams is used to move the pointer to the detected location on the luminosity prim, it does NOT move to a location on the luminosity prim. It moves to a location on the base (the PARENT prim). Even though the script is running in the child prim, movement is in relation to the parent. When I determined the size of the luminosity prim and offset the horizontal and vertical distances by 1/2 the prim's dimensions, that was all irrelevant. It was the parent prim that I needed to be concerned with. And, that's also why using the code below and trying to move the pointer to <0,0,0> (lower left hand corner) of the luminosity prim wouldn't work: llSetLinkPrimitiveParams(gPointerNo,[PRIM_POS_LOCAL,<0,0,0>]). (gPointerNo is the link number of the pointer prim.) Where did the pointer move to when I used the above code? It moved to the center of the base (the parent prim). It was one of those aha moments. So, indeed, Rolig's suggestion of working from the perspective the parent is sage advice.

Thank you! I think that will help. I will try that approach. But, I'm still mystified why the following wouldn't set the pointer prim to the lower left hand corner of the luminosity prim? llSetLinkPrimitiveParams(gPointerNo,[PRIM_POS_LOCAL,<0,0,0>])

I'm still struggling with this . . . My color picker is several linked prims consisting of a base prim, color palette prim, luminosity slider prim, and the pointers. The parent is the base. The luminosity (child) prim is tall rectangle with the following dimensions: X=.01, y=.10, z=.58. I have a script in the luminosity prim. I know the link number of the pointer arrow. The color picker object is attached as a HUD. I've set up the script in the luminosity prim to execute the following upon touch: llSetLinkPrimitiveParams(gPointerNo,[PRIM_POS_LOCAL,<0,0,0>]). (gPointerNo is the link number of the pointer prim.) Shouldn't the pointer prim move to the lower left hand corner of the luminosity prim? It doesn't. In order to move the pointer prim to the lower left hand corner of the luminosity prim, I have to use the following (approximate) vector: <0,-.39,-.2>. I must be intrepreting something wrong because <0,0,0> is not lower left hand corner of the luminosity prim. Can you set me straight?

Thank you so much Rolig for replying. I tried your code, and I'm getting some weird movements of the pointer arrow. Here is what's happening . . . The first image show the starting location of the pointer arrow: When I click at the very top of the luminosity slider, the pointer arrow ends up as shown in the next image: Here's another example. If I click at the very bottom of the luminosity slider, the pointer arrow ends up as shown below: Any suggestions in what might going wrong? Thank you again for taking the time to reply.

Hello everyone. I’m working on script for a color picker and I need some help. Just briefly, I might mention that there’s been some good work done with color picking. However, after searching for the better part of a month, I’ve found that there’s not a complete solution available in public domain – particularly one that works in a HUD situation. I’m certainly not an expert in scripting – far from it - but if I manage to put something together that’s workable, I’ll post it and make it available to the Second Life community for anyone’s use in their own projects. I’m trying to create a color picker that looks and acts similar to Second Life’s. I want something that’s familiar and comfortable to SL users. Of course, it’s not possible duplicate all of the functions in SL’s version, but I would like something that’s a close match. Actually determining the color chosen by the user has pretty much been worked out by others: Aaron Edelweiss, Fox Stirling, Bjorn Nordlicht (and forgive me if I’ve left out someone). In the color picker that I’m developing, I have the color picking part working fine. My problem is with two reference pointers. Let me explain . . . After someone picks a color, I would like to have a “dot” remain on the color palette. (In Second Life color picker it’s a “plus” but I’m not sure I can duplicate that). I’d also like to have a pointer arrow remain on the luminosity slider after a luminosity setting is picked. When one is trying to get just the right color, it’s really helpful to have those two reference points – to know where your last color appears on the palette and to know your last location on luminosity slider. I have image of what it looks like - below. (To keep things simple, in the image I’m leaving out past saved colors and the “OK” and “Cancel” button) My problem is moving the “dot” and “arrow” to the user’s last touched locations. I have named each of the various prims making up the color picker, and I can tell which prim is being touched and I can move the “dot” and “pointer” by the use of llSetLinkPrimitiveParamsFast. I’ve been able to successfully move the dot and pointer to the last touched location when the color picker is a prim and I’m dealing with regional coordinates. But when it’s a HUD, and I’m dealing with local (or is it screen?) coordinates, I’m totally lost. I’ve tried Rolig Loon’s solution (found here: http://208.74.205.111/t5/LSL-Scripting/Moving-prim-A-to-position-touched-on-prim-B-in-a-linkset/td-p/2324443). Rolig did a very nice job of explaining the use of local coordinates in this manner. But I’m not having any luck with that solution – and I suspect it has to do with HUD’s. I wonder if anyone could suggest a way to move the dot and pointer to the last touched location on a HUD? Or is it even possible? Thanks in advance for your help!

One correction. For AO Settings, that should be "Approximate" not "Normalize."

I just wanted to thank Rahkis and Codewarrior. Following your instructions, I had much better luck with baking AO's. I upped the multires to 2 which helped. Interesting enough, the mesh floor made a big difference. (I hadn't been using one.) In particular, I found Rahkis' idea of using a sphere for the mesh floor to work quite well. I adapted his idea a bit, starting with a hemisphere with the opening facing up. I extruded the top of the hemisphere upward and scaled it out a bit, so it looked like the avatar was standing in an open cone with the top of the cone at the armpits. Here are my AO settings: 16 samples. "Raytrace." (I tried Normalize but it made things worse.) My Bake Settings: AO Bake and "Normalized" checked. (I tried the "Bake from Multires" setting along with various combinations but I could never get it to work properly. The bakes were always incomplete.) Frawmusl - thank you as well, but it appears that extra lighting will not help when it comes to doing an AO bake. I had experimented with lights earlier and didn't notice any changes. And then I found this in the Blender help documentation: "Ambient Occlusion Bake: Bakes ambient occlusion as specified in the World panels. Ignores all lights in the scene."