Arsinikk

I think I was more talking about having to make the BAT file yourself. You did mention including a BAT file, which is easy enough for a casual user. Although I do find the BAT solution to be more of a "band aid" solution in general. Especially if its only use is "pause on close with ENDOOM" the BAT file. It'd make much more sense to me if it was just a option in the main config file.

Actually I'd like to retract that statement. I think I let my previous technical issues with PrBoom Plus cloud my judgment here a bit and equated that towards performance, but that's definitely the incorrect term to use there. Even so, I wouldn't even be able to probably tell a difference between the two, since I have a high-end PC. I remember having some stuttering issues (possibly relating to high framerates) with PrBoom Plus before, but those have been fixed since. Previous problems such as jerky mouse movement and lack of high DPI scaling support have also since been fixed (in the latest 2.6.66 version that is). I cannot comment on your PrBoomX, as I have yet to try it out. I will say that DSDA Doom seems to run audio differently than PrBoom Plus, and I personally prefer how DSDA Doom does it. (Sorry I don't know how to explain it better than that, but I think the audio sounds a bit different between ports).

Not even going to go into how some of my best friends are speedrunners... It's not like I don't work with source port developers all the time to fix issues... Or that I am a web developer who is used to working with code. Or even that I've coded my own infopack applications. That's some conjecture there. Tbf I don't really have strong opinions about this. I have strung together a logic map based on what other users have posted about and what your responses have been like. It is the conclusion I have come to of why things have ended up where there are, and tbh you haven't exactly disproved any of the points I have brought up. If there's certain features that you have removed, in which I have come to the wrong conclusions, then why not enlighten me. My discussions on my Discord server tell me otherwise. Many players I talk to who have used DSDA Doom are hesitant to use it, simply due to feature removal. Honestly it's because of how you respond and don't clarify why things were done. For example, your most recent statement here: "If someone doesn't like to tinker and also doesn't want to use the launcher, then endoom doesn't exist for them." comes off as harsh with no attempt to empathise with any such user in that group. Talk about ignoring a certain userbase that uses your port. If you wanna take it that way, sure I guess. I never said you were dumb. I do think by not acknowledging that many causal Windows users do not wanna mess with BAT files nor command line, shows that your perspective on what's normal for many causal users is a bit skewed. I wouldn't say this is surprising, as you tend to dive into complicated code being a program developer. However I think that this can blind some people of the experience of other users that don't like working with code. Regarding your character, you are are honestly not the nicest source developer that I talked to, which makes it difficult to have an actual discussion with. Your harsh comments toward some users about the port do not help your case. This is a fair point... I think my point was mostly that in the sphere of doom sourceports, multiplayer is often not considered a priority unless multiplayer is the main purpose of the port. That's my guess into why it hasn't come up again. PrBoomX From DOOM With LOVE was created with that in mind, but it was quickly abandoned - that tells me that the demand for such a fork is diminute at best. [citation needed] The Eternity Engine I'll go through these a bit in a sort of rapid fire format, since I sorta think this sorta misses the point a little. The goal of me posting in this thread isn't to make me happy, it's to stop the future posts complaining about the *removal of this feature* and such. PrBoomX - has rewind. I am aware of the port, but it still misses features such as the indexed renderer and lite-UDMF support. Plus it's closer to PrBoom Plus than DSDA Doom, which I kinda see as a con. DSDA Doom runs much better performance-wise. From DOOM with LOVE - I actually didn't realise this was based on DSDA Doom (for some reason I thought it was based on Woof). This is a fair point as it was abandoned. Tbf that makes it all more important to try and get certain features in DSDA Doom, if forked ports are just going to get abandoned. Classic OpenGL Renderer [citation] - This came from a close friend in my Discord server that I'd rather not name drop for his sake. His examples were that Sunlust and Epic 2 were designed with the old OpenGL PrBoom Renderer in mind, and now that that's gone some maps may not look as they were intended to look. However it is not a stretch logically to assume that certain mapsets made around the early 2010s were based on the old OpenGL Renderer light modes. The Eternity Engine - I won't go into detail about how I personally feel about the engine and it's slow development. I will say I'm grateful for what Eternity has paved the way for features added into other ports. The Eternity Engine does have some UDMF support, but of course that's kind of besides the point because it's missing features such as rewind and the new indexed renderer. I don't think it's a stretch that users of DSDA Doom would want a source port to be the best port it could be and that's why when certain features are removed, people ask for them. Perhaps this is the only explanation my brain could come to for why certain features would be cut, as reasons for features getting cut don't ever seem to be explained besides the dev saying that he found them to be unimportant. As Graf Zahl said above, DSDA Doom being placed in the speedrunning thread does overshadow the speedrunning idea all over the port, and if you wanted to disconnect that misconception than it'd probably be better to move it into the source ports subforum. Else everyone (including me) will always look at the port only being directed towards speedrunners. Tbh many speedrunners have voiced their opinions on some of these features (especially about ENDOOM) here and their outlook has typically been that they don't care much for extra features. Every "misconception" has elements of truth and whenever I see speedrunners commenting on these threads, it's mostly to say that the feature isn't important to them. So my logic isn't quite that far of a jump. Perhaps it is only the loud and outspoken that feel this way. The idea of grouping "speedrunners" together was to highlight that depending on how certain people use a program can shape what features they deem important. In a port that is in the "speedrunning" subforum, I think it's a valid concern that users that just play doom for fun also have their opinions heard. When I see people complain about ENDOOM or the old OpenGL Renderer, the response from the dev is often "we aren't adding that back" without any other explanation. This leads to those users thinking that the dev doesn't care about their concerns. I'm not sure if it's because the dev doesn't want to deal with those comments, or they just don't feel the need to elaborate, but it comes off as callous and uncaring.

It's honestly really simple. In a general sense, if you are speedrunner, you care about how fast the program runs and make sure to focus on un-bloating a program with unnecessary stuff that could lead to slower load time. Speaking of ENDOOM, you said that you cut out the original implementation due to bloat. So I would assume that's why the new implementation is much lighter than the previous implementation. However you still get comments on every thread (not by me) about how they find the ENDOOM implementation unsatisfactory. It is true that DSDA Doom does implement ENDOOM in a different way than any other port that also has support for it. By casual audience, I am referring to non-speedrunners. Many non-speedrunners tend to not wanna dabble with BAT files and the like (speaking generally ofc, there are always exceptions). Keep in mind, the only reason I brought this up in the first place is because even before my post, someone asked about a fullscreen ENDOOM. It's clear for the amount of threads and posts that the feature is in demand. Speaking of the removed zoom levels, the only reason I could think to cut that out would also be for bloat. The only players that would ever use that are players that use DSDA Doom casually. There's no reason to mess with that if you are recording demos. My concern is that what you may find unimportant, other players may enjoy that feature, and so it's strange to me that you'd cut something that most likely didn't affect the program in the long run, but just to cut it out (this can be seen as speculation... however I have not seen an explanation to counter it). Perhaps I may be misguided when I say that the source port caters to speedrunners. However it's clear that the speedrunner group cares very little for the ENDOOM features as a whole, and probably cares very little about the zoom feature. Those features however would be something that casual players would be more interested in. The reason I mention speedrunning in general is because you specifically have hammered home that the port was created for the initial purpose of catering to speedrunners, so it would only make sense for decisions to be made to benefit that group. However I do think that some features you deem unimportant (possibly due to your own personal focus of speedrunning) and decide to cut out from the port make it a little harder for casual players to enjoy your port. I think it's much less about the features being removed, and more that they seem like minor things to remove in the first place. I say all this in respect for you and your craft, so don't take this as an attack, but just cuz you find something unimportant doesn't mean other people do. It's a flawed assumption to expect players to just follow along how you think about things, and that's why I find it strange when you respond so harshly to the features that you may find unimportant, and since they keep cropping up, obviously are important to some people. I'm glad that you are adding new features to port. It is true that the new features are for everyone. Tbh I think this further divides the audience as if they want rewind, UDMF, and indexed renderer, there is only one port that supports all of those. And yet this port doesn't support a fullscreen ENDOOM, vanilla zoom, nor classic opengl renderer. It's only natural that many players would ask for the features that have been removed from an advanced port that has features that no other port provides. I'd rather not go into depth about the classic opengl renderer, however I will say that many early 2010 PWADs have been designed around that renderer's light modes. That seems like a valid criticism / ask from players. (even if say implementing the opengl renderer breaks some aspects of this renderer, it goes a long way telling people about why it is currently cut, instead of being abrasive against them). Tbf not everyone is the same, and I'm sure there are going to doomers like you that are fine with how DSDA Doom is. But with some of these threads, and some of the recurring complaints, obviously there are doomers that find parts of the program that bother them. I mean, I'm not the only one that sees that it's just the DSDA Doom that ends up with these kind of threads. Other source ports do not end up this way because they either implement the features or the developers make an effort to communicate with players about why certain features are cut. So far regarding many features of this port, it seems things were just cut because DSDA-Dev didn't see them as important. Most of the time, when devs cut something it's because of a specific reason like it caused [blank] to break or something like that. Many people just feel like DSDA Doom features are getting cut just on a whim, especially minor things that seem to be cut for seemingly no reason. If you wanna know about the features that DSDA Doom lacks, it's some of what I mentioned before: fullscreen ENDOOM, vanilla zoom, classic opengl renderer, etc. Keep in mind, this would be fine if there was another port with similar new features like rewind, UDMF in a classic doom port, opengl indexed renderer also in it. The problem is that if you want those features, especially rewind, DSDA Doom is your only option.

This is a fair point, in that Vanilla did have multiplayer support. I don't think there was any blowback to this because the casual audience doesn't really care for multiplayer support. In general, if you are going to play multiplayer, you'd go towards a multiplayer centric port such as ZDaemon, Odamex, or Zandronum. I think that there is a bit of a difference between the singleplayer and multiplayer "players", and DSDA Doom with an emphasis on new features would appeal much more to singleplayer, than multiplayer. I agree that these threads seem to stem from DSDA Doom trying to serve two audiences: speedrunners and non-speedrunners, and it's sorta causing a divide when some features are removed for the casual audience of the port. These threads are evidence of that. I realise that the port was initially created for speedrunners, but it would be a mistake to ignore that DSDA Doom is the main port used by many casual users. It is the only source port with rewind and an Indexed OpenGL render mode. It makes sense that it would draw in many casuals in general with the technical advancements it has made. I am very grateful to Kraflab and what DSDA Doom has become, but it's also clear that his focus is only towards the speedrunner group, with casual features being pushed to the side (or just straight up removed). I think alot of these threads could be avoided if a specific fork was made that focuses more on QoL aspects and non-runners to make casual players more happy, that pulls in the updates made from the main DSDA Doom branch. Tbh I haven't pushed very hard for a new port or fork, because I am not a programmer that has the ability to make such a port. Plus, it feels a bit hypocritical to me to push for something that I cannot attribute any programming skills to.

I don't necessarily mind this thread being split, as tbh my first post was only half about ENDOOM. I'm actually a little disappointed that the second point has been overshadowed tbh. I do find it a little disingenuous that it is labeled as a "panic" thread though, since I've been respectful and calm this entire time. I'm a little surprised that having a simple discussion would lead to it being perceived as "panicking"... but that is neither here nor there. I would to clarify that this isn't in my best interest necessarily. As I said, personally I could just create a BAT file as I'm well acquainted with them. Yeah I'll agree I'm not crazy about the implementation. In fact, if you've read the entire thread I even say that I just currently have the ENDOOM feature disabled entirely. I brought this up because of the comments that people make on like every DSDA Doom thread about ENDOOM. You can ignore the casual users that don't wanna tinker, but they are going to constantly come back and complain about it... So the next time this topic comes up, it won't be me, and it won't be my fault as I have suggested solutions to avoid ENDOOM ever being talked about again in association with DSDA Doom. I'll check this out, though a viewer in of itself isn't that much of use. It's only if it was tied with the closing of a program funneling the ENDOOM information, that it would become useful imo.

Well tbh the ENDOOM discussion seems to pop up quite often in the DSDA Doom threads. Tbh the only reason I mentioned anything in this thread is cuz someone else mentioned the Windows implementation of ENDOOM and how it disappeared almost immediately. If anything an ENDOOM solution would cause people to stop mentioning it in these threads, and if they did, people could just direct them to a link instead. Tbh the ENDOOM "craze" may have been slightly my fault for starting the ENDOOM appreciation thread in the first place, which still has people posting new and old ENDOOMs of PWADs. Since now that Doomers keep coming across that thread, they now wanna see the screen show up in their ports to appreciate the art.

I actually didn't think of this. I myself have used BAT 2 EXE before, and then used another program to add a custom icon to it. Lol but if Slimm Bat To Exe does both that's even better. To be fair, I think having an BAT file turned EXE would work well. The reason I brought up a new ENDOOM exe is cuz it could possibly allow for more customisation and features specific to ENDOOM only. I could be wrong, but doesn't DSDA Doom export the ENDOOM code into the console while it exits? Couldn't that data just be sent to another EXE without changing too much? I don't see how you'd be required to add back interface code back into DSDA, if you are just sending the data to another program that has that interface code. (Forgive me as I don't know how DSDA exactly deals with ENDOOM code). A third-party program, as I said above, could possibly allow for more customisation and features specific to ENDOOM only. The beauty of this option would be that DSDA-Dev would not have to worry or deal with ENDOOM again. Looking forward, it could also potentially be used by other source ports as well.

It is easier for the user. They just drag and drop an exe in the folder and it works. A BAT file requires you to create a BAT, type in the commands, and if you are using a launcher, you can't launch it using the normal exe. Yeah I'm used to dealing with BAT files, so it's easy for me, but for casual windows users, it may as well be hacking to them. Am I literally the only person that realises that BAT files are not normal for casual users? Casual users just wanna drop a file in and have it work when they run the exe. Quite honestly, causal users would just want the ENDOOM functionality embedded in DSDA Doom... But we can't have that, because DSDA-Dev doesn't want the code in the DSDA Doom. And so I'm looking for other solutions. Plus you ignoring the fact that some users would like a solution that is more similar to GZDoom with a full-screen option. Having a separate program would allow that, possibly with extra options. Who knows?

I was thinking that if dsda-dev doesn't want to develop a ENDOOM-type viewer, another dev could come up with it. Obviously it's possible since other ports like GZDoom have ENDOOM solutions. All someone would have to do is strip just the ENDOOM terminal displaying code and isolate it. Then all that DSDA Doom would have to do then is send the ENDOOM data of the WAD to the separate exe. Plus, I'm not sure what you mean by maintaining two projects. ENDOOM has worked the same for 20 years. I doubt such a program would have to updated that frequently, if at all.

Please don't make this a repeat of what happened the last time ENDOOM and DSDA Doom was discussed. Just as last time, I've been respectful of the dev and the work that they've put in. It's a better idea to try and make everyone happy than try and argue semantics. Obviously there is a reason the dev doesn't want to have the ENDOOM code in. Let's leave that as it is and instead focus on ways we can make the dev's work easier. That's why I suggested a separate ENDOOM.exe solution.

The way ENDOOM works now is that it's actually an output after DSDA Doom closes. The devs wanted to strip out the ENDOOM code (and perhaps a terminal emulator like rformin said) from DSDA Doom completely, so it makes sense if they wanted to make DSDA Doom a bit lighter. I still think that it'd be nice to have a separate ENDOOM.exe program that DSDA Doom could send the ENDOOM information to, have it open after DSDA Doom closes, display the ENDOOM in full screen, and then close on key press. Of course, I'm not an exe programmer (at least to that capacity), so I can't say how difficult that'd be to implement. But it seems like having a separate program could make things pretty simple for the user and easier for the developer. Still I don't wanna say too much, cuz I don't know what it would require to code such a program.

The Quality-of-Life update of 200 Line Massacre has been updated on /idgames! A reminder that this update is demo-compatible with the last "final" version. It just has some fixes for ZDoom, ZDaemon, and now works correctly when used with VULD. It also includes the Unity (Bethesda Port) version of the WAD in the same archive - note that this WAD is incompatible with the non-unity version. Full changelog here: >>>>>>>>>>>>>>>>>>>>>> QUALITY OF LIFE UPDATE - 10/21/2023 <<<<<<<<<<<<<<<<<<<<<<<< This should be the FINAL update for this WAD. It just really bothered me that it didn't work when using DEUSF.EXE (and VULD), even though it was a Vanilla compatible WAD. Once I found the problem, I fixed the WAD and figured I'd include some minor ZDoom port fixes as well.

Use dsda-doom.bat instead of dsda-doom.exe in the Doom Launcher and it will work. You can increase console window size and change font. Right click console window title bar->Properties. I think you are missing the point I'm trying to make. My point isn't necessarily that it's impossible to get something to work the way I'd want. Nor is it that I wanted you to troubleshoot an issue I'm having. The point is that for a person to get the ENDOOM to work in a reasonable way, it requires jumping through a bunch of hoops to get there. Why not just make it easier for the user? Trust me, I can work my way through complex stuff such as setting up VULD with a specific configuration to use DOOM32.EXE and a specific version of DEHACKED with [PARS], all while running DOSBOX with a specific config. I regularly fiddle with the Windows Registry to get certain parts of Windows to do what I want. I even have no problem compiling source code for specific doom ports for testing and troubleshooting. I even code my own infopacks my some of my WADs. I know how to do complicated software tweaking. My problem is that most people do not. Are you going to tell every single person who wants to use the ENDOOM screen in DSDA Doom to create a BAT file with specific arguments to get it to stay? Many casual Doom players may not even know what BAT files are. That is my point, as many users that try and use the ENDOOM option are just going to say that it disappears and just never bother fix it and turn it off. Maybe I would agree with your point if it was a parameter like -file or -complevel, but I think BATs and console arguments are a bit much for many modern users, especially nowadays. For someone who uses DOS or Linux, maybe, but not for many Windows users. I'd just like to clarify that this is not a heated statement, I'm just trying to clarify, in detail, what I meant when I said DSDA Doom's ENDOOM support was poor. It is through the eyes of a casual player that just wants to play using a somewhat accurate sourceport and wants to have the ENDOOM screen shown on close. (Before you say "oh just use Woof", I'm not a particular fan of how the rendering works in Woof or Nugget Doom. There's something about how DSDA Doom renders high-resolution that is unmatched in demo-compatible sourceports imo).

This would not help my case, because I use Doom Launcher to manage my hundreds of WADs. Even so, if I used ZDL or some other launcher, the fact that I need to create a bat file or run it through the console is poor user experience imo. Even so, wouldn't it make more sense to just execute the "pause" command by default? (Forgive me as I do not know how the DSDA Doom code works, so it's possible that it doesn't work that way). I'd assume anyone on Windows (or any OS) who would set ansi_endoom 1, would want it to pause by default anyway. There's no other reason they would set that option, unless they wanted to see and look at the ENDOOM. It seems like a bad idea to make particular launchers to have to add their own support for the "pause", rather than just implement it in the engine itself. Then you'd run into every launcher having to add support for this specific use case for this one specific engine. Then again, I've never been a huge fan of printing the ENDOOM in a small console window anyway (I'm not going to argue about how it should be done, since I don't know how the engine is coded). I will however give my experience as a user of the engine itself, and currently I'd say with how the ENDOOM implementation is, it isn't even worth me turning on honestly.

So I didn't say anything previously, because I was debating whether I wanted to stir the pot or not, but I think I should at least give my thoughts on a couple things, since DSDA Doom is my main port of choice - It is the port that I enjoy playing on the most, both for it's rendering and "game feel". 1) I'm glad that since version 0.27, turning on ENDOOM no longer results in DSDA Doom hard crashing when exiting. Though I will say that with my experience on Windows 11, how ENDOOM is implemented is absolutely useless and so I just end up turning it off. Having it print in the console window and just immediately disappear is quite lame, and is basically the equivalent of just not seeing the ENDOOM at all. I'm not saying this to stir more controversy, I'm just telling you how it currently is. I think I've seen certain people recommend to use different default consoles to stop it from just exiting, but honestly I think that it should not be on the user to have to do that. Having to change a default console on Windows just for DSDA Doom is quite honestly ridiculous. This is all I will say on this matter, as I do not want a repeat of the previous ENDOOM clusterf---. 2) This was actually done in the latest major release of DSDA Doom, but I'm not really a fan of removing features from the port that were in the original Doom. To this point, I am specifically talking about the screen zoom being removed. You'd expect source ports to generally keep features included in the original game, and expand features on top of it. It seems strange to me, for original features to be stripped out (just to clarify, I am not talking about ENDOOM here, as ENDOOM is technically outputted after the program is closed, so you could see it as not part of the original game in a way). I'm not saying I actually use this features (I don't), but it's more about what removing this features means for the future. It means that you have no problems stripping out other stuff from the game that was there originally, and that honestly concerns me. What other features will you decide to strip out of the port, since original features such as that have been removed? I often tend to joke about this with other Doomers, but I do find it a bit worrying... I can't wait to see the HELP screen get removed in a later update.

