dsda-doom source port [v0.24.3]

[Shepardus]

4 hours ago, ChopBlock223 said:

If someone can relay it to kraflab, there seems to be a bug regarding UMAPINFO and custom monsters using the boss death function, where it plain just doesn't work.

 

It appears to work just fine in Woof.

If it's the same thing as this, it's been fixed for the next release:

Until then, it's recommended to use v0.23.x for wads that rely on this behavior.

Edited August 16, 2022 by Shepardus

[ChopBlock223]

Ah, alright, that's good to hear.

[Gregor]

On 7/22/2022 at 10:32 PM, Maribo said:

 Everyone is still welcome to post in this thread, just be aware that bug reports should go through the Discord or Github channels as of now, as stated by Kraflab.

Maybe a link to the discord should be posted in the OP if it's the appropriate channel for bug reports and questions.

Edited August 19, 2022 by Gregor

[CeDean]

I am currently using DSDA Doom as my goto source port (switched from prboom+) but im wondering, is there still the "doom compatibility" and "enemies" menu? I cannot find it, if it was removed, can I ask why? Since im not a speedrunner, should I just use the UMAPINFO fork itself? 

Edited August 19, 2022 by CeDean

[Maribo]

19 hours ago, Gregor said:

Maybe a link to the discord should be posted in the OP if it's the appropriate channel for bug reports and questions.

Reasonable, done.

 

13 hours ago, CeDean said:

I am currently using DSDA Doom as my goto source port (switched from prboom+) but im wondering, is there still the "doom compatibility" and "enemies" menu? I cannot find it, if it was removed, can I ask why? Since im not a speedrunner, should I just use the UMAPINFO fork itself? 

The port's focus is speedrunning, and by extension that means maintaining the proper compatibility settings for each compatibility level. There are a handful that remain under different sub-headers in General, notably stuff like emulating spechits overflow, jumping, and vertical aiming. You can totally use this port for casual play (many people do!), but if you want to mess around with those compat settings, Pr+ would be a better choice.

[Gregor]

13 hours ago, CeDean said:

I am currently using DSDA Doom as my goto source port (switched from prboom+) but im wondering, is there still the "doom compatibility" and "enemies" menu? I cannot find it, if it was removed, can I ask why? Since im not a speedrunner, should I just use the UMAPINFO fork itself? 

 

DSDA only removed the access from the in-game menu, not the compat options themselves. You can still set the compatibility options in DSDA through the use of the options.lmp. The options lump was introduced by the original MBF. It does the same thing as the compat settings menu under PrBoom-plus (also introduced by MBF but for some reason PrBoom+ did not to support the options.lmp). It's a file you load using the -file parameter, just like a regular mod. The settings inside the lump will affect gameplay from -complevel 11 upwards, including MBF21. 

 

Copy one of the templates on the page i linked to into a text file (each respective template begins with "# General" and ends after "comp_reservedlineflag 1"), set things the way you like (0=nay, 1=yea), save it, and rename the .txt extension of the file to .lmp. Now you can just load it after the -file parameter inside a batch file/command line or your launcher of choice.

[Xaser]

Beyond just the speedrunning focus, the presence of those options in pr+'s menus a footgun anyway. It was easy for a user to toggle some settings that might accidentally break a map or seriously muck with the experience without it being obvious what's wrong. Moving all that stuff to the OPTIONS lump is a godsend for mappers since it lets folks set the exact settings that work best for the wad (if even necessary; the new defaults for cl21 are damn nice ;), while still allowing users to tinker with it themselves via a custom wad.

 

Either way, I'd recommend taking a look at setting up a wad with a custom OPTIONS lump and sticking to dsda-doom so you can have your cake and eat it too -- there's not a lot of compelling reasons to stick to prboom+ (even the UM fork/continuation) over dsda at this point, especially as dsda starts getting more cool new shit as time goes on.

[Gregor]

27 minutes ago, Xaser said:

Beyond just the speedrunning focus, the presence of those options in pr+'s menus a footgun anyway. It was easy for a user to toggle some settings that might accidentally break a map or seriously muck with the experience without it being obvious what's wrong. Moving all that stuff to the OPTIONS lump is a godsend for mappers since it lets folks set the exact settings that work best for the wad (if even necessary; the new defaults for cl21 are damn nice ;), while still allowing users to tinker with it themselves via a custom wad.

 

