What Does Limit-Removing Actually mean?

[Arsinikk]

What Does Limit-Removing Actually mean?

This may seem like a simple question, but in this post I'll elaborate that it really isn't, in fact.

 

 

Doom Complevels

As most of the Doom community knows, classic WADs are designed to be compatibile with specifical complevels.

 

Here are some of the most notable ones:

• Complevel 2 - Vanilla Doom and Doom 2
• Complevel 3 - Ultimate Doom
• Complevel 4 - Final Doom (Plutonia, TNT)
• Complevel 9 - Boom
• Complevel 11 - MBF
• Complevel 21 - MBF21

 

For the sake of simplicity, complevels 2-4 are pretty close to the same, with some minor differences (complevel 4 having teleport to ceiling, etc.).

 

The differences between Vanilla (cl 2-4) and Boom are quite big, besides the addition of extra line actions and dehacked codepointers. Not only does Boom remove most, if not all, mapping limitations that Vanilla had, it also changes how physics work in Doom (ex: monsters getting stuck on ledges, etc.).

 

 

What is Limit-Removing?

And so here comes limit-removing as an extra complevel...? Or well not really. As far as speedrunners are concerned, they still record demos for these maps in complevel 2.

Let's lay down what limit-removing is.

 

The idea seems to have surfaced as a way for mapping for Vanilla, but without the restrictions that Vanilla mapping entails. That means that there is no HOMing when there are more than 256 lines on screen, no Visplane Overflows, with many of the other static Vanilla limitations mappers would have to work with complevel 2.

 

According to the Doomwiki page, Limit-removing should remove all limits that were present for Vanilla mapping.

 

 

Limit-Removing Example

Here's where things get muddied for me. What static limits are removed for a map to be considered limit-removing?

I was working on a map for a community project that was limit-removing, and the maps were being tested in Crispy Doom. In my mind, limit-removing would mean that all static limitations and complevel bugs would be removed. The project leader said that while it was limit removing, they encountered an Intercepts Overflow or "all-ghosts" bug in my map and it had to be tweaked.

 

My question would be doesn't limit-removing mean that Intercepts Overflow would be fixed. Does that mean that Spechits Overflow is also not fixed in limit-removing?

 

 

Limit-Removing Confusion

I haven't even touched on some of the added features that some limit-removing projects use such as sky transfers and musinfo lumps.

 

As far as speedrunning goes, limit-removing maps much be run in complevel 2, right? Should some of those Vanilla bugs be ignored for runs?

 

It seems really hard to say because it doesn't seem like there's a fully defined definition of what limit-removing actually means.

 

Another minor question would be, would you consider Crispy Doom a limit-removing port? Because I'll tell you that right now there's no option to turn off intercepts or spechits overflows.

 

And I know someone's gonna say it, but the answer isn't to just use Boom instead. Boom changes how some of original Doom actions and physics work. There's a reason why some mappers like working with complevel 2 over complevel 9.

[Maribo]

5 minutes ago, Arsinikk said:

As far as speedrunning goes, limit-removing maps much be run in complevel 2, right? Should some of those Vanilla bugs be ignored for runs?

Generally, when the term is used properly, then yes, cl2/3/4 for the relevant IWADs. For the purposes of running, a "limit-removing" set is assumed to mean that it only uses vanilla actions and doesn't have any other indicators that it's meant to be run in Boom or higher, of which the most common reason would be excessive lost souls/pain elementals (Deus Vult is a good example). For DSDA submissions, it is entirely allowed to disable overflow emulation, the run will just be given a note stating that it must be watched back with the emulation disabled.

[OpenRift]

I think when it comes to the term "limit-removing" it mostly refers to removing vanilla limits that have an effect on mapping scope (visplanes, dragsegs, etc.). Anything that would have an effect on gameplay or demo playback (like the all-ghosts effect) would still be retained from vanilla. 

 

Quote

Another minor question would be, would you consider Crispy Doom a limit-removing port? Because I'll tell you that right now there's no option to turn off intercepts or spechits overflows.

That's because Crispy Doom is a limit-removing source port, and nothing more. It doesn't have any complevels to set or anything of the sort because it only supports vanilla format WADs, just with extended mapping limits. 

[Arsinikk]

15 minutes ago, Maribo said:

For DSDA submissions, it is entirely allowed to disable overflow emulation, the run will just be given a note stating that it must be watched back with the emulation disabled.

I would assume this includes Spechits Overflow as well? Not sure what it does, only that it supposedly breaks Vanilla demo recording.

 

5 minutes ago, OpenRift said:

