Ferk

That's good news. I wonder if they still plan to release with the coop and multiplayer modes too. The trailer didn't showcase that.

Art is subjective. Statements like "conveying the same sense of satisfaction as Doom" or "lack the same visual clarity and appealing design" need to be taken with a grain of salt. Neither is Doom (nor the Id from the 90s, in general) the apex of consistency, nor is Freedoom's ensemble something that can't be explained out, the same way Doom mix up of religion folklore, robots, D&D inspired creatures and sci-fi elements is explained with a story that "it's expected to be there, but it's not important”. You gotta factor-in how Doom has become part of our contemporary folklore. With its theme and many of its sound effects being now something we are so used to that it makes it much harder to judge free of prejudice. If you played Freedoom and were exposed to its themes just as much as you were exposed to Doom-related / inspired lore, then I feel the judgement might have been different. That said, of course Freedoom has things that could be improved. But a lot of the things that were mentioned here were either fuzzy/unclear or are unjustified/subjective. What's wrong with the pink worm? I feel that's the most representative and thematically fitting replacement in the roster, it does feel like an eldritch horror creature that fits well as a hell spawn (it's not necessarily too sci-fi) while also fitting pretty well with the color scheme/behavior of the original without being an obvious copy or a reskinned "hulk" that would make it look as an uninspired variant of the original pinky, just with human features. Of course these are all subjective takes too, but so are the ones from OP. The worm is one of the least controversial replacements among those of us who follow Freedoom. The current imp replacement is a sprite of decent quality and it was never a requirement (or even necessarily desirable) to fit "the silhouette" of the original. Just as long as it doesn't cause misinterpretation/glitches when mapped to the boundaries of the original, it actually would be better for replacements to distance themselves from original Doom (while hopefully not clashing too much with the theme of maps they might be found in). I've always preferred the "less sci-fi" takes... since I've always been a fan of gothic / demonic themes, but the definition of what constitutes a "demon" is something very malleable, so I've long been advocating to at least not mix up tech/scifi in enemies that had a more organic/eldritch design in the original Doom. Which will allow wads that have a more medieval theme to use the less techy themed creatures to fit in there. So in that sense, I do feel a bit disappointed when I see cybernetics/tech related elements being given to, say, the baron of hell replacement. But other than that, I don't think using visually distinct and strange monsters makes it "inconsistent"... it's not like the original cacodemon or pain elemental from Doom, and their "floating balloon" aesthetic fit really in any traditional definition of what's considered a "demon" anyway, and Doom's archdemon could easily be confused for a skinny alien with its bulbous head and pale naked skin... yet you don't see people complaining about those things.

To be honest, I feel Freedoom is pretty much feature complete already. Of course there are things to improve, but a project like this will likely be forever improving. I'm sure there will always be tweaks to do or maps to improve, but as long as you can play Freedoom as an IWAD without having floating placeholder letterboxes or maps that are either impossible to complete or 1-room switches, I would consider it a complete game. With things to improve, but complete. I feel like contributing to projects like Blasphemer should me more interesting for new contributors already if what they wanted is to leave a helpful and impactful mark on the project. And yet the progress isn't really there. I feel it might also be a problem of marketing. I was a bit sad when the Blasphemer thread on this forum was unpinned, I wouldn't be surprised if a lot of new people only discovered the project because of it being pinned here. Much in the same way, this thread shows how the Zauberer project isn't very well known either.

There are many different ways to do it, what I was explaining is the reason why a change was needed. The fact you admit that a change "was needed" is just reafirming that it's true. I brought it up to show how depending on a static byte that you can just bump up is not always the best solution.

It's true. PrBoom+um bumped the number to indicate UMAPINFO suport, this made it match Eternity header too much, that's why the header was changed. Otherwise it's likely it would have remained that way. And of course the version number is not the only possible way to determine uniqueness, but I didn't mean it was. You can add up to the static list of bytes and the mess of nested wrappers to check for to figure out what to load, or another way is to design a more dynamic format that's more extensible. I feel the new header was a step in the right direction, but of course it's just my opinion.

But that would be a different topic. Even if it was the case that UMAPINFO doesn't need a complevel, a string of feature keywords is more flexible than a static set of integers. The reason a change in the header was needed in the first place was because bumping up the version number was causing conflicts with demos from Eternity that were already using the number.

