JPL

Let me check my source control history for the project (for the map files themselves not pure MAPINFO changes like level order, skies etc): (All the texture assignments I did to fix conflicts.) Fixed an unattainable secret in Klie's "CPU" map. Tagged blue key for medium difficulty in Mustaine's map14 homage - this was almost certainly an oversight Fixed unattainable secret in dante25 aka if_map01 Removed unneeded GLNODES in trouble aka tt_map06 Rebuilt cb_map05 and cb_map09 reject lumps with ZenNode, hopefully not a foolish move? cb_map05: NE triangle shaped room: untag tiny sector inside teleporter as secret, tag surrounding sector as secret cb_map09: grid stairs in center right of brain maze: untag teleporter sector itself as secret, tag destination sector with mega as secret nudge over thing 575 (armor bonus) and its siblings in brain maze so that it's not halfway out of the world same for thing directly north of it in same hallway dark lava rock pit southest of right eye: untag teleport sector here Fixed Trouble on Titan (tt_map06) floor height, made after an earlier sector edit, making secret inaccessible (I think this was just a fix to a previous unintentional change I made.) That's all I could find. These were all done to fix bugs and/or allow 100% kills + items + secrets. I do wish there were a good "map diff" tool that would just tell you everything about a WAD that's changed.

Oh wow, this is very cool, congrats on the release! Really glad that someone made a non-ZDoom-only, non-WadSmoosh requiring, more super duper version of Works of the Masters.

Okay, I'm not going to help you troubleshoot that. I assume from your earlier replies that the initial problems you were having with WadSmoosh were resolved, or it worked fine from the start and you just weren't finding the PK3 file it output? Doesn't matter, I guess. Good luck.

The PK3 (doom_complete.pk3) WadSmoosh produces is an "IWAD", aka a replacement for doom.wad and doom2.wad. Put it in the same directory as your gzdoom.exe and select WadSmoosh from the list of IWADs that GZDoom pops up on first launch (you can also get that window to come back up from the GZDoom options menu, IIRC). There's no real reason to edit the doom_complete.pk3 directly, the intended usage of WadSmoosh is to run it once and not need to run it again (unless you buy new retail content like Final Doom or the Master Levels and want to integrate that). If you're developing levels, just point your editor to doom.wad or doom2.wad; those are the canonical resource files that you know everyone has. WadSmoosh has no overlap with level editing, it was created solely as a way to combine all your retail content (ie official releases you pay for, that can't be distributed freely like any mod would) into one file you can play without restarting GZDoom.

No, I just wanted to make sure it wasn't in a folder that couldn't be written to. I'm baffled by why WadSmoosh isn't producing a wadsmoosh.log file for you. When you run WadSmoosh, does the window stay up so you have a chance to read it? If so, can you try scrolling upward to see if you can spot any of the errors it mentions as it's completing? You could try copy-pasting everything from that window here - that's basically what gets written to the log file anyway.

No worries! Just trying to work through the possible causes for your problem. When you ran wadsmoosh.exe, it should have produced two files, doom_complete.pk3 (the file that GZDoom can use in place of doom.wad / doom2.wad) and wadsmoosh.log. If you don't see those files in the folder next to the EXE and other stuff, then maybe you're running it from a folder that you don't have write permissions for? Did you extract the ZIP to C:\Program Files\ by any chance? Windows doesn't allow programs to store things in that folder and certain others on the system (C:\Windows\ being another example). If that is the case, and you have a folder called something like "Downloads" (C:\Users\[your username]\Downloads), try extracting and running Wadsmoosh from there (with the WADs you dropped into source_wads, of course). This might not be the cause of the problem but it's worth trying to help narrow down the issue. Don't touch "base_library.zip", that is an internal file used by Wadsmoosh (specifically, it's part of the Python interpreter the program uses).

Just in case this can be answered by it, here's the "Absolute Beginner's Guide" instructions from the readme in the ZIP you downloaded: If you do these steps and don't see a doom_complete.pk3 file, let me know. Wadsmoosh.log should be in the same folder where you extracted the ZIP.

By "how are you running WadSmoosh" I specifically want to know what steps you took to run it. Where did you extract the wadsmoosh.zip file to? Did you run by double clicking the EXE? If so, did a window pop up? Or did you run it from a Command Prompt (ie typing in wadsmoosh.exe in a terminal window)?

Hi. First two questions should probably be, how are you running WadSmoosh and where did you download it from?

Having spent a lot of time looking at old FPS engines and more recently some time looking at ScummVM and SCUMM specifically, I think the biggest differences are that adventure games have way simpler technical demands that lend themselves to a common "everything engine". Scumm was definitely upgraded over the years (1987-1997) to do many new things, and even fully rewritten once, but there weren't any real "paradigm shifts" in hardware capabilities that changed everything the way Wolf3D -> Doom -> Quake -> onward did. The latter technical leaps meant massive changes to data formats, simulation, rendering, networking, the works. As plenty of projects have shown you can definitely "emulate" Doom in Quake and even kinda vice versa, but FPS are so dependent on things like how the lower level controls and collision feel, how levels are constructed, and how game logic is defined. At the point that you're writing entirely different code paths to cover those differences, you might as well have different engines with a few shared libraries, which is what we have anyway across all the different source ports. I don't get the impression that duplication of effort is a major problem there. It's understandable to wonder about though!

Check this post, I made optional addon PK3 for the MIDI packs and Romero's levels: https://itch.io/post/4237949 These are offered without any support; if something goes wrong someone else here can probably help you figure it out. I don't want to make these part of Wadsmoosh itself because they work fine as PK3s and doing otherwise would create the need for configuration and customization. The files are hosted on my non-HTTPS website, but they're just ZIPs with data in them. If your browser complains then use Firefox and tell it to "download anyway". Feel free to mirror them here or wherever.

If you want to keep tabs on the very latest work done, see this view of the different branches in github: https://github.com/luciusDXL/TheForceEngine/branches Last commit was a couple weeks ago. Also worth noting that some work might be going on in non-public branches or depots. This is really normal with spare time open source projects, people get pulled away by real life stuff, energy for the project wanes and waxes, etc. I say let folks take a break when they need to. Lucius made incredible progress over the last year, I'm happy to wait.

For folks following this project, it does look like great progress has been made since the last update, in this branch of the project's git repo: https://github.com/luciusDXL/TheForceEngine/commits/release Basically lots of game sim being implemented, as Lucius described in the last update: https://theforceengine.github.io/2021/04/12/GameLoop.html

Thanks for the explanation Lucius! I'm familiar with that style of gradually filling in a disassembly. Your commenting style is very good and makes it very easy to understand what's going on in that excerpt, I strive for that with my own work. Looking forward to playing the results, keep up the great work.

Very cool! For possible future project news posts, I'm curious to know what your process for reverse engineering is. Do you use a disassembler, monitor the running game in DOSBox, something else, or a mix of techniques? I've never done this kind of programming before and it's where lots of "reimplement old game" open source projects seem to hit a hard wall after getting the formats figured out and the world rendering.