This is actually not the real bug, the reason it increments is that the code above was commented out, Thus causing the function to increment each time.

The code above was supposed to reset the member variable storing the rotations with the real rotation of the object itself and therefore stop it incrementing.

to sum up what I have just posted:
"getObjectRotation" should not be returning relative positions in the first place, It should be returning the actual rotation which has caused this bug.

Edit:
The problem is in the server - deathmatch project
CObject.cpp
line 193

I see, in CObject.cpp

if ( m_pAttachedTo )
{
    // TODO: fix this
    //m_vecRotation = m_pAttachedTo->GetRotation ();
    m_vecRotation += m_vecAttachedRotation;
}

but the real fix is at CElement

Actually CElement doesnt have Get/SetRotation functions, so you cant know if the function exists in m_pAttachedTo, thats why that code is commented out. As a fast fix [Get/Set]Roration virtual funtions should be added to CElement.

Current CElement::[Get/Set]Position doesnt check if element is attached, and most of attachable Elements need this. Non attachable Elements will evaluate if(m_pAttachedTo) => false

CElement.h

const CVector&              GetPosition             ( void );
void                        SetPosition             ( const CVector& vecPosition );

const CVector&              GetRotation             ( void );
void                        SetRotation             ( const CVector& vecRotatation );

CElement.cpp

const CVector& CElement::GetPosition ( void )
{
// Are we attached to something?
if ( m_pAttachedTo )
{
m_vecPosition = m_pAttachedTo->GetPosition () + m_vecAttachedPosition;
}

return m_vecPosition;

}

void CElement::SetPosition ( const CVector& vecPosition )
{
// If we're attached to something, dont change anything (attachment takes priority over moving here)
if ( m_pAttachedTo ) return;

// Different position?
if ( m_vecPosition != vecPosition )
{
    // Update our vectors
    m_vecLastPosition = m_vecPosition;
    m_vecPosition = vecPosition;
}

}

const CVector& CElement::GetRotation ( void )
{
// Are we attached to something?
if ( m_pAttachedTo )
{
m_vecPosition = m_pAttachedTo->GetRotation () + m_vecAttachedRotation;
}

return m_vecRotation;

}

void CElement::SetRotation ( const CVector& vecRotation )
{
// If we're attached to something, dont change anything (attachment takes priority over moving here)
if ( m_pAttachedTo ) return;

// Different rotation?
if ( m_vecRotation != vecRotation )
{
    // Set the new rotation
    m_vecRotation = vecRotation;
    //last rotation ??
}

}

this should work

Another related issue is this, in CPed (and derived class CPlayer)

inline float    GetRotation ( void )    { return m_fRotation; }
inline void     SetRotation ( float fRotation ) { m_fRotation = fRotation; }

If you attach something to a ped, the above GetRotation would fail
When Ped rotation changes, m_vecRotation doesnt

void CPed::SetRotation ( float fRotation )
{
// If we're attached to something, dont change anything (attachment takes priority over moving here)
if ( m_pAttachedTo ) return;

// Set the new rotation
m_fRotation = fRotation;
m_vecRotation.fZ= fRotation; 

}

m_vecRotation is not initialized in CPed constructor it should be initialized to 0 0 0

Linker should choose the correct GetRotation here:
m_vecPosition = m_pAttachedTo->GetRotation () + m_vecAttachedRotation;

When a ped is attached to an Element it rotates in X Y axes correctly but not
Z coordinate. I think in client Z coordinate is forced to this single fRotation

"Actually CElement doesnt have Get/SetRotation functions, so you cant know if the function exists in m_pAttachedTo, thats why that code is commented out."

Hence why it isn't fixed yet if it was a simple job of un-commenting that line.