Dora Gustafson

llGetInventoryType( string name) only accepts a string as argument so when you give it a key it will look for a name not found in inventory. With that in mind I only see what can be expected in your example. I do not claim to fully understand your post, but you can blame me for that :smileysurprised::smileyvery-happy:

You may do it by intersecting your object with a cylinder: use: Mesh / Faces / Intersect You will get all edges and vertexes where the cylinder intersect the box and you will need to do some cleaning up to keep only that. :smileysurprised::smileyvery-happy:

To meet that issue you may consider naming all your way points identically and use the name as filter in llSensorRepeat() Say: llSensorRepeat("waypoint", "", PASSIVE, sensorDistance, PI, 1.0); The number can be placed in the description and you can get it by: list L = llGetObjectDetails( llDetectedKey( detected), [OBJECT_DESC]);integer number = llList2Integer( L, 0); As a bonus you can remove the filtering you have in the sensor event handler :smileysurprised::smileyvery-happy:

I am almost certain, but don't take my word for it:smileyindifferent: I remember I read it somewhere but can't find it now :smileysurprised::smileyvery-happy: FOUND: The results are ordered from nearest to furthest. Found at http://wiki.secondlife.com/wiki/Sensor

Sure you can do that Give all the prims the same name and let your moving prim use llSensor() to sense them The first one returned (number 0) out of max 16 is the nearest one In the sensor event you have access to all returned prim positions and rotations at the same time Use llDetectedPos() and llDetectedRot() for that :smileysurprised::smileyvery-happy:

Which brings us back to the beginning. Since neither the box prim nor the line prim is the root prim you need almost all the bells and whistles This is a case derived from the general solution in this post float amount_of_size_change; vector linePrimPos; vector boxPrimPos; rotation boxPrimRot; vector relativePos = linePrimPos - boxPrimPos; vector newlinePrimPos = boxPrimPos + amount_of_size_change * relativePos; assuming: 'boxPrimPos' is the same before and after rotation of box prim is the same before and after rotation of line prim is the same before and after If you use different scaling on the three axes it is an entirely different story :smileysurprised::smileyvery-happy:

You probably do, I just don't understand your problem Maybe we just understand 'scale' differently Do you want to change size AND local position? Are the two local positions on a straight line through local zero? If they are on a straight line you can obtain one from the other by multiplying by a constant float number, say: vector P = llGetLocalPos();float amount_of_size_change = 2.0;llSetPos( amount_of_size_change * P); If they are not in line with local zero you must code the local positions into your program :smileysurprised::smileyvery-happy:

Oh dear! You are confusing the prim-Scale(or prim size) with the amount of change in scale you want to apply Say, you want to double the size vector S = llGetScale();vector P = llGetLocalPos();float amount_of_size_change = 2.0;llSetScale( amount_of_size_change * S);llSetPos( amount_of_size_change * P); This will double the size and local position of the child prim that contains the script/snippet I see you know your way with 'PrimitiveParams', so it should be easy for you to adopt the snippet in a central script :smileysurprised::smileyvery-happy: I can understand if you are trying to learn and want to know what goes on Still llScaleByFactor() can do it all for you You can even look under the hood here in deep notes

See Note 2 This is what you ask The equations simplify to what is in note 2 in the special case where position and rotation of prim 1 both are ZERO As noted somewhere along the line: F is the scale! :smileysurprised::smileyvery-happy:

When you know position and rotation for two prims the relation can be computed like this: relativeRot = P2Rot / P1Rot; relativePos = (P2Pos - P1Pos) / P1Rot; When you know the relation and position and rotation for prim 1 you can compute position and rotation for prim 2 like this: P2Rot = relativeRot * P1Rot; P2Pos = P1Pos + relativePos * P1Rot; When you want to scale the position with a factor: F, use: P2Rot = relativeRot * P1Rot; P2Pos = P1Pos + F*relativePos * P1Rot; :smileysurprised::smileyvery-happy: Reference Note: If you are trying to resize a linkset you should take a look at llScaleByFactor() llScaleByFactor() includes what is said above and more, in one function Note 2: The snippets above are general and work for any two linked or unlinked prims or link sets Inside a linkset where we use local positions and local rotation we can simplify the snippets to: Child_new_local_position = F*Child_local_position; ...provided P1 is the root prim and P2 is a child prim

