Missing some linedef options in Doom Builder 2 (v2.1.2.1553)

[DASH Project]

Okay, the answer to this question is probably painfully obvious, but it's not obvious to me right now.

Ever since yesterday afternoon I've been just coasting through AlysiumX's excellent Doom Builder 2 tutorials, until I got to the one about creating doors in Hexen format (also seemingly classified as the way to create doors for zdoom...I already know how to create doors within Builder, but because I wanna experiment with some of the more advanced things zdoom can do in my WADs, I wanted to figure out the way zdoom does things like doors, for flexibility's sake.)

Things were just fine until I realized the available linedef options to check in my version of Builder and significantly fewer than the ones in the same window shown in the tutorial. I am missing the options for "Repeatable Action," "Monster Activates," "Block Players" and "Block Everything," as you can see in the linked screenshot below. Mine just cuts off after "Shown." I need to be able to check the "Repeatable Action" box in order to finish the tutorial, and further down the line I don't think I can do many of the things I want to do if my program is missing some crucial features.



I do know that the tutorial I am watching is from December 2009, and I am currently using version 2.1.2.1553 of Doom Builder 2, almost assuredly newer than the version he is using in the video. My best guess is they changed some things in my newer version. So if that's the case, what are the newer alternatives to the old actions? Help would be greatly appreciated, thanks beforehand.

[Da Werecat]

You need to create a new map with "ZDoom (Doom in Hexen format)" game configuration. Right now you're most likely using "ZDoom (Doom in Doom format)" config.

[Kappes Buur]

The difference stems from editing in Doom2 format or ZDoom (Doom in Hexen) format.

The Doom format is rather limited in what can be done. The linedef type itself determines
if the action is done once or can be repeated.

The ZDoom (Doom in Hexen) format extends the number of available linedef actions and
separates the settings for how the action is triggered. While the format mentions Hexen,
it does not mean that you have to install Hexen. It just means that ZDoom can use all
of the features which are in Hexen, and builds on them.

To use ZDoom simply download from http://devbuilds.drdteam.org/zdoom/ and install it,
then select and set up the configuration in Doombuilder 2.

While at that website, you may want to download the latest version of Doombuilder2, or GZDoom Builder,
which is the extension of Doombuilder2.

[DASH Project]

Da Werecat said:

You need to create a new map with "ZDoom (Doom in Hexen format)" game configuration. Right now you're most likely using "ZDoom (Doom in Doom format)" config.

You are correct, my bad. I currently have it in Doom 2 format, or at least have the Doom 2 IWAD set up for what Builder uses. I just created a new map to replace it that is set up as "ZDoom (Doom in Hexen format)" like you suggested...I take it I don't need an actual Hexen IWAD to do that though, I sure hope not (forgive that n00bish question...I haven't been active with modding since 2009, so I've gotten a wee bit rusty.) Either way I set the game configuration as "ZDoom (Doom in Hexen format)" but still used the Doom 2 IWAD as a resource for textures and stuff. And hey, the actions I need are there.

Okay, I did all that stuff, setting zdoom as the test program for "Doom in Hexen format" WADs too, and ran it. But now there are a whole host of other parameters I am not familiar with, like movement speed and tags for lighting and the sector, just for action 11 (Door Open.) I tested the WAD and found that the door plays the opening noise when you activate it, but it does not actually move.

Got any pointers for learning the way Hexen does stuff? Because if I'm not mistaken, Hexen seems to be the new standard for zdoom, more so than vanilla Doom. That's where ACS originated too, I think.

Kappes Buur said:

The difference stems from editing in Doom2 format or ZDoom (Doom in Hexen) format.

The Doom format is rather limited in what can be done. The linedef type itself determines
if the action is done once or can be repeated.

The ZDoom (Doom in Hexen) format extends the number of available linedef actions and
separates the settings for how the action is triggered. While the format mentions Hexen,
it does not mean that you have to install Hexen. It just means that ZDoom can use all
of the features which are in Hexen, and builds on them.

To use ZDoom simply download from http://devbuilds.drdteam.org/zdoom/ and install it,
then select and set up the configuration in Doombuilder 2.

While at that website, you may want to download the latest version of Doombuilder2, or GZDoom Builder,
which is the extension of Doombuilder2.

I am pretty sure I have the latest version of Doombuilder2...well, it's from June 1st, 2012, which is almost two years ago. But it looked like it was the most recent on the website (not sure how to get an even newer one.) And as for GZDoom Builder, if that involves using GZDoom instead of ZDoom, then I'm probably not interested. I haven't have much luck with GZDoom and prefer the original ZDoom, which I think I have the latest version of (version 2.8, from earlier this same month I think.) Actually no, I just downloaded an even newer version from just three days ago. Damn, those devs work fast!

[Blastfrog]

DASH Project said:

Got any pointers for learning the way Hexen does stuff? Because if I'm not mistaken, Hexen seems to be the new standard for zdoom, more so than vanilla Doom. That's where ACS originated too, I think.

You seem to get the idea. I'd recommend looking on ZDoom's wiki. They've got all the linedefs and their usage explained. It will solve all of your problems with stuff like stuck doors and platforms.

DASH Project said:

And as for GZDoom Builder, if that involves using GZDoom instead of ZDoom, then I'm probably not interested. I haven't have much luck with GZDoom and prefer the original ZDoom, which I think I have the latest version of (version 2.8, from earlier this same month I think.)

You can still use GZDoom Builder for normal ZDoom. It makes the editing of 3D floors much more straightforward and manageable. ZDoom supports 3D floors these days. I remember that sloped 3D floors don't work in software mode. However, I haven't used the port myself in quite a while, so I don't know if this has been changed yet or not.

[DASH Project]

Sodaholic said:

You seem to get the idea. I'd recommend looking on ZDoom's wiki. They've got all the linedefs and their usage explained. It will solve all of your problems with stuff like stuck doors and platforms.You can still use GZDoom Builder for normal ZDoom. It makes the editing of 3D floors much more straightforward and manageable. ZDoom supports 3D floors these days. I remember that sloped 3D floors don't work in software mode. However, I haven't used the port myself in quite a while, so I don't know if this has been changed yet or not.

Good. But one question though, now about slopes and other things that ZDoom can do. I am one modder who likes to stay away from true 3D in my WADs, as I prefer the genuine raycasting of the original rendering engine. I was actually reading the ZDoom wiki about things like slopes, PolyObjects and even 3D bridges, all of which seem to be able to be possible without resorting to the true 3D that ZDoom and GZDoom are both capable of nowadays (using Open GL I think.)

Is it true that all of what I just mentioned can be done without resorting to OpenGL true 3D rendering? I can kind of visually "guess" to see if a WAD is genuine raycasting or true 3D by looking up or down, and as a result seeing either a perfect change in view about 90 degrees up or down (for true 3D,) or if it looks more static and "distorts" a bit, which would mean it is actually Y-shearing, on a genuine raycasted WAD. I refuse to do anything in my WADs that would require a mandatory switch to true 3D. Because for me, true 3D just isn't the same for an old-school game like Doom, as silly as that sounds. I prefer extending and pushing the heck out of the original rendering engine.

[Blastfrog]

DASH Project said:

Good. But one question though, now about slopes and other things that ZDoom can do. I am one modder who likes to stay away from true 3D in my WADs, as I prefer the genuine raycasting of the original rendering engine. I was actually reading the ZDoom wiki about things like slopes, PolyObjects and even 3D bridges, all of which seem to be able to be possible without resorting to the true 3D that ZDoom and GZDoom are both capable of nowadays (using Open GL I think.)

Is it true that all of what I just mentioned can be done without resorting to OpenGL true 3D rendering? I can kind of visually "guess" to see if a WAD is genuine raycasting or true 3D by looking up or down, and as a result seeing either a perfect change in view about 90 degrees up or down (for true 3D,) or if it looks more static and "distorts" a bit, which would mean it is actually Y-shearing, on a genuine raycasted WAD. I refuse to do anything in my WADs that would require a mandatory switch to true 3D. Because for me, true 3D just isn't the same for an old-school game like Doom, as silly as that sounds. I prefer extending and pushing the heck out of the original rendering engine.

Yes, you can do that in software mode.

The qualifications you defined for "true raycasting" are a bit vague. Note that Marathon was 2.5D but had portals for lines, so they could create overlapping sectors that act separate from each other. Jedi engine and Build engine games did this too.

Later Build games introduced plane (floor/ceiling) portals to create true 3D spaces, even if implemented in a limited fashion. ZDoom has plane portals, but no line portals. Eternity has both kinds. As I mentioned previously, ZDoom has 3D floors. While it's a different implementation, you can use them to create areas like Build engine games while keeping in the true software engine, as well as the plane portals.

I don't really see any reason why you should avoid 3D floors and portals, you can still do it in a column-based renderer like other FPSes of the time did.

Lastly, one could very easily fake a software-like mode in OpenGL. It is possible to do Y-shearing in OpenGL, since all consists of is panning in 2D on a high FOV area. You can also imitate the sector specific dark fog of software mode in OpenGL (even in 32 steps), and then use post processing to palettize it to a fixed 256 color bitmap. ZDoom is using an actual software renderer, though.

[Kappes Buur]

DASH Project said:

..... And as for GZDoom Builder, if that involves using GZDoom instead of ZDoom .....

Just because there is a leading G in GZDoom Builder does not mean that GZDoom Builder is only for GZDoom mapping.
In fact GZDoom Builder has configuration files for many engines.



MaxED took over from Codeimp when Doombuilder2 was at r1630.
Many features have been added, some due to requests from people using GZDoom Builder,
others because MaxED saw a need for those features. GZDoom Builder is now at r1922.

For a short list of features see
http://forum.zdoom.org/viewtopic.php?f=3&t=32392

[Gez]

DASH Project said:

I take it I don't need an actual Hexen IWAD to do that though, I sure hope not

Of course not. It only describes the technicalities of the map format, since Doom and Hexen use slightly different map formats. (Differences concern how things and linedefs are stored, as well as the addition of ACS.)

Likewise, you don't need a Doom IWAD to use the Doom format. You can make a Heretic in Doom format map for instance.

DASH Project said:

Got any pointers for learning the way Hexen does stuff? Because if I'm not mistaken, Hexen seems to be the new standard for zdoom, more so than vanilla Doom. That's where ACS originated too, I think.

Using Hexen's format in other games has been a ZDoom feature for over 15 years (at least since December 22, 1998). The new standard for ZDoom, since March 2009, is UDMF. There are many ZDoom features that require clumsy hacks to be used in a Hexen format map, and are nearly impossible to use to a Doom format map. If you make a new map for ZDoom, it's really advised to use UDMF now.

DASH Project said:

And as for GZDoom Builder, if that involves using GZDoom instead of ZDoom, then I'm probably not interested.

You can map for ZDoom in GZDoom Builder. Heck, you can map for plain vanilla Doom in GZDoom builder. GZDB has features specifically relevant to GZDoom (like preview of its dynamic lights) but most of the stuff it has on top of DB2 are useful for ZDoom editing too. It also has some bug fixes and increased usability over DB2 which would probably make it a better choice even for vanilla/Boom editing.

[DASH Project]

Sodaholic said:
Yes, you can do that in software mode.

The qualifications you defined for "true raycasting" are a bit vague. Note that Marathon was 2.5D but had portals for lines, so they could create overlapping sectors that act separate from each other. Jedi engine and Build engine games did this too.

Later Build games introduced plane (floor/ceiling) portals to create true 3D spaces, even if implemented in a limited fashion. ZDoom has plane portals, but no line portals. Eternity has both kinds. As I mentioned previously, ZDoom has 3D floors. While it's a different implementation, you can use them to create areas like Build engine games while keeping in the true software engine, as well as the plane portals.

I don't really see any reason why you should avoid 3D floors and portals, you can still do it in a column-based renderer like other FPSes of the time did.

Lastly, one could very easily fake a software-like mode in OpenGL. It is possible to do Y-shearing in OpenGL, since all consists of is panning in 2D on a high FOV area. You can also imitate the sector specific dark fog of software mode in OpenGL (even in 32 steps), and then use post processing to palettize it to a fixed 256 color bitmap. ZDoom is using an actual software renderer, though.

I don't quite know all the technical details of source ports and what can and can't be done with raycasting versus true 3D just yet, but I presume "software mode" means traditional raycasting.

Also, a Marathon-type setup would be pretty nice...but what do you mean by 3D portals? And the Build engine was for Duke Nukem 3D right? And the Jedi engine was Dark Forces, if I am remembering correctly. So would "3D floors" and ceilings mean the floors and ceilings are true 3D, but the walls are still raycasted? That's what I got out of what you said, feel free to correct me if I am wrong.

If that's the case, then I might be willing to use a hybrid raycasted/true 3D setup as long as it's the easiest way to do things. Especially since I want to eventually learn to put stuff in my WADs like sloped/slanted floors and walls and stuff, doors that slide/swing horizontally, and distance fog. But still, the more original raycasting I can implement, the better.

The main thing I have against doing everything in true 3D is the fact that the game environment itself would more resemble a modern game, but the sprites of enemies, items, guns, the player, etc. would all be the original, low-res, stiffly-animated sprites from the original game, or some variation thereof, and I think it would just seem silly and mess with my autistic obsession with completeness and functional elegance. Because I tend to prefer high-quality 2D over mediocre 3D, and while I do know true 3D source ports such as Doomsday support stuff like Quake models, I can *not* 3D model to save my life currently, though I do have 3D Studio Max 2011, it just seems incredibly daunting to teach myself something like that, especially when I am so much better at 2D spriting, which is what Doom was meant for in the first place.

Kappes Buur said:
Just because there is a leading G in GZDoom Builder does not mean that GZDoom Builder is only for GZDoom mapping.
In fact GZDoom Builder has configuration files for many engines.

I actually downloaded GZDoom Builder (as well as the latest version of Slade 3...my version of Slade was badly in need of an upgrade, considering the last version I used was from early 2011 I think) and I find it to be just as easy to use as Doom Builder 2. Plus it has a host of new features apparently, such as more advanced sector-drawing options. Aside from that, what else makes GZDoom Builder different from regular Doom Builder?

Gez said:
If you make a new map for ZDoom, it's really advised to use UDMF now.

Good idea. I just made a practice map in the UDMF format last night, and I think I'm getting the hang of how it handles basic things like doors and stuff. I can't show you my WAD just yet, since all the practice maps I've made so far are beyond pathetic (like, "only two rooms separated by a single door, and no weapons or monsters" pathetic) but I expect to be able to start making more interesting custom levels over the next week (I have spring break, so that gives me a ton of extra time to practice modding and level making.)

One single, extremely n00bish question about UDMF and other map formats though...since I mentioned before I want to stick with the original raycasting as much as possible, does the map format have anything to do with whether the map is rendered in traditional raycasting or whether it uses Open GL for true 3D instead? My common sense tells me no (also from experience in looking up and down in an UDMF-formatted map, and seeing Y-shearing, rather than true vertical FOV movement,) but I'm just making sure, since it's such a new format, and new game stuff is generally true 3D.

[Gez]

Just to nitpick, Doom doesn't use raycasting. It uses the BSP tree to render, instead of projecting rays.

ZDoom renders 3D floors in software by basically creating portals on the fly. As far as the renderer is concerned, a room with a 3D floor is the same as a room with a portal setup. This is an approach that had the merit of being relatively simple, but it has bugs (sometimes you can see sprites through the 3D floors even though you shouldn't) and limitations (this is what prevents sloped 3D floors from being rendered).

The only thing that determines which renderer is used to display a map is which port you're using. ZDoom only has the software renderer, so everything in the game world will be rendered in software.

Compared to DB2, GZDB has a ton of updates. If you're not specifically interested in the ZDoom and GZDoom editing features, the most salient would be:
* Some errors fixed in configuration files
* Find and replace mode is more powerful (can search for things by flags, angle, etc.)
* Several semi-obscure bugs fixed (e.g. DB2 could crash if the loaded PLAYPAL had less than 256 colors, DB2 would sometime fail to detect a key had been released so it behaved like the key was stuck)
* Error checker looks for unknown things, unconnected vertices,
* Many interface tweaks (filters for lists like things, actions and effects, can change size of vertex handles, linedef angle and front side tab is previewed when drawing lines, "paint selection" mode, sector tags are shown on top of unselected sectors, texture dimensions are shown in linedef/sector editing panels, etc.)
* Batch-editing of detected errors
* Much faster performances when parsing configuration files (so you can now have dozens of configs at once without needing to wait a half hour between starting GZDB and being able to use it), loading the texture browser when you have hundreds of textures loaded, deleting map elements, etc.
* Faster rendering performances in 2D modes
* Included ZDBSP and ACC are newer and have less bugs
* Many elements with controversial behavior (like autoaligning texture offsets when splitting a linedef) are now optional
* Action to select things in selected sectors
* You can give labels to tags
* You can change the default flats, textures, brightness level, floor and ceiling heights
* SLADE-like render of thing sprites in 2D modes
* Added hint panel feature
* "Go To Coordinates" action
* Better support for absolutely gigantic maps (DB2 could run out of memory with behemoths like ZDCMP2)
* Entire interface can now fit in a 1024x768 screen

[Da Werecat]

autoaligning texture offsets when splitting a linedef is optional in GZDB

My heart filled with hope, but it turned out that this feature still doesn't quite work.

Although the way it didn't work in DB2 (where it was also present) was worse, as far as I can tell after a few minutes of poking around.