Poly Objects don't move slopes

[Rachael]

So is this a bug that can be fixed in the zdoom code? Or can it be scripted around? Does zcsript have access to the polyobj vertices and normals? Maybe i could just write my own polyobj movement routines to get around this bug?

Unfortunately calling this a bug is a bit of a misnomer. The behavior is correct as coded, even if the end result is not what the user expects. The real issue here is a missing feature that would have allowed to keep the planar information in sync with the polyobject's movement.

[Caligari87]

Polyobjects are just walls. Nothing implies they are infinitely tall.

My bad. I guess it'd be more accurate to say that they typically behave as though they're infinite because in normal use they fill floor-to-ceiling in whatever sector they occupy. But obviously as this thread indicates, there's exceptions.

For what it's worth I would adore canonical 3D polyobjects, even if they can't be sloped. The workarounds I've seen over the years to support equivalent functionality are kinda yikes.

[Sir Robin]

So is this a bug that can be fixed in the zdoom code? Or can it be scripted around? Does zcsript have access to the polyobj vertices and normals? Maybe i could just write my own polyobj movement routines to get around this bug?

Unfortunately calling this a bug is a bit of a misnomer. The behavior is correct as coded, even if the end result is not what the user expects. The real issue here is a missing feature that would have allowed to keep the planar information in sync with the polyobject's movement.

Yes, this is what I've been saying since the beginning. The slope normals are not getting updated while the polyobject is moved. And you're now saying this is an intended behavior. So the answers my first question. My second question was whether the slope normals are exposed to zscript - would it be possible for me to write my own polyobj movement script that would update those slope normals?