← 목록

mLua · Nemotron-CC 리프레이즈 (CPT)

총 8,200개 · 페이지 160/274
🔀 랜덤
불러오는 중…

[task] | distill [title] | Effective MSW 2 [category] | Guides [rephrased] | # 실행 제어(Execution Control) 제한 사항 함수 실행 공간 설정을 통해 클라이언트-서버 통신을 자동화하지만, 특정 제약으로 인해 동작하지 않거나 에러가 발생할 수 있습니다. ## 1. 매개 변수 타입 제한 실행 제어 시 매개 변수는 **"전송 가능한 약속된 형태"**로 변환되어 전송됩니다. * **`number`, `string` 등**: 전송 가능합니다. * **`any`**: 전송 불가능합니다. 타입이 불확실하여 약속된 형태로 변환할 수 없으므로, 다른 공간의 함수에서 `any` 타입 인수를 전달하면 [original] | # 학습 과정 소개 함수의 실행 공간을 설정하면 별도의 과정 없이 쉽게 클라이언트와 서버가 통신할 수 있습니다. 자동으로 처리하기 때문에 편리하지만, 몇몇 경우는 제약이 있어 크리에이터가 원하는 대로 동작하지 않을 수 있습니다. 일부는 로그가 나오지만, 어떤 것은 동작하지 않는 이유를 확인할 수 없을 수도 있습니다. 이번 가이드에서는 실행 제어를 사용할 수 없는 경우를 알아봅시다. # 매개 변수가 지원하지 않는 종류 함수에는 여러 종류의 매개 변수(parameter)가 있습니다. 이 매개 변수는 다른 공간에서 실행 제어를 사용 [chunk_id] | Guides:560:0

[task] | knowledge_list [title] | Effective MSW 1 [category] | Guides [rephrased] | ```lua -- wait 함수는 호출된 코드의 실행을 지정된 시간만큼 일시정지 시킨 후, 직렬(Sequential) 흐름으로 다음 코드를 순차적으로 실행합니다. local function exampleWait() log("Start") wait(1) -- 1초 대기 log("End") -- 1초 후 실행 end ``` ```lua -- TimerService:SetTimerOnce 메서드는 주어진 함수를 지정된 시간 후에 한 번만 실행하도록 예약하며, 현재 코드의 흐름을 중단시키지 않고 병렬(Parallel [original] | `wait`는 대기한 뒤에 직접 어떤 행동을 수행하는 것이고, `TimerService`는 해당 행동을 수행하는 별도의 일을 만드는 것입니다. `wait`는 직렬, `TimerService`는 병렬 형태로 동작합니다. 따라서 `wait`의 사용 코드는 다음과 같이 표현할 수 있습니다 ```lua local targetEntity = _EntityService:GetEntity("a22396e1-6365-42d4-9cef-5924c223f7fa") targetEntity.TestComponent:ShowMessage() func [chunk_id] | Guides:559:2

[task] | distill [title] | Effective MSW 1 [category] | Guides [rephrased] | # 특정 클라이언트 대상 함수 호출 서버에서 **Client** 실행 공간의 함수를 모든 클라이언트가 아닌 **특정 클라이언트**에만 실행할 수 있습니다. 이는 요청(Request)-응답(Response) 처리 시 불필요한 네트워크 트래픽을 줄이고 월드 성능을 최적화하기 위한 기능입니다. ## 동작 규칙 1. **Client** 실행 공간의 함수를 서버에서 호출할 때, 마지막 매개변수로 대상 `UserId`를 전달하면 해당 유저의 클라이언트에만 함수가 전송됩니다. 2. 마지막 매개변수인 `targetUserId`는 시스템에 의해 [original] | 어떤 함수의 실행 제어 옵션이 **Client**로 설정되어 있다면 해당 함수는 모든 클라이언트에서 실행됩니다. 하지만 서버에서는 모든 클라이언트가 아니라 특정 클라이언트에만 함수를 실행하고 싶은 상황이 생길 수 있습니다. 특정 클라이언트가 서버에 어떤 요청(Request)을 보내고 서버가 로직을 처리한 이후, 해당 클라이언트에 응답(Response) 하는 상황이 그것입니다. 예를 들어 봅시다. 1. A 클라이언트에서 아이템 구매 버튼을 누른다면 : (Request) 2. 서버에서는 A가 가진 돈을 차감하고 아이템 개수를 늘린 다 [chunk_id] | Guides:559:4

