UE4Game.Target.cs 파일에 다음의 코드를 추가한다.

if (Target.Configuration == UnrealTargetConfiguration.Shipping || Target.Configuration == UnrealTargetConfiguration.Test)
{
  bAllowGeneratedIniWhenCooked = false;
  bAllowNonUFSIniWhenCooked = false;
}

엔진을 빌드한다.

이후, 게임 프로젝트의 *.Target.cs 파일에도 동일한 코드를 넣는다.

 

위의 코드를 넣어주면, 게임 구동시 [게임명]/Saved/Config/[빌드설정]/Config 폴더에 ini 파일을 쓰지도 않고, 읽지도 않는다. 단, GameUserSettings.ini 파일은 여전히 읽고 쓴다.

 

[부작용]

게임 옵션에서 인풋액션 설정을 Input.ini 파일을 통해서 저장하고 있었다면, 해당 기능을 더 이상 쓸 수 없다.

그런 경우, GameUserSettings.ini 파일을 이용하도록 코드를 수정하면 된다.

혹은, 엔진 수정을 통해 Input.ini 파일도 예외로 추가할 수도 있겠다.

제목 설명 장점 단점
BASE64 바이너리 데이터를 텍스트 포맷으로 변경해 줌. 이메일이나 URL 표시등에 사용. 텍스트 포맷이라 다루기 편함 데이터 사이즈가 늘어남. 2배.
SHA256 단방향 해쉬 알고리즘. 해쉬 키 길이는 32바이트(256비트). 짧은 데이터는 늘어나고, 긴 데이터는 줄어든다. MD5와 유사. 원본 데이터 보관은 어려우나 검증이 필요할 때 좋음. 즉, 비밀번호 검증 등에 효과적. 원본 데이터 복원이 안됨.
AES256 암복호화 알고리즘. 패킷 등의 데이터를 암호화 해서 주고 받을 때 좋음. 32바이트 단위로 처리하므로 패딩이 필요할 수 있음. 즉, 원본 데이터의 사이즈는 따로 보내야 함. 패딩이 없다면, 암호화 한 데이터의 사이즈가 늘어나지 않음. 작은 사이즈의 데이터를 보낼 땐 패딩 사이즈만큼 부하가 커짐.
RSA 개인키 공개키를 이용한 암호화 알고리즘. 강력한 보안이 필요할 때 사용함. 보안 처리가 강력함. 중요한 데이터(예: AES에 사용할 키)를 전송하는 데 사용하면 좋음. 원본 데이터 보다 암호화한 데이터가 훨씬 큼. 사용 방법이 까다로움. 

 

몬티홀 딜레마는 미국에서 약 40여 년간 방영한 미국의 TV쇼에서 유래한 확률 문제임.

사회자의 이름인 몬티 홀(Monty Hall)의 이름을 따서 몬티홀 딜레마 혹은 몬티홀 문제(Monty Hall Problem)이라고 불림.

 

A, B, C 세 개 문 중 하나의 문 뒤에 자동차가 있고, 나머지 문 뒤에는 염소가 있다.

참가자가 하나를 고르면, 정답을 아는 사회자가 나머지 두 개의 문 중 염소가 있는 문을 하나 연다.

이후 참가자에게 답을 바꿀 기회를 준다. 이때, 답을 바꾸는 게 좋을까 아니면 그대로 있는 게 좋을까?

 

얼핏 보면 최종적으로는 2개 중 하나이니까 50% 확률이라고 생각하기 쉽다.

하지만, 처음에 정답을 골랐을 확률은 1/3이고, 오답이 제거된 상황에서 처음 답을 유지하면 여전히 1/3 확률로 정답이지만, 선택을 바꿀 경우 1 - 1/3 = 2/3로 정답을 맞힐 확률이 올라간다.

 

좀 더 이해하기 쉽게 처음에 선택지가 10개가 있었다고 가정하자.

처음에 정답을 맞힐 확률은 10%밖에 안된다. 이후 사회자가 나머지 8개의 오답을 모두 제거하고 이제 딱 2개만 남았다고 생각해보자. 이런 경우엔 당연히 본인이 처음에 선택한 문보다는 사회자가 열지 않은 마지막 남은 문에 자연스럽게 눈길이 가게 될 것이다. 사회자가 남긴 문이 정답일 확률이 90%인 것이다.

 

이 문제를 코드로 작성해서 확인해 보자.

// Online C# Editor for free
// Write, Edit and Run your C# code using C# Online Compiler

using System;

public class HelloWorld
{
    static Random rand = new Random();
    
    static float TestMontyHall(int totalItemCount, bool changeFirstSelection, int testCount)
    {
        int successCount = 0;

        for (int i = 0; i < testCount; ++i)
        {
            int correctIndex = rand.Next(totalItemCount);
            int firstAnswerIndex = rand.Next(totalItemCount);
            
            // 처음 선택을 바꾼 경우
            if (changeFirstSelection)
            {
                // 첫번째 선택이 답이 아닌라면, 바꾼 후에 성공!
                if (correctIndex != firstAnswerIndex)
                    ++successCount;
            }
            else // 선택을 바꾸지 않은 경우
            {
                // 첫번째 선택이 정답인 경우에만, 성공
                if (correctIndex == firstAnswerIndex)
                    ++successCount;
            }
        }
        
        return (float)successCount / testCount;
    }
    
    public static void Main(string[] args)
    {
        Console.WriteLine ("Hello Monty Hall Problem World");
        
        Console.WriteLine ("If you change the first selection, success ratio is " + TestMontyHall(3, true, 10000));

        Console.WriteLine ("If you don't change the first selection, success ratio is " + TestMontyHall(3, false, 10000));
    }
}

결과는 아래와 같다.

Hello Monty Hall Problem World
If you change the first selection, success ratio is 0.664
If you don't change the first selection, success ratio is 0.3301

몬티홀 문제를 풀게 될 경우가 생긴다면, 처음 선택을 고집하지 말고 답을 바꾸자!

잡을 복사했는데 "빌드" 버튼이 보이지 않는다.

이럴 경우 "구성"으로 들어가서..

"저장"을 한번 해 주면 된다.

끝.

4.26 기준.

 

1.Diff 후 BP 컴파일 에러

소스 컨트롤과 Diff를 하고 난 이후 게임을 컴파일하면 느닷없이 컴파일 에러가 뜰 때가 있음.

자세히 보면 에러나 블루프린트(BP) 파일에 temp 어쩌고 하는 이름이 들어 있음.

Diff를 할 때 임시로 생성한 예전 BP파일을 컴파일하려다가 오류가 발생하는 걸로 보임.

 

대처법: 에디터를 껐다가 다시 켠다.

 

2.BP 컴파일 도중 검색하면 에디터 먹통

Find in blutprints에서 뭘 찾고 있는 동안 BP를 컴파일하면 에디터가 간혹 먹통이 된다.

 

대처법: 작업 관리자에서 에디터를 강제로 종료하고 다시 켠다.

 

3.PIE 도중 검색하면 에디터 먹통

에디터에서 게임을 플레이(PIE)하는 도중에 Find in blutprints에서 뭘 찾으면 간혹 에디터가 먹통이 된다.

 

대처법: 작업 관리자에서 에디터를 강제로 종료하고 다시 켠다.

퍼포스에서 sync나 submit 작업 시 멀티 스레드로 동시에 여러 파일을 전송하면 성능을 향상할 수 있다.

 

해당 기능을 적용하려면 퍼포스 관리자 권한이 있어야 한다.

관리자라면 퍼포스 서버에 직접 들어갈 필요 없이 본인 PC에서 원격으로 설정할 수 있다.

 

먼저, 콘솔창을 연다.

현재 서버에 설정된 값을 보는 방법은 다음과 같다.

p4 configure show

 

서버의 병렬처리 기능을 켜고 싶다면 다음의 명령어를 쓰면 된다. (숫자는 스레드 개수인데 1보다 커야 한다)

p4 configure set net.parallel.max=4

참고로, 서버를 재시작할 필요 없이 바로 적용된다.

 

서버에 위의 옵션을 켜 놓으면 클라에서는 바로 멀티 스레드를 활용할 수 있다.

예를 들어 다음과 같이 사용하면 된다.

p4 sync --parallel=threads=4 ...
p4 submit --parallel=threads=4 ...

 

만약, 모든 클라에 기본으로 병렬 sync 옵션을 적용하고 싶으면, 다음의 변수를 추가로 설정하면 된다.

p4 configure set net.parallel.threads=4

 

submit에 대해서도 모든 클라에 기본으로 적용하고 싶으면, 다음의 변수를 설정하면 된다.

p4 configure set net.parallel.submit.threads=4

 

위의 모든 옵션을 적용했을 때 설정값은 다음과 같다. (p4 configure show 명령어 사용)

 

설정된 변수를 지우고 싶으면 unset 옵션을 써서 삭제하면 된다.

p4 configure unset net.parallel.max
p4 configure unset net.parallel.threads
p4 configure unset net.parallel.submit.threads

 

참고로 퍼포스 클라이언트 UI(p4v)에서는 병렬 서밋 옵션은 기본적으론 꺼져 있다.

 

참고 링크:

https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_sync.html#Parallel

 

p4 sync

p4 sync Copy the latest revision of all files from the depot to the client workspace, as mapped through the client view. If the file is already open in the client workspace, or if the latest revision of the file exists in the client workspace, it is not co