Either way, I'd recommend taking a look at setting up a wad with a custom OPTIONS lump and sticking to dsda-doom so you can have your cake and eat it too -- there's not a lot of compelling reasons to stick to prboom+ (even the UM fork/continuation) over dsda at this point, especially as dsda starts getting more cool new shit as time goes on.

Well, the one thing i don't like about DSDA's options lump implementation is that some of the original mbf flags where removed or rather set to always default to 0. I just like having the ability to turn things as vanilla as i want to.

 

EDIT: i just remembered that those flags are actually only turned off under MBF21; DSDA has nothing to do with this. Whoops.

Edited August 20, 2022 by Gregor

[Legatron17]

I recently tried to switch from PrBooom+ to DSDA, and I must say that I prefer the vanilla experience in this source port (complevels 2, 3 and 4) over PrBoom+. However, I have one very big issue with complevels 9, 11 and 21, and it's got to do with translucency. In PrBoom+, as well as in Boom 2.02 and the original MBF, there is an optional setting to make things like projectiles and certain items NOT translucent while keeping textures, like translucent waterfalls, actually still translucent. In DSDA however, there doesn't seem to be such an option, and all you can really do is set the translucency filter percentage to any value, which affects projectiles and translucent textures equally. This way, you can completely turn off translucency, but in return you can't enjoy translucent textures, which makes maps like Eviternity's MAP22 very irritating to play. I personally have an unhealthily extreme amount of hatred towards translucent projectiles and items, while at the same time loving translucent textures, and most of my friends share similar feelings. This is why my number 1 wish for this source port is to add the same option for complevels 9, 11 and 21 that many other source ports already have, and that is an option to keep translucent textures activated while deactivating translucent projectiles and items. As long as that option doesn't exist, I'm just going to play PrBoom+ for the aforementioned complevels (except 21, as that's not out yet for PB+).

 

Because PrBoom+ already has that option, I'm sure that it isn't difficult to implement, nor do I see a reason why it shouldn't be implemented. Since it's already possible to make projectiles and translucent textures either completely invisible or completely opaque in complevels 9, 11 and 21, AND the fact that the source ports DSDA is trying to emulate already have the option to differentiate between projectiles and translucent textures, there really is no reason why said option shouldn't be allowed to exist in this source port. On top of that, I don't think that anyone considers such an option to be "cheating", as it has existed for over two decades now and has been allowed in demos ever since it was a thing, since it's more of a cosmetic option than anything else.

 

I hope that such a simple but important option will come to DSDA soon! :)

[Shepardus]

IIRC the "enable translucency" setting in PrBoom+, Boom, and MBF operates on all translucency, not just projectiles/items, and turning it off is effectively the same as setting the filter percentage to 100. Woof and Eternity do have settings to disable the "predefined" translucency, though. There is a dehacked known as notransl.deh that you can use with dsda-doom to achieve the same, but it would be nice to have "official" support for it IMO, since loading extra modifications while recording demos isn't allowed by DSDA rules.

[Legatron17]

6 hours ago, Shepardus said:

IIRC the "enable translucency" setting in PrBoom+, Boom, and MBF operates on all translucency, not just projectiles/items, and turning it off is effectively the same as setting the filter percentage to 100. Woof and Eternity do have settings to disable the "predefined" translucency, though. There is a dehacked known as notransl.deh that you can use with dsda-doom to achieve the same, but it would be nice to have "official" support for it IMO, since loading extra modifications while recording demos isn't allowed by DSDA rules.

 

While the enable translucency setting does operate on all translucency, there is an extra setting in Boom, MBF and PrBoom+ to disable predefined translucency. For Boom and MBF, you could turn on the option "enable translucency for some things" in the .cfg file (see pic), which would make projectiles & items opaque but keep translucent textures still translucent. The same thing is possible in PrBoom+, but this time, you don't even have to go into the .cfg file, as you could directly enable the option "No predefined translucency for some things" on the last page of the compatibility settings (see pic), which has the exact same effect as the setting from Boom and MBF. So it's not just Woof and Eternity that have this setting.

