xtc4u

Thanks I was thinking about that but thought that there may be a different way. The listener never gets called if RLV is not present so I set a var to FALSE and turn it to TRUE if the listener is called. I do shut down the listener after about ten seconds to help with lag.

I have a script that sends a rotation message to the avatar llOwnerSay("@setrot:" + (string) ang+"=1") ; Is there a way to only send it if RLV is enabled in the viewer? It's harmless if it isn't enabled but it does clutter the Chat window. Thanks

By full premissons you mean Transfer as well? I don't want to do that as I plan on selling it. So would I set the texture on the prim faces by the hard coded UUID's and then also set the texture on the particles as I change them? Would doing it this way prevent the "grey box lag" that happens when the particle effect first starts? How do sellers handle these hard coded UUID's. I mean if a given avatar that has the texture in it's inventory some how goes away or gets deleted then all of the sold items would break because the texture with the UUID got accidently deleted?

So I have a prim that has 4 textures on 4 sides of it. The textures were selected from my inventory and placed on 4 of the prims faces. In my script I get the texture via this code: list lTexture = llGetLinkPrimitiveParams( 1,[PRIM_TEXTURE, 4]); texture = llList2String(lTexture, 0);and then set the PSYS_SRC_TEXTURE to the texture and all works well. I seem to remember the reason for doing it this way was something I read about this helping prevent initial grey boxes from the emiter because the texture has already been loaded as part of the rez of the prim. Anyway it works fine except..... When I give this to someone else (Copy/Mod permissions) the textures don't show. They get the particles but the textures aren't there. What am I doing wrong?

Here is the correct link: http://wiki.secondlife.com/wiki/LSL_http_server/examples

How does one define consent? If someone chat's to you "follow me" or "come with me" or "walk with me" is that consent to follow them? I think it is. Why would I then have to inconvenience them requiring them to click a Yes button to give me permission to follow them. As for the mechanics of the HUD, it's a single small round button. If clicked it follows the nearest avatar. Click again it stops following. Click and hold for a second or more and a dialog list of avatars pops up and you can select a name of an avatar to follow. There is an options menu button added to the end of the avatar list that allows you to change the follow distance, quickness of follow, color and transparency of the botton, and distance range of the avatars to put on the list to select. 99% of the time I use it in the one click on and one click off mode. Someone tp's me to an interesting place and wants to show me around. They indicate they want me to follow them. I click on the button. They take off up some slope or down some spiral staircase and I can pay attention to the surroundings and not focus on keeping up with them. I never had anyone object, just this one person who didn't object but after a bit noticed how "good" I was following and asked if I was using a HUD. Then the conversation about TOS occured.

Yes I did set the parcel to the group. Interesting note that the person who could not rez was also set to be a co-owner of the group. The solution was to eject him from the group and then have him join again. I have no idea why that worked unless there was some artifact from other settings in the link of group/avatar that wasn't being cleared.

I wrote a simple follower HUD and use it to follow someone when they "say" follow me or come this way. Anyway I just had a 6 year in SL life guy mention to me that I should have asked before I "attached" a script to him. I explained that it wasn't anything that animated his avatar just something that animated mine. Then he mentioned that it was against the TOS to do it to someone without their permission. Now frankly I don't remeber if he said "let me show you something" or "follow me" or whatever but he indicated I should follow him, so in my book he did give me permission. But just to understand better I read through the TOS and I guess generally it could be classifed under "Griefing". But if someone says or implies to someone to follow them why would that be considered Griefing? I've used it many times with no one either noticing or saying anything, and it comes in handy when trying to follow someone in unfamilar areas. Any thoughts? --||-

I wrote a simple follower HUD and use it to follow someone when they "say" follow me or come this way. Anyway I just had a 6 year in SL life guy mention to me that I should have asked before I "attached" a script to him. I explained that it wasn't anything that animated his avatar just something that animated mine. Then he mentioned that it was against the TOS to do it to someone without their permission. Now frankly I don't remeber if he said "let me show you something" or "follow me" or whatever but he indicated I should follow him, so in my book he did give me permission. But just to understand better I read through the TOS and I guess generally it could be classifed under "Griefing". But if someone says or implies to someone to follow them why would that be considered Griefing? I've used it many times with no one either noticing or saying anything, and it comes in handy when trying to follow someone in unfamilar areas. Any thoughts? --||-

Not sure why but I had to remove the member from the group and invite him again. Then he could Rez. Note that he couldn't Build as I previously stated, I tried so many things I got confused on that point. Anyway all is working as advertized.

