Heretic: mace spawning spots limit handling

[JNechaevsky]

Dear @fabiangreffrath, @kraflab, @rfomin, @kitchen-ace, @NightFright2k19, and anyone who interested.

I'm suggesting a small discussion regarding Heretic's vanilla mace spawning spot limit. The problem is - it's a play state, not a rendering limit, and must be handled carefully.

Situation: if map have 8 or more mace spawning spots, the game will bomb out with "Too many mace spots" error message. The only known map with this limit is, presumably, is The Realm of Parthoris E1M8, but just in case providing proper limit-removing, probably it is worth to handle this case?

There are three possible ways:
1. Perform a full limit-removing approach by array doubling. Like this one, nothing extra special. This way mace spots will be working as mod author intended.
2. Do not use extra spawning spots and don't bomb out with error message. This way should preserve vanilla mechanics at some point. Something like this:

void P_AddMaceSpot(mapthing_t * mthing)
{
---    if (MaceSpotCount == MAX_MACE_SPOTS)
+++    if (MaceSpotCount >= MAX_MACE_SPOTS)
    {
---        I_Error("Too many mace spots.");
+++        return; 
    }

3. Do nothing. I.e. leave possible bombing out, despite of limit-removing declaration.

Please note than neither 1st, nor 2nd approach will fix demo handling, as vanilla heretic.exe still will be bombing out on such maps. Guarding mace spot counter with "single player only" condition is even worse, imagine The Realm of Parthoris was practices w/o demo recording, and when recording is on, player will reach E1M8 and puff! "No more mace spots, have a nice day".

[kitchen-ace]

I'm playing around with some things before I really form an opinion. For the meantime I wanted to say that there's a similar limit on the number of D'Sparil teleport locations, and that whatever fix is applied to Mace spots should probably also apply to that.

There are two maps in HUMP that have >8 mace spots, and one that has >8 boss teleports ("Too many boss spots"). I don't remember offhand if these maps are otherwise playable but I think they are. Though this wad officially targets ZDoom, several of the maps work in limit-removing ports.

[kitchen-ace]

So IMO the best thing to do would be if all currently-maintained ports that play demos could support more than 8 mace spots and D'Sparil spots in a demo-compatible way. I think this is much more preferable to just bombing out, and it's very hard to come up with another port-based solution that doesn't have problems or compromises, as @JNechaevsky pointed out.

It would be nice to have some indication that this isn't truly vanilla-compatible behaviour, for mappers that want to take advantage of it; it would be better still if new mapsets just didn't have more than 8 spots (it really doesn't add much to a map anyhow IMO) but I'm not sure how to reconcile that with supporting the few already-existing maps that have more than 8 spots.

This means there's another option though: fix the few maps that exist that have more than 8 spots, and encourage new mappers to make sure their maps are compatible with this limit. In 2015 when Realm of Parthoris was released, there were very few options for limit-removing Heretic ports; now with Crispy Heretic, International Heretic, DSDA-Doom's Heretic support, and Eternity getting full Heretic support sometime(??), there are a lot more ways to test a map for cross-compatibility.

AFAIK the only maps that have more than 8 mace or D'Sparil spots but are otherwise limit-removing are 1 in Realm of Parthoris, and a few in HUMP (which is officially a ZDoom-specific wad anyhow even though much of it works in limit-removing Heretic ports).

I'm also going to ping @ETTiNGRiNDER to join this discussion, since he is very knowledgeable about Heretic maps, and might have an opinion or know of more maps with these problems.

[ETTiNGRiNDER]

I should preface this with saying I don't use Crispy so I'm not super familiar with the particular goals/culture of the project, but since my input was specifically requested, I'll put in what I can. Going any deeper than this would require me to dig out map editors and a bunch of ports for comparisons which isn't convenient at the moment.

As far as the OP options given, 1 is valid if you're going for "truly limit removing", 3 is valid if you're going for "be accurate". I strongly dislike option 2, it smacks of introducing an arbitrarily weird behavior to sneakily pretend there's not a problem in similar ways to the ZDoom decision to treat 0-tagged actions as valid (though admittedly with probably far less widely disastrous results). As soon as you have a schism between ports that treat all mace spots as valid and those that just ignore some of them in accordance with an arbitrary vanilla limit without actually flagging it as a problem, you're going to get an inconsistency in how the map works that's IMO worse than having an error that explicitly tells the author "go fix this".

As far as encountering this type of issue "in the wild":

Excessive mace spots in vanilla maps are unambiguous: it's treated as a fatal error, full stop, and will not even let you play the map. As a result, I don't think there's a single vanilla map on the archives that has this problem; it's not like visplanes or the like where a map can seem playable and only collapse midway through playing and therefore sneak through testing. I haven't played completely through every map in the vanilla section of idgames but I've probably at least loaded all of them except some odds and ends in the deathmatch directories and later maps in multi-map WADs I disliked and didn't yet manage to slog through. I don't think I've ever seen the mace spawn error or related ones in any of them.

As far as maps which are under the "limit removing" moniker, I definitely haven't tried all of them as I haven't kept up with newer releases that often, but I already find this to be a bit of a problematic term when it comes to Heretic map sets. My usual response to a Heretic WAD that's marked as "limit removing" with no other qualifiers is to try Heretic-Plus first. This definitely doesn't always work and there should always be a reminder that Plus is "limits raised" and not true limit-removing, but it also shows up how many "limit removing" WADs are actually ZDoom-lite WADs. To the best of my knowledge Plus does nothing to address mace/D'Sparil spot limits.
When it comes to "limit removing" Heretic maps we have more or less three eras:

• The wHeretic era. To the best of my knowledge, every extant WAD that specifically cites wHeretic as a requirement is straight limit-removing and will work on Plus with, at most, possibly needing to fix the wad with DeuSF for sprite/flat errors first. I think I've tried all of these. I have no idea if wHeretic did anything about the spawn limits and it's become an obscure/bitrotted port these days, but I've never seen it be a problem.
• The era where "limit removing" for Heretic essentially meant "for ZDoom, but doesn't use stuff like DECORATE, ACS, etc. (may still be 'impure' in ways that make ZDoom a recommendation/requirement because no one tested anything else and there was precious little else worth doing such testing on)" I don't have a comprehensive list at the moment but excess mace spots / D'Sparil teleports are just the tip of the iceberg for ZDoomisms in this era of maps. Tutti-frutti errors, tag 0 shenanigans, you name it. Occasionally something from this era might be vetted against jHeretic/Doomsday in addition to ZDoom and those are more likely to be "pure" limit removing but I think Doomsday also ignores some potential errors like TFE. Probably most of your problem maps are coming from this batch.
• Nowadays when there's actually more of an option for ports and we have compatibility issues like this. I know very little about what the new batch of ports is like TBH, I've yet to find a reason to really bother that much when "use (G)ZDoom" remains the most correct answer to just about any WAD that doesn't play nice with vanilla or Plus for the reasons stated above.

In light of all the above, I can think of another option: treat excessive mace spawns / D'Sparil landings / etc. the way some ports treat improper tag 0 triggers and the like: have a compatibility flag that says "act like ZDoom for this" and otherwise treat it as invalid. If you don't want to ever treat it as invalid mapping, then maybe "do whatever ZDoom is doing with them" is the correct general answer for as much as that might sound like a poison pill to swallow.

Since it hasn't been mentioned yet, a final addition is that I'm pretty sure there's a "too many ambient sounds" error in this class as well, but I can't remember if I've ever seen it "in the wild" or just in my own mapmaking.

Hope it helps.

[kitchen-ace]

Thanks for the comments @ETTiNGRiNDER . The wad in question that sparked this discussion indeed comes from the limit-removing-for-ZDoom era.

I personally would very much support a compatibility option/flag for this kind of problem, except for the fact that if it's encountered the engine quits immediately. With tag 0 triggers and the like you usually have the chance to turn the compatibility option on mid-level, or even just noclip through the non-functioning parts.

I'm pretty sure there's a "too many ambient sounds" error in this class as well

Actually it seems like this was already fixed in Crispy: #847
I wonder if this suggestion was made to fix a certain map, or was just intended as a good idea?

[NightFright2k19]

I guess Julia brought it up since I recently encountered the issue while doing some Inter-Heretic playtesting with various pwads, "The Realm of Parthoris" being among them.

My personal opinion, if it's worth anything, is that the term "limit-removing" should be taken literally. However, if it's really just for one map... dunno. Since this is already an older project, it's desirable to make it functional, especially considering it's only that one problem which blocks you from running TROP outside of ZDoom otherwise.

If someone wants to map for vanilla, they will test with Chocolate Heretic and realize if they overdid it. Otherwise, Crispy and derivates should be able to handle everything "vanilla-like" which won't explicitly require Boom, UDMF, Eternity, ZDoom or some other advanced features.

One way or the other: Julia fixed it in Inter, so whatever you guys decide, there WILL be at least one limit-removing port besides ZDoom out there able to run TROP. :)