---

printz said:
Ugly may be, but it could have been used to create togglable Impassable linedefs, particularly grates, which for now are only permanent blockers.

Eternity has the 3dMidTex option, but it makes the affected linedefs block the projectiles as well as the actors.

---

---

fraggle said:
apparently intended for use in the Doom II Wolf3D levels

---

---

Inferno said:
Even weapons pass through it, lol.

---

---

geekmarine said:
Any chance of de-bugifying it and having it be fully functional (and not hideous)?

---

---

LogicDeLuxe said:
But if we want to overcome Vanilla Doom's functionality in serious mapping, we just use PolyObjects, don't we?

---

---

fraggle said:
A Chocolate Doom patch that re-enables the code

---

---

printz said:
I`m sorry, but ain`t Choco-Doom supposed to emulate vanilla Doom, not enhance it with map features? Next time we may see plain Doom wads actually requiring the port.

Post typed from a PSP.

---

---

myk said:

That depends on the nature of the project, as the polyobjects code as seen in Hexen isn't free software.

---

---

Quasar said:
Personally I don't think PolyObjects would work if you intended to use these things for every door in your map. For one thing, without an extension such as ExtraData, you are limited to 255 PolyObjects per map, due to the inability to address any more than that via the args to Hexen linedef specials and the angle field of mapthings. For another, the more PolyObjects you put in a map, the more likely you are to have trouble with overdraw errors and nodes getting split where you need square subsectors. Finally, the way PolyObjects are created is kind of annoying; requires a lot of extra, careful mapping work.

So with those things in mind, I don't think an extra way to do cheap, light-weight sliding doors would be out of line. I had considered resurrecting this code myself back when it was first (re)discovered, but I don't really have a solution for partial clipping, so that you could pass through the door as soon as it is open wide enough, and not either be required to wait until it is fully open, or be able to pass through it as soon as it is open even a crack. 3DMidTex do not solve this problem either, since they clip on a per-line basis and not a per-column basis.

---

---

Quasar said:
For another, the more PolyObjects you put in a map, the more likely you are to have trouble with overdraw errors and nodes getting split where you need square subsectors. Finally, the way PolyObjects are created is kind of annoying; requires a lot of extra, careful mapping work.

---

---

Graf Zahl said:
That's where polyobject-aware node builders come in.

---

---

deathbringer said:
You could make a crude emulation of a side-opening (not closing again) door using several instant-lower sectors. The advantage is it would be "3D", the disadvantage is it'd look more like the door was progressively dissapearing than 'opening'. Though it could work with more plain textures or if you see the actual opening from a long distance.
Using that method "swinging" doors work better, there's some in Eternal 3

---

---

printz said:
Are there any for Eternity, as long as it uses the Doom format?

---

---

TheDarkArchon said:


Nodes are independant of the map format so ZDBSP and DeePSeas BSP(?) should be able to handle it.

---

---

printz said:
Fortunately EE uses the same doomednums for the polyobj things, so if the BSP prog doesn't care about map format, all's fine. It will be less fine if EE polyobjs are addressed through ExtraData control objects.

---