[📚정보] 언리얼) 리슨서버에서 캐싱할 때

[익명(121.190)]

오래전에 알게된건데 그냥 끄적여봄

Cast는 무겁기 때문에 자주 쓰는 것들은 캐싱해주곤 하는데 리슨서버에서는 단순히 GetController, GetPlayerState 로는 호스트 컴퓨터가 캐싱이 안됨

그래서 Index 0번으로 호스트를 캐싱하고 나머지는 일반적인 방법으로 캐싱해주면됨

여기서 한가지 더 문제점이 있는데 PlayerController는 괜찮지만 PlayerState는 바로 캐싱하면 제대로 안되는 경우가 생김. 그래서 최소 0.2초정도 딜레이를 걸어줘야함. 나는 안전하게 0.4초 걸어줬음

아마 프레임워크 순서 때문에 그런거 같음

비슷한 문제로 로비에 접속할 때 플레이어들 정보를 PlayerState로 처리하는데 딜레이를 안걸어주면 씹히는 경우가 생겨 이 때도 0.2~4초 정도 딜레이를 걸어줬음

내일도 개발해야지...

[익명(121.140)]

멀티일때는 begin에서 실행하면 순서 문제땜에 씹혀서 생성해주는 주체에서 생성되는놈 begin될때 필요한 함수들 일일이 다 해주고 그랬던거 같은데 같은 맥락인가? 딜레이로도 처리 되나보네

[글쓴 ㅇㅇ(121.190)]

딜레이 쓰는게 좋은게 아니라서 캐싱때만 딜레이썼어 웬만한 정보는 플레이어스테이트 내부에서 OnRep으로 처리하는게 가장 안전하긴해

[ㅇㅇ 1(1.238)]

플레이어 스테이트 생성 과정이랑 이벤트 구조 뜯어봐 이상하게 복잡하긴 한데 딜레이보다 좀 더 깔끔하게 처리할 수 있음. 근데 저런 식의 캐싱은 프로파일링 돌려보고 꼭 필요한 경우에만 하기를 추천함.. 캐싱된 포인터의 유효성 관리를 또 해야 해서 귀찮아지는 경우가 많았음 어차피 엔진 소스코드에서도 Cast static_cast reinterpret_cast const_cast 상당히 자주 쓰기도 하고 - dc App

[글쓴 ㅇㅇ(121.190)]

너 말이 맞아. 나도 유효성 관리하느라 개발기간 늘어진 적 있어서 공감가네. 플레이어스테이트도 컨트롤러에서 캐릭터에 빙의하고 복제되느라 느리게 반응한다는건 알고있었는데 귀찮아서 저리하긴 했음 ㅋㅋㅋㅋ

[ㅇㅇ 2(180.224)]

Cast가 그렇게 무겁지는 않다던데 Update같은데서 쓰는거 아니면 그냥 Cast 써도 될...듯..?