Godot: 더 나은 사용자 정의 EditorPlugin 노드

무슨 말인지 이해가 안 돼요

@reduz 플러그인에 의해 생성된 유형의 노드를 장면에 추가하면 이미 플러그인 스크립트가 첨부되어 있습니다. 따라서 사용자 정의 동작으로 다른 스크립트를 추가하는 것은 불가능합니다.

물론 이것은 핵심 설계에 의한 것이며 변경되지 않을 것입니다.

2016년 8월 7일 18시 11분에 "George Marques" [email protected]이 다음과 같이 썼습니다.

@reduz https://github.com/reduz 장면에 노드를 추가하면
플러그인에 의해 생성된 유형에는 이미 플러그인 스크립트가 첨부되어 있습니다. 그래서
사용자 정의 동작으로 다른 스크립트를 추가하는 것은 불가능합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -238108767,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z29F5q8PaoBv4OrzAUayzrfNjfHyZks5qdkoUgaJpZM4JejbZ
.

이거 슬프네. 그러나 항상 부모나 자식에게 스크립트를 추가할 수 있습니다.

wontfix로 닫습니다.

제가 뭔가 오해를 하고 있을지도 모르지만, 커스텀 타입이 스크립트라면,
생성된 노드에 어떻게 포함되지 않습니까? 그것은 의미가 없습니다
그것은 다르다

2016년 8월 7일 오후 9시 52분에 "George Marques" [email protected] 이 다음과 같이 썼습니다.

이거 슬프네. 그러나 항상 부모나 자식에게 스크립트를 추가할 수 있습니다.

wontfix로 닫습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -238120392,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z27Zo4Ixvo4APSC4Fxf5ZqCJRsAxXks5qdn3igaJpZM4JejbZ
.

노드당 두 개(또는 그 이상)의 스크립트를 가질 수 있는 기능이 필요할 것이라고 생각합니다. 하지만 실제로는 그다지 의미가 없습니다.

Godot는 원래 이것을 지원했지만 이점보다 문제가 더 많았습니다.

2016년 8월 7일 오후 10시 36분에 "George Marques" [email protected] 이 다음과 같이 썼습니다.

당 2개(또는 그 이상)의 스크립트를 가질 수 있는 능력이 필요하다고 생각합니다.
이것은 실제로 많은 의미가 없지만.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -238123729,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z27jidVZl-hHWW3G_ESr8Cqj3eX7Eks5qdogRgaJpZM4JejbZ
.

문제는 커스텀 노드가 실제로 "커스텀 노드"가 아니라 사전 설정된 스크립트와 다른 아이콘이 있는 기본 노드이기 때문에 거의 쓸모가 없다는 것입니다.
"사용자 정의 노드"에서 기대했던 것은 스크립트에 정의된 모든 것을 사용하도록 노드를 확장할 수 있다는 것입니다. 예시 시나리오:
Sprite의 자식인 Test라는 사용자 지정 노드가 있고 true 를 반환하는 test() 함수를 추가합니다. 그런 다음 새 테스트 노드를 만들고 여기에 스크립트를 할당하고 test() 기능을 사용하고 싶습니다.
이건 불가능 해.

그런 다음 콤보를 확장하는 + 스크립트를 상속하는 장면으로 돌아갑니다.

음, 미리 설정된 스크립트와 다른 아이콘이 있는 미리 설정된 노드가 되는 것은 IMO입니다.
사용자 정의가 충분하지만 실제로 사용자 정의 코드를
거기에서 항상 노드와 함께 제공되는 것을 상속할 수 있습니다. 우리는 할 수 있었다
정말로 원한다면 UI에서 이것을 좀 더 쉽게 만드십시오.

2016년 8월 8일 월요일 오전 10시 40분, Dominik Banaszak [email protected]
썼다:

문제는 커스텀 노드가 실제로 쓸모가 없기 때문에 거의 쓸모가 없다는 것입니다.
"커스텀 노드"는 사전 설정된 스크립트와 다른 기본 노드일 뿐입니다.
상. 그런 다음 콤보를 확장하는 + 스크립트를 상속하는 장면으로 돌아갑니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -238240130,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z27eHoXwgr6buF6CCAHfxwx1dKkCiks5qdzHhgaJpZM4JejbZ
.

UI를 통해 자동화/쉽게 만들 수 있으면 좋겠습니다.

내가 이해하는 바에 따르면 기본 제공 노드처럼 작동하는 사용자 지정 노드를 생성할 가능성이 있는 것으로 예상됩니다. 즉, 다음 기능이 있어야 합니다.

• 사용자 정의 아이콘, 사용자 정의 식별자
• 노드 추가 위젯을 통해 인스턴스화 가능(스크립트를 통해 추측하므로 전역 범위에 노출되나요?)
• 스크립트를 통해 코딩된 사용자 지정 API가 있어야 합니다(예: RedNode2D 는 Node2D 를 확장하고 사용자 지정 스크립트를 통해 정의된 빨간색 변조가 있음).
• 그런 다음 이 사용자 정의 노드는 내장 노드처럼 작동해야 합니다. 즉, 사용자는 스크립트 없이 인스턴스를 생성할 수 있어야 합니다(사용자 정의 API는 하드코딩된 내장 스크립트의 경우와 마찬가지로 사용자에게 직접 노출되지 않습니다. C++에서) 사용자 정의 노드를 확장하는 스크립트를 여기에 첨부합니다(예: extends RedNode2D ).

이는 사용자 정의 노드를 선언할 때 "자연스러운" 기대치이며 매우 강력한 기능이 될 것입니다. 나는 부분적으로 디자인 결정으로 인해 지금까지 이런 식으로 작동하지 않는다는 것을 위에서 수집합니다. 위에서 설명한 것과 같은 기능을 가질 수 있는 방법이 있다면 많은 응용 프로그램이 있을 것이라고 확신합니다. assetlib는 즉시 사용할 수 있는 많은 작업을 수행하고 내장된 것처럼 사용할 수 있는 사용자 지정 노드로 가득 차 있습니다.

무엇을 할 수 있는지/하지 말아야 하는지에 대한 합의가 있을 때까지 재개합니다.

+1
이것은 "OtherEngine(tm)"에서 Godot로 기존 프로젝트를 이식하려고 할 때 저에게 첫 번째 주요 장애물 중 하나였습니다. 위에서 설명한 @akien-mga와 같은 사용자 지정 유형은 등록 후 다른 내장 유형처럼 작동해야 합니다.

그들이 아니라고 생각하는 방식을 설명해 주십시오.

2016년 8월 8일 오전 11시 50분에 "Ralf Hölzemer" [email protected] 이 작성했습니다.

+1
이것은 내가 포팅을 시도했을 때 나를 위한 첫 번째 주요 장애물 중 하나였습니다.
"OtherEngine(tm)"에서 Godot까지의 기존 프로젝트. 다음과 같은 사용자 정의 유형
@akien-mga https://github.com/akien-mga 위에서 설명한 대로
등록 후 다른 내장 유형처럼 작동합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -238261603,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z25PJzv9w7iXO350tRF3FcEuYQYUKks5qd0IrgaJpZM4JejbZ
.

이전에 이미 말했듯이 현재 가장 큰 단점 은 사용자 정의 유형이 해당 스크립트의 기본 유형을 인스턴스화하고 해당 인스턴스에 적절한 스크립트를 할당하는 빠른 방법에 불과하다는 것입니다. 이것은 내장 유형으로 할 수 있는 것처럼 편집기에서 다른 스크립트로 해당 노드를 확장하는 것을 불가능하게 만듭니다.

그러나 "새 노드/리소스 만들기" 대화 상자에서 사용자 지정 노드를 사용하여 상속 트리를 구축하는 것도 불가능합니다. add_custom_type을 통해 기본 제공 유형을 부모로 등록할 때 이러한 트리에만 표시되기 때문입니다.

예를 들어, 단일 기본 유형에서 내 프로젝트의 모든 사용자 정의 유형을 상속한다고 가정해 보겠습니다.

base.gd

extends Node
export (Color) var color

type_a.gd

extends base.gd

type_b.gd

extends base.gd

지금처럼 이런 유형을 등록해야 합니다. 이 경우 add_custom_type의 두 번째 인수는 "Node"여야 합니다. 그렇지 않으면 대화 상자에 표시되지 않습니다.

func _enter_tree():
    add_custom_type("Base", "Node", preload("base.gd"), preload("base.png"))
    add_custom_type("TypeA", "Node", preload("type_a.gd"), preload("type_a.png"))
    add_custom_type("TypeB", "Node", preload("type_b.gd"), preload("type_b.png"))

... 그리고 이것이 결과입니다.

이와 같이 사용자 정의 유형을 등록할 수 있다는 것은 좋은 일이지만 대화 상자는 다른 기본 제공 유형과 같은 유형의 상속 특성을 반영하지 않습니다. 모든 빌트인 유형의 경우 해당 트리를 보고 내가 처리하는 내용을 한 눈에 볼 수 있습니다. 예를 들어 Sprite 가 Node2D이고 따라서 Node2D에서 제공하는 모든 기능을 상속하는지 확인할 수 있습니다. 사용자 정의 유형의 경우에도 마찬가지입니다.

이제 위에서 언급한 @akien-mga와 같이 사용자 정의 유형을 전역 범위에 완전히 등록할 수 있다면 상황을 훨씬 더 쉽게 이해하고 사용할 수 있습니다.

첫째, 파일 경로/이름 대신 유형 이름 으로 참조되는 사용자 정의 유형을 상속할 수 있습니다.

base.gd

extends Node
export (Color) var color

type_a.gd

extends Base

type_b.gd

extends Base

... 그러면 사용자 정의 유형의 등록이 다음과 같이 단순화될 수 있습니다. add_custom_type의 누락된 두 번째 매개변수에 유의하십시오.

func _enter_tree():
    add_custom_type("Base", preload("base.gd"), preload("base.png"))
    add_custom_type("TypeA", preload("type_a.gd"), preload("type_a.png"))
    add_custom_type("TypeB", preload("type_b.gd"), preload("type_b.png"))

... "새 노드/리소스 만들기" 대화 상자에서 훨씬 더 멋진 개요를 얻을 수 있습니다.

... 그리고 물론 사용자 정의 스크립트를 사용하여 편집기에서 해당 유형을 확장하는 기능:

... 스크립트 이름/경로 대신 유형 이름 으로도 참조됩니다.

extends Base

여기에서 플레이할 수 있는 위의 예제 플러그인이 있습니다.
addons.zip

아 그렇군요.. 이 두 가지를 확실히 고칠 수 있어야 합니다.
스크립트 생성 대화 상자에 상속 지원 추가

2016년 8월 8일 오후 1시 54분에 "Ralf Hölzemer" [email protected] 에서 다음과 같이 썼습니다.

이전에 이미 말했듯이 현재 _가장 큰 단점_은
사용자 정의 유형은 기본 유형을 인스턴스화하는 빠른 방법에 불과합니다.
해당 스크립트의 적절한 스크립트를 해당 인스턴스에 할당합니다. 이것
편집기에서 해당 노드를 다른 스크립트로 확장하는 것을 불가능하게 만듭니다.
내장 유형으로 할 수 있는 것처럼.

그러나 사용자 정의 노드로 상속 트리를 구축하는 것도 불가능합니다.
"Create new Node/Resource" 대화 상자는 이러한 대화 상자에만 표시되기 때문에
내장 유형을 통해 부모로 등록할 때 트리
add_custom_type.

예를 들어 내 모든 사용자 정의 유형을 상속한다고 가정해 보겠습니다.
단일 기본 유형의 프로젝트.

_base.gd http://base.gd_

노드 확장
내보내기(색상) var 색상

_type_a.gd http://type_a.gd_

base.gd 확장

_type_b.gd http://type_b.gd_

base.gd 확장

지금처럼 이런 유형을 등록해야 합니다. 이에
이 경우 add_custom_type의 두 번째 인수는 "Node"여야 합니다. 그렇지 않으면
대화 상자에 표시되지 않습니다.

