Shpoike / Quakespasm

Extra bloaty junk to modernise stuff a bit.
http://triptohell.info/moodles/qss/
GNU General Public License v2.0
185 stars 41 forks source link

[Bug] DoE lavamen in R2M3 #26

Closed NightFright2k19 closed 2 years ago

NightFright2k19 commented 3 years ago

In DoE's R2M3 "Elemental Fury II", lavamen #2-4 do not spawn in their lava pools, but on the floor/level below. Additionally, they won't stay put (as they should), but roam around freely and chase the player. They can still be killed to reveal the switches. Cannot be fixed by setting "sv_gameplayfix_setmodelrealbox 0". First lavaman spawns and behaves correctly.

Suspicion: droptofloor () from lavaman.qc (in void() lavaman_awake) might not work as intended when models are spawning in these suspended lava pools.

Problem does not occur in official Quakespasm v0.93.2 x64 (from 2019-11-12).

adelpha commented 2 years ago

Can confirm this bug, but they didn't roam around for me, they stayed in one spot - albeit on the floor below where they were supposed to be. they absolutely do roam, just very slowly so I didn't notice them moving at first.

Also, I forgot how good (and challenging) DoE is on Hard.

adelpha commented 2 years ago

As a test, I just shifted the broken lavamen +16 on the z axis. It fixed 2 of them, but the final one needed +20 units to stop falling through.

"origin" "-888 -64 132" --> "origin" "-888 -64 148" (+16)

"origin" "-880 64 348" --> "origin" "-880 64 364" (+16)

"origin" "-200 -64 372" --> "origin" "-200 -64 392" (+20)

So they're either spawning too low to begin with (unlikely, I guess), or as you say, the droptofloor test isn't resolving as it did in the past.

NightFright2k19 commented 2 years ago

droptofloor() is not exactly the correct syntax, anyway. Should be droptofloor(0,0). Anyway, I also tried a fixed progs.dat with that and it didn't make any difference. It worked in vanilla, so I dunno why QSS has problems with it. Anyway, you can provide an external .ent file to fix that issue if you don't want to place an exception case for that map in the code.

But I can confirm your fixed values work in QSS. Thanks for testing it on your own!

adelpha commented 2 years ago

Thing is, QSS shouldn't be different from QS or WQ in this behaviour. There are probably other maps out there with similar setups that are also affected, so the fix should be in the engine and not special-cased.

NightFright2k19 commented 2 years ago

My wildest guess, without having any idea about anything, is that for some reason QSS doesn't recognize the pool floor for lavamen no. 2+3 because they are clipping into it. In other ports, it thinks "OK, entity is clipping into a brush, let's move the model up to the next higher floor and hope for the best" and here it's like "Fine, dropping entity to the lower floor". Again, that's what it looks like to me, it can be something else entirely.

And you are right (again), if the port handles it like that, other maps doing the same thing might suffer from the same issue.

adelpha commented 2 years ago

Just as an aside, vkQuake has also inherited this problem - although only the last lavaman falls through in vkQuake, instead of 3 of them. Scratch that, I forgot to remove my "fixed" ent file from the maps folder. vkQuake's behaviour is identical to QSS.

The problem was introduced to vkQuake in 1.10.0-beta1, which is coincidentally when he merged protocol extensions from QSS, although using cl_nopext 1 doesn't fix the issue, neither does sv_gameplayfix_setmodelrealbox 0.

QS 0.93.2 remains unaffected.

Shpoike commented 2 years ago

QS's tracebox was rewritten to a) be faster b) be more precise. That precision improvement is what fixes the weird collisions you might have in QS which sometimes prevent you from crossing into more open rooms (vanilla/QS will often find a solid leaf to the side instead of the leaf it SHOULD be crossing into).

Unfortunately it has a slightly different behaviour for trace_allsolid. QSS will see the cavity below and report allsolid while QS will somehow treat allsolid as more like startsolid. The droptofloor builtin checks allsolid (for some reason) rather than startsolid, and QSS will then use that cavity that it found (the start might be solid, but the final impact point is empty).

To be clear, those lavamen really are positioned inside walls, and the qc code doesn't bother warning about it. On the plus side, I suppose this also stops them from moving out of their rather small lava pits.

Shpoike commented 2 years ago

fixed by https://github.com/Shpoike/Quakespasm/commit/c6ecb243d66868b776440258468ce03e9b768ef7