[I need help scripting .... ( attach to avatar )]

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

 

 

[Change SL name via LSL scripting?]

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

 

[SLPPF selectively by child prim name?]

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.

 

[Whats the problem with the script?]

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.

 

[Channel Fair Use]

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.

 

[On/off sound script]

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.

 

 

[RLV capture in MLPV menu]

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

 

[RLV capture in MLPV menu]

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?

 

[Scripted support for materials in testing on Aditi]

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

 

[Mesh vs prim and normal clothes]

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.

[can someone help me with this script?]

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.

 

[Color Picker HUD - Moving a Reference Arrow to Last Touched Location]

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:

[Color Picker HUD - Moving a Reference Arrow to Last Touched Location]

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.

 

[Color Picker HUD - Moving a Reference Arrow to Last Touched Location]

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.

 

[Getting a script to respond to a word within a phrase ...]

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.

 

 

[RLV Relay communications.]

1)  Standard Relays listen on a specific channel.  So any communication to them has to be able to 'speak' on that channel.  llRegionSay() and llRegionSayTo() are the longest reaching mechanisms for doing that.  Sending them over email or http isn't standard (but some relays may provide extensions.)

 

2)  I'm not clear on your question.  If they exit via a teleporteer, the teleporter needs to tell the controlling object to clear restrictions and then get a response back before the teleport is performed.

 