I'm having difficulty get things set to allow officer members of my group to rez in my Linden home. I have followed numerous directions, created a group set the the land options, etc. Not sure what I could be doing wrong. The members of the group can build, but they can't rez. Message is: Can't Rez object at {blah blah} because the owner of this land does not allow it......

I'm having difficulty get things set to allow officer members of my group to rez in my Linden home. I have followed numerous directions, created a group set the the land options, etc. Not sure what I could be doing wrong. The members of the group can build, but they can't rez. Message is: Can't Rez object at {blah blah} because the owner of this land does not allow it......

Thanks for the giving me the rational for your design. I can understand the advantage of having all user click events in one script as one of my larger HUD's has two scripts and both have those events. Sometimes tracking down what is going on can be a challenge. I thought I read somewhere about how many if else statements can chew up memory and with all the options I have going on the original single script ran out of memory well before I was done. At this point I don't have anymore questions, thanks again for the explanation. Cheers

I have taken a look at your HUD and have a few questions. I'm not an experienced SL scripter so these may be dumb questions, as I'm still learning the mechanics of the SL remote servers. I will say I have been coding software for quite some time however, but pretty much exclusivly local Winform style exe's. Is there an advantage to breaking things up into so many scripts from a performance standpoint, or is there some other reason? I have build a few HUD's and pretty much jammed all I could into one (or two scripts if memory became an issue), assuming that giving the SL server one or two scripts was better than 7. I thought I read somewhere that less scripts were "better". It seems to me that a lot of the scripts that you have in your design are very specific and basically tell the Core script what to do. What is the advantage of this design? Is it just to break-out the various functionality and make it modular so you only use what you want? I realize that the concept is that this HUD will grow in functionalitly and thus eventually require more than a single monolitic script (do to memory again), so maybe my questions are premature. Anyway please enlighten me as to why you have the design the way it is. Thanks

Well then I would try to start with simpler things and work your way up. Maybe someone else will have the time to rewrite your entire script. If not then break it down into smaller pieces, like one prim and a few fixed colors. Then slowly add more prims and more colors.

I would try two things. First as a test increase the timer event time from .5 to 5 just to slow things down a bit. It may be calling the function to fast. Second I would use something like below to be more efficient and increase the speed of the color change. This was pulled direct from the Wiki : llSetLinkPrimitiveParamsFast default{ touch_start(integer num_detected) { // color the root prim red and the first linked-prim green llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_COLOR, ALL_SIDES, <1.0, 0.0, 0.0>, (float)TRUE, PRIM_LINK_TARGET, 2, PRIM_COLOR, ALL_SIDES, <0.0, 1.0, 0.0>, (float)TRUE]); // instead of: // llSetLinkPrimitiveParamsFast(LINK_ROOT, // [PRIM_COLOR, ALL_SIDES, <1.0, 0.0, 0.0>, (float)TRUE]); // llSetLinkPrimitiveParamsFast(2, // [PRIM_COLOR, ALL_SIDES, <0.0, 1.0, 0.0>, (float)TRUE]); }}

That solved it. I will modify to code above to reflect that change.

Thanks, no doubt, I'm sure that is what happened. Thanks for the tip.

I updated the code to work by using the child linked prim to store the position and size. Thanks Parrish! ====== I am trying to use the Description field to store info about a HUD, position and size. I have used this technique in the past for many Prims but the first time in a HUD (it does have a child prim btw). Anyway the code below seems to change the description fine if I leave the HUD on screen. But as soon as I detach it , the description changes to (no description). If I rez it to the ground, click it, take it, and re rez it to the ground the description remains. So not as a HUD it works as expected, but if it is used as a HUD it loses the description that was changed via the script. I know I have discovered many things about a HUD that are different, is this one of them? vector hudPosition; vector hudSize; HudPosSize2Desc() { list lInfo = llGetPrimitiveParams([PRIM_POS_LOCAL,PRIM_SIZE]); string pos_size = (string)llList2Vector(lInfo,0) + ";" + (string)llList2Vector(lInfo,1); llSetLinkPrimitiveParamsFast(2,[PRIM_DESC,pos_size]); llOwnerSay("HudPosSize2Desc() called " + (string)pos_size); } HudPosSizeFromDesc() { string info = llList2String(llGetLinkPrimitiveParams(2,[PRIM_DESC]),0); list linfo = llParseString2List(info,[";"],[]); hudPosition = (vector)llList2String( linfo,0); hudSize = (vector)llList2String( linfo,1); llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POSITION,hudPosition,PRIM_SIZE,hudSize]); } default { state_entry() { HudPosSizeFromDesc(); llOwnerSay("Position: " + (string)hudPosition); llOwnerSay("Size: " + (string)hudSize); } on_rez(integer start_param) { llResetScript(); } touch_end(integer s) { HudPosSize2Desc(); } }

