Welcome to the ZDoom Forums!

After some debugging I found the cause.

The semantics for 'impact' lines are quite messy. They normally only get triggered when either a hitscan crosses the line or a projectile actually hits it.
But there was a side effect in the original code that also triggers impact and push lines if they get touched by a projectile that at the same time hits another wall.
ZDoom fixes this bug and as a result this setup which explicitly abuses it does not work as intended.

This requires setting a compatibility option for this map.

So it's a case of an IWad developer exploiting a weird engine glitch? They should've known better.

Glad it could be fixed. Though I'm still going to keep the map fix I made, since it makes the window produce glass shards as well.

Well, I don't know.
For some reason, the original implementation sounds a bit like splash damage...
So, perhaps it wasn't a side effect...

The original implementation was clearly broken. You can see that in its inconsistency.
The entire Doom movement code suffers from ugly side effects of some supposedly 'purely informative' functions doing some actions and collecting data - but that data collection again depending on order of checking and not something getting in the way that may cause an early-out of the checks.

The impact trigger at play here is such a thing.

OK, in such case, while I probably won't understand the answer, would you mind telling how should that window have been implemented in the map (compared to the way it is) if vanilla had a consistent implementation ?

I wrote:The sector past the window in Map30 doesn't allow enough room for most missiles to completely enter it. Sure enough, by making the sector deeper, I can get the window to break easily.

As mentioned earlier, the windows in "Bright Crucible" demonstrate that this knid of window can work.

Though really it'd be better to use a dropping sector like Map01's windows.

VoidMage wrote:OK, in such case, while I probably won't understand the answer, would you mind telling how should that window have been implemented in the map (compared to the way it is) if vanilla had a consistent implementation ?

The only proper option would have been to implement consistent trigger semantics. What was missing here is a trigger type that gets triggered by both crossing projectiles and hitscans.
Strife had such semantics so it was certainly doable.

NeuralStunner wrote:

I wrote:The sector past the window in Map30 doesn't allow enough room for most missiles to completely enter it. Sure enough, by making the sector deeper, I can get the window to break easily.

As mentioned earlier, the windows in "Bright Crucible" demonstrate that this knid of window can work.

It's too long since I played vanilla Hexen, but according to my (spotty) memory, these lines did NOT work properly.

They work fine, but with two oddities:

1. The first line is erroneously flagged Repeatable. Shooting throguh it will continuously produce glass shards and sound.
2. The second line is only breakable once placing the gem onto the pedestal. Until then, attacks pass through it (as per the Impassable flag).

I've found a way to fix the first but not the second (short of making it a dropping sector, but only if I don't have to rebuild nodes for vanilla).

NeuralStunner wrote:They work fine, but with two oddities:
...
2. The second line is only breakable once placing the gem onto the pedestal. Until then, attacks pass through it (as per the Impassable flag).

Actually, for that map this part looks like a design choice (at least as far as I recall the map, would need to recheck).