Jump to content

Helium Loon

Resident
  • Posts

    309
  • Joined

  • Last visited

Posts posted by Helium Loon

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

     

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

     

    • Like 1
  8. 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.

     

     

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

     

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

     

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

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

     

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

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

     

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

     

     

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

     

     

    • Like 1
  17. 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.

     

    • Like 1

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

     

    • Like 1
  19. 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.)

     

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

     

×
×
  • Create New...