In our project do not use iris and we use a subclass UExtendAbilitySystemComponent derived from UAbilitySystemComponent.
In this subclass, there is a FastArray member variable named ExtendActivatableAbilities that needs to be replicated.
We want it to be replicated before UAbilitySystemComponent::ActivatableAbilities reaches the client.
To achieve this, we implemented UExtendAbilitySystemComponent::GetLifetimeReplicatedProps as follows:
void UExtendAbilitySystemComponent::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const { FDoRepLifetimeParams SharedParams; SharedParams.bIsPushBased = true; SharedParams.Condition = COND_OwnerOnly; DOREPLIFETIME_WITH_PARAMS_FAST(UExtendAbilitySystemComponent, ExtendActivatableAbilities, SharedParams); Super::GetLifetimeReplicatedProps(OutLifetimeProps); // placed at the end }
In this way, ExtendActivatableAbilities would be replicated to the client before ActivatableAbilities.
According to the description of the bReplicateCustomDeltaPropertiesInRepIndexOrder, this seems to be a mechanism intentionally provided by the engine.
However, after we upgraded the engine to version 5.6.1, this mechanism no longer works even though we have set net.ReplicateCustomDeltaPropertiesInRepIndexOrder = flase and Net.AutoRegisterReplicatedProperties=false.
After checking the source code, we found that previously, the function FRepLayout::InitFromClass would construct LifetimeCustomPropertyState in the order of LifetimeProps.
But in the new version, it now constructs them based on the order of ClassReps.
It seems that users can no longer influence replication order by the order in which they fill LifetimeProps.
slack links:
[Link Removed]
There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-352529 in the post.
| 0 |
| Component | UE - Networking |
|---|---|
| Affects Versions | 5.6.1 |
| Target Fix | 5.7.1 |
| Created | Nov 5, 2025 |
|---|---|
| Updated | Nov 7, 2025 |