Hmm, I'm not sure what to make of that error. So this crash occurs as you're launching the program? It looks like you're meeting the minimum required version #s for OpenGL and GLSL support. The only thing odd from that log output is your "detected screen resolution" of 128x128 and window size of 102x102 - Playscii tries to enforce a minimum window size of 320x240, as various things get weird below that. I'm not sure that that's the cause of this crash though. Without a ChromeOS device handy I'm really not sure how to go about troubleshooting it. I searched for ChromeOS (and Chrome, and "virgl") on the PyOpenGL mailing list to see if anyone had ever confirmed it even ran on that system, and didn't find anything... but PyOpenGL is also an old and very quiet project at this point.

Sorry I can't do more to help! If you're an experienced Python programmer you might try running some of the PySDL2 (the library that creates the window, handles input, and does other stuff) and PyOpenGL (the library that issues commands to the OpenGL context) examples (or write your own if they don't exist), just to see if those respective modules can even run on your hardware.

I've never used ChromeOS and can't offer any support for it. That error message suggests that Playscii failed to create an OpenGL draw context, which is the most basic initialization step after the window itself is created. I don't have a clear understanding of what the OpenGL/driver environment is like in ChromeOS and thus don't know why it would fail. If you're running "python playscii.py" from a terminal (which would be the correct way to run from source), are you seeing any logged lines prior to that error? Playscii logs every step of its initialization and it would be good to know how what it reports up to that point.

Ah I'd forgotten, I misspoke in my previous comment: adding the secret exits to E1M1 and MAP02 for the Xbox levels, if WadSmoosh detects  SEWERS.WAD and BETRAY.WAD, are the only two times level data is modified.

GZDoom's built in map patching functionality correctly handles all versions of it, and WadSmoosh doesn't change the contents (thus the checksums, which is what GZDoom uses to detect map versions) of any of the map files it extracts.  Nothing needs to be patched or altered by the user.

Search the main comments page here for E1M4 and you should find an addon (PK3) I made that adds these two to the map sequence. PK3s are just ZIP files so if you want a variation on that sequence you can just open it up and edit the mapinfo files in any text editor.

I've thought about this a lot over the years since it's such an obviously slow process, would lend itself extremely well to a multi-core and/or GPU accelerated approach, but it's never quite been clear how I'd pull it off - I'm not a particularly knowledgeable or powerful programmer in the directions that would make it easy to try those approaches. I'll let you know if I ever figure anything out.

Some of my old notes about it are on the playscii trello board, which I haven't touched in some time:

https://trello.com/b/BLQBXn5H/playscii

Those aren't official (or effectively-official, like Romero's maps) releases, so no. But if you look at the data inside the doom_complete.pk3 you could add support for those as new episodes without much difficulty - you could copy the mapinfo\doom2_levels.txt and have a decent template for a doom2-shaped episode, and only need to change a few things such as level names and music tracks.

This is just a hacky solution (and running WadSmoosh again will blow away these changes), but if you open the doom_complete.pk3 file in an archive editor (winzip, whatever) and go to the file mapinfo\masterlevels.txt, and delete every line that says "ResetHealth" and "ResetInventory", you will progress from level to level as you do in vanilla Doom 2 etc.

The maps are not balanced for this; you'll have a much easier time, but it's totally up to you how to enjoy them!

I don't really know anything about Wolf3D modding, but that's a cool idea - maybe someone knowledgeable in the Wolf3D community would be interested in it? I know ECWolf is one of the leading source ports these days: http://maniacsvault.net/ecwolf/

No. Maximum Doom is 3461 levels, some of which are duplicates, some of which don't work, some of which are actually Heretic levels, etc. It's all freely available from other sources anyway (WadSmoosh is for compiling retail content) and even if it weren't there's no reasonable way to integrate such a big mess.

What is the correct level order you're citing? I arrived at the level order in the mod by emailing back and forth with Sverre Kvernmo, and this was the sequence he felt best presented his work.

No; GZDoom doesn't support the PSX ports.

Has this always happened? What OS are you running?

"binds.cfg" in your config dir is where the key bindings are defined, you could have a look at that file and see if anything looks out of the ordinary. i think the behavior of the mouse buttons might be hardcoded though.

What's the full output text when you try to run? Are you running from the command line? Which OS are you running from?

Hi, thanks for putting this together and apologies for being out of touch. Yes, I'll make sure this is in the next release, whenever I can get it together.

I've avoided modifying any actual original map data at all costs, preferring instead to use GZDoom's runtime compatibility patching system to fix up anything. In that vein, I'd say you could simply edit the MAPINFO in the E1M8b addon, add the "ResetHealth" keyword to the E1M8b block of that data and you'll start that map with 100 health instead of whatever you ended E1M8 with.

I mean, I drag/drop doom.wad, doom2.wad, tnt.wad, plutonia.wad, chex3.wad, freedoom1.wad, freedoom2.wad, hacx.wad, heretic.wad, hexen.wad, hexdd.wad, and strife1.wad onto the GZDoom exe without issue

The reason those work is because those are all vanilla Doom data and don't redefine any of GZDoom's cvars (console / user config values). The error you're getting is GZDoom saying that you're trying to define the same cvar twice, which you'd definitely get if you're loading doom_complete.pk3 as both an IWAD (as defined in your gzdoom.ini, which gets set when you pick an IWAD from the pre-launch window) and as a PWAD (by dragging it onto the EXE, which GZDoom always interprets as "load this WAD as an addon").

doom_complete.pk3 is an IWAD (an IPK3, functionally the same thing - a primary resource file, same as DOOM2.WAD) so you don't drag it onto GZDoom.exe like you would an addon wad (PWAD). When GZDoom pops up with a window asking which IWAD to use, select doom_complete.pk3 - that is now your running IWAD, and you can access all the episodes etc. The reason GZDoom gave you that script error is because you were effectively loading doom_complete.pk3 twice.

Are you launching GZDoom from the command line or by clicking a shortcut? Which IWAD/IPK3 are you using? What other files are you loading? Anything in your INI autoload list?

I definitely don't have any time or energy for doing any Playscii support right now, but here's the code that does the image conversion:

https://heptapod.host/jp-lebreton/playscii/-/blob/branch/default/image_convert.p...

Oh hey, it looks like you can't read:

As Playscii's sole author, I have multiple objections to the creation and selling of Non-Fungible Token (NFT) art and do not approve of said use. Legally I cannot stop you but I offer absolutely no support to such users, and I am not interested in engaging with them on this subject. See this section of the project's web page for more information on this.

You will get zero further support from me.

I'd like to see if I can reproduce this on my system. If you feel comfortable sending me the source file(s) you're trying to convert, email me at the address on this page: http://vectorpoem.com/contact.html

I thought pressing the use key or fire button would always reload your last save/autosave in GZdoom, is that not happening here? I tried opening the map that way and dying just now and that's what it did... also tested walking through the final portal and "dying" to trigger the E1 finale text, that worked fine too.

Try "map e1m4b" at the console (pull it down with the tilde ` key).

Attack.wad is just the file it checks for to see if the Master Levels are present at all, it logs that rather than logging all 20. What does the rest of the log say? Any errors?

1. This question falls under the "why don't you add WadSmoosh support for [random free mod that you can just download and load in like any other mod]?" section of the WadSmoosh FAQ - because WadSmoosh is for packaging up retail content only.

2. The point of Master Levels Menu Interface is that you can jump into any level at random. The point of this mod is that the levels have been placed into a deliberate sequence that establishes them in the context of their authors' other work. These ideas are incompatible.

Mac has become increasingly hard to support given their ongoing efforts to lock down their platform. First question, are you running on one of the new M1/M2 Macs? The build on itch here will definitely not run on those.

Ahh, okay so it appears that you have "python2" and "python3" executables on your system but it doesn't alias either to "python" the way that pretty much any distro would do. In that case it's probably simple: type "python3 wadsmoosh.py", or edit wadsmoosh.sh to use python3 instead of just python.

Try typing just this at the terminal:

python

and see what appears next. If that actually launches the Python interpreter, quit out of it and type

which python

If that returns a path (eg /usr/bin/python) then try running

python wadsmoosh.py

from the directory where you have WadSmoosh.

Let me know what each of those commands result in. Like I said I don't know anything about ChromeOS specifically but if you're able to get a reasonably normal Linux environment, running programs in python should be straightforward.

WadSmoosh is written in Python so if you're running it "from source" (which is what that shell script does) you'll need Python installed on the system. I've never used ChromeOS before but it looks like it doesn't include Python out of the box.

I can't reproduce this on my Arch-based system. That warning at the end there shouldn't have anything to do with file saving or exporting, but I did fix it recently, as well as changing how the desktop resolution is detected on Linux so that it doesn't launch (since a recent SDL2 update, maybe?) as a tiny 128x128 window in this commit a few days ago: https://heptapod.host/jp-lebreton/playscii/-/commit/a1e0fae59d0a8c06d045709da109...

If you're running from source you should be able to download the version of playscii.py there on the code repo and just replace your local file with it. But like I said, I'm guessing those fixes are unrelated to the problem you're seeing.

Two questions that might be relevant:

1. Does your home directory have a Documents/ folder?
2. What distro are you running?
   

Okay, so it's a level from the expansion. Do you know the name of the level or area? That would help me narrow down where to look for it.

The doom_complete.pk3 file WadSmoosh generates has an IWADINFO lump in it, that is what makes GZDoom treat it as an IWAD. There is zero byte-level difference between a version of the file WadSmoosh outputs with a .PK3 extension and an .IPK3 extension. Rename the file if you'd like it to have that extension.

That is the project's source code repository - it's hosted using the Mercurial version control system. If you just want to use WadSmoosh, you should download it from here on itch.io. Even if you're just looking to modify the code for your own purposes, the code is included with the itch download. The only reason you'd want to access the mercurial repo is if you want to create your own fork of the code.

Your web browser might be refusing to download the ZIP files because my website doesn't use HTTPS. There is no executable code in the ZIPs I link there so the security risk is overstated - you can tell your browser to make an exception just this one time.

Those are the medkit etc sprites from the "BFG Edition". If you want the original red cross medkits, use the original (pre-BFG Edition) WADs. If you want the newer green cross ones, use the WADs from the Unity ports. The files are otherwise the same, they just made those changes for legal reasons (IIRC the International Red Cross organization is strict about people using their symbol)

The supported WADs are mentioned everywhere, including the readme: https://heptapod.host/jp-lebreton/wadsmoosh

Is there a particular file of yours it's not recognizing?

The only difference between a PK3 and an IPK3 I'm aware of is the file extension, so try just renaming the file.

I'm not sure what specific MIDI packs you mean, but further down in this thread I did put together an unofficial, unsupported version of a few of them (for the things WadSmoosh already supports; I don't plan to add any more or do any further work in this direction): https://itch.io/post/4237949

I can confirm this on my system, and in fact all Doom 2 sprites (monsters, archvile fire, super shotgun pickup etc) are invisible. I am baffled as to what would have changed in GZDoom 4.6 to have caused this. I'll investigate.