I think when it comes to the term "limit-removing" it mostly refers to removing vanilla limits that have an effect on mapping scope (visplanes, dragsegs, etc.). Anything that would have an effect on gameplay or demo playback (like the all-ghosts effect) would still be retained from vanilla. 

In my opinion, this makes no sense to me that you'd separate both VPOs from spechits overflow. Both of them are static Vanilla limits, and to say removing one is ok, while keeping the other is strange to me.

 

I would personally argue that overflow bugs affects my mapping style just as much as VPOs do. Depending on if a definition for limit-removing is made, the outcome would literally determine whether I wanted to make a 30K limit-removing slaughtermap or not. Since Intercepts Overflow would most likely trigger immediately.

 

9 minutes ago, OpenRift said:

That's because Crispy Doom is a limit-removing source port, and nothing more. It doesn't have any complevels to set or anything of the sort because it only supports vanilla format WADs, just with extended mapping limits. 

I really do think that the problem is that the term "limit-removing" doesn't have a proper definition. From my point of view, still having Intercepts Overflow isn't really removing Vanilla limits. What is the point of having a "limit-removing" compatibility with some limits enforced? (disregarding new boom features, since those are added and the absence of them shouldn't be considered "limitations" by definition.)

[BoxY]

Indeed the concept of limit removing is quite poorly defined, afaik for demo submissions to DSDA the rule is basically that spechits emulation should be on for vanilla wad recording, and otherwise it's optional, but I can't recall anyone getting a demo rejected specifically because it desyncs due to spechits in vanilla. In my opinion in an ideal world cl2/3/4 should have been split into 6 complevels with spechits forced on or off to account for vanilla and limit removing wads, but it's too late to redefine existing complevels at this point.

[Doomkid]

This is just how I see it, but “limit removing” wads should meet the following criteria:

-Maps use NO boom features or non-vanilla line/sector actions.

 

-complevel 2 (or 3 or 4) is the intended compatibility.

 

-extras like MAPINFO can be used to “spice up” the experience for advanced ports, IE scrolling skies or longer map names, but if anything about this lump is “required” for the wad to work right, it is no longer limit removing, as many LR ports (and vanilla itself) have no support for such lumps.

 

 

It really always was just meant to be “vanilla format without limits”. A map that surpasses the spechit overflow is still “limit removing” and if the project leader wants “limit raised”, which is similar but not the same - not ALL limits are removed, but are more forgiving than vanilla - it’s on the project leader to make it clear to participants what limits are still in place. (And to be fair to the person leading the project, these terms are obviously not clearly understood..)

 

It’s easiest to just release the map as “limit removing” though even if you’ve only surpassed vanilla limits a little.. The non-mapping masses need not care about this thin/blurred line.

[OpenRift]

9 minutes ago, Arsinikk said:

In my opinion, this makes no sense to me that you'd separate both VPOs from spechits overflow. Both of them are static Vanilla limits, and to say removing one is ok, while keeping the other is strange to me.

  

I would personally argue that overflow bugs affects my mapping style just as much as VPOs do. Depending on if a definition for limit-removing is made, the outcome would literally determine whether I wanted to make a 30K limit-removing slaughtermap or not. Since Intercepts Overflow would most likely trigger immediately.

The reason spechits is maintained is for compatibility reasons. It wouldn't work consistently in Doom's vanilla demo format. All limits that have a direct effect on gameplay should be retained. It doesn't really make much sense to have a separate complevel that just fixes vanilla gameplay bugs.

 

13 minutes ago, Arsinikk said:

I really do think that the problem is that the term "limit-removing" doesn't have a proper definition. From my point of view, still having Intercepts Overflow isn't really removing Vanilla limits. What is the point of having a "limit-removing" compatibility with some limits enforced? (disregarding new boom features, since those are added and the absence of them shouldn't be considered "limitations" by definition.)

Here's the thing. Limit-removing is a term that has varied throughout the years in the Doom community until around the early to mid 2010s. Back in the 2000s could refer to something that was made for Boom or ZDoom. But nowadays it refers to removing the limits that don't affect vanilla demo compatibility.

 

You can argue that it's not truly "limit-removing" if some limits are maintained, but I think it's a better name for compatibility than "some limits removed" or "limit-removing except spechits". It's really just an argument of semantics at that point.

[Arsinikk]

16 minutes ago, BoxY said:

In my opinion in an ideal world cl2/3/4 should have been split into 6 complevels with spechits forced on or off to account for vanilla and limit removing wads, but it's too late to redefine existing complevels at this point.

While I agree it's too late to change complevels, perhaps a new parameter like -lr could be added in addition to specifically disable overflows and such, if an official definition of Limit-Removing was decided upon.

 

4 minutes ago, Doomkid said:

It really always was just meant to be “vanilla format without limits”. A map that surpasses the spechit overflow is still “limit removing” and if the project leader wants “limit raised”, which is similar but not the same - not ALL limits are removed, but are more forgiving than vanilla - it’s on the project leader to make this clear to participants. (Though to be fair, as established, they likely didn’t know the ins and outs themselves of this very specific topic..)

I do see that like you said, there's a bit of confusion on the subject. Tbh I don't see any issue that would affect any existing limit-removing maps to just disable overflows with like an extra -lr parameter. This way you could keep the "limit raised" thing by just loading with complevel 2,3,4. But also make it clearer for the community and speedrunners that a map is limit-removing.

[Doomkid]

I would be all for a parameter that bypasses things like spechit overflows while retaining CL2 compatibility. I honestly thought this was a thing already as many vanilla limits are set as options in DSDA Doom. If spechits isn’t yet one of them and indeed it would be possible, I’d like that.

[Arsinikk]

20 minutes ago, OpenRift said:

The reason spechits is maintained is for compatibility reasons. It wouldn't work consistently in Doom's vanilla demo format. All limits that have a direct effect on gameplay should be retained. It doesn't really make much sense to have a separate complevel that just fixes vanilla gameplay bugs.

The overflow settings in DSDA Doom / PrBoom Plus would disprove this.

 

20 minutes ago, OpenRift said:

Here's the thing. Limit-removing is a term that has varied throughout the years in the Doom community until around the early to mid 2010s. Back in the 2000s could refer to something that was made for Boom or ZDoom. But nowadays it refers to removing the limits that don't affect vanilla demo compatibility.
 

You can argue that it's not truly "limit-removing" if some limits are maintained, but I think it's a better name for compatibility than "some limits removed" or "limit-removing except spechits".

Having an extra -lr would solve this problem. You could just use -complevel 2 to run it the old way.

 

20 minutes ago, OpenRift said:

It's really just an argument of semantics at that point.

This is why I made this post. It caused issues in expectations for both the mapper and project leader in a project I was in. I don't see how having an official definition for limit-removing would cause any issues for old or new projects. In addition it would solidify the confusion that is about the subject.

 

13 minutes ago, Doomkid said:

I would be all for a parameter that bypasses things like spechit overflows while retaining CL2 compatibility. I honestly thought this was a thing already as many vanilla limits are set as options in DSDA Doom. If spechits isn’t yet one of them and indeed it would be possible, I’d like that.

I don't think it's ever been a parameter for ports. It is in the compatibility settings for DSDA Doom / PrBoom Plus, but there's no way to force those settings like when using -complevel 2. They must be manually changed. I see this as a win-win for the community and speedrunners alike.

Edited March 4, 2023 by Arsinikk

[Doomy__Doom]

9 minutes ago, Arsinikk said:

I don't think it's ever been a parameter for ports. It is in the compatibility settings for DSDA Doom / PrBoom Plus, but there's no way to force those settings like when using -complevel 2

In dsda-doom you can since 0.25 use -assign attribute=value (temporary) or -update attribute=value (permanently in cfg) for anything that's in config file.

 

But of course you have to choose to enter these settings, and it's wordy/verbose and you need to look up what they're named in cfg.

Edited March 4, 2023 by Doomy__Doom

[Arsinikk]

6 minutes ago, Doomy__Doom said:

In dsda-doom you can since 0.25 use -assign attribute=value (temporary) or -update attribute=value (permanently in cfg) for anything that's in config file.

While this may be true, those are highly user-unfriendly parameters to use every time I make a limit-removing map, that I want to remove overflows from, especially compared to something like -lr.

 

I hope you don't expect me as a mapper to say that to play my map, users need to use a long list of specific parameters to run my WAD correctly.

 

I'd rather focus not derail this thread on a technical mishap, and instead focus on defining what "Limit-Removing" should mean and perhaps implementing a new parameter for both ease and solidifying the definition of the non-complevel.

Edited March 4, 2023 by Arsinikk

[OpenRift]

11 minutes ago, Arsinikk said:

The overflow settings in DSDA Doom / PrBoom Plus would disprove this.

Those options were added primarily because PrBoom-plus (and by extension DSDA) are designed for comprehensive experimentation. Doesn't really serve as much of a purpose in other ports if you ask me.

 

14 minutes ago, Arsinikk said:

This is why I made this post. It caused issues in expectations for both the mapper and project leader in a project I was in. I don't see how having an official definition for limit-removing would cause any issues for old or new projects. In addition it would solidify the confusion that is about the subject.

I think if it's causing that much of an issue in a project, it sounds like people need to do their research.

 

I'm not saying there's a problem with having an official definition for "limit-removing", I'm just saying that trying to poke holes in the logic behind how most people in modern-day Doom modding use the term is getting stuck on semantics. I think there pretty much is a formal definition for limit-removing nowadays, it's more that there wasn't always one.

[Arsinikk]

2 minutes ago, OpenRift said:

I think if it's causing that much of an issue in a project, it sounds like people need to do their research.

Yes, because there's totally a full in-depth bloody wiki page that explains exactly what limit-removing is. If you think I didn't look in-depth for an explanation for limit-removing before making this post, you are sorely wrong.

 

4 minutes ago, OpenRift said:

I'm not saying there's a problem with having an official definition for "limit-removing", I'm just saying that trying to poke holes in the logic behind how most people in modern-day Doom modding use the term is getting stuck on semantics. I think there pretty much is a formal definition for limit-removing nowadays, it's more that there wasn't always one.

I don't really see it as poking holes. Though it'd be delusional to think that limit-removing as a non-complevel doesn't have a clear definition. As a mapper, knowing exactly what limitations I have to work with is both extremely beneficial for the mapper and player.

 

I don't mean to grill you so much, but why are you adamant about not removing overflows for limit-removing. There aren't any downsides I can see to removing these limits. The only small thing I could think of is if the map specifically exploited the spechits overflow, but that's honestly the exception and not common at all.

 

Is there something you have against clarifying an actual definition for limit-removing. While it is true there is a history with Doom modding and limit-removing, tradition does not always mean things can't be improved or clarified. I don't see how adding a parameter and definition would ruin playing older limit-removing WADs.

 

6 minutes ago, OpenRift said:

Those options were added primarily because PrBoom-plus (and by extension DSDA) are designed for comprehensive experimentation. Doesn't really serve as much of a purpose in other ports if you ask me.

Woof-based ports also have options as well. ZDoom ports also remove these limits. Only ports that still keep these would Vanilla, Chocolate, Crispy Doom, and possibly some older ports that a majority of doomers do not use.

[Maribo]

2 hours ago, Arsinikk said:

I would assume this includes Spechits Overflow as well? Not sure what it does, only that it supposedly breaks Vanilla demo recording.

I think you already got an answer from Boxy's reply, but yeah, as far as I'm aware all overflows can be disabled and not be discounted as invalid (at least, for pwad runs.).

 

Anyway, it's really not a dumb question to ask what "limit-removing" actually means. This is the 2nd thread I can remember asking this question in the last few months or so, but I dunno, I could be misremembering. I think I've also posted about this elsewhere, but some more context on the speedrunning side: There were a lot of wads from the 2000s into the early 2010s that self-described themselves as "limit-removing" in their text files, but they actually contained maps with Boom actions. Vice-versa was also true, there are wads labeled in their txt as "Boom-compatible" that contain no Boom actions, no excessive lost soul/pain elemental usage, or anything else that would indicate that it would require Boom to run. I would say that nowadays, when I see a wad/thread labeling itself as "limit-removing", it generally adheres to what I said before: vanilla actions without any other Boom-isms, but apparently it wasn't always an easy thing to understand.

[TimeOfDeath666]

8 hours ago, Arsinikk said:

I was working on a map for a community project that was limit-removing, and the maps were being tested in Crispy Doom. In my mind, limit-removing would mean that all static limitations and complevel bugs would be removed. The project leader said that while it was limit removing, they encountered an Intercepts Overflow or "all-ghosts" bug in my map and it had to be tweaked.

 

imo an intercepts overflow toggle should be necessary for any limit-removing port because they can happen easily in slaughtermaps, but the crispy dev doesn't agree (link).

[prfunky]

Here comes the thread derailment...

Until now, I had no clue what the Doom Complevels were. Thanks for "the notables" list.

Can't seem to find one for me though so I'm going to invent it right here, right now. I map

for complevel Z. It is the end all/be all of Doom Complevels. Let me further define this:

I was reading somewhere a topic about ZDoom 2.8.1 becoming a de-facto standard due

to the fork in development to GZDoom afterwards. It's frozen in time.** I could've called it

ZDoom 2016 but then that would lead to all kinds of other ambiguity. Anyhow, I don't take

advantage of any featureset larger than this level and everything works fine in LZDoom

and Zandronum so I'm happy.

 

Now, if there's a Wiki page somewhere that covers these complevels (which I never

bothered to look for), would the maintainer please add complevel Z to that page?

 

** = "PS: @dew i am not sure if it was you or @Fonze who said that ZDoom 2.8.1, due to being discontinued, was becoming a sort of fixed port for speedrunners alike or not,"...

Edited March 27, 2023 by prfunky
added appropriately related link