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:
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.
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]
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.
… 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.