Johnny Law, thanks for playing and taking the time to post your thoughts! I can't really argue with any of your comments, but glad that you seem to mostly have enjoyed the experience. 

Oh for sure. Threads like these are a useful place to surface critical feedback, but that doesn't mean that any of the nitpicks ruined the experience for me. It's a super-fun map set. 

Ubiquitous, I noticed that some of the commenters on Quaddicted reported that the engine crashes when they try to save on the second or third map. I can confirm the same issue affects the start map, too. The reason this happens is that the "wad" strings in those bsp files are very long. (You likely know what the "wad" string is, but for any reader who doesn't: it's a semicolon-separated list of the paths of the wad files that the compiler is supposed to use when compiling the map.)

There's a historical bug/limitation in the engine whereby the value of an entity key gets copied into a fixed-sized buffer, so if the value contains too many characters, it'll overflow. The "wad" string is stored as a key of the worldspawn entity, which is why this is relevant.

Based on previous reports about other maps, it seems that whether or not this causes a crash is platform-dependent, even when using e.g. QuakeSpasm on different platforms. I haven't looked into the issue enough to be able to tell you why that is.

It's been a long time since I've properly looked at the code in the engine that's relevant to this, but from casting my eyes over it briefly, it looks like the original character limit was 255 characters. In QuakeSpasm 0.93.1 this appears to be bumped to 511 characters.

The v1.3 e1ubi maps have the following character counts for the "wad" strings:

- start: 566
- e1m1ubi: 500
- e1m2ubi: 714
- e1m3ubi: 717

So that seems to explain why e1m1ubi doesn't crash QuakeSpasm but the other three do (or at least, can).

I can think of a couple of ways that the "wad" strings might be made shorter to work around this problem:

1. Relative paths could be used for the wad files instead of absolute paths. Ubiquitous, I noticed from the readme that you're using TrenchBroom: you should be able to choose relative vs. absolute paths at the time you add a wad file.

2. Alternatively, you could make the string shorter by not using multiple wad files. If you're comfortable using command-line tools, ericw's tools include one called bsputil. You could do e.g. "bsputil --extract-textures e1m2ubi.bsp", which will create a new wad file, "e1m2ubi.wad", which contains only the textures used in the map. You could then change the map file to use only that one wad file.

(As a third alternative: it should be possible to strip the "wad" string out of the finished bsp file, however that feels hacky, and if you recompile again, you'd have to remember to do it again.)

If you've any intention of fixing this and releasing an update, there's another bug I noticed in e1m3ubi which I thought you might want to fix: one of the "bottomless pits" in the dungeon doesn't have a trigger_hurt at the bottom of it. It's in the first room of the dungeon, the one with the cells on both walls. 

P.S. looking at the "wad" strings in those files: I'm not sure that changing them to relative paths would necessarily help, because I'm not sure where the wad files are in relation to the directory where your compiler gets run. So, possibly option 2 would be more useful? 

Thanks! I would otherwise have had no idea how to fix it. I am away right now, but will look at fixing this when I get back. Your option 2 shouldn't be a problem for me. 

Using the suggestion of iw, I have produced a new version (1.4) that should hopefully fix the save bug. It can be obtained from Quaketastic here:

http://www.quaketastic.com/files/single_player/maps/e1ubi_plantegenets_v1_4.zip 

Can confirm that with the latest version, it's possible to save in all maps without crashing QuakeSpasm. And the entity keys are short enough that they should be fine for all engines. Good job!

I've recently been working on some bugfixes for progs_dump, and I've been using these maps as additional playtesting material to check that I haven't broken anything (obviously the third map uses some custom features, but the first two maps seem to use only the stock pd features?). So I've played through them a bunch of times, now.

I feel like my original post in this thread was too negative, or at least, not positive enough. There's a lot to like in these maps. I very much like that they have a distinct personality about them, especially with the environmental details that one doesn't usually see in a Quake map (the paintings, rugs, upholstered furniture, etc.). And, the interesting details don't stop the gameplay being authentically Quakey.

My favorite bit of visual design is in the second map, where there's the cosy seating area with chairs and a table and a bookcase on a balcony that's teetering over an abyss. That's a wonderfully surreal scene.

Here's a question that occured to me while replaying: modern Quake engines allow the use of external true color textures as opposed to paletted textures; did you consider using this for the paintings? I wonder how it would have looked? 

Thanks, iw, for the kind comments. The fix for the save error was particularly useful because now I can easily incorporate the same fix into any future release.

Surreal is exactly the vibe I had in mind with the scene you described. The reason I put a bit of extra detail, e.g., into the wing chairs is because I knew the detail there was important to sell the atmosphere.

To be honest, it never crossed my mind to use 32 bit textures. I've developed a pretty routine workflow for processing textures into the quake palette using a combination of Photoshop and TexMex. I guess my worry would be that the high depth textures would look a bit out of place in an otherwise 8 but world. But for textures that stray far from the default quake palette, it might indeed be the best approach. 

Yes, whether things would look too out-of-place would be my concern, as well. I think that, as with any modern Q1 extension, use of 32-bit textures would need to be judicious.

There's some evidence that suggests to me that 32-bit textures are acceptable in some contexts:

* Players don't seem to complain about all of the maps that use 32-bit skyboxes, and many maps rely on those colourful skyboxes for visual effect. On the other hand, the skybox isn't part of the level geometry, so maybe that's why it doesn't bother people?

* One map which has always stuck in my mind for using external textures well is Necros' ne_marb. It uses external textures to transplant Doom's green marble textures into Quake. It's been a long time since I've played it, but my recollection is that the difference between playing with the external textures or without was striking. (N.b. this was one of the first Quoth maps, and IIRC the external textures were included with Quoth itself, not in ne_marb.zip).

But, neither of these are exactly the same case as the artworks in these maps. So, I don't have much of a point, just thinking out loud! 

https://www.twitch.tv/ionous