www.perforce.com

 

ps. 병렬처리 옵션을 켠다고 다 좋은 건 아니다. 싱글 스레드 방식의 p4v에서 sync 시에는 읽기 전용 속성이 풀린 파일을 찾아내 강제로 받을 것인가를 물어보는 팝업이 뜨지만, 병렬처리 시에는 이게 작동하지 않을 수 있다. 또, 많은 사람이 동시에 sync를 받으면 서버에 과부하가 걸리기도 한다.

서밋을 할 때도 여러 사람이 동시에 많은 파일을 서밋 하면 서버가 멈추는 경우가 생길 수 있다.

 

ps. 사실, 이런저런 문제점들 때문에 net.parallel.max 옵션만 설정하고, 빌드서버에서만 --parallel=threads 옵션을 넣어서 사용 중이다. 바이너리 파일을 서밋 할 때 zip으로 압축을 하는데, 멀티 스레드를 사용하지 않으면 많이 느리다.

보안 이슈 등으로 인해 젠킨스 플러그인들에 대한 업데이트가 필요하다는 경고가 떴다.

젠킨스 플러그인 들을 업데이트를 하려고 하니 에러가 난다.

 

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

대략 위와 같은 에러이다.

 

해결책 1.

젠킨스 관리의 플러그인 관리 페이지로 들어간다.

"고급" 탭을 누른다.

https를 http로 바꿔보자

업데이트 사이트에서 프로토콜이 https로 시작하고 있다면, http로 바꾼다.

Submit을 눌러서 적용한다.

 

그런데, 본인의 젠킨스는 위의 방법을 적용했더니, 플러그인이 한번에 딱 하나만 받아지는 문제가 발생했다.

하나 받고 재부팅하고, 하나 받고 재부팅하는 식으로 계속 반복을 해줘야 했다.

처음 하나만 받아진다. 매번 재부팅 필요

에러 내용도 처음에 얘기했던 것과 같은 인증 문제이다.

 

한참 구글링을 하다가 아래의 사이트에서 방법을 찾았다.

https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/SunCertPathBuilderException-fix-for-Jenkins-plugin-download

 

Fix SunCertPathBuilderException Jenkins plugin download error - Coffee Talk: Java, News, Stories and Opinions

As I continue to publish Maven, Git and Jenkins tutorials as part of TechTarget’s coverage of popular DevOps tools, occasionally as I work on examples I run into peculiar problems that are both difficult to diagnose and frustrating to fix. The random

www.theserverside.com

 

해결법2.

젠킨스 플러그인 중에 skip-certificate-check 라는 게 있다.

귀찮은 인증 검사를 스킵해 주는 플러그인

이걸 설치하고 재부팅을 한번 하자.

이후엔 잘 된다.

드디어 성공

UDataAsset을 상속 받아서 만든 클래스에

TArray<enum> 으로 정의된 멤버를 추가했다.

 

enum 에 들어간 내용은 enum class 이름 : uint8 이었다.

그런데, 파일로 저장하니 배열의 사이즈 * 8 바이트의 사이즈로 저장된다.

 

배열의 사이즈가 작으면 별 문제가 안될 수 있으나, 내가 만든 데이터 에셋은 4096*4096 사이즈이다.

즉, 원래는 16MB 정도면 충분한데, 130MB로 저장되었다.

 

혹시나 싶어 TArray<uint8>로 변환해서 저장하니 16MB가 나왔다.

 

좀 알아보니, 언리얼에서는 enum 타입을 저장하면 메타데이터 같은 걸 같이 저장하기 때문에 용량이 커진다고 한다.

그래서 대량의 데이터를 저장할 때는 enum 그대로 저장하는 것 보다는 기본 타입으로 변형해서 저장하는 게 좋다.

 

 

 

 

TArray(배열)에서 아이템 제거해야 되는 경우,

원래는 RemoveAt(위치 인덱스) 사용한다.

이때 내부적으로는 memcpy가 호출되고, 따라서 나머지 항목들의 순서는 유지된다.

 

하지만, 굉장히 많은 항목을 반복적으로 제거해야 되고,

항목들의 순서가 중요하지 않거나 혹은 후처리로 따로 정렬을 해도 되는 경우라면,

RemoveAtSwap을 쓰는 게 낫다.

 

나머지 항목을 전체를 옮기지 않고, 배열의 맨 마지막 항목만 지우려는 위치로 복사한다.

참고 링크 : https://docs.unrealengine.com/4.26/ko/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/TArrays/

DefaultEngine.ini 파일에서 다음과 같이 추가한다.

 

[Core.Log]

Log[카테고리이름]=Verbose

+ Recent posts