Networked Player Movement Support

[Eoin-ONeill-Yokai]

This might already be supported, but I was curious to know if this system works well with UE4's networking systems. Additionally, would it be possible to add the more robust networked movement of, say, TF2 and CS:GO instead of HL2's original networking design?

I know that UE4's UCharacterMovement component supports networked movements with basic rollback / prediction, but was curious to know if this set of components works with their networking systems?

[mastercoms]

This movement component is based on UCharacterMovementComponent and we made no effort to do anything to networking. This means we did not remove anything already there, nor did we add anything new. Replicating any Source game's multiplayer networking is out of the scope of our development at this time and would not fit in with UE4's replication and networking systems.

We have received reports of jitter in turning and crouching, so it's likely not going to work well for networked clients.

We do, however, have some interest in persuing some replication features to accomodate demo support at a later date. We'd like to encourage the community to help us in this effort if they are interested to see further networking/replication support in this movement system.

[Eoin-ONeill-Yokai]

Interesting.

You won't have to necessarily remove UCharacterMovementComponents networking features. IIRC (and it's been a while since I looked into the code) it should be possible to embed a custom packet of data by extending the internal class for your own purposes. Movement packets are stored in a ledger sorted by their time stamp and prediction is then handled by stepping through the inputs until an update is issued by the server. The client then removes all accounted-for packets, and steps through the prediction process again.

Basically, and I can look into this myself sometime, the input packets you are fetching could perhaps be replicated with networking by a few minor changes to how the input vectors (I believe WishDir in this code?) are stored.

I would agree that it's probably beyond the scope of Project Borealis itself, but it's an interesting thought for Source mods which might want to secure a future on the Unreal Engine and remove their dependency on Source 2. It could make for an interesting branch, at the very least.

[Eoin-ONeill-Yokai]

I'm going to go ahead and close the issue.

Looking into it, there's a lot more that would have to be done with the PB character controller to get it replicating properly. Because a lot of the standard UE4 functions are overridden, it would take a lot of work to re-establish the networking protocol.

It wouldn't be impossible though -- so it's worth revisiting at some point I think. :)

[mastercoms]

I think it's best for it to remain as an open issue, as there is possible work to be done in this area.

Also, thank you for bringing this up again. I have since found the Network Prediction plugin which seems to be bringing the more robust replication concepts found in Source to Unreal Engine 4. Once this is finished, we will look into moving our movement component to this new system.

[Hevedy]

Note the default CharacterMovementComponent have a core bug or missing code even if they made different tries to fix it where the Server see all the clients in chunks on Listen Servers https://forums.unrealengine.com/unreal-engine/feedback-for-epic/1346282-impossible-use-ue4-for-a-coop-or-mp-listen-server-game-due-the-unfixed-network-errors-since-4-years

On normal network should work fine.

[mastercoms]

After testing, everything works fine on our code. I have not tested the public character movement plugin specifically, if there is any needed logic, let me know and I can add it.