Seeing as DSDA is a direct fork of PrBoom+, I don't think it would be much harder than copy and pasting a bit of code into the correct places to add this option. Again, I don't see why it shouldn't be added, as I see it as the biggest disadvantage DSDA-doom has in comparison to PrBoom+.

 

Edited September 1, 2022 by Legatron17

[rfomin]

46 minutes ago, Legatron17 said:

For Boom and MBF, you could turn on the option "enable translucency for some things" in the .cfg file (see pic), which would make projectiles & items opaque but keep translucent textures still translucent.

No, it enables/disables all translucency effects in MBF, it's called "enable translucency" in the General menu. In Woof we have to change it to only disable predefined things.

[Grazza]

Yes, we added this stuff in 2.2.6.26 in 2006, and it wasn't in earlier versions (which also had significant bugs with translucency and related deh support).

 

Relevant posts here, here and here (and surrounding posts too).

 

I have also updated the links to the transluc.zip and notransl.zip files, as the ones from 2006 no longer worked. If you don't want these things ever to be translucent in any complevel (unless made so deliberately by a pwad author), then just make notransl.deh a preloaded file and think no more of it. This shouldn't then autoload when anyone watches a demo recorded with it, so those who actually like these things translucent won't be bothered by your preference.

 

Note that changing the comp option has/had no effect in vanilla or Boom/MBF complevels, which would always apply the "correct" setting for that complevel - unconditionally non-translucent for vanilla and unconditionally translucent for Boom/MBF.

 

Some of this stuff may have been changed post-2.5.1.5 for all I know. I haven't used any of the more recent forks.

Edited September 3, 2022 by Grazza

[Gregor]

On 9/1/2022 at 7:14 AM, Legatron17 said:

In PrBoom+, as well as in Boom 2.02 and the original MBF, there is an optional setting to make things like projectiles and certain items NOT translucent while keeping textures, like translucent waterfalls, actually still translucent. In DSDA however, there doesn't seem to be such an option, and all you can really do is set the translucency filter percentage to any value, which affects projectiles and translucent textures equally.

 

On 8/20/2022 at 1:16 AM, Gregor said:

 

DSDA only removed the access from the in-game menu, not the compat options themselves. You can still set the compatibility options in DSDA through the use of the options.lmp. The options lump was introduced by the original MBF. It does the same thing as the compat settings menu under PrBoom-plus (also introduced by MBF but for some reason PrBoom+ did not to support the options.lmp). It's a file you load using the -file parameter, just like a regular mod. The settings inside the lump will affect gameplay from -complevel 11 upwards, including MBF21. 

 

Copy one of the templates on the page i linked to into a text file (each respective template begins with "# General" and ends after "comp_reservedlineflag 1"), set things the way you like (0=nay, 1=yea), save it, and rename the .txt extension of the file to .lmp. Now you can just load it after the -file parameter inside a batch file/command line or your launcher of choice.

 

Note that the comp_translucency setting, the one you're interested in ("No predefined translucency for some things" in the comp menu), is always forced to 0 under mbf21. 

Edited September 2, 2022 by Gregor

[Legatron17]

2 hours ago, Grazza said:

Yes, we added this stuff in 2.2.6.26 in 2006, and it wasn't in earlier versions (which also had significant bugs with translucency and related deh support).

 

Relevant posts here, here and here (and surrounding posts too).

 

I have also updated the links to the transluc.zip and notransl.zip files, as the ones from 2006 no longer worked. If you don't want these things ever to be translucent in any complevel (unless made so deliberately by a pwad author), then just make notransl.deh a preloaded file and thing no more of it. This shouldn't then autoload when anyone watches a demo recorded with it, so those who actually like these things translucent won't be bothered by your preference.

 

Note that changing the comp option has/had no effect in vanilla or Boom/MBF complevels, which would always apply the "correct" setting for that complevel - unconditionally non-translucent for vanilla and unconditionally translucent for Boom/MBF.

 

Some of this stuff may have been changed post-2.5.1.5 for all I know. I haven't used any of the more recent forks.

Thank you very much for this! I just tested it out with a bunch of complevel 9 and 11 WADs, and it works fine with most of them. There is sometimes a problem however when custom projectiles come into play. One example is MAP05 of JUMPWAD (-cl 11) by Ribbiks, where a snow effect is generated through custom projectiles falling down. Without the .deh, there is no problem, but with the .deh the game slows down to a crawl after a few seconds and the snow just gets stuck on the very top of the map, making the map completely unplayable with 2 fps. In PrBoom+ for example, the snow simply ignores the built-in option to disable translucency for some things and doesn't cause such a bug. I'm not sure whether or not there could be other demo desyncing properties caused by the .deh, but it's one of the reasons why I still wish that DSDA would simply add the same option that already exists in PrBoom+, since that option never caused a game-breaking bug for any WAD that I've ever played, while here I have already found a game-breaking bug within less than an hour. Still, thanks for the help!

 

12 minutes ago, Gregor said:

DSDA only removed the access from the in-game menu, not the compat options themselves. You can still set the compatibility options in DSDA through the use of the options.lmp. The options lump was introduced by the original MBF. It does the same thing as the compat settings menu under PrBoom-plus (also introduced by MBF but for some reason PrBoom+ did not to support the options.lmp). It's a file you load using the -file parameter, just like a regular mod. The settings inside the lump will affect gameplay from -complevel 11 upwards, including MBF21. 

 

Copy one of the templates on the page i linked to into a text file (each respective template begins with "# General" and ends after "comp_reservedlineflag 1"), set things the way you like (0=nay, 1=yea), save it, and rename the .txt extension of the file to .lmp. Now you can just load it after the -file parameter inside a batch file/command line or your launcher of choice.

 

Yeah, I will try out the options.lmp technique for -cl 11 and keep the .deh for -cl 9. Once again, it would still be nice to have a built-in option that affects all complevels >= 7 so you don't have to mess around with external files that can cause massive bugs in certain cases.

Edited September 2, 2022 by Legatron17

[Gregor]

9 hours ago, Legatron17 said:

Yeah, i will try out the options.lmp technique for -cl 11 and keep the .deh for -cl 9. Once again, it would still be nice to have a built-in option that affects all complevels >= 7 so you don't have to mess around with external files that can cause massive bugs in certain cases.

 

Well, the comp_translucency setting in the options.lmp controls the same exact thing as the "No predefined translucency for some things" option in the comp menu of PrBoom+. So PrBoom+ doesn't have any extra option compared to DSDA here; it's just that you cannot toggle it in-game for DSDA. If you were fine with how PrBoom+ handles it, you can get the same behavior with DSDA as well; no need for any dehacked files. But again, in both Prboom-plus and DSDA those options only affect gameplay for complevels 11+ where the comp menu/options.lmp settings are used by the engine.

 

Still, i personally would prefer to have the comp menu in DSDA as well. If only for the convenience of toggling settings on and off in-game every once in a while to see the immediate effect. But, alas, such an addition is rather unlikely since kraflab (the author of the port) has already made it clear that he isn't a fan of the in-game comp settings menu. The same i'm afraid holds true with regard to extra translucency options because added translucency for textures or sprites is considered cheating under speedrunning rules, which DSDA is very much geared towards. Hence, you most likely won't see such changes any time soon if ever at all.

 

But you never know. At least in regard to translucency he might change his opinion considering that DSDA already includes a lot of quality-of-life improvements over PrBoom+. If you want to ask him directly, i would suggest heading over to the official speedrunning/DSDA discord linked in the OP.

Edited September 3, 2022 by Gregor

[Legatron17]

10 hours ago, Legatron17 said:

Yeah, I will try out the options.lmp technique for -cl 11 and keep the .deh for -cl 9. Once again, it would still be nice to have a built-in option that affects all complevels >= 7 so you don't have to mess around with external files that can cause massive bugs in certain cases.

 

UPDATE: The comp_translucency setting in the OPTIONS.lmp has been removed, and adding it back has no effect on DSDA-doom. That said, the only way to make the game differentiate between translucent projectiles and translucent textures is through the custom .deh provided by Grazza, but I decided to not use it in the future as it causes game-breaking bugs and potentially even demo desyncs in specific cases. I'll just play DSDA-doom for complevels 2, 3, 4 and 21 but keep playing PrBoom+ for complevels 9 and 11 until DSDA adds back the "No predefined translucency for some things" option from PrBoom+ itself.

I think that it would be kind of weird if it doesn't get added to DSDA in the future, because practically no one considers the option to give you any kind of gameplay advantage, especially since you can already make everything either opaque or completely invisible, so making only translucent textures translucent but not enemy projectiles and items is a purely cosmetic option. The setting has existed in PrBoom since 2006, and it has never been (and probably never will be) considered to not be allowed while recording demos, which is why it would make the perfect QoL option for DSDA-doom and ultimately eliminate the biggest grievance I (and most of my friends) have with the source port.

 

Sorry for bloating the thread a little, and this will most likely be my final message regarding this topic. Here's to hoping that the option will get added at some point! :)

[Shepardus]

Echoing some stuff I said on Discord:

 

The issues with notransl.deh and some wads like Jumpwad come down to load order. If notransl.deh is loaded after Jumpwad, the snow will go haywire, but if Jumpwad is loaded after notransl.deh, the wad will override whatever flags it needs to and it'll work fine. Unfortunately arguments to -deh seem to always load after -file, regardless of the order of the -deh and -file parameters.

 

Putting notransl.deh in the autoload folder seems to do the trick, but it depends on which autoload folder you place it in: If you put it in autoload/doom-all (as I do), it'll load before Jumpwad, but if you put it in autoload/JUMPWAD.wad, it'll load after Jumpwad. Either way it loads after the IWAD, so if you're playing an IWAD that uses DeHackEd, such as the IWAD versions of HacX or REKKR, you'd probably want to use the -noautoload/-noload parameter to skip autoload.

 

You can also put the dehacked patch in a wad (make sure the lump is named DEHACKED) and load it with -file in whatever order. In the upcoming dsda-doom v0.25, you'll be able to load dehacked patches using -file instead of -deh without having to wrap them in a wad, but I haven't tested whether this respects the load order.

[Gregor]

35 minutes ago, Shepardus said:

You can also put the dehacked patch in a wad (make sure the lump is named DEHACKED) and load it with -file in whatever order.

One small correction: the load order for wad files does matter. You have to put the wad containing the dehacked lump in the first position after the -file parameter or it will cause the same glitches.

Edited September 3, 2022 by Gregor

[Dweller Dark]

When it comes to DSDA-Doom and complevels, how do you determine what complevel should be used for a specific WAD? Is there any terminology that would help identify what complevel to use?

[Gregor]

Just now, Eddie 2077 said:

When it comes to DSDA-Doom and complevels, how do you determine what complevel should be used for a specific WAD? Is there any terminology that would help identify what complevel to use?

The intended complevel for any Pwad can be attained by checking the text file that comes with the wad itself.

[Dweller Dark]

Just now, Gregor said:

The intended complevel for any Pwad can be attained by checking the text file that comes with the wad itself.

 

But what if the text file doesn't have complevel information? 

[maxmanium]

4 minutes ago, Eddie 2077 said:

 

But what if the text file doesn't have complevel information? 

 

If it omits the "Advanced engine needed" section, it's vanilla. That or it's super old and guaranteed to be vanilla anyway.

[Gregor]

1 minute ago, Eddie 2077 said:

 

But what if the text file doesn't have complevel information? 

They pretty much always do have the information. Otherwise the wad author messed up.

Normally it's stated right at the top which engine is needed. On rare occasions you have to scan the rest of text for the info. But it's always in there, unless the map maker is new to the scene and doesn't know about the convention. Of course some projects, mostly wads/pk3s made for GZDoom, don't come with text files; but then you already know that they'll require GZDoom anyways. If it's a comparatively well-known wad, you can also check the wiki for the required complevel.

[Maribo]

If you're playing casually, you can honestly just play on cl21 for almost everything and run into no issues, but aside from that:

First thing you'd do is look in the txt file for the wad for specific complevel, but failing that, you'd look for the following
"vanilla" or "limit-removing" - cl2, 3, or 4, depending on the iwad in use. This is not always that simple though, as there are a few WADs out there from the period in time where "limit-removing" and "boom-compatible" were used interchangeably. If it's an older wad (think early to late 2000s), I would personally double check and see if it's already on DSDA with any runs.

