Polyobjects that interact with map geometry

[AFADoomer]

What's the feasibility of adding an option for Polyobjects to make them interact with map geometry instead of floating through walls.

For example... In my Wolf3D TC, pushwalls travel 128 units by default... Including if they are next to a wall (0 units of space available), or only have one wolf grid square (64 units) available... They just keep going through the wall until they've moved the full 128 units. So far my attempts at doing collision detection via scripts are failing.

I'm not sure if this is even possible, since I'm not familiar with that part of the code, but it would be useful...

[Minigunner]

Polyobjects need an overhaul IMO.

[Gez]

They have already gotten two massive overhauls, what with being glitch-free now regardless of shape and movement. All the old limitations (only convex shapes, only one polyobject per subsector, polyobject cannot leave subsector) no longer apply.

But I agree that polyobjects able to be stopped by collision with world geometry and/or other polyobjects would be useful.

Maybe a new line flag, "block polyobjects"?

[koverhbarc]

If you change polyobjects they should make them possible to make moving vehicles out of. Actually though it would probably be better to use voxels for that, all you have to do is make objects able to carry other objects!

[AFADoomer]

If you change polyobjects they should make them possible to make moving vehicles out of. Actually though it would probably be better to use voxels for that, all you have to do is make objects able to carry other objects!

Are you trying to get the thread closed without even being considered?

[Z86]

Doesn't roataing polyobjects already collide with geometry? The first swing-door i made out of polyobjects was unopenable due to colliding with the walls (it opened a tiny bit, then closed). Or did i do something else wrong?

EDIT: though normal polyobjects certainly don't do it, there are good examples of that in Hexen.

[NeuralStunner]

Doesn't roataing polyobjects already collide with geometry?

No. Otherwise most swinging objects would not work at all.

[wtg62]

That polyobj incident happens to me all the time. Its because the angle argument tends to screw around and do whatever. Tried Polyobj_Movetospot?
I hated that because it sometimes went off spot. You could still try it. There are variations of it too. This function only works with ZDoom 2.5.0 and above which I'm assuming you have it.

[Nash]

Gonna highjack this thread for a bit... how hard would it be to extend the 3-d floor renderer to handle polyobjects? One thing has always bummed me out is how I can't create true swinging doors in multi-storey constructs that use 3-d floors...

Got around it with animated 3-d model doors but that's not a very elegant solution and will never work with the software renderer.

[Salad Viking]

Gonna highjack this thread for a bit... how hard would it be to extend the 3-d floor renderer to handle polyobjects? One thing has always bummed me out is how I can't create true swinging doors in multi-storey constructs that use 3-d floors...

I wouldn't doubt the possibility of rendering them in GL (it is full 3D, after all), but in software? Just getting 3D floors and non-crappy polyobjects in separately took some doing. And, of course, the physics would probably need loads of work (think about it: you effectively have Build-style polyobjects, only more 3D). We can't even have dynamic slopes because of the physics!

Now, don't count on my thoughts to be accurate; the devs will soon answer you. But I think that your suggestion suffers from an acute case of "too goddamn good to be true".

[Xaser]

I've actually seen a wad that managed to hack a non-infinite-height polyobject (with a floor n' everything) once, but it wasn't perfect and was a big hack either way. The biggest issue I remember was that the floor did not move along with the 'sector', which is currently a given considering the way flats work (unless explicit scrolling specials are used). I don't completely doubt that someone could attempt a similar hack with 3D floors, but I don't expect it would look or work pretty.

[Nash]

Well how about it being a GL-only feature then? There was a time when it was accepted that there are things GZDoom can do that ZDoom just couldn't. This is directed to Graf Zahl.

[Gez]

There was also a time before Graf got fed up with working on OpenGL stuff.

[Salad Viking]

Well how about it being a GL-only feature then? There was a time when it was accepted that there are things GZDoom can do that ZDoom just couldn't. This is directed to Graf Zahl.

As I said, rendering it in GL probably wouldn't be an obstacle. It's the physics and behavioral code that are the real showstoppers. Also, the automap code.

And, as Gez said, Graf Zahl isn't too hot on doing any work with the GL renderer, so I'd say your chances are next to nil.

[Gilles]

I'm working on the code which allow Polyobjects to interact with map geometry for almost 2 days, I have already done 80% of combinations, but now I'm stuck because I can't figure out how to determine whether or not an object (with a given tid) is outside the map. If anyone has a solution don't hesitate.