Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Never_Again

Set "lower unpegged" for doortraks automatically

Recommended Posts

Not setting the "lower unpegged" flag for the door jambs and such is one of the most common mapping errors. The sight of doortraks sliding up and down along with their doors plagues even some high-profile projects like Mini-level Megawad and Armadosia, not just beginners' WADs.

Wouldn't it be great to have a util that would scan a WAD file and set this flag on doortraks automatically? Something that would do just that and, unlike DoomBuilder, touch nothing else.

Share this post


Link to post

It surely would. Such a utility would need to detect sectors that can be (directly or remotely) opened by a door action, and lower-unpeg 1-sided linedefs connected to these sectors. I can see it to be possible, shamely I can't code anything to cooperate with a wad structure or an editor. From the mapper's perspective, the rare cases of doors intentionally not being unpegged could be easily corrected by hand.

Share this post


Link to post

Pretty sure something like that was in DB2 as well. I remember asking for it some time ago because DeePSea has also had it for many years.

I'm not sure about the DB2 version but, in DeePSea, selecting a suitable sector and picking "Make Door from Sector" lowers the ceiling to the floor, turns the lines if they are facing the wrong way, makes them a door type (with suitable activation type and line parameters in Hexen format), puts DOORTRAK on the tracks and unpegs them, puts BIGDOOR2 on the door fronts and FLAT20 on the ceiling (textures are configurable). I mentioned all of that to CodeImp when I asked if something similar could be in DB2 so it's likely that some, if not all of that made it in and, if so, got carried forward to GZDB.

Share this post


Link to post

Wadauthor has a make door tool too. I never thought I'd see myself using something so trivial but it does speed things up sometimes and reduce the chances of error.

I'm not sure if the plugin in GZDB allows you to specify the line action though, so if you want a fast door or a door that needs a key you'll have to edit it yourself manually.

Share this post


Link to post

It's no plugin, it's a built-in functionality in both DB2 and GZDB. The default hotkey it Shift-D, GZDB also has a menu entry (when in sectors mode in the Sectors menu).

Share this post


Link to post

NERD MODE ON I don't like how you call this design decision a mapping error. NERD MODE OFF

Share this post


Link to post

I would say that it is probably usually either an error or the result of an inexperienced mapper not knowing what to do.

I acknowledge that there are occasions when moving door tracks are there by design though.


40oz said:

I'm not sure if the plugin in GZDB allows you to specify the line action though, so if you want a fast door or a door that needs a key you'll have to edit it yourself manually.


Same with the DeePsea version. If you want something other than what you have set the defaults for, you will have to edit things further. Even then, I find it helpful that the tool has set up a good working door that I merely have to tweak rather than have to remember all the various features of a good looking and working door and add them manually from scratch myself.

Share this post


Link to post

One and a half useful replies out of seven. That's an abysmal signal-to-noise ratio.

scifista42 said:

It surely would. Such a utility would need to detect sectors that can be (directly or remotely) opened by a door action, and lower-unpeg 1-sided linedefs connected to these sectors.

