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. Great! Million thanks once again! ♥
  2. I think you mean the Waterworks prim-water script, also creator of the following HUD (among other things): https://marketplace.secondlife.com/p/The-Swimmer-206-from-Waterworks-Swim-in-prim-OR-sim-water/908729 In the description it says a lite version of that script is included with the HUD. I had searched for it (PrimSwim) before I post in the forum, couldn't find it. Probably it is not free, and as far as i know, not even available separately. Even if it was, I would need to check the code for its listening channel and its expected messages when ppl go in and out of their prim. Or I could contact Waterworks, asking for that info. However, I had a look at the 1st review of the above mentioned HUD, dated in October 2018 saying that the hUD gives a ""Attachments cannot use llVolumeDetect" (hinting that they try to use llDetectVolume() inside the HUD script, which couldn't work anyway according to the Wiki). That, combined with the 2nd review which is a good one but dated back in 2017, made me think that probably that HUD and the PrimSwim script coming with it is probably either outdated or abandoned (and using llDetectVolume() too for detecting). That's when I started looking for other alternatives, hopefully most recent ones. Plus I much prefer the HUDs to be free, since I'll be giving my prim-water free too. I have already made my prim-water compatible with 2 free Swim HUDs (namely, AT-Swimmer and Thor's OAK HUD) and I'm totally happy with it. As i said, my main concern is that my prim-water works with my very own line of WetSense clothing (not released yet) and it seems to work fine so far. The free swim ability will be an extra bonus for pool owners (creators) who will be willing to use my prim-water. PS. About my last question? Does anyone know? Should i insert a short delay between consecutive calls to llRegionSayto() or I'm fine w/o any delay between each call?
  3. 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?
  4. 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! ♥
  5. 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.
  6. 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
  7. 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)
  8. 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 ); }
  9. 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
  10. 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.
  11. 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
  12. 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.
  13. It worked too, and it's less memory intensive, TY!
  14. 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?
  15. 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.
  • Create New...