32bit threadID와 16비트 상위 WriteFlag에 대해

어차피 쓰레드는 많아야 최대 30개 수준입니다.따라서 int8, int16, int32 뭐로 관리하더라도 상관없고사실 손실 문제는 걱정할 필요가 없습니다.손실은 무조건 일어나는 것이 아니고, 아주 큰 숫자를 캐스팅할 때나 일어나는 것입니다.

GENERATED_BODY() 빨간 밑줄이 사라지지 않습니다

빌드는 되지만 그냥 빨간줄이 뜨는 것일까요?UE5의 매크로를 VS가 오인하는 일은 흔해서 큰 문제가 아닙니다 (보기 지저분한 것 제외하면)

수업자료 확인 부탁드립니다.

경로가 조금 수상한데 (zip이 찍히는게)압축 파일을 먼저 푸신 다음에, 그 폴더의 .sln을 열어서 실행하셔야 합니다.

질문 있습니다

0바이트를 보내는 것은 상대방이 연결이 끊길 때 일어나는 행동이라,Recv 0바이트에 집중하기 보다는 왜 끊겼는지를 봐야 합니다클라 쪽에서 접속는 잘 되었는지를 확인해봐야 할 것 같네요.그리고 강의 전체 소스를 실행해도 동일한 문제가 발생하는지 보고그렇지 않으면 하나씩 복붙 잡업을 해보세요

수업자료 확인 부탁드립니다.

안녕하세요 제가 방금 확인해보니 잘 열리는데, 혹시 어떤 강의의 수업 자료에 문제가 생기는지 알려주실 수 있을까요?그리고 혹시 Visual Studio가 설치된 상태는 맞으실까요?

Job Scheduler - Cache locality

1) This is a different situation. Job scheduling is about managing tasks across cpu cores. When it comes to multi-threading, what you know as 'cache' is not that effective. Often you will have to abandon what little data is cached in the cpu, because that data cannot be read across different cores. The current problem is more about [managing and executing 1000000 tasks across different cores], rather than [how to manage 10000 tasks ASAP]2) We only use locks to push/pop events from the queue. Mostly executing jobs will take 10000 more time than pushing/popping them into the queue. So it doesn't make that much difference and context switching is not a big issue. But you can still consider using lock-free queues if locking really bothers you.

언리얼 버전

네 5. 버전이면 상관 없습니다.

강의 영상 편집이 잘못된 것 같아요

허걱 제보 감사합니다!!

인벤토리 테이플 데이터가 엄청 많아지면

2만명은 귀여운 수준입니다!MMO 라이브에서는 아이템 데이터가 몇 백만 단위를 넘어가는데도 잘 돌아갑니다.물론 주기적으로 필요하지 않은 (버린 아이템)은 제거하긴 합니다.

C# 게임서버 3D MMORPG

MMO까지는 아니지만, 대표적으로 마영전 서버가 C#으로 유명합니다.최근에 만들어지는 MMO 프로젝트들은 간혹 C#을 채택하기도 합니다.다만 기본적으로 업계 표준 언어가 C++이기도 해서굳이 다른 언어로 할 이유가 딱히 없는 것도 사실입니다.