Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About hectic1

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Just wanted to add that rotation worked just fine too, ty Rolig For the moment I'll settle with Innula's initial suggestion of just moving the root which is simple, effective and requires the least changes in the already written code. Plus when minimized, the HUD really gets out of the way (I move it to the bottom of the screen, by only changing the z-coord... I keep the y-coord the same as the restored HUD, so if I have moved the HUD, the minimization only affects the vertical pos). Thank you all
  2. Ty for the answer Rolig, and for the link! Ofc I'm trying things out.. that's all i do actually. But sometimes when there's so much stuff going on and/or you are tired or frustrated due to things not working as u expect, then a little help sparing you the trouble of hunting wiki links one after the other, or trying to digest notes, examples and snippets that don't make much sense to you at that given moment, is like a god-sent bless. Especially when you are trying to learn a new language, the docs of which are not exactly organized perfectly or very easy to discover... and all that assuming that you know what you are looking for, which is not always the case. Actually, i had already tried to rotate the HUD before deciding to drop that approach and use move instead. The reason was that the Luminosity slider of the embed Chimera's Color Picker was reversed when i was rotating the HUD back on screen.... and that was the only child prim doing that back then (it was even before I open the Chimera Color Picker thread). I do recall i was struggling and experimenting with all those diff kinds of coordinates, plus the diff behavior depending on the nature of the prim (root, or child, attached or not, etc). Obviously I was doing something wrong, but the botom line is that i got so confused and frustrated that i decided to drop that approach altogether and try something else (that is, moving instead of rotating). So now that rotation came up again as a pretty good option (as the Catwa's HUD example demonstrates, at least to my eyes), I thought I should ask the forum about it, hoping for pointers that would spare me the struggle i faced when i 1st tried. I can't really test it right now, but I certainly will and get back.
  3. I took a closer look at the Catwa HUD, what they do is quite similar to what Innula suggested (that is moving the root of the HUD off screen) but they use rotation instead. There is quite a gap between the root prim (the min/restore button) and the rest of the HUD. When minimized, the root prim is shown inside the visible part of the screen and the rest of the HUD is located above the visble top (edit the HUD and use the mouse-wheel to see it) but it is rotated. When you click on the root prim, the whole thing gets rotated again (apparently with a reversed angle) so now the root prim goes over the visible top of the screen (they make it invisible too), and the rest of the HUD shows up in the visible part of the screen. Apparently, the diff between this and moving the HUD, is that with rotating it, both the root and the rest of the HUD appear at the same location when they are shown. This made me take a look at the llSetRot() wiki, expecting it to work like llSetPos(), meaning that by rotating the root prim, then all children will be rotated accordingly keeping their relative positions. Unfortunately, I got really confused by the wiki. There is a note stating: "If the prim is attached, then this function offsets the rotation by the avatar's rotation.". Then there is an example for rotating the root prim, but it's noted that "it won't work on child prims if the root is rotated.", and then there are these 4 snippets: //-- These correctly set a global rotation for the root prim in all scenarios llSetLocalRot( rot ) llSetPrimitiveParams( [PRIM_ROT_LOCAL, rot] ) //-- These correctly set a global rotation for a child prim in all scenarios llSetLocalRot( rot / llGetRootRotation() ) llSetPrimitiveParams( [PRIM_ROT_LOCAL, rot / llGetRootRotation() ] ) It must be my inexperience, but i don't really get what is going on. But if i got it right, we can't just llSetRot() the root prim, like we did with llSetPos(), is that true? On a side note, when moving everything but the root prim, like I tried to do it initially (and Innula brought up the great PRIM_LINK_TARGET implementation) its easier to make it never expose its hidden part (the one that is off screen), even if the user manually moves it say to the opposite corner of the screen, cause according to the PRIM_POS_LOCAL documentation, when applied on a HUD, the value 1.0 in the pos vector translates to the corresponding dimension of the visible screen. Also it doesn't really matter where the HUD is initially attached on the screen. However, its is considerably slower compared to moving the root (and judging from Catwa's HUDs, compared to rotating too), especially for HUDS having like 300 buttons on them (like Catwa's HUDs). Any pointers on rotating FAST the root prim and have its children follow, will be more than welcome
  4. I don't think so, because the Catwa heads HUDs which i used as an example above, are visible when editing them and then shrinking the screen viewing part via the mouse-wheel.
  5. It worked too, and it's less memory intensive, TY!
  6. Wow, that was plain awesome! Tried it and it worked pretty good (so that's what PRIM_LINK_TARGET does :))) Ty so much! I still can see it moving off and on screen, but this time is really fast, since llSLPP is only called once! I will also try the other suggestion, moving the root, but I'm not sure i totally got it. When we move the root prim, its children are automatically moved along, keeping their relative positions?
  7. Hello, i'm learning LSL by trying to make a custom texture+color+sheer+materials HUD. I'm doing a decent job so far I think, and the forum has already helped me with Chimera's Color PIcker, the code of which I have modified and embed into this custom HUD. My current question is about minimizing/restoring the HUD and all its children. I have already implemented that, but the effect is not rapid as in other HUDs i have seen and/or used. In my HUD the min/restore button is the root prim, and the way i move it off and on screen is via this function I have coded: integer g_is_hud_minimized = 0; <snip> /* ---------------------------------------------- * Move all children of a prim (specified by link) by the given offset. */ MoveLinkChildrenByOffset(integer link, vector offset) { list params_lst = []; vector local_pos; integer i = llGetNumberOfPrims(); while (i > link ) { params_lst = llGetLinkPrimitiveParams(i, [PRIM_POS_LOCAL] ); local_pos = llList2Vector(params_lst, 0); llSetLinkPrimitiveParamsFast(i, [PRIM_POS_LOCAL, local_pos + offset] ); --i; } } <snip> if (g_is_root_min_restore && touched_link == LINK_ROOT) { if ( g_is_hud_minimized ) { // show the HUD MoveLinkChildrenByOffset(LINK_ROOT, -1*POS_OFFSET); } else { // hide the HUD MoveLinkChildrenByOffset(LINK_ROOT, POS_OFFSET); } g_is_hud_minimized = !g_is_hud_minimized; } So the idea is that that everything but the root prim is moved by the given offset when the root is touched. This works, but I can literally see the children of the HUD moving off and on screen one by one, especially when the HUD contains lots of children (around 60 atm). I did try hidding them via alpha = 0.0 prior to moving the HUD off screen, and then show them back via alpha 1.0 when moving the HUD on screen, and it did get a little better, but nowhere near the rapid effect i see with other HUDs (plus, i don't really want to apply alpha =1.0 to all children when showing the HUD, cause some of them may initially be semi-transparent... and using a loop like the one above for their initial alpha, would slow things even more ). I understand the problem is due to the loop that visits all children and process them one by one, but I wonder how others do it and they have their HUDs moving off and on the screen in a blink of the eye. And i'm talking about those ppl who don't just rotate the HUD, but actually move it off screen (like Catwa heads HUDs for example). I can tell they move it off screen, cause i see them when I edit their HUDs and then use the mouse-wheel to shrink the visible part of the screen. Any help is greatly appreciated.
  8. 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).
  9. 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?
  10. 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!
  11. 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.
  12. 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!
  13. 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
  14. 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.
  • Create New...