Flying replication problem

lmperitum · November 1, 2022, 6:35pm

Hi!
Please help to solve the problem of jittering the ship controlled by another player (multiplayer).
Game problem video
The flight speed is 10000-20000 on average, for movement I use the built-in functionality through the MovementComponent.

Many times I twisted the replication settings in various variations, the settings in the MovementComponent, nothing changes, absolutely. I test by launching 2 clients in the editor.

The problem is super-important, I will be grateful for any tips that can help get on the path to solving it!

Rev0verDrive · November 1, 2022, 7:00pm

Show the code on the Thrust function @ tick.

lmperitum · November 1, 2022, 7:17pm

Its no code in tick. I just use build-in flying logic in MovementComponent

Rev0verDrive · November 1, 2022, 8:04pm

No the function running on Tick.

Need to see the code executed.

Your jitter issues is caused by Client - Server Fighting. Server is correcting!

lmperitum · November 1, 2022, 8:10pm

It only has logic for visual effects for a better speed feeling
If i turn it off, nothing changes

3dRaven · November 1, 2022, 8:29pm

How does the ship behave closer to 0,0,0 coordinates? Does it still jitter?

Your ship is traveling at very high speeds.
The further away it is from world center the more unstable it might get (due to floating point rounding errors) this may also effect server coorinates causing it to behave weird.

Rev0verDrive · November 1, 2022, 8:35pm

Lower movement speed to closer to defaults… say 1000 and test. If resolved, increment and test until you find the max.

lmperitum · November 1, 2022, 8:36pm

Yes! It’s dont jittering being close to 0,0,0
How can i fix this?

lmperitum · November 1, 2022, 8:39pm

Its still a little bit jittering at the default max fly speed - 600.

3dRaven · November 1, 2022, 8:45pm

You can’t really.
The only thing you can try is scaling the universe to a smaller scale (like 0.5 scale) this will make it seem bigger. It’s more of a math problem then a game engine one.

Unreal 5 does have a large world coordinate system but it seems to need to be enabled.
Seems you need to set bEnableLargeWorlds boolean to true (the docs are a bit vague where)

Rev0verDrive · November 1, 2022, 8:46pm

only other alternative is Origin Rebasing.

lmperitum · November 1, 2022, 8:52pm

Thank you!
I already enabled this option.
The ship starts jittering after 2 seconds from the starting point. I have a big map with long space tracks, Its wery hard to fit all these objects in such a small space. I think that should be some other solution for this problem, because i am sure that other multiplayer games use no smaller sizes than mine

lmperitum · November 1, 2022, 8:55pm

Thank you! I will try to google that

Rev0verDrive · November 1, 2022, 8:57pm

github.com/CesiumGS/cesium-unreal

Multiplayer Origin Rebasing Support Notes

opened 09:59PM - 04 Jun 21 UTC

closed 12:35PM - 03 May 22 UTC

xuelongmu

research

