View Issue Details

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

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:

addCommandHandler("test",
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(),
    function(deltaT)
        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
        end

        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)
        end
        local width, height = guiGetScreenSize()
        dxDrawText(text, 0, 0, width, height, tocolor(255, 0, 0, 255), 1.5,  "clear", "center", "top")
    end
)

end
)

Additional Information

See video: http://www.youtube.com/watch?v=_xUO6U8Cyno 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.

Activities

Kayl

2010-11-05 14:21

developer   ~~0012112

I have posted a fix on http://forum.mtasa.com/viewtopic.php?f=91&t=29888
Video: http://www.youtube.com/watch?v=cg_swiBrJ4A

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).

Kayl

2010-11-06 18:56

developer   ~~0012117

Updated the fix: http://forum.mtasa.com/viewtopic.php?p=326214#p326214

Actual rotation order is:

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

ryden

2010-11-06 19:02

manager   ~~0012118

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

Kayl

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.

Kayl

2010-11-08 18:17

developer   ~~0012132

Posted a patch proposal (to be discussed on forum though):
http://dkrclan.com/qttolua_data/eulerPatch.patch

Uploaded test code too:
http://forum.mtasa.com/viewtopic.php?p=326489#p326489

Kayl

2010-11-08 21:59

developer   ~~0012133

Posted new patch with both clientside and serveerside version:
http://dkrclan.com/qttolua_data/eulerPatchFull.patch

Added serverside test code too:
http://forum.mtasa.com/viewtopic.php?p=326503#p326503

Kayl

2010-11-09 10:26

developer   ~~0012136

Fixed in 1.1 by r2067

Issue History

Date Modified Username Field Change