ZDoom

Yup, it definitely needs a compatibility option. This is a behavioral change, not something that can be edited in the map data.

[quote="Professor Hastig" post_id=1256709 time=1732542657 user_id=37599]
It's typical Doom: Once an issue becomes known it is not "How do I avoid it?" but "How can I exploit it?" :twisted:
[/quote]

Welcome to the wonderful world of Doom editing where there's no glitch some mapper did not find useful to exploit.
Does anybody wonder why the engine cannot really be optimized anymore?

You won't be able to address the problem with level postprocessing. It gets triggered while the level runs by performing an overeager sector type transfer that transfers the secret flag along with the desired parts of the flag field.
You need at least a new compatibility flag here to have both the correct behavior and support for all these ugly hacks that abuse the bug.

It's typical Doom: Once an issue becomes known it is not "How do I avoid it?" but "How can I exploit it?" :twisted:

[quote=Mordeth post_id=1022863 time=1508007554 user_id=329]
Hi,

In a Doomworld thread (https://www.doomworld.com/forum/topic/97332-how-to-reveal-secret-without-player-entering-any-specific-sector) the question was asked how to create a triggerable secret tag for Boom-compatible ports. My suggestion was to turn the sector the player was standing on from normal to secret by using a 'change effect' trigger. See example level https://www.dropbox.com/s/z2eex38v2g4bk8x/trigger.wad?dl=0. Two secrets: the red area counts as one; the blue area turns red & secret after pulling the switch.

That is, in PrBoom and Eternity. In (G)ZDoom this does not work. However, other sector flags (eg damage, friction) work as intended. The 'light' based flags might work, but they will not yield the intended result anyway in any port so I did not test that.
[/quote]

Hello! So, I saw this report back from 2017, which was closed with this explanation from Graf:

[quote="Graf Zahl" post_id=1022865 time=1508011083 user_id=75]
This was a fully intentional change because this behavior broke the secret counting in one of Heretic's IWAD maps (E3M4).
[/quote]

My understanding is that this was at a time when ZScript was still in its infancy and the the levelpostprocess compatibility layers were nowhere near as robust as they are today. Because of that, I figured it wouldn't hurt to bring this up again, as I imagine by now, if there's a vanilla map error, then surely both the fix could be applied [i]and[/i] a new workaround fix could be supplied in levelpostprocess, so this way both Heretic as well as mods that take advantage of this trick could work. :) What do you think?