Doom Mod Loader

Hi everyone!

Publishing a new version at the end of April it's starting to become some kind of ritual...

Once again, special thanks to eviltechno, who helped me a lot with the testing of the Windows version and by suggesting almost all the new features, without him probably this version would end up be just a Linux port. Speaking of Linux, v2.5 is the first DML 2.X version that is NOT a Windows exclusive (more on that later).

Without further ado, here the full changelog. Below you will find a more in-depth explanation of the main new features.

Changelog 22/04/2022 - v2.5

(This is the latest changelog. You can read all changelogs here P36software.net)

NEW FEATURES:

• Now it works under Linux/Mac through mono (Be sure to have downloaded the mono version, the one with "mono" in the exe name, and follow the instructions otherwise it will not work!)
• The preset name it's now fully visible while browsing the preset list, no matter how long the preset is.
• Mods list "Order By" value it's now kept between application launches.
• Preset order can now be changed via the software settings. Possible order are "Alphabetical - Ascending", "Alphabetical - Descending" , "Date - Ascending" and "Date - Descending".
• Mods list can now also be ordered by "Date - Ascending" and "Date - Descending".
• Added a workaround that mitigate the gzdoom bug where quicksave made with 'BIND [KEY] "SAVE QUICKSAVE.ZDS"' are saved in the wrong folder. Can be enabled in DML 2.X preferences. (Windows/Linux only) .
• In the mod order window, the selected mod can now be pushed directly to the top/bottom of the list also by using pageUP/pageDOWN.
• Now the mod that you always use can be placed in a preset and loaded automatically each time you play, just select the preset in the "autoload" combobox in the "Game" section of DML 2.X.
• Updated the renderer selection in order to work with the newest gzdoom releases.
• Added a monero address in the welcome/about windows and readme txt, in case anyone wants to donate.

BUGFIXES:

• Fixed bug where the DMLv2.ini will store the whole path of the alternative sourceport configuration file instead of just the name, making DML 2.X not fully portable.
• Fixed bug where the "please insert a preset name" error message had of a information icon instead of an error one.
• Fixed bug where the mods list extension filter only showed matching file that had a lowercase extension. Now it shows all matches.

NEW SETTINGS:

• RENDERER2
• FILE_ORDER_BY
• PRESET_ORDER
• GZDOOM_QUICKSAVE_FIX
• AUTOLOAD_PRESET

SUPPORTED SOURCEPORTS:

As for this version, the only tested sourceport are (Remember that as long as it follows the zdoom command line standard, any engine should work fine):

FULL COMPATIBILITY:

• GZdoom (v4.7.1, -height and -width do not work due to gzdoom way of handling resolution)
• LZdoom (v3.87c)
• Zandronum (3.1)
• Zdoom(2.8.1)
• QZDoom (2.1.0)
• Skulltag(98d)

PARTIAL COMPATIBILITY (Some DML features will not work):

• Chocolate Doom (3.0.1)
• PrBoom+ (2.6.2)

Let me explain a bit the most interesting features:

• Now it works under Linux/Mac through mono (Be sure to have downloaded the mono version, the one with "mono" in the exe name, and follow the instructions otherwise it will not work!)

There are now 2 version available for download, the "Windows" and the "mono" version.

If you're on windows you just need an up-to-date windows system (7/8.1/10) and .net framework 3.5, so the same requirements as any other DML release.

If you're on Linux/Mac OS you'll need to install "mono" on your OS, which is an open-source equivalent of .net framework and enable .net framework windows executable to run on non windows OS.

Note that while it SHOULD run on Mac OS, I've NEVER tested it under that OS as I don't own a Mac. While on Linux I've been using it on Linux Mint since I started the port. While both "Windows" and "mono" downloads are in the end a windows .exe, the "mono" version have a few difference that I had to make in order to make it run under mono. You will find the download for the mono version and more detailed instructions here (as it's NOT a native Linux/MacOS application) Github.com

Also, only on Linux (can confirm on mac os as I don't own one) as a plus I've not coded but came free by using mono... DARK THEME! It follows your system settings, if you're using a light theme it will look similar to how it looks on windows. As it's not something that I've coded, there is no way to toggle it via DML 2.X itself.

• Added a workaround that mitigate the gzdoom bug where quicksave made with 'BIND [KEY] "SAVE QUICKSAVE.ZDS"' are saved in the wrong folder. Can be enabled in DML 2.X preferences. (Windows/Linux only) .

This gzdoom (and also Zandronum, being it based on an older gzdoom version) bug as hunted me for quite a while, I had sometimes someone reporting it to my and I couldn't recreate it, until eviltechno explained to me this alternative quicksave method. While gzdoom have already a ready to use quicksave function, it will prompt the first time the user to select the saving slot, and from the second time (until the software is closed if I recall correctly) will ask for confirmation. To some user this is an unacceptable 2 step process, so by using the console command written above, replacing [KEY] with any keyboard key ("F6" for example), the user can make a "very-quick-quicksave™", that will create and overwrite over and over again a "quicksave.zds" without asking for slot or any kind of confirmation. The issue was that on Windows this quicksave.zds file, if the gzdoom process was started from another process, it would not be created in the "Save" folder next to the gzdoom executable but instead it would create it next to the DML 2.X exe. Until gzdoom it's running it will still save/load fine, but once it's closed, the next time you boot it up you're savegame will be missing from the list, while it's still there next to dml 2.x, but gzdoom looks only in the save folder, as it's where all save should normaly be.

This does not happen if you use the normal quicksave or don't use a frontend, and I don't know why it happens, my guess it's that inside gzdoom there should be some kind of function that generate a path to where the save file, based on the gzdoom exe location, but that somehow it get "confused" if the gzdoom process is started via another software, and that maybe it mistake the DML 2.X as the gzdoom process and so it mess up the location, but I really don't know. On linux it's also bugged, but it saves it in the user "home" folder.

So my "solution" (which is really a workaround since I can't really fix this) it's to look for any .zds file in the dml 2.x folder (or "home" folder on linux) and moving it to the correct one (which is different in windows and linux) once you've closed the sourceport. Note that has been tested only with recent version of gzdoom/zandronum and on linux as been tested with only version installed trough apt. If for any reason future gzdoom/zandronum releases change saving location this fix will stop working, so by default it's disabled. You can enabled it in the DML 2.X "preferences" window. If you don't use quicksave made trough the custom method explained above you don't need to enable it as this gzdoom bug it's not afflicting the normal saves/quicksaves. If you're on Mac OS do not enable it because it will not work. Take a look to the readme for more info.

• Now the mod that you always use can be placed in a preset and loaded automatically each time you play, just select the preset in the "autoload" combobox in the "Game" section of DML 2.X.

This one is if you have a few "quality-of-life improvements" mod that you always play, like the doom minor sprite fixing project, or for example a sound replacement for the plasmagun etc... With this new feature you can select one preset, as an "autoload preset" in the game section. The idea is that you make one (ore more) autoload preset that contains only your quality-of-life improvements" mods (I personally have one general autoload preset and one for tnt.wad, that include also the secret level yellow key fix). The autoload preset mods will load in the order you've setted them up in the mod list, AFTER all other mods, so they always have the priority over anything you load. Take a look to the readme for more info.

• Updated the renderer selection in order to work with the newest gzdoom releases.

Since a few updates ago, gzdoom no longer have a single renderer option, but your render it's selected by using two values, one for the API backend (the value on the left is the backend on posix system like Linux/MacOS while the second value it's on Windows) and the other one it's for the render mode itself. If unsure on what those setting means or you're using an older gzdoom version that still use the old system, leave it to the "DONT OVERRIDE" setting or select "SDL + OPENGL | OPENGL" and "HARDWARE ACCELERETED (OPENGL)" or "DOOM SOFTWARE RENDERER". From my experience and by reading some post, the vulkan backend might be a bit faster then the opengl one if you're running recent hardware, the GLES2 it's usually the best on old/low end hardware but it may have some graphical issue in complex mod. Try to play around with them, personally having a 8 years old machine running Linux Mint I use the GLES2 for the newset and complex mapset that require hardware acceleration, I use opengl with doom software renderer for old classic mod/ original IWAD and i use the standard opengl hardware acceleration for older gzdoom mod (like Psychophobia). Take a look to the zdoom wiki for more info zdoom.org.

Note that this option overwrite the relative values in the gzdoom ini, it's not just a per-session setting, so the "DONT OVERRIDE" option will not override the current settings, but if the current setting it's already been changed by a previous launch it will still use the last selected renderer and not the "original" one.

Also note that while the newer version seems to no longer support the old softpoly software rendererers, I've still leave them in the list (with an "unsupported" warning) so if you need them, and you're using an older gzdoom version you can still use that renderer.

Also if using an older gzdoom version that does not use the 2 values but just the +vid_rendermode one, select "SDL + OPENGL | OPENGL" in the +vid_preferbackend field and then select the renderer like you would have done in an older DML 2.X version

Since 2.2b I've been saying that this version will be the last, and here we are 3 main updates later, where I still say that this version will be the last. Well, sort of... Let me explain: The more I've worked on the project the more I've realized of bad I've made it's "foundations".

It all started in 2016 as an experiment as I was learning VB6 at school (yeah, the 90' language... you still be surprised that it's actually quite used in today business, in the last place I worked this basic (pun intended) VB6 knowldege has come handy as the main project I worked on was a revamp in C# of an old VB6 set of softwares). DML 1.X is a VB.NET software but the syntax was quite similar to VB6. At the begginning of 2019 I've started working in a software house that coded mainly in C#, so to experiment with the language I've had started working on DML 2.X, for like half a year it sitted only as a GUI (no code logic was written) in my hard drive.

Later I decided to finish it, so I started working on it on and off in my spare time and in July 2019 I've release the first version of it. It really started as a one off project, something that I will publish an probably forget about really soon. But I started to get some attention, people started giving me feedbacks and suggesting new features, so I've started adding this features, and updating my software, but as at the time I didn't really any do any reaserch about "winform", so I didn't know it has been for a long time a dead platform. Also as I didn't know how to "plan" a software, and If a knew how to do it I still wouldn't probably care to do it as tought this will be one of my many "one off" projects. If you noticed I've started calling 2.X only from later releases (the software logo/icon still says "DML 2.0" to this very day!). So it ended up being a project really hard to maintain and to work on it, there are still some feature that I would have included but are still missing as those either required some wacky hack to work on winform or require ti have to change to much stuff, as again this project has really bad foundations, that were fine for what I think at the time of the project, but not adequate for what it become.

So from this release, excluding an eventual 2.5b for bugfixing, the 2.X brench of the project have reached it's end. Does it mean this is the LAST ever DML release? No. There WILL be a next future release. I plan to start a new 3.X version from scratch, but this time having some good, strong foundations. I plan a better, more modern and resizeble GUI, full support for non zdoom like sourceport, a true standalone version for Linux (and hopefully Mac OS) plus all the missing features that I've not been able to add, and a dark theme also for windows user. So will this 3.X version come out soon? Once again, no. Given that I also want to dedicate more time to my other project, and that I've also kinda starting a bit to burn out more and more with each DML release, and given that other that the few lines above I've have absolutely zero ideas on how to do it, it will take quite some time, probably years before the first 3.X version is out. But yeah this project it's not dead :)

The mono version does NOT have a new version notification and require some extra step in order to work. Read carefully the download page! Also remember that it should work on Mac OS, but I couldn't test it, not even booting it up. So maybe it wont even start. Or maybe you need to do some more extra step that I don't knwo nothing about.

For the next few hours the windows version will prompt you to download the 2.4, which of course it's the old version. Once I've update the version number on my server it will stop doing that.

I usually update the server version number as the last step I do in a release because it will rollout the update notification to the over 6000 users of the 2.4, so I'm very careful and release it very slowly, before on github, then on modb, then I made a moddb news and only later the full rollout, once I'm sure there is nothing wrong with the release.

Long story short, on the mono version the update notification is missing and you'll have to check it out manually on github (or my twitter @p36software) and for the windows version ignore the new version notification, I'll update it in a day or two

If you're upgrading from an older version, you will find the instructions in the download page, be sure to backup your CONFIG folder somewhere, so if anything goes wrong while updating to the new version you don't have to reconfigure everything from scratch.

Also note that you made need to update your presets in order to work with the new settings, to do that, just save again the preset by verifying that all checkboxs of the information you want to save in a preset are checked and click "update". This will update the preset in order to be 100% compatible with the new version. You don't need to to that for all preset, just for the one that you've stored the renderer. All older preset should work out of the box (Take a look to the "how to update from an older DML 2.X version" section in the download page for more info)

If you find any bug with this version please report it trough github (if you're familiar with it), or by sending an email at support@p36software.net with subject "DML 2.5 *Here your OS* Bug - *Here describe the bug in a few words*" and in the mail itself try to explain with much accuracy and details as possible what happened, what did you expect it should have happened and a step by step guide on how to reproduce it, as if I can't reproduce it on my end, I can't fix it.

If you're interested in my softwares, games, open source projects or just want to contact me, you can find me here:
Website: P36software.net
Support e-mail: support@p36software.net (for reporting bug/give feedback/ask for help)
Info e-mail: info@p36software.net (for anything else)
Twitter: Twitter.com (@p36software, gets updated more often)
Github: Github.com
ModDB: Moddb.com
IndieDB: Indiedb.com
Youtube: Youtube.com

Once again, thanks for your support, you're all amazing! <3
-Matteo