itch.io

Sorry, it's definitely never happening, there's no way I will buy an ARM Mac just to do builds for it, and Apple has made very sure that that's the cost for entry. I recommend running Playscii from source (installing Python, etc).

Did you have a particular one in mind? I've never done it before but would be willing to learn if it wasn't a lot of work and made the program easier to get for people who'd appreciate it.

Correct, I'm no longer active on Twitter. Thanks for pointing out that link in the docs, I'll amend that part to no longer mention twitter. Development has been very dormant for the past few years, but any announcements or updates will be posted on https://cohost.org/playscii

You want "Disable Clean Menu Scaling" from the Miscellaneous section of the options menu, or "m_cleanscale" at the console.

Thank you! Gosh, this mod is written entirely in ZScript and I'm not sure a version of it for Boom derived ports would even be possible. If I ever figure it out I'll let you know here.

Wild guess, but is your desktop using X11 or Wayland? PyOpenGL is pretty ancient and creaky at this point, and I recall Wayland making it trickier in various ways for it to get a context it considered valid.

If you are indeed running Wayland, I'd say try to run from the latest Playscii source (last public commit was August 2022) as I did add a few things after 9.17.1 for working on newer Linux desktops.

Depending on what type of GPU you have, there's a billion reasons the GL context creation could be failing. Does the log print anything before it hits that error? My code tries to output what it's doing as it goes but IIRC that's pretty early in the process.

Hm, if you have all the dependencies installed, see if you can run "import sdl2" from the python REPL environment (ie run python3 from the command line). Do you get the same error from there?

By "having no luck" do you mean it doesn't launch? If not, what errors do you see in the log? I haven't tried running LZDoom in a long time but theoretically the WadSmoosh IPK3 doesn't use any features that LZ doesn't have...

Linux (Arch) compat report, if you care: worked fine on my system when I commented out the two lines that call tk.Tk().iconbitmap('icon.png') - not sure why that fails.

Are your Master Levels WADs modified in any way? Looks like it's expecting to find a sky texture in one of them (one of multiple similar starfields) but it's not finding it. I don't know of any alternate official versions of these (plenty of bootleg versions where people tried to merge all 20 into a single PWAD, but that's obviously unsupported.)

Which OS are you running wadsmoo.sh from?

Okay, that's your problem right there - doom2.wad only has Doom 2 levels in it, naturally; this mod is intended only for a setup where you have all the different sets of levels that WadSmoosh supports and are using the file it generates - doom_complete.pk3 - as your IWAD (base resource file) instead of doom2.wad.

Requires a "doom_complete.pk3" file created with WadSmoosh and assumes you have ALL of the following: Ultimate Doom, Sigil, Sigil II, Doom 2, No Rest For The Living, The Master Levels, TNT: Evilution and The Plutonia Experiment.

Are you running the Full Run mod with this, or vanilla doom2.wad?

I didn't mention the Unity widescreen WADs because those assets are now included as part of GZDoom.

Wadsmoosh seems to be patching the yellow key in on its own.  .... Maybe JP can confirm this is a feature of Wadsmoosh?

No, this is part of the compatibility fixes that GZDoom automatically applies on its own: https://github.com/ZDoom/gzdoom/blob/master/wadsrc/static/zscript/level_compatib...

Also, there are 2 supplemental wadsmoosh specific wads which add community midi packs for episodes without  unique music, and Romeo's alternate episode 1 levels (e1m4b and e1m8b) such that they load sequentially after their original counterparts.

These aren't supported and aren't part of WadSmoosh, I made those purely as addon WADs.

Oh right, sorry I'd forgotten about those. Updated the section in the readme in the depot to mention them.

See the "supported WADs" section of the readme that's included with the download:

https://heptapod.host/jp-lebreton/wadsmoosh/-/blob/branch/default/README.md

It's now part of the progression:

https://jp.itch.io/doom-fullrun/devlog/658269/updated-sigil-ii-now-included-in-p...

Thanks, not sure how long this was broken but it's fixed now: https://jp.itch.io/wadsmoosh/devlog/658262/wadsmoosh-141

What do you mean by "being flagged"? My understanding is that permission issues aren't a result of some "malicious software" detection heuristic, just a set of rules that applications have to follow to be able to do things like access different parts of the file system. Not knowing anything about how those rules might have changed for Win11, I could be wrong but that's my guess as to why you can't get a file listing for certain directories on your system from within Playscii.

Hm, looking at the source code it looks like the save dialog defaults to the user Documents/Playscii/ folder, but will change to whatever directory you last successfully saved something to, within the same session. Not the same as being able to set something that's persistent across sessions, but maybe that help? I'd have to think carefully about how to let users override some of the default paths it uses.

This is almost certainly a permissions issue, eg which directories an application is allowed to access. I don't have a Windows 11 system to test on, but I wouldn't be surprised if they changed a bunch of stuff in the name of security.

Do you know of any other 3rd party applications, particularly open source ones with public bug trackers, that have had this kind of issue? If so I could refer to what they did and maybe that'd help us fix this issue.

https://doomwiki.org/wiki/Skill_level#Doom_and_Doom_II_skill_levels :

The 2019 re-release introduced a new skill between Ultra-Violence and Nightmare!, entitled Ultra-Violence+. It behaves as UV with fast monsters but also enables the spawning of multiplayer-only map things in single player mode.

That depends on so many things (WADs you have, and which exact versions of those you have) with so many possible combinations that it wouldn't be practical to give a single hash or even a list of hashes.

Are you talking about the animated rock texture on the walls, or something else?

Is "Enable Final Doom Texture Substitutions" switched on in the Wadsmoosh section of the options menu?

Dang, thanks for the heads up on this. Let me know if this new build doesn't fix it for you: https://jp.itch.io/mr-friendly/devlog/632301/build-74-a-fix-for-the-major-text-b...

Romero said that that level will eventually be part of another project, so I intend to wait and see what becomes of that.

I know you're asking for Windows compat feedback here specifically but I just wanted to report that this EXE runs fine on Wine on my Linux system. Hooray!

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.