func _enter_tree():
add_custom_type("기본", "노드", preload("base.gd"), preload("base.png"))
add_custom_type("TypeA", "Node", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", "노드", preload("type_b.gd"), preload("type_b.png"))

... 그리고 이것이 결과입니다.

[이미지: add_node_flat]
https://cloud.githubusercontent.com/assets/8785013/17486294/9bcc029c-5d90-11e6-81e6-6fce6b0e7cf0.png

이와 같이 사용자 정의 유형을 등록할 수 있다는 것은 좋지만,
대화 상자는 다음과 같은 유형의 상속 특성을 반영하지 않습니다.
다른 내장 유형. 모든 내장 유형의 경우 해당 트리를 보고
내가 무엇을 다루고 있는지 한 눈에보십시오. 예를 들어 나는 다음과 같이 확신할 수 있습니다.
Sprite는 Node2D이므로 _제공되는 모든 기능을 상속합니다.
by_ Node2D. 사용자 정의 유형의 경우에도 마찬가지입니다.

이제 사용자 정의 유형이 다음과 같이 전역 범위에 완전히 등록될 수 있다면
@akien-mga https://github.com/akien-mga 위에서 언급한 대로
이해하고 사용하는 것이 훨씬 간단합니다.

먼저 _type name_에서 참조하는 사용자 정의 유형에서 상속할 수 있습니다.
파일 경로/이름 대신.

_base.gd http://base.gd_

노드 확장
내보내기(색상) var 색상

_type_a.gd http://type_a.gd_

베이스 확장

_type_b.gd http://type_b.gd_

베이스 확장

... 그러면 사용자 정의 유형의 등록이 다음과 같이 단순화될 수 있습니다.
이것. add_custom_type의 누락된 두 번째 매개변수에 유의하십시오.

func _enter_tree():
add_custom_type("기본", preload("base.gd"), preload("base.png"))
add_custom_type("TypeA", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", preload("type_b.gd"), preload("type_b.png"))

... "새로 만들기
노드/리소스" 대화 상자:

[이미지: add_node_tree]
https://cloud.githubusercontent.com/assets/8785013/17487264/619f4da0-5d94-11e6-880f-a00791e30125.png

... 물론 편집기에서 이러한 유형을 확장하는 기능은
사용자 정의 스크립트:

[이미지: custom_type_no_script]
https://cloud.githubusercontent.com/assets/8785013/17487807/b54aced2-5d96-11e6-90e5-ee838b6a1335.png

... 스크립트 대신 _type name_으로도 참조됩니다.
이름/경로

베이스 확장

여기에서 플레이할 수 있는 위의 예제 플러그인이 있습니다.
addons.zip https://github.com/godotengine/godot/files/407291/addons.zip

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -238299152,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z20FQioFVkVcvhhbvDQ7jQKv5De7Hks5qd19QgaJpZM4JejbZ
.

절대 일어나지 않을 일은 인스턴스 노드에서 스크립트가 사라지는 것입니다.
숨겨지므로 노드가 스크립팅되었음을 분명히 해야 하지만
거기에 스크립트를 추가하면 여전히 해당 스크립트를 대체할 수 있습니다.
그것에서 상속

2016년 8월 8일 오후 2시 2분에 "Juan Linietsky" [email protected] 이 다음과 같이 썼습니다.

아 그렇군요.. 이 두 가지를 확실히 고칠 수 있어야 합니다.
스크립트 생성 대화 상자에 상속 지원 추가

2016년 8월 8일 오후 1시 54분에 "Ralf Hölzemer" [email protected] 에서 다음과 같이 썼습니다.

이전에 이미 말했듯이 현재 _가장 큰 단점_은
사용자 정의 유형은 기본 유형을 인스턴스화하는 빠른 방법에 불과합니다.
해당 스크립트의 적절한 스크립트를 해당 인스턴스에 할당합니다. 이것
편집기에서 해당 노드를 다른 스크립트로 확장하는 것을 불가능하게 만듭니다.
내장 유형으로 할 수 있는 것처럼.

그러나 사용자 정의 노드로 상속 트리를 구축하는 것도 불가능합니다.
"Create new Node/Resource" 대화 상자는 이러한 대화 상자에만 표시되기 때문에
내장 유형을 통해 부모로 등록할 때 트리
add_custom_type.

예를 들어 내 모든 사용자 정의 유형을 상속한다고 가정해 보겠습니다.
단일 기본 유형의 프로젝트.

_base.gd http://base.gd_

노드 확장
내보내기(색상) var 색상

_type_a.gd http://type_a.gd_

base.gd 확장

_type_b.gd http://type_b.gd_

base.gd 확장

지금처럼 이런 유형을 등록해야 합니다. 이에
이 경우 add_custom_type의 두 번째 인수는 "Node"여야 합니다. 그렇지 않으면
대화 상자에 표시되지 않습니다.

func _enter_tree():
add_custom_type("기본", "노드", preload("base.gd"), preload("base.png"))
add_custom_type("TypeA", "Node", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", "노드", preload("type_b.gd"), preload("type_b.png"))

... 그리고 이것이 결과입니다.

[이미지: add_node_flat]
https://cloud.githubusercontent.com/assets/8785013/17486294/9bcc029c-5d90-11e6-81e6-6fce6b0e7cf0.png

이와 같이 사용자 정의 유형을 등록할 수 있다는 것은 좋지만,
대화 상자는 다음과 같은 유형의 상속 특성을 반영하지 않습니다.
다른 내장 유형. 모든 내장 유형의 경우 해당 트리를 보고
내가 무엇을 다루고 있는지 한 눈에보십시오. 예를 들어 나는 다음과 같이 확신할 수 있습니다.
Sprite는 Node2D이므로 _제공되는 모든 기능을 상속합니다.
by_ Node2D. 사용자 정의 유형의 경우에도 마찬가지입니다.

이제 사용자 정의 유형을 전역 범위에 완전히 등록할 수 있다면
위에서 언급한 @akien-mga https://github.com/akien-mga 처럼
이해하고 사용하는 것이 훨씬 간단합니다.

먼저 _type name_에서 참조하는 사용자 정의 유형에서 상속할 수 있습니다.
파일 경로/이름 대신.

_base.gd http://base.gd_

노드 확장
내보내기(색상) var 색상

_type_a.gd http://type_a.gd_

베이스 확장

_type_b.gd http://type_b.gd_

베이스 확장

... 그러면 사용자 정의 유형의 등록이 다음과 같이 단순화될 수 있습니다.
이것. add_custom_type의 누락된 두 번째 매개변수에 유의하십시오.

func _enter_tree():
add_custom_type("기본", preload("base.gd"), preload("base.png"))
add_custom_type("TypeA", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", preload("type_b.gd"), preload("type_b.png"))

... "새로 만들기
노드/리소스" 대화 상자:

[이미지: add_node_tree]
https://cloud.githubusercontent.com/assets/8785013/17487264/619f4da0-5d94-11e6-880f-a00791e30125.png

... 물론 편집기에서 이러한 유형을 확장하는 기능은
사용자 정의 스크립트:

[이미지: custom_type_no_script]
https://cloud.githubusercontent.com/assets/8785013/17487807/b54aced2-5d96-11e6-90e5-ee838b6a1335.png

... 스크립트 대신 _type name_으로도 참조됩니다.
이름/경로

베이스 확장

여기에서 플레이할 수 있는 위의 예제 플러그인이 있습니다.
addons.zip https://github.com/godotengine/godot/files/407291/addons.zip

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -238299152,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z20FQioFVkVcvhhbvDQ7jQKv5De7Hks5qd19QgaJpZM4JejbZ
.

@reduz
노드가 스크립팅되었음을 명확히 하는 기술적인 이유가 있습니까? 그렇다면 점유된 스크립트 슬롯이어야 합니까?

사용자 정의 유형을 표시하는 다소 서투른 방법인 것 같으며 노드의 현재 스크립트를 교체하여 이미 존재하는 스크립트를 확장하는 스크립트를 얻는다는 아이디어는 아무도 생각하지 못할 것이라고 생각합니다. 그것은 스크립트를 통한 확장이 기본 유형에 대해 작동하는 방식이 아닙니다.

사용자가 해당 스크립트 필드를 지우면 어떻게 될까요? 사용자 정의 유형이 이전 스크립트로 되돌아가나요 아니면 기본 유형으로 완전히 되돌아갑니까? 다시 말하지만, 나는 이것이 좋은 생각이 아니라고 생각합니다.

대신, 빈 스크립트 슬롯을 희생하지 않고 다른 색상, 일부 아이콘 또는 다른 것을 통해 노드 트리 또는 속성 편집기에서 사용자 정의 유형으로 표시될 수 있습니다.

절대 일어나지 않을 일은 인스턴스화된 노드에서 스크립트가 사라지거나 숨겨지는 것입니다. 노드가 스크립팅되었음을 분명히 해야 하지만 여기에 스크립트를 추가하면 해당 노드에서 상속된 스크립트를 대체할 수 있습니다.

여기서 요점은 사용자 지정 노드를 정의하는 스크립트가 _instanced_ 노드의 속성이 아니라 해당 유형의 속성이기 때문에 _should_ 숨겨져 있다는 것입니다. 따라서 이 스크립트는 사용자 정의 노드에 속성을 부여해야 하지만 내장 노드의 C++ 클래스처럼 인스턴스 노드의 사용자에게 보이지 않아야 합니다. API를 제공하지만 수정이 불가능하고 확장만 가능합니다. Sprite를 인스턴스화할 때 scenes/2d/sprite.cpp 가 인스턴스화된 노드의 스크립트로 첨부되지 않는 것처럼, my_custom_node.gd 가 인스턴스 사용자 정의 노드의 수정 가능한 스크립트로 첨부되어서는 안됩니다.

지금 당장은 기술적으로 _가능한_지는 모르겠지만 자연스러운 사용 사례 AFAIU가 될 것입니다. 사용자 정의 유형의 스크립트를 수정하면 유형 자체가 수정되므로 이 유형의 모든 인스턴스에 영향을 미칩니다. 그러나 사용자 정의 유형을 사용하는 인스턴스화된 노드에는 extends CustomNode 자체 스크립트가 있어야 합니다.

나는 그 기능에 "기본 사용자 정의 스크립트 유형"에 대한 추가 포인터가 있는 Object가 필요하다고 생각합니다. 왜냐하면 그 정보에서 사용자 스크립트를 제거하려고 할 때 해당 정보가 필요하기 때문입니다(실제로 기본 스크립트로 대체해야 함).
일단 가지고 있으면 나머지는 수많은 부작용을 일으킬 수 있으므로 모든 경우에 포함시키는 문제입니다. 결국에는 스크립트를 처리하는 방법만 다를 뿐 하나의 스크립트만 첨부될 것입니다.
나는 일반적으로 상속에 대한 열렬한 팬이 아니지만 이것이 내가 하는 방법입니다.

사실, 그 포인터는 필요하지도 않았습니다. 스크립트를 표시하는 것으로 충분합니다. 예를 들어 스크립트로 add_custom_type()을 수행하면 엔진이 클래스에 플래그를 설정할 수 있으므로 "이 스크립트 클래스는 엔진 유형 확장입니다"와 같이 정보를 사용할 수 있습니다. 그런 다음 사용자 스크립트를 제거하면 "사용자 정의 유형"으로 표시된 첫 번째 상속된 스크립트 클래스로 대체되거나 없는 경우 제거합니다.

죄송합니다. 노드에 스크립트가 있는 경우 스크립트를 숨기는 것에 반대합니다. 뭐야
아닌 것을 시뮬레이션하는 포인트?

스크립트가 있다는 사실이 슬롯이 사용 중이거나 필요하다는 의미는 아닙니다.
두 번째 스크립트,
기존 것.

동의한다면 우리가 할 수 있는 일은 장면 트리에서 스크립트 아이콘을 숨기는 것입니다.
할당된 스크립트는 사용자 정의 유형의 스크립트이며 스크립트를
생성 대화 상자는 스크립트 생성 시 상속을 자동으로 제안합니다.
이 정도면 될까요?

2016년 8월 10일 오후 11시 1분에 "Marc" [email protected] 이 작성했습니다.

사실, 그 포인터는 필요하지도 않았습니다. 스크립트를 표시하면
예를 들어 스크립트로 add_custom_type()을 추가하면 엔진이
정보를 사용할 수 있도록 클래스에 플래그를 설정할 수 있습니다.
스크립트 클래스는 엔진 유형 확장입니다." 사용자 스크립트를 제거하면
그런 다음 "custom
type"을 입력하거나 없는 경우 제거합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -239055986,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z2xLGOhgMk__ZoRW1neRu1aRb5Qr_ks5qeoJogaJpZM4JejbZ
.

@reduz 충분히 좋을 것 같아요 :스마일:

@reduz 동의합니다. 두 번째 스크립트가 필요하다고 말하지 않았습니다. 첫 번째 스크립트(플러그인에서 정의한 사용자 정의)를 상속하는 스크립트를 추가한 다음 제거하기로 결정하면 어떻게 될지 궁금합니다. 그런 다음 스크립트 없이 노드를 기본 엔진 유형으로 되돌리겠습니까?

나는 우리가 어떻게 든 그것을 더 사용자 친화적으로 만들 수 있다고 생각합니다.

2016년 8월 11일 06:10에 "Marc" [email protected] 이 썼습니다.

@reduz https://github.com/reduz 동의합니다. 그리고 우리가 필요하다고 말하지 않았습니다.
두 번째 스크립트. 스크립트를 추가하면 어떻게 되는지 궁금합니다.
첫 번째 것(플러그인에서 정의한 사용자 정의)을 상속하지만 다음으로 결정합니다.
그것을 제거하십시오. 그런 다음 노드를 기본 엔진 유형으로 되돌립니다.
그럼 스크립트?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment -239109334,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z26JUJ0gjaCFwlsIDsINWp3_nqliwks5qeubygaJpZM4JejbZ
.

이 주석 https://github.com/godotengine/godot/issues/6067#issuecomment -238299152에 설명된 경로 대신 유형 정의 노드로 확장 부분을 파헤쳤습니다.

추가할 몇 가지 제안 사항:

• 애드온 유형의 node.get_type()은 유형 이름을 반환해야 합니다.

예시:

add_custom_type("MyCustomNode", "Node2D", preload("my_custom_node.gd"), preload("icon.png"))

node.get_type() should return "MyCustomNode" instead of "Node2D"

• 플러그인은 유형별로 다른 플러그인을 확장할 수 있습니다.

예시:
사용자 A는 Node2D를 기반으로 보다 정확한 가시성 알림을 위한 플러그인을 만듭니다.
add_custom_type("PreciseNotifier", "Node2D", preload("precise_notifier.gd"), preload("icon.png"))

그런 다음 사용자 B는 다른 구성이 있는 다른 애드온 폴더의 정확한 알리미를 기반으로 트리거 애드온을 개발합니다.
add_custom_type("Trigger", "PreciseNotifier", preload("trigger.gd"), preload("icon.png"))
그리고 trigger.gd 스크립트에서도 유형 이름으로 확장해야 합니다.
extends PreciseAddon
물론 사용자는 트리거 하나를 사용하려면 두 애드온을 모두 추가해야 합니다.

한 그룹은 스크립트가 없는 사용자 정의 노드 유형을 기반으로 하는 사용자 정의 노드 유형에서 여전히 파생되는 것으로 정의하고 다른 그룹은 동일한 시나리오를 기본으로 되돌아간 노드로 정의하려는 것처럼 보입니다. 엔진 유형. 나는 전자 그룹에 속해 있지만 사용자 정의 유형이 여전히 "스크립팅"되고 UI에서 이를 명확하게 하려는 것과 관련하여 후자 그룹의 요점도 볼 수 있습니다.

그런 다음 절충안은 일종의 스크립트++ 아이콘이 있는 스크립트 아이콘 옆에 있는 장면 트리 독의 노드 행에 추가 UI 버튼을 두는 것입니다. 이를 클릭하면 extends Base 또는 extends "Base" 와 같이 사용자 정의 유형에서 이미 상속된 스크립트가 있는 일반적인 "스크립트 작성" 팝업 창으로 이동합니다. 그런 다음 정의된 스크립트가 생성되고 사전 설정 스크립트가 무엇이든 즉시 대체됩니다. 따라서 노드에 이미 존재하는 스크립트가 있음을 여전히 명확하게 표시할 수 있지만 해당 사전 설정 스크립트를 쉽게 교체할 수 있는 친숙한 인터페이스도 있습니다.

이 제안은 커스텀 노드를 엔진 내 대응 노드와 다소 다르게 취급하기 때문에 아마도 덜 직관적일 것입니다. 생각?

이 토론의 뒷부분에서 2센트를 줄 때 문제는 애드온을 상속하는 여러 노드가 기본적으로 동일한 원본 스크립트를 공유한다는 사실에 있다고 생각합니다. Juan이 이 스레드의 맨 처음에 주장했듯이 코드 가시성은 신경쓰지 않습니다. 디자인 선택이자 애드온을 사용하는 개발자에게 노드 동작을 투명하게 만드는 데 중요한 것이기도 합니다. 그러나 일반적으로 코드에서 다른 노드의 동작을 변경하고 싶을 것이며 현재로서는 원래 스크립트 참조를 제거하고 새 스크립트를 만들고 기본 스크립트 코드를 복사하여 붙여넣는 것뿐입니다. 새 애드온 노드의 스크립트를 새 .gd 파일로 save as 할 수도 없습니다. 이렇게 하면 원본 스크립트를 사용하는 다른 모든 노드에 대한 참조가 변경되므로 이 3단계 복사-붙여넣기가 있습니다. 절차상.

다시 말하지만 그렇게 복잡하지 않습니다. 이 특별한 경우에 GDScript 편집기의 save as 옵션이 예상대로 작동하지 않으며 ' GDScript 편집기에서 '복사 및 저장' 버튼을 사용하여 애드온을 빠르게 사용자 정의할 수 있습니다(그리고 아키텍처 측면에서 이 버튼을 표시하는 것은 상속된 스크립트를 사용할 필요 없이 Godot에서 게임을 만드는 좋은 접근 방식이기 때문에 의미가 있습니다).

@henriquelalves 나는 코드에서 사용자 정의 노드를 사용자 정의하는 것이 기본적으로 상속이라고 생각했습니다. 예를 들면 extends "addons/thing/thing.gd" ? 상속된 스크립트는 무엇을 재정의하는지 알면 애드온 버전과 동일한 작업을 계속 수행합니다. 복사/붙여넣기가 필요 없습니다.

@Zylann 당신이 옳았지만 일반적으로 코드 가시성과 자동 완성 단점 때문에 이 특정 접근 방식을 좋아하지 않습니다(적어도 2.1에서는 지금까지 테스트하지 않았습니다). 그리고 대부분의 경우 메서드를 재정의하고 싶지 않고 원래 애드온 스크립트에서 확장 변수가 아닌 특정 항목만 변경합니다. 이것이 현재 save as 동작에서 저를 괴롭히는 것입니다. 그러한 스크립트에 대한 모든 노드 참조를 변경하지 않고는 스크립트 사본을 신속하게 생성할 수 없습니다. UI 친화적인 방식으로 이것을 해결하면 사용자 정의할 여러 노드와 코드 가시성 등의 원래 문제가 해결됩니다.

@henriquelalves 글쎄, 나는 복사/붙여넣기 tbh xD를 참을 수 없다. 그리고 당신은 또한 버전 관리가 있는 플러그인을 포크하고 처음에 대신 사용할 수 있다.

@Zylann Forking 플러그인은 아주 간단해야 하는 것에 더 많은 단계를 추가하고 있습니다. 하하하. 여전히 save as 동작이 이상하다고 생각하더라도 이것이 우선 순위가 아닌 경우 수동 복사-붙여넣기를 계속할 것입니다.

@henriquelalves 복사/붙여넣기는 분기입니다^^ 하지만 버전 관리 없이 완료하면 플러그인이 업데이트되면 나중에 뒤에서 물어뜯을 것입니다.

사용자 지정 노드에 스크립트를 첨부하는 현재 동작은 해당 사용자 지정 노드를 애드온으로 사용하는 것과 단순히 스크립트를 노드에 첨부하는 것의 이점이 거의 없습니다. 유일한 이점은 노드 대화 상자에 표시된다는 것인데 실제로는 전혀 이점이 없습니다.

저는 사용자 정의 노드가 일류 내장 유형처럼 작동해야 한다고 주장하는 진영에 있습니다. 그렇지 않으면 왜 애드온을 만들거나 사용하는 것을 귀찮게합니까? 대화 상자에서 볼 수 있고 스크립트 추가 버튼을 클릭하지 않아도 됩니까?

@RodeoMcCabe 문제는 사용자 정의 유형이 실제로는 여전히 엔진 내 노드 위에 계층화된 스크립트이며 사용자 정의 유형 노드가 엔진 소스로 직접 컴파일되지 않기 때문에 변경할 수 없다는 것입니다. 우리가 해야 할 일은 이러한 스크립팅된 노드가 사용자의 눈에 엔진 내 노드의 동작을 시뮬레이션 할 수 있도록 하는 구체적인 단계/기능 세트를 공식화하는 것입니다. 예를 들어...

1. "노드 생성" 창에 노드 추가(완료)
2. 사용자가 "노드 생성" 창에 대해 노드에 대한 텍스트 "간단한 설명"을 제공할 수 있도록 합니다(완료되지 않은 것으로 보입니까? - 적어도 add_custom_type 의 일부가 아님).
3. 사용자가 "노드 생성" 창에서 노드 계층 구조를 표시하고 추상 사용자 정의 유형을 정의할 수 있습니다. 이것은 add_custom_type 함수가 추상 유형인지 여부에 대해 bool을 추가하는 것을 포함할 수 있습니다. "노드 생성" 마법사는 그에 따라 추상 사용자 정의 유형 생성을 차단하도록 업데이트해야 합니다.

4. 노드가 스크립트가 없는 것처럼 보이도록 하십시오.

   ㅏ. 노드에는 Scene 도크에 "스크립트가 이 노드에 있습니다" 아이콘이 없어야 합니다. 좀 더 투명하게 만들기 위해 "이것은 사용자 정의 유형 노드입니다" 아이콘이 대신 있어야 합니다. 그런 다음 사용자를 클릭하면 사용자 정의 유형 추가 스크립트로 직접 이동할 수 있습니다. 그것은 "몰입"을 깨뜨리지만 사용성을 위해 필요한 희생이 될 것입니다(분명히 원하는 경우 사용자 정의 유형 노드가 어떻게 작동하는지 보고 볼 수 있기를 원할 것입니다).

   비. 인스펙터에 표시되는 스크립트 속성은 사용자가 스크립트를 로드하지 않는 한 기본적으로 비어 있는 것으로 표시되어야 합니다. 이 경우 스크립트는 사용자 정의 유형으로 사용된 스크립트 유형에서 파생되어야 합니다. 그러나 사용자는 사용자 정의 유형의 스크립트 파일 위치를 알 필요가 없습니다(스크립트라는 개념은 숨겨져 있어야 함). 이것은 사용자 정의 클래스의 문자열 이름이 다른 엔진 내 클래스처럼 GDScript 파서에 의해 인식되어야 하거나(얼마나 쉬운지/어려운지 확실하지 않음) 레코드를 가져오기 위한 일종의 전역 함수가 있어야 함을 의미합니다. 클래스 이름, 예를 들어 add_custom_type("MyClass", "Node", load(res://addons/git-repo/api/my_class.gd), load(res://addons/git-repo/icons/icon_myclass.svg) 에 있는 스크립트의 경우 사용자는 extends MyClass 또는 extends custom("MyClass") 를 사용하여 스크립트를 만들 수 있습니다.

   씨. 사용자가 사용자 정의 유형 파생 스크립트를 노드에 로드하는 경우에만 "이 노드에 스크립트가 있습니다" 아이콘이 장면 독에 표시되어야 합니다.

5. 스크립트에 사용되는 편집기 아이콘은 현재 스크립트에 사용되는 흰색 상자 모양의 아이콘 대신 카테고리 블록에 추가되어야 합니다( property_editor.cpp ). 이것은 사용자 정의 유형 노드 개체에 대한 __meta__ 사전 속성의 일부여야 합니다.

6. 사용자 정의 유형에서 "스크립트 추가"를 클릭하면 4b에서 사용된 방법으로 "상속" 필드를 미리 채워야 합니다.
7. 스크립트를 제거하는 경우 사용자 정의 유형 스크립트는 여전히 후드 아래에 있어야 하며 제거되지 않아야 합니다. 사용자 정의 유형 노드는 로드된 스크립트가 null로 설정된 경우 사용자 정의 유형 스크립트를 백업 스크립트로 효과적으로 사용합니다. 따라서 에디터의 Scene 도크와 인스펙터 도크에 기본 유형의 에디터 아이콘과 스크립트 속성이 계속 표시되어야 합니다. 저는 이미 "스크립트 변수"를 실제 스크립트의 이름으로 바꾸는 기능을 병합하는 과정에 있지만 이러한 모든 변경 사항이 추가되면 업데이트해야 할 수도 있습니다.
8. Object::get_script() 는 사용자 정의 유형 스크립트가 있고 로드된 스크립트가 없는 노드에 대해 null 를 반환해야 합니다.
9. Object::get_property_list , 메소드 및 신호에 대한 유사한 기능은 로드된 스크립트가 없더라도 사용자 정의 유형 스크립트의 내용을 포함해야 합니다.
10. Object::get_custom_script() 같은 두 번째 C++ Object 함수가 필요할 수 있으므로 스크립팅 측에서 이 두 번째 스크립트를 인식하지 못하는 경우에도 엔진이 스크립트가 있는지 확인할 수 있습니다.
11. 사용자 지정 유형 파생이 아닌 스크립트를 개체에 로드하려는 시도는 완전히 실패하고 오류(관련 함수의 &is_valid 참조 bool)를 보고하여 개체가 이를 수행할 수 있는지 확인해야 합니다. 이 정보에 대한 피드백을 제공해야 하는 관련 Godot 편집기 시나리오도 이를 설명하기 위해 업데이트되어야 합니다.

이것은 단지 표면을 긁는 것일 뿐이지만 사용자가 찾고 있는 동작의 종류는 이 정도(그래서 꽤 강렬함)에 대한 것입니다. 필요한 경우 사용자 정의 유형의 존재에 액세스할 수 있도록 하고(따라서 해당 스크립트를 보려면 노드 행에 있는 장면 독에 사용자 정의 유형 아이콘이 있어야 함) 인식할 수 있도록 가능한 한 해당 유형의 존재를 숨기고 싶습니다. 엔진 내 유형으로. 아마도 많은 곳에서 물건을 망가뜨릴 것이기 때문에 제대로 하려면 많은 작업이 필요할 것입니다.

이 중 좋은 소리가 있습니까? 나는 단지 조금 숙고하고 있기 때문에 내가 놓친 항목이 더 있을 것이라고 확신합니다. 이것이 미친 소리처럼 들리면 저에게 알려주십시오. ;-)

편집: 아, 하지만 스크립트가 사용자 정의 유형 스크립트와 일치하는 경우 장면 독에서 스크립트 아이콘을 숨기겠다는 reduz의 제안도 가치가 있을 수 있습니다. 단, get_script() 메서드는 여전히 아무 것도 반환하지 않습니다. Object 자체에 별도의 스크립트 속성을 생성하지 않고도 할 수 있는 방법 이 있을까요? Idk, 왜냐하면 우리가 유지하고 싶지만 custom_type 스크립트 개념으로 유지하기 어려운 개체당 1개의 스크립트에 대한 코드베이스에 이미 많은 가정이 있기 때문입니다.

좋은 제안, 잘 생각했습니다. 이 모든 것이 구현되면 우리가 찾고 있는 동작이 제공될 것이라고 생각하지만 노드당 1개의 스크립트 규칙을 어기는 것은 코드의 많은 예기치 않은 부분에 반향을 일으킬 수 있는 나쁜 소식이 될 수 있다고 생각합니다. 나는 코드베이스를 잘 모르고 내 C++는 평범하기 때문에 소금 한 알과 함께 그것을 가져 가라. Reduz는 위에서 원래 노드당 하나 이상의 스크립트를 사용하려고 시도했으며 "그만한 가치가 있는 것이 더 문제였습니다"라고 말했는데, 이는 나에게 합리적으로 들립니다.

포인트 1~4는 훌륭하고 1-script 규칙을 어기지 않고 달성할 수 있다고 생각합니다. 추상 사용자 정의 유형은 어쨌든 인스턴스화할 수 없으므로 사용자가 편집기에서 스크립트를 추가할 수 없기 때문에 분명히 문제가 되지 않습니다. 그러나 코드를 통해 그렇게 하려고 할 수도 있으므로 필요한 검사와 오류가 있어야 합니다.

포인트 6도 좋고 여기서 우리가 여기서 벗어날 수 있다고 생각합니다. 포인트 6에 따라 새 스크립트를 생성하면 현재 사용자 지정 노드에 연결된 스크립트가 새(파생된) 스크립트로 변경됩니다. 이전(기본) 스크립트가 노드에서 제거됩니다. 새로 첨부된 스크립트는 원래 스크립트에서 파생되므로 모든 기능이 유지됩니다. 나는 기본 클래스(추상이든 아니든)가 있고 파생된 스크립트를 노드에 첨부하는 경우 종종 이 작업을 수행합니다. 여기서 차이점은 사용자 정의 유형에 더 이상 해당 스크립트가 첨부되어 있지 않기 때문에 새 스크립트는 단순히 사용자 정의 노드의 이름이 아니라 extends "res://addons/path/to/base-script.gd" 라고 말해야 한다는 것입니다. 다시 생각해 보면 remove_custom_type() 가 호출되지 않았고 첨부된 스크립트가 여전히 이전 스크립트에서 파생되므로 이것이 필요하지 않을 수 있습니까? 이 점에 대해 명확히 해 주십시오.

포인트 7, 8, 9는 좋고 1-script 규칙을 유지하면서 그다지 어렵지 않을 것입니다. 1-script 규칙을 유지하면 10이 필요하지 않습니다. 11이 좋습니다. 노드 유형을 확장하지 않는 스크립트를 연결하려고 하면 내장 노드가 작동하는 방식이기 때문입니다.

어쨌든, 그것은 많은 작업처럼 들리고 우리는 이미 베타 버전이므로 이것이 3.1 또는 3.2용이 될 것이라고 생각합니다(최근 로드맵을 본 적이 없음).

@RodeoMcCabe 예, 이것은 확실히 3.0용이 아닙니다.

노드당 1개의 스크립트 규칙을 어기는 것은 코드의 예상치 못한 많은 부분에 반향을 일으킬 수 있는 나쁜 소식이 될 수 있습니다.

내 생각과 일치 해. Object는 사용자 정의 백업 스크립트를 인식하지만 다른 개체는 이를 인식하지 못하고 단순히 개체가 단일 스크립트를 갖는 것으로 인식하는 공용 인터페이스를 생각하고 있습니다. 트릭은 스크립트 속성에 대한 setter 및 getter를 편집하는 것입니다. getter는 null을 확인해야 합니다. null이면 대신 백업 스크립트를 반환해야 합니다. setter는 마찬가지로 새 스크립트가 백업 스크립트를 확장하는지 다시 확인해야 합니다. 그렇지 않으면 어떻게든 실패를 보고해야 합니다.

추상 사용자 정의 유형은 어쨌든 인스턴스화할 수 없으므로 사용자가 편집기에서 스크립트를 추가할 수 없기 때문에 분명히 문제가 되지 않습니다.

스크립팅 측면(afaik)에는 추상 유형이 없습니다. 스크립트를 추상화하는 방법을 알고 있다는 말씀이신가요? can_instance 메서드는 스크립팅 측에 노출되지만 스크립트 자체가 유효한지 확인하고 도구인 경우 ScriptServer에서 현재 스크립팅이 활성화되어 있는지 여부를 확인하기만 하면 됩니다. 스크립트 유형의 추상성과는 아무 관련이 없다고 생각합니다.

CreateDialog::_update_search 메서드가 텍스트를 회색으로 표시하거나 선택할 수 없게 만드는 시점 등을 알기 위해서는 클래스가 추상인지 확인할 수 있어야 합니다.

참고로 문제(#13401)의 추상적인 부분에 대한 문제를 만들었습니다.

Object 유형에 backup_script private 멤버를 추가한 다음 이를 사용하여 script 속성 검사를 수행하면 전반적으로 가능하다고 생각합니다.

내 사용자 지정 노드에서 수행하는 작업은 기본 스크립트를 상속하여 기본적으로 사용자 지정 노드 스크립트를 비어 있게 만드는 것입니다...

자동 상속은 플러그인 자체에 영향을 미치며 플러그인을 복제하지 않고는 둘 이상 만들 수 없겠죠?

Multiscript는 올해 두 번째로 추가되었으며 다시 죽이기 쉽습니다(여러 문제 발생).

스크립트 대신 사용자 정의 노드의 기반으로 장면을 허용하면 루트에 스크립트가 없도록 할 수 있습니다.

내 사용자 지정 노드에서 수행하는 작업은 기본 스크립트를 상속하여 기본적으로 사용자 지정 노드 스크립트를 비어 있게 만드는 것입니다...

죄송합니다. 이것이 추상성이나 이전에 했던 다른 제안에 영향을 미친다는 말씀이신가요? 이게 어디서 연결이 되는지 안보이네요...

자동 상속은 플러그인 자체에 영향을 미치며 플러그인을 복제하지 않고는 둘 이상 만들 수 없겠죠?

/addons/ 폴더에 플러그인을 두 번 포함하고 프로젝트 설정의 플러그인 섹션에서 둘 다 활성화하면 문제가 발생한다고 말씀하시려는 건가요? 같은 이름으로 정의된 여러 사용자 정의 유형을 가질 수 없음).

"플러그인을 복제하지 않고는 둘 이상을 만들 수 없습니다."라는 말이 무슨 뜻인지 잘 모르겠습니다. 노드를 생성하고 정의된 사용자 정의 유형 스크립트를 자동 첨부하기 때문에 사용자 정의 유형 노드의 여러 인스턴스를 생성할 수 있습니다. 내 제안은 다음을 수행하도록 CreateDialog의 스크립트 생성 프로세스를 변경하는 것과 관련이 있습니다.

1. 노드의 내장 스크립트가 노드를 인스턴스화할 수 있는지 여부(추상)를 결정하게 합니다.
2. 기본 제공 노드 유형을 만듭니다.
3. 사용자 정의 스크립트를 노드의 backup_script 속성으로 설정합니다(스크립팅 API에 노출되지 않음).
4. 노드의 자체 Object 코드가 다른 모든 사람이 backup_script 를 개체의 공식 script 속성으로 보도록 속이는 작업을 처리하도록 합니다.
5. 편집기 아이콘의 메타데이터 업데이트
6. 간략한 설명(?)에 대한 메타데이터 업데이트

...대신에...

1. 내장 노드를 생성합니다.
2. script 속성으로 사용자 정의 유형 스크립트를 첨부하십시오.
3. 사용자 정의 편집기 아이콘의 메타 데이터를 업데이트하십시오.

Multiscript는 올해 두 번째로 추가되었으며 다시 죽이기 쉽습니다(여러 문제 발생).

나는 동의한다. 멀티스크립팅 개체는 이 시점에서 나쁜 생각이 될 것이라고 생각합니다(어쨌든 실제로 필요하지도 않음). 그것은 내가 제안하는 것이 아닙니다. 공개 보기에서 Object 에는 여전히 1개의 스크립트만 있어야 하지만 스크립트 역할을 대신하는 백업 스크립트를 사용하는 것이 좋습니다(따라서 script 속성에 자신을 할당). 기본 script 속성이 null / unloaded 등으로 설정될 때마다. 이렇게 하면 Object 클래스에 대한 코드베이스의 인터페이스를 변경하지 않고도 "사용자 정의 유형"을 보다 효과적으로 지원할 수 있습니다. 그런 다음 코드(예: CreateDialog 에서 사용자 정의 유형 스크립트를 할당하는 코드)를 추가하거나 제거할 수 있는 이 백업 스크립트 속성에 대한 전용 setter/getter를 가질 수 있습니다. 이렇게 하면 script 속성이 작동하는 방식에 대한 옵트인 수정이 이루어지며 엔진에 필요한 변경 사항이 비교적 적습니다.

노드의 상황에 맞는 메뉴에 대한 새로운 옵션이 "상속된 스크립트 바꾸기" 문제를 해결할 수 있다고 생각합니다. 이 문제는 현재 스크립트에서 상속되는 감지된 모든 스크립트가 포함된 하위 메뉴와 새 스크립트를 클릭할 때 끝에 "새 스크립트"가 있을 수도 있습니다. 대화 상자는 "확장" 필드에 스크립트의 경로를 표시해야 합니다.

"대체 및 상속 스크립트" 편집기 도구를 추가하는 것이 더 쉽고 투명하지 않습니까? 내 말은, 이것은 우리가 Addon 노드를 생성할 때 스크립트가 없을 것으로 예상하기 때문에 문제일 뿐입니다. 그러나 addon 노드는 실제로 Create Node 트리에 추가하는 사용자 정의 노드일 뿐이며 사용자는 이를 알아야 합니다. UX 관점에서(저는 전문가는 아니지만) 편의를 위해 투명성을 희생해서는 안 된다고 생각합니다.

@MarianoGnu @henriquelalves 둘 다 실제로 같지 않습니다. "커스텀 유형"의 의미는 엔진 내 노드 유형을 시뮬레이션한다는 것입니다. 이는 스크립트 자체를 제거할 수 없음을 의미합니다. Node2D가 순수한 노드처럼 작동하도록 하기 위해 Node2D의 Node2D성을 제거할 수 없는 것과 같은 방식으로 노드에 부여하는 기능이 기본 제공됩니다.

위의 Akien의 인기 있는 추천 게시물은 유사한 세부 정보를 다룹니다.

여기서 요점은 커스텀 노드를 정의하는 스크립트는 인스턴스화된 노드의 속성이 아니라 해당 유형의 속성이기 때문에 숨겨야 한다는 것입니다. 따라서 이 스크립트는 사용자 정의 노드에 속성을 부여해야 하지만 내장 노드의 C++ 클래스처럼 인스턴스 노드의 사용자에게 보이지 않아야 합니다. API를 제공하지만 수정이 불가능하고 확장만 가능합니다.

"상속된 스크립트에 대한 대체" 항목을 용이하게 하는 편집기 도구를 만들면 멋지겠지만, 어떤 기능도 사용자 정의 유형 스크립트 또는 그 아래에 있는 스크립트 계층 계층을 볼 수 없어야 합니다. "내장된" 동작을 시뮬레이션합니다.

실제로 gdscript_parser 및 기타 스크립팅 콘텐츠에서 콘텐츠에 액세스하려면 $# EditorNode::get_editor_data().get_custom_types() 가 아닌 ClassDB 싱글톤에 사용자 정의 유형 정보가 포함되어 있는지 확인하는 것이 가장 좋습니다. 모듈은 해당 정보에 액세스할 수 없지만 실제로 액세스할 수 있어야 합니다.

나는 스크립트를 노출시키는 데 개인적인 문제가 없습니다. 이것은 실제로 용어와 철학의 문제입니다. 귀하가 언급한 바에 따르면 할 수 있는 일은 ClassDB에 새 클래스를 추가하고 대신 해당 클래스에 스크립트 속성을 추가하는 것입니다. 노드와 클래스는 메서드 스크립트가 존재하는지 확인하고 클래스 부모를 호출하기 전에 호출해야 합니다. 나는 그것이 가능하다고 생각하지만 RC1 이전에 수행하지 않으면 이전 버전과의 역호환성을 깨뜨릴 것입니다.

@willnationsdev 저는 커스텀 유형이 엔진 내 노드로 취급되는 것에 전적으로 동의하지 않습니다. 저에게 Editor Addons의 '강력함'은 사용자 정의 노드 및 편집기 도구의 "팩"을 만들고 github를 통해 공유하는 것이 얼마나 쉬운지에 달려 있습니다. 이러한 모든 도구와 노드는 사실 복사하여 붙여넣을 수 있는 장면과 스크립트이지만 Godot는 이를 용이하게 하기 위해 Addon API를 제공합니다. 처음 사용했을 때 나도 애드온이 스크립트가 없을 것이라고 예상했지만 엔진 자체가 엔진 내 노드로 취급하는 것처럼 보였기 때문이며 이는 아키텍처가 아니라 UX 문제입니다. 내가 이것을 고칠 것이라고 생각하는 것은 다음과 같습니다.

1. 노드 생성 트리의 사용자 정의 유형은 다른 색상으로 표시됩니다(사용자 정의 유형임을 분명히 나타냄).
2. 장면에 추가하면 스크립트 아이콘이 있지만 약간 투명합니다(기본 스크립트가 있지만 대체할 수 있음을 나타냄). 스크립트 아이콘을 클릭하면 편집기에 사용자 정의 유형 스크립트가 표시됩니다.
3. 사용자 정의 유형의 "스크립트 추가" 버튼은 사용자 정의 유형 스크립트로 "상속" 옵션을 자동으로 채웁니다.

다시 말하지만, 나는 확실히 전문가가 아니므로 Custom-Types != In-Engine Nodes에 대한 나의 원래 가정이 틀릴 수 있습니다. 또한, 귀하의 솔루션은 이 스레드에서 내가 본 것 중 가장 명확한 것이므로 Godot 개발이 그런 식으로 진행되는지 충분히 이해합니다.

편집: 나는 그것을 다시 읽었고, 내 "해결책"은 기본적으로 당신의 첫 6개 솔루션 단계입니다. 하하하.

@henriquelalves @MarianoGnu 나는 그것들의 혼합이 확실히 필요할 것이라고 생각합니다. 사용자 정의 유형 클래스를 ClassDB에 추가하는 것은 필수입니다. Henrique가 제안한 세 가지 제안을 모두 정말 좋아합니다. 특히 아이디어 2(내 별도의 사용자 정의 유형 아이콘 제안보다 훨씬 낫습니다). 그리고 "사용자 정의 유형이 무엇인지"가 어느 정도 투명하게 유지되어야 한다는 데 동의합니다. 나는 균형이 유지되어야 한다고 생각합니다. 사람들은 무언가가 사용자 정의 유형인지 여부와 그것이 의미하는 바를 이해할 수 있어야 하지만 사용자 정의 유형이 엔진 유형처럼 느껴지도록 할 수 있는 한 많이 해야 합니다.

@willnationsdev 나는 assetlib에서 이것을 가져 와서 사용자 정의 노드의 코드를 "기본"스크립트로 옮겼습니다.
충돌_경로_2d-1-modified.zip

내가 볼 수 있는 즉각적인 문제는 플러그인이 스크립트를 로드하고 해당 스크립트가 고유하다는 것입니다. 다른 사용자 정의 노드를 추가하면 _같은_ 스크립트를 갖게 됩니다.

그렇다면 이 경우 플러그인에 대한 스크립트 교체는 무엇을 의미합니까? (어쩌면 아무것도, 확실하지 않습니다).

스크립트를 교체하는 데 문제가 없으면(일부 경우 도구 모드가 만족스럽지 않을 수 있음) 사용자 지정 노드 메뉴에 "사용자 지정 스크립트 확장" 항목을 추가하여 해당 교체 프로세스를 수행할 수 있습니다.

@henriquelalves @eon-우리도 같은 생각을 하고 있는 것 같아요. 나는 이것이 무엇보다 UX 문제라는 점에 동의합니다. 지금까지 저는 이 접근 방식에 부분적입니다. 왜냐하면 그것이 가능한 한 단순하게 유지되고 있다고 생각하기 때문입니다. 이는 항상 좋은 IMO입니다.

스크립트를 교체하는 데 문제가 없으면(일부 경우 도구 모드가 만족스럽지 않을 수 있음) 사용자 지정 노드 메뉴에 "사용자 지정 스크립트 확장" 항목을 추가하여 해당 교체 프로세스를 수행할 수 있습니다.

확장 스크립트는 플러그인 스크립트를 상속받아야 하기 때문에 교체해도 문제 없을 것 같습니다. 그러나 다시, 나는 코드베이스에 익숙하지 않습니다. 어쨌든, 나는 2 센트를 주었으므로 여기에서 실제 개발자에게 맡길 것입니다. ;)

@willnationsdev 죄송합니다. 추상적인 내용을 혼동했습니다. 내 "추상" 기본 클래스에는 단순히 _init()에 인쇄 문이 있어 실수로 인스턴스화했는지 알려줍니다....

여기서 차임하기 위해 사용자 정의 노드 유형은 사용자 정의 스크립트 설정, GDScript에서 이름으로 참조 및 상속하는 기능, 유형의 기본 스크립트를 제거할 수 없는 기능을 포함하여 절대적으로 엔진 유형처럼 작동해야 합니다. 이는 엔진에 의해 구현된 노드의 동작을 모방하여 내부 일관성과 사용 용이성을 촉진합니다.

그것이 "커스텀" 노드임을 보여주는 문제와 관련하여, 나는 노드가 개체의 기본 스크립트 파일을 보여주는 "도움말에 표시" 위의 검사기 드롭다운에 항목을 가질 것을 제안합니다. 사용자와 개발자의 관점에서, 당신은 그것을 사용하는 것만으로도 그것이 사용자 정의 노드라는 것을 알아야 하며(누가 그것을 프로젝트에 추가했습니까?) "사용자 정의" 노드(IMO)의 목표는 구별할 수 없는 유형을 GDScript에서 정의할 수 있도록 하는 것입니다. 내장 엔진 유형에서.

@Web-eWorks 실제로 이 작업을 하고 있으며(지금 이 순간) 상당한 부분을 완료했습니다(아직 갈 길이 조금 남아 있습니다). Object 클래스에 백업 스크립트를 설정하고 새 API를 사용하도록 EditorPlugin 메서드를 업데이트하는 것과 함께 ClassDB에 사용자 지정 유형에 대한 저장소를 만들었습니다. 여전히 관련 ClassDB 함수( can_instance 및 get_parent_class 등)를 업데이트하고 모든 Editor/CreateDialog 항목을 업데이트해야 합니다.

@willnationsdev ClassDB 에 등록한다는 것은 플러그인을 만드는 사람들이 충돌을 방지하기 위해 클래스에 접두사를 붙여야 한다는 의미이기도 합니다^^"

@Zylann 예, 불행히도 필요합니다.

이 시점에서 바인딩과 핵심 변경 사항의 대부분을 정리했다고 생각합니다. 이제 Editor, CreateDialog 및 EditorHelp / DocData 클래스(및 GDScript 컴파일러)를 업데이트하기만 하면 됩니다.

앞서 언급했듯이.. 아직 제안된 솔루션이 좋지 않다고 생각합니다.
가장 가능성이 높은 것을 시도하기 전에 저에게 확인하십시오.
거부되었습니다.

2018년 2월 7일 20시 5분에 "Will Nations" [email protected] 에서 다음과 같이 썼습니다.

@Zylann https://github.com/zylann 예, 필요할 것입니다.
안타깝게도.

이 시점에서 나는 대부분의 바인딩과 핵심을 정리했다고 생각합니다.
변경. Editor, CreateDialog 및
이제 EditorHelp / DocData 클래스.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment-363893711 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z2xIYRcs0BFDqTyiFwqlhQWTqjEZtks5tSgIVgaJpZM4JejbZ
.

@reduz 글쎄, 나는 당신이 이전에 제기한 우려를 고려하려고 노력했습니다.

나는 어떤 종류의 멀티 스크립트 시스템도 구현하지 않습니다. 나는 또한 ClassDB에서 ClassInfo 개체로 가장하는 스크립트를 만들지 않습니다. 지금까지 내가 한 일은 ClassDB의 상속 계층에 스크립트(RefPtr를 통해)를 첨부하는 것뿐입니다. Object 클래스는 일반 스크립트 할당이 백업 스크립트의 상속 계층 구조를 침해하려고 시도할 때마다 "backup_script"만 사용합니다.

아 그렇군요.. 그럼 이것의 사용 사례는 무엇입니까?

2018년 2월 7일 20시 32분에 "Will Nations" [email protected] 에서 다음과 같이 썼습니다.

@reduz https://github.com/reduz 글쎄, 나는
이전에 제기한 우려 사항을 설명합니다.

나는 어떤 종류의 멀티 스크립트 시스템도 구현하지 않습니다. 나도 아니야
스크립트를 ClassDB에서 ClassInfo 객체로 가장합니다. 내가 가진 모든
지금까지 RefPtr을 통해 스크립트를 상속에 첨부했습니다.
ClassDB의 계층. Object 클래스는
일반 스크립트 할당이 침해를 시도할 때마다 "backup_script"
백업 스크립트의 상속 계층에서.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment-363900920 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z2yn68Iy6AgAKJHZ4qImH4UBAm5skks5tSghSgaJpZM4JejbZ
.

사용 사례는 누군가 EditorPlugin을 사용하여 엔진에 새로운 유형의 노드를 도입하고 싶지만 해당 노드의 스크립팅된 유형이 편집 가능하기를 원하지 않는 경우입니다(그들은 노드와의 상호 작용이 엔진 내 유형을 모방하기를 원합니다. ). 따라서 예를 들어 백업 스크립트만 있는 노드에서 get_script() 를 시도하면 null을 반환합니다. set_script(null) 시도하면 스크립트가 백업 스크립트로 설정됩니다. set_script(a_script) 를 시도하면 새 스크립트가 백업 스크립트의 상속 계층에 있는 경우에만 스크립트를 성공적으로 할당합니다.

UX의 경우 백업 스크립트만 있으면 스크립트 아이콘이 편집기에 투명 아이콘으로 표시되도록 할 계획입니다. 이 경우 스크립트를 추가하는 버튼은 여전히 ​​"스크립트 제거" 버튼이 아닌 "스크립트 추가" 버튼이며, 이를 클릭하면 텍스트에 유형 이름이 미리 채워집니다(비록 사용자가 스크립트 유형을 GDScript/VisualScript 등에서 변경하는 경우 스크립트 경로로 미리 채움). 다른 스크립트가 할당되면 투명 아이콘이 다시 불투명해집니다. 두 경우 모두 스크립트 아이콘을 클릭하면 활성 스크립트 소스 코드(다른 스크립트가 없는 경우 백업 스크립트 소스 코드)로 이동합니다.

나는 이것의 이점을 실제로 보지 못한다는 것을 인정해야 합니다.
특정 사용 사례를 생각하고 있습니까?

2018년 2월 7일 20시 46분에 "Will Nations" [email protected] 에서 다음과 같이 썼습니다.

사용 사례는 누군가가 새로운 유형의 노드를 소개하려는 경우입니다.
EditorPlugin을 사용하는 엔진이지만 스크립팅된 유형의
편집 가능한 노드(그들은 노드와의 상호 작용이 모방하기를 원합니다.
엔진 내 유형). 예를 들어 노드에서 get_script()를 시도하면
백업 스크립트만 있으면 null을 반환합니다. 내가 시도하면
set_script(null), 스크립트는 백업 스크립트로 설정됩니다. 만약 내가
set_script(a_script)를 시도하면 성공적으로 할당됩니다.
새 스크립트가 백업의 상속 계층 구조에 있는 경우 스크립트
스크립트.

UX의 경우 스크립트 아이콘이 편집기에 표시되도록 할 계획입니다.
백업 스크립트만 있는 경우 투명 아이콘입니다. 그 경우,
스크립트를 추가하는 버튼은 여전히 ​​"스크립트 추가" 버튼이 아니라 "스크립트 추가" 버튼입니다.
"스크립트 제거" 버튼을 클릭하고 텍스트를 이름으로 미리 채웁니다.
유형의(하지만 스크립트 경로로 미리 채워야 할 수도 있습니다.
사용자가 GDScript/VisualScript에서 스크립트 유형을 변경하는 경우
등.). 다른 스크립트가 할당되면 투명 아이콘
다시 불투명해집니다. 두 경우 모두 스크립트 아이콘을 클릭하면
활성 스크립트 소스 코드로 이동합니다(백업 스크립트 소스 코드가
다른 스크립트는 없습니다).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/6067#issuecomment-363904934 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AF-Z26oeOMT4HpjzDsX8eygMSeUhbTgVks5tSgurgaJpZM4JejbZ
.

높은 수준의 사용 사례는 플러그인(EditorPlugins, PluginScript/SubModule 시스템)이 '완벽한' 사용자 정의 노드 유형을 정의할 수 있도록 하는 것입니다. 현재 사용자 정의 유형 시스템은 "노드의 스크립트"를 위한 얇은 공장으로, 새로운 노드 유형을 구축하려는 경우 수많은 워크플로 및 사용성 문제가 있습니다. 게임 플레이 코드로 사용자 정의 노드를 확장합니다(내장 노드와 반대). 더 시급한 문제는 다른 사용자 지정 노드에서 상속되는 사용자 지정 노드를 생성할 수 없다는 것입니다.

일부 특정 사용 사례는 저수준 노드를 생성하는 것입니다. 파괴 가능한 지형에 대한 행진 큐브 기반 복셀 GridMap 구현, ala Minecraft 또는 행진 큐브/이중 윤곽을 사용하는 기타 지형 시스템; 사용자 정의 컨트롤 유형(많은 현대 게임에서 구현되는 원형 메뉴 컨테이너, 엔진 사양 밖에 있을 만큼 충분히 높은 모든 유형의 저수준 컨트롤); 새 노드를 등록하는 플러그인을 빌드하려는 모든 장소. 이러한 각각의 경우 일반적으로 게임플레이 코드를 처리하기 위해 사용자 정의 스크립트를 추가하고 "구현" 코드(GDScript/GDNative로 작성)와 분리되도록 합니다.

여기서 전달하지 못한 것은 엔진 모듈을 작성하고 이에 대해 컴파일할 필요 없이 커스텀 노드가 엔진 노드처럼 작동하도록 하는 것이 목표라는 것입니다.

이러한 개선은 특정 기능(많은 것이 있음에도 불구하고)에 의해 반드시 구동되는 것이 아니라 "현재 방식은 후진하고, 어설프고, 지루하다"는 근거에 의해 이루어집니다. 완전히 구현된다면 이 시스템은 엔진을 재컴파일할 필요 없이 GDScript / GDNative에서 엔진의 내장 유형을 확장하는 매우 강력한 방법을 허용합니다. 디자인 관점에서 이것은 말 그대로 현재 시스템에 대한 직접적인 개선입니다.

그 모든 후에 특정 사용 사례를 원한다면: 전체 플러그인 / AssetLibrary 생태계 .
이것이 이 변경으로 인한 이점의 범위입니다.

자, 다음은 명시적인 예입니다.

다양한 새로운 유형의 노드를 소개하는 godot-skills 플러그인이 있습니다.

효과: Functor 수정
Targeter: 비슷하지만 다른 노드를 찾고 수집합니다.
스킬: Targeter와 Effects의 계층을 결합하여 노드를 찾고 모두에 효과를 적용합니다.
SkillUser: 여러 기술을 "소유"

나는 이러한 각 노드가 사용자가 직접 장면에 생성하고 추가할 수 있는 것을 원합니다. 그러나 이러한 노드 각각은 기본 유형으로 작동하도록 설계되었습니다. 기본적으로 사용할 수 있는 기능이 많지 않으며, 그렇지 않으면 관련될 노드에 파생 스크립트를 배치해야 합니다. 이와 같은 사용 사례의 경우 사용자가 특정 스크립팅된 기능 집합을 제거할 수 없도록 하려는 노드를 만드는 것이 유용할 수 있습니다. 예를 들어, 사용자가 장면에 추가하는 모든 Targeter 노드에 비 Targeter 파생 스크립트를 배치하지 못하도록 하고 싶습니다. 이는 스킬이 Targeter를 자식으로 가질 때 얻을 수 있는 즉각적인 기능이 있기 때문입니다(Area2D 및 CollisionShape2D 노드와 유사).

현재 워크플로에서는 사용자가...

1. 사용자 정의 유형 노드 추가
   2a. 첨부된 스크립트를 제거하고 스크립트 추가 버튼을 클릭하거나
   2b. 노드에서 스크립트 속성 설정
2. EditorPlugin이 파생하려는 사용자 정의 유형 스크립트를 유지하는 대화 창에서 찾으십시오.

이 시스템을 사용하면 이 모든 것을 다음과 같이 바꿀 수 있습니다.

1. 사용자 정의 노드 유형을 추가하십시오.
2. 스크립트로 추가(자동으로 사용자 정의 유형 스크립트 파생 시작)

사용자는 엔진 내 유형을 파생시키는 고유한 사용자 정의 유형을 동적으로 추가할 수 있습니다(단순한 사용성을 위해). 또한 문제의 노드에 스크립트 기능이 존재하도록 하여 플러그인 기능의 보안을 강화합니다. 현재 사용자는 스크립트를 쉽게 제거하고 문제를 해결할 수 있습니다(바람직하지 않음). 또한 누군가가 노드에서 스크립트를 "지우기"를 원하면 해당 노드는 사용자 지정 유형 기능을 잃지 않아야 합니다(이것은 큰 기능입니다). 사용자 정의 유형 스크립트를 갖는 것으로 되돌아가야 합니다.

좋아, 그래서 업데이트. 나는 현재 다음을 가지고 있습니다.

• ClassDB 는 이제 사용자 정의 유형을 직접 추가 및 제거할 수 있습니다.
• EditorPlugin 에는 사용자 정의 유형뿐만 아니라 아이콘과 같은 기타 편집기 관련 데이터를 추가 및 제거하는 유사한 사용자 정의 유형 메소드가 있습니다. 이 메서드는 EditorPlugin 가 활성/비활성으로 전환될 때마다 방출되는 새 신호에 연결됩니다.
• GDScript는 이제 스크립트에서 상속할 사용자 지정 유형의 이름에서 직접 상속할 수 있습니다.
• 장면 독은 현재 스크립트가 노드의 사용자 정의 유형 스크립트와 일치할 때 투명한 스크립트 아이콘을 생성합니다. 그것을 클릭하면 편집기에서 사용자 정의 유형 스크립트가 열립니다. 이 상태에서는 "스크립트 제거"가 아닌 "스크립트 추가" 버튼이 표시됩니다. 선택하면 이 버튼은 "상속" 필드를 사용자 정의 유형 스크립트의 이름으로 미리 채웁니다(null이 아닌 경우).
• 스크립트를 제거하려고 하면 사용자 정의 유형 스크립트가 스크립트 값으로 다시 할당됩니다. 따라서 스크립트를 제거하려면 먼저 set_custom_script(RefPtr()); 로 사용자 정의 유형 스크립트 값을 지워야 합니다.
• 노드 생성 대화 상자는 사용자 정의 유형에 대한 상속 관계 및 추상 노드를 올바르게 표시합니다.
• project.godot 파일은 실행된 게임이 나머지 게임이 시작되기 전에 main.cpp 에 설정할 수 있도록 모든 사용자 정의 유형으로 채워집니다.

남은 과제 완료...

• 사용자가 사용자 정의 유형에 대한 클래스 API 문서를 생성하도록 허용합니다.
• script_create_dialog.cpp 에서 사용자가 Inherits 필드를 편집할 수 없도록 하는 별도의 버그를 모두 수정합니다.
• GDScript 전역 맵/배열에서 사용자 정의 유형을 동적으로 추가 및 제거하는 방법 찾기 *
• VisualScript에서 사용자 정의 유형 지원 구현

* 실제로 이것에 대해 몇 가지 질문이 있습니다.

먼저 GDScriptLanguage 클래스에서 전역을 제거하는 방법 없이 gdscript_compiler.cpp 파일에서 add_global_constant / _add_global 봅니다. 싱글톤이 추가되거나 제거될 때마다 완전히 다시 초기화됩니까? 전역 식별자는 어떻게 동적으로 편집됩니까? 이는 사용자가 스크립트를 변수에 먼저 로드하지 않고도 MyNode.static_func() 를 수행할 수 있도록 하기 위한 것입니다.

내가 그것에 있는 동안, Godot의 GDScript는 특히 이 변경의 일부로 네임스페이스 도입으로 큰 이점을 얻을 수 있을 것 같습니다. 플래그를 지정하려면 올바른 구분 기호를 찾아야 하지만 고유한 스크립트를 만들 때 엔진 및 플러그인 유형의 이름 충돌에 대한 우려를 없앨 수 있습니다. 예를 들어 \ 가 선택 구분 기호라고 가정하면...

extends Node # an in-engine type.
extends \ # triggers an error if left alone, but would prompt a dropdown of the plugin API names for auto-completion as well as the names of any scripts in the current project that are not part of a plugin.
extends \MyPlugin\ # triggers an error if left alone, but would prompt a dropdown of the scripted types that exist for the plugin
extends \MyNode # extends my_node.gd somewhere in res://
extends \MyPlugin\MyNode # extends my_node.gd somewhere in res://addons/[my_plugin_something?]/

func _ready():
    print(\MyNode.CONSTANT) # would print CONSTANT in the current project's my_node.gd script

어쨌든 이 모든 ^는 현재 주변에서 던지고 있는 아이디어일 뿐입니다. 네임스페이스가 도입된 경우 EditorNode 의 resource_saved 신호를 사용하여 스크립트가 파일 이름을 기반으로 이름과 자동으로 연결되도록 할 수도 있습니다. 그것들은 반드시 사용자 정의 유형일 필요는 없지만(객체에서 스크립트를 제거할 수 없다는 의미에서) 매우 유용하고 직관적인 이름만으로 액세스할 수 있습니다. 스크립트는 맨 위에 네임스페이스 제목을 제공하여 기본 자동 이름 지정( filename.capitalize().replace(" ", "") ?)을 재정의할 수도 있습니다(예: \MyPlugin\mynode ). 이제 갑자기 "\MyPlugin\mynode"는 해당 스크립트의 전역 식별자입니다.

여기까지의 진행 상황의 스니펫 이 있습니다.

@willnationsdev \ 를 선택하지 마십시오. 이미 이스케이프 및 여러 줄에 사용되었습니다. . , : 또는 :: 가 더 좋아 보입니다.

@Zylann 프로젝트에 추가되는 모든 노드의 접두사로 구분 기호를 사용할 계획이었습니다. 따라서 예를 들어 res://container.gd 에 있는 스크립트는 실제 Container 클래스와 충돌하는 것을 원하지 않습니다. 마침표(.)를 사용하면 다음과 같이 보일 수 있습니다.

var engine_type = Container.new()
var script_type = .Container.new()
var plugin_script_type = .MyPlugin.Container.new()

그런 형식에 대해 반대하는 사람이 있습니까?

편집하다:

파생 클래스 함수 내에서 부모의 메서드를 호출하지만 문제가 발생할 수 있습니다.

func _virtual_method():
    ._virtual_method() # parent stuff
    # my stuff

흠 ... 상수 및 / 또는 변수에 문제가 있습니까? 그렇지 않은 경우 괄호는 수퍼 함수이고 그렇지 않으면 가능한 네임스페이스 식별자임을 의미한다고 가정할 수 있습니다.

솔직히 말해서 지금은 네임스페이스를 보류하고 싶습니다. 나중에 도입될 수 있으며 가능한 한 빨리 현재 시스템을 도입하고 싶습니다. 우리는 또한 자동 이름 등록을 위해 _정말_ 잘 생각한 시스템이 필요하며, 아마도 전체 애드온 조직 구조의 재작업으로 확장될 수 있습니다. 이는 상당한 양의 작업이며 이 문제의 범위를 벗어납니다.

개인적으로 '자동 등록' 스크립트의 이름을 파일의 선언으로 제어하는 ​​것이 좋습니다.

register <NAME> extends <PARENT>

또는 GDScript에 이미 존재하는 현재 extend <NAME> 프롤로그를 기반으로 하는 유사한 구문입니다.

편집: 또한 부모(예: Spatial)에서 파생된 스크립트를 사용자 지정 자식(예: Sprite3D->CustomType)에 할당하는 방법을 묻고 싶었습니다. 이것은 이미 엔진 유형에 대해 작동하며 사용자 정의 유형 자체에서 파생되도록 할당된 스크립트를 제한하는 것은 잘 작동하지 않을 것입니다.

@Web-eWorks 충분히 공정합니다. 현재 API를 완성하기 위해 작업한 다음 PR이 제출되면 네임스페이스에 대한 새 문제를 열겠습니다.

@Web-eWorks가 의미하는 바를 잘 이해하더라도 여전히 이 질문이 있습니다. Object 에 단일 스크립트만 있을 수 있다는 사실을 어떻게 해결할 수 있습니까? 어떻게 ... "스크립트 가능"합니까? 그와 별개로 ClassDB에 등록하는 것은 프로그래머와 디자이너의 사용 측면에서 글로벌 식별자에 불과하기 때문입니다.

@Zylann 내 포크에서 수행한 작업은 Object custom_script 속성을 만드는 것입니다. 값이 할당된 경우에만 중요하지만 스크립트 가 할당된 경우 기본 script 속성에 대한 백업 스크립트/제약 조건 역할을 합니다. script custom_script 설정되고 Script 를 script 에 새로 할당하면 Script 인스턴스는 custom_script 에서 파생됩니다. 그리고 이 모든 것은 배후에서 Object 에 의해 관리되므로 엔진에 관한 한 Object 에는 여전히 1개의 실제 스크립트만 있습니다.

ClassDB 콘텐츠에는 등록된 사용자 지정 유형의 보조 맵이 있으며 스크립트 자체 및 기타 정보를 할당한 이름에 매핑합니다. 그런 다음 관련 상속 방법( get_class_list , is_parent_class , get_parent 등)과 함께 해당 이름과 상속 계층 구조를 제공합니다. 그리고 이것은 일부 방법에 대한 옵트인 플래그로 수행됩니다. get_class_list 는 이제 true 를 두 번째 매개변수로 전달하는 경우 사용자 정의 유형만 포함하는 bool 플래그를 사용합니다. 이것이 엔진의 나머지 부분과의 호환성이 깨지는 것을 방지하는 방법입니다.

@willnationsdev 그래서 스크립트가 내장 클래스처럼 작동하도록 하는 시스템에서 사용자가 모든 스크립트와 애드온이 내장 클래스와 같은 일류 시민으로 간주되고 "구식" 방식을 버리기를 원하지 않는 이유는 무엇입니까?

아. 현재 스크립트가 작동하는 방식은 extends Node VBoxContainer 에 넣을 수 있고 여전히 잘 작동한다는 것입니다. 현재 구현이 사용자 정의 유형에 대한 동작을 중단하면 몇 가지 문제가 있습니다. 엔진 유형에서 직접 파생된 '일반' 스크립트를 사용하면서 사용자 정의 스크립트의 동작을 유지할 수 있는 방법이 있습니까?

@Zylann 이것이 바로 내가 네임스페이스를 도입하여 엔진 내 유형과 충돌하지 않고 이름을 통해 스크립트와 플러그인의 스크립트를 안전하게 통합할 수 있는 이유입니다. 사람들이 새로운 방법만 사용하고 옛 방법을 무시하는 것을 막는 것은 없을 것입니다. 그리고 나는 실제로 그것이 전반적으로 더 나을 것이라고 생각합니다. 매번 명시적 경로를 사용해야 하는 것은 힘든 일입니다.

@Web-eWorks 여기에서 팔로우하고 있는지 확실하지 않지만...

커스텀 유형은 특히 상속을 위해 엔진 내 유형처럼 작동합니다. 따라서 사용자 지정 유형에서 확장하는 경우 엔진 내 계층 구조의 완전히 다른 분기에서 확장하는 것과 같습니다. 전. Node 확장하는 사용자 정의 유형 MyNode 을 생성하면 Node2D 를 넣을 수 없는 것처럼 해당 스크립트를 VBoxContainer 에 넣을 수 없습니다. Node2D "켜기" a VBoxContainer . 이것은 실제로 의도된 동작입니다.

이제 네임스페이스 개념을 사용하면 사용자 정의 유형이 아닌 명명된 스크립트를 갖는 것이 이상적입니다. 따라서 이 경우 Node 를 확장하는 스크립트를 만들고 Node , VBoxContainer AND MyNode 에 넣을 수 있습니다. 말이 돼?

그래서 내가 말하려는 것은 MeshInstance $를 상속하는 사용자 정의 유형 MyNode 을 만들고 편집기에서 해당 노드의 인스턴스를 만들고 Spatial 를 상속하는 스크립트를 추가하려고 시도하는 경우입니다. MyNode 유형의 노드에 연결하면 제대로 작동합니까? 그것은 '엔진' 노드에서 제대로 작동하며, 이것이 우리가 에뮬레이트해야 하는 동작입니다.

이는 '사용자 수준' 스크립트의 상속 계층 구조에 관계없이 사용자 지정 유형의 스크립트가 호출되는지 확인하는 문제이기 때문에 네임스페이스에 독립적이어야 합니다.

@Web-eWorks 예, 작동합니다. ClassDB 의 custom_types 맵에 있는 모든 "첫 번째 수준" 항목은 $#$ classes #$ 맵의 유형에 다시 링크되어야 합니다. 그렇지 않으면 오류가 발생하고 사용자 정의 유형이 생성되지 않았습니다. 이렇게 하면 사용자 지정 유형에서 최대 Object 까지 엔진 유형으로 다시 이동할 때 상속 체인이 유지됩니다.

@willnationsdev 확실히 하자면 MyNode 에 _ready 메서드를 추가하고 Spatial에서 파생된 사용자 스크립트의 준비 노드를 추가하면 Spatial._ready(), MeshInstance._ready(), MyNode._ready(), script._ready() 와 같이 호출됩니다. ? (또는 _ready 가 발송되는 주문에 상관없이.)

나는 이것이 불필요하고 혼란스럽다는 내 견해를 여전히 고수합니다. 이 문제는 코어 엔진이 아닌 에디터 UI에서 해결해야 합니다.

@reduz 그렇다고 Editor UI만으로는 해결할 수 있는 문제가 아닙니다. 개체에 대한 사용자의 스크립트 조작을 제어하려는 경우에는 그렇지 않습니다. 많은 사람들이 설정하고 싶어하는 기능인 것 같습니다.

gdscript_compiler가 스크립팅된 유형에 대한 새로운 전역 식별자를 설정하기 위해 ClassDB에서 모두 추적하고 ClassDB가 엔진의 모든 상속 정보를 관리하도록 허용하는 대신 EditorData의 콘텐츠를 참조해야 한다고 제안하고 있습니까?

물론 에디터 UI의 관점에서 풀어야 할 부분도 있지만, 핵심적으로 풀어야 할 부분도 있다. ClassDB의 관점에서 엔진에 사용자 정의 유형을 추가하는 _actual_ 유형은 매우 강력하고 궁극적으로 필요한 기능입니다. 혼란스러운 한, 나는 그것이 현재 시스템보다 더 혼란스럽지 않고 아마도 덜할 것이라고 여전히 주장합니다.

@Web-eWorks 동의합니다. 상속 데이터를 편집기에서 추적하도록 하는 것은 실제로 내 생각에 훨씬 더 혼란스러울 것입니다. 그리고 편집기 없이 게임을 실행하면 해당 유형 정보가 더 이상 존재하지 않기 때문에 이상한 해결 방법이 됩니다 project.godot ClassDB 시작 시 사용자 정의 유형을 추가하기 위한 EditorPlugins 없음으로 인해 장면을 실행할 때 GDScript가 컴파일에 실패했습니다).

@Web-eWorks 그리고 이전 질문에 대답하기 위해 예, 제대로 작동합니다.

내 테스트 시나리오에는 $ GDSkillsEffect > GDSkillsAPI > Node 를 확장하는 Node.gd 가 있고 각 스크립트에 구현된 _ready 메서드는 적절한 주문: API, 효과, Node.gd.

두 개의 스크립트가 모두 이름으로 사용자 정의 유형 스크립트에서 상속을 시도할 때마다 현재 일종의 무한 루프 오류가 발생하고 있습니다. 전. Node.gd 에 extends GDSkillsEffect 가 있고 gdskills_effect.gd 에 extends GDSkillsAPI 가 있으면 gdskills_effect.gd 또는 gdskills_api.gd 를 수정하고 저장하려고 하면 편집기가 무한히 "로드"한 다음 충돌합니다. 그것이 아마도 현재 나의 가장 큰 버그일 것이다.

@willnationsdev 아, 아니요, Node.gd 확장 Node , _not_ GDSkillsEffect 에 대해 이야기하고 있습니다. _that_이 작동하면 모든 것이 좋습니다.

예를 들어 다음은 장면 트리의 표현입니다.

-> User Script:
  extends Node
  func _ready(): pass

@Web-eWorks 아, 무슨 말씀인지 알겠습니다. 글쎄, 그것은 작동해야하지만 방금 테스트했으며 Object::set_script() 논리가 어떤 이유로 차단하는 것처럼 보이므로 수정해야 할 버그입니다. XD Node 가 사용자 정의 유형 스크립트를 파생시키지 않는다는 것을 감지했기 때문에 실패하는 것입니다.

@Web-eWorks 언급했듯이 이것은 ClassDB에서 변경할 필요가 없습니다.

각 스크립팅 언어가 다르게 처리하기 때문에 이것이 핵심에서 해결될 필요가 있다고 생각하지 않습니다. Mono에서 새 클래스를 쉽게 만들 수 있으며 작동할 것입니다. GDScript의 경우 스크립트 파일을 미리 로드된 전역으로 노출하는 간단한 경우일 수 있습니다. PR에서 제안한 만능 솔루션은 확실히 갈 길이 아닙니다.

@willnationsdev 나는 당신의 노력에 감사하지만 이것은 이미 끝없이 논의되었으며 합의는 다음과 같습니다.

• 사용자 정의 유형을 추가하는 것은 스크립트 언어마다 다르므로 실제로 C++ 항목을 등록하기 위한 목적으로만 사용되는 ClassDB에서 무언가를 해킹하는 것은 올바른 방법이 아닙니다.
• 이러한 길이로 이동하기 전에 사용자 정의 노드의 스크립트를 확장하려는 경우 UI 사용성을 개선하여 단순 상속을 생성할 수 있습니다.
• 일반적으로, 코너 케이스를 처리하기 위해 코어 엔진에 핵을 추가하는 것은 결코 옳은 방법이 아닙니다. 핵심은 해킹이 없는 상태로 유지되어야 합니다.

@willnationsdev 참고로 엔진 동작은 상속 계층 구조에서 _something_을 확장하거나 그 이전의 스크립트를 노드에 추가할 수 있다는 것입니다. 따라서 extends Spatial MeshInstance 에 추가할 수 있지만 Control 또는 Node 에는 추가할 수 없습니다 Spatial . 이것은 복제해야 하는 동작입니다. (부담없이...)

@reduz 그러나 Mono에서 새 클래스를 생성하면 엔진의 상속 계층 구조에 추가됩니까? 또는 편집기의 노드 생성 대화 상자? 아마도 이것의 목적이 무엇인지 간결하게 기술하는 새로운 문제를 열어야 할 필요가 있을 것입니다. 왜냐하면 저는 우리가 여기서 같은 것에 대해 이야기하고 있지 않다고 생각하기 때문입니다.

ClassDB 수정의 요점은 엔진을 다시 컴파일할 필요 없이 새로운 유형의 노드(또는 리소스)를 등록할 수 있도록 하는 것입니다. @willnationsdev 가 동일한 분기에서 작업하고 있는 접선 문제이지만 GDScript에 새로운 사용자 정의 전역을 추가하지 않는 것이 좋습니다.

이것의 요점은 해킹을 추가하는 것이 아니라 엔진 유형을 확장하기 위해 잘 설계된 _시스템_을 만드는 것입니다.

@Web-eWorks 엔진 상속 계층은 스크립트가 아닌 C++용입니다. 두 가지를 혼합하려는 시도는 처음부터 개념적으로 잘못되었습니다.

아마도 노드 생성 대화 상자가 새 클래스가 추가된 것처럼 보이게 하는 것으로 오해할 수 있으므로 이러한 사용자 정의 유형을 스크립트를 명확하게 포함하는 것으로 표시하는 것이 좋습니다.

@Web-eWorks Mono를 사용한다면 새로운 클래스이기 때문에 마치 새로운 클래스가 추가된 것처럼 투명하게 보일 것입니다. GDScript의 경우 클래스는 기본적으로 파일이므로 이 방법으로 수행할 수 없으므로 이를 수행하는 방법은 설정을 위해 전용 UI가 있는 새 전역을 추가하는 것일 수 있습니다(싱글톤 자동 로드의 경우와 같이)... 그러나 이것은 여전히 ​​엔진 클래스가 아닌 스크립트 클래스입니다.

@willnationsdev 내 요점은 엔진에 실제 새 클래스를 추가하는 것처럼 보이게 하는 것이 잘못되었다고 생각한다는 것입니다. 그렇지 않기 때문입니다. 혼란스러울 수 있습니다. 스크립트가 있는 노드일 뿐이므로 스크립트를 숨기는 대신 만들기 대화 상자에서 더 잘 보이도록 하는 것이 맞다고 생각합니다.

@reduz 글쎄요. Node+Script는 Scene입니다. add_custom_type 메커니즘은 표준에 따라 기술적으로 '클래스'가 아니더라도 '새 클래스'를 등록하는 Mono처럼 작동해야 합니다. ClassDB를 건드릴 필요 없이 할 수 있는 방법이 있다면 모두 귀담아 듣겠습니다.

또한 @akien-mga는 장면 트리 보기에서 사용자 지정 노드의 스크립트를 숨길 수 있다고 제안하여 사용자가 해당 스크립트를 만들고 실수로 편집한 것에 대해 혼동을 주지 않도록 했습니다(그러나 여전히 맨 아래의 검사기에는 표시됨) .

이러한 노드에서 스크립트를 추가하면 상속 모드에서 생성 대화 상자가 열리므로 사용자 워크플로에는 여전히 매우 투명하지만 엔진의 일부가 아닌 사용자 지정 노드임이 분명합니다.

@willnationsdev 구체적으로 구현 범위를 자세히 설명하는 보다 간결한 새 문제를 여는 데 이의가 있습니까?

@Web-eWorks 노드 + 스크립트는 장면이 아니며 트리 레이아웃의 노드는 장면입니다. 노드뿐만 아니라 사용자 지정 리소스 유형을 추가할 수도 있습니다.

그리고 아니요, 새 클래스를 등록하는 것처럼 작동하지 않아야 합니다. 스크립트가 미리 추가된 C++ 클래스라는 것이 분명해야 합니다.

@Web-eWorks 예, 저에게는 문제가 되지 않습니다. 저를 언급해주시면 핑을 받을 수 있습니다. 그래도 별도의 문제가 필요한지 확실하지 않습니까?

다른 관점에서 보세요. 당신의 주장은 마치 새로운 엔진 유형으로 엔진 유형을 확장하는 것처럼 사용자에게 보이도록 하는 것입니다.

제 관점은 새로운 엔진 유형이 아니라 스크립트를 사용하여 엔진 유형을 확장하고 있다는 것입니다. 그리고 사용자는 바보가 아니며 이것을 알아야 합니다.

@reduz 내가 Node+Script에 대해 의미한 것은 그 메커니즘이 Scene을 인스턴스화함으로써 이미 다루어졌다는 것입니다.

Mono 구현을 잘못 이해하고 있을 수 있지만 Mono 클래스는 여전히 Scripts가 아닙니까?

@reduz 나는 대부분 당신의 말에 동의합니다. 또한 당신이 사용자 정의 노드에 스크립트를 추가하는 것은 단순히 그것을 상속하도록 제안할 것이라고 말했습니다. 그러나 이것이 GDNative 맞춤 유형에서 어떻게 작동할 것으로 예상합니까?

@reduz 하지만 우리 목표 중 하나는 C++ 클래스에 미리 할당된 스크립트인 사용자 지정 유형 스크립트를 제거할 수 없도록 하는 것입니다. 런타임에 항상 스크립트를 제거할 수 있기 때문에 편집기 컨텍스트에서 수행할 수 없는 작업입니다(해당 기능을 유지하고 편집기에서 디자인 타임에 사용자 지정 유형 스크립트만 보호하려는 경우가 아니면).

나는 확실히 다른 방법에 대해 열려 있습니다. 어느 쪽이든, 가장 쉬운 구현은 일부 타사 등록 클래스(ClassDB, ProjectSettings, EditorData 또는 누가 무엇을 알고 있는지 여부)를 확인하여 Object가 조건부로 스크립트를 자체에 할당하도록 하는 것입니다(내 구현에서 수행한 대로). . 그러면 편집기 자체가 해당 타사와 확인하고 다르게 표시하는 것이 매우 쉬워집니다(내 구현에서 수행한 것처럼). 등록을 ClassDB가 아닌 다른 컨텍스트로 옮기는 것은 그다지 많은 작업이 아닐 것입니다.

^^ 그 타협이 받아들여질까요? 그렇지 않으면 Object가 제3자와 확인하기 위해 할당된 스크립트를 얻을 수 있는 모든 가능한 위치를 세부적으로 관리해야 합니다. 훨씬 더 복잡할 것입니다.

내가 수행한 구현은 지금까지 어떤 "유형"이 스크립트이고 어떤 것이 아닌지에 대해 매우 명확했습니다. 결국 내가 공유한 비디오의 장면 독에서 사용자 정의 유형과 관련된 스크립트를 여전히 명확하게 보고 액세스할 수 있습니다.

@willnationsdev 당신이 무엇을 하려는지 이해는 하지만 이것이 결코 깔끔하게 만들어질 수 없다고 생각합니다. 숨길 이유가 없는 복잡성을 예상대로 완전히 작동하지 않는 방식으로 숨기고 있습니다.

@Zylann 나는 그것이 동일하다고 생각하지만 a) 스크립트가 gdnative 내부 b) gdnative 내부 메소드를 사용합니다. 솔직히 말할만큼 익숙하지 않습니다.

@reduz 개체에 대한 스크립트 기반 제약 조건을 만드는 것을 허용하지 않는다는 말씀이신가요? 체크 로직을 에디터 자체로 옮길 수 있기 때문에 디자인 타임에 제약 조건을 쉽게 확인할 수 있지만(예: UI 변경) 런타임에는 작동하지 않으므로 사람들은 여전히 ​​잠재적으로 게임이 실행되면 상황을 변경할 수 있습니다. 그게 당신에게 더 좋을까? 그래도 런타임에 물건을 확인할 수 있으면 좋겠지만...

@willnationsdev 어떤 종류의 스크립트 기반 제약을 수행하고 싶습니까?

사용자 정의 스크립트 속성이 처음부터 있었던 것과 동일한 제약 조건: 할당된 스크립트가 다른 스크립트를 파생하도록 강제합니다.

장면 계층에서 확장된 스크립트에 대한 스크립트 아이콘을 숨기고 공격받은 스크립트를 상속하는 노드의 기본 클래스를 상속하는 대신 누군가가 "스크립트 추가" 버튼을 클릭하는 경우를 추천합니다. 투명하고 ClassDB를 전혀 어지럽힐 필요가 없습니다.

따라서 script_language.h 의 일부 정보를 검토하는 것만으로도 ClassDB 에 추가한 새 콘텐츠를 ScriptLanguage 클래스로 옮기고 일종의 ScriptDB 싱글톤은 스크립팅 언어에서 사용하려는 경우에만 생성됩니다. 그리고 object.cpp 에는 이미 script_language.h 가 포함되어 있기 때문에 $# set_script(const RefPtr &p_script) 에서 다음을 수행할 수 있습니다.

1. p_script 가 실제로 스크립트인지 확인
2. p_script 가 속한 언어 확인
3. p_script 및 Object 인스턴스의 custom_script 를 연결된 ScriptLanguage 에 대한 ScriptDB 에 전달합니다.
4. $# Object 에 대한 custom_script 에 암시된 제약 조건이 주어지면 p_script 가 Object 에 할당될 수 있는지 여부에 대한 응답을 ScriptDB 에서 받습니다. Object 인스턴스.

이렇게 하면 ClassDB 를 수정하지 않고 object.h 를 깨끗하게 유지할 수 있습니다( custom_script 에 대한 setter/getter 제외). 또한 식별자와 네임스페이스를 정의하기 위해 Godot에 의존할 필요가 없는 스크립팅 언어의 불필요한 복잡성을 방지합니다(예: C#, C++, Python 등과 달리 GDScript 및 VisualScript는 필요함).

그런 다음 사용자 정의 유형/사용자 정의 유형 상속을 확인하는 실험적인 ClassDB 기능을 대체하기 위해 적용 가능한 모든 스크립팅 언어에서 식별자/네임스페이스 검사를 수행할 수 있는 ScriptServer 메서드를 정의하기만 하면 됩니다. 계층. 충분히 쉽습니다.

이 중 어떤 것이 허용 가능한 대안 @reduz처럼 들립니까?

여기에 내 목소리를 추가하면 됩니다. 저는 Godot와 함께 일하기 시작했고 사용자 정의 유형 애드온에 대해 읽었을 때 정말로 재사용 가능한 새로운 기본 유형을 만들 것이라고 생각했습니다. KinematicBody 를 만들 때 스크립트를 첨부할 수 있지만 여전히 KinematicBody 의 모든 작업을 수행합니다.

이것은 두 가지 방법으로 강화됩니다.

1. 그들은 유형이라고합니다. Type이 확장 가능한지 여부는 언어마다 다르지만(javascript: yes, golang: no, python: yes) 일반적으로 정의하는 유형은 첫 번째 클래스 언어 유형이 확장 가능한 경우 확장 가능합니다. Godot에서 첫 번째 클래스 유형은 확장 가능하지만 사용자 정의 유형은 확장할 수 없습니다(적어도 같은 방식은 아닙니다). 조립식 장면이나 템플릿 장면과 같은 다른 것으로 호출하면 다른 것으로 표시하는 데 도움이 됩니다.

1. 'Create New Node' 창의 첫 번째 클래스 노드와 동일한 트리에 표시됩니다. 이것은 당신이 그것들을 같은 방식으로 사용한다는 것을 의미합니다. 'Prefabs' 또는 'Templates' 또는 이를 호출하려는 항목에 대해 별도의 섹션이 있으면 다시 다르게 호출됩니다.

@JPTeasdale 불행히도 이 시점에서 더 큰 관심사는 구현이 아니라 "이를 어떻게 정의합니까?" 질문입니다. 그리고 Godot 사용자 정의 유형은 확장 가능합니다(그냥 스크립트일 뿐입니다). 편집기에는 노드 생성 대화 상자에서 사용자 정의 유형 간의 상속 관계를 표시하는 코드 지원이 아직 없지만 데이터는 사용할 수 있습니다. 또한 "사용자 정의 유형"에서 다른 이름으로 이름을 바꿀 이유가 없습니다. "조립식"과 "템플릿"은 실제로 적절한 용어가 아니며 처음부터 장면도 아닙니다(그냥 단순하고 단순한 스크립트일 뿐입니다).

나는 그것이 의도 한 솔루션보다 훨씬 간단하다고 생각합니다.

1. 인스펙터에 숨겨진 속성을 "custom_type_script"라는 Object 클래스에 추가하고 Script 대신 이 속성을 선택하도록 사용자 정의 스크립트를 할당합니다.
2. 노드를 확장하려고 할 때 이 속성이 null인지 확인하고 그렇지 않은 경우 노드 클래스 대신 이 스크립트를 확장합니다(Extend "res:/path/to/script.gd" 쓰기).
3. 노드 스크립트가 null인 경우 사용자 정의 스크립트의 인스턴스를 가리키도록 get_script_instance를 변경하십시오.

@MarianoGnu 글쎄, 편집기 변경 사항을 만드는 측면에서 script 속성을 자동으로 채우고 처음부터 null이 되는 것을 방지하는 것이 더 간단합니다. script 속성이며 script 속성을 참조할 때마다 찾아 script 의 값만 변경하면 해당 코드를 수정할 필요가 없습니다. .

즉, 이 프로세스를 다시 수행하는 목표의 일부는 일반적으로 스크립팅 언어가 스크립트 클래스를 찾기 위해 파일 경로가 아닌 식별자를 사용하도록 선택하는 것입니다. 이것이 ScriptDB 개념 또는 ClassDB 수정이 처음에 제안된 유일한 이유입니다. 그러나 이제 Juan이 ClassDB 변경 사항에 대해 그렇게까지 반대하는 이유를 알았습니다. 따라서 스크립팅 API에만 정보를 저장하는 것이 좋습니다. 개별 스크립팅 언어로 된 모든 정보가 자체적으로 포함되어 있습니다.

개체에 보이지 않는 스크립트를 저장하는 대신 ScriptDB에 저장하는 대신 스크립트 판독기에 사전 전달을 추가하여 "extend CustomClassName"을 "extend "res:/path/stored/inScriptDB.gd로 대체할 수 있습니다. " GdScript의 프리컴파일러에서는 스크립트를 스크립트에서 상속 계층 구조에서 벗어나게 하는 것이 매우 번거롭기 때문에(계층 구조는 루트에서 맨 아래로 직선이어야 하며 분기가 있으면 혼란을 야기합니다)

스크립트를 스크립트 상속 계층에서 벗어나게 하는 것은 매우 번거롭기 때문입니다(계층은 루트에서 아래로 직선이어야 하며 분기가 있으면 혼란을 야기합니다)

@MarianoGnu 여기에 약간의 오해가 있을 수 있습니다. 어느 시점에서 상속의 직선이 없다고 생각합니까? 내가 구현하는 한, 스크립트 사이에는 항상 매우 명확한 상속 계층이 있습니다. 상속 계층 자체가 작동하는 방식에 대해서는 아무 것도 변경하지 않았습니다. 방금 주어진 스크립트를 StringName에 매핑하고 일종의 DB에서 찾는 것을 가능하게 만들었습니다.

그리고 이미 그 작업을 진행하고 있다면 스크립트 텍스트를 GDScript 컴파일러의 경로로 다시 바꿀 이유가 없습니다. 컴파일러가 하는 일은 Script 인스턴스를 script 변수에 할당하는 것입니다. ResourceLoader::load(path) 메소드를 통해 스크립트를 로드했는지 아니면 $#$ Class/ScriptDB::get_script(namespace_and/or_identifier) 를 사용하여 스크립트를 가져왔는지는 중요하지 않습니다.

언급하고 싶은 것은 Godot의 새로운 사용자로서 플러그인의 "커스텀 노드"가 빌트인 노드 역할을 할 것이라는 인상 하에 플러그인을 만들었습니다. 즉, 노드 목록에서 선택했을 때 스크립트 없이 노드를 얻을 것으로 예상했지만 플러그인에서 스크립팅한 기능은 이미 내장되어 있습니다(내장 노드의 경우처럼). 방금 들어오는 누군가로부터 다른 의견을 제시해야 한다고 생각했습니다(여기에서 논의가 이미 광범위하게 진행된 것처럼 보이지만).

"사용자 정의 노드"는 스크립트일 뿐이므로 스크립트를 내장 노드에 할당하는 것과의 차이점은 무엇입니까? 사용자 정의 노드 기능은 무엇을 해야 합니까?

@MCrafterzz 플러그인에서 생성한 커스텀 노드 위에 스크립트를 추가할 수 있는 기능을 커스텀 노드에 추가하는 기능이 있어야 한다고 논의했습니다.

현재 커스텀 노드는 스크립트가 이미 첨부되어 있고 아이콘과 이름이 이미 변경된 노드로 생성됩니다.

@willnationsdev 이 기능을 구현하는 데 어느 정도 도달했습니까?
나는 이 기능이 3.1 이전에 여기에 있었으면 정말 좋겠습니다. 정말 놀라운 추가 기능이 될 것입니다.
Godot 플러그인 및 애드온 시스템용.

누구에게도 압력을 가하고 싶지 않습니다. 그러니 업무 방식으로 받아들이지 마십시오.

나는 사용자 정의 유형 시스템에 대한 새로운 백엔드를 완전히 구현했습니다. 새로운 기능을 사용하면 사용자가 원래 기능을 모두 수행할 수 있을 뿐만 아니라 스크립트 추가 버튼이 기본적으로 사용자 정의 스크립트를 확장하는 새 스크립트를 추가하도록 만들 수 있습니다(사용자 정의 스크립트를 여는 대신). 사용자 정의 스크립트를 제거할 수 없습니다(다른 엔진 유형과 마찬가지로 유형 변경 편집기 명령을 사용해야 함).

@swarnimarun

또한 사용자는 유형 이름 대 파일 경로 매핑에 대한 액세스를 제공하는 전역에 유형을 등록할 수 있습니다. GDScript는 이러한 매핑을 본질적으로 단순한 전역 유형 이름으로 인식할 수 있습니다. 또한 유형은 등록하기 위해 사용자 정의 유형일 필요가 없으며 유형은 스크립트 또는 장면일 수 있습니다.

지금까지 새 백엔드를 구현했고 원래 사용자 지정 유형 스크립트 기능을 다시 설정했습니다. 현재 새로운 기능을 개발 중입니다. 지금부터 아마 일주일. 나는 이번 주에 그렇지 않으면 바쁩니다.

@willnationsdev 걱정 마세요. 3.1이 되면 만족합니다.
그리고 나는 그것이 꽤 많은 작업이 될 수 있다는 것을 깨달았습니다.
좋은 일을 계속하십시오.

현재 편집기는 노드의 스크립트를 쉽게 확장할 수 있는 기능이 있습니다.

노드 자체는 현재 다음과 같습니다.

그리고 @reduz 의 주요 관심사는 이미 스크립트가 첨부되어 있다는 사실을 숨기는 것이었습니다. 한편으로는 이를 사용자에게 숨기지 않는 것이 좋습니다. 그러나 반면에 사용자 정의 노드에는 거의 항상 스크립트가 첨부되어 있습니다. 스크립트가 없으면 사용자 정의 노드는 추가 기능이 추가되지 않고 사용자 정의 아이콘이 있는 기존 일반 노드입니다.

그리고 사용자 정의 스크립트를 확장할 수 있지만 일반 사용자 정의 노드가 확장 사용자 정의 노드와 동일하게 보이는 것은 매우 성가신 일입니다.

여기 내 간단한 솔루션이 있습니다. 사용자 정의 노드의 스크립트가 사용자 정의 노드의 정의에 있는 스크립트와 동일한 경우 스크립트 아이콘은 다음과 같이 희미해져야 합니다.

의미:

여러분, 실제 예: 동일한 종류의 많은 사용자 정의 메모가 있고 각 스크립트가 자체 인스턴스에 대해 사용자 정의되어 있는 경우 기본 사용자 정의 노드 스크립트를 변경하려면 어떻게 됩니까? 최악의 경우 수정해야 하고 그에 따라 다른 모든 인스턴스도 수정해야 하므로 인적 및 오타 오류가 발생할 가능성이 높습니다.

스크립트를 숨기고 싶지 않으세요? 좋습니다. 그런 다음 custom_node 스크립트와 프로젝트 노드 스크립트를 표시합니다.

@aaronfranke 제 생각에는 이것이 최고의 솔루션입니다. 인스턴스화된 장면에서도 이점을 얻을 수 있습니다.

@zatherz et al, 이제 #30697이 구현되었으므로 개선할 수 있는 것은 무엇입니까? https://github.com/godotengine/godot/issues/6067#issuecomment -238250383에 중요한 것이 있습니까?

#30697에서 수정한 대로 종료합니다. https://github.com/godotengine/godot/issues/6067#issuecomment -238250383에 설명된 OP의 원래 제안은 구현되지 않았지만 https:// 에서 @reduz 의 우려로 인해 발생하지 않습니다. github.com/godotengine/godot/issues/6067#issuecomment -239060186.