Godot: `class_name`の使用法によっては、予期せず循環エラーが発生する可能性があります

基本スクリプトにclass_nameを指定し、それを拡張行で使用すると機能します。
最初にファイル名を使用したときにもエラーが発生します（https://github.com/godotengine/godot/blob/master/modules/gdscript/gdscript_parser.cpp#L4947）が、消えて表示されません一度機能した後（前述の回避策を使用した後のように）

@ PetePete1984かっこいい、ありがとうピート。 これがその時の使用目的ですか？

これを再確認してテストしているときに、 get_class()メソッドを調べていて、Node2Dを返す必要があるかどうか疑問に思いました。 is CustomClass部分は_true_を返しますが、一方is_class("CustomClass")は_false_です。

CC @reduz @vnen @willnationsdev

私はそれが意図された振る舞いであるとは言いません、特に何もないところに周期的な包含を暗示するエラーメッセージではそうではありません。
get_class()とis_class()は一般的に私を混乱させます、それについて本当にコメントすることはできません。 ソースは長期的にはその謎を解くかもしれませんが、これまでのところis十分でした。

@vnenこれは、より明確なエラーメッセージを必要としているものでしょうか？

@ PetePete1984はい、 isは3.1で驚くべきものになりました。 match custom_thing.get_class()ような新しいmatchを使用して、いくつかの文字列と比較したいという状況に遭遇しましたが。 しかし、重要なことは何もありません。読みやすさとタイピングの少ないことだけです。

@avencherusあなたは

match custom_thing.get_script():
    <typename>: stuff # script classes
    <typename>: stuff
    _: match custom_thing.get_class():
        "Node": stuff # engine classes

なぜこのエラーが発生するのかわかりません。調査する必要があります。

@willnationsdev get_script()部分から何をチェックするのか完全にはわかりませんが、少なくとも私にとっては、GDScriptオブジェクト[GDScript:1057]返します。

@vnenありがとうvnen。 X）これらの提案を試して、より良い情報を提供できるかどうかを確認するために戻ったとき、他の奇妙なことが起こっているようです。 少し引っ張って再構築し、それをいじります。 追加するものが他にあるかどうかを確認します。 途中で別の問題にぶつかったかもしれません。

@avencherusスクリプトクラスの「クラス名」は、スクリプトを参照するグローバル変数です。 そう...

class_name CustomType
match get_script():
    CustomType:
        print("I am a CustomType!") # should print

@willnationsdevああ、きちんと、私は今わかります。 class_nameがそのように機能することや、カスタムタイプが一致パターンで使用できることを期待していませんでした。 このヒントを共有していただきありがとうございます。

@vnenはい、ストーリーにいくつかの追加のしわがあります。 それらをどれだけうまく表現できるか見てみましょう。

まず、Peteのソリューションは機能します。基本クラスにclass_nameが与えられると、すべて問題なく表示されます。 私が気付いたのは、基本クラスに戻って、追加したclass_name CustomBaseを引き出すと、半分は機能するということです。 ノードを追加するときにノードリストに表示されなくなりましたが、 isは機能し、奇妙なエラーは発生しません。

次に、これを確認するために、base2.gd-> custom2.gd拡張スクリプトを作成する手順を再作成しました。 次に、custom.gd内でclass_name CustomClass2使用しますが、基本クラスにはクラス名を付けません。

別の問題が発生しました。 ノードリストには最初のものがありましたが、「エラー」というアイコンでリストされていました

そこで、最初の基本クラスを変更して、両方がclass_name使用するようにしました。 しかし、再び奇妙な結果を得ました。

すべてがノードリストに表示されているわけではなく、 isキーワードはそのうちの1つに対してのみtrueを返しました。 このスクリーンショットでは、ノードリストがCustomClass2を認識していることがわかりますが、その背後にあるコードでは、 is CustomClass2がfalseを返しています。

多くのことが切り替えられているか、舞台裏で長引いているようです。 私の限られた知識でそれが何をしているのかを完全に予測するのは難しいです。

お役に立てば幸いです。 バツ）

編集はこのコメントを無視します。 class_nameが3.0.6で実装されていないことに気づいていません

class_nameは3.0.6で壊れているようです。 別の問題を作成しますが、次のとおりです。

@bfishmanスクリプトクラスは3.0.xの機能ではありません。 それが機能していない理由です。

私は次のことを試しましたが、各バージョンが機能しました。 すべてのスクリプトクラスがCreateDialogに表示され、スクリプトが正常にコンパイルされ、シーンが正常に実行されました。

このようなシーン階層の場合：

• ノード（base.gd）
  
  
  
  • ノード（派生.gd）
  
  

脚本：

# res://base.gd
extends Node
class_name BaseNode
func _ready():
    print("base")

# res://derived.gd
extends BaseNode
extends "base.gd" # I tried both of these 'extends' lines and they each worked
class_name DerivedNode # I tried with and without this line
func _ready():
    print("derived")

テストを実行するたびに、印刷されました

base
derived
base

...そうあるべきです。

私の提案は、エディターのファイルキャッシュをクリアしてみることです（プログラミング/エンジンの更新中にファイルキャッシュの保存方法に変更があった場合、クリアするまでどういうわけか混乱する可能性があります）。

@willnationsdev見てくれてありがとう、これを試してみます。 これはAppData / Roamingフォルダーのファイルですか？ とりあえずすべてをクリアします。 もしそうなら、私が削除すべきより具体的なものがあるかどうか疑問に思いますか？

@avencherusよくわかりません。 以前にスクリプトクラスのアイコンにいくつかの修正を追加したときに、 @ karroffelがそれについて何か言及したことを思い出します。

https://github.com/godotengine/godot/commit/1093c0ff51b980634dffdd9618eaa53061da6419でテスト済み
エラーは表示されませんが、[新しいノードの作成]ダイアログにノードが表示されません。

元の投稿（Windows x64 Godot 3.1 alpha）に示されているエラーも発生します：

ただし、それは別のコンテキストで発生します。 それぞれ異なるclass_nameを持つ3つのスクリプトがあり、それぞれがNode2Dを拡張しています。 スクリプトの1つがis演算子で参照しない限り、エラーは発生しません。 たとえば、 if some_var is Incomerです。 ただし、奇妙なことに、同じスクリプトが他のclass_nameを参照していれば、問題はありません。 また、他のスクリプトが問題のclass_nameを参照している場合も、問題はありません。

つまり、ClassA、ClassB、ClassCがあります。 ClassCがis演算子を使用してClassAを参照している場合、ロード時にエラーが発生します。 ClassCがClassBを参照している場合、エラーはありません。 ClassBがClassAを参照している場合、エラーはありません。

どのスクリプトも同じシーンになく、すべてのノードが兄弟です（祖先の関係はありません）。

@AlexHolly今も私と同じ状況です。 エラーはなくなったようですが、 class_nameも使用する基本スクリプトがない場合、クラスはノードの追加ウィンドウに表示されません。

これはアルファ3.1c320d93です

「is」を使用した小さな例。 「as」を使用した場合も同じことが起こります。
これは@Oranjooseによっても言及され
cycle.zip

どのスクリプトも同じシーンになく、すべてのノードが兄弟です（祖先の関係はありません）。

これは、シーン内のノードとは何の関係もありません。 サイクルはスクリプト自体で発生します。

今のところ、 isとasを使用すると、サイクルを取得するのは非常に簡単です。それが発生した場合、それは実際にはバグではありませんが、現状のままです。 私はこれを改善しようとしますが、3.1では改善しません。 コードに実際のサイクルがないため、元のレポートはバグです。

451e5fdでもエラーを再現できませんでした。 ノードが作成ウィンドウに表示されませんでした。

この問題は0dbe014（私が引いた最新のマスター）には存在しないことを確認できます。 おそらくこの問題を解決できます。

また、スクリプトを拡張するスクリプトクラスがCreateDialogに表示されるようにすることができましたが、これはまだバグでした。 PRは上にリンクされています。

@willnationsdevありがとうウィル。 X） class_nameでさまざまな問題にぶつかっていますが、これを再現できませんでした。 それらを再現するのは非常に困難ですが、それ以来、私はそれらの使用をやめました。

参照されているスクリプトのエラーが原因で、あいまいで無関係なエラーがスクリプトに表示される場合があることに気付きました。 それらは、原因のスクリプトを開くとより意味のあるものになり、修正すると、これらの他のスクリプトもクリアされます。

ただし、この周期的なエラーは奇妙な状況でも発生しているようであり、再現しようとするとわかりにくいため、投稿のトピックを再調整します。 ですから、おそらくまだ何かが残っているので、vnenのために開いたままにしておきます。

@avencherusなるほど。 それがどのような状況で起こっているのかを最終的に特定できることを願っています。 コンテキストがなければ、修正することはできません。 XD

godotで発生した循環参照エラーに気づきました-次の作業では、静的型付けを使用して、スクリプトのクラス名と同じ型を返していると言うことができましたが、実際にクラス名を参照しようとするとスクリプトの（後で関数に戻るためのインスタンスを作成するために）、スクリプトはそれ自体を参照するため、スクリプト自体を無限に再帰的にロードする必要があるため、機能しません。

私が見つけた解決策は、 load(get_script().resource_path).new()を使用すること

私は定期的にそれをからかうために努力し続けます。 もっと助けていただければと思いますが、実装について深い知識を持っている人が自分のプロジェクトに取り組み、最初にこれらの問題にぶつかるまで待たなければならないと思います。 私は彼らがその状況で彼らの視線をどこに置くべきかを知っているだろうと賭けます。

いくつかの問題の簡単な要約（これらは今後数週間のうちに投稿されます）：

1. obj is MyClassを実行すると、これらの周期的なエラーが発生し、2つの間に他の接続や参照がありませんでした。 シーンツリーをスキャンして、その子を循環参照としてカウントしているかどうかはわかりませんが。
2. あなたが説明した不便にも遭遇しました。 同じタイプの状況で組み込み/ネイティブクラス名で正常に機能するため、そうでないことを望みます。 したがって、カスタムタイプの追加を開始するまでは、すべてが順調であると考えて、この目的を念頭に置いて大量のコードを記述できます。ハック/回避策/古い方法に頼る必要があります。冗長なパス名を避けない場合の値は？
3. 私はこれらのことをエディターでエラーなしで実行し、テスト実行中にクリーンに実行しましたが、エクスポートされたゲームでエラーと失敗が発生し続けます。 以下の例（おそらくこの問題とは無関係ですが）は、class_nameの使用法がビルドでアイコンを見つけることができなかったが、エディターからの実行とテストで問題がないことです。

全体として、 class_name私の経験は、予測不可能で、説明が難しく、エラーを再現するのが難しい、ほぼ毎日の出会いでした。 その周りで踊り、それらを解決しようとすると、多くの時間が無駄になります。

私は本当に彼らを楽しみにしていました、そして彼らは絶対に特定のもののコーディングをずっとコンパクトで読みやすくするでしょう。 実用的な時間の理由で、私はそれらを脇に置き、現在のプロジェクトでそれらを使用することをオプトアウトする必要があります。

多分4.0で。 バツ）

スクリプトパスの古い方法に戻ります。 そうすることで、ランダムなclass_nameサプライズを回避し、コードの一貫性を保つために、それらをずっと使用することが私自身の好みになります。

前に述べたように、特にisとasを使用する場合、 class_nameでサイクルを作成するのは非常に簡単です。 パスを使用するのは簡単ではありませんが、同様の問題にぶつかる可能性もあります。 問題は、GDScriptがそのように機能するように配線されていないため、リソースの読み込みに大きく依存していることです。 これを修正するためのアイデアがいくつかあります（特に、リソースの読み込みを無視し、依存関係の浅い解析を直接実行するだけです）が、これにはパーサーの構造変更が必要です。

おそらく、これを台無しにするのは良い時期ではないので、次のバージョンで適切に解決されるでしょう。 class_nameは、今のところ「より少ない機能」になります。 場合によってはまだ使用できますが、期待するほど広範囲には使用できません。

@vnenねえ。 お帰りなさい。 バツ）

返信とタイムラインをありがとう。

うん、だから今は棚に置いておく必要がある。 私はそれがそれほどスムーズで、適切で、自然な統合ではないことに気付くのに少し時間がかかりました。 （プロジェクトファイル内のすべてのエントリを見たとき、私はこれのヒントを得ていました。）

「少ない」機能のように思えますが、しわを解消できれば、非常に深刻なメリットがあります。 私は本当にそれを楽しみにしていて、すでにそれをいくつか使用した後にその喪失を感じます。 それは間違いなくGDScriptにとって良い道です。

私が見逃している大きなことの1つは、カスタムクラスを新しいタイプのヒントと組み合わせたときにヒントを利用できることです。 var thing : NewThing

数日かけて大規模なクラスを作成すると、おそらく数日後に初めて使用するようになりますが、数回使用するまで、すべての関数の名前を100％正確に覚えているとは限りません。 したがって、これらのヒントを取得することは、私にとって非常に予想外で重要な生産性の向上でした。 私はずっと長く1つのエリアに滞在して働くことができました。

確かに問題の核心はあなたが言うように、簡単なサイクルですが、私の最も悪い経験は、現在いくつかのエラーが正しい場所を指していないということだと思います。 数週間経ちましたが、カスタムクラスを使用して数日間はすべて順調だったという状況がありました。 次に、そのカスタムクラスを呼び出すコードをさらにいくつか作成し、開発中のある時点でサイクルエラーが発生し始めました。 場合によっては、これらのエラーは、エラーが発生している場所を説明するのに役立たなかった。 それを見つけるために、エラーが停止するまで、すべてのクラス名の使用法を1つずつ探して削除する必要がありました。

そのようなほんのわずかな事件が利益の多くを取り戻しました。 30,000行のどこかでそのような問題を引き起こすことを想像するのが怖いです。

私がそれらすべてをヤンクさせた1つの事件は、サイクルエラーがエクスポートビルドにのみ現れ、無関係のスクリプトエラーをスローしていた事件でした。 アイコンのテクスチャが見つからないと言っていたと思いますが、実際にはそうではなく、class_nameの使用法をいくつか捨てるとクリアされました。 class_nameが失敗していて、エラーが次の行にあると思われます。

原因の上または下の行でエラーが発生している場合に発生することがあります。

私とここでのゼロ知識がこれらの問題の多くの原因を特定することは本当に難しいです。 その多くは私にとってはカーテンの後ろにあるだけであり、あなたがこれのいくつかを解読することができて感謝しています。

3.1では、警告やエラーを伴う異常なイベントが多数発生しているので、問題はそれ自体なのか、それともエラー報告ロジックの問題なのか疑問に思います。 どこから始めればよいのかまだ正確にはわかりません。そのうちのいくつかが役立つことを願っています。また、時間の経過とともに、それらを小さなプロジェクトに絞り込むことができるかもしれません。

編集：気にしないでください、どういうわけか私はそれをしないことによって単に循環包含を解決しました...
project.godotのグローバルクラスは、エディターを起動するととにかく上書きされます。

@vnenまたは@avencherusOPを更新して、このバグが最終的に何であるかを明確に説明することをお勧めします。そうしないと、良いアイデアを得る前に読むのに長い議論になるからです。

@ akien-mga私はもうそのステータスについて、またはそれについて具体的に何を書くべきかについてあまりよくわかりません。

私が思い出すならば、少なくともそれには部分があります。 現在の形式のGDScriptの制限として予想される循環エラー、および小さなプロジェクトで分離して再現するのが難しいと思われる予期しないエラー（エラーメッセージが不正確な場合もあります）。

現在使用している機能ではないので、進捗状況を追っていません。 この時からあちこちで修正されていることがあると思います。

これらの他の問題を一見すると、GDScriptで必要な変更に関する話のように見えます。 3.2を目指した改訂で。 それが計画である場合、3.1マイルストーンの下にはもうありません。

vnenが簿記に使用している場合、または3.1.0が安定して着陸したときに今後発生する重複の問題を参照するために使用する場合を除いて、これを閉じることはおそらく問題ありません。

この機能は、私が興味を持っているユーザビリティの勝利であるため、3.2で再検討し、調査結果を投稿する可能性が非常に高いです。

まあ、これは閉じるべきではありません、いいえ、重複したレポートの膨大な量は間違いなく修正するものがあることを示しています:)

プロジェクトを3.0から3.1に更新する際に問題となる次のエラーメッセージが表示されました。 以前は、次のコードが機能していました。

extends Node2D
export(String, FILE, "*.gd") var _class_name = "res://Test.gd"
onready var SomeClass = load(_class_name)

func foo():
    for c in get_children() :
        if c is SomeClass : 
            do_stuff()

コードを次のように変更すると：

extends Node2D
class_name SomeClass

func foo():
    for c in get_children() :
        if c is SomeClass : 
            pass

次のエラーが発生します。

解析エラー：クラスファイルで1つの名前を使用することは許可されていません（循環参照を作成します）

私が探している子ノードはすべてこのクラスから継承し、そうでない他の子ノードと混合されているため、これは私にとってイライラします。 この方法で機能しないように意図されたスクリプトクラスの他のインスタンスのタイプチェック機能はありますか？これを行う必要がある別の方法があります。

@Diaspaterあなたがしなければならないのはif c is SomeClassをif c is get_script()変更することだけだと思います。 どちらのオプションもランタイムチェックを実行しますが、 SomeClassバージョンでは、エディター時にスクリプトを再度ロードする必要があります（循環参照になります）が、 get_script()メソッドは編集者時間。

@willnationsdevそれが有効な解決策であることを理解しています（または、最初の方法がまだ機能していることを元のコメントを書いた後に気付いた私の問題の回避策です。それは、2番目の方法が適切にサポートされることを望んでいると言われています。私も理解しましたこれが機能すること：

DummySomeClass.gd
extends Node2D
class_name DummySomeClass

func foo():
    pass


SomeClass.gd
extends DummySomeClass
class_name SomeClass

func foo():
    for c in get_children() : 
        if c is DummySomeClass: 
            pass

そうは言っても、なぜ現在エラーが発生しているのかについての説明は理解できます。 この問題に対する複数の解決策または回避策があるため、これは修正する必要のある必須のバグではないと思いますが、将来のある時点で修正してもらいたいバグです。

この方法を少し複雑な使用法で使用した後、これが他の結合スクリプトの他の場所で他の循環エラーを引き起こしているように思われるため、これはおそらく問題の適切な解決策/回避策ではありません。

これは単純な質問かもしれませんが、この非周期的な制限を取り除くべきではありません。
つまり、Java、C＃、C ++などの他の言語は問題なく型を処理できます...

@harrapsは実行されますが（スレッドで数回言ったように）、GDScriptの配線方法にいくつかの基本的な変更が必要です。 リリースが近づいており、この変更により互換性が損なわれる可能性があるため、ここでは触れません。

他の人がこれに遭遇した場合、「循環参照」関連のエラーの別のインスタンスを見つけましたが、ここにリストされている他のインスタンスとは異なります。

戻り値で現在のクラスの名前を参照する静的ファクトリメソッドを使用してクラスを作成すると、エディター自体のエラーは報告されませんが、エディターを閉じると、エラーレポートが表示されます。そのリソースはまだ使用されています。

extends Reference
class_name MyClass

static func make() -> MyClass:
    # can't even use get_script() for static funcs, but that's a separate issue
    var c = load("res://my_class.gd").new()
    return c

次に、次のエラーが発生します。

ERROR: SelfList<class GDScriptFunction>::List::~List: Condition ' _first != 0 ' is true.
   At: .......\godot\core/self_list.h:111
ERROR: SelfList<class GDScript>::List::~List: Condition ' _first != 0 ' is true.
   At: .......\godot\core/self_list.h:111
WARNING: ObjectDB::cleanup: ObjectDB Instances still exist!
     At: core\object.cpp:2093
Leaked instance: GDScript:17060 - Resource name:  Path: res://my_class.gd
Leaked instance: GDScriptNativeClass:1058
ERROR: ResourceCache::clear: Resources Still in use at Exit!
   At: core\resource.cpp:425

＃944からの再投稿、

また、定期的にGDscriptの周期的な依存関係に遭遇しています。 現在、型指定されていないGDscriptに戻すことを余儀なくされているいくつかのユースケースを次に示します。

1. 私のキャラクターは、異なるMoveを実行するActorControllerています（ステートマシンの状態のように）。 ActorController _physics_process()などをアクティブなMove転送します。 逆に、移動はActorControllerにアクセスして、別のMoveに切り替えるか、プロパティ（ジャンプの高さ、走行速度など）にアクセスします。

2. 私のMoveRepositoryと同じ状況-リポジトリは再利用可能なMove格納しますが、別のMoveをフェッチする場合は、 Moveもリポジトリにアクセスする必要がありますActorControllerそれを選択します

これはC＃またはC ++では問題になりませんが、GDscript（オプションの静的型付けあり）では、バリアント（動的型付け）にフォールバックするか、イベントなどを使用して不要な間接を作成する必要があります。

私もこの問題を抱えています。 私は似ているがより単純な設定をしています。
クラスTurnManagerは型Actor変数があり、すべてのActorにはTurnManagerへの型付き参照があります
私はisを使用していません。文字通り変数を宣言したばかりで、このエラーを引き起こすのに十分です。
Linux64ビットで新しい安定バージョン3.1を使用する。

ちょうどこれに遭遇しました。 関連しているようです。

確かに非常に奇妙です。

私もこれに遭遇しているようです。 スクリプトがほとんどオブジェクトから切り離されていたからだろうかと思っていました。 ノードを拡張する基本属性クラスと、それを拡張するPrimaryAttributeおよびSecondaryAttributeがあり、12個のPrimaryAttributeノードとSecondaryAttributeノードが好きです。 編集者はそれを気に入らないようですが？ プレイするとゲームは正常に動作しますが。

注目すべきことに、class_namesのリソースパスを切り替えたところ、約5分間正常に動作してから、理由もなくエラーが発生しました。 ：/

うーん。 エラーは、エディターウィンドウに読み込まれる順序に関係しているようです。 継承した順序でファイルを閉じて再度開くことで、ファイルを削除できます。 だから、おそらくそれの周りのある種の問題がいくつかのファイルで物事を宣言していない。 ：/

編集：実際にはありません。ファイルを開く順序は関係ありません。また、他のファイルを開いている場合でも関係ありません。 これらのファイルの1つを最初にロードしたとき、エラーは表示されず、変更するまで表示されません。その後、すべてのエラーが表示されます。 ：/

@ Angular-AngelGodotを再起動するとエラーが解決することに気づきました。 奇妙なエラーがポップアップすることなく、カスタムクラス/タイプでGodotの静的型付けを使用できないのは残念です。

プロジェクトを「ただ」閉じる/再開するだけで十分でした。 Shift + Ctrl + Q（プロジェクトリストに移動）、プロンプトの確認、そしてプロジェクトをもう一度ダブルクリックします。 まだ少しイライラしますが、（修正されるまで）慣れます。

申し訳ありませんが、私も少しイライラしています。皆さんがコメントしていたので、その回避策については知りませんでした。しばらくの間、コードの入力をやめましたが、それでも多くのことを見逃しています。

同意しました。 これは私自身と他の人にとって非常に速く非常に重要な習慣になりました。 おそらく、再起動の回避策で今のところ十分かどうかがわかります。 2019年5月16日8:27には（ゴドーが速い素晴らしいものだから）、リカルド・アルカンタラ[email protected]書いた：申し訳ありませんが、私は少しあまりにもイライラしています、そしてあなたたちはコメントので、私はその回避策については知りませんでした、しばらくの間コードの入力をやめましたが、それでも多くのことを見逃しています。

-コメントしたため、これを受け取っています。このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

Godot 3.1.1（モノラルではない）
Stack.zip

最小限の再現可能な例

https://cdn.discordapp.com/attachments/477544613511692358/584811385838632977/unknown.png

_お願い_誰かがこれを修正してください。

ロードは正常に機能しますが、プリロードは機能しません

StackList.gdには実際にはキャッチされていないスクリプトエラーがあることに注意してください。 具体的には、辞書キー宣言の構文エラーです。 ただし、辞書が定数に変更された場合にのみキャッチされます。

今日も「is」class_nameバグに遭遇したことをメモしたかっただけです。

オブジェクトがclassNameであるかどうかをテストするのではなく、object.has_method（ "name"）を使用するように戻しました。

私は3.1.1でこれを頻繁にヒットし、それを回避するためにフープを飛び越えてきました。
3.2で修正されることを願っています！

新しい情報なしで問題をぶつけないようにお願いします。 私たちは皆、これが起こることを知っています、すでにたくさんの例があります、より多くのコメントで魔法のように消えることはありません。