[task] | extract_knowledge [title] | Effective MSW 1 [category] | Guides [rephrased] | # 1. 개념 설명 메이플스토리 월드(mLua) 환경에서 객체 참조와 비동기 처리 시 발생하는 문제를 해결하기 위한 두 가지 핵심 개념이 존재한다. 1. **객체 유효성 검사 (`isvalid`)**: 루아의 일반적인 `nil` 체크와 달리, mLua에서는 엔티티(Entity)나 컴포넌트(Component)의 삭제 과정이 즉시 완료되지 않는다. 삭제 요청부터 실제 메모리 해제(`nil` 상태)까지 여러 단계(삭제 처리 대기, 삭제 중, 삭제 완료)가 존재하므로, 단순한 `nil` 비교는 중간 상태의 객체를 참조하여 오류를 유발 [original] | # 학습 과정 소개 메이플스토리 월드는 쉬운 코딩을 위해 다양한 편의 기능을 지원하고 있습니다. 대표적으로 간편한 실행 제어 설정 기능이 있습니다. 그러나 간단한 설정이 얽히며 복잡해질 수 있고, 잘못 설정하면 원하는 기능이 제대로 실행되지 않을 수도 있습니다. 때로는 월드가 매우 느려질 수도 있습니다. 이런 문제는 월드의 규모가 작거나 월드 제작 초창기에는 발견하기 어렵습니다. 하지만 월드의 규모가 커지고 완성도가 높아질수록 문제가 될 수 있습니다. 그러므로 제작 초기부터 모든 동작이 원활하고 효율적으로 진행되도록 구조를 고민 [chunk_id] | Guides:559:0

[task] | knowledge_list [title] | Effective MSW 2 [category] | Guides [rephrased] | 제시된 문서의 내용을 바탕으로 핵심 사실을 추출하여 목록으로 정리했습니다. 1. 함수의 실행 공간을 설정하면 별도의 통신 과정 없이 자동으로 클라이언트와 서버 간 통신이 처리되지만, 특정 제약 상황에서는 크리에이터의 의도대로 동작하지 않거나 원인을 파악하기 어려운 로그 없이 실패할 수 있다. 2. 다른 공간에서 실행 제어 함수를 호출할 때 매개 변수(parameter)는 전송 가능한 약속된 형태로 변환되어 전송되어야 하며, `number`, `string` 등은 이 변환을 지원하지만 `any` 타입은 약속된 형태가 없어 전송할 [original] | # 학습 과정 소개 함수의 실행 공간을 설정하면 별도의 과정 없이 쉽게 클라이언트와 서버가 통신할 수 있습니다. 자동으로 처리하기 때문에 편리하지만, 몇몇 경우는 제약이 있어 크리에이터가 원하는 대로 동작하지 않을 수 있습니다. 일부는 로그가 나오지만, 어떤 것은 동작하지 않는 이유를 확인할 수 없을 수도 있습니다. 이번 가이드에서는 실행 제어를 사용할 수 없는 경우를 알아봅시다. # 매개 변수가 지원하지 않는 종류 함수에는 여러 종류의 매개 변수(parameter)가 있습니다. 이 매개 변수는 다른 공간에서 실행 제어를 사용 [chunk_id] | Guides:560:0

[task] | distill [title] | Effective MSW 2 [category] | Guides [rephrased] | **Local 처리 개요** 메이플스토리 월드는 기본적으로 멀티 플레이를 지원하지만, `UIEntity`, `입력 처리`, `내 캐릭터`는 **내 클라이언트에만 존재하는 개념**이므로 별도로 처리해야 합니다. 특히 내 캐릭터는 `_UserService.LocalPlayer`를 통해 식별합니다. **1. 입력 처리 (Input)** `Player` 엔티티는 모든 클라이언트에 존재하므로, 특정 키 입력 시 해당 입력이 '나'에게서 발생한 것인지 확인해야 합니다. 확인되지 않으면 로직을 중단(`return`)합니다. ```lua Ev [original] | 메이플스토리 월드에서는 기본적으로 멀티 플레이를 손쉽게 구현할 수 있습니다. 대부분의 기능을 멀티 플레이 기반으로 처리하는 것을 권장합니다. 하지만 일부 항목은 별도의 Local 개념이 필요합니다. 주요 항목은 다음과 같습니다. * Localized Entity * 입력 처리 * 내 캐릭터 처리 **UIEntity**와 **입력** 그리고 **내 캐릭터** 모두 **나의 클라이언트에만 존재하는 개념**이라 별도로 처리해야 합니다. 특히 **내 캐릭터**는 클라이언트에서 처리하기 위해 `_UserService.LocalPlay [chunk_id] | Guides:560:1

[task] | extract_knowledge [title] | Effective MSW 1 [category] | Guides [rephrased] | # OnUpdate() 내에서 wait() 사용의 문제점 및 주의사항 ## 개념 설명 `OnUpdate()`는 매 프레임마다 호출되는 함수로, 한 번의 실행이 종료되면 해당 프레임의 업데이트 처리가 완료되고 다음 프레임에서 새로운 `OnUpdate()`가 생성됩니다. `OnUpdate()` 내부에서 `wait()` 함수를 호출하면, 해당 코드의 실행은 즉시 중단되지 않고 지정된 시간만큼 대기 상태를 유지합니다. 그러나 mLua의 동작 원리에 따라, `OnUpdate()`가 정상적으로 종료되지 않고 `wait()`로 인해 매달려 [original] | 그럼 `OnUpdate()`에서 사용할 경우를 살펴보겠습니다. `OnUpdate()` 문에서 아래 코드는 어떻게 동작할까요? ```lua log("TEST") -- No.1 wait(1) log("TEST2") -- No.2 ``` * 기대 동작: TEST - 1초 대기 - TEST2 - TEST1 - 1초 대기 - TEST2 * 실제 동작: **TEST - TEST - TEST - .... (첫 번째 TEST가 찍힌 시점부터 1초가 지났을 때 ) - TEST2** `OnUpdate()`는 논리적인 측면에서 수행이 끝날 당시 [chunk_id] | Guides:559:3

