selliott4
-
Content count
46 -
Joined
-
Last visited
Posts posted by selliott4
-
-
Wow, you're right. That's a really neat and note worthy monster too. I'm surprised we missed that after our multiple reviews of the list. At least we have screenshots of the Octaminator. I'll update the website sometime today.
-
Thanks. For everyone's convenience here's a summary of the changes since the previous release (sorry for not translating to Markdown for this forum, but that's not obvious to me):
= Freedoom project news
== 0.13.0 (2024-01-29)
=== General
* Improved vanilla compatibility.
** Boom features removed.
** Hall of mirrors greatly reduced.
** Visplane overflows fixed.
** Savegame buffer overflow errors remain.=== Levels
* Relevant Eureka warnings fixed.
* New levels E1M9, E2M2, E2M3, E2M4, E2M7, E2M8, E3M5, MAP07, MAP21 and MAP27.
* Various level renames.
* Numerous vanilla fixes and aesthetic modernizations.
* Fixed and standardized secret exits.=== Manual
* French and Spanish translations.
* Sections added to highlight project mandate and additional accessibility options.=== Misc
* Adds automatic labeling to pull requests.=== Monsters
* New minigunner.
* The hatchling, which replaces the deadflare.
* The matribite, which replaces the summoner.=== Music
* Lots of new music including most of FreeDM music.=== Sounds
* New boss brain sounds.=== Visuals
* Colorblind-friendly keys and key indicators.
* Various revisions to sprites and textures.
* Improved kerning for menu text.=== Weapons
* Improved weapon sprites generally.
* SSG replacement restored to updated take on older version.
* Revised polaric energy weapon.
* Double-barreled shotgun flash timing bug fixed in built-in DeHackEd.=== Textures
* Esa Repo (Espi)'s old STAR* textures are now included under ESPI*.
* A STARBR1 texture is now included as a counterpart to STARBR2.
* Numerous additional grey and METAL2-based textures also available.
* Boss brain wall found to have Hexen resources and was re-done.
* Wolfenstein replacements completely redone, designed to work as
seamlessly with other textures as possible. A few are also added. -
Recently when I cleaned up a bunch of Eureka check warnings (Check / ALL or F9) in the Freedoom project I found that not all checks could be fixed - there are false positives that can not be worked around without compromising the aesthetics of the map. For example, fake floors and fake ceilings are used which results in a missing texture warning. There are some false positives for Medusa textures as well.
In software development for compiler warnings to be as helpful as possible warnings are either avoided, or suppressed with some special syntax in the code ("@SuppressWarnings" or similar). Similarly I thought it would be nice if there was a way of suppressing warnings that editors give.Whatever approach is used should not break when things are renumbered (you wouldn't want to just have a list of sector numbers for sectors where the warnings are suppressed (unchecked) since those numbers may become invalid). You wouldn't want some information in a separate lump since that lump maybe be stripped out, or become out of date.
What I came up with is the idea that a special thing type can be added to a sector that indicates that all warnings for that sector (and connected sidedefs and things in them) should be suppressed, which I refer to as an unchecked sector.I took a shot at implementing this in my fork of Eureka, but I'm more interested in how folks feel about the approach than the implementation. Does this seem potentially helpful, and a reasonable approach?
Sorry if this has already been done, but I didn't find it with a quick Google.
-
On 8/14/2021 at 1:59 AM, CBM said:GZFreeDOOM has changed its name to GZFreePunk to reflect the steampunk astetics that will likely be a big part of it moving forward and to put fraggles worries to rest while also restoring my full creative freedom. It is still a fork of FreeDOOM, it is still using the Freedoom levels but as UDMF maps and it is still a solo project.
Sounds like a neat project. Probably one of the first things to do is create readme describing the goals of the project since otherwise different folks might have different ideas about what it will look like, but good luck in any case.
-
Neat project. Older Freedoom was in Subversion. I don't suppose anyone has a still functioning Subversion URL that can be shared that can be used to find older resources.
Are you aware of the fraggle's Freedoom leftovers from 2010?
19 hours ago, Catoptromancy said:The iwads older than 0.6.4 can be hard to find
git has tags for 0.6.4 down to 0.5:
$ git tag | sort -V | grep ^v | head -8 v0.5 v0.6 v0.6-rc1 v0.6-rc2 v0.6.1 v0.6.2 v0.6.3 v0.6.4 -
9 hours ago, MrFlibble said:It is my understanding that the people involved in actual development now mostly communicate via discord. Since I don't use that, I largely don't know the state of affairs, but I had the impression that plans about moving forward exist and are being carried out as the time permits.I
I wrote my comment without first pulling the latest from git, which was silly of me since there's actually been a lot of activity in the last week, which is great.
I hope my comment didn't rub anyone the wrong way. I also meant it as a compliment to how complete and close to done Freedoom is.9 hours ago, MrFlibble said:For example, you say that all maps are good, even though some may not perfectly comply with vanilla standards. I remember from old discussions that 100% vanilla compatibility was set as one of the goals at one point (and this is reflected in the current project readme), and you can see the work done in that direction in another thread. If you're suggesting to drop that goal, what is your reasoning for that?
I'm in favor of 100% vanilla compliance. I even submitted a pull request that adds a test script to test for vanilla compliance. I was exploring how things could be wrapped up easily, but I see now that that's no longer relevant.
9 hours ago, MrFlibble said:But Doom and Doom II weren't libre, open source community projects, they were done on schedule in a completely different environment. Besides, Doom actually had some not very drastic, but noticeable changes after the initial release, so I'm not sure the analogy can provide useful insights.
Maybe I should've done more research into Freedoom's post 1.0 goals before making that comparison, but often with games they become static at some point. People can then set speed run records knowing they'll remain relevant, but is that a good reason? I actually don't know, but I'm happy to hear what others think.
-
I've touched on this in my previous comment where I mentioned that many of the 39 (at the time) open pull requests didn't have any comments, but Freedoom development waxes and wanes in large part due to involvement of folks of who have write access to the repository.
I know everyone who is working on Freedoom is working for free and as such we're not entitled to anything. And I know Freedoom has been around for a long time and that some folks may be tired of it. Given that I'd like to propose a conservative approach to wrapping it up.
Freedoom has had all 100 maps for a while now. I've played through all of the single player maps and I've enjoyed them. From my perspective they are all perfectly playable. They may not be perfectly vanilla, but they're close.
I think Freedoom should have one final push where no maps are replaced, where only critical fixes are made for things like crashes in game engines, or playability issues that can be fixed with minimum risk and effort (not enough ammo, a game mode not being playable due to a barrier, etc.).
It seems like it should be possible to do this in a few weeks. Maybe set a date a few months from now, whenever key players are available. And then have a 1.0 release, declare victory, and never work on Freedoom again. From that point forward any additional changes can be via a fork and managed by someone else. Hopefully having the finish line in sight will be energizing.
I don't mean to criticize the more ambitious suggestions in this thread, but wrapping up Freedoom may be best. It's not like id Software has ongoing incremental changes to Doom 1 and Doom 2. -
Software development is difficult to plan. Often the time needed increases dramatically, seemingly exponentially, with the scale of the project. Underestimating this phenomena can result in development hell. I don't think that's what is happening with Freedoom. Although there is software in Freedoom (the build system) it's mostly levels, graphics and sound which should be, in least in theory, easier to plan.
I wouldn't say that I'm a core developer of Freedoom, but I've contributed a few commits and as such I have some thoughts about how things could be done differently.
Currently there are 39 open pull requests. Some have comments, which is great, but many don't. There's a risk of folks getting discouraged when they don't receive any feedback. Even if it's just something like "I'm busy now, but I'll get back to this in a bit" or "Sorry, but this isn't the direction we want to go" would be better than nothing.
I don't understand the status of the 100 levels that make up Freedoom. I assume most of them are fairly stable and possibly a few may be replaced, but I'm not sure which. I was considering doing cleanup work to fix level editor warnings (unused tags, etc.), but I don't want to risk causing a conflict with trivial changes if there's a chance that someone is working on the level. A 100 row shared spreadsheet (Google Doc, etc.) would work well here. Just the level name and some status indicating the remaining work like "Done", "Minor changes", "Major changes", "Replace" and optionally a column describing what need to be done would be great.
I'm all for branching and tagging in VCS. It allows users in support branches to receive the critical fixes they need with a minimum risk of regression while development continues. However, I think the nature Freedoom is that there's relatively little risk of a serious regression. In spite of that Fedora 34, released two months ago, packages Freedoom based on the latest tag, which is v0.12.1 from 2019, so it's missing about a year of changes. Freedoom seems like a good candidate for tagging often and releasing often in the master branch to assure that the distros get the latest.Anyway, those are my thoughts about how development could work differently.
-
I created a pull request that adds a script and build targets to test for and fix errors that have to do with vanilla compliance. That is, it flags things that may be at risk of working differently for various source ports, or may simply be different than the style of the original IWADs from the 90s.
For any field of any element in any lump that has a discrete set of values where it was possible to determine the vanilla set the script flags values that are outside of that set. For example, for the THINGS lump only the lower editor lumbers listed here are allowed.
In some cases errors can be fixed in an automated way. For example, for the original IWADs from the 90s the goal was for angles to be a multiple of 45°, and in range [0°, 360°). The script fixes angles by rounding to the nearest multiple of 45°, changing the angle by at most 22°, which shouldn't be very noticeable in most cases. For whatever reason a common issue in Freedoom is angles set to 360°, which gets safely mapped to 0°.
Although there are currently 456 errors after the fixes there are only 38 errors four of which are slopes (type 340) on E2M1, leaving only 34 errors to go through. However, I'm not submitting those fixes with this pull request, just the script itself.
Ideally I think this would be combined with fixing errors flagged by map editors, which is why I added such as a suggestion to the documentation in README.adoc. I've had good luck with Eureka (the Check / All menu) which is why I suggested it, but other map editors will work.
I know there are APIs that may have made this easier (omgifol comes to mind), but I wanted to avoid dependencies and licensing issues, and I had fun writing it anyway.I actually created a small test suite in another branch for test-vanilla-compliance, just in case that's interesting to anyone, but that small test suite is not part of the merge request.
-
Nice. It's a tough map, but maybe that's because I played it on UV. It looks like Phase 1 C 3, but it's a Phase 2 map.
-
35 minutes ago, Hideous Destructor Guy said:Do you mean this? It's the only PR I can find searching for "fix-map-names" and it looks like it's been merged.
Yes, that is the PR that added script to fix the map names that I wrote, but it hasn't been used. It should be easy and low risk (it literally modifies only 2 bytes per WAD), so I think running it periodically is a good idea.
My motivation - the map names in the WADs in the "levels" directory do not matter very much except that wad2image, which I previously added to Freedoom, creates image files based on those names. So currently things like "make wad-image-diff", useful to see changes to maps, produces files with confusing names. See "make wad-image-help" for more info. -
Just as I was becoming concerned that people were loosing interest in Freedoom there's been a huge increase in activity in git. There are 40 commits for August so far. Go Freedoom!
PS: Now that people are actively working on it if one of you with commit access could check in the result of "make fix-map-names" that'd be great. It will get "make test" to pass cleanly. I could submit a PR, but it's changes to binary files, so it's easier to just do it rather than trust/examine the changes to those binary files in a PR. -
Were you thinking it could take the place of one of the currently vacant "dummy" maps?:
$ grep MAP.*dummy wadinfo_*.txt wadinfo_freedm.txt:MAP33 = dummy wadinfo_phase2.txt:MAP26 = dummy wadinfo_phase2.txt:MAP33 = dummyI have no idea if it's suitable, nor do I have any authority, I'm just letting you know what seems to me would be a likely place for new maps.
-
It looks more like actual walking with your change.
I think before maybe there was a huge amount of perspective, like the viewer was close, and maybe close to his feet, but I'm not sure why that would be. I like what you did.
-
-
After thinking about it a bit more I think they way to go is to have a Python script, sort of like the one I just proposed, that can both fix the map names *and* test that if they are correct. So something like "scripts/fix-map-names" since I think there is a desire to keep scripts in "scripts". By default fix-map-names would iterate through the files in "levels" and print out a table of any incorrect WAD files, the map name it had, and the correct map name it was changed to. It could be run after replacing or reordering maps.
To test if the maps names are correct the new "test-map-names" build target would call something like "fix-map-names -t" where the "-t" option would test, which would effectively make it a dry run.
This way the concept of having a basic test scaffolding run by "make test" is maintained where people could add "test-*" build targets, anyone could easily fix or test the map names at any time, and redundancy between testing and fixing scripts would be avoided (my proposed fix-map-names script would obsolete the current test-map-names in my PR).
How does that sound? I would probably submit such a script some evening this week, or the weekend.
-
1 hour ago, Ferk said:I wonder if it's worth the maintenance burden of keeping the names of the lumps always matching their position whenever they are rearranged.
That's a good question. I thought (hoped?) that things are settling down and that rearrangements or replacements are getting to be less common, but you know better than me. In any case I don't mind checking in again in a few months and fixing it again.
1 hour ago, Ferk said:Another way to go about it would be having them all with lumpname MAP01 (or E1M1 for maps meant for Doom 1) independently of their position, since it seems what matters for the build script is the file name.
True, that could be done, but it would make wad2image output even more confusing. It's also possible I should update wad2image to generate image files based on the filename passed to it.
In any case, one question is if the map names have any value for anything else such as build error messages, making things less confusing for people editing the files, people consuming Freedoom resources, or whatever. I don't know the answer though.
The map name is the name of the first lump, which has a zero byte value. I assume that lump is required, but what if it could be stripped out of the WAD files in the "levels" directory combined with something being passed to duetex, possibly with a duetex modification, telling it what map name each file was? That may be getting more ambitious than we want to talk about though.
And finally, a script could be written that automates fixing the map names. Since the map name is just the first lump name it could be done with a Python script that decodes reads the WAD file directly without any dependencies, and then writes the correct name. It would have some regexs to map from Freedoom filename, to Doom map name. I don't think it would be too hard. I could possibly write such a script.
-
Since PR 481 has been open for over a year I thought I'd see if there's anything I can do to finish it up.
PR 481 is about making sure that he nap name for the WAD files in the "levels" directory match the file names. My interest in this has to do with the fact that wad2image that I wrote, which has been integrated into Freedoom's "Makefile", generates images based on the map name, not the filename. This means that the output is confusing when the map name is incorrect. wad2image works this way since it can work with WAD files that contain multiple levels.
PR 481 has two parts, the fix, which literally alters only a few bytes per effected WAD file, and a shell script that can report on the problem in the future including what the current incorrect names are, and what they should be changed to.
For the script I thought it might be nice to add a basic test scaffolding. In this case a new target "test" depends on a "test-map-names" target which runs "tests/test-map-names". That way if someone wants to add a test in the future there's a pattern to follow. But if you don't like it I can change it. I can move the script to the "scripts" directory with a "test" prefix. I can get rid of the build targets, or whatever you want.
PR 545 adds instructions on how to do enable binary diffing in git. If those instructions are followed here's what it looks like for one of the files that PR 481 changed:
diff --git a/levels/map18.wad b/levels/map18.wad index b2ea036..1e9d1b6 100644 --- a/levels/map18.wad +++ b/levels/map18.wad @@ -15179,7 +15179,7 @@ 0003b4e0 00 b5 04 f8 04 02 05 0c 05 ff ff 00 00 b5 04 f8 |................| 0003b4f0 04 ff ff 00 00 b5 04 f8 04 f9 04 ff ff 00 00 b1 |................| 0003b500 01 b5 04 ff ff 0c 00 00 00 00 00 00 00 4d 41 50 |.............MAP| -0003b510 30 36 00 00 00 0c 00 00 00 34 17 00 00 54 48 49 |06.......4...THI| +0003b510 31 38 00 00 00 0c 00 00 00 34 17 00 00 54 48 49 |18.......4...THI| 0003b520 4e 47 53 00 00 40 17 00 00 d8 6b 00 00 4c 49 4e |NGS..@....k..LIN| 0003b530 45 44 45 46 53 18 83 00 00 d0 6a 01 00 53 49 44 |EDEFS.....j..SID| 0003b540 45 44 45 46 53 e8 ed 01 00 f8 1e 00 00 56 45 52 |EDEFS........VER|
Since I can understand that a relative unknown (me) changing a bunch of WAD files might be concerning I thought PR 545 might be helpful in this case, and possibly future cases, to make it easier to see that there are no extraneous changes.
-
It's a bit surprising to me that levels are still going to be replaced, not just edited, which I'm guessing is how this happens. In any case I could take that one liner and make it into a script, something like "scripts/test-map-names.sh". There would then be a build target like "test-map-names" that ran it. There could be a new "test" target that then depends on "test-map-name" so additional tests could be added easily in the future. Does that sound about right?
I think fixing this problem in an automated manner is a harder problem than detecting it. I can just check again in a while and submit another CR if need be.
-
-
I noticed that some of the WAD files in the "levels" directory contain maps that do not match the filename. For example, "map08.wad" contains MAP01. Here's a one liner to get a list of all WAD files that contain unexpected maps:
cd levels; for w in c*.wad dm*.wad map*.wad; do l=${w%.wad}; l=${l^^}; l=${l/DM/MAP}; l=${l/C/E}; bad=$(yadex $w < /dev/null | grep " Levels:" | grep -v $l | awk '{print $2}'); if [[ -n $bad ]]; then echo -e "$w\t$bad"; fi; done
And the output it produced:
dm31.wad MAP01 dm32.wad MAP01 map06.wad MAP04 map08.wad MAP01 map13.wad MAP09 map14.wad MAP03 map18.wad MAP06 map19.wad MAP08 map24.wad MAP06 map32.wad MAP01
I realize that the build handles this correctly, that the filename drives what maps ends up as in the final "freedoom*.wad" files, but it's still a bit confusing. For example, wad2image, which I'm in the process of trying to get integrated into the build, generates images based on the map name, not the filename.
Fortunately based on a quick experiment I did it's possible to change the map name within the WAD file with a hex editor without otherwise changing a map. In other words it's possible to edit the map names listed above by only changing one or two bytes in the containing WAD file. The build seems to still work correctly after the edit.
Should I submit a pull request with the map names edited to match the WAD files?
-
I've finally submitted a significantly overhauled pull request in part based on feedback I received. I hope it's helpful. Let me know what you guys think.
-
-
Thanks for the feedback. I've added a sentence about ImageMagick to the requirements in wad2image's home page.
You can control the animation speed with "--gif-duration". By default it's 500 milliseconds per frame. Try adding "--gif-duration 2000" to make it four times as slow with 2 seconds per frame.
I've fixed the two bugs that you've found and I've released version 0.9.1. The direct download link is here. It should now render Hell Knights. Also it should also no longer have "animate: unable to open" error messages combined with a non-zero exit status.
It does build the GIF files by loading the PNG files created where each PNG file is one animation frame.
Generally "-d gif" is good if you don't care about keeping the static PNG images that went into building the GIF.
The GIFs are valid in my testing. They appear animated in chromium, animate and gpicview. If you like I can try your "Feveswar*.wad" files.
Freedoom 0.13.0 was released
in Freedoom
Posted
Interesting. I've never noticed that window in spite of all the times I've played that map. It's neat. I'm not too worried about the sky box texture not being an actual sky box - seems hard to notice, but good catch.