Godot: より優れたカスタムEditorPluginノード

意味がわかりません

@reduzプラグインによって作成されたタイプのノードをシーンに追加すると、プラグインスクリプトがすでに添付されています。 したがって、カスタム動作で別のスクリプトを追加することはできません。

もちろんそうではありません。これはコア設計によるものであり、変更されることはありません。

2016年8月7日18:11、「GeorgeMarques」 [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分、「GeorgeMarques」 [email protected]は次のように書いています。

これは悲しいことだ。 ただし、スクリプトはいつでも親または子に追加できます。

wontfixとして閉じます。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/6067#issuecomment -238120392、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AF-Z27Zo4Ixvo4APSC4Fxf5ZqCJRsAxXks5qdn3igaJpZM4JejbZ
。

ノードごとに2つ（またはそれ以上）のスクリプトを持つ機能が必要になると思いますが、これは実際にはあまり意味がありません。

Godotは当初これをサポートしていましたが、利点よりも厄介でした

2016年8月7日午後10時36分、「GeorgeMarques」 [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 [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に移植しようとしたときの最初の大きな障害の1つでした。 上で説明した@ akien-mgaのようなカスタム型は、登録後に他の組み込み型と同じように動作するはずです。

彼らが信じていない方法を説明してください

2016年8月8日午前11時50分、「RalfHölzemer」 [email protected]は次のように書いています。

+1
これは、私が移植しようとしたときの最初の主要な障害の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の2番目の引数は「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の2番目のパラメーターが欠落していることに注意してください。

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

ああ、なるほど..これらの2つの泥棒は、一緒に、間違いなく修正可能でなければなりません
スクリプト作成ダイアログに継承サポートを追加

2016年8月8日午後1時54分、「RalfHölzemer」 [email protected]は次のように書いています。

すでに前に述べたように、現時点での_最大の欠点_は
カスタムタイプは、ベースタイプをインスタンス化する簡単な方法にすぎません。
そのスクリプトのを作成し、そのインスタンスに適切なスクリプトを割り当てます。 この
別のスクリプトを使用してエディターでそのノードを拡張することは不可能になります-
組み込み型でできるように。

ただし、カスタムノードを使用して継承ツリーを構築することもできません。
[新しいノード/リソースの作成]ダイアログは、これらにのみ表示されるため、
組み込み型に親として登録すると、
add_custom_type。

たとえば、すべてのカスタムタイプを継承したいとします。
単一の基本タイプからのプロジェクト。

_base.gd http：//base.gd_

ノードを拡張します
エクスポート（色）var color

_type_a.gd http：//type_a.gd_

base.gdを拡張します

_type_b.gd http：//type_b.gd_

base.gdを拡張します

今のところ、こういうタイプを登録する必要があります。 これで
この場合、add_custom_typeの2番目の引数は「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"））

...そしてこれが結果です。

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

このようなカスタムタイプを登録できるのは素晴らしいことですが、
ダイアログは、次のようなタイプの継承の性質を反映していません
その他の組み込み型。 組み込み型の場合は、そのツリーを見て、
私が扱っているものを一目で見てください。 たとえば、私はそれを確認することができます
スプライトはNode2Dであるため、提供されたすべての関数を継承します。
by_Node2D。 同じことはカスタムタイプには当てはまりません。

ここで、カスタムタイプをグローバルスコープに完全に登録できる場合は、次のようになります。
@ akien-mga https://github.com/akien-mga上記のように、物事は
理解と使用がはるかに簡単になります。

まず、_typename_によって参照されるカスタムタイプから継承できます。
ファイルのパス/名前の代わりに。

_base.gd http：//base.gd_

ノードを拡張します
エクスポート（色）var color

_type_a.gd http：//type_a.gd_

ベースを拡張します

_type_b.gd http：//type_b.gd_

ベースを拡張します

...次に、カスタムタイプの登録を次のように簡略化できます。
これ。 add_custom_typeの2番目のパラメーターが欠落していることに注意してください。

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"））

...そして「Createnew」でより良い概要を得ることができます
ノード/リソース」ダイアログ：

[画像：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

...これもスクリプトの代わりに_typename_によって参照されます
名前/パス

ベースを拡張します

これが上からのプラグインの例です。
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日14:02、「JuanLinietsky」 [email protected]は次のように書いています。

ああ、なるほど..これらの2つの泥棒は、一緒に、間違いなく修正可能でなければなりません
スクリプト作成ダイアログに継承サポートを追加

2016年8月8日午後1時54分、「RalfHölzemer」 [email protected]は次のように書いています。

すでに前に述べたように、現時点での_最大の欠点_は
カスタムタイプは、ベースタイプをインスタンス化する簡単な方法にすぎません。
そのスクリプトのを作成し、そのインスタンスに適切なスクリプトを割り当てます。 この
別のスクリプトを使用してエディターでそのノードを拡張することは不可能になります-
組み込み型でできるように。

ただし、カスタムノードを使用して継承ツリーを構築することもできません。
[新しいノード/リソースの作成]ダイアログは、これらにのみ表示されるため、
組み込み型に親として登録すると、
add_custom_type。

たとえば、すべてのカスタムタイプを継承したいとします。
単一の基本タイプからのプロジェクト。

_base.gd http：//base.gd_

ノードを拡張します
エクスポート（色）var color

_type_a.gd http：//type_a.gd_

base.gdを拡張します

_type_b.gd http：//type_b.gd_

base.gdを拡張します

今のところ、こういうタイプを登録する必要があります。 これで
この場合、add_custom_typeの2番目の引数は「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"））

...そしてこれが結果です。

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

このようなカスタムタイプを登録できるのは素晴らしいことですが、
ダイアログは、次のようなタイプの継承の性質を反映していません
その他の組み込み型。 組み込み型の場合は、そのツリーを見て、
私が扱っているものを一目で見てください。 たとえば、私はそれを確認することができます
スプライトはNode2Dであるため、提供されたすべての関数を継承します。
by_Node2D。 同じことはカスタムタイプには当てはまりません。

ここで、カスタムタイプをグローバルスコープに完全に登録できる場合は、
上記の@ akien-mga https://github.com/akien-mgaのように、
理解して使用する方がはるかに簡単です。

まず、_typename_によって参照されるカスタムタイプから継承できます。
ファイルのパス/名前の代わりに。

_base.gd http：//base.gd_

ノードを拡張します
エクスポート（色）var color

_type_a.gd http：//type_a.gd_

ベースを拡張します

_type_b.gd http：//type_b.gd_

ベースを拡張します

...次に、カスタムタイプの登録を次のように簡略化できます。
これ。 add_custom_typeの2番目のパラメーターが欠落していることに注意してください。

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"））

...そして「Createnew」でより良い概要を得ることができます
ノード/リソース」ダイアログ：

[画像：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

...これもスクリプトの代わりに_typename_によって参照されます
名前/パス

ベースを拡張します

これが上からのプラグインの例です。
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_ノードのプロパティではなく、そのタイプのプロパティであるためです。 したがって、このスクリプトはカスタムノードにプロパティを付与する必要がありますが、組み込みノードのC ++クラスと同じようにインスタンス化されたノードのユーザーには表示されないようにする必要があります。 APIを提供しますが、変更可能ではなく、拡張可能のみです。 スプライトをインスタンス化するときと同じように、インスタンス化されたノードのスクリプトとしてscenes/2d/sprite.cppがアタッチされないのと同様に、インスタンスのカスタムノードの変更可能なスクリプトとしてmy_custom_node.gdがアタッチされるべきではありません。

さて、それが技術的に現在_可能_であるかどうかはわかりませんが、それは自然なユースケースAFAIUでしょう。 カスタムタイプのスクリプトを変更すると、タイプ自体が変更されるため、このタイプのすべてのインスタンスに影響します。 ただし、カスタムタイプを使用するインスタンス化されたノードには、 extends CustomNodeという独自のスクリプトが必要です。

この機能には、「基本カスタムスクリプトタイプ」への追加のポインタが必要だと思います。これは、オブジェクトからユーザースクリプトを削除するときにその情報が必要になるためです（実際には基本スクリプトに置き換える必要があります）。
それができたら、それが多くの副作用をもたらす可能性があるので、残りはすべての場合にそれを含めることの問題です。 最終的には、スクリプトが1つだけ添付され、それを処理する方法が異なります。
私は一般的に継承の大ファンではありませんが、これが私のやり方です。

実際には、そのポインタは必要ありませんでした。 スクリプトにマークを付けるだけで十分です。たとえば、スクリプトを使用してadd_custom_type（）を実行すると、エンジンはクラスにフラグを設定して、「このスクリプトクラスはエンジンタイプの拡張機能です」などの情報を利用できるようにすることができます。 ユーザースクリプトを削除すると、「カスタムタイプ」とマークされた最初の継承されたスクリプトクラスに置き換えられるか、存在しない場合は削除されます。

申し訳ありませんが、ノードにスクリプトがある場合、スクリプトを非表示にすることはできません。 何ですか
そうでない何かをシミュレートするポイントは？

スクリプトがあるという事実は、スロットがビジーであることや、スロットが必要であることを意味するものではありません。
2番目のスクリプトは、次のスクリプトを継承する新しいスクリプトを簡単に作成できるためです。
既存のもの。

同意する場合、私たちにできることは、シーンツリーのスクリプトアイコンを非表示にすることです。
割り当てられたスクリプトはカスタムタイプのものであり、スクリプトを作成します
スクリプトの作成ダイアログは、スクリプトの作成時に継承することを自動的に提供します。
これで十分でしょうか？

2016年8月10日午後11時1分、「Marc」 [email protected]は次のように書いています。

実際には、そのポインタは必要ありませんでした。 スクリプトをマークすると
たとえば、スクリプトを使用してadd_custom_type（）を実行する場合は、エンジンで十分です。
クラスにフラグを設定して、情報が利用できるようにすることができます。
スクリプトクラスはエンジンタイプの拡張機能です」。ユーザースクリプトを削除すると、
次に、「カスタム」とマークされた最初の継承されたスクリプトクラスに置き換えます
「」と入力するか、存在しない場合は削除します。

—
あなたが言及されたので、あなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/6067#issuecomment -239055986、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AF-Z2xLGOhgMk__ZoRW1neRu1aRb5Qr_ks5qeoJogaJpZM4JejbZ
。

@reduz私はそれで十分だと思います：smile：

@reduz同意しますが、2番目のスクリプトが必要だとは言いませんでした。 最初のスクリプト（プラグインによって定義されたカスタム）を継承するスクリプトを追加するとどうなるのかと思っていましたが、削除することにしました。 次に、スクリプトなしでノードを基本的なエンジンタイプに戻しますか？

その点で、どういうわけかもっとユーザーフレンドリーにすることができると思います

2016年8月11日06:10、「Marc」 [email protected]は次のように書いています。

@reduz https://github.com/reduz同意しますが、必要だとは言いませんでした
2番目のスクリプト。 スクリプトを追加するとどうなるのだろうと思っていました
最初のもの（プラグインによって定義されたカスタム）を継承しますが、その後、
それを除く。 次に、ノードを基本的なエンジンタイプに戻します。
それではスクリプト？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、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
もちろん、ユーザーはトリガー1を使用するために両方のアドオンを追加する必要があります

一方のグループは、スクリプトなしでカスタムノードタイプを、それが基づいているカスタムノードタイプから派生しているものとして定義したいと考えているようですが、もう一方のグループは、ベースに戻ったノードと同じシナリオを定義したいと考えています。エンジン型式。 私は前者のグループに属していますが、カスタムタイプがまだ「スクリプト化」されており、UIでそれを明確にしたいと考えているという点で、後者のグループのポイントもわかります。

妥協案として、シーンツリードックのノードの行のスクリプトアイコンの横に、ある種のscript ++アイコンが付いた追加のUIボタンを配置することが考えられます。 それをクリックすると、カスタムタイプからすでに継承されているスクリプト（例： extends Baseまたはextends "Base" ）を含む一般的な[スクリプトの作成]ポップアップウィンドウが表示されます。 次に、定義されたスクリプトが作成され、プリセットされたスクリプトが何であれ、すぐに置き換えられます。 したがって、ノードに既存のスクリプトがあることを明確に示すことができますが、そのプリセットスクリプトを簡単に置き換えるための使い慣れたインターフェイスもあります。

この提案は、カスタムノードをエンジン内の対応するノードとは多少異なる方法で処理するため、おそらく直感的ではありません。 考え？

この議論の後半で2セントを与えると、問題は、アドオンを継承する複数のノードがデフォルトで同じ元のスクリプトを共有するという事実にあると思います。 Juanがこのスレッドの冒頭で論じたように、コードの可視性は設計上の選択であり、アドオンを使用して開発者がノードの動作を透過的にするためにも重要です。 ただし、通常はコード内のさまざまなノードの動作を変更する必要があります。現時点で変更する唯一の方法は、元のスクリプト参照を削除し、新しいスクリプトを作成して、ベーススクリプトコードをコピーして貼り付けることです。 新しいアドオンノードのスクリプトを新しい.gdファイルにsave asすることさえできません。これにより、元のスクリプトを使用する他のすべてのノードへの参照が変更されるため、この3ステップのコピーアンドペーストがあります。手順の癖。

繰り返しになりますが、それほど複雑ではありません。この特定のケースでは、GDScriptエディターのsave asオプションが期待どおりに動作しないため、「」を使用する方がUIに適していると思います。 GDScriptエディターの[コピーして保存]ボタンを使用すると、アドオンをすばやくカスタマイズできます（アーキテクチャに関しては、このボタンを表示することは、継承されたスクリプトを使用せずにGodotでゲームを作成するための優れたアプローチであるため意味があります）。

@henriquelalvesコードでカスタムノードをカスタマイズすることは基本的に継承だと思いましたか？ たとえば、 extends "addons/thing/thing.gd" ？ オーバーライドする内容がわかっている場合、継承されたスクリプトは、アドオンバージョンと同じことを実行します。 コピー/貼り付けの必要はありません。

@Zylannあなたは正しいですが、コードの可視性とオートコンプリートの癖のために、通常、この特定のアプローチは好きではありません（少なくとも2.1では、私は今までにそれをテストしていません）。 そして、ほとんどの場合、メソッドをオーバーライドしたくはありません。元のアドオンスクリプトの拡張変数ではない特定のものだけを変更します。 これが、現在のsave asの動作に悩まされていることです。そのようなスクリプトへのすべてのノード参照を変更せずに、スクリプトのコピーをすばやく作成することはできません。 UIに適した方法でこれを解決すると、カスタマイズする複数のノードがあり、コードの可視性などがあるという元の問題が解決されます（少なくとも私のワークフローでは、私だけがこのように考えています）。

@henriquelalvesよく私はtbhxDのコピー/貼り付けに耐えられません。また、バージョン管理を使用してプラグインをフォークし、代わりにそれを使用することもできます。

@Zylann Forkingプラグインは、非常に単純なはずの何かにさらに多くのステップを追加しています、ハハハ。 save asの動作がおかしいとは思いますが、これが優先されない場合は、手動でコピーして貼り付けることに固執すると思います。

@henriquelalvesコピー/貼り付けはフォークです^^しかし、バージョン管理なしで行われた場合、プラグインが更新された場合、将来的にあなたを噛みます。

スクリプトをカスタムノードにアタッチする現在の動作では、スクリプトをノードにアタッチするだけの場合と比べて、そのカスタムノードをアドオンとして使用するメリットはほとんどありません。 唯一の利点は、ノードダイアログに表示されることですが、実際にはまったく利点ではありません。

私は、カスタムノードが一流の組み込み型と同じように動作する必要があると言っているキャンプにいます。 それ以外の場合は、なぜアドオンを作成/使用するのですか？ ダイアログに表示され、スクリプトの追加ボタンをクリックする必要がないようにするためですか？

@RodeoMcCabe問題は、内部では、カスタムタイプは実際にはエンジン内ノードの上に階層化されたスクリプトであり、カスタムタイプノードはエンジンソースに直接コンパイルされないため、変更できないことです。 私たちが行う必要があるのは、これらのスクリプト化されたノードがユーザーの目にエンジン内ノードの動作をシミュレートできるようにする具体的な一連のステップ/機能を策定することです。 例えば...

1. 「ノードの作成」ウィンドウへのノードの追加（完了）
2. ユーザーが「ノードの作成」ウィンドウにノードのテキストによる「簡単な説明」を提供できるようにします（完了していないように見えますか？-少なくとも、 add_custom_typeの一部ではありません）。
3. ユーザーが「ノードの作成」ウィンドウでノード階層を表示し、抽象カスタムタイプを定義できるようにします。 これには、抽象型であるかどうかに関係なく、 add_custom_type関数にブール値を追加することが含まれる可能性があります。 「ノードの作成」ウィザードを更新して、それに応じて抽象カスタムタイプの作成をブロックする必要があります。

4. スクリプトがないかのようにノードをSEEMにします。

   a。 ノードには、シーンドックに「スクリプトはこのノードにあります」アイコンがあってはなりません。 物事をより透明にするために、おそらく代わりに「これはカスタムタイプのノードです」アイコンがあるはずです。 これをクリックすると、ユーザーはカスタムタイプが追加されたスクリプトに直接移動できます。 これは「没入感」を壊しますが、使いやすさの理由から必要な犠牲になります（もちろん、必要に応じて、カスタムタイプノードがどのように機能するかを確認できるようになります）。

   b。 インスペクターに表示されるscriptプロパティは、ユーザーがスクリプトをロードしない限り、デフォルトで空であると表示されます。ロードされた場合、スクリプトはカスタムタイプとして使用されるスクリプトタイプから派生する必要があります。 ただし、ユーザーはカスタムタイプのスクリプトファイルの場所を知っている必要はありません（スクリプトであるという概念はユーザーから隠す必要があります）。 つまり、カスタムクラスの文字列名は、他のエンジン内クラスと同じように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")を使用してスクリプトを作成できます。

   c。 ユーザーがカスタムタイプから派生したスクリプトをノードにロードした場合にのみ、「このノードにはスクリプトがあります」アイコンがシーンドックに表示されます。

5. スクリプトに使用されているエディタアイコンは、現在スクリプトに使用されているホワイトボックスのようなアイコン（ property_editor.cpp ）ではなく、カテゴリブロックに追加する必要があります。 これは、カスタムタイプノードオブジェクトの__meta__ディクショナリプロパティの一部である必要があります。

6. カスタムタイプで[スクリプトの追加]をクリックすると、4bで使用されている方法を[継承]フィールドに事前に入力する必要があります。
7. スクリプトを削除した場合でも、カスタムタイプのスクリプトは内部に存在し、削除されないはずです。 カスタムタイプノードは、ロードされたスクリプトがnullに設定されている場合に、カスタムタイプスクリプトをバックアップスクリプトとして効果的に使用します。 そのため、エディターのシーンドックとインスペクタードックに基本タイプのエディターアイコンとスクリプトプロパティが表示されます。 「スクリプト変数」を実際のスクリプトの名前に置き換える機能をすでにマージ中ですが、これらの変更をすべて追加した場合は更新が必要になる可能性があります。
8. Object::get_script()は、カスタムタイプのスクリプトがあり、スクリプトがロードされていないノードの場合、 nullを返す必要があります。
9. Object::get_property_list 、およびメソッドとシグナルの類似関数には、ロードされたスクリプトがない場合でも、カスタムタイプのスクリプトの内容を含める必要があります。
10. スクリプト側がこの2番目のスクリプトを認識していない場合でも、エンジンがスクリプトがあるかどうかを確認できるように、 Object::get_custom_script()などの2番目のC ++オブジェクト関数が必要になる可能性があります。
11. カスタムタイプから派生していないスクリプトをオブジェクトにロードしようとすると、正常に失敗し、エラー（おそらく、関連する関数の&is_valid参照ブール）を報告して、オブジェクトがそれを実行できるかどうかを確認する必要があります。 この情報に関するフィードバックを提供する必要がある関連するGodotEditorシナリオも、これを説明するために更新する必要があります。

これは表面を傷つけているだけですが、ユーザーが探している種類の動作は、これほど広範囲にわたるものだと思います（したがって、かなり激しいです）。 必要に応じてカスタムタイプの存在にアクセスできるようにします（したがって、ノードの行のシーンドックにカスタムタイプアイコンを配置してスクリプトを表示します）が、認識できるように、カスタムタイプの存在を可能な限り非表示にします。エンジン内タイプとしてそれら。 おそらく多くの場所で物事を壊してしまうので、それを正しく行うには多くの作業が必要になります。

この音のどれかがいいですか？ 少し考えているだけなので、足りないアイテムがもっとあると思います。 これがおかしなことに聞こえる場合は、私に知らせてください。 ;-)

編集：ああ、しかし、スクリプトがカスタムタイプのスクリプトと一致する場合にシーンドックのスクリプトアイコンを非表示にするというreduzの提案も価値があるかもしれません。 ただ、 get_script()メソッドはまだ何も返さないはずです。 オブジェクト自体に個別のスクリプトプロパティを作成せずにそれを行う方法があるのではないでしょうか。 Idk、オブジェクトごとに1つのスクリプトについて、コードベースにはすでに多くの仮定があります。これは維持したいと思いますが、 custom_typeスクリプトの概念では維持するのが困難です。

良い提案、よく考えられた。 これがすべて実装されていれば、私たちが探している動作が得られると思いますが、ノードごとに1つのスクリプトルールを破ることは、コードの予期しない多くの部分に共鳴する可能性がある悪いニュースになる可能性があると思います。 私はコードベースをよく知らず、私のC ++は平凡なので、一粒の塩でそれを取ります。 Reduzは、元々、ノードごとに複数のスクリプトを作成しようとし、「それだけの価値があるのはもっと面倒だった」と述べました。これは私には合理的に聞こえます。

ポイント1から4は素晴らしいです、そして私は1スクリプトのルールを破ることなく達成できると思います。 抽象カスタム型は、とにかくインスタンス化できないため、明らかに問題にはなりません。したがって、ユーザーはエディターでスクリプトを追加できません。 ただし、コードを介してそうしようとする可能性があるため、必要なチェックとエラーを設定する必要があります。

ポイント6も良いです、そしてここで私たちはこれで逃げることができると思います。 ポイント6に従って新しいスクリプトを作成すると、カスタムノードに現在接続されているスクリプトが新しい（派生）スクリプトに変更されます。 古い（ベース）スクリプトがノードから削除されます。 新しい添付スクリプトは元のスクリプトから派生しているため、すべての機能が残ります。 私はよくこれを行います。ここでは、基本クラス（抽象クラ​​スかどうかに関係なく）があり、派生スクリプトをノードにアタッチします。 ここでの違いは、新しいスクリプトが言っているかもしれないということですextends "res://addons/path/to/base-script.gd"というだけで、カスタム・ノードの名前よりも、カスタムタイプはもはや....添付そのスクリプトを持っているため、2番目の思想上のが、 remove_custom_type()は呼び出されず、添付されたスクリプトはまだ古いスクリプトから派生しているので、おそらくこれは必要ありませんか？ この点について明確にしてください。

ポイント7、8、および9は適切であり、1スクリプトのルールを維持しながらおそらくそれほど難しくはありません。 1スクリプトルールを維持する場合、10は必要ありません。 11は良いです。これは、ノードタイプを拡張しないスクリプトを組み込みノードにアタッチしようとした場合に、組み込みノードがどのように動作するかを示しているためです。

いずれにせよ、それは多くの作業のように聞こえます、そして私たちはすでにベータ版にあるので、これは3.1または3.2でさえあると思います（最近ロードマップを見ていません）。

@RodeoMcCabeええ、これは間違いなく3.0ではありません。

ノードごとに1つのスクリプトルールを破ることは、コードの予期しない多くの部分に共鳴する可能性がある悪いニュースになる可能性があります

私の考えは正確に。 オブジェクトがカスタムバックアップスクリプトを認識しているが、他のオブジェクトはそれを認識せず、オブジェクトが単一のスクリプトを持っていると単純に認識するパブリックインターフェイスを考えています。 秘訣は、scriptプロパティのセッターとゲッターを編集することです。 ゲッターはnullをチェックする必要があります。 nullの場合は、代わりにバックアップスクリプトを返す必要があります。 セッターは同様に、新しいスクリプトがバックアップスクリプトを拡張することを再確認する必要があります。そうでない場合は、何らかの理由で失敗を報告する必要があります。

抽象カスタム型は、とにかくインスタンス化できないため、明らかに問題にはなりません。したがって、ユーザーはエディターでスクリプトを追加できません。

スクリプト側（afaik）には抽象型はありません。 スクリプトを抽象化する方法を知っていると言っていますか？ can_instanceメソッドはスクリプト側に公開されていますが、スクリプト自体が有効かどうか、ツールの場合はScriptServerで現在スクリプトが有効になっているかどうかを確認するだけです。 スクリプトタイプの抽象性とは何の関係もないと思います。

CreateDialog::_update_searchメソッドがテキストをグレー表示/選択不可にするタイミングなどを知るには、クラスが抽象であるかどうかを確認できる必要があります。

参考までに、問題の抽象的な部分に関する問題を作成しました（＃13401）。

全体として、 backup_scriptプライベートメンバーをObjectタイプに追加し、それを使用してscriptプロパティチェックを実行すれば実行可能だと思います。

カスタムノードで行うことは、ベーススクリプトを継承することです。これにより、カスタムノードスクリプトがデフォルトで空になります...

自動継承はプラグイン自体に影響を与え、プラグインを複製せずに複数を作成することはできませんよね？

マルチスクリプトは今年2回目に追加され、再び簡単に削除できました（複数の問題が発生します）。

スクリプトの代わりにカスタムノードのベースとしてシーンを許可すると、ルートからスクリプトを解放できる場合があります。

カスタムノードで行うことは、ベーススクリプトを継承することです。これにより、カスタムノードスクリプトがデフォルトで空になります...

申し訳ありませんが、これは私が以前に行った抽象性やその他の提案に何らかの影響を与えると言っていますか？ これがどこにつながるのかわかりません...

自動継承はプラグイン自体に影響を与え、プラグインを複製せずに複数を作成することはできませんよね？

プラグインを/addons/フォルダーに2回インクルードし、プロジェクト設定のプラグインセクションで両方を有効にすると、何らかの問題が発生することを伝えようとしていますか（つまり、プラグインがカスタムを追加している場合は、かなり正常に聞こえます）タイプ。同じ名前で複数のカスタムタイプを定義することはできません）。

「プラグインを複製せずに複数を作成することはできません」とはどういう意味かよくわかりません。 カスタムタイプノードの複数のインスタンスを作成できます（？）。ノードを作成し、定義されたカスタムタイプスクリプトを自動接続するだけだからです。 私の提案では、CreateDialogのスクリプト作成プロセスを次のように変更する必要があります...

1. ノードの組み込みスクリプトに、ノードをインスタンス化できるかどうかを決定させます（抽象）。
2. 組み込みノードタイプを作成します。
3. カスタムスクリプトをノードのbackup_scriptプロパティとして設定します（スクリプトAPIには公開されません）。
4. ノード自体のObjectコードに、他のすべての人をだましてbackup_scriptをオブジェクトの公式scriptプロパティとして表示させるタスクを処理させます。
5. エディターアイコンのメタデータを更新します
6. 簡単な説明のメタデータを更新します（？）

...それ以外の...

1. 組み込みノードを作成します。
2. カスタムタイプスクリプトをscriptプロパティとして添付します。
3. カスタムエディタアイコンのメタデータを更新します。

マルチスクリプトは今年2回目に追加され、再び簡単に削除できました（複数の問題が発生します）。

同意します。 現時点では、マルチスクリプトオブジェクトは悪い考えだと思います（とにかく実際には必要ありません）。 それは私が提案していることではありません。 パブリックビューでは、 Objectはまだスクリプトが1つしかないはずですが、スクリプトとしての役割を引き継ぐバックアップスクリプトを利用できるようにすることをお勧めします（したがって、 scriptプロパティに自分自身を割り当てます）メインのscriptプロパティがnull /アンロードなどに設定されている場合は常に。これにより、Objectクラスに対するコードベースのインターフェイスを変更することなく、「カスタムタイプ」をより効果的にサポートできるようになります。 次に、このバックアップスクリプトプロパティ専用のセッター/ゲッターを使用して、コード（ CreateDialogカスタムタイプスクリプトを割り当てるコードなど）でその存在を追加または削除できます。 このように、これはscriptプロパティの動作をオプトインで変更したものであり、エンジンに必要な変更が比較的少なくなります。

ノードのコンテキストメニューの新しいオプションは、この問題を解決すると思います。「継承されたスクリプトを置き換える」これは、現在から継承されたすべての検出されたスクリプトと、新しいスクリプトをクリックしたときに最後に「新しいスクリプト」を含むサブメニューを持つこともできます。ダイアログの「extends」フィールドにスクリプトのパスが表示されます。

「スクリプトの置換と継承」エディタツールを追加するだけで、より簡単で透過的になりませんか？ つまり、これは問題にすぎません。アドオンノードを作成するときは、スクリプトがないと予想されるためです。ただし、アドオンノードは、実際には、ノードの作成ツリーに追加するカスタマイズされたノードであり、ユーザーはそれを知っている必要があります。 UXの観点から（私は専門家ではありませんが）、利便性のために透明性を犠牲にするべきではないと思います。

@ MarianoGnu @ henriquelalvesどちらも実際には同じではありません。 「カスタムタイプ」の意味は、エンジン内のノードタイプをシミュレートしているということです。 これは、スクリプト自体を削除できないことを意味します。 ノードに組み込まれている機能は、純粋なノードのように機能させるためにNode2DのNode2Dらしさを削除できないのと同じ方法で組み込まれています。

上記のAkienの人気のある賛成の投稿は、同様の詳細をカバーしています。

ここでのポイントは、カスタムノードを定義するスクリプトは、インスタンス化されたノードのプロパティではなく、そのタイプのプロパティであるため、非表示にする必要があるということです。 したがって、このスクリプトはカスタムノードにプロパティを付与する必要がありますが、組み込みノードのC ++クラスと同じようにインスタンス化されたノードのユーザーには表示されないようにする必要があります。 APIを提供しますが、変更可能ではなく、拡張可能のみです。

「継承されたものにスクリプトを置き換える」ものを容易にするためのエディターツールを作成する場合、それはすばらしいことですが、カスタムタイプのスクリプト以下のスクリプト階層のレイヤーは、想定されているため、どの機能も見ることができないはずです。 「組み込み」の動作をシミュレートします。

実際、 gdscript_parserやその他のスクリプトコンテンツからコンテンツにアクセスできるようにするには、カスタムタイプ情報がEditorNode::get_editor_data().get_custom_types()だけでなく、ClassDBシングルトンに含まれていることを確認するのが最適な場合があります。モジュールはその情報にアクセスできませんが、実際にはアクセスできるはずです。

スクリプトを公開することに個人的な問題はありません。これは実際には用語と哲学の問題です。あなたが言ったことによると、ClassDBに新しいクラスを追加し、代わりにそのクラスにスクリプトプロパティを追加することができます。ノードとクラスは、メソッドのスクリプトが存在することを確認し、クラスの親を呼び出す前にそれらを呼び出す必要があります。 可能だと思いますが、RC1より前に実行しなかった場合、以前のバージョンとの下位互換性が失われます。

@willnationsdevなるほど、カスタムタイプがエンジン内ノードとして扱われることに心から同意するわけではありません。 私にとって、エディターアドオンの「強力さ」は、カスタムノードとエディターツールの「パック」を作成し、それをgithubを介して共有することがいかに簡単であるかにあります。 これらのツールとノードはすべて、実際にはコピーアンドペーストできるシーンとスクリプトにすぎませんが、Godotはこれを容易にするためにアドオンAPIを提供しています。 私が最初にそれを使用したとき、私もアドオンがスクリプトレスであることを期待していましたが、それはエンジン自体がそれらをエンジン内ノードとして扱っているように見えたためであり、それはアーキテクチャではなくUXの問題です。 私がこれを修正すると思うのは：

1. [ノードの作成]ツリーのカスタムタイプは、異なる色で表示されます（カスタムタイプであることを明確に示しています）。
2. それらをシーンに追加すると、スクリプトアイコンが表示されますが、わずかに透明になります（デフォルトのスクリプトがあることを示しますが、置き換えることができます）。 スクリプトアイコンをクリックすると、エディタにカスタムタイプのスクリプトが表示されます。
3. カスタムタイプの[スクリプトの追加]ボタンは、[継承]オプションにカスタムタイプのスクリプトを自動的に入力します。

繰り返しになりますが、私は間違いなく専門家ではないので、カスタムタイプの最初の仮定！=エンジン内ノードは間違っている可能性があります。 また、あなたの解決策は私がこのスレッドで見た中で最も明確なものなので、Godotの開発がそのように進むかどうかは完全に理解しています。

編集：私はそれをもう一度読みました、そして私の「解決策」は基本的にあなたの最初の6つの解決策のステップです、ハハハ。

@ henriquelalves @ MarianoGnu私はそれらの組み合わせが確かに必要だと思います。 カスタムタイプクラスをClassDBに追加することは、必須のimoです。 あなたがヘンリケに持っていた3つの提案すべてを本当に愛しています。 特にアイデア2（私の個別のカスタムタイプのアイコンの提案よりもはるかに優れています）。 そして、「カスタム型とは何か」がある程度透過的であることを確認する必要があることに同意します。 バランスを保つ必要があると感じています。カスタムタイプかどうか、そしてそれが何を意味するのかを理解できるようにする必要がありますが、カスタムタイプをエンジンタイプのように感じさせるためにもできる限りのことをする必要があります。

@willnationsdevこれをassetlibから取得し、カスタムノードのコードを「ベース」スクリプトに移動しました。
collision_path_2d-1-modified.zip

私が目にする当面の問題は、プラグインがスクリプトをロードし、そのスクリプトが一意であるということです。別のカスタムノードを追加すると、同じスクリプトが作成されます。

それでは、その場合、スクリプトの置き換えはプラグインにとって何を意味しますか？ （多分何もない、私にはわからない）。

スクリプトの置き換えに問題がない場合（ツールモードがうまくいかない場合もあります）、カスタムノードのメニューに「カスタムスクリプトの拡張」のエントリを追加して、その置き換えプロセスを実行できます。

@henriquelalves @ eon-s私たちは同じことを考えていると思います。 私はこれが何よりもUXの問題であることに取り組んでいます。 これまでのところ、私はこのアプローチに部分的です。なぜなら、それは物事を可能な限りシンプルに保つと思うからです。これは常に良いIMOです。

スクリプトの置き換えに問題がない場合（ツールモードがうまくいかない場合もあります）、カスタムノードのメニューに「カスタムスクリプトの拡張」のエントリを追加して、その置き換えプロセスを実行できます。

拡張スクリプトはプラグインスクリプトから継承する必要があるので、それを置き換えることは問題ではないと思います。 しかし、繰り返しになりますが、私はコードベースにあまり精通していません。 とにかく、私は私の2セントを与えました、私はここから本当の開発者にそれを任せます;）

@willnationsdev申し訳ありませんが、私は抽象的なものについて混乱しました。 私の「abstract」基本クラスは、_init（）にprintステートメントを持っているだけで、誤ってインスタンス化したかどうかを教えてくれます...。

ここでチャイムを鳴らすために、カスタムノードタイプは、カスタムスクリプトの設定、GDScriptでの名前による参照と継承の機能、タイプのベーススクリプトを削除できないなど、エンジンタイプのように完全に動作する必要があります。 これは、エンジンによって実装されたノードの動作を模倣し、内部の一貫性と使いやすさを促進します。

「カスタム」ノードであることを示す問題に関しては、ノードの「ヘルプで表示」の上にあるインスペクターのドロップダウンに、オブジェクトのベーススクリプトファイルを表示するエントリがあることを提案します。 ユーザーと開発者の観点からは、それを使用するだけでカスタムノードであることを知っておく必要があります（他に誰がプロジェクトに追加しましたか？）。「カスタム」ノード（IMO）の目標は、GDScriptで区別できない型を定義できるようにすることです。内蔵エンジンタイプから。

@ Web-eWorks私は実際にこれに取り組んでおり（現時点で）、かなりの量の作業を完了しています（まだ少し方法があります）。 Objectクラスにバックアップスクリプトを設定し、ClassDBにカスタムタイプのストレージを作成し、新しいAPIを使用するようにEditorPluginメソッドを更新しました。 それでも、関連するClassDB関数（ can_instanceやget_parent_classなど）を更新し、すべてのEditor / CreateDialogを更新する必要があります。

@willnationsdev ClassDBに登録するということは、プラグインを作成する人が衝突を防ぐためにすべてのクラスにプレフィックスを付ける必要があることも意味することに注意してください^^ "

@Zylannええ、残念ながらそれは必要でしょう。

この時点で、バインディングとコアの変更のほとんどを整理したと思います。 今すぐEditor、CreateDialog、EditorHelp / DocDataクラス（およびGDScriptコンパイラ）を更新するだけです。

前に述べたように..私はまだ提案された解決策が良いとは思わない。
可能性が最も高い何かを試みる前に、私に確認してください
拒否されました。

2018年2月7日20:05、「WillNations」 [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、「WillNations」 [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、「WillNations」 [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システム）が「絶対確実な」カスタムノードタイプを定義できるようにすることです。 現在、カスタム型システムは「ノード上のスクリプト」のシンファクトリであり、新しいノードタイプを構築しようとすると、ワークフローと使いやすさの問題が多数発生します。その中で最も少ないのは、簡単、直感的、効果的に完全に機能しないことです。カスタムノードをゲームプレイコードで拡張します（組み込みノードとは異なります）。 より差し迫った問題は、他のカスタムノードから継承するカスタムノードを作成できないことです。

いくつかの特定のユースケースは、低レベルのノードを作成することです。おそらく、破壊可能な地形、ala Minecraft、またはマーチングキューブ/デュアルコンターを使用するその他の地形システム用のマーチングキューブベースのボクセルGridMap実装です。 カスタムコントロールタイプ（多くの最新のゲームで実装されている円形メニューコンテナ、エンジン仕様の範囲外になるほど高い任意のタイプの低レベルコントロール）。 そして、新しいノードを登録するプラグインを構築したい場所。 これらの各ケースでは、通常、ゲームプレイコードを処理するカスタムスクリプトを追加し、それを「実装」コード（GDScript / GDNativeで記述）とは別にする必要があります。

ここで伝えられていないのは、エンジンモジュールを記述してコンパイルしなくても、カスタムノードをエンジンノードのように動作させることが目標だと思います。

この改善は、必ずしも特定の機能（多くはありますが）によって推進されるのではなく、「現在の方法は後進的で、薄っぺらで、退屈である」という論理的根拠によって推進されます。 このシステムを完全に実装すると、エンジンを再コンパイルしなくても、GDScript / GDNativeからエンジンの組み込み型を拡張する非常に強力な方法が可能になります。 設計の観点からは、これは文字通り現在のシステムをまっすぐに改善したものです。

その後、特定のユースケースが必要な場合：プラグイン全体/ AssetLibraryエコシステム。
これが、この変更によるメリットの範囲です。

さて、ここに明示的な例があります：

作業中のプラグインgodot-skillsがあります。これにより、さまざまな新しいタイプのノードが導入されます。

効果：ファンクターのうなずき
ターゲッター：似ていますが、他のノードを見つけて収集するだけです
スキル：ターゲッターとエフェクトの階層を組み合わせてノードを見つけ、それらすべてにエフェクトを適用します
SkillUser：いくつかのスキルを「所有」している

これらの各ノードは、ユーザーが作成してシーンに直接追加できるものにしたいと思います。 ただし、これらのノードはすべて、基本タイプとして機能するように設計されています。 すぐに使用できる機能は多くなく、派生スクリプトをノードに配置する必要があります。 このようなユースケースでは、ユーザーが特定のスクリプト機能のセットを削除できないようにするノードを作成すると便利な場合があります。 たとえば、ユーザーがシーンに追加するTargeterノードにTargeterから派生していないスクリプトを配置しないようにします。 これは、スキルがターゲッターを子として持つことで得られるインスタント機能があるためです（Area2DおよびCollisionShape2Dノードと同様）。

現在のワークフローでは、ユーザーは...

1. カスタムタイプノードを追加します
   2a。 添付されているスクリプトを削除し、[スクリプトの追加]ボタンをクリックするか、
   2b。 ノードにscriptプロパティを設定します
2. EditorPluginが派生させたいカスタムタイプのスクリプトを保持しているダイアログウィンドウで見つけます。

このシステムでは、これらすべてを次のものに置き換えることができます。

1. カスタムノードタイプを追加します。
2. スクリプトとして追加（カスタムタイプスクリプトの派生を自動的に開始します）

ユーザーは、エンジン内タイプを派生させる独自のカスタムタイプを動的に追加できます（使いやすさを向上させるため）。 また、問題のノードにスクリプト化された機能の存在を強制することにより、プラグインの機能のセキュリティを強化します。 現在、ユーザーはスクリプトを簡単に削除して問題を解決できます（望ましくありません）。 さらに、誰かがノード上のスクリプトを「クリア」したい場合、そのノードはそのカスタムタイプ機能を失うべきではありません（これは大きなものです）。 カスタムタイプのスクリプトを使用するように戻す必要があります。

さて、更新します。 私は現在次のものを持っています。

• ClassDBは、カスタム型を直接追加および削除できるようになりました。
• EditorPluginには、カスタムタイプだけでなく、アイコンなどの他のエディター関連データを追加および削除する同様のカスタムタイプメソッドがあります。 これらのメソッドは、 EditorPluginがアクティブ/非アクティブに切り替わるたびに発行される新しいシグナルに接続されています。
• GDScriptは、スクリプトから継承するカスタム型の名前から直接適切に継承できるようになりました。
• 現在のスクリプトがノードのカスタムタイプのスクリプトと一致すると、シーンドックは透明なスクリプトアイコンを作成します。 それをクリックすると、エディターでカスタムタイプスクリプトが開きます。 この状態では、「スクリプトの削除」ではなく「スクリプトの追加」ボタンが表示されます。 選択した場合、このボタンは「継承」フィールドにカスタムタイプスクリプトの名前（null以外の場合）を事前に入力します。
• スクリプトを削除しようとすると、カスタムタイプのスクリプトがスクリプト値として再割り当てされます。 そのため、スクリプトを削除するには、最初にカスタムタイプのスクリプト値をset_custom_script(RefPtr());でクリアする必要があります。
• [ノードの作成]ダイアログには、カスタムタイプの継承関係と抽象ノードが正しく表示されます。
• project.godotファイルにはすべてのカスタムタイプが入力されているため、実行されたゲームは、ゲームの残りの部分が開始する前に、それらをmain.cppに設定できます。

完了する必要のある残りのタスク...

• ユーザーがカスタムタイプのクラスAPIドキュメントを生成できるようにします。
• ユーザーがscript_create_dialog.cppの[継承]フィールドを編集できないようにする別のバグを完全に修正します。
• 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が1つのスクリプトしか持てないという事実をどのように回避しますか？ それらはどのように...「スクリプト可能」になりますか？ それとは別に、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は、2番目のパラメーターとしてtrueを渡した場合にのみ、カスタムタイプを含むブールフラグを取得するようになりました。 これにより、エンジンの他の部分との互換性が損なわれるのを防ぐことができます。

@willnationsdevでは、スクリプトを組み込みクラスのように動作させるシステムでは、ユーザーがすべてのスクリプトとアドオンを組み込みクラスのような一級市民と見なして、「昔ながらの」方法を採用することを妨げているのはなぜですか。

ああ。 スクリプトが現在機能する方法は、 extends Node VBoxContainerに配置でき、それでも問題なく機能することです。 現在の実装がカスタムタイプの動作を壊す場合、いくつかの問題が発生します-エンジンタイプから直接派生する「通常の」スクリプトを使用しながら、カスタムスクリプトの動作を維持する方法はありますか？

@Zylannだからこそ、名前空間を導入して、スクリプトとプラグインのスクリプトをエンジン内の型と衝突することなく名前を介して安全に統合できるようにしたいのです。 人々が新しい方法だけを使用し、古い方法を無視することを妨げるものは何もありません。 そして、私は実際にそれが全体的に良いだろうと思います。 毎回明示的なパスを使用する必要があるのは面倒です。

@ Web-eWorksここでフォローしているかどうかはわかりませんが、...

カスタムタイプは、特に継承用のエンジン内タイプのように機能します。 したがって、カスタムタイプから拡張する場合は、エンジン内階層の完全に異なるブランチから拡張するかのようになります。 元。 私はカスタムタイプ作成した場合MyNode拡張Node 、私が上でそのスクリプトを置くことができなくなりますVBoxContainer私は置くことができないだけのようにNode2D "on" VBoxContainer 。 これは実際には意図された動作になります。

これで、名前空間の概念を使用すると、カスタムタイプではない名前付きスクリプトが理想的になります。 したがって、その場合、 Nodeを拡張するスクリプトを作成し、それをNode 、 VBoxContainerおよびMyNodeます。 それは理にかなっていますか？

つまり、私が言っているのは、たとえばMeshInstance $を継承するカスタムタイプMyNodeを作成し、そのノードをエディターでインスタンス化して、 Spatialを継承するスクリプトを追加しようとする場合です。 MyNode型のノードに、それは正しく機能しますか？ これは「エンジン」ノードで適切に機能し、それがエミュレートする必要のある動作です。

これは、「ユーザーレベル」スクリプトの継承階層のポイントに関係なく、カスタムタイプのスクリプトが呼び出されるようにするための問題であるため、名前空間に依存しない必要があります。

@ Web-eWorksはい、それでうまくいきます。 ClassDBのcustom_typesマップのすべての「第1レベル」エントリは、$ classesマップのタイプにリンクし直す必要があります。そうしないと、エラーが発生し、カスタムタイプはありません。作成されていません。 これにより、カスタムタイプからObjectまでのエンジンタイプに戻るときに、継承のチェーンが維持されます。

@willnationsdev念のために言っておきますが、$＃ MyNodeに_readyメソッドを追加し、Spatialから派生した準備完了ノードをユーザースクリプトに追加すると、 Spatial._ready(), MeshInstance._ready(), MyNode._ready(), script._ready()のように呼び出されます。 ？ （または、 _readyがディスパッチされた注文。）

私は、これは不必要で混乱を招くものであるという私の見解を今でも支持しています。 この問題は、コアエンジンではなく、エディターUIから解決する必要があります。

@reduzこれは、エディターUIだけで解決できるものではありません。 オブジェクトに対するユーザーのスクリプト操作を制御したい場合はそうではありません。 それは多くの人がセットアップしたいと思っている機能のように思えます。

スクリプト型の新しいグローバル識別子を設定するために、gdscript_compilerがEditorDataのコンテンツを参照する必要があることを提案していますか？ClassDBですべてを追跡し、ClassDBがエンジン内のすべての継承情報を管理できるようにするのではありませんか？

確かに、エディターUIの観点から解決する必要のある部分もありますが、コアで解決する必要のある部分もあります。 エンジンにカスタムタイプを追加することは、ClassDBの観点からは_actual_タイプであり、非常に強力で、最終的に必要な機能です。 紛らわしい限り、私はそれが現在のシステムよりも混乱することはなく、おそらくそれよりも少ないと主張しています。

@ Web-eWorks同意します。 継承データをエディターで追跡することは、私の意見では実際にははるかに混乱します。 また、エディターなしでゲームを実行すると、そのタイプ情報が存在しなくなるため、奇妙な回避策が発生します（そのため、実際に情報をproject.godotにロードするために、情報のロードを開始する必要がありました。起動時にClassDB 。カスタムタイプを追加するためのEditorPluginsがないため、シーンの実行時にGDScriptのコンパイルが失敗していました）。

@ Web-eWorksそして、あなたの以前の質問に答えるために、はい、それは正しく機能します。

私のテストシナリオでは、 GDSkillsEffect > GDSkillsAPI > Nodeを拡張する$ Node.gdがあり、各スクリプトに実装されている_readyメソッドは適切にトリガーされます順序：API、Effect、Node.gd。

2つのスクリプトの両方がカスタムタイプのスクリプトから名前で継承しようとするときはいつでも、私は現在、ある種の無限ループエラーを経験しています。 元。 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あなたの努力に感謝しますが、これはすでに終わりのない議論であり、コンセンサスは次のとおりです。

• カスタムタイプの追加はスクリプト言語ごとに異なるため、ClassDBで何かをハッキングすることは、実際にはC ++のものを登録することだけを目的としています。
• このような長さになる前に、カスタムノードのスクリプトを拡張する場合のUIの使いやすさを向上させることができるため、単純な継承が作成されます。
• 一般に、コーナーケースを処理するためにコアエンジンにハックを追加することは決して道のりではありません。 コアはハッキングのない状態を維持する必要があります。

@willnationsdev参考までに、エンジンの動作では、継承階層で_something_を拡張するスクリプトをノードに追加できます。 したがって、 extends Spatial MeshInstance追加できますが、 ControlまたはNodeは追加できません。後者は、どちらもSpatialから継承されていないためです。

@reduzしかし、Monoで新しいクラスを作成すると、それがエンジンの継承階層に追加されますか？ または、編集者の[ノードの作成]ダイアログ？ おそらく、ここでは同じことについて話しているのではないと思うので、これの目的が何であるかを簡潔に述べた新しい問題を開く必要があります。

ClassDBの変更のポイントは、エンジンを再コンパイルすることなく、新しいタイプのノード（またはリソース）を登録できるようにすることです。 GDScriptに新しいカスタムグローバルを追加しないでください。ただし、これは@willnationsdevが同じブランチで取り組んでいる接線の問題です。

これのポイントは、ハックを追加することではなく、エンジンのタイプを拡張するために適切に設計された_system_を作成することです。

@ Web-eWorksエンジン継承階層は、スクリプトではなくC ++用です。 それらの両方を混合しようとすることは、そもそも概念的に間違っています。

おそらく誤解は、ノードの作成ダイアログが新しいクラスが追加されたように見えることです。そのため、そのようなカスタム型にスクリプトを明確に含むものとしてマークを付けることをお勧めします。

@ Web-eWorks Monoを使用している場合、Monoは新しいクラスであるため、新しいクラスが追加されたかのように透過的に表示されます。 GDScriptの場合、クラスはデフォルトでファイルであるため、この方法で行うことはできません。そのため、これを行う方法は、専用のUIを備えた新しいグローバルを追加して設定することです（シングルトン自動ロードの場合のように）...ただし、これはまだスクリプトクラスであり、エンジンクラスではありません。

@willnationsdevこれに関する私の全体的なポイントは、実際の新しいクラスをエンジンに追加しているように見せることは間違っていると思うということです。そうではないからです。 混乱する可能性があります。 これはスクリプトを含む単なるノードなので、スクリプトを非表示にするのではなく、作成ダイアログでスクリプトをより見やすくすることが正しい方法だと思います。

@reduzまあ、それが問題です。 Node + Scriptはシーンです。 add_custom_typeメカニズムは、Monoのように動作し、標準によって技術的に「クラス」でなくても、「新しいクラス」を登録する必要があります。 ClassDBに触れることなくそれを行う方法があれば、私はすべての耳です。

また、@ akien-mgaは、シーンツリービューでカスタムノードのスクリプトを非表示にして、ユーザーがそのスクリプトを作成して誤って編集したことについてユーザーを混乱させないようにすることを提案しました（ただし、下部のインスペクターに表示します）。 。

このようなノードでは、スクリプトを追加すると継承モードで作成ダイアログが開くため、それがカスタムノードであり、エンジンの一部ではないことは明らかですが、ユーザーのワークフローに関してはかなり透過的です。

@willnationsdev実装の範囲を具体的に詳述する、新しい、より簡潔な問題を開くことに異議はありますか？

@ Web-eWorksノード+スクリプトはシーンではなく、ツリーレイアウトのノードはシーンです。 ノードだけでなく、カスタムリソースタイプを追加することもできます。

いいえ、新しいクラスを登録するように動作するべきではありません。 スクリプトが事前に追加されたC ++クラスであることを明確にする必要があります。

@ Web-eWorksええ、それは私には問題ありません。 私に言及してください。そうすれば私はpingを受け取ります。 別の問題が必要かどうかわかりませんか？

別の観点から見てください。 あなたの議論は、あたかも新しいエンジンタイプでエンジンタイプを拡張しているかのようにユーザーに見えるようにすることです。

私の見解では、新しいエンジンタイプではなく、スクリプトを使用してエンジンタイプを拡張しています。 そして、ユーザーは愚かではなく、これを知る必要があります。

@reduz Node + Scriptについて私が意味したのは、そのメカニズムはシーンのインスタンス化によってすでにカバーされているということでした。

たぶん私はMonoの実装を誤解していますが、Monoクラスはまだスクリプトではありませんか？

@reduz私はほとんどあなたに同意します。また、カスタムノードにスクリプトを追加すると、それを継承することを提案するだけだとあなたが言ったときもそうです。 しかし、これがGDNativeカスタムタイプでどのように機能すると思いますか？

@reduzただし、私たちの目標の1つは、カスタムタイプのスクリプト（C ++クラスに配置されたこれらの事前に割り当てられたスクリプト）を削除できないようにすることです。 これは、実行時にいつでもスクリプトを削除できるため、エディターのコンテキストでは実行できないことです（その機能を保持し、エディターで設計時にカスタムタイプのスクリプトのみを保護する場合を除く）

私は確かに別の方法を受け入れるでしょう。 いずれにせよ、最も簡単な実装は、サードパーティの登録クラス（ClassDB、ProjectSettings、EditorData、または他に何を知っているか）をチェックすることによって、オブジェクトに条件付きでスクリプトを割り当てさせることです（実装で行ったように）。 。 そうすれば、編集者自身がそのサードパーティに確認して、別の方法で表示することが非常に簡単になります（実装で行ったように）。 ただし、登録をClassDB以外のコンテキストに移動することはあまりないと思います。

^その妥協は受け入れられますか？ それ以外の場合は、オブジェクトがサードパーティに確認するために割り当てられたスクリプトを取得する可能性のあるすべての場所を細かく管理する必要があります。 それははるかに複雑になります。

私が行った実装は、これまでのところ非常に明確です。どの「タイプ」がスクリプトであり、どの「タイプ」がスクリプトではないかについてです。 結局のところ、私が共有したビデオのシーンドックで、カスタムタイプに関連付けられたスクリプトをはっきりと確認してアクセスすることができます。

@willnationsdevあなたがやろうとしていることは理解していますが、これをきれいに行うことはできないと思います。 それは、期待どおりに完全に機能することは決してない方法で、隠される理由のない複雑さを隠しています。

@Zylann同じだと思いますが、a）スクリプトがgdnative internalである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のセッター/ゲッターは別として）。 また、識別子と名前空間を定義するためにGodotに依存する必要がないスクリプト言語の不必要な複雑さを防ぎます（C＃、C ++、Pythonなどとは異なり、GDScriptやVisualScriptが必要になります）。

次に、カスタムタイプ/カスタムタイプの継承を確認する実験的なClassDB機能を置き換えるために、適用可能なすべてのスクリプト言語で識別子/名前空間チェックを実行できるScriptServerメソッドを定義するだけです。階層。 簡単です。

このいずれかが許容可能な代替@reduzのように聞こえますか？

ここに私の声を追加するだけです。 私はGodotを使い始めたばかりで、カスタムタイプのアドオンについて読んだとき、実際に新しい再利用可能なベースタイプを作成すると思いました。 KinematicBodyを作成するときのように、スクリプトをそれにアタッチできますが、それでもKinematicBodyのすべてのことを実行します。

これは2つの方法で強化されます。

1. それらは型と呼ばれます。 タイプが拡張可能かどうか（javascript：yes、golang：no、python：yes）は言語によって異なりますが、ファーストクラスの言語タイプが拡張可能であれば、通常、定義するタイプは拡張可能です。 Godotでは、ファーストクラスタイプは拡張可能ですが、カスタムタイプは拡張できません（少なくとも同じ方法ではありません）。 それらをプレハブシーンやテンプレートシーンなどの別の名前で呼び出すと、それらを異なるものとしてマークするのに役立ちます。

1. これらは、[新しいノードの作成]ウィンドウのファーストクラスノードと同じツリーに表示されます。 これは、同じように使用することを意味します。 「プレハブ」または「テンプレート」、またはそれらを呼び出したいものに個別のセクションがあると、それらは再び異なるものとして呼び出されます。

@JPTeasdale残念ながら、現時点でのより大きな懸念は実装であり、「これをどのように定義するか」という質問ではありません。 そして、Godotカスタムタイプは拡張可能です（それらは単なるスクリプトです）。 エディターには、ノード作成ダイアログでカスタムタイプ間の継承関係を表示するためのコードサポートがまだありませんが、データは利用できます。 また、「カスタムタイプ」から別の名前に変更する理由もわかりません。 「プレハブ」と「テンプレート」は実際には適切な用語ではなく、そもそもシーンでもありません（これらは単なるスクリプトであり、単純で単純です）。

私はそれが意図した解決策よりもはるかに簡単だと思います：

1. インスペクターに隠されているプロパティを「custom_type_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のみに情報を保存することをお勧めします。 個々のスクリプト言語のすべての情報が含まれています。

非表示のスクリプトをオブジェクトに保存する代わりに、スクリプトリーダーにプリパスを追加して、「extendCustomClassName」を「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 。