
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Duplicate
|
|
|
|
This issue is original of duplicate:
|
|
|
SVC-1994 llSetForce not affecting flying av correctly
|
|
|
|
|
Relates
|
|
This issue Relates to:
|
|
|
SVC-2098 llSetForce (with a large force) in an attachment fails if the avatar is not moving or bumped
|
|
|
|
|
|
This issue is related to by:
|
|
SVC-737
(Havok4) Meta-issue: Avatars Physics
|
|
|
|
|
|
|
| Linden Lab Issue ID: |
DEV-3901
|
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,
|
|
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-734 Falls under this but, although it only specifically names llMoveToTarget, |
Show » |
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,
|
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
]
|
made changes - 10/Oct/07 09:51 PM
|
Resolution
|
Fixed Internally
[ 7
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 10/Oct/07 09:52 PM
|
Resolution
|
|
Fixed
[ 1
]
|
|
Status
|
Reopened
[ 4
]
|
Resolved
[ 5
]
|
made changes - 10/Oct/07 09:56 PM
|
Status
|
Resolved
[ 5
]
|
Closed
[ 6
]
|
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
]
|
made changes - 19/Oct/07 05:54 PM
|
Linden Lab Issue ID
|
|
DEV-3901
|
made changes - 21/Dec/07 12:03 PM
|
Resolution
|
Fixed Internally
[ 7
]
|
|
|
Status
|
Resolved
[ 5
]
|
Reopened
[ 4
]
|
made changes - 21/Dec/07 12:03 PM
|
Status
|
Reopened
[ 4
]
|
Closed
[ 6
]
|
|
Fix Version/s
|
|
Havok4 Beta
[ 10171
]
|
|
Resolution
|
|
Fixed
[ 1
]
|
made changes - 22/Dec/07 01:52 AM
|
Workflow
|
jira
[ 15717
]
|
jira-2007-12-21
[ 23462
]
|
made changes - 23/Dec/07 12:34 AM
|
Workflow
|
jira-2007-12-21
[ 23462
]
|
jira-2007-12-22a
[ 49391
]
|
made changes - 03/Apr/08 07:58 AM
|
Link
|
|
This issue is duplicated by SVC-1994
[ SVC-1994
]
|
made changes - 03/Apr/08 08:01 AM
|
Resolution
|
Fixed
[ 1
]
|
|
|
Status
|
Closed
[ 6
]
|
Reopened
[ 4
]
|
made changes - 06/Apr/08 04:01 PM
|
Link
|
|
This issue Relates to SVC-2098
[ SVC-2098
]
|
made changes - 19/Apr/08 07:35 AM
|
Priority
|
Normal
[ 4
]
|
Major
[ 3
]
|
made changes - 22/May/08 11:11 AM
|
Affects Version/s
|
|
1.21.0 Server
[ 10310
]
|
made changes - 22/May/08 11:12 AM
|
Affects Version/s
|
1.21.0 Server
[ 10310
]
|
|
made changes - 13/Nov/08 12:07 PM
|
Workflow
|
jira-2007-12-22a
[ 49391
]
|
jira-2008-11-14
[ 81622
]
|
made changes - 13/Nov/08 04:35 PM
|
Workflow
|
jira-2008-11-14
[ 81622
]
|
jira-2008-11-14a
[ 88631
]
|
|