Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Pegleg

Trigger lines that don't cross the whole sector?

Recommended Posts

Recently, I have noticed that in some wads I look at in an editor, there are trigger lines that do not fully cross the sector they're in. For instance, there is a corridor that is 64 units wide, but a walkover trigger line is drawn that starts about 8 units from the wall and ends 8 units from the other wall. You can't sneak around the edges of the line, so you will still trigger it. The  front and back of the lindef reference that sector, so the lines are just included in that sector, even though they don't touch any of the walls. The lines are not marked as invisible, but do not show up in the automap.

 

I don't know how widespread this type of construction is or even how long it has been a custom to do. Is there an advantage to making your trigger lines this way? Does it allow you to do something you couldn't otherwise do?

Share this post


Link to post

In areas that push the vanilla engine to the limits, visplanes are a precious thing that you need to keep track of. Every time you split a sector you'll make new visplanes and/or drawsegs, which can potentially lead to crashes. So, from a vanilla perspective, it's because it keeps the limit (somewhat) under control.

 

Please inform me if I'm incorrect.

Share this post


Link to post

It also prevents a player from guessing there is a trigger line there from looking at the automap (i.e if the trigger line connects to the wall, the automap would draw the wall either side of it separately).

 

I had some difficulty writing the above, so hopefully you understand.

Share this post


Link to post
54 minutes ago, NaZa said:

In areas that push the vanilla engine to the limits, visplanes are a precious thing that you need to keep track of. Every time you split a sector you'll make new visplanes and/or drawsegs, which can potentially lead to crashes. So, from a vanilla perspective, it's because it keeps the limit (somewhat) under control.

 

Please inform me if I'm incorrect.

you can merge those sectors and still have line down the middle all the way through (in doom builder the default hotkey for this is J with both selected)

 

the nodebuilder is supposed to discard lines that cut across when making subsectors if they dont have textures on them, it shouldn't affect nodes too much, though i suppose the edges on either side have a vertex in the middle.

Share this post


Link to post
1 hour ago, Pegleg said:

 

I don't know how widespread this type of construction is or even how long it has been a custom to do. Is there an advantage to making your trigger lines this way? Does it allow you to do something you couldn't otherwise do?

I like using those. Poolyash already mentioned lots of reasons why those lines can make life easier when mapping. Another benefit is that these lines don't end up "warping" a sector's shape when the vertices snap to the grid while also connecting to the linedefs that make the sector what it is. Also they make life easier when you're doing the texturing after constructing the geometry that you need for the gameplay.

Share this post


Link to post
1 hour ago, NaZa said:

In areas that push the vanilla engine to the limits, visplanes are a precious thing that you need to keep track of. Every time you split a sector you'll make new visplanes and/or drawsegs, which can potentially lead to crashes. So, from a vanilla perspective, it's because it keeps the limit (somewhat) under control.

 

Please inform me if I'm incorrect.

 

Splitting a sector doesn't create new visplanes if there's no height or light difference between the parts, but splitting a line always creates new drawsegs.

Share this post


Link to post

Actually, not generating segs for lines that have the same sector on both sides is a bit of an optimization when it comes to segs. ZokumBSP can also does such stuff for a few more edge cases, like removing sides facing a wall that is 0 units tall and doesn't have a tag nor is connected to any know linedefs with a special Dx type.

It should however be possible to programmatically "merge" lines split by trigger lines in the node builder IF the texture alignment is correct. That's a pretty problematic one though, since you'd have to know the width of the texture. That is not a trivial question when custom textures are involved. I don't see any point in adding any code for this, just put the vertex 1 unit away from the wall and the problem is gone.

ZokumBSP does have an option for merging split lines in the blockmap. On map01 in Doom 2, this replaces the alternating textures in the main corridor on the map with solid long lines, simplifying collission detection and allowing for bigger maps. This is done in the geometry step, before the blockmap is built.

Share this post


Link to post
6 hours ago, zokum said:

It should however be possible to programmatically "merge" lines split by trigger lines in the node builder IF the texture alignment is correct. That's a pretty problematic one though, since you'd have to know the width of the texture. That is not a trivial question when custom textures are involved.

 

Finding texture width is the biggest problem? Come on, you already have so much fancier features.

Share this post


Link to post

It's actually not a trivial problem. I would have to code something that understands the Doom texture definition entries. And it would also mean that when building a map, you would also have to supply any additional texture wad(s) you are using.

I'm gonna spew a bit of "thoughts" on BSP I have had lately in the ZokumBSP thread. I have a few ideas and pointers on how to improve the build process.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×