Please note the difference between llGet* and llSet* in the following explaination, to avoid confusion. Also as a foreword to people who have not used these functions, There is an llGetLocalPos and llGetLocalRot, but only an llSetLocalRot (and not llSetLocalPos) because llSetPos already affects child prims' local positions. Currently, the only way to reliably use a local position (get only) and local rotation (both get and set) is to use separate llGetLocalRot + llGetLocalPos, or llSetLocalRot + llSetPos. There is no PRIM_LOCAL_POSITION or PRIM_LOCAL_ROTATION for use in llGetPrimitiveParams, nor is there PRIM_LOCAL_ROTATION for llSetPrimitiveParams. The two workarounds are as follows, neither of which being an acceptable solution: 1. Use two separate scripts; one for position, another for rotation. Have them trigger on the same link-message. This causes the object to move in close sync uder ideal sim conditions, but has unpredictable results under heavy sim load, and is quite excessive in itself. 2.) Use the position of the root object (llGetRootPosition and llGetRootRotation) to determine the offset of the child and calculate the new PRIM_ROTATION for use in llSetPrimitiveParams. This works only if the object is nonphysical and stationary, since the position the object was in when it calculates is not exactly where it will be when it executes a few milliseconds later. Since child position/rotation are stored locally (in relation to the root prim) anyway, adding PRIM_LOCAL_ROTATION and PRIM_LOCAL_POSITION for use in llGetPrimitiveParams should not be a difficult addition. As for llSetPrimitiveParams, since PRIM_POSITION already reads global and sets local, PRIM_LOCAL_POSITION would function identically to PRIM_POSITION when used in llSetPrimitiveParams. PRIM_LOCAL_ROTATION, however, would affect it in the same wa as llSetLocalRot when used in llSetPrimitiveParams.