[Lou][2.1.14] FluidWagonPrototype base_valve_offset issues

[protocol_1903]

After following up on boskid's advice in 135371, I noticed that base_valve_xy_offset_when_horizontal and base_valve_xy_offset_when_vertical do not function independently. Neither will function properly when the other is nil or set to {0, 0}. This isn't documented, so I assuming it's a bug, probably something to do with this being a 2 tank wagon. I can get away with this for now by setting the other offset to something very small, but it'd be nice not to need that workaround.

Specific valve rendering code, if desired. I've been modifying the mk02-fluid wagon (Advanced fluid wagon) from pYIndustry

Code: Select all

    tank_count = 2,
    valve_to_valve_offset_when_horizontal         = {1.64, 0},
    base_valve_xy_offset_when_horizontal          = {0.1, 0},  -- does not work (can set higher for testing)
    base_valve_z_offset_projected_when_horizontal = -1.55,
    valve_to_valve_offset_when_vertical           = {0, 1.2},
    base_valve_xy_offset_when_vertical            = {0, 0},    -- ???
    base_valve_z_offset_projected_when_vertical   = -1.57,

[PennyJim]

From protocol, since his account isn't working right now: Upon further investigation, it seems that the offsets don't function properly when the opposite axis for the other direction is 0 or nil, i.e. the vertical y offset will not function when the horizontal x offset is 0. I haven't checked but this issue may also be present in valve_to_valve_offset, but wouldn't show up because there's no reason to use the y offset horizontally or the x offset vertically.

[Lou]

Hello and thank you for the report.

Your observation is correct, the _offset_when_horizontal/vertical are not completely independent. In general case, elliptical interpolation is done on the tangential and normal components, basically:

Code: Select all

  double r_tangential = getEllipsesRadius(offsetWhenHorizontal.x, offsetWhenVertical.y);
  offset += ({-sin, cos} * r_tangential );

  double r_normal = getEllipsesRadius(offsetWhenHorizontal.y, offsetWhenVertical.x);
  offset += ({-cos, -sin} *r_normal );

which for non-zero cases evaluates to offsetWhenHorizontal when horizontal (and analogously for vertical). What alerted you to the issue was, that the getEllipsesRadius function returns zero when either of the arguments is zero, regardles of angle. One could argue, that when horziontal, it should retutn the value of the horizontal argument, but this is already a generally undesirable state - when the horizontal argument would be returned, there would be shard jerk to zero when any deviation from the horizontal direction would occur.

So basically the real bug is lacking documentation and allowing mod authors to fall into this trap. I will expand the docs and add a check and throw for this exact case. If you still need to be able to fine tune the cardinal directions without affecting other directions, I can add explicit fields to do that.

Hope this clears things up, sorry for the confusion caused by insuffiscient documentation.

[protocol_1903]

One could argue, that when horziontal, it should retutn the value of the horizontal argument, but this is already a generally undesirable state - when the horizontal argument would be returned, there would be shard jerk to zero when any deviation from the horizontal direction would occur.

I don't understand how it would jerk to zero when a deviation occurs. Ideally, when either parameter is zero the function would work as if the parameter was near-zero, like a mathematical limit interpretation. From my understanding this "jerk" is a misimplementation, not how it's supposed to work.

So basically the real bug is lacking documentation and allowing mod authors to fall into this trap. I will expand the docs and add a check and throw for this exact case. If you still need to be able to fine tune the cardinal directions without affecting other directions, I can add explicit fields to do that.

Hope this clears things up, sorry for the confusion caused by insuffiscient documentation.

Thank you especially for the documentation, it makes things a lot easier to work with. If my previous assumption was wrong and this "jerk" is actually how it maths out, yes some way to tune the cardinal directions without tuning other directions would be appreciated. I'd rather not specify one value as 0.0001 or some such, but it may come down to that.

[Lou]

Ellipsis with one radius =0 and the other !=0 degenerates into a line segment, so only few options for evaluation:
1) zero everywhere (what is currently in game)
2) zero everywhere but in two directions (jerk/jump)
3) don't allow this situation (what I am gonna do)
when you set the other argument near zero, it will still "jump", but continuusly, and closer to 0 you will be the sharper the jump.

The whole reason for this the need to keep the illusion of having 45° projection, while square grid in-game and a rotating entity.

I don't have a solid math proof behind the choice of the ellipses as interpolation, but it fits our current graphics for rotations of the wagons while keeping the rigid body feel for some other values I observed. Furthermore, having offset when_horizontal.x zero but non-zero when_vertical.y would correspond physically to a line segment in the XY plane that would appear 0 in the X orientation and non-zero in the Y, which does not make sense given the restrictions. Same holds for the other degenerate cases. In 3D this can happen, and can be achieved by setting apt base_valve_z_offset_projected_when_horizontal/vertical values. Valves are assumed to be in the same height, so no analogous valve_to_valve_offset z-component should be needed.

If this is not suffiscient for your case, could you share it please?

[protocol_1903]

I'm trying to line up graphics for an entity where the offset is zero when horizontal, but there is a vertical offset in different directions depending on the direction the wagon is facing.

Could perhaps, if the argument is zero, the position is just interpolated along the straight line? Such that it just moves back and forth? I feel like that's what the math should do anyway when one number is very small but it sounds like that's not the case, there must be some snapping happening?

I'm realizing now as I open up the testing again there's other issues with the placement, hm. I don't know if this is going to be strictly necessary for mine but it would be nice to have a solution in case it is.

[Lou]

well, (assuming we are talking tangential direction), that should be achievable setting specific values for the z_offsets when horizontal and when vertical. If that doesn't help, show me, the potential API extention would be dependent what is actually needed.

[Lou]

The checks have been added to 2.1.21.

[protocol_1903]

Thank you!