[469b] Warping/Desync bugs with Lifts, Teleports and Zone Portals

[BerserkerBG]

Lifts and Teleports (Playtested with High Ping): https://www.youtube.com/watch?v=o2ebfdJ6Wy0 ^ When your ping is high and you try to jump off any lifts like in the video, your screen warps and jerks around due to desync issues between the client position you see and the actual mover position.

Here is another example of mover desync. If you set up a long and slow mover going upwards, shoot at the wall as you go up. You will notice your weapon shots going "above" your head. This will help understand more what's going on with mover desync. It can happen with normal ping as well: https://streamable.com/ljuzwh

Warp Zones (playtested with Low Ping): https://www.youtube.com/watch?v=itIvWaDw_oQ During online play, when you enter a warp zone, there is a slight stutter and lag when you enter it.

[SeriousBuggie]

You need specify Expected result and Actual result fields for this videos. Because I watch it and still not have any clue what there wrong.

[SeriousBuggie]

About WarpZone there exists #103 issue, where exists few attempts improve situation on net. But you need understand - warping require movement player on big distances, so this create huge problem which hard solve with local prediction. ESP if there involved change direction stuff. So Portals is not good for very high speed net play. better avoid it if possible. Not sure if this problem can be solved at all.

[BerserkerBG]

So Portals is not good for very high speed net play. better avoid it if possible. Not sure if this problem can be solved at all.

Ouch thats sad to hear. Warp Zones are not very common on most maps anyway. However, Teleporters and Lifts are the most common actors in every map and they suffer from warping the most.

Unlike Warp Zones, Teleporters should be more simpler to attempt and fix. Besides the warping problems when entering teleporters, sometimes they randomly rotate you incorrectly and you end up looking in a different direction than intended.

[NeonKnightOA]

Just from the top of my head, official maps that use WarpZones:

• Chizra
• DmRadikus

[SeriousBuggie]

Official Unreal Tournament maps?

AFAIK no way normally solve rotation bug for teleport/warp with change rotation, until UT not introduce way make SetClientRotation relative to current value.

It can be in direct form like add 5000 to Yaw, or in Indirect form - transfer to client, server value of what server know about actor rotation. So on client you can compute difference and use it, instead of blindly set server value and lost any changes which happens since server data, because of latency.

Possible second approach can be done as second optional parameter to SetClientRotation. not sure. Maybe this totally break old clients.

[NeonKnightOA]

DM-Fractal? Can't remember if other maps implement such a thing. I know a version of CTF-Face does so.

[NeonKnightOA]

https://unrealarchive.org/maps/unreal-tournament/capture-the-flag/F/ctf-finalface_9edf8199.html

This one.

[SeriousBuggie]

I think in DM-Fractal is almost not critical what happens in second before die. Yes there can survive, but in general it mostly death and not matter jitter it you before or no. xD

I really want portal tech be usable on net, but very doubt if it can. Also not forget about NewNet (and based on it stuff), which use own movement (and replicate it over net) code. Very doubt if this good work in portals.

Also such stuff as NewNet really limit changes what can be done on native side,

[SeriousBuggie]

One problem of warpzones - calculate distance. Imagine you stay near wrap surafce. Now you goes to portal. Your coordinates fast changed to new location. So simple check like VSize(Location - OldLocation) < 10 fail. now prediction system think you too far. Server too think you too far or try cheat. Both try return you to last known position.

And we even not look at some not orthogonal movement into portal surface. Any jitter here and you warp back and forward.

Replay movement too can be screwed if warp turn you. For example you goes X +5 on replay movement. After warp in 180 degrees attempt replay X +5 lead to warp back.

Also warp can be blocked if there object on which you try warp. Server must properly calculate relevancy for stuff, which visible via portal. This lead to support Trace and friends for portals.

List can be continued, but this problem enough for say: need very big engine rework for make portals reliable more than fancy teleport with preview. And I am almost sure, such changes not possible without break compatibility with old versions.

[Melle4x]

Regarding mover desync on network play, has there been a solution for that yet?

(link posted by OP Berserker: https://streamable.com/ljuzwh (video by NuLL)) In the video you can see an example of a mover being desynced between server & client. The mover on client is ahead/behind compared to server side.

AFAIK this happens only on ROLE_SimulatedProxy, where the mover doesn't update it's position on client during move time, right? So I'm guessing for some reason the move times between client & server aren't matching? Dysync can be fixed by the mapper (or server mutator) to set the mover's Role=ROLE_DumbProxy, which AFAIK makes the mover update it's position on every tick, making it's position accurate between client & server, but stuttery.

So I was reading this thread on ut99.org: https://ut99.org/viewtopic.php?p=108210 And I'm seeing 2 interesting things:

1. By Sektor2111: https://ut99.org/viewtopic.php?p=108210#p108210 He talks about replacing the mover's original InterpolateTo function with an improved custom function. Which seems to adjust the mover's move time slightly. Because I'm guessing replicating vectors/rotators will round them, which is avoided by making movetimes "rounded"?
2. By Buggie: https://ut99.org/viewtopic.php?p=133615#p133615 An alternative calculation to the previous point.

Now I wonder, could this info help with finding a fix for desynced movers in network play? Imo changing movers move times isn't very optimal because it can break/change gameplay in maps.