* Fixes the attachment scripted rotation bug. The problem is the code was relying on m_host.ParentId = 0 to determine if the attachment should be rotated against root prim offset. To fix it for attachments, we also need to check if the host's localID == RootPart's localID. otherwise we are cumulatively rotating against the host's root part rotation offset (which in this case, is it's own rotation)

avinationmerge
teravus 2013-01-01 23:07:37 -05:00
parent ce4b09cf63
commit 397aa74777
1 changed files with 11 additions and 2 deletions

View File

@ -2353,8 +2353,17 @@ namespace OpenSim.Region.ScriptEngine.Shared.Api
{
m_host.AddScriptLPS(1);
SceneObjectPart rootPart = m_host.ParentGroup.RootPart;
// Teravus: if (m_host.ParentID == 0) is bug code because the ParentID for the Avatar will cause this to be nonzero for root prim attachments
// which is then treated like a child prim rotation and it's offset gets cumulatively multiplied against.
// to fix the scripted rotations we also have to check to see if the root part localid is the same as the host's localid.
// RootPart != null should shortcircuit
// try to let this work as in SL...
if (m_host.ParentID == 0)
if (m_host.ParentID == 0 ) //|| (rootPart != null && m_host.LocalId == rootPart.LocalId))
{
// special case: If we are root, rotate complete SOG to new rotation
SetRot(m_host, rot);
@ -2362,7 +2371,7 @@ namespace OpenSim.Region.ScriptEngine.Shared.Api
else
{
// we are a child. The rotation values will be set to the one of root modified by rot, as in SL. Don't ask.
SceneObjectPart rootPart = m_host.ParentGroup.RootPart;
if (rootPart != null) // better safe than sorry
{
SetRot(m_host, rootPart.RotationOffset * (Quaternion)rot);