Unreal 5.6 Mover Standalone Liaison Component, broken sync state collection life cycle

Development Programming & Scripting
, ,
1

Hi there,

In UE5.6 I noticed relevant changes to the whole mover liaison component middleware.

Unfortunately I also noticed that when selecting the UMoverStandaloneLiaisonComponent in a mover component its syncstate collection will not be properly “cleaned” between activations and the movement mode’s start state will no longer be invalidated when re-entering the same state.

Concretely this means that movement modes that rely on this (such as the Epic’s provided example UZipliningMode) will not work if the mover component is set to use the UMoverStandaloneLiaisonComponent.

Specifically calls such as this

const FZipliningState* StartingZipState = Params.StartState.SyncState.SyncStateCollection.FindDataByType<FZipliningState>();will always return a valid starting state except for the very first frame of the first time the mode is ticked within the session.

Previously it would return a null state on the first frame of each activation of the movement mode and this was used to initialize the movement mode.

My questions are:

  • is this intentional?
  • if so,
    • are there any examples of complex (stateful) movement modes (like the ziplining mode) that work properly with the standalone liaison?
    • how should the movement mode detect the first frame of simulation tick to initialize its sync state?
    • is it then expected that movement modes will need to be written keeping in mind the choice of liaison component?

My current workaround is to rely on the “MoverNetworkPredictionLiasisonComponent” (which is the default for mover component).

However, if I understand properly, this solution is keeping me from experimenting with the async simulation introduced in 5.6 for standalone :frowning:

Thanks for you help!

2

Steps to Reproduce

Reproducing the issue entirely within the contents of “Mover Examples Content”

  1. Enable the Mover and Mover Examples plugins
  2. Open “AnimatedMannyPawnExtended”, included in the Mover Examples Content plugin
  3. On the “ExtendedCharacterMoverComponent” component set the “Backend Class” to “MoverStandaloneLiaisonComponent”
    1. Compile and save the asset
  4. Load Map “L_CharacterMovementBasics”, included in the Mover Examples Content plugin
    1. Start the map
  5. Swap to the extended pawn by entering the pedestal ahead, slightly to the right of the spawn position
  6. Using the extended pawn (green) zipline upwards by jumping towards the zipline start point and pressing E on the keyboard when near the beginning of the zipline
  7. Notice you can no longer zipline downwards as the ziplining mode will not be re-initialized in successive attempts to use it
    1. Conversely if you first zipline downwards you will no longer be able to zipline upwards
3

Thanks for letting us know! This is definitely a bug and we’ve got a potential fix under review.

4

A fix has been integrated for the next release. It hasn’t shown up on the public Github repo yet, but here’s the addition in UMoverComponent::SimulationTick:

[Image Removed]

5

Unfortunately the cutoff for 5.6.1 has already passed, so it will be in the next release. If they decide to have another patch release, I’ll submit it for inclusion.

In the meantime, here’s the change in Github:

https://github.com/EpicGames/UnrealEngine/commit/944ae19da556d1bbe351476610fa306fa529a853

Once the issue becomes public, you can track it here:

6

Hi there,

Thanks for the reply!

Is this coming in 5.6.1?

  • If so, is there an ETA for that?
  • If not, is there a CL I can use as reference or maybe there’s a UE bug ticket I can follow up on?

Cheers!