LlSetKeyframedMotion - Revision history

Frio Belmonte: KFM doesn't have the same limit as llSetPos with regard to the region ground, but gets unstable if you try to go too deep under

2026-05-19T12:57:32Z

KFM doesn't have the same limit as llSetPos with regard to the region ground, but gets unstable if you try to go too deep under

← Older revision		Revision as of 05:57, 19 May 2026
Line 44:		Line 44:
	*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.		*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.
	*As with dynamic objects, objects moving using this function are paused when they are selected by an avatar with adequate permissions (object owner, passenger, etc). When such an avatar deselects the object, motion resumes, even if the object had been paused using [[KFM_CMD_PAUSE]].		*As with dynamic objects, objects moving using this function are paused when they are selected by an avatar with adequate permissions (object owner, passenger, etc). When such an avatar deselects the object, motion resumes, even if the object had been paused using [[KFM_CMD_PAUSE]].
	*A ~~Key Framed Motion~~ is a '''prim property''' in some respect. When a [[KFM_LOOP]] or [[KFM_PING_PONG]] is initiated the '''the motion''' is '''preserved after the script is removed'''. I.E. The prim will continue what motion it had. It will survive take and copy. It will survive server restart.		*A Keyframed motion is a '''prim property''' in some respect. When a [[KFM_LOOP]] or [[KFM_PING_PONG]] is initiated the '''the motion''' is '''preserved after the script is removed'''. I.E. The prim will continue what motion it had. It will survive take and copy. It will survive server restart.
	*~~Inter region~~ movement is far from perfect. Crossing from sim 1 to sim 2 using a Key Frame list with numerous frames on a curved path will pick up conspicuous errors on the crossing and when reversed by [ [[KFM_MODE]], [[KFM_REVERSE]] ] the object will stay in sim 2 and never return to sim 1		*Interregion movement is far from perfect. Crossing from sim 1 to sim 2 using a Key Frame list with numerous frames on a curved path will pick up conspicuous errors on the crossing and when reversed by [ [[KFM_MODE]], [[KFM_REVERSE]] ] the object will stay in sim 2 and never return to sim 1
			* Unlike [[llSetPos]], [[PRIM_POSITION]] and related functions, keyframed motion '''can''' move objects below the region ground level, but the behavior becomes increasingly unstable beyond a short distance. Attempting to correct position drift after keyframed motion with calls to such functions will cause the object to snap to the ground level instead, which may be unexpected.
	\|examples=		\|examples=
	A KFM object must use the new Prim Equivalency system in order to work. One of many ways to achieve this is to make sure the object uses Convex Hull for its physics shape. (Mainly new prims need a workaround like this. Mesh objects always use the new Prim Equivalency system.)		A KFM object must use the new Prim Equivalency system in order to work. One of many ways to achieve this is to make sure the object uses Convex Hull for its physics shape. (Mainly new prims need a workaround like this. Mesh objects always use the new Prim Equivalency system.)

Nelson Jenkins: Added note about translation positions being relative to grid

2026-05-15T06:56:01Z

Added note about translation positions being relative to grid

← Older revision		Revision as of 23:56, 14 May 2026
Line 15:		Line 15:
	* ''float'' time		* ''float'' time

	Each keyframe is interpreted '''relative''' to the previous transform of the object. Time values must be 1/9s. or greater. For example, consider the following list of keyframes:		Each keyframe is interpreted '''relative''' to the previous transform of the object. Translation positions are relative to the grid and are not affected by the object's rotation. Time values must be 1/9s. or greater. For example, consider the following list of keyframes:
	[<0, 0, 10>, [[ZERO_ROTATION]], 5, <0, 0, 0>, [[ZERO_ROTATION]], 5, <0, 0, -10>, [[ZERO_ROTATION]], 5]		[<0, 0, 10>, [[ZERO_ROTATION]], 5, <0, 0, 0>, [[ZERO_ROTATION]], 5, <0, 0, -10>, [[ZERO_ROTATION]], 5]
	This would cause the object to move up 10m over the course of 5s. It would then remain at the location for 5s before moving down 10m over the course of another 5s.		This would cause the object to move up 10m over the course of 5s. It would then remain at the location for 5s before moving down 10m over the course of another 5s.

Lou Netizen: Updated "Continuous Spin" example script to a working example

2024-09-07T16:25:13Z

Updated "Continuous Spin" example script to a working example

← Older revision		Revision as of 09:25, 7 September 2024
Line 189:		Line 189:
	default		default
	{		{
	~~touch_start~~(integer total_number)		touch_end(integer total_number)
	{		{
	gON = !~~gON;~~		if (gON = !gON)
	~~if (~~gON)
	{		{
	// Make repeated rotations of PI/2 radians, each taking ~~0.5~~ seconds		// Make repeated rotations of PI radians, each taking 1 seconds
	~~llSetKeyframedMotion([~~llEuler2Rot(<0.0,0.0,PI/2>), ~~0.5~~],[KFM_DATA,KFM_ROTATION, KFM_MODE,KFM_LOOP]);		rotation r = llEuler2Rot(<0.0, 0.0, PI>);
	}		llSetKeyframedMotion(
	~~else~~		[
	{		r, 1,
	~~llSetKeyframedMotion([],[])~~;		r, 1
			],
			[KFM_DATA, KFM_ROTATION, KFM_MODE, KFM_LOOP]
			);
			return;
	}		}

			llSetKeyframedMotion([], []);
	}		}
	}		}

Wulfie Reanimator: Updated examples.

2023-07-06T07:02:17Z

Updated examples.

← Older revision		Revision as of 00:02, 6 July 2023
Line 47:		Line 47:
	*Inter region movement is far from perfect. Crossing from sim 1 to sim 2 using a Key Frame list with numerous frames on a curved path will pick up conspicuous errors on the crossing and when reversed by [ [[KFM_MODE]], [[KFM_REVERSE]] ] the object will stay in sim 2 and never return to sim 1		*Inter region movement is far from perfect. Crossing from sim 1 to sim 2 using a Key Frame list with numerous frames on a curved path will pick up conspicuous errors on the crossing and when reversed by [ [[KFM_MODE]], [[KFM_REVERSE]] ] the object will stay in sim 2 and never return to sim 1
	\|examples=		\|examples=
			A KFM object must use the new Prim Equivalency system in order to work. One of many ways to achieve this is to make sure the object uses Convex Hull for its physics shape. (Mainly new prims need a workaround like this. Mesh objects always use the new Prim Equivalency system.)
	<source lang="lsl2">		<source lang="lsl2">
	/~~/ If your client is not mesh-aware use the following line:~~		llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);
			</source>

	~~llSetLinkPrimitiveParamsFast(LINK_THIS~~,		This is a simple example of back-and-forth or "ping pong" motion, using only positions and time.
	~~[PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);~~
	~~</source>~~
	<source lang="lsl2">		<source lang="lsl2">
	llSetKeyframedMotion(		llSetKeyframedMotion([<0.0, 0.0, 10.0>, 5, <0.0, 0.0, -10.0>, 5], [KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_PING_PONG]);
	[<0.0, 0.0, 10.0>, 5, <0.0, 0.0, -10.0>, 5],
	[KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_PING_PONG]);
	</source>		</source>

			This example includes position, rotation, and time.
	<source lang="lsl2">		<source lang="lsl2">
	llSetKeyframedMotion(		llSetKeyframedMotion(
Line 64:		Line 64:
	[KFM_MODE, KFM_REVERSE]);		[KFM_MODE, KFM_REVERSE]);
	</source>		</source>

	=== Pause-Play ===		=== Pause-Play ===
	<source lang="lsl2">llSetKeyframedMotion([],[KFM_COMMAND, KFM_CMD_PAUSE]);		If you need to update a KFM object's position, you will need to pause KFM and continue it afterwards.
	//~~modify~~ prim positions here		<source lang="lsl2">
	llSetKeyframedMotion([],[KFM_COMMAND, KFM_CMD_PLAY]);</source>		llSetKeyframedMotion([],[KFM_COMMAND, KFM_CMD_PAUSE]);
			// Modify prim positions here
			llSetKeyframedMotion([],[KFM_COMMAND, KFM_CMD_PLAY]);
			</source>

	===Sample Script - Key Framed Follower===		===Sample Script - Key Framed Follower===
	Under some circumstances, rotations will generate a run-time error unless they are normalized. This script illustrates a way to use llKeyframedMotion to create a follower -- think, for example, of a cart behind a vehicle -- using normalized target rotation.		Under some circumstances, rotations will generate a run-time error unless they are normalized. This script illustrates a way to use llKeyframedMotion to create a follower -- think, for example, of a cart behind a vehicle -- using normalized target rotation.
	<source lang="lsl2">		<source lang="lsl2">
			key scriptedObjectToFollow = "daf4847b-967d-bff6-69c0-fd7022241be7";
	integer isSensorRepeatOn;		integer isSensorRepeatOn;

	rotation ~~NormRot~~(rotation Q)		rotation NormalizeRotation(rotation Q)
	{		{
	float MagQ = llSqrt(Q.xQ.x + Q.yQ.y +Q.zQ.z + Q.sQ.s);		float MagQ = llSqrt(Q.xQ.x + Q.yQ.y +Q.zQ.z + Q.sQ.s);
			return <Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>;
	return
	<Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>;
	}		}

Line 85:		Line 89:
	state_entry()		state_entry()
	{		{
	llSetLinkPrimitiveParamsFast(LINK_ROOT,		llSetLinkPrimitiveParamsFast(LINK_ROOT, [
	[PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX,		PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX,
	PRIM_LINK_TARGET, LINK_ALL_CHILDREN,		PRIM_LINK_TARGET, LINK_ALL_CHILDREN,
	PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE]);		PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE
			]);
	}		}

Line 97:		Line 102:
	if (isSensorRepeatOn)		if (isSensorRepeatOn)
	{		{
	~~// PUBLIC_CHANNEL has the integer value 0~~
	llSay(PUBLIC_CHANNEL, "Sensor repeat switched on!");		llSay(PUBLIC_CHANNEL, "Sensor repeat switched on!");
			llSensorRepeat("", scriptedObjectToFollow, SCRIPTED, 10.0, PI, 0.3);
	llSensorRepeat("", ~~"91b39b5b-13b1-2517-273a-67360b842c02"~~, SCRIPTED, 10.0, PI, 0.1);
	}		}
	else		else
	// {		{
	llSensorRemove();		llSensorRemove();
	// }		}
	}		}

