MrFlibble

Interesting! I did not know that story. I looked up what the actual fish in the anime looks like, the resemblance is pretty vague, although I guess the Pink Fish image is amateur fan art. Is the Freedoom version directly derived from that image by the unknown author?

I don't remember @wesleyjohnson actually recalling contributions, save for the general desire to dissociate from the project in its current state reflected in that post you've linked to before. And I would like to think that if Freedoom stayed along the design directions from pre-2015, @wesleyjohnson would not mind continuing to contribute to it. Now I do not know everything because some of the events happened when I took a break from actively following Freedoom's development, but I very much hope that nothing happened on the same scale as with @Wereknight who basically demanded to rescind the free license attached to the contributions already made. To be very, very honest, I like the old doors by @Fredrik more. The new ones (including the current ones in the repo) look fancier but they're flatter and look like something from a much newer game than the Doom knockoff that the project originally started as. Yes, that is an excellent idea! BTW, I also thought that this topic would generally be a good, more or less centralised place to document all known contributions to the project, so if you find something in the forums here or elsewhere (and specifically on Discord because that is not public and stuff disappears after a while) that is related to Freedoom, please don't hesitate to post it here. I remember that from an old release, what is particularly wrong with that asset? I believe someone here in the forums uses the same fish as the avatar.

Yes, I just copied the strings in d_englsh.h from my current MBF code and forgot to not reshuffle back the level names. In-game, you should still have correct level names per your nine-level arrangement though, because the strings from chex3.deh override the internal values anyway. Currently you will see the shortened level names from the vanilla DeHackEd patch, but DoomNew actually supports longer strings -- which, among other things, allows for proper cheat codes (this needs to be set as a variable in deh_main.c, since by default this function is disabled). I've just replaced a few of the truncated cheat codes in chex3.deh with their original, longer counterparts, and they worked in-game just fine. But, I've also brought back the original Chex Quest cheat codes using gamesrc-ver-recreation into the relevant C file (so currently the right codes are overridden with truncated versions from chex3.deh). I didn't realise that id would go an extra mile to obscure the cheat codes even in the source code, because MBF reworks this completely into very user-friendly code that is easy to change. Perhaps it would be a good idea to have a different DEH file for this version that does not duplicate redundant strings that are already hard-coded. I still wonder what causes the slowdowns/crashes though and if it could be somehow related to actor code. Obviously, DoomNew is pretty limited in how it handles DeHackEd, although I imagine that if the external DEH patch has worked with the vanilla executable it should be good. UPD: I'm silly, I just loaded chex3v.wad as the main IWAD using the unmodified DoomNew DOOM.EXE without the DeHackEd file, to see if there would be crashes. I was able to complete Landing Zone without trouble, although the Cycloptis was simply a Spectre with the Stridicus sprites (as expected). Storage Facility started fine. Trying to warp to the lab level from the command line froze the game, and trying to start the second episode from the menu crashed with the P_SpawnMapThing: Unknown Type error, which, again, was likely predictable. I double-checked by loading the unmodified chex3.deh (again, with the original DoomNew DOOM.EXE and chex3v.wad as the main IWAD), and I got slowdowns in certain places, but most importantly, a complete freeze as soon as I entered the red key door. Looking at the code, DoomNew seems to be generally very closely based on Linux Doom 1.10 (which was the original source release), so I guess maps alone should not cause a freeze, and the above results appear to point to the DEH file as the culprit. UPD2: I installed DeHackEd 3.1 for DOS and loaded chex3.deh with it. It complained about a bunch of unmatched lines (some of which are supported by DoomNew, as far as I can tell), but loaded the file. I re-saved it (chex3deh.zip), shaving off about 5 KiBs in the process, and tried to load CHEX3.EXE with this version. Again, Landing Zone freezes after entering the red key door.