"boom-compatible" - cl9
"mbf-compatible" - cl11
"mbf21-compatible" - cl21

You'll pretty much never use any other complevels except in rare cases where cl0 or cl1 would allow you to do something super specific on a cl2/3/4 wad.

 

You can also crack open the wad in UDB and see if it uses and boom / mbf / mbf21 exclusive line actions.

 

There are also other reasons a WAD would be run, for instance, in cl9 even though it functions 100% properly in cl2. The most common reason for this is the lost soul limit, a good example for a WAD that is run in cl9 due to this would be Deus Vult.

There are some rare instances where runs for a WAD would be accepted in multiple complevels (usually cl2 and cl9), usually due to history. I believe both complevels are currently accepted for Hellbound runs.

[Dweller Dark]

3 minutes ago, Maribo said:

If you're playing casually, you can honestly just play on cl21 for almost everything and run into no issues, but aside from that:

First thing you'd do is look in the txt file for the wad for specific complevel, but failing that, you'd look for the following
"vanilla" or "limit-removing" - cl2, 3, or 4, depending on the iwad in use. This is not always that simple though, as there are a few WADs out there from the period in time where "limit-removing" and "boom-compatible" were used interchangeably. If it's an older wad (think early to late 2000s), I would personally double check and see if it's already on DSDA with any runs.

"boom-compatible" - cl9
"mbf-compatible" - cl11
"mbf21-compatible" - cl21

You'll pretty much never use any other complevels except in rare cases where cl0 or cl1 would allow you to do something super specific on a cl2/3/4 wad.

 

You can also crack open the wad in UDB and see if it uses and boom / mbf / mbf21 exclusive line actions.

 

There are also other reasons a WAD would be run, for instance, in cl9 even though it functions 100% properly in cl2. The most common reason for this is the lost soul limit, a good example for a WAD that is run in cl9 due to this would be Deus Vult.

There are some rare instances where runs for a WAD would be accepted in multiple complevels (usually cl2 and cl9), usually due to history. I believe both complevels are currently accepted for Hellbound runs.

 

I pretty much always play casually, but I've heard that complevels are sometimes required for certain things in WADs to function properly. But cl21 should be fine in that case, unless I run into a specific issue?

[Gregor]

3 minutes ago, Eddie 2077 said:

 

I pretty much always play casually, but I've heard that complevels are sometimes required for certain things in WADs to function properly. But cl21 should be fine in that case, unless I run into a specific issue?

The DSDA crowd always wants to push MBF21 as the answer to all questions. Do not be deceived. ;)

I would recommend to use the appropriate complevel for whatever wad you play, but if it's too much of a hassle (especially at the beginning) mbf21 is most likely gonna cover most wads.

[Maribo]

4 minutes ago, Eddie 2077 said:

I pretty much always play casually, but I've heard that complevels are sometimes required for certain things in WADs to function properly. But cl21 should be fine in that case, unless I run into a specific issue?

Yeah, totally fine. If you do find something that is broken specifically when running cl21 in a lower complevel wad, feel free to post about it (providing a demo would be extra helpful but details are fine too), because cl21 is supposed to cover everything within the bounds of the standard complevels.

[Dweller Dark]

1 minute ago, Maribo said:

Yeah, totally fine. If you do find something that is broken specifically when running cl21 in a lower complevel wad, feel free to post about it (providing a demo would be extra helpful but details are fine too), because cl21 is supposed to cover everything within the bounds of the standard complevels.

 

I'll make sure to do that, then. Is it possible for a launcher to read and display the complevel of a WAD? If it's possible, that would be a neat feature for a launcher to have.

[Shepardus]

WAD authors can also put a COMPLVL lump in their WAD (text lump with possible values "vanilla," "boom," "mbf," or "mbf21"), which dsda-doom (and Woof) will use if no -complevel parameter is provided (the parameter will still take precedence over the lump). Hopefully that catches on more over time so there's less ambiguity about the intended complevel (though I'd say people are already better about specifying complevel in text files nowadays than they used to be).