Dora Gustafson

It will work better saving and using the sound you find: default{ touch_start(integer total_number) { string sound = llGetInventoryName(INVENTORY_SOUND,(integer)llFrand(llGetInventoryNumber(INVENTORY_SOUND))); llPlaySound( sound, 1); }} :smileysurprised::smileyvery-happy:

Models uploaded to SL are compromising between number of triangles and cost More triangles cost more to upload, take more bandwidth to communicate to the viewer, the viewer needs more power to render and more triangles need more prim space when rezzed in world. So dense models can easily course a laggy experience This is the simple version. There are more things to consider when the cost is calculated. This wiki article will get you started and lead you to a lot of other relevant articles :smileysurprised::smileyvery-happy:

Make sure the first frame is the T pose, it is needed for reference Make sure you don't include the T pose in the loop That is you if you have two frames the first is the T pose and the second is the one with your pose and the one to loop :smileysurprised::smileyvery-happy:

Looks like your left and right curly brackets do not match Counting I get one right too many :smileysurprised::smileyvery-happy: (Posting scripts please use the "C" icon in top of the edit window)

Knowing the avatar's key you can do this within the same region using llGetObjectDetails() :smileysurprised::smileyvery-happy:

What you list here is ONE single LSL-function and it need to be included in an event-handler which again need to be included in a state in order to form a proper script. I can only advise you to consult the wiki and read the examples on how this function is used :smileysurprised::smileyvery-happy:

I have experienced something similar. What happened to me was that the building was moved inadvertently by me, so furniture looked as moved and and some disappeared inside walls :smileysurprised::smileyvery-happy:

Vulpinus wrote: No I didn't use llSetTextureAnim (might investigate doing it that way though...). I'm still finding my feet in terms of what LSL offers. I simply(?) used sin/cos formulae to calculate the position of the moon, and updated the object's rotation along with its position in a call to llSetLinkPrimitiveParamsFast(), like this: llSetLinkPrimitiveParamsFast(moon, [PRIM_POSITION, <Y, X, 0.504742*scale>, PRIM_ROT_LOCAL, sunrot*<0, -1, 0, 1>]); This is not an efficient way to spin a prim The smart way is with llTargetOmega() In fact llTargetOmega() mostly put no load at all on the server :smileysurprised::smileyvery-happy:

Wandering Soulstar wrote: As I said, I am looking at code ways of doing this, but was wondering if there is a simple way for the user to drop a script onto a prim in such a way that the script is added to the prim, but starts in a not running state. Holding down Ctrl while dragging a script to a prim inventory will include it not running I am confused about what a "not running state" is, is it a LSL state doing nothing or 'state' in a more general sense where the script simply isn't running? :smileysurprised::smileyvery-happy:

The parameters for llRezObject() makes it possible to rez your object in any offset position and rotation, so you can make a script in the root prim rezz an object fitting your barrel I don't understand the last part of your post :smileysurprised::smileyvery-happy:

arton Rotaru wrote: How about llList2Rot()? Well spotted except llList2Rot() doesn't work, See the work around here :smileysurprised::smileyvery-happy:

You are not saying one word about what error you have so I am guessing You have a not normalized quaternion which is likely to happen when you cast from a string See Normalizing a Rotation to solve this problem :smileysurprised::smileyvery-happy:

Wandering Soulstar wrote: Dora, The point is the llFloor does not return a value less than 1: pos.x = 0.044634 (llFloor(pos.x * 10000)) = 446 So thus why does float test = (llFloor(pos.x * 10000))/10000 not result in test = 0.0446 since I declare test as a float and then divide one integer by another? It should be the same as the code that works, just doing it on the same line as opposed to two. Because, as I said: 446/10000 = 0; 446 and 10000 are both integers and the division is consequently an integer division I see you found out how to force a floating point division by turning one or both numbers into floating point, so problem solved and we can all be happy :smileysurprised::smileyvery-happy:

The frame rate all depends on the scene. Lots of objects, textures and people will slow you down Try to decrease your drawing distance to say 100 meters and see what effect that has You can also see a big difference when you are on the ground in a busy place and when you fly up high where there is not much to render Your equipment looks OK to me. If 24 fps isn't alright with you then 'Ultra' is too high :smileysurprised::smileyvery-happy:

llFoor() returns an integer so in the first example when you divide something less than 10000 with 10000 the result is 0 Say 980/10000 = 0 In the second case you convert to float before dividing so you get 980.0/10000 = 0.098 (10000 is automatically cast to a float in this case) :smileysurprised::smileyvery-happy:

Any object you Pay, not Buy, will have a script that will know what is payed The script can pass a fraction on to another resident and let the owner keep the rest :smileysurprised::smileyvery-happy:

When a rezzed object is made an event will happen in the rezzing object When that happens the event handler: object_rez will give you the UUID of the rezzed object Use that UUID with llRegionSayTo() to target the specific object :smileysurprised::smileyvery-happy:

Use these basic relations to fix your problem :smileysurprised::smileyvery-happy:

I conducted a small test and it showed that the texture must be in the prim you click to get the name It will not do to have it in the root if you are clicking a child prim When you are having script and textures in the root you get the names when clicking the root but you get keys when clicking the child prims It may be discussed how useful that is :smileysurprised::smileyvery-happy:

For llGetTexture() it is stated: If the texture is in the prim's inventory, the return value is the inventory name, otherwise the returned value is the texture UUID. This is the only explanation I see :smileysurprised::smileyvery-happy:

Sounds a bit odd to me as well When the texture is contained as a name that name should be given A texture referenced as a key should not be contained, because the key is universal and can be used in any script in SL There is no need to read from inventory Actually I don't see how You can get the key from a texture when you have full perms for that texture In the viewer inventory we have a menu option to extract the key In LSL we can use llGetTexture() to extract the key from a texture on a prim face or by using llGetInventoryKey() to get the key for a texture name in inventory :smileysurprised::smileyvery-happy:

Harlow LittleBoots wrote: I have the https://marketplace.secondlife.com/p/More-Imaginary-Seats-on-one-Prim/2859530 it is supposed to sit morethan one avatar butu it won't. would this fall under the no room to sit catagory? I am preplexed. The full documentation is found here From it I quote: “There is no room to sit, please try another spot” This is an error message you may get when two or more agents try to sit on one prim It arises when some bounding box prevents the sitting The first sit is never a problem because it is defined by the single SitTarget, but for the rest the server must find a place to sit before the script can place the sitter When the server can't find a place we have this "There is no room to sit, please try another spot" error You can read more about it and about other peoples experiences on the SL forum It must be emphasized, that this is not a script error but a system caveat, it can be seen when two or more avatars try to sit on an unscripted prim The only way to work around is to modify object design or to modify the environment You are welcome to contact me anytime for support on scripts I sold you provided the scripts are not modifiable :smileysurprised::smileyvery-happy:

Rolig Loon wrote: Natural log would be my guess. LN (x) = 2.30258 Log10(x). But don't ask me why it's here. :smileyindifferent: Rather the logarithm based on the number two log(1024)/log(2) = 10; ln(1024)/ln(2)=10; 2^10 = 1024; In general the two based logarithm of x equals ln(x)/ln(2) Even more general the N based logarithm of x equals ln(x)/ln(N) :smileysurprised::smileyvery-happy:

Johan Laurasia wrote: on_rez() should only be used when you want to do something at the point at which the object is rezzed. state_entry() when you want the function performed every time the script is ran. In this case it would be proper to use state_entry, not on_rez. While both would work, the on_rez version would break if the script was simply reset. For any script where you're grabbing keys it's prudent to grab them each time the script is ran, not rezzed, hence, use state_entry(). The state_entry() is not run every time the script is run. It is only run when a state is entered, hence the name. If the default state has a state entry event handler then that state_entry() is run every time the script is reset because a reset will enter the default state :smileysurprised::smileyvery-happy:

You are right in your assumption :smileysurprised::smileyvery-happy: