Never_Again

Take 2: REPENT2 by Drew Cerny, also available as REPENT - minor map differences, no music. edit: Take 1, includes a comment on TRILOGY by Marc 'Wolfy'.

@thestarrover: The E1L1 WAD (dated 1994-03-19) you linked to on the previous page is clearly a slight modification of the E1M1 from a pre-v1.2 IWAD, so I'm puzzled by your later remark Were you thinking of some other WAD? The dates for all three WADs you listed look OK. The maps are all basic edits of levels from a shareware IWAD, "basic" meaning "no changes to 2D geometry". The reason is stated in the first post of this thread (the first sentence after the list itself, in fact): "Only WADs containing original, new-from-scratch levels are included". That excludes any IWAD level edits, regardless of the extent of the modification done to the levels. There are some really good early edits out there, of which Greg Grimsby's E2L2_GG1 (March 24) is probably the best; they are not the subject of this thread, though. It's on the Deathday Collection CD-ROM in \MIXED\DMMKS and \WADS\1 with the 1994-03-26 9:58:24 pm date. The various March 27 entries in my collection all reproduce the x:58:24 part, only the hour part is different (from 4am to 1pm). These are important details that I was not aware of. I have copies of DE_250B3.ZIP but not the earlier DE_250B.ZIP. Could you provide a link to it, please? Preferably to an archive.org CD-ROM with a browseable file list. Good point. DYLAN2 was intentionally omitted as it is not an original; therefore I should have limited the STEPSx entry to STEPS1 and it should be dated March 28. As for MINE1, the following CD-ROMs at least list it with the March 29 timestamp: - 1000 Doom Levels - 4-ever-Doomed - Cobra Doom Utilities - D!Zone 150 - Doom Magazine - Doom Mania Perhaps there was a DE_250B2.ZIP on 29th? re: DMGRAV: we might never know for sure but given the meager data I'm inclined to concur.

The entire Episode 6 is ripped from PE3_INCI.

1KILLTNG MAP13 has two zero-length linedefs, 1891 and 2234, among other errors (open sectors, vertices not splitting linedefs they are on, etc.). But that's not what crashes Choco, though it may have thrown off the unknown nodebuilder used on that map, creating two segs with invalid references elsewhere: P_LoadSegs: linedef 2223 for seg 3761 references a non-existent sidedef -1 P_LoadSegs: linedef 2220 for seg 3765 references a non-existent sidedef -1 Fixing those two segs in SLADE allows Choco to load the map. Vanilla doesn't seem to mind either way. Good question, that. The standard procedure is to open an issue on the Github project's tracker. When it will be acted upon and even if it will be acted upon at all is anybody's guess. The Medusa issue referenced above, for example, predates the Github repo itself. It illustrates perfectly the old trope "After everything has been said and done, a lot more has been said than done". Quasar's experimental Medusa-emulation branch has been allowed to rot into obsolescence and the same fate apparently awaits the Doom v1.6 emulation and the Doom v0.99 demo support PRs. The latter also includes v1.1 support and various fixes affecting the existing -gameversion 1.2. It has been awaiting a review for three years now. This call for a new release has been gathering dust for two years. The list goes on and on. How many more years have to pass before we muster enough courage to ask ourselves some hard questions, like "Has Chocolate Doom been abandoned by its creator?", "Does this project in its current state have any future?" and "What are we going to do about it?".

Doom Wiki: Versions of Doom and Doom II The Cutting Room Floor: Doom (PC, 1993)/Revisional Differences The latter is more extensive and detailed, albeit not without inaccuracies. For file checksums you could use 7-zip. It adds a "CRC SHA" item to Windows Explorer's context menu. Supports two varieties each of CRC and SHA. A great archive program, too; handles anything from ZIP, ARJ, TAR to RAR and ISO. For MD5 I would recommend HashMyFiles, which also doubles as an indispensable tool for duplicate files detection.