I have two scripts running in HUD. All of a sudden one of them just stopped working. I tore my hair out for over an hour because I had made quite a few changes to it and couldn't figure out what was happening. Long story short I copied both scripts to inventory, deleted them in the hud, copied both back to the hud, and voila all was fine. I now surmise that it had something to do with the UUID of the one script that the SL servers didn't like or lost track of. Any figured I would mention it if others encounter a similar problem.

Figured out my problem. In order to center the child prim within the root prim the position is <0,0,0> not the local position of the root. After all the position of the child prim is relative to the root prim. Don't know what took me so long to figure that simple fact out, but I guess it's all part of the learning process.

I'm trying to adapt the code to move the child to a specific spot on the root. In my case the root prim is divided 4x4, 16 positions. When you click on a position the child prim should align with that position. What is stumping me is the root prim location I am gettng back from the call to llGetLinkPrimitiveParams. It sort of appears to be the center of the HUD position, not the center of the root prim position that is attached to the HUD (in my case top left). Here is some code that positions the child (which is the size of one of those 16 squares). It moves to a position below the root, outside of it's bounds. Why isn't it positioning itself to the left and right of the center of the root. Actually interestingly it seems to be moving on the z axis, but again below the root. list lpriminfo = llGetLinkPrimitiveParams(LINK_THIS,[PRIM_SIZE,PRIM_POS_LOCAL]); vector size = llList2Vector(lpriminfo,0); vector pos = llList2Vector(lpriminfo,1); float xofrootsize = (size.y / 4); vector offset= <0.0, xofrootsize, 0.0>; // nb I'm moving on the Y axis because I think it's at ZERO_ROTATION integer n = llDetectedLinkNumber(0); llSetLinkPrimitiveParamsFast(2,[PRIM_COLOR,ALL_SIDES,<0.0,1.0,0.0>,.5]); if(1 == n) {//if it was the root prim that was touched toggle=!toggle; //vector pos = llList2Vector(llGetLinkPrimitiveParams(2,[PRIM_POS_LOCAL]),0); if(toggle) { llSetLinkPrimitiveParamsFast(2,[PRIM_POS_LOCAL,pos-offset]); } else { llSetLinkPrimitiveParamsFast(2,[PRIM_POS_LOCAL,pos+offset]); } } else if (2 == n) { llOwnerSay("you touched link number "+(string) n); //etc }

You know I tried what you suggest, and it did work yesterday, but I thought I could make it more generic. Guess not. Check out the code below if I leave out the hard coded rotation setting of rtemp <0.412602, -0.884828, 0.196148, 0.091464> it doesn't work as expected. I just had to try doing it in pieces (x,y,z) just to see if that would make a difference. Apparently it doesn't. Maybe if I actually set the rotation after each step it would work but that would be too much overhead for my situation. ResetRot2(){ rotation rtemp; rtemp = <0,0,0,1> * llEuler2Rot(<180, 0, 0> * DEG_TO_RAD); llSleep(.25); rtemp *= llEuler2Rot(<0,25,0> * DEG_TO_RAD); llSleep(.25); rtemp *= llEuler2Rot(<0,0,40> * DEG_TO_RAD); rtemp = <0.412602, -0.884828, 0.196148, 0.091464>; // captured after adjusting to <180,25,40> llSetLinkPrimitiveParamsFast(2, [PRIM_ROT_LOCAL, rtemp]); }

I'm trying to write a reset function to reset a rotation of a child prim (2). I thought I had it working but apparently not. Can someone tell me why if a child prim rotation says (180, 25, 40) degrees when looking at it in "Edit Linked" editing, that the following code moves it to: (205, 0, 310) degrees. (180, 25, 40) is the reset position I want. But no matter how it is rotated on reset it goes to (205, 0, 310). Shouldn't it just remain where it is, rotation wise? llSetLinkPrimitiveParamsFast(2, [PRIM_ROT_LOCAL, <0,0,0,1> * llEuler2Rot(< 180, 25, 40>*DEG_TO_RAD)]);

Inspiring and Wow! Now back to coding....