• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: SVC-763
Type: Bug Bug
Status: Reopened Reopened
Priority: Major Major
Assignee: Andrew Linden
Reporter: Ryozu Kojima
Votes: 12
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

All scripted physics calls fail a "physics deactivated" avatar

Created: 03/Oct/07 04:38 PM   Updated: 06/Sep/08 07:52 AM
Return to search
Component/s: Physics
Affects Version/s: None
Fix Version/s: Havok4 Beta

Issue Links:
Duplicate
 
Relates

Linden Lab Issue ID: DEV-3901


 Description  « Hide
Not sure the proper terminology, but I should clarify what I mean by "physics deactivated."
As I understand it, a collection of physical objects, and/or an avatar, once they come to a rest, are "deactivated" so as to save the physics engine cycles. Once a physical interaction is due to happen, they are reactivated and processed.

From my testing, once an avatar comes to a rest and is deactivated, any scripted physics call on that avatar fails. Persistent physics effects such as llSetForce or llMoveToTarget take effect once the avatar is activated, such as by the user moving the avatar. One-off physics calls such as llApplyImpulse or llPushObject simply fail, as their effect happens on an avatar that is not in the active state.

This applies to:

llApplyImpulse
llPushObject
llSetForce
llMoveToTarget

All physics functions excluding llPushObject must be in an attachment, and thus "part of the avatar" to affect the avatar. llPushObject may be called from an inworld object. Even when not attached, it still fails.

I'm guessing there should be a code path that each physics call goes through that just needs to activate the avatar before taking effect.

SVC-734 Falls under this but, although it only specifically names llMoveToTarget,



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Ryozu Kojima made changes - 03/Oct/07 04:41 PM
Field Original Value New Value
Description Not sure the proper terminology, but I should clarify what I mean by "physics deactivated."
As I understand it, a collection of physical objects, and/or an avatar, once they come to a rest, are "deactivated" so as to save the physics engine cycles. Once a physical interaction is due to happen, they are reactivated and processed.

From my testing, once an avatar comes to a rest and is deactivated, any scripted physics call on that avatar fails. Persistent physics effects such as llSetForce or llMoveToTarget take effect once the avatar is activated, such as by the user moving the avatar. One-off physics calls such as llApplyImpulse or llPushObject simply fail, as their effect happens on an avatar that is not in the active state.

This applies to:

llApplyImpulse
llPushObject
llSetForce
llMoveToTarget

All physics functions excluding llPushObject must be in an attachment, and thus "part of the avatar" to affect the avatar. llPushObject may be called from an inworld object. Even when not attached, it still fails.

I'm guessing there should be a code path that each physics call goes through that just needs to activate the avatar before taking effect.

SVC-760 Falls under this but, although it only specifically names llMoveToTarget,
Not sure the proper terminology, but I should clarify what I mean by "physics deactivated."
As I understand it, a collection of physical objects, and/or an avatar, once they come to a rest, are "deactivated" so as to save the physics engine cycles. Once a physical interaction is due to happen, they are reactivated and processed.

From my testing, once an avatar comes to a rest and is deactivated, any scripted physics call on that avatar fails. Persistent physics effects such as llSetForce or llMoveToTarget take effect once the avatar is activated, such as by the user moving the avatar. One-off physics calls such as llApplyImpulse or llPushObject simply fail, as their effect happens on an avatar that is not in the active state.

This applies to:

llApplyImpulse
llPushObject
llSetForce
llMoveToTarget

All physics functions excluding llPushObject must be in an attachment, and thus "part of the avatar" to affect the avatar. llPushObject may be called from an inworld object. Even when not attached, it still fails.

I'm guessing there should be a code path that each physics call goes through that just needs to activate the avatar before taking effect.

SVC-734 Falls under this but, although it only specifically names llMoveToTarget,
Ryozu Kojima made changes - 03/Oct/07 08:28 PM
Link This issue is related to by SVC-737 [ SVC-737 ]
Andrew Linden made changes - 10/Oct/07 04:38 PM
Assignee Andrew Linden [ Andrew Linden ]
Andrew Linden made changes - 10/Oct/07 04:42 PM
Status Open [ 1 ] Resolved [ 5 ]
Resolution Fixed Internally [ 7 ]
Ryozu Kojima made changes - 10/Oct/07 09:51 PM
Resolution Fixed Internally [ 7 ]
Status Resolved [ 5 ] Reopened [ 4 ]
Ryozu Kojima made changes - 10/Oct/07 09:52 PM
Resolution Fixed [ 1 ]
Status Reopened [ 4 ] Resolved [ 5 ]
Ryozu Kojima made changes - 10/Oct/07 09:56 PM
Status Resolved [ 5 ] Closed [ 6 ]
Ryozu Kojima made changes - 10/Oct/07 09:58 PM
Status Closed [ 6 ] Reopened [ 4 ]
Resolution Fixed [ 1 ]
Andrew Linden made changes - 11/Oct/07 07:27 PM
Resolution Fixed Internally [ 7 ]
Status Reopened [ 4 ] Resolved [ 5 ]
dan linden made changes - 19/Oct/07 05:54 PM
Linden Lab Issue ID DEV-3901
Torley Linden made changes - 21/Dec/07 12:03 PM
Resolution Fixed Internally [ 7 ]
Status Resolved [ 5 ] Reopened [ 4 ]
Torley Linden made changes - 21/Dec/07 12:03 PM
Status Reopened [ 4 ] Closed [ 6 ]
Fix Version/s Havok4 Beta [ 10171 ]
Resolution Fixed [ 1 ]
Rob Linden made changes - 22/Dec/07 01:52 AM
Workflow jira [ 15717 ] jira-2007-12-21 [ 23462 ]
Rob Linden made changes - 23/Dec/07 12:34 AM
Workflow jira-2007-12-21 [ 23462 ] jira-2007-12-22a [ 49391 ]
Johan Durant made changes - 03/Apr/08 07:58 AM
Link This issue is duplicated by SVC-1994 [ SVC-1994 ]
Johan Durant made changes - 03/Apr/08 08:01 AM
Resolution Fixed [ 1 ]
Status Closed [ 6 ] Reopened [ 4 ]
Sean Buridan made changes - 06/Apr/08 04:01 PM
Link This issue Relates to SVC-2098 [ SVC-2098 ]
Johan Durant made changes - 19/Apr/08 07:35 AM
Priority Normal [ 4 ] Major [ 3 ]
Johan Durant made changes - 22/May/08 11:11 AM
Affects Version/s 1.21.0 Server [ 10310 ]
Johan Durant made changes - 22/May/08 11:12 AM
Affects Version/s 1.21.0 Server [ 10310 ]
Sue Linden made changes - 13/Nov/08 12:07 PM
Workflow jira-2007-12-22a [ 49391 ] jira-2008-11-14 [ 81622 ]
Sue Linden made changes - 13/Nov/08 04:35 PM
Workflow jira-2008-11-14 [ 81622 ] jira-2008-11-14a [ 88631 ]