I'm fairly certain @GeorgePieVG is not asking about those faulty/mala fide contributions (which obviously should not be included or archived anywhere because of license violations): Although I suppose that it might have happened once or twice that someone contributed something copyrighted by mistake and then asked for it to be removed themselves -- but again, it should be obvious in those cases that there is no need nor legal reason to archive those.

Yesterday I thought I was onto something when I found a new build of DoomNew that uses APODMX instead of the original proprietary DMX library like the previous versions: https://github.com/neozeed/doomnew-for-dos DoomNew is the only vanilla DOS port that I know of that has proper implementation of DeHackEd support, both for external patches and embedded lumps. What's more, I was able to compile it with Watcom 11.0c, making it possible to introduce various changes without resorting to hacking the binary. It can load chex3v.wad as the main IWAD without errors, and appears to properly use chex3.deh. If chex3v.wad is loaded as a PWAD, it tries to load the internal DEHACKED lump but fails because DoomNew seems to have no support for BOOM extensions, just plain DeHackEd. Loading internal DEHACKED lumps can be disabled in EXTEND.CFG though. However, once you're in, the game will sometimes slow down to a crawl and then crash DOSBox under certain conditions -- it is my understanding that this happens in when a Cycloptis enemy is nearby. I have not been able to figure out a more exact cause. For example, I was just able to complete CQ3M1 without any issues, but the game semi-froze on CQ3M2; there were no issues in CQ1M1 until I got to the red key area which houses a Cycloptis. Similarly, warping to CQ1M3 and entering the very first room slows down to a halt if you look to the left where there are two Cycloptis enemies. Here's my attempt to build the Chex-specific binary (BTW, DoomNew has built-in support for the original Chex Quest 1& 2 out of the box): chexnew.zip It recognizes chex3v.wad as the Ultimate Doom IWAD and auto-loads chex3.deh. Use of internal DEHACKED lumps must be disabled in the EXTEND.CFG file. I have not made any further changes that affect the number of levels per episode or the number of episodes (you can still select the invisible fourth episode, but that should be easily disabled in the code). I guess it would be nice to have this working to build a custom binary without having to code back all the monster changes manually.

Have there been a lot of people apart from CWolf/@Wereknight to do that? Personally I greatly dislike the whole concept of first making contributions to a free/libre project and then backpedalling on in -- especially since if something has been in a release for at least a while, there's really no putting it back into the bottle. To be super honest, I never particularly liked most of @Wereknight's submissions that were actually used in the IWADs. But he made that Infernal-like Lost Soul thingy that ended up as a Gargoyle placeholder in Blasphemer. But even if you do not put anything in the attic, those resources are still in the releases anyway, and in the source code of those releases, no one's gonna remove them from there. On the one hand, I think that perhaps it would be more honest to document such submissions in the attic and put an explicit note that the authors of these submissions requested to remove them from the project. So that people would know that these resources are preserved for historical purposes, but are not to be used further. But, on the other hand, doing so could be construed as normalizing the practice of pulling back submissions, which is very much an undesirable thing. So I'm not really decided on this, perhaps it's better to archive them privately but not add to the attic, for now.

I have just run the v1.17.1 WAD with the recent build of DoomNew (a vanilla port that adds DeHackEd support), and the slime trail thing is not there. Must be something related to Boom/MBF I guess? Sorry for making such a fuss around it!

Interesting, DoomNew is able to load embedded DHEACKED lumps, but only in PWADs, it will not look into the IWAD for one.

