ZDoom

I'd say change it - but only for MF_SPECIAL items.
I noticed this problem in Hexen, too, but never bothered to track it down.
This clearly got consolidated with other code where the different handling was crucial, but for item pickups it's clearly not correct.

To be sure that I got the idea right, here is my PR.

Looks fine.

https://www.doomworld.com/idgames/theme ... s/vltnight
BA1288DF7A7AD637948825EA87E18728 // vltnight.zip:vltnight.wad map02

Valletta's Doom Nightmare: MAP02 has a locked door with a backwards linedef, so it doesn't open from that side. Now that FlipLine finally exists, this line can be fixed without having to replace the entire map.

Hello, I have recently encountered a pretty strange issue while I was playing with my HXRTC Project randomizer mod on Community Chest 2 under latest release of GZDoom, currently at this moment 4.2.4a version...

After arriving to the big hellish marble area of MAP07: To Hell and Back (North-East corner in GZDoom automap) for getting the Red Skull Key, and once the Mancubus and Arachnotron monster-types showdown is over, the teleporting-exit passage opens like expected, but the bridge that allows arriving you to the exit passage doesn't rise at all. What happened? I have never faced this on my past games with the CC2 megawad...

But curiously, and after making some tests, seems I've detected the reason why this happens. The use of the console cheat command KILL MONSTERS effectively raises the aforementioned bridge to exit. So the problem must come from the Arachnotron-derivated monsters... then I enter into automap mode and use the IDDT cheat twice for viewing all the map elements... and voilá! There are a couple of Arachnorbs stucked in their teleport-ambush lair (hidden area at North of map) which seems the fast scroll floor hasn't taken them into the big marble area... Is this because they are floating monsters and scrollers don't affect them?

If answer is positive, is there any solution to apply for this? Now that I think, probably some other monster randomizers may get affected by this issue...

Thanks in advance for your attention!

Hexereticdoom wrote: Is this because they are floating monsters and scrollers don't affect them?

Correct.

Hexereticdoom wrote: If answer is positive, is there any solution to apply for this? Now that I think, probably some other monster randomizers may get affected by this issue...

Aside from not playing with mods that alter the monsters in a way that makes them incompatible with what the map expects - no.

Graf Zahl wrote:

Hexereticdoom wrote: Is this because they are floating monsters and scrollers don't affect them?

Correct.

Hexereticdoom wrote: If answer is positive, is there any solution to apply for this? Now that I think, probably some other monster randomizers may get affected by this issue...

Aside from not playing with mods that alter the monsters in a way that makes them incompatible with what the map expects - no.

OK, I see, then it's just what I suspected... But it's good to know it, too. In fact, I'm working around again on the mod at this moment to update it and resolve the aforementioned issue in an effective way for avoiding that map-breaking. I guess I'll finish it in a matter of few hours...

Thank you for your answer!

Alien Vendetta MAP11, waist-deep water:



official version map checksum: BCCD19190CA9BA14A4469617AE7909A8 // 1AV.WAD map11
Lexicon version is affected too: 620DE0E7CCC48BC7923378F215B06F7A // Lexicon-beta-build-137.pk3 av11

Alien Vendetta contains quite a few render hacks that cannot work with hardware rendering. Just have a look at the code for MAP01 fixing a comparable setup.

REKKR Expected behaviour (as per Chocolate Doom, as Rekkr is vanilla compatible):


GZDoom behaviour:

The door does open but the entire setup is very volatile, it depends on alerting an actor in a hidden room so if you do not shoot in the area where this can be done, the door won't open.

Graf Zahl wrote:The door does open but the entire setup is very volatile, it depends on alerting an actor in a hidden room so if you do not shoot in the area where this can be done, the door won't open.

No matter how many rounds I fire, I can't get the door to open in GZDoom whilst I can do so in Crispy. Using GZdoom 4.3.3 and the latest version of Rekkr

(Actually, are you using Rekkr 1.16? E1M3 was changed a lot in the last update)

I used the version in my play directory. No idea how old it is.

So I'm a bit at a loss here, because on one hand: This broke in a more recent update but on the other hand: This works in vanilla doom and as such should work on GZDoom?

The entire setup for this is one incredible hack. Like I said, it works in the older version I tested with. Where can I find the one it DOESN'T work with?