Line 115:		Line 118:
	rotation detectedRotation = llDetectedRot(0);		rotation detectedRotation = llDetectedRot(0);

	~~llSetKeyframedMotion(~~		vector kfmPosition = (detectedPosition - ownPosition) + <-1.0, 0.0, 0.2> * detectedRotation;
	[(detectedPosition - ownPosition) + <-1.0, 0.0, 0.2>*detectedRotation,		rotation kfmRotation = NormalizeRotation(detectedRotation / ownRotation);
	~~NormRot~~(detectedRotation/ownRotation), 0.12],		llSetKeyframedMotion([kfmPosition, kfmRotation, 0.15], []);
	[]);
	}		}
	}		}

Wulfie Reanimator at 06:26, 6 July 2023

2023-07-06T06:26:09Z

← Older revision		Revision as of 23:26, 5 July 2023
Line 15:		Line 15:
	* ''float'' time		* ''float'' time

	Each keyframe is interpreted '''relative''' to the previous transform of the object. Time values must be 1/9s. or greater.		Each keyframe is interpreted '''relative''' to the previous transform of the object. Time values must be 1/9s. or greater. For example, consider the following list of keyframes:
			[<0, 0, 10>, [[ZERO_ROTATION]], 5, <0, 0, 0>, [[ZERO_ROTATION]], 5, <0, 0, -10>, [[ZERO_ROTATION]], 5]
	For example, consider the following list of keyframes: [<0, 0, 10>, [[ZERO_ROTATION]], 5, <0, 0, 0>, [[ZERO_ROTATION]], 5, <0, 0, -10>, [[ZERO_ROTATION]], 5]. This would cause the object to move up 10m over the course of 5s. It would then remain at the location for 5s before moving down 10m over the course of another 5s.		This would cause the object to move up 10m over the course of 5s. It would then remain at the location for 5s before moving down 10m over the course of another 5s.

	An empty list will terminate any keyframed animation currently playing.		An empty list will terminate any keyframed animation currently playing.

Wulfie Reanimator: Reworded the function description with a hopefully more "clear at a glance" structure.

2023-07-06T06:22:45Z

Reworded the function description with a hopefully more "clear at a glance" structure.

