1-sided linedefs with only a back sidedef

In a recent build of GZDB MaxED fixed bugs in my plugins that assuemd that a 1-sided linedef only has a front side, but not a back side. I always assumed that's a given.

But that doesn't seem to be completely true. Linedefs with only a back sidedef and no front sidedef seem to work fine in PrBoom+, Eternity and ZDoom. GZDoom has a small rendering issue (thin seam of HOM between the wall and the floor). On the other hand Chocolate Doom just quits without any message whatsoever.

The Linedef entry in the Doom Wiki seems to indicate that constructs like this are indeed valid - the footnote in the Linedef structure section says that the front (right) sidedef can be -1.

Is there any consensus in the community if this is ok or not ok?

[edit] To clarify: I mean that the formal sector strucutre stays intact, i.e. a 1-sided linedef that points away from the sector's interior has only a back sidedef.

Hiya!

Uh...why? A square room with all the 4 linedefs front facing out and the back facing into the sector...again...why? If there's some cool trick or something that needs this, that's one thing, but otherwise I can't think of a reason.

^_^

Paul L. Ming

I'm not aware that there is any point in doing it. That's why the question in the GZDB thread came up if those constructs should be actively prevented.

some old topic https://www.doomworld.com/vb/doom-editing/67558-question-on-one-sided-linedefs/
edit: or nevermind, that's a different question I guess

I've disable them under default settings, but leave an option to enable them from Game Configurations or Preferences or whatever, and label the option with a warning that such lines would crash most non-advanced ports.

The original Doom source code actually has an assumption that lines have a front sidedef. So making lines that break this assumption can cause undesirable behavior - for instance, Chocolate Doom just crashes. Oddly enough, doom2.exe continues working if it encounters linedefs with no front sidedef, but other weird subtle bugs creep up instead.

There might be some tricks you can do with not having a front sidedef on a line, but I can't imagine any downsides to an editor assuming that a 1S line should face in the direction so that its only sidedef is on the front and not the back.

It is an illegal construct which causes undefined behavior in the vanilla engine. Modern ports "tolerate" it by "correcting" the line to have a first side, by aliasing it to another arbitrary sidedef (usually sides[0]) in the map. This is undesirable and editor utilities should flag and report it as an error, and not allow trying to exploit it as a feature.