Helium Loon

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

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

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.

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.

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.

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.

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

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?

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

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.

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.

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:

You know, this is such a commonly used dialog in many things, you'd think LL would just go ahead and make a script function llColorPickerDialog(key avatar, string message, list options, integer channel) that would pop up an actual script dialog with a color/luminance/etc. picker on it, returning a color vector on the channel, just like a regular dialog would.

Rolig's script snippet is not precise for your particular prims. You'll need to adjust some of the constants in there, You'll notice that your vertical position is almost correct, but the horizontal is offset about half the width of the prim. You need to put in some adjustment factors to move the final coordinates to fit your particular prims and layout. You may also need to make some adjustments to the input coordinates, depending on just how you are doing your picker. If you are using a single prim, the input coordinates have to be filtered to determine WHICH part you are clicking on. If you are using individual prims for each section, each one will have it's own scaling factors and offsets.

There are a few ways to speed up things.... All the greetings have different starts. Do your comparisons on a substring (in this case, the first 2 characters differ in every greeting in the list) so the comparisons execute faster. Not a lot in this particular case, but for more extensive lists it can add up quickly. Open listens on the public channel are potentially lag monsters. Do like Rolig says, and only open it when someone gets close by (use a sensor or a collision volume or collision object) then close it after a timeout. There are potential cases where it will then not work correctly (the avi enters, but doesn't say anything before the timeout.) A repeat sensor with a long time between refreshes (the same as the timeout of the timer, or a little less) that keeps the listen from being removed if someone is still in range. Or just put a keypad and require entering a code. Or have a listen on a non-public channel that the users you want to be able to enter are given and only listen on that (and maybe an object they can use that will echo what they type onto that channel when active.) Lots of potential workarounds to avoid lag and poor responsiveness.