3)  It's better to use @clear to remove all restrictions.  And a relay will never ask permission to remove restrictions, as once it has permission to control the viewer, it has control until all of it's restrictions have been cleared (at which point any relay command from the object are gone, and a new command will re-request permissions again.

 

 

[Party Time: Grand Re-Opening of the JIRA's]

It's great to have it back, though it'd be better if it didn't get hidden again after triage.  Additional comments with updated incidents with further info could help narrow down the issue, or reveal other potential causes.

 

Here's hoping it just gets better and better.  Good job, Ebbe!

 

[Choosing A Channel]

The biggest issue with using Listen()'s is that they consume a good bit of server resources, script-wise().  This can be limited with using proper filtering on the listen parameters, but they still consume a good bit of resources.

 

The channel is a 32-bit signed integer.  This gives about 2 billion positive (chat accessible) and 2 billion negative (script only) channels.

 

Use of a channel is pretty much a matter of taste.  Realize that the more 'common' a channel you use, the more likely something else may be using the same channel in the same area.  Which means more work for the server sending messages to scripts that don't really need to 'hear' the cross-talk.

 

The particular 'common' channels you list are easily typed and remembered.  A LOT of scripts use them.  I find 3 digit (non-repeating) numbers work very well and minimize the chance of crosstalk.  456, 789, 234....these are all easily used, and rarely will you experience any crosstalk.

 

Make sure you put good filters on your llListen() call.  If only you are ever supposed to use it, make sure you set the user filter to llGetOwner().  If it only gets one command, set the text filter to that command.  That will minimize the impact on the server from the Listen.

 

[I need opinions, and hopefully suggestions for this mesh please!]

---

Coby Foden wrote:

I have always thought this arms modelling in T-pose being very strange too. Wouldn't A-pose be more natural? Where does this T-pose modelling originate from I wonder?

Jonathan Williamson, in his female figure modelling series, used A-pose. The reason being that he saw A-pose more natural pose than T-pose to model a human figure. (T-pose raises the shoulders up in a position where we very seldom see them.)

---

The primary reason for the T-Pose is that it aligns the major extremities along the XYZ axes.  This makes for simpler storage and calculations of deformations and rotations from the base (axis-aligned) orientation.  This was from back when such calculations could take hours or days to do.  It's kind of hung around since then.  And since most animation is done using skinned vertex shaders these days, it makes a simpler shader program if you know that the bones will be basically aligned with a specific axis....

 

[Where do these 鋰㰀暜藐 come from?]

---

Orca Flotta wrote:

Those characters are not Asian-like, they are in fact very Asian, Korean to be more exact. Sorry, can't help you with the technical stuff.

---

Actually, those are not Korean.  Those are Chinese or Japanese Kanji.  Korean characters look more like this:  푸 미아오 리

 

[Which 3D program works best for mesh clothing specifically?]

While what several of the others have said is true, I'll add a caveat....

 

Different modelling software approach the task of modelling differently.  So you may find it 'easier' to model in one particular program than the others.

 

I personally find modelling easiest in Lightwave3D.  That's just me.  The flow of it just seems more natural to me.  But I know others find 3DSMax or Maya or Blender 'easier'.  They can all do the same stuff.....it's just how they approach the individual tasks differently.

 

I suggest trying out demos, or old versions, etc., and see which one you can follow the processes easier on.  Of course, you may find that the one you find easiest is the most expensive....or that none of them seem to be 'easier' for you.  There are hundreds of modelling programs out there...... (ZBrush, modo, Wings3D, SketchUp, to name a few)....try a few.  As long as they can export/import the most common formats (obj, dae) you can always bring them into another program to do another part of the flow (e.g., I model in Lightwave, but I weight and rig in Blender.)

 

[Why Collision Volumes might be the better choice]

Thanks, Gaia, for giving a fair assessment.

 

As much as I liked the deformer, the existence of collision volumes already being implemented within the viewer pipeline is a major bonus to it.  It also means that adding NEW collision bones is a relatively simple matter (assuming the code is even remotely well-designed) for LL to do.  This means extending the customizability of the fitted mesh system becomes simpler for them, even if it makes things a bit more complex for those of us trying to twist mesh capabilities into pretzels to get our meshes to do juuuussst what we want them to.

 

Now if we can just get them to expose the morph targets and such, we'll be in business!

 

[Checkerboard distortion.. about phong reflection]

Just to clarify for Madeliefste, 'Phong Shading' refers to a specific algorithm for determining the size and tightness of the specular highlight when shading a polygonal model in 3D rendering.  It was a major improvement from 'Gourad Shading', which used face normals to calculate the specular reflection (and resulted in banding.)

 

The Phong shading model uses vertex normals, and interpolates across the faces between the normals.  This produces a much more accurate highlight (compared to Gourad shading, though less accurate and flexible than Blinn or several later models).  It was a little more computationally expensive than Gourad, but easily optimized.  It was noted for making everything look a bit 'plastic', the hallmark of early CG work.

 

[any one know off hand will bouncey boobs and butt work on rigged av's?]

I like exposed boobies as much as the next y-chromosome bearing human.  And I agree.

 

Expose the morph parameters for rigged mesh uploads.  Let us make mesh avatars that can do what the existing avatar can provide.  Yes, it makes more work for us to do all the morph targets and vertex groups in our rigged meshes......and we'll have to modify all the tools to give us ways to prepare the data for uploads.....and probably a lot more.  But the option has to be there first.

 

And with that, we'd have the functionality for facial expressions, hand poses, and rigged mesh clothing could also follow avatar shapes (since AFAIK, the shape elements that don't adjust bone position are morph targets.)

 

A lot more work for the mesh modellers, but what a return on investment!

 

(Of course, this means we need a way to include, or a separate mechanism to upload the morph data, and it will increase the download weight of a mesh considerably.  A fully rigged avatar this way could easily be 5-10 times the simple rigged mesh download size.  There are a LOT of morphs in there.  Of course, you could always not include morphs you don't want to support or that aren't required by that particular element....pants don't need to implement breast morph targets......so except for full avatars, the file sizes and data sizes won't increase more than 2-3 times....)

 

[Checkerboard distortion.. about phong reflection]

I've seen this on a few other transparent objects with advanced lighting model active.  It seems like the shaders being used in the client don't like smooth shading anything seen THROUGH a transparent surface.  

 

It's the newest variation of the alpha-blending bug rearing its ugly head!