Ferk

Can you elaborate on that? What makes the CC0 not compatible with the BSD? My impression was that the CC0 was actually less restrictive than the BSD, not even requiring attribution. My understanding is that you can use CC0 content in a fully BSD work (or even proprietary) without problem. Is this not the case? I believe that what you aren't able to do is distribute BSD content as if it were CC0-licensed work (the opposite) because the BSD does require the 3-clause notice to carry on. Also, the subject of "compatibility" is always very unclear to me. The definition of what it means being "compatible with" seems to change depending on what license we are talking about. For the GPL it means "you can combine code released under the other license with code released under the GNU GPL" (and according to the FSF, both the CC0 and the 3-clause BSD are "compatible with" the GPL.. even if the FSF does not recommend CC0 for code: https://www.gnu.org/licenses/license-list.en.html); for the CC Share-Alike licenses "compatible" has nothing to do with combining multiple licenses in the same work, but about releasing the whole work under a different license "when you make adaptations of material under BY-SA or BY-NC-SA and share the adaptation"; but as far as I understand, the CC0 has no restrictions on what license you can use for adaptations.

Not within the github website like that, I don't think so. It probably requires some scripting using git commands. Yes, that's a pity. The problem with that is also that if that content was never formally included in the repo then it never was really explicitly put into the MIT license. I'm not sure if it would be wise to take those work-in-progress / rejected graphics without the author's consent and assume that the author is actually OK with them being put in the attic under the MIT license. Unless they gave explicit permission, which in some cases it might be hard to get if a long time has past.

That mobile app is an "unofficial" independent project, not associated to the Freedoom team, it was set up by @t3l3tubie I wish that had been made more clear ..or a different name was chosen for the app. Because it's not the first time people come here asking about it. There's an issue open in their Github about this: https://github.com/mkrupczak3/Freedoom-for-Android/issues/49 My understanding is that it's not very actively maintained, so most likely it uses an outdated version of GZDoom which might not support every pk3 out there.

On the other hand, this all being tracked in git potentially allows for automating it... I guess it would be technically possible to automatically generate a website, sort of a "Freedoom DB" that chronicles the evolution of each graphic file. I think the idea was kind of hinted before in a github issue, someone mentioned about a script to track changes in levels: https://github.com/freedoom/freedoom/issues/775 The attic definitely could do with some reorganizing. While authors should definitely be given credit, grouping it like that makes it very hard for people to know where to look for when they are searching for something specific. Although I'm not sure if there's a better way to do it if we are limited to folders. I feel there might be assets that could fit in more than one "category" (and things like levels have often been moved and switched around to different slots over time), so maybe it might be better to just have one big folder for each generic type of asset (eg. sprites, flats, levels, etc.) and a yaml or json file for each of them to keep the metadata about author, submission date, etc. I don't know... Also, for anyone wanting to check older versions of an asset in the main repo, instead of wading through Pull Requests, you could directly look at the history of the individual file you wanna check. Bonus Armor Pickup history: https://github.com/freedoom/freedoom/commits/master/sprites/bon2a0.png Bonus Health Pickup history: https://github.com/freedoom/freedoom/commits/master/sprites/bon1a0.png Though that's from after it was converted from GIF to PNG (in 2017). For history of the older GIF versions it would be: Bonus Armor Pickup GIF history: https://github.com/freedoom/freedoom/commits/96ca8bf/sprites/bon2a0.gif Bonus Health Pickup GIF history: https://github.com/freedoom/freedoom/commits/96ca8bf/sprites/bon1a0.gif In 2015 and earlier, all files were using symlinks (back then the attic was actually part of the main repo and the files from it were linked into the right location, when used), which further complicates things...

As far as I understand (I could be wrong), there're still textures included that aren't even used in the maps. But even if they all were, the 4046 lump limit is not unreasonable for the project. I'd argue it helps preventing the WAD from becoming bloated. I don't think hosting an ever growing huge texture dump should be a goal. The limit also helps imposing some consistency, since it encourages maps to reuse the textures and not keep adding variants of the same texture just for flavor. I don't believe that being "distinct from Doom" requires that. Note that keeping the entire set of Aquatex textures is also not one of the formal "project goals", so if you really think there's any one particular texture that is more deserving to be included than others, I think it would make more sense to propose a texture replacement (removing whichever other "bonus" texture seems to be redundant or least used/useful) instead of asking for the new textures to be added while placing the blame on the Vanilla compatibility for not allowing every single possible "perfectly good" texture that was (or will be) ever proposed to be included. There's also an "attic" stored as a separate repository. There's no limit to how many textures could be placed there, so there's that as an option for submissions. It's not like the textures would be lost forever if they aren't included / or are removed. If someone wants to use those textures in a PWAD for Freedoom, they can still tap into that resource to have extra textures and it would still be vanilla compatible, since the limit is per-WAD.

They also need to tile perfectly, the left edge and the right edge should feel seamless when joined, which you wouldn't get from an unedited real world picture.

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.