I may look into this, however it's a bit trickier than it may seem. While many of the weapons are stronger, for balance reasons there are also some changes that can be seen as nerfs. For example, while the plasma gun and bfg are more powerful, the max ammo capacity for both weapons has been diminished for balancing. Regarding the chaingun, chaingunners do not drop chainguns and instead clips as I found the chaingun to be too powerful to be acquired by chaingunners themselves. Perhaps one of the most interesting changes is that the players starts maps with 0 pistol bullets instead of the usual 50. My point is that all these maps in this mapset have accounted for these changes, but there's no guarantee that all maps played with the add-on would be balanced. The question comes if I were to make this an add-on, it'd probably need some of the monster changes as well, for overall balancing? Though perhaps that is not as big as an issue as I am thinking it is...

Introducing RC3! >>>>>>>>>>>> DOWNLOAD HRs <<<<<<<<<<<< We came, we saw, we kicked some bug ass! I'm proud to announce this update allows for MAP30 to work correctly in ZDaemon and ZDoom ports. This is all thanks to the hard work by @Worst to create an amazing ACS solution! Another large thing to point out is that MAP02 has been updated! It seems that the mapper used HNTR to include the most difficult difficulty of the map. That has since been remedied and now the difficulties should be consistent with the rest of the megawad! In addition, the map has had a minor visual facelift. Thanks to @bioshockfan90 for pointing out MAP02's HNTR difficulty being crazy, or we wouldn't have known about it. Here is the changelog for RC3:

Tbh if I find that someone plays my map incorrectly or skips some progression during testing, I tend to adjust my map to accompany that skip. I don't like forcing players to play my maps in the exactly the same way as I play them. While I think it's nice to have a "mapper intended" way of completing a map, I find some exploits fun and make the map more interesting. The only exploits I tend to remove and/or fix are ones that result in the map breaking and/or getting softlocked. For example, in alot of my Boxcutter maps, I almost have two progressions for many of the maps. The normal progression and the speedrunner progression. For example in MAP05, you can play through the map normally and it take around 5-7 minutes, or you can do a tricky platforming sequence at the start, grab the rocket launcher, and rocket jump across the gap into the exit in around only 10 seconds. My goal with having more than one progression is to create fun for as many people as possible, and just cuz you may not be able to do the 'secret' speedrunner progression, doesn't mean you can't enjoy the maps.

Btw thanks @Andromeda for sharing this. I've updated both HR and HR II Doomwiki pages to mention Yonatan's approval with your source. Previously, only HR's page only mentioned it, but without a source, while HR II's page had absolutely no mention.

Finally finished streaming through the rest of Hell Revealed (UV pistol start MAP24-MAP30). I think I came out of playing HR liking it a bit more than I originally had, interestingly. However, there are some maps that I remember hating, that I ended up hating even more as well. It's definitely a mixed bag, but I think that HR is definitely worth playing just for maps such as Last Look at Eden, The Path, Resistance is Futile, Post Mortem, Dead Progressive, Afterlife, etc. It is true that the the first episode of HR, is a bit of different beast but I do think it has its own charm. In short, when HR is good, it's good, but when it's bad, it's really bad. Anyway here's my review of the final maps:

Replaying moar Hell Revealed on UV! (MAP24-??) https://twitch.tv/arsinikkdm

People are asking why because they don't understand why you would want what you've asked for. There's a reason why most people don't use or want to use a DOS-like interface. If you want a DOS-like interface, just use DOSBOX to emulate DOS itself, it's as simple as that. "why" is actually a very important question to answer, especially for sourceport developers. They have created sourceports for a particular reason and/or to solve something that was lacking before making their own sourceport. Unfortunately, if you want something that's super niche and is something you and only you want, you would have to make it yourself. Especially since what you've been asking for isn't what's in demand. Then again, how would we even know what you want, if you don't answer the most important question: why. I can see why some people would want the DOS experience, but we already have DOSBOX to provide that. If you really wanted a sourceport like experience in DOS, I'd suggest just using VULD and perhaps an executable hack like DOOM32 to be able to play some more modern limit-removing WADs. Either way the reason most people have strayed away from DOS is because it is quite a bit of work to set up correctly, and if you aren't willing to put in the effort, frankly you shouldn't be dabbling in DOS at all imo. Personally I have set up VULD and just have a few BAT files set up to just run custom WADs in Doom32 at the click of a file.

>>>>>>>>>>>>>>>>>>>>>> QUALITY OF LIFE UPDATE - 10/21/2023 <<<<<<<<<<<<<<<<<<<<<<<< 200 Line Massacre has a new update to fix a few minor things with certain ports. Note that this new version is still demo compatible with the previous version, as it does not change any maps or DEHACKED. Below are some of the changes made: QOL Update Changelog: /idgames: Download Now (new version - 10/21/23)

In a way, you could say that. I led a recent HR I and II inspired project called Hell Revealations. I'd probably call it more of a love letter to both Hell Revealed and Hell Revealed II, in that it takes elements of both to emulate the best of both WADs (obviously subjective). Also, technically Doomer Boards is doing the "official" Hell Revealed III, but after playing the part 1 demo, I don't have much hope on how faithful of a sequel it will be. TBH that was part of the reason I wanted to do a Hell Revealed style project is cuz I felt that I understood what made Hell Revealed 1 and 2 so Hell Revealed-like.