## Overview I did some investigation into multiplayer support with Cesium for U…nreal - specifically, whether multiplayer would be compatible with World Origin Rebasing. As mentioned in the [reference frames documentation](https://github.com/CesiumGS/cesium-unreal/blob/54c0e4f0afb37a6e1c2866f36939e28a4a747667/Documentation/reference-frames.md), Unreal Engine uses both an FIntVector (int32) to represent the position of a "floating" world origin relative to the absolute world origin (0,0,0), and an FVector (float) to represent the location of actors relative to that floating origin. World Origin Rebasing is the process of moving the floating origin closer to the player character's location in order to avoid floating precision errors, which can be noticeable after traveling a few kilometers away from the floating origin. Cesium for Unreal will call Unreal Engine's world origin rebasing function once the world origin is a user-specified distance away from the player camera, if the `Keep World Origin Near Camera` feature is enabled in the `CesiumGeoreference`. The normal World Origin Rebasing functionality is not compatible with multiplayer, as it cannot handle a client + server having different world origins. But a few engine versions ago, a [multiplayer version was added](https://github.com/EpicGames/UnrealEngine/pull/2359) and can be enabled via the Project Settings -> `Enable Multiplayer World Origin Rebasing`. ## How it works The way the multiplayer origin rebasing resolves the "multiple world origin" issue is by interpreting location vectors in the absolute world frame. That is, when a server sends (replicates) an updated movement location to a client, that location vector is rebased to the absolute origin frame before being sent, and when the client receives it, they rebase it to their own floating origin before applying the location update. This all happens under the hood when the `Enable Multiplayer World Origin Rebasing` feature is enabled. But you will also need to account for this when writing gameplay code, so here's a blueprint example, which demonstrates a teleportation mechanic that can be called from a client. My goal is to teleport the player pawn to the location of `BP Teleport Actor`. On the client side, I rebase that vector to the absolute origin before sending it to `S_Teleport` (server-side function), which rebases it back onto its own floating origin before actually teleporting the actor. The consequence of the server-side teleport is then propagated back to the client. Cesium for Unreal's world origin rebasing logic is compatible out of the box with multiplayer origin rebasing. ![image](https://user-images.githubusercontent.com/10490807/120864779-c4896800-c55a-11eb-93c9-767b7458a42f.png) _Blueprint example showing a custom teleportation mechanic, accounting for the multiplayer origin rebasing changes._ ## Caveats The glaring compromise to this approach, however, is that there is still a maximum distance we can reasonably play in before the floating point accuracy breaks down (approx 20x20 km play area). The philosophy behind doing this at all is that the jitter from client-side systems (in animation, client-side physics, particles) is noticeable sooner than in server-side systems like movement correction, which are more macroscopic. So, we can freely rebase client-side systems to benefit from smooth animations, until we reach the server-side accuracy limit. In order to have multiplayer gameplay on a truly global scale, Unreal Engine will most likely need double floating precision support. There was also a Cesium for Unreal specific issue I encountered as well, which is that when Frustum Culling is turned on, the ground that the client is standing on can be unloaded at any time in the server's game instance. Because physics is mostly handled server-side, and the server is the authority on what's actually happening in-game, the client is now falling into oblivion. Meanwhile, the client does not immediately notice - after all, in their game instance, they're standing on solid ground - until the discrepancy manifests itself via some catastrophic glitch. Disabling Frustum Culling resolved the issue, but also creates a ton of overhead, as all loaded tiles must be held in memory. A possible solution is for the server to avoid unloading tiles in the vicinity of clients. What would be even better is to only load the collision geometry rather than the entire gltf mesh + texture. This would also be a helpful step towards supporting dedicated servers, which do not actually render anything, and only handle gameplay logic, physics simulation, and network replication. As Cesium for Unreal currently decides which tiles should be rendered via calculating a view frustum, it probably wouldn't work at all in a dedicated server in its current state. ## Links Link to a sample project with gameplay examples at this [Unreal Engine forum thread](https://forums.unrealengine.com/t/pull-request-world-origin-shifting-in-mp/62649/77) and a [direct Google Drive link](https://drive.google.com/file/u/1/d/1yv1LZljx5JeyQLhkzVMr1BbNsRVFXecp/view?usp=drive_open). ![image](https://user-images.githubusercontent.com/10490807/120861749-cc92d900-c555-11eb-8772-db88b4f1a076.png) _Screenshot of a server + client with different floating world origins, as indicated by the location of the red spheres._ Note: When enabling the multiplayer world origin rebasing in your own project, I found that a restart was necessary, even though it wouldn't prompt you to restart. Otherwise the behavior is very buggy.

Doublezer0 · November 2, 2022, 3:09pm

There are issues with multiplayer and large worlds with World Composition that uses origin rebasing. It requires custom solutions to solve the issues. All of which are solved in UE5 with World Partition. If it’s too late to switch over then I would look up some historic solutions for origin rebasing + multiplayer + floating point issues

Chatouille · November 2, 2022, 4:45pm

Considering this issue only happens in multiplayer according to your post, I suggest looking into these config variables

With your massive scale and flight speeds, you probably should bump up the error tolerances. So look into these two in particular