私は現在@JavaryGamesでこれを修正しようとしていますが、解決策はすでに進行中です。 これは大きな変更であり（GDScriptが内部でどのように機能するかをある程度再配線する必要がありました）、リリースが近づいているため、3.2になるかどうかはわかりませんが、3.2.1などに統合できる可能性があります。 間違いなく4.0で修正されます。

私が取り組んでいた修正はまだWIPであり、クラッシュを引き起こしています。 ベータ段階でこのような大きな変更をマージすることに自信がないので、3.2.xリリースで後で行われる可能性があります。

@vnenコンパイルしてテストできる、このバグを修正したブランチはありますか？

この時点でより多くの情報が役立つかどうかはわかりませんが、回避策（私にとってはうまくいきました）は、問題のあるクラスのclass_nameを変更してから、元に戻すことです。 これにより、キャッシュに関連しているように見えます。

変数のキャスト先のクラスのメソッドのシグネチャを変更した直後、実際のメソッドを修正する前に、 asを使用してクラスメンバーをキャストしていた行で発生しました。 その後、メソッドを修正した後、行はこのエラーを出し続け、キャストクラスの名前を最終的に別の名前に変更してから元に戻したときにのみ停止しました。

@vnenコンパイルしてテストできる、このバグを修正したブランチはありますか？

はい、パブリックフォークにあります： https ：

この時点でより多くの情報が役立つかどうかはわかりませんが、回避策（私にとってはうまくいきました）は、問題のあるクラスのclass_nameを変更してから、元に戻すことです。 これにより、キャッシュに関連しているように見えます。

編集中にすべてが常に再ロードされるため、エディターでキャッシュアーティファクトが発生する可能性があります。 ただし、この問題が発生した場合は、エディターでエラーを発生させなくても、実行時に機能しない可能性があります。

https://github.com/godotengine/godot/issues/38265は、複製の詳細を含むこれの重複レポートのようです。

この修正はいつメインラインに登場しますか？
タイプ保存スクリプトを使用していて、この問題が頻繁に発生するため、非常に煩わしいです。
今日、私は解決できない状況に遭遇します。

extends Resource
class_name WfcSlotHistory

func _init(slot:WfcSlot):
    pass

extends Resource
class_name WfcSlot

function saveHistory():
   var history:WfcSlotHistory = WfcSlotHistory.new(self)
   ...

res：//assets/wfc/WfcSlotHistory.gd ：5-解析エラー：クラス「WfcSlot」を完全にロードできませんでした（スクリプトエラーまたは循環依存）。
modules / gdscript / gdscript。 cpp：576-メソッドが失敗しました。 戻り値：ERR_PARSE_ERROR

@MikeSchulzeこの場合、それは部分的に設計上の問題であるように感じます。 WfcSlotはおそらくWfcSlotHistoryについて知らないはずです。 saveアクションはおそらく後者にあるはずです。

（ただし、この動作/バグは煩わしいものですが、誤解しないでください。）

@ Jeto143ご回答ありがとうございます。すべてのスロットメンバーを手動でSlotHistoryにコピーすることで、問題を解決しました。
うまくいけば、このバグは解決されるでしょう

こんにちは開発者は、この長い...長いバグが最終的に解決されるときですか？

最初はクラスに複数のコンストラクターが必要ですが、これは許可されていませんが、なぜですか？
次に、静的関数を使用してこの問題を解決してみますが、これも機能しません。

私はこのようなクラスを持っています（簡単な例）
「」
リソースを拡張します
class_name ClassA

_init（valueA：int、valueB：int）：
prints（valueA、valueB）

static func of（value：int）-> ClassA：
ClassA.new（value、value）を返します
「」

「」
var o：ClassA = ClassA.new（1,2）＃正常に動作しています

var o2：ClassA = ClassA.of（2）＃エラーが発生します

「」

静的関数を使用すると、このエラーが発生します。
「パーサーエラー：クラスファイルで独自の名前を使用することは許可されていません（循環参照を作成します）」

したがって、これにより、現代語の標準的な動作である複数のコンストラクターを使用するクラスを作成することができなくなります。

