[Bug] Softlock in Dimension of the Machine map mge2m2 in Ironwail

[DespairEngine]

I recently switched from good old Quakespasm to Ironwail and have been very impressed with its performance. While replaying Dimension of the Machine, I encountered a bug in mge2m2 (Fading Embers): the rune in this screenshot will zip downwards and disappear as soon as the elevator starts going down, softlocking the map. I tried it with unlimited FPS, locked to 60, to 120 etc. with the same result every time.

[daftmugi]

Hi @andrei-drexler, could you please take a look at this? Since it is game breaking, it may be considered high priority. I wonder if it is affecting other maps as well.

I did confirm this. The rune falls through the floor once the elevator starts to move, making it impossible to pick up later. I also tested this in QuakeSpasm and vkQuake, and they both work fine.

Fortunately, it's pretty easy to noclip to this area of the map to test it out, if needed.

Sorry to bother you. I know you're really busy. Thank you for looking into this when you can.

[andrei-drexler]

This does happen in vanilla QS, too - Quake's original ray tracing function is... let's say "quirky". QSS (and vkQuake) use a different function by default (unless pr_checkextension 0 is used), which is in theory more robust, but it can also cause other compatibility issues (e.g. https://github.com/Novum/vkQuake/issues/337), so I'm hesitant to go that route.

[DespairEngine]

That's odd. It works for me no problem in vanilla QS, same as @daftmugi said. I recorded a short clip of me activating the elevator and then collecting the rune in the latest version of QS (typed "version" into the console as proof): https://streamable.com/1hjoo2

I tried it three times just to be sure, and it worked fine every time.

[daftmugi]

Interesting. I tested using QS (https://github.com/sezero/quakespasm/commit/22b9b3474c4102bbcfee033935758cc497445970) and it worked fine. Is there an option that I have set in QS that makes it work? Does that commit work for you?

[andrei-drexler]

Hmm. I tested this by first making a savegame after unlocking the button that sends the platform down and then loading that in IW and QS, and the outcome was the same. The savegame was made in IW, though, and starting the map in QS directly doesn't exhibit this issue. I looked into this a bit, and it's triggered by an optimization that unfortunately exposes another issue in Quake's intersection code. For now I've reverted that optimization (commit 782f3c5e69a9ac1a8dc194e17dfa12d823b8c383), but I'll have to take a closer look at the ray tracing code at some point, since that optimization alone doubled the framerate on 10kknights.

@temx @Novum you might want to look into this, too, since a higher AREA_DEPTH affects droptofloor regardless of the value of pr_checkextension.

[daftmugi]

Thank you for solving this!

[temx]

Thanks for the heads up. The issue appears to be the rune is placed inside the enclosing bar entities and the behavior of SV_ClipToLinks when the trace returns startsolid depends on the order edicts are visited. A low AREA_DEPTH will place everything in the leaves and the correct entity (the large platform, on normal skill #524) will be visited last. With high AREA_DEPTH the large platform will get linked in an upper tree level so the enclosing bars (#240..247) will be visited last, their fraction is higher but having startsolid makes them overwrite the result. Not sure what to do about this. At least with QSS' tracing the rune doesn't completely fall off and can still be picked with a bit of erroft.

[wirion]

FYI this bug also occurs in The Punishment Due's 4th level "With fiends like this" (pun4). https://www.quaddicted.com/reviews/pun.html

There are 10 buttons to hit in order to progressively lower the golden key to where the player can grab it. Upon hitting the 10th button, the golden key lowers down to the floor, and then drops through it. Savegame attached. s19.zip