I was just Googling completely different things and found that there is actually a recent version built with APODMX (haven't tested it yet): https://github.com/neozeed/doomnew-for-dos However, it looks like @maraakate has changed the video mode from ModeX to Mode 13h (possibly from Heretic code), which results in visible screen tearing that vanilla Doom doesn't have. It probably works faster on low-end machines though. And this is, as far as I know, the only vanilla-based DOS port that includes fully functional built-in DeHackEd support.

Oh. Then I guess I conceived of your project's ultimate goals entirely backwards :) I assumed that using a hacked Ultimate Doom binary was just a temporary measure, until you'd get around to actually produce a vanilla Chex 3 executable built from source that would work just like Chuck Jacobi's ZDoom version -- basically, backport Chex Quest 3 to DOS. Sorry for any misunderstanding! I just had this idea, the limit-removing versions of the levels should work wonderfully with the MBF port and take advantage of its capabilities. Perhaps you could upload them somewhere so I could give them a spin?

@GeorgePieVG, JIC, when I looked up @Blastfrog's old rejected PRs in the freedoom repo, I was able to open up an entire branch that was linked to the MIDI submissions by @nub_hat: https://github.com/freedoom/freedoom/tree/5d785a9016744f5aa966698f8d3c53cb0b6a5ea5 I downloaded the branch and found some other MIDI music that was not in the attic, and possibly not in the main repo -- but not sure. I waded through the entire music folder and identified two sub-folders not available elsewhere: mogul -- includes 11 MIDIs called MogulFreedoomMusic*.mid and a note which says: sodaholic -- two MIDIs, grendelsrevenge.mid and wastelandscavengers.mid. I have checked the other folders not related to music in that branch, but I think they only have @Blastfrog's stuff known from elsewhere. Still, it might be a good idea to take a look at other rejected PRs by @Blastfrog and check if something else of interest has crept in. I see you're also reorganizing the map submissions. I remember that apart from Double Impact having been dontated to the project, @Jimmy² permitted to use a lot of previously created maps in Freedoom, and some of them were included in the IWADs if I'm not mistaken, but not sure about that. I suppose that they could also go into the attic? UPD: The same topic about map donations also includes several maps donated by @Mechadon (at least one should be usable without modifications) and one by @Sergeant_Mark_IV.

I'm not sure the intro/outro levels that you have added can count as a equivalent replacement of the videos that would make them "redundant". The art and spoken dialogue from the videos is completely missing, there isn't much background provided on the flemoid invasion compared to the intro, and in the outro level, there's no sense of urgency as no flemoids are after the player, and the captives are represented by other Chex Warriors. I get it that you put much work into these filler levels, but they're just not the same as the original videos. Well, the original Chex Quest simply played both the intro and the outro outside the main game, and there doesn't seem to be a reason not to reproduce that for now, until you may find other ways to get them into the actual game. I've looked at the reconstructed Chex code from gamesrc-ver-recreation, and the change required to reduce the number of maps per episode is quite trivial. In g_game.c, there's the following section (taken from MBF code), and you need to simply replace "case 8" with "case 5": static void G_DoCompleted(void) { int i; gameaction = ga_nothing; for (i=0; i<MAXPLAYERS; i++) if (playeringame[i]) G_PlayerFinishLevel(i); // take away cards and stuff if (automapactive) AM_Stop(); if (gamemode != commercial) // kilough 2/7/98 switch(gamemap) { case 5: // 2024/09/15 Chex episodes only have 5 maps gameaction = ga_victory; return; case 9: for (i=0 ; i<MAXPLAYERS ; i++) players[i].didsecret = true; break; } Since many ports already introduce a similar exception for vanilla Chex Quest 1, you could just send a pull request to them to include support for CQ3V, and/or compile a version that does the same yourself, e.g. based on Chocolate Doom. I've updated my MBF version with this code and everything seems to work as intended, each episode ends after the fifth map: chex_101.zip I have rearranged the levels in the correct order and put them into chex_pat.wad to override chex3v.wad contents. It appears that since the game now does not allow more than five levels per episode, secret exits in CQ2M1 and CQ3M2 now work like normal exits and do not break the intended level progression sequence. I also edited m_cheat.c to disallow warping to levels 6-9 in each episode and/or to any level in the fourth episode. Please let me know what you think about it.

@NY00123, apologies for another question, is it possible to compile the game code with Open Watcom? I'm getting an error because the makefile expects a compiler called wcc386p, while the Open Watcom package only contains wcc386. Edit: To elaborate, I'm using Open Watcom 1.9. Also I figured out I was trying to use a non-Borland TASM while the code expects Borland TASM 3.1. I fixed that, but still cannot compile. I've tried renaming wcc386p to wcc386 in the makefile, but I'm getting a bunch of errors and the entire process shuts down after some failure in compiling i_sound.obj. I'm not sure if this is caused by the Watcom version or if I put the APODMX and AUDIOLIB directories where they shouldn't be. I've got a folder with DOS stuff mounted as C: in DOSBox, and the code is in the C:\GAMESRC directory, while ADPDMX is in C:\APODMX and AUDIOLIB in C:\AUDIOLIB Open Watcom 1.9 compiled APODMX, but with a few warnings. However, Open Watcom 2.0c failed to compile it at all. I don't suppose I should be downgrading to some older Watcom C/C++ version to have it all done? Edit2: Alright, I found the freeware Watcom 11.0c at the Open Watcom website and installed it. It still does not have a wcc386p compiler, so I had to edit the makefile once again (I started clean). This version compiled APODMX with just a couple of warnings, and also reported significantly less warnings when trying to compile the CHEX binary. However, it still exited without producing anything because of an error when compiling i_sound.obj: i_sound.c(437): Error! E1062: Inconsistent return type for function 'I_PlaySong'

It's okay, you were doing what you thought was right. I still think, though, that taking into account the context of "Flynn Taggart"'s posts back when they were made, it was very likely that they were still intended as submissions, even if we did not know this was @robotdog1. This is not the first time some of @Fredrik's work does not get included -- although it this case some of the people thought that the edits were not an improvement. As far as I know, the RW35 versions showcased here (at the bottom of the page) never ended up in any IWAD release: https://web.archive.org/web/20070817160354/http://www.dd.chalmers.se/~frejohl/doom/blah/compare.html But I see those are already included in the attic. Just posting the link here so it is not forgotten. UPD: It turns out that the same page, (almost) completely intact, still exists: https://fredrikj.net/doom/blah/compare.html UPD2: I've filled in the missing GIFs from the original Freedoom repo, which I extracted from the v0.3 IWAD: compare.zip I noticed that, in addition to the unused RW35 patches, the new (current) cardboard crate set also included the patch for the side of the very small crate the player can step on (VGCRATE1): However, it seems to have been never included in the repo, so to this day Freedoom still uses the old patch from the original metal crate set.

The head looks a bit too static, it feels detached from the rest of the body.

@NY00123, am I right to understand that the audiolib repo already includes precompiled versions of the Apogee Sound System? The readme states you strictly need Watcom C 10.0b to compile it, which I believe is not available publicly.

I think there is little doubt that DEMO1 ended with the player getting slimed, considering that the player keeps shooting in that small corridor between the landing bays, and the camera turns at the end (presumably to face the flemoid that finished the player off). I just wanted to point out that it is not strictly necessary for the demo to end like that. Um, this is not what I meant to say. Using the mouse or not has no bearing on how the player gets killed, but when you use the mouse the player turns visibly faster and with greater precision, which is good for playing but not always so when viewing a built-in self-running demo. If you look at the original demos in the various versions of Doom, Heretic and other Doom-engine games (including HacX), most of them produce the impression of smooth continuous movement. However, when I experimented with recording demos for my HacX MBF version for DOS (I had to record new demos because both the vanilla v1.1 demos and the new v1.2 ones would desync in MBF), I was playing with WASD+mouse and I quickly realised that using these controls results in very quick, jerky movement and turning of the player, which is not good for viewing demos at all. In the end I still used the WASD+mouse controls, but tried to move the mouse as slowly as I could so that there would be no visible jerkiness and the player would move and turn smoothly. But it seems reasonable that using keyboard only should be preferable to produce authentic-looking demos that behave similar to those recorded back in the 90s for the Doom engine games. On a completely different note, what do you think of bringing back the original video cutscenes from Chex Quest 1? They are absent from most online distributions of the game, sadly.

Actually, you don't have to kill off the Chex Warrior to end the demo, and perhaps it would be a better idea not to anyway, 'cause this is a kids' game after all. The demo can end at any moment you quit the game while recording, leaving the demo on a cliffhanger note so to speak. I noticed that both in this and the previous versions of the demo that you have recorded, you're not aiming to repeat the exact path the player follows, just the general sequence of level areas that have been visited. Also, in a few instances I think the player turned visibly very sharply, perhaps because you're using WASD+mouse? From my experience, demos looks more authentic if recorded on keyboard only, or if the mouse is used very gently for turning. Anyway, here's my take on it, still very imperfect: CQ3V_2.zip I couldn't replicate every movement because the position and number of flemoids in the final map are definitely quite different from the version of the map that was used to record the demo (assuming that my inference about the different map revision is correct). But I watched the original demo without monsters several times and tried to stay close at least to the general trajectory of the player's motion, like starting to go 'round the starting area counter-clockwise; going to the desk in the reception room and taking out the flemoid behind the desk first; and backing to the far wall of the landing bay while fighting the flemoids that arrive from the hangar. It's still very easy to screw things up because of the randomness in how monsters wander the map when activated, and the relatively low movement precision when playing keyboard only. I decided not to engage the flemoid that guards the red key; very obviously, in the original demo the player fights a differently positioned monster (or maybe two) that should have been visible when opening the blue key door from the higher landing bay, but does not take the key or even go into that area. So I just scanned the red key room (without revealing either the key or the flemoid) and then headed back to the access to the lower landing bay. Also I decided against playing a suicidal Chex Warrior and trying to get him killed after where the original demo ended. Honestly, it looks quite artificial most of the time, although I had nearly depleted my ammo and could have attacked them with the spoon instead (but there's a zorch refill in the lower bay, and the enemies are quite weak even if you only have the spoon). Later levels with higher-tier and ranged enemies would present better opportunities for making a "standard" Doom demo that ends with the monsters "getting" the player without it looking deliberate. So I just quit the game in that area. That ending part is not "canon" to the original demo anyway, no matter how you look at it or what you do there.

I was wondering, does anyone have fond memories of playing Warcraft II back in the day, or does anyone still play? It was one of my favourite games in the mid-90s, although I never played competitively (no Internet back then), but it blew my mind by being awesome in almost every way imaginable. Great visuals like my favourite animated series! You have complete control over what and where to build, where to send your forces and so on! Compelling storyline with different missions! Cute critters! etc., etc. I made a few scenarios in the editor, admittedly very amateurish (I was 11 at the time), but still very cool. It was only when StarCraft came out it pushed Warcraft II aside by superseding it in all quarters, with more compelling story and interesting characters, more sides to play, a hugely advanced map/campaign editor and so on. However, I still love the somewhat more simple and straightforward approach in Warcraft II. While the game has greatly influenced the RTS genre, and there have been numerous attempts to copy the formula, I feel that almost none have quite captured the feel of the game. There's an indie game called Wyrmsun that does a spot-on impression of the visual style, while mixing fantasy with bits of Age of Empires-esque pseudohistory. However, this project has seen sporadic development over the past few years, with some issues not being ironed out, while the more recent versions have taken design choices that I feel are rather questionable, like trying to limit base-building by introducing "building sites" for certain building types that are randomly placed on the map, instead of allowing players to construct buildings wherever they like. It would be nice to see a true spiritual successor to Warcraft II (not in the least because Warcraft III took too much of a departure from the previous game in terms of both visuals and mechanics), but so far nothing seems to quite fulfil this task.

Oh, I must have misunderstood your intent then! I have run CHEX.WAD as a PWAD and watched the demo without the altered monster behaviours. It still seems to not completely match the original intent, as the player appears to be almost certainly shooting at monsters that are not there in several instances, including the secret area with the rapid zorcher hidden behind the blue key, and in the landing bay that leads to the red key room. The demo might have been recorded with an earlier version of the map that had different monster placement, rather than in the version that did not have altered monster behaviours as you have speculated. It seems to make very little sense for Flemoids to drop ammo or weapons after being sent back to their dimension, or to have ranged hitscan attacks, whereas they are very obviously hurting the Chex Warrior by sliming him, which is not really well represented by the zombies' original hitscan attack. Furthermore, I've just recompiled MBF 2.04 (original, not my CHEX3 version) with the option to use the MBF-specific killem cheat during demos, then loaded the original 1996 CHEX.WAD and watched the demo without any monsters (but without loading chex3.deh either). It does not end in the red key room, like it does when you run the demo with monsters and default monster behaviour, instead the player, apparently, was supposed to dispatch the flemoid guarding the key, but not pick it up, and would instead go back and then downstairs, where the demo ends (see screenshot below) -- presumably after being attacked by a monster that must have either wandered in there or was placed in the version of the map that the demo was recorded with (assuming that I'm correct about the different map version). Ahh, apologies for my ignorance then, and thank you for the information (and for your reverse-engineering work!). Cheers!

I'm not sure why you'd even bring this up here. Clearly those are modding resources, not free/libre game art. That's a completely different playground, and as far as I know, usage of copyrighted assets in a mod is covered by the fair use exception, at least in certain jurisdictions. Conversely, "Flynn Taggart"'s post with modified Freedoom SKAG sprites was made in the Spriting Carnival thread, right along posts with art by @raymoohawk and other users with stuff that has since found its way into the project repo. For example, a few pages further you can see keycards by Blox (who is for some reason credited as "Bloax" in the attic), which have been used at least in v0.10 -- yet there's no "I contribute this to Freedoom" message either. Personally, I don't feel there's a stronger implicit meaning of "please accept my contribution" present in the phrase "does freedoom have decent cards?" than there is in "An edit for FreeDoom's SKAG-1337 to make it more symmetrical and to fix/smooth out the errors and inconsistencies." Oh, and nevermind, I was going to check if the timing of "Flynn Taggart"'s post somehow coincided with the decision to use @Amuscaria's weapons from Demon Eclipse, but instead found proof that "Flynn Taggart" is indeed @robotdog1, as I previously suggested: That should basically solve the issue, right? I did not remember exactly this post (but I do remember @wesleyjohnson's negative reaction to the art direction the project took with @raymoohawk's contributions stated elsewhere), but I feel there's all the more reason to archive these unused assets, so perhaps one day an alternate fork could be created with the phased-out art back in use, as originally intended. On another note, do you have these texture edits by @Fredrik accounted for? https://www.doomworld.com/forum/post/1355045 What about @Blastfrog's chainsaw? I know it's too similar to vanilla one, but it could be useful as a modding resource: https://www.doomworld.com/forum/post/1326468 For the record, I don't remember downloading the WAD file, which is no longer available.

Warcraft II was one of my first PC games as well. I remember first seeing it at my classmate's birthday party, it must have been early autumn '96 (I was ten at the time). We played the music through an ultra-cool sound system his dad had in the living room, and then I poked around with the game along with my classmate's younger brother while everyone else went for a munch. I fell in love with both the music and the game itself, you know, it looked magical on the big CRT screen. However, the PC at my home was not up-to-date for playing such a game, being an upgraded 386DX with four (IIRC) megs of RAM and no CD-ROM drive. I guess I would have appreciated the Warcraft 1 demo but I think none of my friends had Warcraft 1, actually. So I only had to content myself with listening to my friends retellings of what the game looked and played like, and looking at the rare screenshots in video game mags. Later on, I played a bit at another classmate's house, this was probably 1997 or 1998. I mostly watched as he worked through the Alterac mission where you need to free the peasants at the beginning, and then had a spin with an earlier mission all by myself. That was cool. Around that time we got a Toshiba laptop that had a CD-ROM drive and I borrowed the game to play, although not to completion. The sound was not working for some reason, maybe I got scared of the warning in the sound setup programme ("Your sound card works perfectly!") that the computer might freeze during auto-detection, and skipped the sound setup altogether. Although later on I played StarCraft (again, borrowed from a friend) on the same laptop, and the sound did not work either for some reason, although I'm pretty sure it did play Windows system sounds just fine. In December 1999 I got my hands on Horde, and also got a copy of StarCraft of my own, getting instantly carried away with the seemingly boundless capabilities of Blizzard's new hit. (I set off to write my own campaign almost right away.) However, I kept fond memories of Warcraft II and eventually revisited it with the Battle.net Edition in the mid-late 2000s. I gave that copy away to a University friend sometime later as it was gathering dust on a shelf, but later I happily purchased the GOG version. Anyways, back in the mid-late 90s I was obsessed with the game while still not being able to properly play it at home, and my attention was also caught by Rage of Mages, an RPG/RTS hybrid that I read about in a magazine, very obviously inspired by Warcraft II and Diablo (BTW, I was never particularly impressed by Diablo). The screenshots looked cool, and the preview promised amazing things too. I got ahold of a copy already as a student, in the mid-2000s. It's a decent game that plays fine and has some interesting concepts, although I've never been a particular fan of RPG grinding mechanics (in fact, I never played a single RPG during my formative video game years in the 90s), so I was less excited to play than I had imagined. There's no base-building, but you can hire mercenary troops and play missions as tactical RTS scenarios with heroes that level up. From today's standpoint, it's a quality game that has a good deal of nostalgic value to me, both from the design choices and production values. In the mid-2000s, when I got consistent Internet access for the first time, I started to collect info on various games from the 90s that I have missed back then, which is to say very many. I also downloaded the Warcraft 1 demo (I remember having to wait through a queue at FilePlanet for being an unregistered user) and played it for the first time -- I had only heard of the game before. When Warcraft III came out, I already had a powerful enough PC to play it, and bought the game soon after. Oh yes, Warcraft III. I had mixed feelings about this one. I remember snapping at all the bits of info I could get before the game's release, and honestly I was not super happy with the full 3D transition, as I had an aversion of early 3D graphics back then. But... it was still Warcraft, and nothing better was forthcoming, so after some thinking this over I decided to try the game (downloading the demo was out of the question with the dial-up Internet back then). Played the campaigns from start to finish, and then the expansion, which was thankfully better in many ways than the base game, at least for my liking. Never mastered the multiplayer/skirmish part, and never really liked the hero mechanics, the high hitpoint count for units, and the tedious battles with limited forces (which I guess was the price you had to pay for true 3D on PCs back then). It never felt like the proper sequel to Warcraft II to me, with the new races feeling a bit forced, and the scope of the game narrowing to what seemed like an RPG with an extended party rather that a strategy game where you command armies. The story did not feel particularly imaginative to me either, it mostly lost its Tolkien-esque epicness that the second game seems to have. I was also much disappointed that Blizzard cancelled Warcraft Adventures. Although I never really liked point-and-click adventure games, I'd probably play it from start to finish, had it come out in 1997 or 1998. The animated style was excellent, a perfect match for Warcraft II's in-game visuals -- I wish they had drawn Warcraft II in-game cutscenes in the same style, rather than use pure pre-rendered CGI that hasn't aged very well. I was really waiting for Warcraft Adventures to come out, especially since the StarCraft CD contained a teaser. It would have expanded the game world for me in ways that I had imagined by playing Warcraft II, reinforced by similar-style animated series like Conan the Adventurer that I'd watched on TV only a few years prior. Oh well.

Trying to apply some common sense here, it is my understanding that a) people who post images in the Spriting Carnival topic and in the Show Your Sprites thread here, usually do not do so with the intention that no one ever uses the art that they post, although not everyone accompanies posts with an explicit permission; and b) modders that explicitly prohibit reuse of their assets usually do so because they want their mod creations to have unique art. Flynn Taggart accompanied the SKAG edits with the following text: The intention to use the art in some private project is not evident here, although admittedly it does not say "I want to contribute this to Freed∞m" either. I'm not even mentioning the fact that you need to take quite a close look and compare both versions to actually notice the edits that Flynn Taggart made to @Fredrik's sprites. I understand that you want to err on the side of caution, but personally I don't believe it would constitute any violation of Flynn Taggart's rights if these edits were included in the attic or in an actual build of either Freed∞m or Lotan's Tomb (or whichever other fork). BTW, if you have a ZDoom forums account, perhaps you could try reaching out to that user and ask directly? Because I'm not sure if this is the same user as one of the several Flynn Taggarts registered here. I'm fairly certain that @fraggle was referring to rather different kinds of "legal discussions". Since the current question is whether or not we should count an edited Freed∞m sprite as 3BSD-licensed, I think this is quite an important matter to have a clear, unambiguous answer to, rather than just sweep it under the rug. Back on the topic of completing the attic, have you looked here? https://jmtd.net/tmp/freedoom_old_ftp/ There are mostly maps, sounds and music, but also some sprites. However, unlike what I thought, this is not the place where the most recent update of @wesleyjohnson's Large Technospider is located -- that would be in @Catoptromancy's archive (wesley/spid_v80.wad), which I believe was never contributed to the main repo, although it is an improvement over the current version. One thing though, I believe that the horizontal offsets in the WAD are wrong because they are the same as the older version, even though the new sprites are about twice as wide.

Congratulations on the milestone 1.0 release!

Yes, very definitely, please feel free to use these versions! Thanks for the information! I had to convert MIDIs to MUS because the way @ludicrous_peridot's support for GENMIDI+OPL2 works, the music needs to be in the MUS format. I simply used the midi2mus utility without passing any parameters. I has worked fine for me before with other projects. If you want, I can also put the MBF extended menu lumps into the PAT wad (or upload them right here) so you could incorporate them into the main IWAD. They should work with all BOOM/MBF-derived ports like PrBoom and Woof! BTW, here's the fixed coredata.wad without the DECHAKED patch, for anyone interested: coredata.zip That does not seem like a good idea to me at all. From my experience, it is always safer to record a new demo, rather than try to adapt an old one to an updated map/release. Well, there's no problem to make the MBF version recognize chex3d2.wad as a valid IWAD -- I commented out all Doom II/Final Doom IWAD names from d_main.c, because the port's logic prioritises Doom II over the original, and if a user accidentally put a Doom II IWAD into the IWAD folder, this would break the game. I was thinking, maybe @NY00123 and the gamesrc-ver-recreation team could do their magic to the original CHEX.EXE and restore the code? That would help immensely to recreate the true vanilla binary, as opposed to a hacked Doom one. (My understanding is that CHEX.EXE was build from modified source, not hacked into like HACX.EXE for example.) I never watched the original demo to the end before, so I tried to recreate it as well. Here are my two takes: chex3demos.zip It is indeed not easy to create an exact reenactment, even though I tried to mimic the player's movements as close as I could, because the flemoids in the blue room seem to move in different directions. However, I believe I was able to make it look more natural in both cases. UPD: I had a simple idea: if you want a demo to desync, what could be better than one that desyncs for real? So I used the original CHEX.EXE to load chex3v.wad as a PWAD and recorded the first level (there are two takes): desync.zip As I expected, both desync when played back in either vanilla Chex Quest 3 or in the MBF version, with very similar results to the original desyncing demo.