← Older revision		Revision as of 23:22, 5 July 2023
Line 3:		Line 3:
	\|func=llSetKeyframedMotion		\|func=llSetKeyframedMotion
	\|func_id=?		\|func_id=?
	\|func_desc=Specify a list of ~~times~~, ~~positions~~, and ~~orientations~~ to be followed by an object. The object will be smoothly moved between keyframes by the simulator. Collisions with other nonphysical or keyframed objects will be ignored (no script events will fire and collision processing will not occur). Collisions with physical objects will be computed and reported, but the keyframed object will be unaffected by those collisions. (The physical object will be affected, however.)		\|func_desc=Specify a list of positions, orientations, and timings to be followed by an object. The object will be smoothly moved between those keyframes by the simulator.

			Collisions with other nonphysical or keyframed objects will be ignored (no script events will fire and collision processing will not occur). Collisions with physical objects will be computed and reported, but the keyframed object will be unaffected by those collisions. (The physical object will be affected, however.)
	\|func_sleep		\|func_sleep
	\|func_energy		\|func_energy
Line 13:		Line 15:
	* ''float'' time		* ''float'' time

	Each keyframe is interpreted relative to the previous transform of the object. For example, consider the following list of keyframes: [<0, 0, 10>, [[ZERO_ROTATION]], 5, <0, 0, 0>, [[ZERO_ROTATION]], 5, <0, 0, -10>, [[ZERO_ROTATION]], 5]. This would cause the object to move up 10m over the course of 5s. It would then remain at the location for 5s before moving down 10m over the course of another 5s.		Each keyframe is interpreted '''relative''' to the previous transform of the object. Time values must be 1/9s. or greater.
	~~Time values must be 1/9s. or greater.~~
	~~Linear and angular velocities will be clamped to limits set by the simulator (values TBD).~~		For example, consider the following list of keyframes: [<0, 0, 10>, [[ZERO_ROTATION]], 5, <0, 0, 0>, [[ZERO_ROTATION]], 5, <0, 0, -10>, [[ZERO_ROTATION]], 5]. This would cause the object to move up 10m over the course of 5s. It would then remain at the location for 5s before moving down 10m over the course of another 5s.

	An empty list will terminate any keyframed animation currently playing.		An empty list will terminate any keyframed animation currently playing.
	\|p2_type=list\|p2_subtype=instructions\|p2_name=options\|p2_desc=modifiers and future options		\|p2_type=list\|p2_subtype=instructions\|p2_name=options\|p2_desc=modifiers and future options
Line 36:		Line 39:
	*This function can only be called on the root prim of a linkset.		*This function can only be called on the root prim of a linkset.
	*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.		*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.
			*Linear velocity greater than Second Life's maximum of 250 meters per second will produce an error on DEBUG_CHANNEL.
	*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread] KFM claims delta times must be larger than 0.1 seconds; in practice, however, delta times slightly over 0.1 will produce an error on DEBUG_CHANNEL. Testing shows a minimum delta time is about 6/45 (.13333) seconds.		*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread] KFM claims delta times must be larger than 0.1 seconds; in practice, however, delta times slightly over 0.1 will produce an error on DEBUG_CHANNEL. Testing shows a minimum delta time is about 6/45 (.13333) seconds.
	**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].		**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].
Line 51:		Line 55:
	<source lang="lsl2">		<source lang="lsl2">
	llSetKeyframedMotion(		llSetKeyframedMotion(
	[<0.0, 0.0, 10.0>, 5,		[<0.0, 0.0, 10.0>, 5, <0.0, 0.0, -10.0>, 5],
	<0.0, 0.0, -10.0>, 5],
	[KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_PING_PONG]);		[KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_PING_PONG]);
	</source>		</source>
Line 58:		Line 61:
	llSetKeyframedMotion(		llSetKeyframedMotion(
	[<0.0, 0.0, 10.0>, llEuler2Rot(<90, 45, 180> * DEG_TO_RAD), 5,		[<0.0, 0.0, 10.0>, llEuler2Rot(<90, 45, 180> * DEG_TO_RAD), 5,
	<0.0, 0.0, -10.0>, llEuler2Rot(<270, 225, 360> * DEG_TO_RAD), 5],		<0.0, 0.0, -10.0>, llEuler2Rot(<270, 225, 360> * DEG_TO_RAD), 5],
	[KFM_MODE, KFM_REVERSE]);		[KFM_MODE, KFM_REVERSE]);
	</source>		</source>

