Small question about compatibility

Can I call my wad limit removing even if I put some boom engine elements, such as ANIMATED and SWITCHES lumps, into it? Because I saw some wads were defined as limit removing, despite it has some lumps related to boom engine. And I honestly think that there is a huge difference between limit removing and boom compatible one.

I think if a map is beatable and looks mostly complete in cl2, it's fair to have cosmetic cl9 stuff (sky transfers, fake floors, etc) and still call it limit-removing. I'd have to imagine switches and animated lumps get ignored by prb+ on pre-boom complevels, ya?

Yeah, limit-removing is not the most well-defined term. Stuff like SWITCHES/ANIMATED, Boom-format strings in Dehacked, tiling of non-128px high textures, etc. etc. all gets used these days. Basically as long as you're using only vanilla linedef and sector types, Limit-Removing is the best label. (edit: As Ribbiks pointed out, cosmetic stuff like sky transfers are pretty much OK too as long as your map won't break if it gets ignored.) Doesn't hurt to say that you're using extra lumps or whatever in the text file I guess.

Ribbiks: nope, PrBoom+ is fine with SWITCHES/ANIMATED lumps in cl2. Same with recent versions of Crispy Doom, which doesn't support Boom-level maps at all.

Call your wad "PrBoom-plus -complevel 2 compatible". Calling it "limit-removing" would imply that it's supposed to work in every limit-removing port, not just PrBoom-plus. In practice, though, PrBoom-plus is simply the most widely used classic limit-removing port, and supports Boom features too, that's why the terms somewhat blend together.

Just say what it works with and how. Don't use loopholes.

scifista42 said:

...In practice, though, PrBoom-plus is simply the most widely used classic limit-removing port...

Right. Come to think of it, It's hard to recall other limit removing source ports that don't support boom compatibility these days. Maybe some old version of Legacy or jDoom can be the examples?

Still, I think that there should be strict criteria to divide between limit-removing and boom-compatible.

The correct meaning of "limit-removing" is "not being constrained by these vanilla Doom's static limits", specially MAXDRAWSEGS and MAXVISPLANES.

EDIT: I see, I see, you're saying that the term should be better defined, I agree, but well, I'm not sure if everyone would ever agree on whatever proposed strict set of criteria.

antares031 said:

Right. Come to think of it, It's hard to recall other limit removing source ports that don't support boom compatibility these days.

Doomsday still isn't Boom-compatible. But on the other hand, that's not really the port people use to play custom maps...

Crispy Doom isn't, and likely never will be, even though it supports some Boom features.

3DGE isn't fully Boom-compatible yet, though I gather that will be fixed soon.

Maybe some people still use doom2p.exe ?

A linedef with a player-activated special doesn't need to use a switch texture to work, so a port that doesn't support the SWITCHES lump will only result in a small loss of cosmetic niceties (the switch sound and texture change giving feedback to the player that something was indeed activated even if the effect itself is not instantly visible) but not break the map.

Likewise, if an animated texture doesn't animate, it's a purely cosmetic loss but it shouldn't impact gameplay.

This is like the MBF sky transfers that don't prevent from playing with Boom. You'll miss on cosmetics, but not on anything demo-breaking.