Thank you for putting it into a nutshell, scifista42. Add another condition (the sector's ceiling height == floor height) to it and I think we have a viable detection algorithm.

Share this post


Link to post
Never_Again said:

One and a half useful replies out of seven. That's an abysmal signal-to-noise ratio.

Thank you for putting it into a nutshell, scifista42. Add another condition (the sector's ceiling height == floor height) to it and I think we have a viable detection algorithm.



Why are you still acting as if there is nothing to construct a door for you.
As Boris told you, a Make Door feature is already build into the editor.



Highlight a sector and invoke the shortcut and presto, the sector is now a door with simple activation special.
Ceiling height is at floor height and the sides are lower unpegged.
How much easier can it get.

Share this post


Link to post
Never_Again said:

One and a half useful replies out of seven. That's an abysmal signal-to-noise ratio.

Really? You had your answer almost immediately. Most of the discussion is on-topic and scifista42's comment, whilst a valuable part of the discussion, is certainly no more useful than the one that actually gave you the answer.

So, to be clear, when you are making a door, use the door making tool and it will do the job for you.

Extra tip:
If you are trying to fix a map where you think you may have missed an unpegging, use the find feature to find all lines with the texture that you have been using for your door tracks (probably DOORTRAK) and then step through the results line by line with the arrow keys keeping an eye on the information panel. When you see one that doesn't say Unpegged Lower, have a closer look at it in the editor to see if you actually want to change it. I've done it loads of times. It really doesn't take long. No special analysis tool for finding doors required.



If you have been using a number of different textures for your door tracks, you might want to search for something else, like door line types. However, that will take a bit longer because the editor will jump to the door front lines rather than the tracks so you will have to move the mouse around and select the tracks for each door separately. Even then, and even on a big map, it doesn't take that long.

[edit] I'm not sure that DB2 shows the flags in the bottom right like GZDB does but it certainly has the information on the bottom left. [/edit]

Share this post


Link to post
Kappes Buur said:

Why are you still acting as if there is nothing to construct a door for you.

Because I'm not looking to construct a door, maybe? :D
Seriously, thank you for trying to help, Kappy, but this is not what this thread is about.

Enjay said:

Really? You had your answer almost immediately. Most of the discussion is on-topic and scifista42's comment, whilst a valuable part of the discussion, is certainly no more useful than the one that actually gave you the answer.

Please read the second paragraph of the first post. You may see that scifista42's post is the only reply that addresses the issue directly. Rather amusing, that, if you take into account that English is not his first language. Perhaps I didn't word the first post clearly enough. I'll try and rectify that below.

Enjay said:

So, to be clear, when you are making a door,

I am not making a door. ;)
This is not about making doors or maps. This is about taking extant WADs going back as far as 1994 and fixing them in bulk, automatically. We are talking hundreds of WADs here, so doing it with a map editor is out of question. Much less an editor that does stuff like removing unused sectors upon load without prompting the user or offering an option to disable such behavior. I specifically mentioned DoomBuilder by name in the first post to avoid going down a road that ends in a dead-end.

Share this post


Link to post

It's easy to understand why no one thought that you're talking about fixing other people's wads in bulk.

1. You didn't say it directly.
2. It's a bad idea, because sometimes it's a design decision, and you can't tell unless you look into each wad yourself.

Share this post


Link to post
Never_Again said:

I am not making a door. ;)
This is not about making doors or maps. This is about taking extant WADs going back as far as 1994 and fixing them in bulk, automatically...

Ah, right. In that case, I'd say forget it. There are just too many exceptions where either being unpegged is not desirable or where the detection would be difficult.

As Memfis said, sometimes not being unpegged is a design decision. Sometimes the tracks are meant to move because they look like chains (etc). Sometimes the tracks are split so they aren't made of a single line. Sometimes these split tracks are there to make the door track a more interesting shape - and that alone may make them more difficult to detect. Sometimes they are made so that some of the lines are unpegged and some aren't so that only parts of the track move. Sometimes doors have pillars completely inside the door sector.

Brute-forcing a batch "fix" on hundreds of WADs will "fix" many doors that aren't meant to be fixed in the first place and probably miss a whole bunch of tracks that perhaps should, or perhaps shouldn't, be changed. There are so many maps out there and so many quirks that people have built into their maps over the years that it is entirely inappropriate to come up with a set of rules and then try to apply them to all maps. As soon as you do, you'll find 101 maps specifically designed around constructs that break your rules.

I agree that, for "normal" doors, tracks should be unpegged and I personally think it looks bad when they aren't. I would usually regard unpegged tracks as an error or oversight. However, I think the suggestion of a tool that fixes a whole bunch of maps in one go is simply unworkable and would sometimes be inappropriate.

Share this post


Link to post

Thank you, Enjay. Would you agree that creation of such a tool in itself would provide an interesting challenge? I think this idea is worth exploring further.

Share this post


Link to post

An interesting challenge? Possibly, for someone who wants to practise that kind of programming. I suspect, however, that the number of exceptions it would have to catch versus the (I'm guessing) relatively low level of usage it would get would mean the old equation of "effort versus benefit" would mean that it wasn't really worth doing and, perhaps, something else might be a better tool to investigate.

Share this post


Link to post

You could code a hack in a source port to handle the most common cases, e.g., a DOORTRAK texture on a one-sided line facing a door sector. Here's a quick example I just did in Chocolate Doom:

Before hack:



After hack:

Share this post


Link to post

You could but then that would still stop DOORTRAKs that were meant to move by design from moving. And what about maps where someone has edited the DOORTRAK texture - e.g. to make it wider or different looking when given an X offset (i.e. the first 8 pixels look normal but the next 8 look like a chain and the 8 after that also look like normal DOORTRAK or something).

What about maps where some doors are meant to have non moving tracks and some are meant to move? I've seen individual doors where some parts of the track are meant to move and others aren't. And what about doors that are comprised of lifts and doors (in ports that allow such constructs to be activated simultaneously)?

Unfortunately, there simply isn't a "one size fits all" solution for this.

I quickly threw this file together in a few minutes just to show a few examples of where an auto-"fix" of this problem might be difficult.

http://www.aspectsweb.co.uk/enjay/doom/unpeg.zip

I have seen constructs similar to these in real WADs (hell, I even made a few ;) ).

[edit - fix typo]

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
Sign in to follow this  
×