• Tracker

    Spaces
    Browse
    Statistics
  • /
  • /Stable Feedback
  • /DZG-2614
Back
0

[CE] mapgroupproto proxy with a non-zero third rpy value ignores the parent's yaw and adds it to the item's pitch

BugServerCentral Economy
0

State

Open
Issue key
DZG-2614
Access
Public
Space
DayZ
Project
Stable Feedback
Creator
cflynn_93
Created
Nov 7, 2026
Views
19
Platform
PC Steam
What happened?

Version: DayZ Server 1.30 (PC, Windows), offline CE mission dayzOffline.chernarusplus. Mods: @CF and @VPPAdminTools only. Nothing that touches CE or loot.

A <proxy> inside a <dispatch> in mapgroupproto.xml places its item correctly relative to the parent object only when the third rpy value is exactly 0. With any non-zero third value, even 0.002, the item's rotation no longer follows the parent. The parent's yaw is added to the item's pitch, so the same proxy comes out tilted differently on each parent instance. Proxy positions are unaffected and stay correct.

Expected: each pot sits upright, with its yaw equal to its table's yaw: (45, 0, 0) and (-110, 0, 0).

Actual: with a non-zero third value, each pot's world orientation is roughly (yaw = proxy middle value, pitch = -first value - table yaw, roll ~ third value). It ignores the table's yaw and tilts by it instead. With the third value at exactly 0, both pots are correct.

Measured on two tables, items logged by server script (GetOrientation, WorldToModel):

Proxy rpy -0.002 -0.009 -0.002 (Pot): table yaw 45 -> item ori (-0.011, -44.998, 0.003); table yaw -110 -> (179.986, 69.998, 179.994), i.e. pitch 110

Proxy rpy -90.002 2.174 -0.003 (Mackerel): table yaw 45 -> (2.177, 45.002, 0.004); table yaw -110 -> pitch -159.998

Proxy rpy 0 -0.009 0 (Pot): correct, table-relative for both

Proxy rpy 89.27 -90.97 0 (KitchenKnife): correct for both

Proxy positions were correct to under 1 mm in every case.

Workaround: keep the third rpy value exactly 0. Items that need a real roll, such as a fishing rod lying on its side, can't be posed correctly.

Reproduction steps

In mapgroupproto.xml, add a group for Land_Misc_Table_Large_Spawn with lootmax="0" and one dispatch: <dispatch dechance="1"><proxy type="Pot" pos="0 0.435 0" rpy="0 0 0.01" dechance="1" /></dispatch>

Spawn two of these tables through an event group (cfgeventgroups.xml), one child at a="45" and one at a="250".

Start the server with fresh storage and read each pot's GetOrientation() from script, or look at them in game.

Repeat with rpy="0 0 0".

Exact build version (optional)
1.30.164289
Where did it happen?
Local / Offline
Is it modded?
Yes
Expected result

Each pot sits upright, with its yaw equal to its table's yaw: (45, 0, 0) and (-110, 0, 0), regardless of the third rpy value.

Section
Mod list

@CF and @VPPAdminTools only. Neither touches CE or loot.

Load order / launch params
—
Public attachments1 file · visible to everyone

vanilla_proxy_roll_probe.txt

2.7 KB

Reactions

Activity

    about 16 hours ago
  • cflynn_93
    created issueabout 16 hours ago
  • cflynn_93
    changedabout 16 hours ago
  • cflynn_93
    added tagsBugServer
    +1
    about 16 hours ago
  • okonkwocommented
    about 8 hours ago
    okonkwocommented
    about 8 hours ago

    I usually don't draw upon my vast technical knowledge to comment on tickets here, but I thought I'd dip just a little bit into the vastness for once.

    essentially this is a 400-word lab report on a pot that's a little crooked.

    Your own measurements answer the question: at exactly 0 everything works, and at 0.002° of roll your pot goes full Tony Hawk. That's a float comparison or an Euler-order mixup in the proxy transform, not a mystery. The parent's yaw landing in the child's pitch is what you'd expect from a YPR/RPY convention mismatch. Congratulations on discovering gimbal lock, which has been ruining people's weekends since the Apollo program.

    Two other things:

    1. Your report says angles of -110 and -165 fail "without any RPT warning." Then you note that vanilla only uses 0-360. So you fed the engine out-of-range input and are annoyed it didn't write you a note about it. Your repro even uses a="250", which is -110 with better manners.

    2. You're running CF and VPP, then telling us "nothing touches CE or loot." VPP exists specifically to touch things

    The core issue is probably legit, so I'll leave it open. A fishing rod "lying on its side" is the one pose that needs real roll, and that's where this breaks. Impressive that you found the exact one scenario where physics matters.

    Please retest vanilla with no mods and report back. Bring the pot.

  • cflynn_93commented(edited)
    about 2 hours ago
    cflynn_93commented(edited)
    about 2 hours ago

    Retested on a vanilla server with no mods (DayZ Server 1.30.164289, no -mod parameter, no CF or VPP in the RPT). Same result.

    One Land_Misc_Table_Large_Spawn group with three Pot proxies, identical apart from the third rpy value, spawned on two tables (child a="45" and a="250"). World orientation from GetOrientation():

    rpyTable yaw 45Table yaw −1100 0 0(45, 0, 0), correct(−110, 0, 0), correct0 0 0.01(−0.01, 45.0, −0.01)(179.97, −70.0, −179.97), i.e. pitch 1100 0 10(−9.85, 44.1, −14.0)tilted ≈ 110°

    Positions are correct for all six pots. This isn't gimbal lock: pitch is 0 throughout. A 0.01° change in the third value shouldn't move the pot 45–110°. With a non-zero third value the parent's yaw ends up in the item's pitch, so the bug is in how the proxy rotation is combined with the parent's. It lines up with your "Euler-order mixup in the proxy transform". No physics is involved: these are the orientations the CE sets at spawn.

    Agreed on the negative a values: out-of-range input. I'll drop that part.

    Pot attached.

  • cflynn_93
    changedabout 2 hours ago
  • cflynn_93
    changedabout 2 hours ago

You are not signed in. Please sign in to see more details and to reply.

State

Open
Issue key
DZG-2614
Access
Public
Space
DayZ
Project
Stable Feedback
Creator
cflynn_93
Created
Nov 7, 2026
Views
19