Skip to content
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

Closed
NightFright2k19 opened this issue Dec 4, 2020 · 8 comments
Closed

[Bug] DoE lavamen in R2M3 #26

NightFright2k19 opened this issue Dec 4, 2020 · 8 comments

Comments

@NightFright2k19
Copy link

NightFright2k19 commented Dec 4, 2020

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
Copy link

adelpha commented Aug 4, 2021

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
Copy link

adelpha commented Aug 4, 2021

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
Copy link
Author

NightFright2k19 commented Aug 5, 2021

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
Copy link

adelpha commented Aug 5, 2021

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
Copy link
Author

NightFright2k19 commented Aug 5, 2021

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
Copy link

adelpha commented Aug 7, 2021

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
Copy link
Owner

Shpoike commented Aug 12, 2021

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
Copy link
Owner

Shpoike commented Sep 8, 2021

fixed by c6ecb24

@Shpoike Shpoike closed this as completed Sep 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants