[RC4.1] Chex Quest 3: Vanilla Edition

This includes the maps from Chex 1 and 2, right? So you basically play all the maps and you don't need anything else, correct?

7 minutes ago, VGA said:

This includes the maps from Chex 1 and 2, right? So you basically play all the maps and you don't need anything else, correct?

Yup, all levels from the original CQ1 and CQ2 with some minor tweaks and updates, just as in the original ZDoom version of Chex Quest 3.

@Melodic Spaceship, I took the liberty of making a dedicated DOS port for your version, based on Gerwin Broers' MBF Maintenance release 2.04 (and the similar projects I did for HacX 1.2 and REKKR). It loads chex3v.wad as a PWAD and uses a miniwad-based IWAD that the game detects as Doom Registered, thus offering only three selectable episodes.

Download:

• chexmbf.zip - DOS binaries, needs chex3v.wad to play; includes modified IPXBOOM and SERBOOM for multiplayer
• chxmbf_s.zip - source code, you will need @ludicrous_peridot's modified Allegro library to compile

It fully implements all text, exit messages and cheat codes. BTW, I noticed that in your vanilla-based DOS version, the invulnerability powerup cheat is truncated to andrewb, while in the original DOS Chex Quest, you need to enter andrewbenson to activate it. The MBF version replicates the intended behaviour, with all cheats implemented at their full length.

Special thanks go to @Eevee for the Doom Text Generator, which spared me an hour or two by allowing to quickly generate additional menu text lumps for the extended MBF menus.

I briefly tested the game and everything seems to work. I played through the entire Episode 2 on HMP, it worked smoothly in DOSBox at 33445 cycles. I remember the Chex Museum level gave me lags in certain areas when I played the original ZDoom version a good while ago (probably over ten years back), but in the Vanilla Edition it worked very well, without any framerate drops at all. Excellent job!

8 hours ago, MrFlibble said:

@Melodic Spaceship, I took the liberty of making a dedicated DOS port for your version, based on Gerwin Broers' MBF Maintenance release 2.04 (and the similar projects I did for HacX 1.2 and REKKR). It loads chex3v.wad as a PWAD and uses a miniwad-based IWAD that the game detects as Doom Registered, thus offering only three selectable episodes.

Very interesting! While I'm not entirely sure about using this to replace the current official DOS version, this seems like a pretty decent alternative for those who would prefer a more polished DOS version. Who knows, maybe I could just consider offering two separate "MBF DOS" and "Vanilla DOS" versions.

One thing I might suggest is also adding support for the "modding version" (chex3d2.wad).

Edit: About the truncated cheats, that was done because of vanilla string length limitations as a result of having to hack the original executable.

Edit 2: Okay, I just noticed a slight issue. The oxygen tanks (and possibly other objects) have a red palette translation when they shouldn't. It's possible this could be fixed from Chex 3 Vanilla's end, though it would be nice if the MBF fork was altered to not do that.

Edit 3: Okay, I think I found the culprit here. It's the DEHACKED lump in "coredata.wad". That needs to be removed or ignored in order to not mess with Chex 3 Vanilla's sprites.

@Melodic Spaceship, thank you for the feedback! I'll take a look into the palette translation issues you've mentioned.

11 hours ago, Melodic Spaceship said:

Okay, I think I found the culprit here. It's the DEHACKED lump in "coredata.wad". That needs to be removed or ignored in order to not mess with Chex 3 Vanilla's sprites.

I just looked into this, I did not realise that miniwad1 contains some extensive DeHackEd tweaks, likely not intended to be used with mods. It did not occur to me to check the DeHackEd lump contents, because in the original (Doom II-only) miniwad by @fraggle, the DeHackEd lump only contains some harmless text replacement without any game behaviour tweaks (IIRC).

Speaking of palette swaps, I noticed that chex3v.wad includes MBF translation tables (CR*), most of which do nothing to change the colour of the green HUD font that is used in the extended menus. Moreover, they seem to exclude the original red colour range (palette indices 176 to 191), breaking the colours on the minimized HUD. I have included my versions of these translation tables that cover both the red (176-191) and green (112-127) ranges, both hardcoded in the EXE and supplied in CHEX_PAT.WAD, to override the ones in chex3v.wad. From what I understand, it should be no problem to keep both ranges, because these tables only affect the menu and HUD text and nothing else (e. g., they're unrelated to player colours in multiplayer games).

I forgot to mention in my previous post, I noticed that DEMO1 seems to desync a bit towards the end. I checked this both in your vanilla build and in the MBF version, the plays the same (so no problem on MBF's part). The demo ends with the player trying to get the red key, but somehow starts shooting into the wall while being flanked by a Flemoid. The demo then stays for a few seconds after the Flemoid finishes the player off, which is a sign of a desynched demo usually. The other demos seem to play fine, without any desynching.

12 hours ago, Melodic Spaceship said:

One thing I might suggest is also adding support for the "modding version" (chex3d2.wad).

I've just tried loading chex3d2.wad in MBF, but it exits to DOS with a "Segmentation Violation" message as soon as I start a new game (or try to level-warp from the command line). I'm not sure what causes this, but I see that there are empty NODES lumps in every map -- possibly related?

12 hours ago, MrFlibble said:

Speaking of palette swaps, I noticed that chex3v.wad includes MBF translation tables (CR*), most of which do nothing to change the colour of the green HUD font that is used in the extended menus. Moreover, they seem to exclude the original red colour range (palette indices 176 to 191), breaking the colours on the minimized HUD. I have included my versions of these translation tables that cover both the red (176-191) and green (112-127) ranges, both hardcoded in the EXE and supplied in CHEX_PAT.WAD, to override the ones in chex3v.wad. From what I understand, it should be no problem to keep both ranges, because these tables only affect the menu and HUD text and nothing else (e. g., they're unrelated to player colours in multiplayer games).

Oh, I didn't realize that it was also used for the small fullscreen HUD font. At any rate, the color translation lumps were already going to be updated in the upcoming 1.0 to add more proper translations, but I went ahead and edited them to still change the red colors. Could I maybe use the ones you made for CHEX_PAT.WAD in the official base version of chex3v.wad for 1.0?

12 hours ago, MrFlibble said:

I forgot to mention in my previous post, I noticed that DEMO1 seems to desync a bit towards the end. I checked this both in your vanilla build and in the MBF version, the plays the same (so no problem on MBF's part). The demo ends with the player trying to get the red key, but somehow starts shooting into the wall while being flanked by a Flemoid. The demo then stays for a few seconds after the Flemoid finishes the player off, which is a sign of a desynched demo usually. The other demos seem to play fine, without any desynching.

About the supposed demo desyncing, it's not actually desynced. Those are actually the exact movements I made when recording that demo, and it ended up resembling a desynced demo even though it's not. I was trying to intentionally get slimed by that Flemoid but it was too hard to not make it obvious that it was intentional, because the demo's actually a re-enactment of this.

12 hours ago, MrFlibble said:

I've just tried loading chex3d2.wad in MBF, but it exits to DOS with a "Segmentation Violation" message as soon as I start a new game (or try to level-warp from the command line). I'm not sure what causes this, but I see that there are empty NODES lumps in every map -- possibly related?

Yeah, it seems like even though vanilla handles the dummy levels just fine, some source ports can't handle levels with only 1 sector. Looks like I might just need to add a second sector in all the dummy levels for the next version, to prevent crashing. At any rate, since chex3d2.wad is not meant to be run completely on its own anyways maybe it's not that big of a deal, unless you don't want any crashing after a PWAD's custom levels.

Also, here's an issue I noticed with D_EPIC_W in CHEX_PAT.WAD: It plays way slower than it's supposed to. That particular MIDI track always has that issue when converting to MUS so it requires more manual work to get a proper conversion of it. chex3v.wad already has a properly converted MUS version of it as the D_BUNNY lump, so you can just go ahead and copy that into CHEX_PAT.WAD under the name "D_EPIC_W".

1 hour ago, Melodic Spaceship said:

About the supposed demo desyncing, it's not actually desynced. Those are actually the exact movements I made when recording that demo, and it ended up resembling a desynced demo even though it's not. I was trying to intentionally get slimed by that Flemoid but it was too hard to not make it obvious that it was intentional, because the demo's actually a re-enactment of this.

You know, this got me thinking, wouldn't it be possible to hex-edit the original demo file from CHEX.WAD to load the correct level in CQ3V?

2 hours ago, OpenRift said:

You know, this got me thinking, wouldn't it be possible to hex-edit the original demo file from CHEX.WAD to load the correct level in CQ3V?

I'm pretty sure it would go out of sync if I did that. Sure, it may technically match how it is in the original Chex Quest, but as the linked video shows, that's actually out of sync too. I chose to remake it in order to match the original intention with the demo.

17 hours ago, Melodic Spaceship said:

Oh, I didn't realize that it was also used for the small fullscreen HUD font. At any rate, the color translation lumps were already going to be updated in the upcoming 1.0 to add more proper translations, but I went ahead and edited them to still change the red colors. Could I maybe use the ones you made for CHEX_PAT.WAD in the official base version of chex3v.wad for 1.0?

Yes, very definitely, please feel free to use these versions!

17 hours ago, Melodic Spaceship said:

Also, here's an issue I noticed with D_EPIC_W in CHEX_PAT.WAD: It plays way slower than it's supposed to. That particular MIDI track always has that issue when converting to MUS so it requires more manual work to get a proper conversion of it. chex3v.wad already has a properly converted MUS version of it as the D_BUNNY lump, so you can just go ahead and copy that into CHEX_PAT.WAD under the name "D_EPIC_W".

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

15 hours ago, OpenRift said:

You know, this got me thinking, wouldn't it be possible to hex-edit the original demo file from CHEX.WAD to load the correct level in CQ3V?

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.

17 hours ago, Melodic Spaceship said:

Yeah, it seems like even though vanilla handles the dummy levels just fine, some source ports can't handle levels with only 1 sector. Looks like I might just need to add a second sector in all the dummy levels for the next version, to prevent crashing. At any rate, since chex3d2.wad is not meant to be run completely on its own anyways maybe it's not that big of a deal, unless you don't want any crashing after a PWAD's custom levels.

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.

On 9/10/2024 at 3:25 AM, Melodic Spaceship said:

Edit: About the truncated cheats, that was done because of vanilla string length limitations as a result of having to hack the original executable.

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.)

17 hours ago, Melodic Spaceship said:

About the supposed demo desyncing, it's not actually desynced. Those are actually the exact movements I made when recording that demo, and it ended up resembling a desynced demo even though it's not. I was trying to intentionally get slimed by that Flemoid but it was too hard to not make it obvious that it was intentional, because the demo's actually a re-enactment of this.

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.

10 hours ago, MrFlibble said:

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.)

Guess what? The work had already been done in early 2022. I added reconstructed Chex Quest specific code to the Doom repository found there.

12 hours ago, MrFlibble said:

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 the main reason I suggest this is because the original demos should be compatible with the original maps, right? All the behavior should be identical and thus be demo-compatible. If this was a situation where the map was modified or rebuilt with a different node builder, then I'd understand, but that isn't the case. Am I missing something here?

4 hours ago, OpenRift said:

Well the main reason I suggest this is because the original demos should be compatible with the original maps, right? All the behavior should be identical and thus be demo-compatible. If this was a situation where the map was modified or rebuilt with a different node builder, then I'd understand, but that isn't the case. Am I missing something here?

I mean, even not taking into account the fact that the demo was already desynced in the first place, from my experience demos can and will desync from even the most seemingly inconsequential changes. Hell, I had to re-record my fully own CQ2M1 demo between RC4.1 and the upcoming 1.0 because of seemingly minor tweaks. I just don't think it's a good idea since demos seem to desync if you so much as look at them funny. Also, Chex 3 Vanilla has really subtle behavior differences from Chex 1 that could also cause a desync.

Edit: I looked at @MrFlibble's demos. I appreciate the attempt in helping to make a new demo, but I was aiming for having the demo match how it is when the original DEMO1 is played back in DOOM.EXE, rather than the desynced form played back in CHEX.EXE.

2 hours ago, Melodic Spaceship said:

Also, Chex 3 Vanilla has really subtle behavior differences from Chex 1 that could also cause a desync.

Ah okay. That was the information I was looking for.

18 hours ago, Melodic Spaceship said:

I appreciate the attempt in helping to make a new demo, but I was aiming for having the demo match how it is when the original DEMO1 is played back in DOOM.EXE, rather than the desynced form played back in CHEX.EXE.

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).

23 hours ago, NY00123 said:

 

Guess what? The work had already been done in early 2022. I added reconstructed Chex Quest specific code to the Doom repository found there.

Ahh, apologies for my ignorance then, and thank you for the information (and for your reverse-engineering work!). Cheers!

8 hours ago, MrFlibble said:

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.

Ah, good catch! In that case, I went ahead and re-recorded the demo to bring it closer to the apparent true original intention. One difference is that I had to go through the door after heading downstairs since I couldn't get attacked by a Flemoid there, and I instead had to go a bit further to get attacked. But I guess you can't make things completely perfect when re-enacting an old desynced demo. Get it here and tell me what you think: cq3v_1.zip (Demo is for Chex 3 Vanilla)

12 hours ago, Melodic Spaceship said:

One difference is that I had to go through the door after heading downstairs since I couldn't get attacked by a Flemoid there, and I instead had to go a bit further to get attacked.

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.

12 hours ago, MrFlibble said:

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

Interesting take on it, but I checked the other demos included in chex.wad (which, unlike the first demo appear to only play back correctly with CHEX.EXE), and they do all end in the Chex Warrior getting slimed, so we can probably infer that would've been the intention with DEMO1 too. Besides, since you don't actually die in Chex Quest and just get slimed I don't think it would make it any less family-friendly. I'm personally satisfied with my second take on the demo, which is more consistent with the other built-in demos in Chex 3 Vanilla anyways (which likewise were recorded with WASD+mouse and ended in the player getting slimed, with the exception of CQ1M0 since that level doesn't have any hazards whatsoever). Although I suppose for future reference I can keep in mind that keyboard-only is good for ensuring I die on a built-in demo.

7 hours ago, Melodic Spaceship said:

and they do all end in the Chex Warrior getting slimed, so we can probably infer that would've been the intention with DEMO1 too

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.

7 hours ago, Melodic Spaceship said:

keyboard-only is good for ensuring I die on a built-in demo

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.

What's up with all this talk about demos? Is it really important?

10 hours ago, VGA said:

What's up with all this talk about demos? Is it really important?

If the attempt is authenticity, I can fully understand a desire to keep the demos working.

That said, that doesn't seem to be the focus of this project, so in my opinion recording new demos seems perfectly fine.  I think the existing ones get the job done very well.  The "feel" of a lot of the level geometry changes gives me Doom Jaguar vibes, in a good way.  This is exactly the kind of project I've been waiting for, since up until now, to the best of my knowledge, there hasn't been any attempts to make Chex3.wad work in anything other than ZDoom, what with it's bizarre use of custom coding and Hexen mapping.  (No offense to the creator, because I love the levels and the work put into remastering all the previously released levels.  It's a similar criticism I've aimed at Romero's Sigil projects, which I also otherwise love.)

The only real point of contention I'd offer, personally, is that I don't really see much of a point in "level 0".  You walk in, read a slide, and leave.  It's not exactly jumping into the action there.  It's more useful to have those videos play on their own, as in a batch file that starts up that opening cinematic in full screen before going into the game right after.  The videos are really the best way to experience the silly commercial story of this thing anyway, in all their 90's "just add milk" glory.  Hey do the flemoids have any relation to the soggies?  I just searched for that.. and I found a set of tabletop RPG rules for the various "races" of cereal mascots.  Thank you internet! https://i.4pcdn.org/tg/1601676253885.pdf

Perhaps the "intro" scene, if it's considered important, can be shunted off to a "forth episode" replacing "Thy Flesh Consumed" (which... now that I think about it is a perfect way to describe how most outside entities view creatures made of cereal).

I know it's beyond the scope of this project, but might there be interest in making a sort of "in between" port, with all the same level geometry of Chex Quest 3, but requiring a limit-removing port like certain hacked DOS versions or Crispy Doom?

16 minutes ago, Dark Jaguar said:

The only real point of contention I'd offer, personally, is that I don't really see much of a point in "level 0".  You walk in, read a slide, and leave.  It's not exactly jumping into the action there.  It's more useful to have those videos play on their own, as in a batch file that starts up that opening cinematic in full screen before going into the game right after. 

Since this is running on vanilla Ultimate Doom, a "level 0" is needed to pad out the early secret exit trick. There is only 5 maps on the standard CQ episode but 9 total on vanilla Doom, the shortest path in UD one can take on E1 is "1 > 9 > 4 > 5 > 6 > 7 > 8" leaving 7 maps total, M1 matching to the "level 0".

38 minutes ago, Dark Jaguar said:

The only real point of contention I'd offer, personally, is that I don't really see much of a point in "level 0".  You walk in, read a slide, and leave.  It's not exactly jumping into the action there.
Perhaps the "intro" scene, if it's considered important, can be shunted off to a "forth episode" replacing "Thy Flesh Consumed" (which... now that I think about it is a perfect way to describe how most outside entities view creatures made of cereal).

Basically what @elf-alchemist said above. I just thought it would be a good idea to base the required filler levels off of the intro/ending cutscenes. I did initially consider having them get skipped over in source ports that support MAPINFO, but it was ultimately decided to not do that as I put too much effort into making MIDI recreations of the intro/outro soundtrack, plus there were concerns about sync between non-MAPINFO and MAPINFO ports.

38 minutes ago, Dark Jaguar said:

I know it's beyond the scope of this project, but might there be interest in making a sort of "in between" port, with all the same level geometry of Chex Quest 3, but requiring a limit-removing port like certain hacked DOS versions or Crispy Doom?

Well, making the levels vanilla-compatible was actually a two-step process where I made a limit-removing version first and then reduced that down to vanilla. Since I already have limit-removing versions, I could possibly release an alternate version or PWAD with these limit-removing versions of the levels.

I see!  Thank you now I understand why it was done as it was, and if you'd already explained this earlier then my apologies for missing it.

If you already have limit-removing versions, that's wonderful!  I must say I was just expecting a polite declining of my vain hope but this is delightful to hear!  A version with vanilla limits, and a limit removed version!  Good stuff!
 

3 hours ago, elf-alchemist said:

Since this is running on vanilla Ultimate Doom, a "level 0" is needed to pad out the early secret exit trick. There is only 5 maps on the standard CQ episode but 9 total on vanilla Doom, the shortest path in UD one can take on E1 is "1 > 9 > 4 > 5 > 6 > 7 > 8" leaving 7 maps total, M1 matching to the "level 0".

I keep forgetting just what aspects are hard coded in vanilla, and this illustrates that pretty well.  I presume similar limitations aren't an issue in episodes 2 and 3 then?

In either case, the "intro level" grew on me a little, in the sense that I remembered just who this game was originally intended for.  Providing a moment to simply get used to how to move around in the world without worrying about anything dangerous is a good intro for younger children perhaps.

32 minutes ago, Dark Jaguar said:

I keep forgetting just what aspects are hard coded in vanilla, and this illustrates that pretty well.  I presume similar limitations aren't an issue in episodes 2 and 3 then?

The limitations are the same in episodes 2 and 3, but their secret levels are later in the episode so you can skip more levels that way. For episode 2 the progression is 1 -> 9 -> 6 -> 7 -> 8, and for episode 3 the progression is 1 -> 2 -> 9 -> 7 -> 8.

16 hours ago, MrFlibble said:

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.

Well, on one hand it would be redundant with CQ1M0 and CQ1M6 which have to be included for reasons stated above. However, maybe if I switch the engine for the DOS vanilla executable from a hacked DOOM.EXE to something based on the reverse-engineered code I could theoretically add an SMK player to the engine. Maybe I could just have the intro video play after the level version, and the ending video play before the level version.

11 hours ago, Melodic Spaceship said:

Well, on one hand it would be redundant with CQ1M0 and CQ1M6 which have to be included for reasons stated above.

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.

11 hours ago, Melodic Spaceship said:

However, maybe if I switch the engine for the DOS vanilla executable from a hacked DOOM.EXE to something based on the reverse-engineered code I could theoretically add an SMK player to the engine.

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.

16 hours ago, elf-alchemist said:

Since this is running on vanilla Ultimate Doom, a "level 0" is needed to pad out the early secret exit trick. There is only 5 maps on the standard CQ episode but 9 total on vanilla Doom

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.

Of course you can modify the executables/source code to do whatever, but I thought the point of this project was to make it compatible with vanilla Ultimate Doom and any source port.

Yeah, I just thought it'd make things smoother and more polished if I did things in a way that did not require source ports to explicitly support Chex 3 Vanilla or some form of MAPINFO. Plus, I wanted to allow any vanilla PWADs for Chex 3 Vanilla to use the Doom-style arrangement of levels if needed. However, if you still personally prefer the arrangement you're using there, you're free to continue using it in that manner for MBF Chex 3. But the "official" version is not going to have its level arrangement changed, for various reasons.

17 hours ago, Melodic Spaceship said:

Yeah, I just thought it'd make things smoother and more polished if I did things in a way that did not require source ports to explicitly support Chex 3 Vanilla or some form of MAPINFO.

17 hours ago, Melodic Spaceship said:

But the "official" version is not going to have its level arrangement changed, for various reasons.

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!

On 9/15/2024 at 3:31 AM, Melodic Spaceship said:

I made a limit-removing version first and then reduced that down to vanilla. Since I already have limit-removing versions, I could possibly release an alternate version or PWAD with these limit-removing versions of the levels.

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?