Walls to block Polyobject?

[SPV999]

Scripting in the latest version of ZDoom.
On player activation, I have a set of polyobject pillars that I want to go crazy (by which I mean random generators). However, after a few seconds they all wonder outside the level and disappear.

Is there a way to check if a polyobject has gone through a wall and prevent it or teleport it back in?

Thanks.

[gemini09]

Please elaborate :)

Do they rotate, or something?

If so, they need to rotate inside a sector that matches the dimensions of the sector where it appears in-game, if I'm not mistaken.

[Quasar]

In short, no. The DOOM engine cannot easily recognize valid space vs invalid space. You COULD test for intersections between polyobject lines and static linedefs, in a way similar to the dynaseg split process. However this would be a very costly operation to do every frame, and the question of *what* the engine is supposed to do when it detects a collision is not simply answered.

[SPV999]

That's what I figured. I know polyobjects arent subject to the normal rules, and didnt know if there was some catch built in to account for this (a special linedef setting or something). Oh well.

[Gez]

It'd be great if there was a way to detect polyobject collisions with geometry or other polyobjects; it'd allow to replicate the Wolf 3D push walls nicely. And even do crazy stuff like Sokoban!

[EarthQuake]

You need to keep track of where the polyobjects are, and define where the polyobjects are allowed to go, so they don't move into walls or polyobjects. If the desired direction would result in overlapping, pick a new direction or wait until that space is clear. Since you can't directly check their location, but you DO know where they start and how far they move each time, this is definitely doable (assuming we're talking about "sliding" polyobjects and not rotating ones).

Basically you'd need two sets of "collision code", one for fixed walls to keep the polyobjects within bounds, and one for other polyobjects. In the latter "collision script", each polyobject would have its own set of variables so that it could be compared to other polyobjects. In this sort of situation, you want to prevent collision from happening, not actively do something about it.

However, this is some tricky stuff... the more irregular the "bounds" of the spawn area are, and the more polyobjects you have, and the more complex the polyobjects are, the more complex the script can get.

Can you maybe post a screenshot of the polyobjects and the area where they "spawn", and then describe how you've envisioned their movement in said space?

Oh, and if you want to avoid hardcoding any numbers into the script (like wall or initial polyobject positions), you can use mapspots and check against those instead.

[printz]

Quasar said:

In short, no. The DOOM engine cannot easily recognize valid space vs invalid space. You COULD test for intersections between polyobject lines and static linedefs, in a way similar to the dynaseg split process. However this would be a very costly operation to do every frame, and the question of *what* the engine is supposed to do when it detects a collision is not simply answered.

What about... trying to link square polyobjects to solid map objects? Solid map objects can collide. How do one-sided one-sidedef passable linedefs act? Do they block bullets and monster lines of sight? Do they work on polyobjects? Can you overlap such polyobjects over solid objects?

[Quasar]

printz said:

What about... trying to link square polyobjects to solid map objects? Solid map objects can collide. How do one-sided one-sidedef passable linedefs act? Do they block bullets and monster lines of sight? Do they work on polyobjects? Can you overlap such polyobjects over solid objects?

The problem is the map object would have to have a slightly wider radius than the polyobject so that you could reject any polyobject move on the basis of a P_CheckPosition failure by the attached mobj.

Such an approach MIGHT be doable in ZDoom but it is not, currently, in Eternity, because of the limitations of the blockmap with respect to mobj clipping and large radii.