스즈키입니다. GameOfThrones가 재미 있고 잠이 부족합니다.

복제는 액터 단위로 서버에서 전송됩니다.

액터 속성의 복제는 틱마다 여러 액터가 지명되어 전송됩니다.

SimulateProxy 액터를 가지는 클라이언트상에서의 처리로, 자신 이외의 복수의 액터내의 replicate 변수에 액세스 하는 처리가 있는 경우, 프로퍼티의 갱신 타이밍의 어긋남에 의해 문제가 나오는 일이 있습니다.
※근본적으로는 다음 액터 밖에 강한 의존관계가 있는 것은 바람직하지 않습니다

그림

ThePawn과 TheActor의 각각이 가지고 있는 프로퍼티 LastPower와 Power가 싱크로 하고 있을 것을 기대하고 있다고 했을 때의 거동입니다.
※나쁜 설계의 예입니다



서버측에서는 ThePawn과 TheActor는 연속적으로 처리되고 있습니다만,
클라이언트 측에서는 복제가 액터 단위로 이루어지기 때문에 LastPower와 Power 속성이 액터간에 동기화되지 않은 타이밍이 발생합니다.
여러 액터에 걸쳐 있는 변수 액세스를 할 경우에는 이러한 타이밍의 어긋남이 있기 때문에 가능한 한 피하는 것이 열심합니다.

서버에서 처리 순서와 RepNotify 처리 순서가 일치하지 않음

RPC는 처리 순서를 보장하지만 RepNotify는 순서를 보장하지 않습니다.
예를 들어 서버와 클라이언트의 처리 흐름을 작성해 보겠습니다.

서버

Pawn::SetValueA(B)

OnRep_ValueB() ※로컬로 호출

Pawn::SetValueA(10)

OnRep_ValueA() ※로컬 호출

PawnA의 속성을 복제

클라이언트

클라이언트에서 패킷 수신

속성을 PawnA에 저장 (ValueA:10 ValueB:5)

PawnA에 대해 RepNotify 호출

OnRep_ValueA

OnRep_ValueB

클라이언트 측에서 서버 RPC의 순서로 RepNotify가 일어나기를 기대하면 버그의 원인이 됩니다.
또한 모든 값이 저장되고 RepNotify가 호출되기 때문에
각 RepNotify에서 트리거 대상이 되는 대상의 다른 변수에 액세스하는 경우에도 주의가 필요합니다.

RepNotiy라는 순서는 UClass의 속성 목록 순서에 따라 달라집니다.

참고

예전에 쓴 남자
UE4 MultiPlayer Online Deep Dive: 실천편 1