私はこのような現在のハッキーな回避策を使用しています
`` `
static func of（value：int）-> ClassA：
var clazz = load（ "res：//../../ ClassA.gd"）
clazz.new（value、value）を返します
「」

宜しくお願いします
マイク

こんにちは開発者は、この長い...長いバグが最終的に解決されるときですか？

GDScriptの書き直しの一環として4.0で解決される予定です。

これは修正されたときに静的関数でも機能しますか？

class_name Cls

static func f():
    print(Cls)

@vnenなので、3.2.Xリリースを使用していますが、すぐに修正されると思いますか？

@ Ploppy3これらの修正は、GDScriptの書き換えに伴う大規模な変更によるものであり、それらを選択することはおそらく不可能です。 これらの修正が必要な場合は、4.0にアップグレードする必要があります。

私もこの問題を抱えています。ここに私の2つのスクリプトがあります。

class_name Entity extends Area2D

export var resource : Resource

onready var sprite   = get_node("sprite")
onready var collider = get_node("collider")

func _process(delta: float) -> void:
    if sprite   == null: sprite   = get_node("sprite")
    if collider == null: collider = get_node("collider")
    if resource is EntityConfig:
        sprite.frame = wrapf(sprite.frame+resource.gfx_speed, resource.gfx_start, resource.gfx_start+resource.gfx_count)

class_name EntityConfig extends Resource

export var gfx_image   := ""
export var gfx_start   := 0
export var gfx_speed   := 1.0
export var gfx_count   := 0
export var gfx_xoffset := 0.0
export var gfx_yoffset := 0.0
export var gfx_xsize   := 16.0
export var gfx_ysize   := 16.0
export var hit_xoffset := 0.0
export var hit_yoffset := 0.0
export var hit_xsize   := 16.0
export var hit_ysize   := 16.0

func new()->Area2D:
    var entity = Entity.new()
    entity.sprite            = Content.load_texture(gfx_image)
    if entity.sprite != null:
        entity.sprite.frame      = gfx_start
        entity.sprite.position.x = gfx_xoffset
        entity.sprite.position.y = gfx_yoffset
        entity.sprite.hframes    = entity.sprite.texture.get_width () / gfx_xsize
        entity.sprite.vframes    = entity.sprite.texture.get_height() / gfx_ysize

    entity.collider.position.x      = hit_xoffset
    entity.collider.position.y      = hit_yoffset
    entity.collider.shape.extents.x = hit_xsize / 2
    entity.collider.shape.extents.y = hit_ysize / 2
    return entity

Godot 3.2.3でキャップストーングループプロジェクトに取り組んでいるときに、この問題を発見しました。 衝突コールバックの場合、次のようなものがあります。

extends Area2D

func _on_Throwable_body_entered(body: Node) -> void:
    if body is Player:
        if body.pick_up():
            queue_free()

したがって、Player固有のメソッドを呼び出す前に、 if body is Playerを確認する必要があります。 問題は、 Player class_nameまたはpreload -edのどちらで宣言されていても、グローバルスコープであっても、 Playerが使用できる場合とできない場合があることです。 これは、 Playerがスクリプトをプリロードしていない場合でも発生し、明らかな循環依存を引き起こします。

現在、 PlayerがArea2Dの衝突マスク内の唯一のものであることを確認し、コード内で何もチェックしないことで、これを回避しています。 最初はif body.name == "player"をチェックしていました。

時間がかかっても作業が進んでいることを知り、嬉しく思います。

静的メソッドを使用してBuilderパターンを実装できなかったときに、同様の依存関係の問題が発生しました。

class_name MyClass

static func build() -> MyClass:
  var new_instance  = MyClass.new()
  ...
  return new_instance

ここで説明

私はこのトリックを使用して、静的メソッド（get_script（）が使用できない）でも現在のソースファイルパスを取得します。

static func build() :
    var new_instance = load(GodotExt.current_script_path()).new()
    ...
    return new_instance

と

class_name GodotExt

static func current_script_path():
    return get_stack()[1].source    <- return usable script path

現在のクラスを取得するためのこのトリックは、どこからでも機能するようです。
これは未加工であり、グローバルな依存関係の修正を待つ同様の循環依存関係の問題を回避するために使用できます。

こんにちは@AliBouarab素敵なトリック