I'm not sure I understand what you mean. Or whether I'm getting my point across. I edited it quick to try to clarify myself but you were quicker answering. "Wouldn't a complevel for UMAPINFO have the same result for a MIDI pack that adds a UMAPINFO lump and wants it to be loaded?" So.. I'm talking on a situuation where a new complevel to determine UMAPINFO (which would have also been integrated in the demo header) would have been used instead of a feature flag in the new header. I feel a complevel is not really what would have solved that particular case.

Wouldn't a complevel for UMAPINFO have the same result for a MIDI pack that adds a UMAPINFO lump and wants it to be loaded? I don't see why using a number instead of a more extensible string would help the case.

I feel PrBoom+ was in a good path with the new demo header that added a toggleable feature-based approach to new functionality, without submitting to an unstable standard that you'd end up having to track by yet another version number. In my humble opinion, if PrBoom+ is to keep adding features it would be best if they are discrete feature sets that are self-contained and stable or at least are more generic / de-hardcoded and that would be more future proof. Slowly but safely, all while making sure they wouldn't break wads that were working before. I'm not sure if MBF21 is a good candidate for that. Perhaps adding MBF21 would have made more sense if it had been split in sub-features that allowed stabilicing parts of it. Also, MBF21 has already a few decisions based on making it similar to other ports (ie. the Eternity-like flags) that are kind of duplicating part of what umapinfo (and other mapinfo-like formats) already solved with more flexibility. Who knows if those MBF21 flags will become just compatibility baggage in 10+ years in the same way many flags and features in GZDoom are just there due to its legacy.

The author himself has also already answered this in the thread for the wad. It's definitely not intentional. https://www.doomworld.com/forum/post/2255527

Remember that this thread is outdated. All freedom levels are already named, and many are different from what this 2013 post states. For the up to date list see: https://github.com/freedoom/freedoom/blob/master/lumps/dehacked/dehacked.txt#L205 Imho, this should be mentioned in the OP message, or at least be unpinned.

Sounds exciting if it spreads to other ports! About these flags: All these were already introduced as things properties before: https://github.com/fabiangreffrath/crispy-doom/pull/636 Imho, extra flags can conflict with other ports and it's less flexible for things that might well be numbers. Things like "NORADIUSDMG" could be instead a "Splash Damage Multiplier" property. So you could have an enemy that takes much more damage from explosions or has certain level of resistance (up to 100% resistance), instead of either immune or normal. About the flags for map bosses, doesn't UMAPINFO cover that?

What about a cheatcode that uses a thing id number as parameter for what to spawn/summon? Then with a dehacked mod you could spawn custom helper dogs, or other type of objects. Kinda like this

Then it won't be really fully FOSS. At that point, "you might as well" also make it freeware, or commercial. And then it would be harder to stand out among the rest of modern retro-inspired single-player FPS games that already exist. Anyway, the bulk of the work is creating the assets and maps, so whether you want to use the Quake tools or Unreal/Unity boils down to a preference on what tools you're more comfortable with for the goal and your sense of fulfillment when you have your creation run in an engine that you love. I don't see why that feeling can't be valid for Quake. Maybe personally for you that's not the case, but there are people who think of Quake 1 as the biggest 3D game ever, it just comes down to personal experience. Of course this is a Doom community so most people feel more nostalgic about Doom but there are Quake communities as well. Also, you can make the same argument about Unity/Unreal for 2.5D games... if you know well how to use Unity/Unreal you'll find making an "Action Doom" in those more modern tools gives actually a lot more flexibility (and there are already a few retro FPS games done in those engines that are amazing). It'd be possible to make a template in Unity that can be reused to make it easy to create Doom-like games. But I wouldn't say that this would mean everyone should stop making IWADs, right?

Imho, a free IWAD for Doom does not necessarily need to be Doom, much how a Quake PAK can be its own game while remaining compatible with Quake mods. I do believe that a singleplayer-focused 3D game in a fully 3D engine is something that you don't see very often in the FOSS world... so it would be a welcome project in my view. Other than Freedoom, the only singleplayer FPS campaigns I've seen in any FOSS projects were actually based on multiplayer-centric games, without a real focus in singleplayer. The fact that Freedoom is almost alone in the FPS singleplayer category in the FOSS world makes me wonder if it would have ever been possible for it to have gotten this level of attention, contributions and maturity had it not been for its goal of being Doom compatible. Sure, it would be great if there was a very ambitious project that expanded and added extra stuff, but building up to match Quake-level of content is imho already a huge undertaking. And since the project is FOSS, expanding it could still happen in theory. I'm just happy enough that there's a team working on a foundation already, and using Quake-compatibility as a base makes already for a solid one.