NightFright Posted January 19, 2023 (edited) I don't see the need of defining a Windows-wide variable for a port that I have been using since ages without needing that. For the time being, I guess I'll keep using my "custom DLL mix" version which works fine. Just for the lulz, I tried setting the Windows var and that worked. However, with several iwads located in the same dir, it would only choose the last one, so it's not exactly an ideal option. Edited January 19, 2023 by NightFright 0 Quote Share this post Link to post
mikeday Posted January 19, 2023 With that variable set, you can specify IWADs by name only (doom.wad, doom2.wad, etc) and source ports will automatically find the file in the specified directory. It’s pretty much a game-changer if you run from command line. Most source ports will also search for PWADs in that directory (and in the directories listed in DOOMWADPATHS) as well. 2 Quote Share this post Link to post
NightFright Posted January 19, 2023 Still, this doesn't explain why relative paths work with my custom build and not with the one posted by Never_Again. 0 Quote Share this post Link to post
Never_Again Posted January 19, 2023 Relative paths work just fine with my builds; yes, I have tested that. It's the code straight from the master branch, my only addition being the -mconsole flag for the linker to make a working console. The problems you are having with the builds are not due to the builds themselves but with how you run them. Yes, you can use relative paths if you want to; but you need a firm grasp of the "working dir" concept and to be able to account for the different ways it is set under Windows, depending on the invocation method: command prompt, batch file, shortcut, call from another program etc. re: "since ages": %DOOMWADDIR% was in prboom at least five years before prboom-plus was a thing: In light of the above 52 minutes ago, NightFright said: I don't see the need of defining a Windows-wide variable for a port that I have been using since ages without needing that reads very much like "I don't see the need for a fishing net because I have been catching fish with my bare hands since ages". :) 1 Quote Share this post Link to post
mikeday Posted January 19, 2023 As I suggested earlier, it would helpful if you shared the command-line output so we can see what might be happening. 0 Quote Share this post Link to post
NightFright Posted January 19, 2023 Output.txt remains empty when I append your command. My start.bat looks like this: prboom-plus.exe -iwad iwad/doom.wad > output.txt 2>&1 0 Quote Share this post Link to post
mikeday Posted January 19, 2023 Try a backslash instead of a forward slash. 0 Quote Share this post Link to post
rfomin Posted January 19, 2023 Do you have non-Latin characters anywhere in your paths? Recently there have been changes related to this. 0 Quote Share this post Link to post
NightFright Posted January 19, 2023 (edited) Backslash (-iwad iwad\doom.wad) = same result. The path to my test build is C:\Users\firstname.lastname\Downloads\prboom And before you ask: It also doesn't work when I make it as easy as possible, i.e. C:\prboom Edited January 19, 2023 by NightFright 0 Quote Share this post Link to post
mikeday Posted January 19, 2023 The fact that there’s no output makes me think that there’s something weird happening here. What happens if you try to run directly from the command line? (No batch file) 0 Quote Share this post Link to post
NightFright Posted January 19, 2023 (edited) So here's the latest: If I replace prboom-plus.exe provided by Never_Again with the one taken straight from Github Actions, I am able to launch everything just fine, provided I copy over the following DLLs from the "Windows Dependencies" package (or just rename the corresponding files from Never_Again's release): dumb.dll (libdumb.dll) libfluidsynth-2.dll (libfluidsynth-3.dll) pcreposix.dll (libpcreposix-0.dll) portmidi.dll (libportmidi.dll) vorbisfile.dll (libvorbisfile-3.dll) Attaching new functional build. PrBoom+_(v2022-12-30).zip Edited January 19, 2023 by NightFright 0 Quote Share this post Link to post
Hitherto Posted January 26, 2023 That is wrong with prboom+ (and it's derivatives with lmp-footer feature) if it attempt to _silently_ play demo if any or all specified by footer wad files are missing? Or it is just stupid me missing something? 0 Quote Share this post Link to post
Never_Again Posted January 27, 2023 That happens when Getwad is not set up in prboom-plus.cfg. The entry is in the "Prboom-plus demos settings" section and should look like this: getwad_cmdline "c:\DOOM\getwad\getwad.exe -d "d:\WADS"" 1 Quote Share this post Link to post
Hitherto Posted January 27, 2023 (edited) Excuse me but this is too complicated solution for doing quite simple thing, which btw already exists in prboom+ for pattern-driven automated demo playback. Edited January 27, 2023 by Hitherto 0 Quote Share this post Link to post
ImproversGaming Posted January 27, 2023 Hey @rfomin and others, I had a query to my YouTube channel from someone who has a non-latin character in their Windows username that is in the path for their Doom directories. I recreated their directory structure and tested it and although it is fine for PrBoom+ it does not work for DSDA-Doom. Found your comment so thought I would ask. Is there a suggested approach to help with this (like environmental variables or something else)? Details of my test: Spoiler I ran these two tests: (1) [ This one fails - tests DSDA-Doom with a folder name space and an "á" ] “D:/Users/Seán/Documents/DooM/Source_Ports/dsda doom 0.25.6/dsda-doom.exe” -iwad "D:/Users/Seán/Documents/DooM/DooM WADs/DooM/DOOM2.WAD" DSDA-DOOM ERROR: "Unable to find the required file "dsda-doom.wad"" (2) [This one works fine - tests PrBoom+ with a folder name space and an "á"] “D:/Users/Seán/Documents/DooM/Source_Ports/prboom-plus-262-w32/prboom-plus.exe” -iwad "D:/Users/Seán/Documents/DooM/DooM WADs/DooM/DOOM2.WAD" Original comment I am responding too: Spoiler On 1/19/2023 at 3:42 PM, rfomin said: Do you have non-Latin characters anywhere in your paths? Recently there have been changes related to this. 0 Quote Share this post Link to post
rfomin Posted January 28, 2023 4 hours ago, ImproversGaming said: it is fine for PrBoom+ it does not work for DSDA-Doom Yes, DSDA-Doom didn't merge changes needed for non-Latin characters support. We can try ask @dsda-dev about it. 2 Quote Share this post Link to post
dsda-dev Posted January 28, 2023 The related commits are in the queue. There are important changes in those commits that I can't just cherry pick. It's on the to-do list but I don't know when I'll get to it. Maybe for 0.26. 4 Quote Share this post Link to post
ImproversGaming Posted January 28, 2023 Really appreciate the feedback on this. @rfomin thanks for the responsiveness and for extending the request! @dsda-dev there is no rush or pressure, I was just interested. Many thanks for letting me know. 0 Quote Share this post Link to post
fabian Posted January 31, 2023 I'd like to inform you that my dsda-doom package has just been accepted into the Debian archive. What doesn't sound like a big deal comes with some implications. This package demotes the prboom-plus package to a transitional dummy package. This means that users who ask to install the prboom-plus package will get dsda-doom instead. 10 Quote Share this post Link to post
Danfun64 Posted February 2, 2023 A bit surprised there wasn't an option for both, seeing that PrBoom-Plus 2.6.2 is a thing and there are a handful of newer PrBoom-Plus features (like the aforementioned Non-Latin support) that DSDA-Doom hasn't implemented yet. 1 Quote Share this post Link to post
fabian Posted February 2, 2023 1 hour ago, Danfun64 said: A bit surprised there wasn't an option for both, seeing that PrBoom-Plus 2.6.2 is a thing Honestly, no, it isn't. 1 hour ago, Danfun64 said: and there are a handful of newer PrBoom-Plus features (like the aforementioned Non-Latin support) that DSDA-Doom hasn't implemented yet. This is about Linux. We don't have problems with non-Latin file names over here. ;) 6 Quote Share this post Link to post
jerk-o Posted February 3, 2023 Is there any particular reason for the switch? 0 Quote Share this post Link to post
fabian Posted February 3, 2023 PrBoom-plus doesn't get any active development anymore. Dsda-Doom is actively developed based on its code base, so it's the logical successor. 10 Quote Share this post Link to post
fabian Posted February 4, 2023 @Never_Again I'd like to tag a final release in the source repository this week. Will you be there to provide the "official" Window binaries? 4 Quote Share this post Link to post
Consummation Posted March 24, 2023 nooo i need my colored blood in prboom 0 Quote Share this post Link to post
Redneckerz Posted March 24, 2023 44 minutes ago, Consummation said: nooo i need my colored blood in prboom Use DSDA then. PrBoom is discontinued. 0 Quote Share this post Link to post
Consummation Posted March 24, 2023 (edited) 5 minutes ago, Redneckerz said: Use DSDA then. PrBoom is discontinued. As far as I know DSDA does not have colored blood Edited March 24, 2023 by Consummation didint tag 1 Quote Share this post Link to post
Redneckerz Posted March 24, 2023 7 minutes ago, Consummation said: As far as I know DSDA does not have colored blood Apologies, i mean Crispy Doom. There is also a patch to add Colored Blood as a Dehacked patch. (This is a different one, i can't find the other one) 0 Quote Share this post Link to post
Consummation Posted March 24, 2023 22 minutes ago, Redneckerz said: Apologies, i mean Crispy Doom. There is also a patch to add Colored Blood as a Dehacked patch. (This is a different one, i can't find the other one) Im currently using prboom+umapinfo 2.62 or the one that was last updated in Feb of 2022. I was not aware of a patch for the colored blood for dsda doom, thank you for the education as well as your work on the doomwiki 1 Quote Share this post Link to post
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.