In both Choco and Crispy D1 monsters' projectiles trigger walkover line specials only in v1.2 compat, as expected. See P_CrossSpecialLine in p_spec.c: if (gameversion <= exe_doom_1_2) { if (line->special > 98 && line->special != 104) { return; } } else { // Triggers that other things can activate if (!thing->player) { // Things that should NOT trigger specials... switch(thing->type) { case MT_ROCKET: case MT_PLASMA: case MT_BFG: case MT_TROOPSHOT: case MT_HEADSHOT: case MT_BRUISERSHOT: return; default: break; } } } The wiki article Projectiles triggering linedefs explains the above and is mostly correct, except for listing line specials 125 and 126 - those were not present in v1.2 and older.

Affirmative.

E2M1 = REPENT.WAD by Drew Cerny, also available as REPENT2 which adds a music track. E1M2 and E1M3 are original levels by the compilation's author, Marc "Wolfy". archive.org links for the two WADs: DMDOOMED.WAD TRILOGY.WAD The way I see it this is not a compilation, all maps being by the same author and the whole WAD put together by himself. There are some other multi-level WADs where some of the maps had been released separately - e.g. 666EPIS (mentioned earlier by Doomkid), preceded by 666 and 777; and SERENITY, preceded by NATHRATH. Seriously, would you consider SERENITY a compilation?

That happens when Getwad is not set up in prboom-plus.cfg. The entry is in the "Prboom-plus demos settings" section and should look like this: getwad_cmdline "c:\DOOM\getwad\getwad.exe -d "d:\WADS""

Nice find. That's Medusa. Choco crashes because its default heap size (16 MB) is twice that of vanilla. You can avoid crashes if you run it with "-mb 8". What the blue key enclosure will look like will depend on the heap's contents; the look above can be reproduced by accessing the menu. Close enough to what vanilla shows, which is also highly variable. Timeline: Silent crashes on levels with Medusa were reported in 2014.

Relative paths work just fine with my builds; yes, I have tested that. It's the code straight from the master branch, my only addition being the -mconsole flag for the linker to make a working console. The problems you are having with the builds are not due to the builds themselves but with how you run them. Yes, you can use relative paths if you want to; but you need a firm grasp of the "working dir" concept and to be able to account for the different ways it is set under Windows, depending on the invocation method: command prompt, batch file, shortcut, call from another program etc. re: "since ages": %DOOMWADDIR% was in prboom at least five years before prboom-plus was a thing: In light of the above reads very much like "I don't see the need for a fishing net because I have been catching fish with my bare hands since ages". :)

There's nothing in my builds that would prevent use of relative paths. You or the launcher, when you use it, don't specify the correct working (current) dir. For a batch file it would like this: @echo off d: cd d:\doom\prboom-plus prboom-plus.exe <your params here> if D:\doom\prboom-plus is your prboom-plus dir. Once again, you can save yourself the trouble of specifying any paths by setting %DOOMWADDIR%. Here is a step-by-step tutorial on how to do it under various Windows versions. The var it deals with is %PATH% but the principle and the steps are exactly the same.

It's under Computer->Properties->Advanced System Settings->Environment variables. %DOOMWADDIR% takes a single path and is for IWADs. %DOOMWADPATH% can have multiple paths separated by semicolons and is for PWADS: SET DOOMWADPATH=C:\DOOM\WADS\1;C:\DOOM\WADS\2 Both can be overriden from the command prompt or via batch files.

Do you have DOOMWADDIR set properly in your enviroment? Point it to the folder where your IWADs are and use the absolute path. You won't need to specify a path in the launcher then.

Good point about the Windows dependencies package not being updated. If some of them (cough ... SDL2 ... cough!) happen to introduce bugs how is the user expected to detect and report those bugs? MSVC bins as default for the Github Actions is a pretty odd choice. I was under the impression that most port devs ran some flavor of Linux.