Meaning: s, w, p and d ? in: set_bitfield(integer s, integer w, integer p, integer d) Neither do I and I would have to analyze the script to find out, which I am not intending I merely do bit logic from case to case when it is convenient :smileysurprised::smileyvery-happy:

Right This is the actual structure: if(m == "POP") { .... if(IntValue == 2) { ... } else { ... } if(m == "Push") { ... } if(m == "Rub") { ... } if(m == "Glomp") { ... } if(m == "Inflate") { ... } } It shows that m equal to POP will exclude the rest of the tests for m to become true. A stringent formatting can reveal that right away :smileysurprised::smileyvery-happy:

A widespread way to do this is by a particle rope I found this for you in the LSL Library :smileysurprised::smileyvery-happy:

I guess you find an answer in this thread :smileysurprised::smileyvery-happy:

You are so right, in movies and on TV there are nothing but stills In the virtual world there is nothing but stills and on the SL servers we have 45 per second at the most The virtual motion we see is generated by the viewer though and is not limited to the capacity of server and connection It is client side, the number is not fixed and can go higher than 100 FPS

Make the offset the vector between you and the object: vector offset = llGetPos()-llDetectedPos(0); pos += offset; In one step: pos = 2.0*llGetPos()-llDetectedPos(0); :smileysurprised::smileyvery-happy:

If you are familiar with vectors it should be easy. llGetPos() gives you the actual position of the arrow llGetVel() gives you the velocity e.i. the speed and the direction the arrow moves When you add the two you get a point somewhere ahead of your arrow and that is exactly what you want for llLookAt(): a point to look at. It doesn't matter how far away the point is as long as it is ahead of the arrow in the direction of the movement :smileysurprised::smileyvery-happy:

The arrow is attracted to ground by gravity so it's path is not a straight line This can be why :smileysurprised::smileyvery-happy:

You are in luck:) The arrow head has forward in the Z direction so llLookAt is made for you: llLookAt( llGetVel()+llGetPos(), 1.0, 0.5); :smileysurprised::smileyvery-happy:

Problem may arise because llSetRot is not for physical objects The wiki says about llSetRot(): This function is available for nonphysical root prims and all child prims. It has no effect on the root prim if the object is physical. Take a look at llRotTarget() and the example to see how it can be done Also notice if STATUS_ROTATE_X, STATUS_ROTATE_Y and STATUS_ROTATE_Z are set true See llSetStatus() about how you do that :smileysurprised::smileyvery-happy:

http://maps.secondlife.com/secondlife/Sandbox%20Cordova/189/96/27 http://maps.secondlife.com/secondlife/Sandbox%20Wanderton/145/156/27 http://maps.secondlife.com/secondlife/Sandbox%20Newcomb/163/121/27 http://maps.secondlife.com/secondlife/Sandbox%20Goguen/98/89/27 None of these allow scripts running :smileysurprised::smileyvery-happy:

Use the World map! You get no better way to find mainland where you want, at the size you want and at the price you want :smileysurprised::smileyvery-happy:

LOL That is one way to go when the prim is NOT a cylinder, prism, sphere, torus, tube, ring or sculpty type and it is has NO cut, twist, shear and tapering NOT to mention different textured faces and different face atributs like different color, shine, alpha, bumps, glow and fullbright :smileysurprised::smileyvery-happy:

If you plan to spend money try this: Prim-Mirror-Tool Works for all kinds of prims and link sets but not for mesh models There are a few more makes out there :smileysurprised::smileyvery-happy:

32 bit targa in SL is 24 bit RGB + 8 bit alpha channel So if you don't have alpha in your texture don't use it! Stick to 24 bit RGB Guess when you say 8 bit RGB you mean 8 bit per color red, green and blue? If it is not then it is paletted and you should start using 24 bit right away :smileysurprised::smileyvery-happy: