View Issue Details

IDProjectCategoryView StatusLast Update
0005631Multi Theft Auto : San AndreasClientpublic2010-11-09 11:07
ReporterKayl Assigned ToKayl  
Status resolvedResolutionfixed 
Target Version1.1Fixed in Version1.1 
Summary0005631: Inconsistency of setElementRotation/getElementRotation/getElementMatrix

Depending on the type of element setElementRotation doesn't do the same thing (cf example).
Furthermore, getElementRotation, depending on the element type, doesn't always return the expected value.
And finally, getElementMatrix, when transformed back to Euler angles, also gives different values depending on the type.

It would be good if either this inconsistency could be explained (to find temporary workarounds) and then fixed.
Playing with matrices and rotation angles when considering the relative positioning of elements of several types is currently a nightmare since semantically the rotations don't have the same meaning.

Steps To Reproduce

Clientside code:

function ()
local x, y, z = -1375.1043701172, -25.0885887146, (14.1484375 + 5)
local elements = {}
elements[1] = {createPed(0, x, y, z ), 0}
elements[2] = {createVehicle(520, x, y, z), 10}
elements[3] = {createObject(1632, x, y, z), -10}

local rx, ry, rz = 0, 0, 0
local totalTime = 0
local rotationTime = 5
addEventHandler("onClientPreRender", getRootElement(),
        totalTime = totalTime + deltaT
        if totalTime > 5*rotationTime*1000 then
            totalTime = 0
        elseif totalTime > 4*rotationTime*1000 then
            rx = rx + 360/rotationTime*deltaT/1000
            ry = ry + 360/rotationTime*deltaT/1000
            rz = rz + 360/rotationTime*deltaT/1000
        elseif totalTime > 3*rotationTime*1000 then
            rz = rz + 360/rotationTime*deltaT/1000
            rx, ry = 0, 0
        elseif totalTime > 2*rotationTime*1000 then
            ry = ry + 360/rotationTime*deltaT/1000
            rx, rz = 0, 0
        elseif totalTime > 1*rotationTime*1000 then
            rx = rx + 360/rotationTime*deltaT/1000
            ry, rz = 0, 0

        local text = nil
        for _, data in ipairs(elements) do
            local element = data[1]

            local erx, ery, erz = getElementRotation(element)
            text = ((text and text.."\n") or "")..string.format("%s %f %f %f ", getElementType(element), erx, ery, erz)

            local deltaX = data[2]
            local rotMult = data[3]
            setElementPosition(element, x+deltaX, y, z)
            setElementRotation(element, rx, ry, rz)
            setElementVelocity(element, 0, 0, 0)
        local width, height = guiGetScreenSize()
        dxDrawText(text, 0, 0, width, height, tocolor(255, 0, 0, 255), 1.5,  "clear", "center", "top")


Additional Information

See video: for an illustrated example.

  • When doing rotations on one axis at a time, ped turns in the wrong direction.
  • When doing rotations on all axis, the rotations don't match: no element type does the same thing as the other element types.
TagsNo tags attached.



2010-11-05 14:21

developer   ~~0012112

I have posted a fix on

Basically, the problem is just rotation order when using the Euler angles provided.
Vehicles are XYZ, peds are -X-Y-Z, and objects are YXZ.
So I posted in the topic a lua based patch that creates the expected unified versions of setElementRotation and getElementRotation. It also provides an extra parameter allowing the user to specify if they want those rotations to make mathematical sense (0 of rotation on Z pointing at +X hence East, not North).


2010-11-06 18:56

developer   ~~0012117

Updated the fix:

Actual rotation order is:

  • objects: ZXY
  • vehicles: ZYX
  • peds: -Z-Y-X


2010-11-06 19:02

manager   ~~0012118

Changing that convention would cause lots of scripts to stop working properly.


2010-11-06 19:05

developer   ~~0012119

Last edited: 2010-11-06 19:20

That's why I now don't rename the set/get functions anymore but provide functions with the _Euler[ORDER] suffix.
This is more an information related bug report now. No real need for fixing.
You can close it if you want.


2010-11-08 18:17

developer   ~~0012132

Posted a patch proposal (to be discussed on forum though):

Uploaded test code too:


2010-11-08 21:59

developer   ~~0012133

Posted new patch with both clientside and serveerside version:

Added serverside test code too:


2010-11-09 10:26

developer   ~~0012136

Fixed in 1.1 by r2067

Issue History

Date Modified Username Field Change