Notes |
|
|
Is this a new problem in 1.3 or did this also happen in earlier versions? And can you record a client demo that shows this issue? |
|
|
(0010678)
|
Frits
|
2014-10-25 08:47
(edited on: 2014-10-25 09:10) |
|
you're faster then i can add a demo :). This didn't exist in 1.2.2
As you can see in the screenshot and demo, the floor looks like it's lowered on the client but on the server it's actually on the same level as i am standing.
EDIT: it's not happining all the time more like half of my attempts. And as far as i can tell when there are 2 players it can be possible that only player A sees it and vice versa.
|
|
|
|
Thanks for the demo!
Quote from Frits This didn't exist in 1.2.2
In that case, can you check older 1.3 builds (see here and here) to narrow down when this crept in? |
|
|
(0010685)
|
Frits
|
2014-10-25 15:40
(edited on: 2014-10-25 15:53) |
|
It's present in 1.3 140610-2242.
I wasn't able to run to demo in other versions of zandronum with Zcinema as this demo somehow failed to run on it.
I tried reproducing the bug in a local server but that unfortunately didn't work either.
|
|
|
|
Unfortunately, playing the demo is not sufficient to check whether a certain revision is affected by the bug. It needs to be checked with client and server using the revision in question.
Quote from Frits
I tried reproducing the bug in a local server but that unfortunately didn't work either.
Does this mean the problem only happens if you use a non-local server, regardless of the binary revision? In this case, can you check if you can reproduce the problem with a ping / packet loss emulator like Gamer's Proxy? |
|
|
(0012019)
|
Frits
|
2015-04-04 16:45
(edited on: 2015-04-04 17:02) |
|
Sorry for the long delay in my reply Torr, as i am quite busy in real life.
I managed to reproduce this in 2.0 with HR2 MAP31 on a localhost server w/o using gamersproxy. However i cannot produce it when i'm offline or in multiplayer emulation mode.
A good way to reproduce this is to activate the lift, die while it's lowering and then jump off the edge so that when the survival countdown timer reaches 0 you're still mid-air(falling down towards the lift floor). I hope that makes sense to you ;)
|
|
|
(0013196)
|
unknownna
|
2015-08-10 14:27
(edited on: 2015-08-10 14:44) |
|
I can confirm this. It seems to have something to do with ping spikes. It's very easy to reproduce the issue with these proxy settings when using Gamer's Proxy:
* The ping is combined at 40 ms.
* Ping spike chance is 75.00%.
* Max ping spike strength is 500.00%.
I managed to reproduce the issue in 98d and 1.0 as well.
|
|
|
|
A reduced example wad would really help here. |
|
|
(0013209)
|
Frits
|
2015-08-11 11:25
|
|
That's so strange, I've played this map a million and one times in 98D and never noticed it. Maybe it just occurs more now?
@edward-san but everyone has hr2.wad :P (-map map31 -nomonsters) |
|
|
(0013210)
|
unknownna
|
2015-08-11 13:36
(edited on: 2015-08-11 15:45) |
|
Quote from Edward-san A reduced example wad would really help here.
It doesn't seem to happen in hr2_floor_test_01.wad. It also doesn't happen when I copy-paste an empty shell of the map. It starts to happen once I copy-paste all the things as well. I'll try to narrow this down further.
It seems to be dependent on how many things there are present in the map. The more things there are present, the more likely it is to break.
It can also happen with a direct LAN connection to the server.
On a side note, the new example WAD causes the gameplay to lag/stutter considerably more offline when resetting the map once. The lag/stutter is very reminiscent of the RichEdit control lag issue. However, unlike the RichEdit lag issue, this lag goes away after a "map/changemap" map change and starts to lag again whenever you reset the map.
|
|
|
|
I figured out what makes this break.
If there's too many actors (1760+ things) on the map that have a minimum of 2 frames in their idle animation, for instance "BKEY AB 10", it glitches. It can be any thing that has a few frames of animation in its idle state. The more actors that animate, the worse it desyncs. The same amount of things that only have 1 frame of looping animation or have a -1 frame in their idle states don't cause the glitch.
This code causes the glitch:
Spawn:
BKEY AB 10
Loop
This code doesn't:
Spawn:
BKEY A 10
Loop
Why this makes floors break at map resets, I'm not sure. But maybe this information can help you narrow it down. |
|
|
|
This issue is curiously linked to 0003334, particularly when using "cl_usemovebuffer 1". This causes the map to break more often even with a local connection to the server. You can "fix" the issue by turning the movebuffer off, and if you use the chasecam to observe your own player, you can see how the player shifts heights depending on the "cl_usemovebuffer" setting. The player animation also breaks and won't stop animating. I also recommend using the "idmypos" cheat to see the z-height desync.
There are 2 maps (MAP01 and MAP02) in the updated example wad. They are identical other than having different dummy actors that animate differently. The 1st map that almost always glitches out uses 2 frames for its actors, whereas the 2nd map that doesn't break uses 1 frame for its actors.
Simply shoot at the switch, and press +use to reset the map. Use "changemap/nextmap" to do the same on the other map that doesn't break.
I can confirm that the offending map also breaks in Skulltag 98d, so it's an ancient issue that's made more present with the new movebuffer.
Quote from unknownna On a side note, the new example WAD causes the gameplay to lag/stutter considerably more offline when resetting the map once. The lag/stutter is very reminiscent of the RichEdit control lag issue. However, unlike the RichEdit lag issue, this lag goes away after a "map/changemap" map change and starts to lag again whenever you reset the map.
This does not seem to be the case anymore from testing. It never lags now. It must have been changed or fixed by something else later on. |
|