hectic1

Thank you both so very much for your precious help and your great ideas!! ♥♥♥ For the moment I'll leave the code relying on collision_start() and collision_end(). In my tests it isn't that bad, plus the 2 free swim HUDs I had the chance to look at their code, they both do the same thing. Thor's OAK does keep a list of the collided avatars, but also uses collision_start() and collison_end() so I am not sure what is really doing (looks like it defeats the purpose of keeping an avatars-list so you don't rely on those events). All in all, my main concern is for my prim-water to work with my wetsense clothing, and it seems to work niclely so far (i also included 2 buttons in the HUD so ppl can tackle manually cases of missing/misfiring events). If I start getting complains, I'll re-visit the subject (the truth is I'm really overwhelmed with fast approaching deadlines atm). Making the prim swimmable has a lower priority atm, and I think I'm satisfied with the way it works right know (plus I don't have a clue if my project will become popular or not.. if it starts getting I'll definitely revisit it for improvements) I do have one last question tho, if I may. My prim-water sends 3 different messages to 3 channels (mine, and the 2 swim huds) via 3 calls to RegionSayTo()... well 6 actually, 3 on collision_start() and 3 on collision_end(). Do I have to add a small llSleep(0.5) delay between each call?

Wooooo hoooo! Worked like a charm! Thank you so very much! ♥ I even made it working with my own prim-water, since the listening channel of the HUD and the commands it expects were revealed! Thx again! ♥

I just happened to get this bundle too, cause I wanted to check out the code of the script, hoping I could make a project I'm working on compatible with the Thor HUD. Turns out that the included Pool Water Script v0.7 does not compile. It uses Firestorm's pre-processor to #include a certain file, that is not present in the bundle. So that must be the reason it is not working. It isn't for me either (it doesn't even turn the prim to Phantom, as expected by the usage of llVolumeDetect() inside the code Actually I have no clue how others were able to make swimmable prim-water with Thor's script.... maybe it was an earlier version which was compiling, and which I can't find). That's such a pity, since it would be awesome to make my project compatible with that HUD. ANyway, I will try to contact Thor and I'll get back.

Oh dear God! Isn't LSL crippled or what? lol Seems like I have to go into much of otherwise un-needed math, if only events were properly functioning. Thank you very much for that info too Rolig. I'm not sure I want to go into all that trouble (i think I don't only need to check if llDetectedKey(0) pos.z is below the prim's top face, but if the collided avatar is within the prim-water range in general, right?). I'll probably just add a couple of buttons on the HUD, letting them "fix" manually cases of missing/misfired events lol

That was really fast! Thank you so much for that Rolig! ♥ So, since num_detected will be 0 like 99.99% of the times, I think I should keep the loop to tackle even the rare case of multi avatars entering/exiting the "water" at the exact same time. Unless the loop adds significant runtime overhead or other (please let me know). Regarding the "reacting to one and only one collision per avatar", I am not sure I understood. Don't collison_start() and collison_end() fire just once per avatar every time they get in and out of the prim?? I mean i do not use collision(), just collision_start() and collision_end()... the rest are handled by the script on the wearable of the avatar (it is just a boolean toggle btw, so i know if the owner of the wearable is in or out of the prim)

Hi everybody! Continuing the title of the post, my question is whether I should loop via the num_detected param of collision_start () and collision_end() event handlers for messaging llDetectedKey(i), or can I simply message once llDetectedKey(0). I couldn't find comprehensive info on the subject, that's why I'm posting here. I definitely want to message a scripted wearable on every colliding avatar, both on entry and on exit of the prim (which is supposed to be primwater btw). And I definitely want to do when multiple avatars are inside the prim-water at the same time. I tested with my normal avi and my alt (being in and out of the prim at the same time, and separately in and out) and both of the following snippets seem to work. So I can't really tell whether I should loop or not. I was under the impression that the collided avatars are queued, so I can simply message llDetectedKey(0) every time the event fires, but then I saw the code of a prim-water SwimHUD and they were looping. Which cases does the loop tackle? Snippets: ... collision_start(integer num_detected) { integer i = 0; for(; i < num_detected; i++) { llRegionSayTo( llDetectedKey(i), channel, msg ); } } OR ... collision_start(integer num_detected) { llRegionSayTo( llDetectedKey(0), channel, msg ); }

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

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.

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

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.

It worked too, and it's less memory intensive, TY!

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?

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.

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).

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?

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!

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.

Awww, ty Innula! Very useful info!

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!

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

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.

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).

Thank you so much for such a detailed answer! How can I measure the ARC of my avatar? It would help me evaluate better the demos of the mesh bodies I've collected so far, along with my current clothing, jewlery, etc. The Tonic feet are indeed compatible, I have tested them with Slink shoes and they fit perfectly (same thing with the eBODY). I haven't tested te ehands yet though. I was about to go with Maiterya (or Belleza) when those two bodies came to my attention. Its sooooo hard to ignore all their pros, especially the Tonic one for jus 2000L, but a little voice keeps telling me to go with a mainstream body lool.

So I am bit confuded about that ARC meter. Just saw at the Meshbodyaddicts blog a comment from Tonic's body creator claiming he has fixed the ARC for that body. Does this mean ARC is no longer a problem for this body? To be honest I fell in love with that body, and its HUD. I have even made half a dozen of custom shapes for its demo, while I was trying it with my current clothing. The docs even talk about a separate Outfit Saver that lets you save unlimited combos of Alpha cuts and layers directly into the inventory, and loading them at will, pretty similar to how normal Outfits work in SL... however the saver is not included in the demo. The only catch I can see (besides that ARC thing you guys are mentioning and its supposedly fixed now) is the lack of direct support from clothing designers, but other than that it seems that this body has everything one could ever ask for. And for what a price!. As I see it, with 3000L you can get a great mesh body along with a top notch skin of your own personal taste. But I kinda need confirmation from gilrs who have better knowledge and/or experience than me with female mesh bodies, before I go on and get it. My major gripe from the HUD is that I can't switch the available feet heights (I have to loat them from the inventory) but in general the whole thing looks too good to be true, there must be a catch ... lol. Thanks in advance!