I never tested it with MP, so try it I guess. But a quick look at the code suggests that it might not, while the timer is global it might be assuming the first player in a session might be the only one who gets affected by the timeout kill. If so, I don't have any plans to support multiplayer.
JP LeBreton
Creator of
Recent community posts
Okay, just tried recompiling ZMusic (GZDoom dependency) and it fixed the crash - I'm guessing that this was the fix that went in just today: https://github.com/ZDoom/ZMusic/commit/f6facdaa683e7159b7569d5287a088da352a7c92
So hopefully a GZDoom minor version update will release soon that fixes this for everyone. And if you're compiling your own, you can get it right away.
I can reproduce this on my Linux desktop with all the IT, S3M, PSM, and MOD files - basically all the tracker formats. I'm not sure what GZDoom changed to break these - I'm guessing it's not intentional, because tons of mods use tracker music and they are probably now also broken. I'll see what I can find out, thanks for the bug report.
Which OS are you running GZDoom 4.14.0 from?
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
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.
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.)
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.
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.
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.
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...
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.
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: