Jump to content

Helium Loon

Resident
  • Content Count

    309
  • Joined

  • Last visited

Community Reputation

24 Excellent

About Helium Loon

  • Rank
    Advanced Member
  1. If you aren't using experiences, you'll have to use RLV with Relays to do transformations. And if you don't want it asking about each element, you'll want to give a folder to the #RLV of the transformee, and then do a force-attach or force-wear for each attachment/clothing part or the whole folder (or have one attachment that then rezzez the others so regular llAttachToAvatar() will work.) Unfortunately, the TF players voices were shouted down about having the RLV command "acceptpermissions" work for temp-attach requests....not even a Debug Setting to permit it being auto-accepted. Same with AutoAccepting inventory gives to #RLV......so TF players have gotten used to having to click a lot of accept dialogs.....
  2. RLV provides something of this functionality. The various 'Renamer" scripts/objects allow whatever the user types into local to be captured by the script (and stopped from going out into local) and the script/object then changes its name to what the desired 'apparent' name, then does a say to local. Then it changes it's name back to normal. It does this everytime the wearer says something. So with RLV enabled clients, yes. However, the viewers will clearly show that the chat is coming from an object, not the person themselves (they use different coloration in the display.)
  3. While this isn't currently possible, it can always be suggested to the RLV/RLVa projects. RLV is maintained by Marine Kelley (Restrained Love Viewer), while RLVa is maintained by Kitty Barnett (Catznip Viewer). They would have to add in the code to disable voice when restricted appropriately, possibly even adding in new commands to provide this capability in viewers that include their RLV/RLVa patches.
  4. This is the perfect example of where doing something multiple times in code might be better handled as a function, rather than inline code. To wit: list GetPrimsByName(string name){ integer i; list result; while (i <= llGetNumberOfPrims()) { string prim = llGetLinkName(i); if (~llSubStringIndex(prim,name)) { result += [i]; } i++; } return result;}DoSomethingToPrimList(list prims){ integer i; while (i <= llGetListLength(prims)) { // Do something here to the the prim where the prim number is element i of the list prims // Example: llSetLinkColor(llList2Integer(prims,i), <1.0,1.0,1.0>, ALL_SIDES); // where this---------------^^^^^^^^^^^^^^^^^^^^^^^ is the value of the i-th element of the prim list. // you could also have another parameter passed in with something to change to.... i++; } } This creates 2 functions we can use anywhere in the code. One to get a list of prims by name-fragment (it tests to see if the string passed in is present anywhere in the prims name.) And one that does something to all prims in a list, and has an example of setting the color to white. To use these, just put them outside of any states (i.e., they are global functions) and then call them within other code, like: integer isRed;list red_prims;default{ state_entry() { isRed=FALSE; red_prims = GetPrimsByName("RedFace"); // this assumes these prims are named like "RedFace1", "RedFace2", "BackRedFace", etc. } touch_start(integer numDetected) { isRed = !isRed; if(isRed) DoSomethingToPrimList(red_prims); }} Now, obviously, if you are only doing this a couple of times in the code, or you only load the list once, it makes more sense to just inline the code instead of using a function. But for things you may do many times in many places, functions can save a lot of code space. They also make it much easier to debug the code, since things are broken down into sections. And once you know the code works right, the function calls can be replaced with inline versions of the function and the function removed.....if it's only used in a few places.
  5. Always best to be very accurate with communication....especially where hypnosis is concerned. And while I'm a skilled hypnotist, I'm highly analytical which makes me a very poor subject for most hypnotists (there are specific techniques for dealing with highly analytical subjects, but usually only a professional hypnotists or hypnotherapists study them.) And I've met many subjects who wanted to learn to trance others, but found themselves unsuitable for being on the other side of the pocketwatch (they tended to drop themselves before their subject went under, or didn't have the right temperment to be 'in charge', etc.)
  6. Might want to include whether you are looking for subjects, hypnotists, or someone who does both?
  7. In state SecondDialog, inside the listen() event handler, you are using llDetectedName() which does not have valid info inside a listen() event (only used in sensor, touch, collision events). Just use the m parameter passed into the listen() event. It will be the text of the button that was selected in the dialog. However, since they are limited to 22 (?) characters, you will likely have issues anyway.
  8. This really comes down to intent as to whether or not it is ethical. Are you intending to make your own products to directly compete with the original authors, effectively using your knowledge of the channel numbers to supplant the original authors products? Or are you intending to use the channels for other purposes (i.e., not using them to control the original authors sold products in a similar fashion?) Note, there are some grey areas in here. Making a 'better' controller for his products, reverse-engineering his stuff to develop similar products, etc. At that point, it becomes a judgement call as to just HOW similar the products are, and whether or not they could be easily mistaken for one another.
  9. llPlaySound() can only have one sound playing from a prim at one time. Each of those will cause the prior call to stop playing. llSleep() stops the script from responding to any touches (it basically pauses the script completely.) I'm assuming your sleep calls are pausing for the duration of the sound file, so this might not be a problem. llTriggerSound() will allow you to play more than one at the same time, but they do not follow the prim around, the sound plays from the location at which it was started. It looks like you are trying to play these in sequence? If so, and you want it to respond during the playing, you'll need a timer even to 'switch out' sounds. The sleeps in the first touch event keep it from responding to touches to turn it off except in the very brief interval when it starts the next sound. In a psuedo-code style, this would look like: Get list of sounds to play and their durations into lists (sounds and durations), set 'playing' to false, and your sound number 'index' to 0. Set timer to very small value. On Touch, toggle a flag variable 'playing' and if it is false, turn Timer off. In Timer, Play sound 'index', and change timer duration to duration 'index', and increment 'index', and check if index is past the end of the list, if so, set it back to 0.
  10. Okay. In order: Scan for Active Relays: llSensor() to get the avatars in range, save in a list. llSay() on RLVRS channel a #Version request to everyone in that list (to their relays, technically) llSetTimerEvent() to create a timeout for those who don't have relays. Listen() handler listening to the RLVRS channel (or specified channel) for responses. Record relay answers until timer expires. Display list of targets as a llDialog() to the one who instigated the scan. Force-Sit: Rez poseball in calculated location (since more than one could be active?), save key of new object rezzed. Send Relay command to target to force sit on Poseball. Poseball should have a script inside that when link changes occur, executes a prevent stand relay command, requests animation permissions, and in the permissions event, animates the avatar on the sit-target. Poseball script should also have a llListen() listener set up to allow the main object to send it a command to 'release' a target (stop animation, allow standing, delay, and llUnSit().)
  11. You might want to provide a little more detail on exactly what you are hoping to accomplish, sequence-wise. RLV Relay scripting work is very sequence oriented. I'm guessing you want the main object to scan for active relays in a given radius, provide a dialog of targets, and attempt to RLV force-sit the target on the poseball. If you are attempting to prevent them standing up afterward, the poseball(s) will still need a script to prevent that, but that's pretty simple. It'll need a message system of some sort to be told to release the captive, or a timer system of some sort as well. For any force-sit, you'll need the keys of the poseball(s), as that has to be passed in as part of the RLV Relay command. Can you clarify exactly what you want to happen here? Also, are the poseballs rezzed, or linked prims?
  12. Woot! I agree, it's about time they got this in. Been waiting for months. Now if we could just get them to add texture animation channels to the materials texture channels.....Animated normal maps and specular maps would be very cool and useful.....
  13. I'll have to disagree about mesh not being suited for 'skin-tight' clothing. Especially latex/metallic things, since a mesh can use the materials system and animated textures and scripts, whereas the standard clothing layers cannot. Agreed, mesh doesn't perfectly auto-size to a given shape (though fitted is helping with that, it still is a lot of work, and is rarely perfect) so for those you often just wear the alpha that hides 90%-100% of your body and accept the shape the mesh maker used for the outfit. So, there are still some limitations. So it really depends on how 'attached' you are to your shape. Mesh, rigged mesh, fitted mesh, prim/flexi attachments, system clothing. The good designers use some or all of these, as appropriate for each part, to create great outfits.
  14. The big issue is in your Make_Test_list() function. You are adding ONE string that is a concatenation of all three elements. Try this instead for it: Make_Test_list(){ Themes = []; string Menu_Button_Name = "Fantasy Tiger"; string Back_Drop_UUID ="8f304cf2-7120-24e2-d1f1-db6b31bd6f6"; string Floor_Drop_UUID = "false"; Themes = [Menu_Button_Name,Back_Drop_UUID,Floor_Drop_UUID];} Then it will match up with the format it is expecting.
  15. Well, I'm handy enough with C++ to look into the client side of this......the server side is all LL, though. The server side of this code should be pretty simple, though. It just sends the message to the client to display the dialog. When the client actually clicks on the dialog and hits 'OK', it sends the vector to the server which then forwards it to the appropriate channel. Since there is already a picker inside the client, displaying it on a script dialog shouldn't be THAT hard. And as I said, the server side is pretty simple. And while I know a lot of people are waiting on llGetPony(AMAZING_COLORS|RAINBOW), I think that would involve a lot more. I've tried to push a pony through Cat5 cables, and it wasn't pretty....... :matte-motes-sick:
×
×
  • Create New...