Myrmidon Hasp

If it's necessary to have a really smooth circular path why not feed llPatrolPoints() a calculated at runtime subset of the total waypoints and update it on a cadence or conditional to match up with reaching the last element of that subset? It may stutter a bit when it reaches those calculation points but it will stay under memory limits and get a really smooth plot of points. The other option as I see it is to just use a coarser set of the full circle. Depending on the object's speed of travel and the size of the radius it's possible to get some good enough looking results. I'm not certain, but it might be possible to smooth out those coarser circles by adjusting the turning speed and radius properties when initializing the pathfinding character.

Just to clarify the specific error; there's a block of bracket and brace garbage between the end of your startParticle() function and the default state. ]); } } ] ) ; } should be: ]); }

If you want the rezzed objects' positional offsets to match the rotation of the root prim, you need to multiply by the root prim's rotation instead of the child prim's ultimate rotation. vector myPos =llGetPos() + relPos * relRot; should be: vector myPos =llGetPos() + relPos * llGetRot(); You'll also want to either set the position first or store the data from the initial llGetRot() from your on_rez event in a variable. As you have it currently, setting the rotation first wipes the data you need to get the position rotated properly. EDIT: clarity

Many educational institutions also begin fall semester around this time as well. It's a busy time not only for those attending, but for anyone employed in related businesses. Also there's been a hurricane making a mess in the gulf coast for most of the week.

I haven't done a ton of testing on it, but I'm pretty sure it's based on what the copy permissions are for the texture/object. It seems to only output the name of the texture if it doesn't have full perms. I'd assume that they have it set this way to prevent stealing textures by grabbing the UUID.

If I'm understanding correctly, you're interested in having a child prim rotate around the root as if it was orbiting the root prim, not just rotating the child prim. I'm not sure if there's a more elegant way to accomplish this nowadays, but you can use a while loop to step through some simple trigonometry and progressively set the position of the orbiting child prim. I tore this little function out of one of my other projects and gave it a quick edit so it isn't going to do exactly what you're looking for, but it should show you how to do the math to plot a circle in a set number of slices. Xsurround(integer slices) // slices refers to how smoothe of a circle gets plotted. Larger values make for smoother circles. {// when run within a child prim, progressively sets the position in circle around X axis integer count=0; //initialize the loop count vector position=ZERO_VECTOR; //sets the centerpoint of the circle float radians=DEG_TO_RAD*360/slices; //calculates how many radians are incrimented per slice float radius=1; //sets how far out from the centerpoint to set the position while (count<=slices) { position.z = radius*llSin(radians * count); //calculates the z component of the circle position.y = radius*llCos(radians * count); //calculates the y component of the circle llSetPos(position); // sets the position, if this script is in a child prim it uses local coordinates ++count; //incriments the loop count } } You'll need to switch to a different function to set the position of a child prim from a root prim to really get what you're after. This doesn't change the rotation of the child prim, so you'll need to figure out where you want it to face with llRotBetween() and then use llSetLinkPrimitiveParamsFast(linknum, [PRIM_ROT_LOCAL, desiredRoration]); to actually set it. You may get some timing issues if you use the fast versions of the llSet* functions, in that case you may want to use the regular functions or add some more padding by breaking the while loop out into a timer event so everything lands in sequence. I can also send some example scripts or objects if you'd like.

I've found that the best way to deal with dynamic resizing and repositioning of linksets when the overall scale of the object changes is to get all the size and repositioning changes worked out when the linkset is at a preset scale, then multiply those changes by the proportional difference between the preset scale and the current scale. Say your base object is 1.5m cubic, but its been currently scaled up to be 2m cubic. To get the proportional difference you'd divide the current by the base to get a scalar of 1.33. Now you can multiply all the changes you've used in the 1.5m cubic object by that 1.33 scalar and have everything line up with the same proportions in size and position. You do have to be careful that the scalar doesn't set anything beyond the lower limits of prim setting though. Things can only get so tiny and there is only so much resolution that they can be accurately placed.

IIRC, only the script that casts the ray gets any information. When the ray is cast, it'll return everything that intersects that ray except the types of objects you've specifically set to filter out and up to whatever number of objects you've specified by max_hits. To use it in a weapon type scenario, you'd have to either create a secondary effect, like setting it as a particle system target, that the calling script would execute or tell whatever objects it detects that it has been "hit" with a llSay() and have the detected object's script react.