Lou Netizen at 23:24, 11 September 2018

2018-09-11T23:24:20Z

← Older revision		Revision as of 16:24, 11 September 2018
Line 36:		Line 36:
	*This function can only be called on the root prim of a linkset.		*This function can only be called on the root prim of a linkset.
	*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.		*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.
	*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread] ~~In any case,~~ KFM claims delta times must be larger than 0.1 seconds~~. In~~ practice, however, delta times slightly over 0.1 will produce an error on DEBUG_CHANNEL. Testing shows a minimum delta time is about 6/45 (.13333).		*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread] KFM claims delta times must be larger than 0.1 seconds; in practice, however, delta times slightly over 0.1 will produce an error on DEBUG_CHANNEL. Testing shows a minimum delta time is about 6/45 (.13333) seconds.
	**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].		**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].
	*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.		*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.

Lou Netizen: Minimum delta time in practice is not > 0.1, but probably > 0.13333

2018-09-11T23:21:35Z

Minimum delta time in practice is not > 0.1, but probably > 0.13333

← Older revision		Revision as of 16:21, 11 September 2018
Line 36:		Line 36:
	*This function can only be called on the root prim of a linkset.		*This function can only be called on the root prim of a linkset.
	*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.		*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.
	*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread] In any case, delta times must be larger than 0.1 seconds.		*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread] In any case, KFM claims delta times must be larger than 0.1 seconds. In practice, however, delta times slightly over 0.1 will produce an error on DEBUG_CHANNEL. Testing shows a minimum delta time is about 6/45 (.13333).
	**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].		**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].
	*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.		*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.

Lou Netizen: Documented lower limit on delta times

2018-06-18T19:06:14Z

Documented lower limit on delta times

← Older revision		Revision as of 12:06, 18 June 2018
Line 36:		Line 36:
	*This function can only be called on the root prim of a linkset.		*This function can only be called on the root prim of a linkset.
	*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.		*This function requires the linkset to use the Prim Equivalency system. However, it keyframed objects will not receive the dynamics penalty and can have a physics weight of up to 64.
	*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread]		*llSetKeyframedMotion is implemented in terms of frames and not real time. To avoid a drift from the expected positions and rotations, use times which are integer multiples of 1/45, e.g. 20.0/45.0, 40.0/45.0, 90.0/45.0, etc. [http://community.secondlife.com/t5/LSL-Scripting/llSetKeyframedMotion-turning-a-corner/td-p/1225219 Forum Thread] In any case, delta times must be larger than 0.1 seconds.
	**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].		**Natural drift can still occur; for best results use [[moving_end]] to determine when the animation has ended and confirm the target position with [[llSetPos]]. Or you can use [[at_target]] or [[at_rot_target]].
	*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.		*There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.

Tapple Gao: Moved my pendelum example before Dora's, since it's more general

2017-05-15T14:57:55Z

Moved my pendelum example before Dora's, since it's more general

← Older revision		Revision as of 07:57, 15 May 2017
Line 200:		Line 200:
	</source>		</source>
	===More Examples===		===More Examples===
			* [[User:Tapple_Gao/3D_Spinning_Pendulum_Motion\|3D Spinning Pendulum Motion]], Suitable for spinning tops, swings, tire swings. Highly configurable
			* [[User:Dora_Gustafson/Harmonic_Oscillator_motion\|Oscillator Motion in 12 Key Frames]]
	* [[User:Dora_Gustafson/Pendulum_motion\|Simple Pendulum Motion in 24 Key Frames]], a good motion for a swing		* [[User:Dora_Gustafson/Pendulum_motion\|Simple Pendulum Motion in 24 Key Frames]], a good motion for a swing
	* [[User:Dora_Gustafson/Harmonic_Oscillator_motion\|Oscillator Motion in 12 Key Frames]]
	* [[User:Tapple_Gao/3D_Spinning_Pendulum_Motion\|3D Spinning Pendulum Motion]], Suitable for spinning tops, swings, tire swings. Highly configurable
	\|notes=		\|notes=
	Potential Use Cases:		Potential Use Cases: