Shepardus

Doom is 3D, and since when was stacking rooms on top of each other a requirement of FPS games?

This is weird, it appears to be a Boom demo (at least that's what dsda-doom says in the terminal when playing back the demo). The demo plays back fine in dsda-doom but desyncs in Woof.

There should be a yellow key here near the yellow key door: Beyond the yellow door are two switches that require the red and blue keys. Using those reveals a third switch, and using that should open the way to the exit here:

There's a setting in SLADE to disable the "no modifying IWADs" guard, which is mentioned earlier in this thread. No need to hex-edit your WAD for that. As for merging the WADs in SLADE, maybe one of the remove/check duplicate functions in the Archive -> Maintenance menu would help. I feel like something in DoomTools should be able to help too, but haven't looked into it.

Yes, that is the all-ghosts glitch. It just happens a lot on Nuts due to all the enemies in an open space. Others playing back your demo will see the same if their source port has intercept overflow emulation (which includes dsda-doom, Woof, and Chocolate/Crispy Doom). Many people play Nuts with intercept overflow emulation disabled, which you can do for vanilla complevels in dsda-doom and Woof, and is always the case when using Boom or higher complevels.

Probably relevant (and fixed for the next release):

None of those [ or ] characters should be there, that's just how the documentation shows optional parameters. The boolean parameters should be either true or false, no "bool" declaration on that value. PlaySound(44, "ALLARMSTART", CHAN_BODY, 1.0, true, ATTN_NORM) (I excluded the "local" parameter because you didn't set that to either true or false)

I think this is it, though the author is from the Netherlands rather than Spain as claimed in that tweet: Blog post - https://th0mas.nl/2022/07/18/porting-doom-to-a-payment-terminal/ Talk - https://media.ccc.de/v/mch2022-224-payment-terminals-as-general-purpose-game-computers Slides - https://th0mas.nl/downloads/presentation_vx820_mch2022.pdf Appears to be an actual port to a proprietary operating system making use of a bootloader vulnerability, rather than someone just stuffing different hardware in its shell.

^ That post above doesn't seem relevant, but this one is: Your version of GZDoom is probably out of date.

I was so ready to barge into this thread and reply "no" to the title that I wasn't expecting the bump to be from someone who actually did it. Very nice, this fills a major void in the source port landscape!

Much better! I only played a bit, but it's very promising, I'm looking forward to playing the rest!

Can someone give me a hint as to what's supposed to happen? I feel like I'm either blind or the WAD got updated and something broke, because all I see upon warping to MAP21 is and yes, I am playing on complevel 9.

If you include an OPTIONS lump in your WAD, you can adjust some of the compatibility settings that your WAD needs even if someone uses -complevel 21. I think the friendly monster behavior is tied to comp_pursuit, and this was one of the flags whose default was changed between complevel 11 and complevel 21, so if you put "comp_pursuit 0" in the OPTIONS lump it should restore the MBF behavior (it also affects enemy infighting behavior, which is why the default was changed for MBF21).

dsda-doom and PrBoom+ have the -geom (or -geometry) parameter to set the resolution and whether the game's fullscreen or windowed (e.g. -geom 1920x1200f for 1920x1200 fullscreen, -geom 640x480w for 640x480 window). I sometimes use it to run the game in a small window when grabbing a screenshot. There's also -fullscreen, -window, -width, and -height to set each of those individually. Another one I use is -vidmode (sw or gl) to set whether to use software or OpenGL rendering. In my launcher I have separate entries for dsda-doom and dsda-doom with OpenGL rendering (this dates back to when PrBoom+ and GlBoom+ were separate programs, but I've kept it like that because I find it convenient). I used to have the GL one run a shell script that launches dsda-doom with a separate config, but by using -geom and -vidmode instead of -config, I've gotten rid of the need to maintain a separate OpenGL config file in sync with my main config; the OpenGL script just launches dsda-doom with the usual config and adds "-geom 1920x1200 -vidmode gl" to the parameters (the -geom is because I run software rendering at a lower resolution). dsda-doom has the -assign parameter to temporarily change a setting without saving it to the config, which I find useful in a variety of situations (testing settings, changing settings while -viddumping a demo, switching to a different input profile that unbinds the restart level button while in an ironman run). I was also using it for my OpenGL script until just now because I only discovered the -vidmode parameter while writing this post (I was doing -assign videomode=OpenGL). I also use -noautoload with dsda-doom when recording demos to avoid loading cosmetic WADs that I have in my autoload folder, which aren't allowed by DSDA rules. This parameter is also available in Chocolate Doom, Crispy Doom, Woof, and Nugget Doom, but with the latter two it also prevents loading the extended HUD, which I don't want to skip (I also never bothered putting anything in my autoload for those ports so I don't need to use -noautoload anyway). dsda-doom writes stats to the dsda_doom_data directory, so when I don't want to track my stats (e.g. I'm just testing a WAD and don't intend to play through the whole thing) I use the -data parameter to redirect those stats to my /tmp directory (note that this is also where save files go, the -save parameter doesn't seem to work with the "organize my save files" feature).

Sadly it was not to be... Category 2 Dead on MAP01 (1:06, 30 kills) ironman_Shepardus_aaliens.zip