mLua · Nemotron SDG 질문-응답 (SFT)

[task] | single_turn [pass] | ⏳ 미판정 [title] | Hierarchy [question] | 복잡한 맵에서 특정 엔티티를 빠르게 찾거나 체계적으로 관리할 때 Hierarchy의 계층 구조를 활용하는 구체적인 장점은 무엇인가요? [answer] | 복잡한 맵에서 특정 엔티티를 빠르게 찾거나 체계적으로 관리할 때 Hierarchy의 계층 구조를 활용하면 다음과 같은 구체적인 장점이 있습니다. **1. 빠른 탐색 및 시각적 확인** * **계층 구조로 현황 파악:** Hierarchy 탭은 제작 중인 게임 현황을 **계층 구조(부모-자식)**로 보여주기 때문에, 복잡하게 구성한 맵에서도 원하는 엔티티를 빠르게 찾을 수 있습니다. * **검색 기능 활용:** `findentity` 또는 `findcomponent` 명령어를 사용하면 특정 경로(예: `World/ui/Def [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 **Hierarchy** 탭을 이용해 제작 현황을 확인하고, 제작 능률을 높일 수 있습니다. # Hierarchy 소개 **Hierarchy** 탭은 제작 중인 게임 현황을 **계층 구조(부모-자식)**로 볼 수 있는 패널입니다. 복잡하게 구성한 맵에서 원하는 엔티티를 빠르게 찾을 때 사용하거나, 체계적으로 엔티티를 관리할 때 사용합니다. 가장 상위인 **World** 계층 아래에 **common**, **maps**, **ui** 엔트리가 있으며 **maps**와 **ui** 엔트리는 각자 기본 하위 엔트

[task] | two_turn [pass] | ⏳ 미판정 [title] | 엔티티의 생성과 삭제, 유효성 체크 [question] | OnUpdate 함수 내에서 생성된 엔티티의 유효성을 체크하는 패턴을 어떻게 적용해야 하나요? [answer] | `OnUpdate` 함수 내에서 생성된 엔티티의 유효성을 체크하는 패턴은 매 프레임마다 실행되는 코드가 삭제된 엔티티를 참조하여 에러가 발생하지 않도록 방지하기 위해 사용됩니다. `OnUpdate` 시작 부분에 유효성 체크를 수행하여, 대상 엔티티가 `nil`이거나 삭제 대기 중이거나 이미 삭제된 상태(`false`)이면 즉시 함수를 종료(`return`)하는 것이 표준 패턴입니다. ### 유효성 체크 함수 엔티티의 유효성은 다음 두 가지 방법으로 체크할 수 있습니다. 두 방법은 동일한 기능을 수행합니다. 1. **글로벌 [followup] | self.SpawnedEntity가 nil이나 삭제된 경우를 방지하기 위해 OnUpdate 시작 부분에서 isvalid 체크를 수행하는 Lua 코드 구조와, 시간이 3초가 되었을 때 삭제 및 로그를 기록하는 전체 예제를 작성해 주세요. [followup_answer] | `self.SpawnedEntity`가 `nil`이거나 삭제된(삭제 대기 중 포함) 엔티티를 참조하여 에러가 발생하지 않도록 방지하기 위해, `OnUpdate` 함수의 시작 부분에 `isvalid` 체크를 수행하는 코드 구조와 3초 후 삭제 및 로그 기록하는 전체 예시는 다음과 같습니다. 참고 문서의 예제에 따르면, `isvalid` 체크는 글로벌 함수 `isvalid(entity)` 또는 `_EntityService:IsValid(entity)` 중 하나를 사용할 수 있으며, 두 방식 모두 동일한 결과를 반환합니다. ```lu [scores] | [judge_reason] | [source_doc] | | Parameter | Description | | :--: | ----------- | | entity | 유효성 체크 대상이 되는 엔티티를 넣어줍니다. | #### 반환 값 * 매개 변수로 넘겨진 엔티티가 존재하면 **true**를 반환합니다. * 엔티티가 nil이거나 삭제 대기 중, 또는 삭제된 엔티티라면 **false**를 반환합니다. #### 사용 예시 위 `Destroy` 함수 예제에 이어서 엔티티 삭제 전후로 `isvalid` 함수가 어떤 값을 반환하는지 확인하고 실제 사용법을 살펴봅니다. 1. **Spawn

[task] | code [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | UserService의 HandleUserEnterEvent를 통해 유저가 입장했을 때, 확장 모델로 생성된 스폰 객체를 SpawnService로 배치하는 스크립트를 작성해줘 [answer] | 참고 문서에 **`_SpawnService:SpawnByModelId`** API의 존재와 사용 예시는 포함되어 있지 않습니다. 문서에는 모델 확장(Extend)의 개념과 방법, 모델 계층 구조 확인 방법은 설명되어 있지만, 런타임에 확장된 모델을 월드에 배치(Spawn)하는 구체적인 스크립트 API는 언급되어 있지 않습니다. 따라서 문서에 근거하여 확장 모델을 SpawnService로 배치하는 정확한 코드를 작성할 수 없습니다. 참고로, 문서에서 확인할 수 있는 정보는 다음과 같습니다. 1. **모델 확장**: Workspac [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 이번 과정에서는 모델 확장과 모델 생성 방법, 그리고 모델 프로퍼티의 편집 방법을 알아봅니다. 본 과정을 진행하기 전에 [모델](https://mod-developers.nexon.com/docs?postId=55) 가이드를 먼저 살펴보면 도움이 됩니다. # 모델 확장 **모델**은 자신이 갖고 있던 속성, 즉 같은 컴포넌트와 프로퍼티 값을 물려받은 확장 모델을 생성할 수 있습니다. 얼핏 복사와 개념이 비슷한 것 같지만 복사와는 다릅니다. * **복사** * 원본 모델과 복사된 모델이 독립적으로 존

[task] | single_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | UI 엔티티를 모델로 만들어 다른 월드로 공유하려 할 때, 모델화할 수 없는 특정 UI 컴포넌트나 그룹이 존재하는지 그 예시를 알려주세요. [answer] | UI 엔티티를 모델로 만들 때 모델화가 불가능한 특정 대상은 다음과 같습니다. 1. **모든 UIGroup 엔티티**: `UIGroup` 타입의 엔티티는 모델화할 수 없습니다. 2. **Default Group 내 Native 상태의 UIChat과 UIJoystick**: 기본 그룹(Default Group)에 포함되어 있고, Native 상태로 구현된 `UIChat` 및 `UIJoystick`은 모델화할 수 없습니다. 또한, 생성된 모델이 `Extension Info`에서 `Break` 상태가 되는 등 일부 확장 불가능한 모델 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 엔티티를 생성할 때는 주로 **Preset List**의 모델을 활용합니다. **Preset List**의 모델은 기본적으로 **NativeModel**의 특성을 물려받습니다. 그래서 **Preset List**의 모델 속성을 변경하려면 **NativeModel**을 수정해야 합니다. 하지만 **NativeModel**의 속성을 변경하면 해당 **NativeModel**에서 확장된 **Preset List**의 모델 속성이 모두 변경되어 버립니다. 작업 과정에서 원래 모델의 특성이 필요할 때는 또다시 수정해야 하므로 불편합니다.

[task] | single_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | 신규 모델을 생성한 후 바로 엔티티로 배치하려고 해도 아무것도 보이지 않는 이유는 무엇이며, 월드 엔티티와 UI 엔티티 각각에 반드시 추가해야 하는 기본 컴포넌트는 어떤 것들인가요? [answer] | 신규 모델을 생성한 직후에는 아무 컴포넌트도 포함되어 있지 않기 때문에, 이 모델을 엔티티로 배치해도 시각적으로 아무것도 보이지 않습니다. 모델을 실제로 활용할 수 있도록 만들기 위해서는 용도에 맞는 기본 컴포넌트를 반드시 추가해야 합니다. 월드 엔티티와 UI 엔티티에 각각 추가해야 하는 기본 컴포넌트는 다음과 같습니다. * **월드 엔티티** * `TransformComponent` * `SpriteRendererComponent` * **UI 엔티티** * `UITransformComp [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 엔티티를 생성할 때는 주로 **Preset List**의 모델을 활용합니다. **Preset List**의 모델은 기본적으로 **NativeModel**의 특성을 물려받습니다. 그래서 **Preset List**의 모델 속성을 변경하려면 **NativeModel**을 수정해야 합니다. 하지만 **NativeModel**의 속성을 변경하면 해당 **NativeModel**에서 확장된 **Preset List**의 모델 속성이 모두 변경되어 버립니다. 작업 과정에서 원래 모델의 특성이 필요할 때는 또다시 수정해야 하므로 불편합니다.

[task] | instruction_following [pass] | ⏳ 미판정 [title] | 제작 가이드 활용법 [question] | 응용 제작 가이드의 '게임 시스템 따라 만들기' 카테고리에 포함된 모든 항목을 3문장 이내로 요약하세요. [answer] | 응용 제작 가이드의 '게임 시스템 따라 만들기' 카테고리에는 UI에서 아바타 애니메이션 재생하기, 원거리 발사체로 몬스터 처치하기, 상점과 인벤토리라는 세 가지 항목이 포함되어 있습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 메이플스토리 월드에서는 다양한 형식의 가이드를 제공하고 있습니다. 메이플스토리 월드가 생소한 크리에이터라면 기본 **제작 가이드 - 시작하기 - [메이커 사용](/docs?postId=724)을** 먼저 살펴보며 기본 기능 익히기를 권장합니다. # 난이도 가이드를 살펴보기 전, 학습권장대상 배지를 확인하고 나에게 적절한 난이도인지 확인할 수 있습니다. * **Lv.1**: 메이커의 기본 기능과 컴포넌트의 기본 기능을 사용하고 싶은 크리에이터 * **Lv.2**: MSW의 기본 문법을 알고, 간단한 동작을 직접 만들 수 있는

[task] | two_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | UI 엔티티를 모델로 만들 때 적용되는 제약 사항과 모델화 시 주의할 점에 대해 알려 주세요. [answer] | UI 엔티티를 모델로 만들 때 적용되는 제약 사항과 주의할 점은 다음과 같습니다. **1. 모델화 불가능한 대상** * **모든 `UIGroup` 엔티티**: `UIGroup` 타입의 엔티티는 모델화할 수 없습니다. * **기본(Native) 상태의 특정 UI**: `Default Group` 안에 있는 `Native` 상태로 구현된 `UIChat`과 `UIJoystick`은 모델화할 수 없습니다. **2. 모델 확장 기능 관련 주의점** * **확장 불가능한 모델**: `Extension Info`에서 `Break` [followup] | UI 엔티티 모델화를 통해 MSW 패키지에 포함할 때의 이점과, 모델 확장 기능이 사용 불가능한 경우의 예시를 구체적으로 설명해 주세요? [followup_answer] | UI 엔티티를 모델화하여 MSW 패키지에 포함할 때의 이점과 모델 확장 기능이 사용 불가능한 경우의 예시는 다음과 같습니다. **1. UI 엔티티 모델화 후 MSW 패키지 포함 시 이점** * **다른 월드로의 이동 및 재사용 용이**: UI를 모델화하면 이를 MSW 패키지에 포함할 수 있습니다. 이를 통해 제작한 UI를 다른 월드 프로젝트로 쉽게 옮기거나 재사용할 수 있습니다. **2. 모델 확장 기능이 사용 불가능한 경우의 예시** * **`Extension Info`에서 `Break` 상태인 모델**: 모델의 `Ex [scores] | [judge_reason] | [source_doc] | 엔티티를 생성할 때는 주로 **Preset List**의 모델을 활용합니다. **Preset List**의 모델은 기본적으로 **NativeModel**의 특성을 물려받습니다. 그래서 **Preset List**의 모델 속성을 변경하려면 **NativeModel**을 수정해야 합니다. 하지만 **NativeModel**의 속성을 변경하면 해당 **NativeModel**에서 확장된 **Preset List**의 모델 속성이 모두 변경되어 버립니다. 작업 과정에서 원래 모델의 특성이 필요할 때는 또다시 수정해야 하므로 불편합니다.

[task] | instruction_following [pass] | ⏳ 미판정 [title] | 제작 가이드 활용법 [question] | 기본 제작 가이드 중 '스크립트' 섹션에 해당하는 문서 제목들을 단계별 번호 목록으로 나열하세요. [answer] | 기본 제작 가이드의 '스크립트' 섹션에 포함된 문서 제목은 다음과 같습니다. 1. 스크립트 에디터 오리엔테이션 2. 프로퍼티 3. 프로퍼티 동기화 4. 실행제어 5. 함수 6. MSW 기본 이벤트 함수 7. 메이플스토리 월드 루아 기초 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 메이플스토리 월드에서는 다양한 형식의 가이드를 제공하고 있습니다. 메이플스토리 월드가 생소한 크리에이터라면 기본 **제작 가이드 - 시작하기 - [메이커 사용](/docs?postId=724)을** 먼저 살펴보며 기본 기능 익히기를 권장합니다. # 난이도 가이드를 살펴보기 전, 학습권장대상 배지를 확인하고 나에게 적절한 난이도인지 확인할 수 있습니다. * **Lv.1**: 메이커의 기본 기능과 컴포넌트의 기본 기능을 사용하고 싶은 크리에이터 * **Lv.2**: MSW의 기본 문법을 알고, 간단한 동작을 직접 만들 수 있는

[task] | code [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | OnBeginPlay 생명주기 메서드에서 TransformComponent와 SpriteRendererComponent가 포함된 월드 엔티티 모델을 Scene에 배치하기 위해 _SpawnService를 호출하는 스크립트를 작성해줘 [answer] | `OnBeginPlay` 생명주기 메서드에서 `_SpawnService:SpawnByModelId`를 호출하여 월드 엔티티 모델을 Scene에 배치하는 스크립트는 다음과 같습니다. 모델 ID는 실제 프로젝트에서 사용하려는 모델의 Entry ID로 대체해야 합니다. ```lua Property: [None] string TargetModelId = "Your_Model_Entry_ID_Here" Vector3 SpawnPosition = Vector3(0, 0, 0) Method: [server only] void OnBegin [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 엔티티를 생성할 때는 주로 **Preset List**의 모델을 활용합니다. **Preset List**의 모델은 기본적으로 **NativeModel**의 특성을 물려받습니다. 그래서 **Preset List**의 모델 속성을 변경하려면 **NativeModel**을 수정해야 합니다. 하지만 **NativeModel**의 속성을 변경하면 해당 **NativeModel**에서 확장된 **Preset List**의 모델 속성이 모두 변경되어 버립니다. 작업 과정에서 원래 모델의 특성이 필요할 때는 또다시 수정해야 하므로 불편합니다.

[task] | code [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | SpawnService를 사용하여 확장된 모델 ID로 엔티티를 생성하고, 생성된 엔티티의 TransformComponent.Position을 수정하는 스크립트를 작성해줘 [answer] | mLua에서 `_SpawnService:SpawnByModelId`를 사용하여 확장된 모델 ID로 엔티티를 생성한 후, 반환된 엔티티 객체의 `TransformComponent.Position` 프로퍼티를 직접 할당하여 위치를 수정하는 방법은 다음과 같습니다. ```lua Property: [None] number ModelId = 0 Vector3 SpawnPosition = Vector3(0, 0, 0) Vector3 NewPosition = Vector3(10, 5, 20) Method: [server only] void [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 이번 과정에서는 모델 확장과 모델 생성 방법, 그리고 모델 프로퍼티의 편집 방법을 알아봅니다. 본 과정을 진행하기 전에 [모델](https://mod-developers.nexon.com/docs?postId=55) 가이드를 먼저 살펴보면 도움이 됩니다. # 모델 확장 **모델**은 자신이 갖고 있던 속성, 즉 같은 컴포넌트와 프로퍼티 값을 물려받은 확장 모델을 생성할 수 있습니다. 얼핏 복사와 개념이 비슷한 것 같지만 복사와는 다릅니다. * **복사** * 원본 모델과 복사된 모델이 독립적으로 존

[task] | two_turn [pass] | ⏳ 미판정 [title] | Hierarchy [question] | UI를 제작할 때 확인 메시지 창처럼 배경을 부모로, 버튼과 텍스트를 자식으로 구성하는 계층 구조를 활용하는 방식이 좋습니다. [answer] | 네, 맞습니다. 확인 메시지 창과 같은 UI를 제작할 때 배경을 부모 엔티티로, 버튼 배경과 텍스트를 자식 엔티티로 구성하는 것이 좋습니다. 이렇게 부모-자식 구조를 만들면 다음과 같은 장점이 있습니다: 1. **독립적 관리**: 하나의 버튼 위치를 변경하거나 외형을 수정할 때, 같은 메시지 창 안에 있는 다른 엔티티(예: 다른 버튼이나 텍스트)에는 영향을 주지 않습니다. 2. **체계적 관리**: 복잡한 UI 요소들을 논리적인 그룹으로 묶어 관리하기 쉽습니다. 메이플스토리 월드에서 이 구조는 **Hierarchy** 탭을 [followup] | 여러 개의 버튼과 텍스트가 포함된 복잡한 UI에서, 특정 버튼 하나만 다른 위치로 이동시키거나 형태를 변경할 때 다른 UI 요소들이 영향을 받지 않도록 Hierarchy를 어떻게 구성해야 하는지 코드 또는 구조 예시를 보여주세요. [followup_answer] | 복잡한 UI에서 특정 버튼 하나만 이동하거나 형태를 변경할 때 다른 요소에 영향을 미치지 않으려면, 각 UI 요소를 **독립적인 부모-자식 그룹**으로 분리하여 구성해야 합니다. ### Hierarchy 구조 예시 메이플스토리 월드의 **Hierarchy** 탭에서 UI 엔티티는 `World/ui` 하위에 위치합니다. 확인 메시지 창을 예로 들면, 전체 배경을 최상위 부모로 두고, 각 버튼과 텍스트를 그 자식으로 구성하되, **각 버튼 자체도 별도의 부모-자식 구조**를 가질 수 있습니다. ``` World └── ui [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 **Hierarchy** 탭을 이용해 제작 현황을 확인하고, 제작 능률을 높일 수 있습니다. # Hierarchy 소개 **Hierarchy** 탭은 제작 중인 게임 현황을 **계층 구조(부모-자식)**로 볼 수 있는 패널입니다. 복잡하게 구성한 맵에서 원하는 엔티티를 빠르게 찾을 때 사용하거나, 체계적으로 엔티티를 관리할 때 사용합니다. 가장 상위인 **World** 계층 아래에 **common**, **maps**, **ui** 엔트리가 있으며 **maps**와 **ui** 엔트리는 각자 기본 하위 엔트

[task] | single_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | 모델 프로퍼티의 Scale 값을 변경하면 TransformComponent의 Scale도 함께 바뀐다는 설명이 있는데, 이 투영 관계가 양방향으로 작동하는지 궁금합니다. [answer] | 제공된 문서에는 모델 프로퍼티의 값이 변경되면 이에 해당하는 컴포넌트(예: `TransformComponent`)의 프로퍼티 값도 함께 변경된다는 내용만 명시되어 있습니다. 문서에는 컴포넌트 프로퍼티를 직접 변경했을 때 모델 프로퍼티가 자동으로 함께 변경되는지(역방향 투영)에 대한 설명이 없습니다. 따라서 주어진 정보만으로는 이 투영 관계가 양방향으로 작동하는지 확인이 불가능합니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 모델을 통해 엔티티를 생성할 수 있으며, **Preset List**에서 제공하는 **Preset**도 결국 모델이라는 것을 [Model](/docs?postId=55) 가이드를 통해 배웠습니다. **Preset List**의 모델은 **NativeModel**에서 확장되었기 때문에 **Preset List** 카테고리 단위로 **NativeModel**의 속성을 물려받습니다. 따라서 각 카테고리에 해당하는 **NativeModel**을 변경하면 **Preset List**의 모델에도 변화가 생깁니다. 예를 들어 **Preset

[task] | single_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | 모델 프로퍼티 편집 모드에서 특정 프로퍼티를 체크 해제하면 해당 값이 초기화되나요, 아니면 그냥 표시만 사라지나요? [answer] | 제공된 문서에는 모델 프로퍼티 편집 모드에서 체크를 해제했을 때 해당 프로퍼티의 값이 초기화되는지, 아니면 단순히 모델 프로퍼티 목록에서 표시가 사라지는지에 대한 정보가 포함되어 있지 않습니다. 문서에는 체크박스를 통해 특정 프로퍼티를 모델 프로퍼티로 '지정'할 수 있다는 내용과, 모델 프로퍼티가 컴포넌트의 프로퍼티가 투영된 것이므로 모델 프로퍼티 값을 변경하면 컴포넌트 프로퍼티 값도 함께 변경된다는 내용만 설명하고 있습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 모델을 통해 엔티티를 생성할 수 있으며, **Preset List**에서 제공하는 **Preset**도 결국 모델이라는 것을 [Model](/docs?postId=55) 가이드를 통해 배웠습니다. **Preset List**의 모델은 **NativeModel**에서 확장되었기 때문에 **Preset List** 카테고리 단위로 **NativeModel**의 속성을 물려받습니다. 따라서 각 카테고리에 해당하는 **NativeModel**을 변경하면 **Preset List**의 모델에도 변화가 생깁니다. 예를 들어 **Preset

[task] | two_turn [pass] | ⏳ 미판정 [title] | Hierarchy [question] | Hierarchy 탭의 기본 계층 구조(World, common, maps, ui)와 각 엔트리의 역할이 궁금합니다. [answer] | 메이플스토리 월드의 **Hierarchy** 탭은 제작 중인 게임을 부모-자식 관계의 계층 구조로 보여주는 패널입니다. 가장 최상위에는 **World** 엔트리가 위치하며, 그 아래에 **common**, **maps**, **ui**라는 세 가지 기본 하위 엔트리가 존재합니다. 각 엔트리의 구체적인 역할은 다음과 같습니다. * **World**: 실제로 게임 제작에 사용된 모든 엔티티가 모여 있는 가장 상위 계층입니다. 이 엔트리를 통해 제작 중인 게임의 전체 구성 방식을 확인하고 수정할 수 있습니다. * **common [followup] | maps 하위의 map01 엔트리와 ui 하위의 DefaultGroup, PopupGroup, ToastGroup 기본 하위 엔트리 각각에 어떤 엔티티들을 배치하는 것이 적절한가요? [followup_answer] | 제공된 참고 문서에는 `map01`, `DefaultGroup`, `PopupGroup`, `ToastGroup` 엔트리에 구체적으로 어떤 유형의 엔티티를 배치해야 하는지에 대한 지침이나 예시가 포함되어 있지 않습니다. 문서에서는 해당 엔트리들이 각각의 기본 하위 엔트리로서 존재한다는 사실과, `maps` 엔트리는 "맵에 배치한 엔티티"가 위치하며, `ui` 엔트리는 "UI 편집기에서 추가하는 엔티티"가 위치한다는 범위 설명만 제공하고 있을 뿐입니다. 따라서 각 기본 하위 엔트리(`map01`, `DefaultGroup` 등)에 [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 **Hierarchy** 탭을 이용해 제작 현황을 확인하고, 제작 능률을 높일 수 있습니다. # Hierarchy 소개 **Hierarchy** 탭은 제작 중인 게임 현황을 **계층 구조(부모-자식)**로 볼 수 있는 패널입니다. 복잡하게 구성한 맵에서 원하는 엔티티를 빠르게 찾을 때 사용하거나, 체계적으로 엔티티를 관리할 때 사용합니다. 가장 상위인 **World** 계층 아래에 **common**, **maps**, **ui** 엔트리가 있으며 **maps**와 **ui** 엔트리는 각자 기본 하위 엔트

[task] | code [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | OnBeginPlay 생명주기 메서드에서 UITransformComponent와 SpriteGUIRendererComponent가 포함된 UI 엔티티 모델을 생성하여 화면 중앙에 배치하는 스크립트를 작성해줘 [answer] | `OnBeginPlay`에서 UI 엔티티 모델을 생성하여 화면 중앙에 배치하는 스크립트는 제공된 참고 문서에 포함된 API 및 메서드 정보만으로 작성할 수 없습니다. 참고 문서에는 **UI 엔티티 모델**을 생성하는 방법(Workspace에서 Create Model 또는 Scene의 엔티티에서 Create Model From Entity)과, 모델에 필요한 기본 컴포넌트(`UITransformComponent`, `SpriteGUIRendererComponent`)가 언급되어 있습니다. 또한 `_EntityService:GetEn [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 엔티티를 생성할 때는 주로 **Preset List**의 모델을 활용합니다. **Preset List**의 모델은 기본적으로 **NativeModel**의 특성을 물려받습니다. 그래서 **Preset List**의 모델 속성을 변경하려면 **NativeModel**을 수정해야 합니다. 하지만 **NativeModel**의 속성을 변경하면 해당 **NativeModel**에서 확장된 **Preset List**의 모델 속성이 모두 변경되어 버립니다. 작업 과정에서 원래 모델의 특성이 필요할 때는 또다시 수정해야 하므로 불편합니다.

[task] | code [pass] | ⏳ 미판정 [title] | Hierarchy [question] | `ui` 엔트리 하위의 `DefaultGroup`과 `PopupGroup` 엔티티를 `_EntityService:GetEntityByPath`로 각각 조회하고, 두 그룹의 존재 여부를 확인하여 로그에 출력하는 스크립트를 작성해줘 [answer] | `_EntityService:GetEntityByPath`를 사용해 `ui` 엔트리 하위의 `DefaultGroup`과 `PopupGroup` 경로를 조회하고, 반환된 엔티티가 `nil`인지 확인하여 존재 여부를 로그로 출력하는 스크립트입니다. ```lua Method: [server only] void OnBeginPlay() { local defaultGroup = _EntityService:GetEntityByPath("/ui/DefaultGroup") if defaultGroup == nil then [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 **Hierarchy** 탭을 이용해 제작 현황을 확인하고, 제작 능률을 높일 수 있습니다. # Hierarchy 소개 **Hierarchy** 탭은 제작 중인 게임 현황을 **계층 구조(부모-자식)**로 볼 수 있는 패널입니다. 복잡하게 구성한 맵에서 원하는 엔티티를 빠르게 찾을 때 사용하거나, 체계적으로 엔티티를 관리할 때 사용합니다. 가장 상위인 **World** 계층 아래에 **common**, **maps**, **ui** 엔트리가 있으며 **maps**와 **ui** 엔트리는 각자 기본 하위 엔트

[task] | two_turn [pass] | ⏳ 미판정 [title] | Hierarchy [question] | 드래그 앤 드롭으로 만든 부모-자식 구조에서 부모 엔티티의 TransformComponent를 변경했을 때 자식 엔티티에 미치는 영향과, 그 반대(자식 [answer] | 드래그 앤 드롭을 통해 만든 부모-자식 구조에서 **부모 엔티티의 `TransformComponent`를 변경하면 자식 엔티티는 자동으로 해당 변경 사항의 영향을 받습니다.** 반면, **자식 엔티티의 `TransformComponent`를 변경하더라도 부모 엔티티에는 어떠한 영향도 미치지 않습니다.** 이는 부모-자식 관계가 **단방향(부모 → 자식)**으로만 영향을 끼치기 때문입니다. 즉, 상위 계층(부모)의 상태 변화는 하위 계층(자식)에 전파되지만, 하위 계층(자식)의 상태 변화는 상위 계층(부모)으로 역전파되지 않습니다 [followup] | 부모) 방향의 영향 관계가 어떻게 되는지 구체적으로 알고 싶습니다. → 부모 엔티티의 위치를 변경할 때 자식 엔티티가 절대 좌표가 아닌 상대 좌표로 이동하는지, 그리고 자식 엔티티를 선택해 이동할 때 상위 부모의 위치에는 아무런 영향이 없는지 확인하고 싶습니다. [followup_answer] | 참고 문서에 따르면, 부모-자식 구조의 영향 관계는 다음과 같이 설명됩니다. 1. **부모 위치 변경 시 자식의 이동 방식** 문서에는 "부모 엔티티의 **TransformComponent**를 변경하면 자식 엔티티는 **자동으로 변경**된다"고 명시되어 있습니다. 또한 "Box1(부모)을 선택해 나머지 오브젝트(자식)까지 **한꺼번에 움직인다**"는 예시를 통해, 부모의 변환(Transform) 변경이 자식에 전파됨을 확인할 수 있습니다. 그러나 문서에는 자식이 **절대 좌표**인지 **상대 좌표**인지에 대한 [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 **Hierarchy** 탭을 이용해 제작 현황을 확인하고, 제작 능률을 높일 수 있습니다. # Hierarchy 소개 **Hierarchy** 탭은 제작 중인 게임 현황을 **계층 구조(부모-자식)**로 볼 수 있는 패널입니다. 복잡하게 구성한 맵에서 원하는 엔티티를 빠르게 찾을 때 사용하거나, 체계적으로 엔티티를 관리할 때 사용합니다. 가장 상위인 **World** 계층 아래에 **common**, **maps**, **ui** 엔트리가 있으며 **maps**와 **ui** 엔트리는 각자 기본 하위 엔트

[task] | instruction_following [pass] | ⏳ 미판정 [title] | 인내의 숲 만들기 [question] | 원숭이 함정의 방향을 변경하기 위해 프로퍼티 에디터에서 체크해야 하는 정확한 컴포넌트 경로와 프로퍼티 이름을 3문장 이내로 서술하세요. [answer] | 원숭이 함정의 방향을 변경하려면 프로퍼티 에디터에서 SpriteRendererComponent 컴포넌트를 선택해야 합니다. 해당 컴포넌트 아래에 있는 FlipX 프로퍼티를 찾아 체크박스를 클릭합니다. 이를 통해 원숭이가 바나나를 던지는 방향이 오른쪽에서 왼쪽으로 바뀌도록 설정할 수 있습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 이번에는 캐릭터를 공격하는 함정을 곳곳에 설치하여 게임의 난이도를 올려보겠습니다. 1. **Preset List - Trap**에서 원숭이 함정을 선택합니다. 이 함정은 바나나를 던져 캐릭터를 공격합니다. 맵 곳곳에 추가 타일과 원숭이 함정을 배치합니다. 2. 원숭이 함정은 기본적으로 오른쪽에서 왼쪽으로 바나나를 던지기 때문에, 캐릭터의 오른쪽에 오도록 배치할 수밖에 없습니다. 바나나를 왼쪽에서 오른쪽으로 던지도록 수정해 봅시다. 원숭이 함정을 다음과 같이 왼쪽에 배치합니다. 원숭이 함정을 선택하고 **프로퍼티 에디터

[task] | single_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | Object 모델을 2배 크게 생성하기 위해 MapObject 모델의 Scale을 2로 설정하면, 이미 생성된 엔티티에도 즉시 반영되나요? [answer] | 제공된 문서에는 모델 프로퍼티(예: Scale)의 값이 변경되면 해당 모델에 연결된 컴포넌트 프로퍼티의 값도 함께 변경된다고 설명하고 있습니다. 또한, Preset List의 모델은 NativeModel에서 확장되어 속성을 물려받으므로, NativeModel(예: MapObject)의 속성을 변경하면 Preset List의 모델에도 변화가 생긴다고 명시되어 있습니다. 그러나, **이미 생성된 엔티티에 즉시 반영되는지에 대한 구체적인 동작(즉시 반영 여부 또는 재생성 필요 여부)에 대한 설명은 문서에 포함되어 있지 않습니다.** 따 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 모델을 통해 엔티티를 생성할 수 있으며, **Preset List**에서 제공하는 **Preset**도 결국 모델이라는 것을 [Model](/docs?postId=55) 가이드를 통해 배웠습니다. **Preset List**의 모델은 **NativeModel**에서 확장되었기 때문에 **Preset List** 카테고리 단위로 **NativeModel**의 속성을 물려받습니다. 따라서 각 카테고리에 해당하는 **NativeModel**을 변경하면 **Preset List**의 모델에도 변화가 생깁니다. 예를 들어 **Preset

[task] | code [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | TimerService를 사용하여 5초 간격으로 모델의 프로퍼티 값을 변경하여 확장 모델의 물려받은 속성 변경 시나리오를 시뮬레이션하는 스크립트를 작성해줘 [answer] | 제시된 참고 문서에는 `TimerService`의 구체적 API(예: `SetTimerOnce`, `SetTimer`의 정확한 시그니처)나 모델 프로퍼티를 런타임에 동적으로 변경하는 mLua API가 포함되어 있지 않습니다. 또한, 확장 모델의 물려받은 속성이 기반 모델의 변경에 따라 실시간으로 어떻게 동기화되는지 시뮬레이션하는 구체적인 스크립트 메커니즘에 대한 설명도 문서에 없습니다. 문서에서 확인할 수 있는 사실은 다음과 같습니다: 1. **모델 확장**: 확장 모델은 기반 모델의 컴포넌트와 프로퍼티 초깃값을 물려받습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 이번 과정에서는 모델 확장과 모델 생성 방법, 그리고 모델 프로퍼티의 편집 방법을 알아봅니다. 본 과정을 진행하기 전에 [모델](https://mod-developers.nexon.com/docs?postId=55) 가이드를 먼저 살펴보면 도움이 됩니다. # 모델 확장 **모델**은 자신이 갖고 있던 속성, 즉 같은 컴포넌트와 프로퍼티 값을 물려받은 확장 모델을 생성할 수 있습니다. 얼핏 복사와 개념이 비슷한 것 같지만 복사와는 다릅니다. * **복사** * 원본 모델과 복사된 모델이 독립적으로 존

[task] | instruction_following [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | Preset List의 Object 카테고리가 NativeModel의 MapObject를 기반으로 한다는 점을 근거로, Object 모델을 2배 크기로 생성하기 위해 MapObject의 Scale 값을 어떻게 설정해야 하는지 2문장 이내로 설명하세요. [answer] | Preset List의 Object 카테고리는 NativeModel의 MapObject를 기반으로 하므로, Object 모델을 2배 크기로 생성하려면 MapObject 모델의 Scale 값을 2로 설정해야 합니다. 이렇게 설정하면 해당 카테고리 내 모델들이 물려받은 속성에 따라 생성되는 엔티티의 크기가 2배로 적용됩니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 모델을 통해 엔티티를 생성할 수 있으며, **Preset List**에서 제공하는 **Preset**도 결국 모델이라는 것을 [Model](/docs?postId=55) 가이드를 통해 배웠습니다. **Preset List**의 모델은 **NativeModel**에서 확장되었기 때문에 **Preset List** 카테고리 단위로 **NativeModel**의 속성을 물려받습니다. 따라서 각 카테고리에 해당하는 **NativeModel**을 변경하면 **Preset List**의 모델에도 변화가 생깁니다. 예를 들어 **Preset

[task] | two_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | Preset List 모델과 NativeModel의 관계 및 신규 모델 생성 방식에 대해 설명해 주세요. [answer] | **Preset List 모델과 NativeModel의 관계** 엔티티 생성 시 주로 **Preset List**의 모델을 활용하며, 이 모델들은 기본적으로 **NativeModel**의 특성을 물려받습니다. 따라서 **Preset List** 모델의 속성을 변경하려면 원본인 **NativeModel**을 수정해야 합니다. 단, **NativeModel**의 속성을 변경하면 해당 모델에서 확장된 모든 **Preset List** 모델의 속성도 함께 변경되므로, 작업 중 원래 모델의 특성이 필요할 때 다시 수정해야 하는 불편함이 있 [followup] | 신규 모델 생성 시 월드 엔티티와 UI 엔티티에 각각 추가해야 하는 기본 컴포넌트는 무엇이며, 이미 배치된 엔티티를 모델로 변환하는 방법은 무엇인가요? [followup_answer] | 신규 모델 생성 시 용도에 따라 추가해야 하는 기본 컴포넌트는 다음과 같습니다. * **월드 엔티티**: `TransformComponent`, `SpriteRendererComponent` * **UI 엔티티**: `UITransformComponent`, `SpriteGUIRendererComponent` 이미 **Scene**에 배치된 엔티티를 모델로 변환하는 방법은 다음과 같습니다. 1. 배치된 엔티티의 콘텍스트 메뉴를 엽니다. 2. **Create Model From Entity**를 클릭합니다. 이 방법 [scores] | [judge_reason] | [source_doc] | 엔티티를 생성할 때는 주로 **Preset List**의 모델을 활용합니다. **Preset List**의 모델은 기본적으로 **NativeModel**의 특성을 물려받습니다. 그래서 **Preset List**의 모델 속성을 변경하려면 **NativeModel**을 수정해야 합니다. 하지만 **NativeModel**의 속성을 변경하면 해당 **NativeModel**에서 확장된 **Preset List**의 모델 속성이 모두 변경되어 버립니다. 작업 과정에서 원래 모델의 특성이 필요할 때는 또다시 수정해야 하므로 불편합니다.

[task] | single_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | 모델 프로퍼티에 속하지 않는 컴포넌트 프로퍼티를 모델 프로퍼티로 추가하려면 어떤 순서로 메뉴를 진행해야 하나요? [answer] | 모델 프로퍼티에 속하지 않는 컴포넌트 프로퍼티를 모델 프로퍼티로 추가하려면 다음 순서로 진행합니다. 1. 편집하고자 하는 모델을 선택합니다. 2. 모델 프로퍼티 상단의 **≡** 버튼을 클릭합니다. 3. 메뉴에서 **View Model Property**를 선택하여 모델 프로퍼티 편집 모드로 전환합니다. 4. 추가하고 싶은 프로퍼티 우측의 체크박스에 체크합니다. 5. 모델 설정 메뉴에서 **View Component Property**를 선택하여 체크한 프로퍼티가 모델 프로퍼티에 표시되는지 확인합니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 모델을 통해 엔티티를 생성할 수 있으며, **Preset List**에서 제공하는 **Preset**도 결국 모델이라는 것을 [Model](/docs?postId=55) 가이드를 통해 배웠습니다. **Preset List**의 모델은 **NativeModel**에서 확장되었기 때문에 **Preset List** 카테고리 단위로 **NativeModel**의 속성을 물려받습니다. 따라서 각 카테고리에 해당하는 **NativeModel**을 변경하면 **Preset List**의 모델에도 변화가 생깁니다. 예를 들어 **Preset

[task] | code [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | _SpawnService:SpawnByModelId 메서드를 사용하여 Preset List의 모델 ID를 전달받아 특정 좌표에 월드 엔티티를 생성하는 스크립트를 작성해줘 [answer] | `_SpawnService:SpawnByModelId` 메서드를 사용하여 Preset List의 모델 ID를 전달받아 특정 좌표에 월드 엔티티를 생성하는 스크립트 예시는 다음과 같습니다. ```lua Method: [server only] void SpawnWorldEntity() { -- Preset List에서 복사한 모델 ID를 사용합니다. local modelId = "PresetListModelId" -- 생성할 위치를 Vector3으로 정의합니다. local spawnPosition [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 엔티티를 생성할 때는 주로 **Preset List**의 모델을 활용합니다. **Preset List**의 모델은 기본적으로 **NativeModel**의 특성을 물려받습니다. 그래서 **Preset List**의 모델 속성을 변경하려면 **NativeModel**을 수정해야 합니다. 하지만 **NativeModel**의 속성을 변경하면 해당 **NativeModel**에서 확장된 **Preset List**의 모델 속성이 모두 변경되어 버립니다. 작업 과정에서 원래 모델의 특성이 필요할 때는 또다시 수정해야 하므로 불편합니다.

[task] | instruction_following [pass] | ⏳ 미판정 [title] | 인내의 숲 만들기 [question] | 게임 출시 시 설정할 수 있는 정보 항목들을 단계별 번호 목록으로 나열하되, 각 단계에 해당하는 UI 버튼명이나 메뉴 경로를 포함하세요. [answer] | 게임 출시 시 설정할 수 있는 정보 항목과 단계별 절차는 다음과 같습니다. 1. **File** 메뉴에서 **Release**를 선택합니다. 2. **Release** 창에서 출시할 게임의 정보와 섬네일 이미지를 등록합니다. 3. 게임에 참여 가능한 인원, 공개 여부, 플레이 가능 기기, 섬네일 이미지를 설정합니다. 4. 게임의 정보를 효과적으로 전달하기 위한 설명을 기재합니다. 5. 게임 제목을 최종 검토합니다. 6. **[출시]** 버튼을 누릅니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 이번에는 캐릭터를 공격하는 함정을 곳곳에 설치하여 게임의 난이도를 올려보겠습니다. 1. **Preset List - Trap**에서 원숭이 함정을 선택합니다. 이 함정은 바나나를 던져 캐릭터를 공격합니다. 맵 곳곳에 추가 타일과 원숭이 함정을 배치합니다. 2. 원숭이 함정은 기본적으로 오른쪽에서 왼쪽으로 바나나를 던지기 때문에, 캐릭터의 오른쪽에 오도록 배치할 수밖에 없습니다. 바나나를 왼쪽에서 오른쪽으로 던지도록 수정해 봅시다. 원숭이 함정을 다음과 같이 왼쪽에 배치합니다. 원숭이 함정을 선택하고 **프로퍼티 에디터

[task] | instruction_following [pass] | ⏳ 미판정 [title] | 원하는 이펙트 찾기 [question] | 스킬 고유 명칭으로 리소스를 찾을 때 애니메이션 카테고리보다 스프라이트 카테고리 검색이 어려운 이유와 추천하는 대안을 3문장 이내로 설명하세요. [answer] | 스프라이트 카테고리는 애니메이션 카테고리보다 검색 결과가 훨씬 많아 원하는 리소스를 특정하기 어렵습니다. 따라서 스프라이트를 바로 검색하기보다는 스킬 고유 명칭으로 애니메이션을 먼저 찾아 검색 범위를 좁히는 것이 좋습니다. 이후 애니메이션 상세 보기에서 확인한 고유 ID 태그를 활용해 2차 검색을 수행하면 수월하게 원하는 리소스를 찾을 수 있습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 리소스 검색 리소스 검색은 현재 웹과 메이커에서 이용할 수 있습니다. * [MSW 리소스](https://maplestoryworlds.nexon.com/resource) * 메이커의 **Resource Storage** 패널 # 스킬 고유 명칭으로 리소스 찾기 제작 리소스 조회 페이지에서는 여러 태그를 제공하고 있지만 아직 정확도가 높지 않습니다. 검색 시 가장 정확도가 높은 키워드는 **스킬의 고유 명칭**입니다. 예로 스킬 고유 명칭인 **워리어리프**로 검색하면 원하는 검색 결과를 확인하실 수 있습니다.

[task] | two_turn [pass] | ⏳ 미판정 [title] | Hierarchy [question] | Hierarchy의 상위 엔트리(World, common, maps, map01, ui) 각각에서 활성화되는 콘텍스트 메뉴의 차이점을 요약해 주세요. [answer] | Hierarchy의 상위 엔트리별 콘텍스트 메뉴는 엔트리의 역할과 구조에 따라 다음과 같이 차이가 있습니다. **공통 메뉴** 모든 상위 엔트리(World, common, maps, map01, ui)에서 사용할 수 있는 기본 메뉴는 다음과 같습니다. * **Create Entity**: 새로운 엔티티를 생성합니다. * **Create Entity as Child**: 하위에 새로운 엔티티를 생성합니다. * **Property**: 해당 엔트리의 프로퍼티 에디터 창을 엽니다. * **Go To Entity**: 선택 [followup] | map01 엔트리에서만 사용할 수 있는 'Switch To RectTileMap'과 'Duplicate' 메뉴는 어떤 상황에서 주로 사용되나요? [followup_answer] | 제공된 참고 문서에는 `Switch To RectTileMap`과 `Duplicate` 메뉴의 기능 설명(각각 RectTileMap으로 전환, 맵을 복사)만 기재되어 있으며, **주된 사용 상황이나 구체적인 사용 시나리오에 대한 정보는 포함되어 있지 않습니다.** 따라서 문서 근거만으로 이 메뉴들이 어떤 상황에서 주로 사용되는지에 대해 답변드릴 수 없습니다. [scores] | [judge_reason] | [source_doc] | 검색 창은 탭 타이틀 바로 아래에 위치합니다. 검색 기준에 따라 다른 결괏값이 나오기에 필요에 따라 선택해 검색합니다.검색 기준은 **Name**과 **Component** 두 가지이며, 다음과 같이 사용합니다. * **Name** : **Workspace**의 전 영역에서 검색한 이름과 맞는 값을 찾을 때 사용합니다. * **Component** : 엔티티 중 검색어에 해당하는 컴포넌트가 포함된 값을 찾을 때 사용합니다. | Name "chat" 검색 | Component "chat" 검색 | | -------------- |

[task] | single_turn [pass] | ⏳ 미판정 [title] | 모델의 활용 [question] | Preset List의 모델이 NativeModel에서 확장된다는 것은 정확히 어떤 의미이며, Preset List에서 직접 속성을 바꾸면 안 되는 이유는 무엇인가요? [answer] | **Preset List 모델과 NativeModel의 관계** Preset List에서 제공하는 Preset 모델은 기본적으로 **NativeModel**에서 확장된 구조를 가지고 있습니다. 이는 Preset List의 각 카테고리가 특정 NativeModel을 기반으로 생성되며, 해당 NativeModel이 가진 속성(프로퍼티)을 물려받는다는 의미입니다. 구체적인 예를 들면, `Preset List - Object` 카테고리의 모델들은 `NativeModel - MapObject`를 기반으로 합니다. 따라서 `NativeMo [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 모델을 통해 엔티티를 생성할 수 있으며, **Preset List**에서 제공하는 **Preset**도 결국 모델이라는 것을 [Model](/docs?postId=55) 가이드를 통해 배웠습니다. **Preset List**의 모델은 **NativeModel**에서 확장되었기 때문에 **Preset List** 카테고리 단위로 **NativeModel**의 속성을 물려받습니다. 따라서 각 카테고리에 해당하는 **NativeModel**을 변경하면 **Preset List**의 모델에도 변화가 생깁니다. 예를 들어 **Preset