[task] | extract_knowledge [title] | Effective MSW 1 [category] | Guides [rephrased] | # `wait()` 함수와 동기화 제어 ## 1. 개념 설명 `wait(seconds)`는 스크립트 실행을 지정된 시간만큼 일시 정지시키는 함수입니다. 이 함수는 현재 실행 컨텍스트에서 후속 코드가 즉시 실행되지 않도록 막아주며, 순차적 제어 흐름을 위해 사용됩니다. 하지만 `wait()`은 다음과 같은 심각한 부작용이 있어 과도한 사용이 권장되지 않습니다. 1. **유효성 보장 불가**: 대기 시간 동안 대상 엔티티(Entitiy)나 컴포넌트(Component)가 삭제될 수 있어, 대기 후 해당 객체에 접근 시 에러가 발생할 [original] | `wait()`는 보통 아래 예시 코드처럼 간단하게 사용합니다. ```lua _UIToast:ShowMessage("Show Message") wait(1) _UIToast:ShowMessage("Show Delay Message") ``` 하지만 `wait()`를 사용할 때는 주의해야 합니다. `wait()`는 말 그대로 행동을 '기다리고' 있기 때문에 여기저기에 마구 사용한다면 전체적인 흐름을 파악하기 어려워집니다. 또한, '대기'를 하므로 이후 작업이 진행되지 않는 문제도 있습니다. 아래 예시를 통해 '대기' 때문에 [chunk_id] | Guides:559:1

[task] | distill [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | **UI_Block_Group 구성** 경로: `/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Blocks/UI_Block_Group` `ScrollLayoutGroupComponent`를 사용하여 자식 UI Entity들의 배치 간격을 일괄 적용합니다. | 프로퍼티 | 값 | 설명 | | :--- | :--- | :--- | | Padding | top:15, right:0, left:0, bottom:0 | 상단 여유 공간 15 | | CellSize | 90, 90 | 카드 크기 90x90 | | [original] | 이제 카드를 화면에 불러낼 차례입니다. 카드를 불러내기 위해선 **/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Block_Group**를 활용합니다. **UI_Block_Group**은 [ScrollLayoutGroupComponent](/apiReference?postId=382%7B%22target%22:%22_self%22%7D)를 활용했습니다. **ScollLayoutGroupComponent**는 여러 개의 엔티티를 펼쳐야할 때 사용합니다. 주로 상점이나, 인벤토리처럼 한 눈에 봐야하는 이미지 [chunk_id] | Guides:561:1

[task] | distill [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | # CardPairGameUI 활성화 월드 로직(`CardPairGameLogic`)에서 유저 입장 시 UI를 활성화합니다. UI 엔티티의 `Enable` 프로퍼티를 `true`로 설정해야 화면에 표시됩니다. ```lua Property: [None] Entity CardPairGameUI = /ui/CardPairGameUI Method: [client only] void StartGame() { self.CardPairGameUI.Enable = true } [client only] void OnBeginPlay( [original] | 리메이크한 월드에는 제작에 필요한 UI, 리소스, 그리고 비어 있는 컴포넌트 등이 있습니다. 단계 별로 하나씩 채워나가며 함께 게임을 완성해봅시다. # CardPairGameUI 활성화 월드에 유저가 입장하면 **CardPairGameUI**가 **Enable**로 변경되도록 만들어 봅시다. 월드 전체에 적용되는 규칙이나 로직을 만들 때는 Logic을 사용합니다. **CardPairGameLogic** 로직에는 짝 맞추기에 기본적으로 필요한 UI를 켜거나 끄기, 카드 입력 등 전반적인 규칙을 작성할 것입니다. 우선 월드에 입장 [chunk_id] | Guides:561:0

[task] | knowledge_list [title] | Effective MSW 2 [category] | Guides [rephrased] | 제공된 문서의 내용을 바탕으로 핵심 사실을 정리한 목록입니다. 1. 메이플스토리 월드에서는 대부분의 기능을 멀티 플레이 기반으로 처리하는 것을 권장하며, 기본 구현 방식이 멀티 플레이에 최적화되어 있습니다. 2. **Localized Entity**, **입력 처리(Input)**, **내 캐릭터 처리**는 모든 클라이언트에 동기화되는 것이 아니라 '나의 클라이언트에만 존재하는 개념(Local)'이므로 별도 처리가 필요합니다. 3. `_UserService.LocalPlayer` API는 현재 스크립트가 실행되는 클라이언트에서 플 [original] | 메이플스토리 월드에서는 기본적으로 멀티 플레이를 손쉽게 구현할 수 있습니다. 대부분의 기능을 멀티 플레이 기반으로 처리하는 것을 권장합니다. 하지만 일부 항목은 별도의 Local 개념이 필요합니다. 주요 항목은 다음과 같습니다. * Localized Entity * 입력 처리 * 내 캐릭터 처리 **UIEntity**와 **입력** 그리고 **내 캐릭터** 모두 **나의 클라이언트에만 존재하는 개념**이라 별도로 처리해야 합니다. 특히 **내 캐릭터**는 클라이언트에서 처리하기 위해 `_UserService.LocalPlay [chunk_id] | Guides:560:1

[task] | diverse_qa [title] | Effective MSW 2 [category] | Guides [rephrased] | 질문: 함수의 실행 공간을 설정하면 클라이언트와 서버 간 통신을 위해 별도의 과정이 필요합니까? 답변: 아니요, 함수의 실행 공간을 설정하면 별도의 과정 없이 자동으로 통신이 처리되므로 쉽게 클라이언트와 서버가 통신할 수 있습니다. 질문: 실행 제어 함수 사용 시 매개 변수(parameter)는 어떤 형태로 변경된 후 전송되어야 합니까? 답변: 매개 변수는 "전송 가능"한 형태로 변경한 후 전송해야 하며, 이는 다른 공간에서 실행 제어를 사용할 때 함께 전송되기 때문입니다. 질문: `number`나 `string`과 같은 매개 [original] | # 학습 과정 소개 함수의 실행 공간을 설정하면 별도의 과정 없이 쉽게 클라이언트와 서버가 통신할 수 있습니다. 자동으로 처리하기 때문에 편리하지만, 몇몇 경우는 제약이 있어 크리에이터가 원하는 대로 동작하지 않을 수 있습니다. 일부는 로그가 나오지만, 어떤 것은 동작하지 않는 이유를 확인할 수 없을 수도 있습니다. 이번 가이드에서는 실행 제어를 사용할 수 없는 경우를 알아봅시다. # 매개 변수가 지원하지 않는 종류 함수에는 여러 종류의 매개 변수(parameter)가 있습니다. 이 매개 변수는 다른 공간에서 실행 제어를 사용 [chunk_id] | Guides:560:0

[task] | wikipedia [title] | Effective MSW 1 [category] | Guides [rephrased] | # 클라이언트 대상 함수 전송 (Targeted Client Function Call) 메이플스토리 월드(MapleStory Worlds)의 mLua 스크립트 언어에서 실행 공간(Execution Space)이 **Client**로 설정된 함수는 기본적으로 월드 내 모든 클라이언트에서 동시에 실행됩니다. 그러나 서버 측 로직 처리 후 특정 클라이언트에게만 결과를 반환해야 하는 상황, 예를 들어 아이템 구매 요청과 같은 경우, 모든 클라이언트에게 불필요한 메시지를 전송하면 네트워크 부하가 증가하고 월드 전체의 성능이 저하될 수 있습 [original] | 어떤 함수의 실행 제어 옵션이 **Client**로 설정되어 있다면 해당 함수는 모든 클라이언트에서 실행됩니다. 하지만 서버에서는 모든 클라이언트가 아니라 특정 클라이언트에만 함수를 실행하고 싶은 상황이 생길 수 있습니다. 특정 클라이언트가 서버에 어떤 요청(Request)을 보내고 서버가 로직을 처리한 이후, 해당 클라이언트에 응답(Response) 하는 상황이 그것입니다. 예를 들어 봅시다. 1. A 클라이언트에서 아이템 구매 버튼을 누른다면 : (Request) 2. 서버에서는 A가 가진 돈을 차감하고 아이템 개수를 늘린 다 [chunk_id] | Guides:559:4

[task] | wikipedia [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | # 카드와 UI 만들기 카드를 화면에 표시하기 위해 `/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Block_Group` 엔티티를 사용합니다. 이 엔티티에는 `ScrollLayoutGroupComponent`가 적용되어 있습니다. `ScrollLayoutGroupComponent`는 다수의 엔티티를 화면에 배치할 때 사용하는 컴포넌트이며, 상점이나 인벤토리처럼 이미지를 한눈에 확인해야 하는 UI 제작에 유용합니다. 이 컴포넌트는 자식 UI 엔티티들의 크기와 배치 간격 등을 일괄적으로 관리할 수 있습니다 [original] | 이제 카드를 화면에 불러낼 차례입니다. 카드를 불러내기 위해선 **/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Block_Group**를 활용합니다. **UI_Block_Group**은 [ScrollLayoutGroupComponent](/apiReference?postId=382%7B%22target%22:%22_self%22%7D)를 활용했습니다. **ScollLayoutGroupComponent**는 여러 개의 엔티티를 펼쳐야할 때 사용합니다. 주로 상점이나, 인벤토리처럼 한 눈에 봐야하는 이미지 [chunk_id] | Guides:561:1

[task] | knowledge_list [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | 제공된 문서 내용에서 추출한 핵심 사실 목록입니다. 1. `CardPairGameLogic` 로직 컴포넌트의 `CardPairGameUI` 프로퍼티는 `[None]` 동기화 속성을 가지며, 타입은 `Entity`이고 기본값 경로가 `/ui/CardPairGameUI`인 엔티티 참조입니다. 2. `CardPairGameLogic` 로직 컴포넌트의 `StartGame` 메서드는 `[client only]` 실행 공간 제약이 있으며, 매개변수가 없고 반환 타입은 `void`인 함수로, 본문에서 `self.CardPairGameUI.En [original] | 리메이크한 월드에는 제작에 필요한 UI, 리소스, 그리고 비어 있는 컴포넌트 등이 있습니다. 단계 별로 하나씩 채워나가며 함께 게임을 완성해봅시다. # CardPairGameUI 활성화 월드에 유저가 입장하면 **CardPairGameUI**가 **Enable**로 변경되도록 만들어 봅시다. 월드 전체에 적용되는 규칙이나 로직을 만들 때는 Logic을 사용합니다. **CardPairGameLogic** 로직에는 짝 맞추기에 기본적으로 필요한 UI를 켜거나 끄기, 카드 입력 등 전반적인 규칙을 작성할 것입니다. 우선 월드에 입장 [chunk_id] | Guides:561:0

[task] | wikipedia [title] | Effective MSW 1 [category] | Guides [rephrased] | # MSW 1의 wait과 TimerService 그리고 OnUpdate 최적화 ## wait과 TimerService의 차이 mLua 환경에서 `wait` 함수와 `TimerService`는 지연된 작업을 처리하는 방식에서 근본적인 차이를 보입니다. `wait`은 호출 지점에서 직접 대기한 후 특정 행동을 수행하는 직렬(serial) 처리 방식인 반면, `TimerService`는 해당 행동을 실행하는 별도의 비동기 작업을 생성하는 병렬(parallel) 처리 방식입니다. `wait`을 사용할 경우, 코드는 순차적으로 실행되 [original] | `wait`는 대기한 뒤에 직접 어떤 행동을 수행하는 것이고, `TimerService`는 해당 행동을 수행하는 별도의 일을 만드는 것입니다. `wait`는 직렬, `TimerService`는 병렬 형태로 동작합니다. 따라서 `wait`의 사용 코드는 다음과 같이 표현할 수 있습니다 ```lua local targetEntity = _EntityService:GetEntity("a22396e1-6365-42d4-9cef-5924c223f7fa") targetEntity.TestComponent:ShowMessage() func [chunk_id] | Guides:559:2

[task] | wikipedia [title] | Effective MSW 2 [category] | Guides [rephrased] | # 실행 제어(Execution Control)의 제약 및 처리 방법 메이플스토리 월드(mLua)에서는 함수의 실행 공간(Execution Space)을 설정함으로써 클라이언트와 서버 간의 통신을 별도의 추가 과정 없이 자동으로 처리할 수 있습니다. 이러한 자동화 메커니즘은 개발 편의성을 제공하지만, 특정 상황에서는 제약 사항으로 인해 의도한 대로 동작하지 않을 수 있습니다. 일부 오류는 로그로 명시되지만, 다른 경우에는 동작하지 않는 원인을 직접 파악하기 어려울 수 있습니다. 본 가이드에서는 실행 제어가 정상적으로 작동하지 않는 [original] | # 학습 과정 소개 함수의 실행 공간을 설정하면 별도의 과정 없이 쉽게 클라이언트와 서버가 통신할 수 있습니다. 자동으로 처리하기 때문에 편리하지만, 몇몇 경우는 제약이 있어 크리에이터가 원하는 대로 동작하지 않을 수 있습니다. 일부는 로그가 나오지만, 어떤 것은 동작하지 않는 이유를 확인할 수 없을 수도 있습니다. 이번 가이드에서는 실행 제어를 사용할 수 없는 경우를 알아봅시다. # 매개 변수가 지원하지 않는 종류 함수에는 여러 종류의 매개 변수(parameter)가 있습니다. 이 매개 변수는 다른 공간에서 실행 제어를 사용 [chunk_id] | Guides:560:0

[task] | diverse_qa [title] | Effective MSW 1 [category] | Guides [rephrased] | 질문: 실행 공간이 Client로 설정된 함수는 기본적으로 어디에서 실행됩니까? 답변: 실행 공간이 Client로 설정되어 있다면 해당 함수는 모든 클라이언트에서 실행됩니다. 질문: 서버가 모든 클라이언트가 아닌 특정 클라이언트에만 함수를 실행하고 싶은 상황의 예시를 들어보세요. 답변: 특정 클라이언트가 서버에 요청(Request)을 보내고 서버가 로직을 처리한 이후, 해당 클라이언트에 응답(Response) 하는 상황이 이에 해당합니다. 질문: A 클라이언트가 아이템 구매 버튼을 눌렀을 때 서버는 어떤 처리를 수행합니까? 답변 [original] | 어떤 함수의 실행 제어 옵션이 **Client**로 설정되어 있다면 해당 함수는 모든 클라이언트에서 실행됩니다. 하지만 서버에서는 모든 클라이언트가 아니라 특정 클라이언트에만 함수를 실행하고 싶은 상황이 생길 수 있습니다. 특정 클라이언트가 서버에 어떤 요청(Request)을 보내고 서버가 로직을 처리한 이후, 해당 클라이언트에 응답(Response) 하는 상황이 그것입니다. 예를 들어 봅시다. 1. A 클라이언트에서 아이템 구매 버튼을 누른다면 : (Request) 2. 서버에서는 A가 가진 돈을 차감하고 아이템 개수를 늘린 다 [chunk_id] | Guides:559:4

[task] | diverse_qa [title] | Effective MSW 2 [category] | Guides [rephrased] | 질문: 메이플스토리 월드에서 기본적으로 권장하는 구현 방식은 무엇인가요? 답변: 대부분의 기능을 멀티 플레이 기반으로 처리하는 것을 권장합니다. 질문: 별도의 Local 개념이 필요한 주요 항목 세 가지는 무엇인가요? 답변: Localized Entity, 입력 처리, 내 캐릭터 처리입니다. 질문: `UIEntity`, 입력, 내 캐릭터는 어디에만 존재하는 개념인가요? 답변: 모두 나의 클라이언트에만 존재하는 개념입니다. 질문: 클라이언트에서 '내 캐릭터'를 처리하기 위해 지원되는 API는 무엇인가요? 답변: `_UserSer [original] | 메이플스토리 월드에서는 기본적으로 멀티 플레이를 손쉽게 구현할 수 있습니다. 대부분의 기능을 멀티 플레이 기반으로 처리하는 것을 권장합니다. 하지만 일부 항목은 별도의 Local 개념이 필요합니다. 주요 항목은 다음과 같습니다. * Localized Entity * 입력 처리 * 내 캐릭터 처리 **UIEntity**와 **입력** 그리고 **내 캐릭터** 모두 **나의 클라이언트에만 존재하는 개념**이라 별도로 처리해야 합니다. 특히 **내 캐릭터**는 클라이언트에서 처리하기 위해 `_UserService.LocalPlay [chunk_id] | Guides:560:1

[task] | diverse_qa [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | 질문: 카드를 화면에 불러내기 위해 어떤 경로 하위 요소를 활용해야 하는가? 답변: **/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Block_Group** 요소를 활용합니다. 질문: UI_Block_Group에 적용된 레이아웃 컴포넌트의 이름은 무엇인가? 답변: ScrollLayoutGroupComponent입니다. 질문: ScrollLayoutGroupComponent는 주로 어떤 상황에서 유용하게 사용될 수 있는가? 답변: 상점이나 인벤토리처럼 한눈에 봐야 하는 이미지가 많은 UI를 제작할 때 [original] | 이제 카드를 화면에 불러낼 차례입니다. 카드를 불러내기 위해선 **/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Block_Group**를 활용합니다. **UI_Block_Group**은 [ScrollLayoutGroupComponent](/apiReference?postId=382%7B%22target%22:%22_self%22%7D)를 활용했습니다. **ScollLayoutGroupComponent**는 여러 개의 엔티티를 펼쳐야할 때 사용합니다. 주로 상점이나, 인벤토리처럼 한 눈에 봐야하는 이미지 [chunk_id] | Guides:561:1

[task] | extract_knowledge [title] | Effective MSW 1 [category] | Guides [rephrased] | # `wait`와 `TimerService`의 차이 및 `OnUpdate` 최적화 ## 1. 개념 설명 mLua 스크립트에서 지연 실행을 수행하는 방법에는 `wait` 함수와 `TimerService` 서비스가 있으며, 두 방식은 동작 방식이 근본적으로 다릅니다. * **`wait` (직렬 처리):** 호출된 함수의 실행 흐름을 일시정지 시킨 후, 지정된 시간이 지난 뒤 다음 코드를 순차적으로 실행합니다. 이는 단일 실행 컨텍스트 내에서 직렬적으로 진행됩니다. * **`TimerService` (병렬 처리):** 현재 [original] | `wait`는 대기한 뒤에 직접 어떤 행동을 수행하는 것이고, `TimerService`는 해당 행동을 수행하는 별도의 일을 만드는 것입니다. `wait`는 직렬, `TimerService`는 병렬 형태로 동작합니다. 따라서 `wait`의 사용 코드는 다음과 같이 표현할 수 있습니다 ```lua local targetEntity = _EntityService:GetEntity("a22396e1-6365-42d4-9cef-5924c223f7fa") targetEntity.TestComponent:ShowMessage() func [chunk_id] | Guides:559:2

[task] | knowledge_list [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | 제시된 문서 원문에 포함된 정보만을 바탕으로 핵심 사실을 정리한 목록입니다. * `UI_Block_Group`은 경로 `/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Block_Group`에 위치하며, 카드 UI를 화면에 불러낼 때 활용되는 UI Entity입니다. * `UI_Block_Group`에는 `ScrollLayoutGroupComponent`가 적용되어 있으며, 이 컴포넌트는 상점이나 인벤토리처럼 한눈에 봐야 할 이미지가 많은 UI에서 여러 엔티티를 펼쳐 배치할 때 사용됩니다. * [original] | 이제 카드를 화면에 불러낼 차례입니다. 카드를 불러내기 위해선 **/ui/CardPairGameUI/UI_Board/UI_Blocks/UI_Block_Group**를 활용합니다. **UI_Block_Group**은 [ScrollLayoutGroupComponent](/apiReference?postId=382%7B%22target%22:%22_self%22%7D)를 활용했습니다. **ScollLayoutGroupComponent**는 여러 개의 엔티티를 펼쳐야할 때 사용합니다. 주로 상점이나, 인벤토리처럼 한 눈에 봐야하는 이미지 [chunk_id] | Guides:561:1

[task] | knowledge_list [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | 제시된 문서 내용을 바탕으로 추출한 핵심 사실 목록입니다. 1. `CardSpawnRoot` 속성은 `[None]` 동기화 태그를 가지며, `/ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group` 경로를 가진 `Entity` 타입입니다. 2. `CreateCardEntities` 메서드는 `[client only]` 실행 공간 제약이 있으며, 반환 타입은 `void` 입니다. 3. `CreateCardEntities` 메서드 내부에서는 로컬 변수 `cardModelId` 에 `"Model [original] | ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group Method: [client only] void CreateCardEntities() { local cardModelId = "Model_Card EntiryID" local card = _SpawnService:SpawnByModelId(cardModelId, "Card", Vector3(0,0,0), self.CardSpawn [chunk_id] | Guides:561:3

[task] | distill [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | # 카드와 UI 만들기 `_SpawnService`를 이용해 UI 하위 엔티티에 카드를 스폰합니다. ## 핵심 API - **`_SpawnService:SpawnByModelId(modelId, name, pos, parent)`**: 지정된 모델 ID로 엔티티를 생성합니다. - `modelId`: 스폰할 모델 ID (string) - `name`: 생성될 엔티티 이름 (string) - `pos`: 위치 (Vector3) - `parent`: 부모 엔티티 (Entity) - **리턴**: 생성된 엔티티 객체 [original] | ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group Method: [client only] void CreateCardEntities() { local cardModelId = "Model_Card EntiryID" local card = _SpawnService:SpawnByModelId(cardModelId, "Card", Vector3(0,0,0), self.CardSpawn [chunk_id] | Guides:561:3

[task] | wikipedia [title] | Effective MSW 2 [category] | Guides [rephrased] | # 메이플스토리 월드의 로컬(Local) 처리 메이플스토리 월드(MapleStory Worlds)는 기본적으로 멀티 플레이 환경을 쉽게 구축할 수 있도록 설계되어 있으며, 대부분의 기능은 멀티 플레이 기반으로 처리하는 것이 권장됩니다. 그러나 모든 기능이 서버와 클라이언트 간에 동기화되는 것은 아니며, 사용자의 개별 클라이언트에만 존재하는 **로컬(Local)** 개념을 요구하는 항목들이 있습니다. 주요 로컬 항목으로는 **로컬라이즈드 엔티티(Localized Entity)**, **입력 처리(Input Handling)**, 그 [original] | 메이플스토리 월드에서는 기본적으로 멀티 플레이를 손쉽게 구현할 수 있습니다. 대부분의 기능을 멀티 플레이 기반으로 처리하는 것을 권장합니다. 하지만 일부 항목은 별도의 Local 개념이 필요합니다. 주요 항목은 다음과 같습니다. * Localized Entity * 입력 처리 * 내 캐릭터 처리 **UIEntity**와 **입력** 그리고 **내 캐릭터** 모두 **나의 클라이언트에만 존재하는 개념**이라 별도로 처리해야 합니다. 특히 **내 캐릭터**는 클라이언트에서 처리하기 위해 `_UserService.LocalPlay [chunk_id] | Guides:560:1

[task] | knowledge_list [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | 제시된 문서 내용만을 바탕으로 추출한 핵심 사실 목록입니다. 1. `CardBoard` 컴포넌트는 `CardPairGameUI` 그룹에 추가되며, `CardSpawnRoot` 프로퍼티는 `[None]` 동기화 속성을 가지며 타입이 `Entity`이고 기본값이 `/ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group`으로 설정됩니다. 2. `CreateCardEntities` 메서드는 `[client only]` 실행 공간에서 동작하며, 반환 타입이 `void`인 함수로, `Model_Car [original] | 1. **CardBoard** 컴포넌트를 **CardPairGameUI** 그룹에 추가합니다. 2. **CardBoard** 컴포넌트를 선택해 스크립트 에디터를 엽니다. 3. **CardSpawnRoot** 프로퍼티를 추가하고, 반환 타입을 Entity로 변경합니다. 4. 엔티티는 **UI_Block_Group**으로 지정합니다. ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI [chunk_id] | Guides:561:2

[task] | wikipedia [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | **카드 짝 맞추기: 카드와 UI 만들기** 리메이크된 월드에는 게임 제작에 필요한 UI, 리소스, 그리고 비어 있는 컴포넌트 등이 사전에 준비되어 있습니다. 본 가이드는 이러한 요소들을 단계별로 채워나가며 게임을 완성하는 과정을 설명합니다. ### CardPairGameUI 활성화 유저가 월드에 입장했을 때 `CardPairGameUI`가 활성화(`Enable`)되도록 설정하는 방법을 다룹니다. 월드 전체에 적용되는 규칙이나 로직을 구현할 때는 `Logic` 컴포넌트를 사용합니다. `CardPairGameLogic` 로직에는 [original] | 리메이크한 월드에는 제작에 필요한 UI, 리소스, 그리고 비어 있는 컴포넌트 등이 있습니다. 단계 별로 하나씩 채워나가며 함께 게임을 완성해봅시다. # CardPairGameUI 활성화 월드에 유저가 입장하면 **CardPairGameUI**가 **Enable**로 변경되도록 만들어 봅시다. 월드 전체에 적용되는 규칙이나 로직을 만들 때는 Logic을 사용합니다. **CardPairGameLogic** 로직에는 짝 맞추기에 기본적으로 필요한 UI를 켜거나 끄기, 카드 입력 등 전반적인 규칙을 작성할 것입니다. 우선 월드에 입장 [chunk_id] | Guides:561:0

[task] | distill [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | # 카드 짝 맞추기: CardBoard 컴포넌트 설정 `CardPairGameUI` 그룹의 `CardBoard` 컴포넌트에서 카드 엔티티 생성 및 배치 로직을 설정합니다. ### 1. 프로퍼티 설정 `CardSpawnRoot` 프로퍼티를 추가하여 카드가 생성될 UI 엔티티 경로를 지정합니다. ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group ``` ### 2. `CreateCardEntities` [original] | 1. **CardBoard** 컴포넌트를 **CardPairGameUI** 그룹에 추가합니다. 2. **CardBoard** 컴포넌트를 선택해 스크립트 에디터를 엽니다. 3. **CardSpawnRoot** 프로퍼티를 추가하고, 반환 타입을 Entity로 변경합니다. 4. 엔티티는 **UI_Block_Group**으로 지정합니다. ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI [chunk_id] | Guides:561:2

[task] | diverse_qa [title] | 카드와 UI 만들기 [category] | Guides [rephrased] | 질문: 리메이크한 월드에는 제작에 필요한 어떤 요소들이 이미 포함되어 있나요? 답변: 리메이크한 월드에는 제작에 필요한 UI, 리소스, 그리고 비어 있는 컴포넌트 등이 포함되어 있습니다. 질문: 월드 전체에 적용되는 규칙이나 로직을 만들 때 어떤 컴포넌트를 사용해야 하나요? 답변: 월드 전체에 적용되는 규칙이나 로직을 만들 때는 Logic을 사용해야 합니다. 질문: `CardPairGameLogic` 로직에서 작성할 주요 규칙은 무엇인가요? 답변: `CardPairGameLogic` 로직에는 짝 맞추기에 기본적으로 필요한 UI를 [original] | 리메이크한 월드에는 제작에 필요한 UI, 리소스, 그리고 비어 있는 컴포넌트 등이 있습니다. 단계 별로 하나씩 채워나가며 함께 게임을 완성해봅시다. # CardPairGameUI 활성화 월드에 유저가 입장하면 **CardPairGameUI**가 **Enable**로 변경되도록 만들어 봅시다. 월드 전체에 적용되는 규칙이나 로직을 만들 때는 Logic을 사용합니다. **CardPairGameLogic** 로직에는 짝 맞추기에 기본적으로 필요한 UI를 켜거나 끄기, 카드 입력 등 전반적인 규칙을 작성할 것입니다. 우선 월드에 입장 [chunk_id] | Guides:561:0

[task] | extract_knowledge [title] | Effective MSW 1 [category] | Guides [rephrased] | # 특정 클라이언트로의 함수 전송 (Targeted Client Execution) ## 1. 개념 설명 메이플스토리 월드(mLua)에서 실행 공간(Execution Space)이 **Client**로 설정된 함수는 기본적으로 모든 클라이언트에 브로드캐스트됩니다. 그러나 서버 로직 처리 후 특정 요청자(Requester)에게만 응답(Response)을 전달해야 하는 경우, 모든 클라이언트로 메시지를 전송하는 것은 네트워크 트래픽을 증가시키고 월드 성능을 저하시키는 비효율적인 방식입니다. 이 문제를 해결하기 위해 mLua는 ** [original] | 어떤 함수의 실행 제어 옵션이 **Client**로 설정되어 있다면 해당 함수는 모든 클라이언트에서 실행됩니다. 하지만 서버에서는 모든 클라이언트가 아니라 특정 클라이언트에만 함수를 실행하고 싶은 상황이 생길 수 있습니다. 특정 클라이언트가 서버에 어떤 요청(Request)을 보내고 서버가 로직을 처리한 이후, 해당 클라이언트에 응답(Response) 하는 상황이 그것입니다. 예를 들어 봅시다. 1. A 클라이언트에서 아이템 구매 버튼을 누른다면 : (Request) 2. 서버에서는 A가 가진 돈을 차감하고 아이템 개수를 늘린 다 [chunk_id] | Guides:559:4

← → 방향키로 페이지 이동 · 숫자 입력 후 Enter로 점프