Sign in to follow this  
Followers 0

2s linedef question

my build .map -> doom .wad level converter (currently being coded, should be a beta out this weekend), arbitrarily sets the orientation of 2sided linedefs such that the first side is the lower number sidedef (because build has no concept that equates to linedef orienation). i know that other than teleporters and switches, a 2 sided linedef can be switched either way with theoretically no effect. (and in these cases the user would have to manually flip those linedefs after conversion).

however, i remember someone mentioning that in practice, its good to face 2s linedefs in a certian direction, better for nodebuilding or something. what is that orientation, so i can code it into my map2wad?

Share this post


Link to post

*bump*

I also have another question. I followed dmspec16.txt 100% in my formatting of the .wad file output from my map2wad, as far as i know. here is a wad the program outputted (3KB). nwtpro, deepsea, and deth crap out over it; xwe and wintex display it fine. If you are knowledgable with the doom .wad format and have a hexeditor, could you tell me where my formatting error lies? thanks.

http://home.adelphia.net/~mainlimits/newboard.wad

the .wad should be a standard doom wad containing only MAP01.

Share this post


Link to post

oblivion said:
however, i remember someone mentioning that in practice, its good to face 2s linedefs in a certian direction, better for nodebuilding or something. what is that orientation, so i can code it into my map2wad?


I can't think of any particular reason other than those you mentioned. Essentially, for rendering purposes almost everything depends on sidedefs & segs, and the orientation of the line makes no difference to those. So I don't think node builders will care about the orientation (excluding bugs - I know BSP v2.3 had a bug where it got linedef orientation wrong sometimes).

The only things the orientation of a 2S linedef should affect are properties of the linedef itself, i.e. only the trigger properties (switches & teleports as you say) and the order in which it refers to the sidedefs. If someone can thing of another reason then speak up...

Share this post


Link to post

It was me that mentioned it, and it's not to do with nodebuilding.

If the front sidedef is facing away from the sector with the lower floor, you sometimes get an 'invisible block' bug. You can walk on the block (height is equal to the higher sector the front sidedef is facing). I've seen this in wads before (inc. Eternity map 6) and have come across it when building my own levels.

The way to stop it is to make sure that all front sidedefs face the sector with the lower floor. (except in a few rare cases)

The only trigger type which is dependent on which way the linedef points is teleporters, (it must be the front sidedef) the rest are independent of orientation.

Share this post


Link to post
oblivion said:

I also have another question. I followed dmspec16.txt 100% in my formatting of the .wad file output from my map2wad, as far as i know.

IIRC that spec is a tad off vs the actual layout:

MAPxx or ExMx
THINGS
LINEDEFS
SIDEDEFS
VERTEXES
SEGS
SSECTORS
NODES
SECTORS
REJECT
BLOCKMAP

Slige made a similar mistake. I took care of that one, but your's slipped by. Is fixed in 11.65. I'd put the missing lumps in at -0- lengths to be safer.

Mostly a safety checking issue since BEHAVIOR (HEXEN) and GL_ (GLBSP nodes) are also lumps that can be in there.

If you notice the DeePsea Previewer didn't care:)

Share this post


Link to post

One more thing - join the vertices that overlap. IOW, right now the lines do not connect properly. Run a scan on the linedefs and find vertices with the same coordinates...

Share this post


Link to post

ok, i'll add the other lumps as 0 length. i wasnt sure whether or not to because my program is not a nodebuilder.

as for the vertexes, i am aware of that problem, haven't corrected it yet.

Share this post


Link to post
This topic is now closed to further replies.
Sign in to follow this  
Followers 0