Wall portals

[Graf Zahl]

I just want to note that the hang was not caused by their one-sidedness, it's just bad style and invitation for problems.

[Major Cooke]

I had a feeling that'd be the case, thus I made no mention of it causing a crash or anything.

I did notice a problem on Happy Time Circus 2 when I modified one of the linedefs that toggles its texture off and disables blocking. I changed it to become single sided. It caused some weird HOM effects here and there, so I stopped that by changing it back to double sided and that fixed it (this was way back last year (It was my fault, not Shtbag's)). I take it that's one of the problems?

[Gez]

How should I go to try to reimplement the 1-6 switching portal from the demo map? The portal line that doesn't change works well enough, but the lines in front of the 1, 2, 3, 4, 5, 6 spots do not. Using SetLineSpecial(id, 0, 0, ...) on them does not clear the portal, and naturally a new portal cannot be created there.

[Graf Zahl]

You have to define a portal there and immediately deactivate it by setting the destination to 0.
The portal system needs to know up front which lines are portals to create all the necessary data structures.

[Major Cooke]

Oh, so the lines need defining from the start. Can they simply have no target as well or does a script need to deactivate them on start?

[Gez]

setting the destination to 0

How? Line_SetPortalTarget(id, 0) crashes with an access violation.

[Graf Zahl]

Oh, so the lines need defining from the start. Can they simply have no target as well or does a script need to deactivate them on start?

Sure they can have no target.

The crash must be recent. This was working when I implemented it.

[Gez]

Is there a reason why ZDoom portal types are set up like this:
Line_SetPortal (targetline, thisline, type, planeanchor)
But Eternity linked portals are set up like that:
Line_SetPortal (which, targetline, type)

To me it'd make more sense to switch the first two parameters around for the EE type, so that the first parameter is always the line ID of the target line, regardless of type, and it's the second parameter, the one that doesn't even have a purpose in UDMF, that's set to either 0 or 1.

[Graf Zahl]

The second parameter in the Eternity method is still 'thisline'. The Eternity type requires linking between two lines with the same line ID which makes it very awkward overall. It's actually Line_SetPortal(which, thisline, 4), and in UDMF the second paramter must be 0 and the line ID field used.

[Major Cooke]

Is there a way to apply a portal to only the top or bottom texture?

[Gez]

Yeah, make both sides of the portal not have the same height, and use the plane align parameter.


I've also found out that the plane align parameter is necessary to prevent glitches when there is a Z offset, even if the heights are identical on both sides.

[Major Cooke]

I'll give it a shot but could you upload a test wad just to make sure I am getting what you're saying? I'm not sure about the plane align part truthfully. A demonstration wad would probably explain it more easily.

[Graf Zahl]

No idea what Gez was saying, but no. Portals cannot be put on upper and lower parts. In ZDoom they always cover the entire wall and in GZDoom only the middle part. Remember, they need to be crossable and only a middle part allows that.

[Major Cooke]

I was hoping to not have to make the 3D floors of a tunnel entrance. And I'm guessing that making a parameter or property for a top or bottom line to view out of another line with a specific offset is out of the question then.

That's what I'm basically trying to accomplish here in these screenshots.

On the playable side, the top linedef would view from the middle linedef of the non-playable side.

---

On the playable side:


On the non-playable side:

[Tormentor667]

No idea what Gez was saying, but no. Portals cannot be put on upper and lower parts. In ZDoom they always cover the entire wall and in GZDoom only the middle part. Remember, they need to be crossable and only a middle part allows that.

Would it be possible to make the portal height definable? For example having a middle texture of 128 floating in sector with a karger height but only the 128 height Shows the portal.