-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] DoE lavamen in R2M3 #26
Comments
Can confirm this bug, Also, I forgot how good (and challenging) DoE is on Hard. |
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. |
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. But I can confirm your fixed values work in QSS. Thanks for testing it on your own! |
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. |
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. |
Just as an aside, vkQuake has also inherited this problem - 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. |
QS's tracebox was rewritten to a) be faster b) be more precise. 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. |
fixed by c6ecb24 |
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).
The text was updated successfully, but these errors were encountered: