Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

JP LeBreton

275
Posts
2
Topics
1,451
Followers
43
Following
A member registered Nov 30, 2013 · View creator page →

Creator of

Recent community posts

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.

(1 edit)

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.

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