GetEntityRotation server/client mismatch

Server

Operating system: Windows 20H2 and Debian/Linux
Artifact version: 3553 (and 3546, maybe others too)
IP address: localhost
Resources: repo-resource (JS)
Onesync: on

Incident

Summary:
On the client, GetEntityRotation works fine and seems to return the real rotation (yaw, pitch, roll) for objects/vehicles/peds. With onesync enabled, the server returns the correct rotation for peds/vehicles, but not for objects. Additionally, an object spawned by the server is spawned in a completely wired rotation. Objects spawned by the client are always in a all-zero rotation vector.

Steps to reproduce:

  1. Create two objects, one server-side and one client-side. The objects will spawn at the peds location and the NetworkId will show up.
    1.1. spawnobjectserver prop_tyre_wall_03
    1.2. spawnobjectclient prop_tyre_wall_03
    As you can now see, two objects spawned but in completely different rotations.
  2. Get the NetworkId of the server-sided spawned object.
    2.1 rotationserver <networkId> returns the following: [14, -140, -140]
    2.2 rotationclient <networkId> returns the following: [-180, 90, 180]
  3. Get the NetworkId of the client-sided spawned object.
    3.1 rotationserver <networkId> returns the following: [-54, -148, -32]
    3.2 rotationclient <networkId> returns the following: [0, 0, 0]

As you can see, the client always gives a rotation vector, which seems more correct than what the server returns and it only seems to affect objects, not vehicles/peds.

Files for repro (if any):
rotationtest.zip (1.9 KB)

Ugh. Could be glm quaternions don’t match what GTA/XnaMath does:

1 Like

… oh, objects have their own orientation node, which might not be handled.

Actually, ahuh, server-side sync tree claims it’s CEntityOrientationDataNode but clients use a different node. That’d explain a bit: off-by-N writes and likely corruption of later nodes.

Should be fixed as of 701215ae18b4eb28faf1cbe3b28e66f0553f0c56:

2 Likes