GoneAway

How about a max tas? :^)

Are you ok?

No, the demo file says where it starts and all the inputs that were made, but you can't tell when an intermission or exit happens.

Please post the demo and link the wad if possible. I won't be able to check until I'm back from the holidays, but maybe someone else can.

That's one of the new comp options: https://github.com/kraflab/mbf21/blob/master/docs/spec.md#new-comp-flags

Are you using the same music backend? If I remember correctly, not all types work in all options, although I'm not completely sure how it all works. I'm not aware of there being any differences in the code base related to music.

Ya, if a thing isn't flagged as the kill counting, then the kill doesn't count. That seems clear cut to me. Such things aren't monsters. The only person who should own that choice is the wad author, and if it seems wrong by either choice or misadventure, it nevertheless is what it is. If you're going to start upgrading objects to monsters, why aren't you also opening unmarked secrets for instance? Those are as much of a glaring omission for the spirit of max, if you want to bring spirit into it instead of going based on what the engine counts.

Early contender for wad of the millennium

Updated to v0.22.4 Small bump before holiday vacation :^) What's New: Improved exit sequence priority Demo files are written before doing anything else when exiting the game The port will now attempt to write a demo file even if it crashed Removed -statdump (obsolete and not maintained) Fixed an issue with casual format demo playback (only affected playback) Download

If you want a spoiler on any part in particular, feel free to DM me. I believe Meowgi did complete all 3 maps without any hints, although some parts are definitely tricky :^)

Here is sliw.wad, wherein I experiment with fucked up platforming. It's a sampler platter of aerial experiences. This wad uses MBF21 map features - you need a compatible port like dsda-doom or woof. Uses otex by Ola Björling (ukiro). sliw.zip

https://www.doomworld.com/forum/post/2425626 cross-post

Thanks for the award 🙂 As source port development is a community effort, I'd like to shout out some people that were essential to the past year's work. I'd like to thank @Graf Zahl and @fabian for their work forking and maintaining prboom+um in the past years. Without that effort I don't think I would have gotten into source port work or ultimately forked my own port out of it. I'd like to thank @rfomin for joining in with that maintenance ultimately and for his work alongside fabian with woof, as this port has had a lot of positive cross-pollination with dsda-doom and new specifications. There have been many issues that they fixed that were inherited into dsda-doom, and I wouldn't have been able to focus on as many bells and whistles if they weren't keeping the boat afloat to begin with. Some people that have been essential to dsda-doom's development but haven't gotten enough recognition for it: @Keyboard_Doomer is the reason releases have been as stable as they have for both demo recording and general issues, as he does extensive regression testing for major releases. @ZeroMaster010 also contributes a lot of energy to testing things out and ensuring stability, including using dsda-doom in his 24/7 demo stream, which means we are constantly testing demos out. Much of the code for mbf21 was contributed by @Xaser (I hope that was a half-lifetime achievement award, because we have more to do in 2022 😉). Lots of improvements have come with the help of @eLim, including graphical updates and lots of discussions about software development in general. There are too many people to name that have tested out new features, debugged weird issues, etc, but things wouldn't be where they are without you, so thanks to you all as well. Here are some people that have made builds for other environments to make sure everyone is able to play: @PBeGood4, @Ramon_Demestre, and @Gibbon. If you've used one of their builds, consider sending them a thank you as well :^) There are a lot of discussions about the port that go on behind the scenes, which are often more related to speedrunning standards, but this is as much an essential element of dsda-doom as anything else, so I'd like to thank these folks as well: @ZeroMaster010, @4shockblast, @Bdubzzz, @Daerik, @Looper, @Meowgi, @dew, and @depr4vity. (Also a ton of other people, sorry I can't list everyone.) Additional people that helped out with mbf21's specification and also in general discussions about new things in doom code: @AlexMax, @Altazimuth, @dew, @MTrop, and @skillsaw. Ideas and discussions were very valuable even for anyone that didn't contribute directly to the text or code. And of course the whole community's contributions to the initial discussion about the idea of having a new standard itself can't be overstated. Let's see what 2022 brings 🔭

It's merged, try it out and let us know if it works.

esspressoman had the same issue earlier in the thread, maybe you can check in with him and see if he figured it out.

As far as demo competition goes, we already have 2.8.1 - demos won't desync in a future version because there is no future version. The only zdoom fork that would be used for speed demo recording would be a dsda-branded and moderated fork with changes and alterations that would be irrelevant for the audience outside speedrunning. Of course there are other applications for demos, but since I was pinged in this thread that is the stance of dsda.

Updated to v0.22.3 This version is still considered experimental. What's New: Added parallel sfx settings Within window game tics, allow the same sound to be played limit times Removed -loadgame / -recordfrom These were buggy and the implementation was unpleasant - this functionality will be replaced eventually like with loading within a demo. Fixed heretic playback desync with user pause This only affected playback, not recording Fixed stutter when changing music with portmidi (pr+) Download

As I mentioned in the other thread, the sound behaviour is not a bug. The buggy behaviour (the sound playing "in doomguy's head") is available on complevel 9 for those wishing to play at accurate settings (and if it's important to you, I recommend making that clear in your release). The latest complevel assigns sounds to the line that generates them. I.e., if I press a switch in real life, the sound of the switch being pressed comes from the switch itself, not from inside my head. We default to the fixed version for these kinds of bugs in the default compatibility setting as they are essentially cosmetic corrections.

If you're concerned with people playing on the wrong settings, you can make the game use complevel 9 by default by adding a lump called COMPLVL with "boom" as the data (adding a simple text lump with Slade for instance).

The sound thing isn't a bug introduced by new versions, it's a bug fixed by new versions. And those fixes are coming from boom, which is the compatibility you are targeting, so it sounds like things are working correctly. This port isn't going to change core behaviour based on your preferences, especially considering it would affect every other wad as well. Saving flat positions: I'd suggest bringing that up in the prboom+ 2.6.1 thread, since a save file bug should be addressed upstream. The standard group has a sufficient number of people currently involved, but thanks for the offer.

@Xymph The api has been updated to have this key: "notes": ["Array of", "Notes"]

For sound / music bugs, please report them in the prboom+ thread since they should be fixed upstream first to allow all forks to benefit. And it's more likely someone will look at it sooner.

https://www.doomworld.com/forum/post/2072728 Keep in mind, these kinds of unoriginal shitposts also waste the archive maintainers' time 🙂

It looks like save files from 0.22.1 are broken, although it's not intentional. EDIT: this is a side effect of support for the extended format, so consider this just another version that breaks saves.

Someone is trying to get banned? 🤔