私はGodotを1年以上プロとして使用しています。

以下を除いて、あなたが言ったことすべてに同意します。

一部の人にとっては、現在の方法を維持する必要があると思います

この絶好の機会があれば、すべての名前を変更しましょう。 これには、Sprite2DとMeshInstance3Dが含まれます。

多くの部分的な痛みを伴うリファクタリングよりも、完全な痛みを伴うリファクタリングの方が常に優れています。

名前の変更と言えば： https ：

@ jahd2602個人的にはどちらの方法でも

それが矛盾しているという事実だけでそれを気にしている人々を確かに見ることができますが、少なくとも彼らが多数派であるか少数派であるかはわかります。

@Zylannここで何かを決めたら、これをあそこに移動します。

名前空間に対するスタンスは近視眼的だと思います。 一般にエンジンワークフローの観点からは理にかなっていますが、ツールメーカーの観点からは無視されます。 たとえば、bitwesによるGodotユニットテスト（GUT）は、更新の1つで名前の競合が原因で壊れました。 専用のGUT名前空間を使用すれば、これを回避できた可能性があります。

また、Waiting And Testing（WAT）の名前空間が欲しいので、他のフレームワーク（GUT.Testを使用する場合はGUTなど）を実行せずに、Test（WAT.Test経由でアクセス）などのクラス名を使用できます。ユーザーのスクリプト。 サブクラスとして使用されるすべてのスクリプトを含むWATクラスを使用して何度も試しましたが、これは循環参照の地獄にすぎません。

エンジン内からツールを作成するように促される場合は、エンジンワークフロー自体に絶対に必要でなくても、エンジン内でそれらのツールを作成するためのツールが必要です。

要約すると、エンジン（または少なくともプラグインスクリプト）からアクセスおよび定義できる専用の名前空間システムであるため、ツールメーカーがお互いに歩き回ったり、その使用が天の恵みになることはありません。

@CodeDarigan私はそれが利点を持っていることを理解しており、それらを否定しているわけではありませんが、コストがそれらを上回っていると心から信じています。

これに加えて、現在のアプローチを好むGDScriptユーザーからの重大な不満はほとんどなかったので、不要なワーフクロウを強制し、すばやく汚いものをすばやく書くことを目的とした言語でより多くのコードを入力します。 （ただし、C＃ユーザーはそれらを望んでいるようです）。

これが、スクリプト言語バインディングのメタデータとして存在できることを意味し、GDNative C ++用に追加することもできます。 コアC ++エンジン用にそれらを追加しないでください。

ナビゲーション-> Nagivagion3D
これはタイプミスですか？

@nitodico確かに

@reduz @

私はまだGodotを使い始めており、提案された変更は私には理にかなっているように聞こえます-ノードの2Dまたは3Dバリアントに微妙に異なる名前を使用することは、どちらが上であるかを学び、Thing2Dに移行するときに少し混乱を引き起こしました/ Thing3DまたはThing / Thing3Dは、明快さとわかりやすさの大幅な改善のように感じます。

して下さい。

とにかくこの変更が行われるので、今すぐ実行して、それを維持することをお勧めします。 3Dの場合、タットはそれほど多くないので、変更によるダメージは1、2年後よりも少なくなります。

マテリアルに関しては、拡散反射や鏡面反射など、最小限のリソースのみを使用するある種のレガシーマテリアルがあると便利です。これは、3Dモバイルゲームに役立ちます。

また、名前を明示的に3Dまたは2Dに変更することにも賛成です。

元の名前を新しい名前のエイリアスとして引き続き存在させることはできませんか？ それらはエディターから非表示になるため、古い名前は使用できなくなります（または「非推奨」の見出しの下に配置されます）。 そうすれば、古いコードは変更なしで、また何かを変換するための追加のロジックを必要とせずに、引き続き機能します。

非推奨のノード名を使用するコードに警告を追加し、4.1または4.2でそれらを削除することができます。

ノードに2つのバージョンがある場合、常に2D / 3Dサフィックスを追加します。

また、Label-> TextLabelがあれば嬉しいです。 テキストを表示できるようにノードを追加するので、検索バーにテキストを入力すると、もちろん、RichTextLabelのみが表示されます。これは、標準のテキストノードの名前に実際にはテキストが含まれていないことを思い出させます。

@ Janders1800は現在の動作方法であり、SpatialMaterialで使用する機能が少ないほど、作成されるシェーダーは小さくなります。

私は2Dの人なので、主に2Dアプリケーションを使用するノードの場合、ノード名にサフィックスが付いていない場合は、サフィックスなしで保持するのが適切だと思います。 これは3Dユーザーにとってはより苦痛なリファクタリングのように見えますが、特定のノードがほとんどの場合2Dまたは3Dアプリケーションしかない場合、目的のドメインの短い名前を保持し、他の場所に接尾辞を付けることは非常に理にかなっています。 統合できる他のすべてのもの、具体的にはSpatial統合されているのを見るとよいでしょう。

私も無条件に2D / 3Dサフィックスを使用することに賛成です。

一部のノードでは、より「自然な」名前を持つ機会が失われたように見えることは事実ですが、一貫性が優先されます。

私があまり好きではないのは、 StandardMaterial3Dが非ORMのものであるということです。 私のポイントは、ORMは標準（少なくともRM、つまりglTFにあるもの）によってより強力にサポートされているということです。

しかし、私はまだより良い命名を提案することはできません。

たぶん、これは「キャンバス」について何かをする機会でもあります。 私はその概念が時々少し混乱することに気づきました。

3Dに対応するものがないため、難しいことはわかっています。3DシーンはSpatialノードに存在しますが、キャンバスにはNode2DとControl混在させることができます。

ただし、「純粋な」2DおよびGUIレルムにとって意味のあるものを維持しながら、 CanvasItemMaterial名前をMaterial2Dに変更できる名前を定義できれば素晴らしいと思います。

私は必ずしも名前の変更に反対しているわけではありませんが、おそらく私の経歴のために、元の名前は私には意味があります。
物理学または工学のデフォルトは「3D」です。 他の空間で作業している場合を除いて、「3Dキネマティックボディ」とは言わず、「キネマティックボディ」と言います。
ただし、これは結局のところゲームエンジンであり、物理学や工学の慣習に厳密に従う必要がないため、全員が同じ背景を持っているわけではなく、それに同意しているわけでもありません。

将来の互換性のために、gdscriptで

gdscriptファイル..

Spatialを拡張します
class_name Node3D

等々。

あなたは、名前の変更について考えているtranslationする空間ノードのためにposition ？

@BeayemX翻訳は3D空間の一般的な用語であり、位置は2D開発者の一般的な用語だと思います：thinking：

4.0がノード名の変更に最適かどうかはわかりません。対処することがたくさんあり、2から3に多くの変更がありました。これは、本、ビデオ、コースの廃止を意味します。
ドキュメントが完全ではなく、途中で変更が加えられると、修正によって処理速度が大幅に低下します...

ここで提案されているように、3Dノードの名前を変更することに賛成です。 チュートリアルメーカーにとってどれほどの問題になるかはわかりませんが。 少なくとも、既存のコードベースをリファクタリングするのは簡単なことです。 C＃では、デバッグモードでObsoleteAttributeを悪用して、簡単にすることもできます（ただし、良いアイデアかどうかはわかりません）。
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

＃18711で説明したように、名前空間/カテゴリを追加したいと思います。 C＃APIを名前空間とおそらくアセンブリに分離して、ユーザーが必要なものだけを選択できるようにしたいと思います。
4.0の私の計画は、他に選択肢がない場合は名前空間のテーブルを自分でハードコーディングすることでしたが、代わりにClassDBからこの情報を取得できる方がよいと思います。

@私はそれは...しながら、考えていないEON-S translation座標を表現することは技術的に有効である、ゴドーは、そうでない場合は、私がいつも見てきた私は、ここで使用されている別の用語を参照してください最初のエンジンであり、 position 2Dまたは3Dに関係なく、 translationは動きに関連しており、言語/変換に関連する別の用語と競合しているため、奇妙です。 これはhttps://github.com/godotengine/godot/issues/16863でも言及されてい

ところで、なぜ私たちはできるだけ壊れないように計画しているのですか？ 私は、人々が互換性の破損をこれ以上望まない理由、特にチュートリアルを作成している人々を理解しています。 しかし、互換性を破る機会として4.0を採用しないのであれば、いつに移行するのでしょうか。 ＃16863はすでにたくさんの提案を集めています。

@neikeqは5.0を待つことができませんか？ 新しい機能や大きな機能は計画されていないため、そうしないと、1〜2年ごとに重要な部品を変更するエンジンの作成やコースの購入が停止され（ビデオチュートリアルメーカーの場合、これはすべての作業をやり直すことを意味します）、数か月の警告時間が必要になります..。。

一貫性のある2D / 3Dサフィックスを持つように名前を変更することに賛成です。一貫性を保つために、このスレッドの多くの人がすべてのノードに対して実行する必要があることに同意します。 一貫した命名規則を持つことは、エンジンを学ぶ人、物事の2D側から3Dに、またはその逆に移動する人にとって非常に役立ちます。

@ eon-s確かに5.0まで待つということは、更新が必要なさらに多くの作業があることを意味しますか？

チュートリアルがあるのは素晴らしいことですが、既存のチュートリアルのためにエンジンを混乱させ続けるよりも、エンジンをより理解しやすくすることに投票したいと思います。 うまくいけば、fixitスクリプトまたはオプションのエイリアス（上記でさまざまに説明したように）を使用して、アップグレードパスをスムーズにすることができます。

ノードノードにはスペースに関する知識がなく、ノード、ノード2D、ノード3Dがあると混乱するため、ノードと空間の名前の違いに感謝します。 Nodeを削除する予定がない限り、それは完全に理にかなっています。

2Dまたは3Dのレルムを1つだけ持つため、接尾辞を付ける必要があります。 現時点では2Dであり、2Dと3Dの混乱はそこで終わります。

3Dサフィックスを追加しないでください。 それが追加するものについて頭痛の種になることは本当に価値がありますか？ それはコストの価値がありますか？ すべてを更新したり、古いチュートリアルを持ったりしますか？ 変更不可能で時代遅れのYouTubeチュートリアル？ それはより多くの混乱をもたらすでしょう。

@dpalacio Godotを使用しているのはほんの数か月ですが、SpatialはNode3Dとして機能し、Nodeにはスペース情報がないため、Node3D、Node2D、およびNodeを使用する方が明確で簡潔だと思います。 3Dの接尾辞の追加は、「反対」という名前になるため、はるかに理解しやすいと思います。 私はそれが本当に反対ではないことを知っていますが、英語は私の母国語ではないので、それをよりよく表現する方法がわかりません。 3Dと2Dを比較すると、私には明らかに素晴らしいと思います。 初心者にとっては非常に簡単で、ゲームエンジンに初めて触れた人にとってはなおさらだと思います。 名前空間も、主に大きなプロジェクトやプラグインに最適です。 矛盾する名前は頭痛の種です。 初心者としては、バージョン間でプロジェクトを変更し続けることが難しいため、互換性の破損を最小限に抑えて自動的に行う必要があると思います。 多くの変更がある場合は、自動変換ツールとそのドキュメントも必要になります。

@neikeqええ、カテゴリは名前空間に置き換えて、適切なものを作成する必要があります。

Godotを試したときに思っていた通りです。 私のOCDはそれがこのようであるべきだと私に言います。

あなたは、名前の変更について考えているtranslationする空間ノードのためにposition ？

「位置」は、相対位置ではなく絶対位置のように聞こえます。
それをポジションと呼ぶことは、新しい開発者を助けるかもしれませんが、最終的に彼らはそれが翻訳と呼ばれるべきであることに気付くでしょう。

私は、Godotチュートリアルを作成し、自分のフル機能のプロジェクトにGodotを使用している人として、この提案に少しばかり気を配っています。

私は、一貫性を保つためにノードの名前を変更することに全面的に賛成です。一貫性が重要であることに同意します。 コードベースとドキュメントの一貫性を高めるには、ノードの末尾/先頭に3Dまたは2Dを追加する必要があります。

一貫性を保つために変更してほしいノードを次に示します。

• MeshInstance -> MeshInstance3D （ MeshInstance2Dとの一貫性を保つため）
• GridMap -> TileMap3DまたはGridMap3D
• TileMap -> TileMap2DまたはGridMap2D
• YSort -> YSort2Dまたは2DSort （または2D用であることを示すもの）
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D （または3D用であることを示すもの）
• ReflectionProbe -> ReflectionProbe3D （または3D用であることを示すもの）
• SpatialMaterial -> PBRMaterialまたはGodot3DMaterialまたはStandardMaterial3D （単なるアイデア）
• Label -> TextLabel （@ MuffinManKenに同意します）

この提案についての私の考えは、ポジティブなものから始まります。

この変更により、Godotの経験がない人にとっては物事が簡単になると思いますが、これらの変更が行われた

多くの場合、私はGodotで他の人を助けていますが、解決策を見つけるための最も確実な方法の1つは、ドキュメントを調べることです。 ただし、ノードの名前は常に一貫しているとは限らないため、探しているノードの名前をすでに知っていない限り、特定のノードではドキュメントページを見つけるのが難しい場合があります。 この提案の変更により、正しいノードを見つけるのがはるかに簡単になります。

この変更で私が見ることができるもう1つの利点は、ノードの命名方法に関する標準を設定することです。これは、プラグインの作成者や将来のGodotEngineの貢献に役立つ可能性があります。 私は、（例えば）デカールノードを作っていた場合、この変更に私はそれを何か名前を付ける必要があります知っているDecal3Dの代わりに、ちょうどDecal 。
これは、GDScript / C＃で定義されたクラスの命名にも役立つ場合があります。

これにより、 Spatialが基本的に3DのNode2Dであることを説明する必要がなくなるため、将来のチュートリアルの作成も少し簡単になります。

ネガティブについて：

この提案で私が抱えている最大の問題の1つは、特にGodot 3.0+がそれほど前に物事を変更したことを考えると、早すぎるように思われることです。 Godot 3.0+を使用したゲームはほんのわずかしか出てこなかったと思いますし、3DGodotゲームもほとんどありません。
Godotショーケースの大きくて印象的な3Dゲームの多くはまだリリースされていません。このように大きな変更を加えると、これらのプロジェクトも更新する必要があり、非常に強力な3DGodotゲームがさらに遅れます。

また、Godot3.0以降のチュートリアルもまだ出ています。 特に3D側では、物事はやや勢いを増し始めています。 これは、Godot 3.0以降でGodotの3D側が強化されたことも一因ですが、チュートリアルライターが作成している（または作業中の）多くの資料が、名前の変更を説明するために突然大規模な言い換えが必要になるのではないかと心配しています。 古いチュートリアルは削除、作り直し、または書き直す必要があるため、これは新しいチュートリアルの作成に時間がかかります。

名前の変更により、チュートリアルではなく、問題に対する単純な解決策である既存のリソースが突然古くなります。 Godotの2D側は間違いなく非常に強力で、おそらく迅速に適応できますが、3D側を使用するコミュニティは著しく小さくなっています。 ノードの名前を変更することで、Godotの3Dユーザーの成長と3D関連の問題の解決策を見つける能力が妨げられるのではないかと心配しています。

@ eon-sに同意します：これらの変更は少し待つことができませんか？ Godot 4.0では、少なくともコードベースでは、状況はすでにかなり劇的に変化しています。 別の大規模な変更を追加すると、開発が難しくなり、Godotの3D側で人々が行っている多くの進歩がリセットされるだけだと思います。

Godot 4.0がリリースされたら、バージョン4.1または5.0でノードの名前を変更する作業は素晴らしいと思いますが、私の意見では、このような別の大きな変更を追加すると、助けよりも害が大きくなると思います。

この移行を改善する可能性のあることの1つは、エイリアス/移行期間を設けることです。たとえば、Godot4.0からGodot4.1への移行などです。 これにより、チュートリアルやリソース（特に3Dのもの）がすぐに時代遅れになることはなく、Godot 4.0の変更の恩恵を受けながら、今後の変更に適応する機会が全員に与えられます。

エイリアス/移行期間を使用すると、突然全員が一度に更新することを強制することなく、互換性を破る変更を加えることができます。 これにより、互換性を破る変更をより頻繁に行うこともできます。理論的には、システムが移行のために配置されると、将来の互換性を破る変更に再び使用できるためです。 これにより、＃16863にリストされている変更により、今後の作業が容易になります。

TLDR：私はすべて変更に賛成です。変更に順応する時間を全員に与えるために、Godot4.1または移行システム/期間が作成されるまで待つ必要があると思います。

この提案がどのように終わるかに関係なく、Godot 4.0は素晴らしいものになると思いますし、楽しみにしています🙂

@reduz私はそれのために行くと言います。 そして私は2番目に@ jahd2602

私はすべての3Dノードを「3D」で終わらせるのが好きではありませんが、誰もが望むなら確かに。 常に接尾辞を付けるのではなく、異なる名前を保持することは問題ないと思います（例：TileMapとGridMap）

私は「翻訳」よりも「位置」を大いに好みます。 後者はローカリゼーションと言語と混同される可能性があり、前者はすぐに明確で初心者に優しいです。 しかし、Godotはこれのためにほとんどの場所ですでに「origin」を使用していませんか？

また、 @ neikeqが新しいプロジェクトへの有益な変更である場合、互換性を壊す価値があることにも同意します。 個人的には、＃16863の大部分が実装されているのを見てみたいと思います。

（ところで、Sprite3Dがクアッドメッシュである可能性があるのに、なぜ存在するのですか？）

@TwistedTwigleg私の投稿を読んでください。内部互換性システムが追加された場合、3.0プロジェクトは4.0で正常に開きます。

素晴らしい変更です。プログラマーとして、相手の名前が可能な限り対称になっているのを見てうれしいです。

ORMスタイルのテクスチャの意味を詳しく説明していただけますか？

@reduzは、標準の空間マテリアルとORMの唯一の違いです。つまり、ORMにはテクスチャチャネルが1つしかありません（現在の3つではありません）。 鏡面反射光や乗数などの同じパラメータ（金属と粗さ）に引き続きアクセスできますか？ 頻繁には使用されませんが、微調整に使用されることもあります。

私はそのアイデアが好きですが、このような小さな変更で2つのマテリアルタイプを使用するのはやり過ぎではないかと思います。 代わりに、単一のマテリアルを使用して、ORMモードの1つのテクスチャチャネルまたは既存のスタイルの3つのテクスチャチャネルを切り替えるトグルがありますか？

また、最近、深度（高さ）チャネルをORMマップのアルファチャネルに配置して、テクスチャからより多くのマイレージを取得しています。 次に、3つのテクスチャ... albedo / normal / ORM（H）を使用してほとんどのテクスチャを実行できます。 これはデフォルトで追加する価値があります（別の高さマップを使用したい高さマップ用の16ビットオプションがない限り）。 4.0が最終的にテッセレーション/変位を取得した場合、高さチャネルは現在よりもはるかに重要になります。

そして、それについて言えば、4.0でDEPTHチャネルの名前をHEIGHTに変更し、現在使用しているものの逆を使用することも良い機会です（つまり、白は隆起した表面で、黒は凹んでいます）。 これにより、他のレンダラーやゲームエンジン、さらに重要なことに、Substance、Quixel、Marmosetなどのツールと歩調を合わせることができます。

2Dノードと3Dノードには明示的なサフィックスを使用し、該当しない場合はサフィックスを使用しない方がよいでしょう。 また、「Control」ノードを「Node2D」ノード用に完全に分離したいと思います（これらは両方とも現在「CanvasItem」の下にグループ化されています）。

translation対positionについては、2Dと3Dの両方で前者を選びます。

positionはより親しみやすいように見えますが、祖先がある程度の回転またはスケールを持っていると、意味がなくなります。

互換性に関しては、チュートリアル、ユーザー、およびプロジェクトに十分な時間を与えるために、移行段階はすべての4.xリリースで継続する必要があります。 新しい名前は一級市民であり、奨励されるべきですが、古い名前は、変更について人々に伝えるための編集中のメカニズムを使用して機能する必要があります。

エンドユーザーが前述のようなツールを使用して既存のコード（独自のコードまたは既存のチュートリアルやドキュメントのコード）を簡単に更新できるように行われている限り、提案された変更に絶対に賛成です。 そのようなツールがないので、v2からv3への大きな移行の直後に積み上げていることに同意する傾向があります。

@TwistedTwiglegは、3Dゲームのリリースに関して、4.0とVulcanを待っているためです😎

Controlノード名...とインラインドキュメントも確認します。

AcceptDialogとConfirmationDialogの違いは何だろうと思うことがありますが、 PopupPanel 、 PopupDialog 、 PopupMenuでも同じです...これを願っています助けます！

家庭教師およびドキュメントの寄稿者として、私は先に進んでください！ 将来、誰もがエンジンを学び、理解しやすくなるように変更すれば、もっと多くのコンテンツを作成してもかまいません。 この種の変更もできるだけ早く行う方がよいでしょう。

パーティーに遅れて来るが、物事を管理しやすくするためのいくつかの説明：

• ノードの名前を変更する提案と、互換性を維持する方法に関する技術的な影響、既存のプロジェクト、チュートリアル、コンテンツメーカーなどへの影響についてのみコメントしてください。
• これは、名前の変更を検討する必要があるAPIの特定のポイントについて説明する場所ではありません。 この大規模な名前変更を採用することにした場合は、スプレッドシートでAPI全体を確認して、名前が一貫していることを確認します。 ここで説明されている以上に名前を変更する必要があるメソッド、プロパティ、クラスなどの特定のものについては、＃16863を参照してください。
• @RandomShaper @fracteed @fire @reduz専用の問題に標準物質についての議論を移動してください。

こんにちは、
他のAPIの慣例に従い、クラス（またはメソッド）の廃止/非推奨のデコレータを作成してみませんか。つまり、古い名前は単に新しい名前のエイリアス/ポインタです。 これにより、重大な変更が停止され、バージョン5で名前を削除できるため、影響を受ける人や気付く人が少なくなります。

デコレータを使用すると、他に2つの利点があります。

1. IDEはこのタグを簡単に取得して、ノード選択ウィンドウに表示できます。たとえば、単に「空間」と言う代わりに、「空間（以前はNode3Dを使用）」と読み取ることができます。

2. デコレータは、コードエディタに表示される組み込みの警告になる可能性があります。

さらに、名前変更ツールの作成を止めることはできません...

いくつかの考え：

一貫性を向上させ、APIの学習と使用を容易にするために、ノードの名前を変更することに同意します。また、いくつかのメソッドとプロパティ（＃16863の現在のリストを参照）にも同意します。 2D / 3Dの区別を明確にすることは良い考えのように思われ、実行する場合は一貫して実行する必要があります（たとえば、前述のMeshInstance3Dも）。 スプレッドシートを使用して、現在のすべてのノードと4.0での新しい名前を一覧表示することをお勧めします。そこで、TileMap / GridMapなどの特定のノードについてバイクシェッドすることができます。 これが私たちの望む方法であることが確認できれば、数日中にこのスプレッドシートを作成します。

それでも、互換性の破損を可能な限り制限するように努める必要があります。 Juanが述べたように、古いシーンをロードして変換できるように、エンジン内部で互換性の名前を変更することができますが、それだけでは十分ではありません。

@RandomShaperと@chucklepieが述べたように、名前を変更するすべてのノード、メソッド、プロパティ、定数、シグナルなどに非推奨のエイリアスを追加し、プロパティデコレータ/メタデータを追加して、それらを廃止として通知し、ユーザーに変更を促す必要があります彼らのコード。 IDEでこの情報を使用すると、ユーザーは4.0の3.xチュートリアルを問題なく実行できるようになり、新しい名前について簡単に学ぶことができます。

そのためには、バインディングを登録するときに非推奨のエイリアスを定義できるヘルパーメソッドが必要です。 ＃23023は、このようなインターフェイスを追加する最初の試みですが、4.0で必要なものに対して十分でない場合は、レビュー、マージ、および拡張する必要があります。 これらの非推奨のエイリアスは、4.xリリースサイクル全体にわたって保持され、5.0で削除されます。
このインターフェイスが適切に設計およびマージされるまで、互換性を壊すような名前の変更には反対します。したがって、これに関心のある人は、このPRを試して、必要に応じて変更を提案してください。

いつについては

Godotのユーザーベースは毎年ほぼ2倍になるため、毎年通過するとリファクタリングの現実性が低下します。最終的には、大規模なユーザーベースの慣性が互換性を損なうことによるメリットを上回ります。 UnityやUnrealのような他のエンジンがGodotと比較してAPIの点で比較的安定しているように見える場合、それはリファクタリングまたは名前変更したいものがないためではなく、余裕がないためです。 今のところまだできるので、機会を利用する必要があります。 これはGodot3.0でも同じで、コミュニティは比較的無傷で出てきましたが、3.0に移植する余裕がないため、2.1に固執するユーザーの割合はわずかです。 4.0の場合、これらの変更の範囲は大幅に少なくなり、移植作業は簡単になるはずですが、その間にコミュニティは多様化するため、互換性のある破損の影響は3.0の場合と同じかそれ以上になります。画像の条件/累積されたユーザーの煩わしさ:)

私は互換性を壊すことを大いに支持しています。
それが問題にならない理由：開発者が古いバージョンでゲームを公開し、その後、古いバージョンのエンジンで開発を続ける場合、誰も開発者に新しいバージョンへの移行を強制しません。 また、まさにこの目的のために、ダウンロード用の古いバージョンを提供し続けてください。
新しいプロジェクトは新しいバージョンのエンジンで開始でき、開発者がエンジンの動作方法を再学習する忍耐力があるかどうかにかかっています。
エンジンの使いやすさを向上させることになると、目標が最もユーザーフレンドリーまたは強力なエンジンになることである場合、再学習の忍耐力が問題になることはありません。

名前の変更については、学習する資料にパターンがある場合、学習曲線を減らすのに役立ちます。 たとえば、他のすべてのノードのNode2DとNode3Dなどです。 それがアヒルのように見える場合、あなたはそれがどうなるか知っています、それはおそらくアヒル、またはこの例ではノードです。
人間の脳は最適化された量子コンピューターとして機能し、システムの最低エネルギー状態を相互に接続して学習し、アイデア間の論理パスを作成します。 学習するアイデアが類似している場合、それらの最低エネルギー状態は互いにより近くなり、それらを接続（および記憶）しやすくなります。これは、事前に2Dを教えられていれば、学生が3Dを理解しやすい理由を説明しています。 。 ノードの名前がそれらの間の類似性を反映している場合、知識が類似のタイプに存在する場合、新しいタイプがどのように使用されるべきかを学び、理解することも容易です。

私は先に進んで、あなたが望む方法で互換性をリファクタリングして壊すと言います。 失ったユーザーが少ない場合でも、使いやすさが向上し、学習曲線が減少することで、さらに多くのユーザーを獲得できます。

これに関連して、Blender2.80を例にとってみましょう。 現在の外観と動作を以前と比較します。 これは大きな変更であり、多くの開発者がソフトウェアの動作を再学習する必要があります。 ここで、Blenderのユーザー数を考えてみましょう。 Godotと比較すると、巨大ですが、とにかくソフトウェアを大幅に変更しました。 どうして？ 長期的には、新しいワークフローに移行する忍耐力がない一部のユーザーを失うことを意味する場合でも、学習曲線を減らして使いやすさを向上させる方が常に有益であるためです。

結局のところ、私はこの場合の重大な変更には賛成しません。

有機的に成長した命名規則に感じられる欲求不満は理解できますが、広範囲にわたる破壊的な変更を正当化するものは見当たりません。

移行したいAPIを非推奨にする（そしてコンパイル時とドキュメントでAPIにフラグを付ける）ことに全力を注いでいますが、理想的には古いノード名は以前と同じように機能し続けます。

おそらく、数年後には、従来のノード名が完全に無痛になったため、廃止する時期かどうかを尋ねることができます。 それまでは、必要に応じて新しい名前を追加し（私はそれについて強い意見はありません）、下位互換性を壊さないようにすることをお勧めします。

@fracteed視差マッピングはそのテクスチャに対して多くのタップを行い、毎回不必要にRGBを取得する必要があるため、実際には別のテクスチャのチャネルに奥行きを持たせることはおそらく良い考えではありません。 単一のグレースケールテクスチャを使用する場合、Godotはそれを半分のサイズに圧縮し、帯域幅を節約します。

標準のマテリアルにORMモードを設定することも良い考えかもしれませんが、それを確認する必要があります。

@chucklepie問題は、すべての言語がtypedefのようなクラスエイリアスをサポートしているわけではないということです。 C＃はその1つです。

@reduzああ、私はそれを知らなかった、知っておくと良い。 より重要な問題は、深度チャネルを4.0の高さに切り替えることです。したがって、それを変更することを検討してください。

編集。 申し訳ありませんが、アキエン、これを投稿した後にあなたのコメントを見ただけです...

@neikeq問題は、すべての言語がtypedefのようなクラスエイリアスをサポートしているわけではないということです。 C＃はその1つです。

ネイティブC ++ライブラリがどのように実装されているかはわかりませんが、アップストリームの言語バインディングが何であるかが問題にならないように、ネイティブC ++レベルでこの装飾を行うメカニズムについて詳しく説明しています。 それが不可能な場合は、各言語のバインディングをスイートに簡単に適合させることができます（たとえば、C＃の属性を使用するなど）。

@ gerald1248私の投稿を読んでください。壊れるとは言っていませんが、3.xで作成されたプロジェクトは、ロード時とスクリプト時にエイリアスを使用して引き続き機能します。 それらを使用すると、非推奨の警告がトリガーされますが、プロジェクトは引き続き機能します。

私はの大ファンです

ナビゲーション-> Nagivagion3D

名前を変更します。 私はこのリクエストを2番目にしています！

@reduzは言った：
@TwistedTwigleg私の投稿を読んでください。内部互換性システムが追加された場合、3.0プロジェクトは4.0で正常に開きます。

私の悪い、私は投稿のその部分を逃しました。

内部互換性システムは移行に役立ち、特に＃23023のようなものと組み合わせると、間違いなく私をフェンスの「変更を加える」側に置くことができます。 この変更の前にプロジェクトで何かが計画されていることを知っておくと、この提案について私が抱いていた多くの懸念を聞くことができ、緩和されます。

@Norroxは言った：
@TwistedTwiglegは、3Dゲームのリリースに関して、4.0とVulcanを待っているためです😎

それは公平です。
特に、Godot 4.0でのGodotの3D側の改善を考えると、待機は3Dの重いプロジェクトにとって悪いことではないかもしれません。

3Dと2Dの区別は、すでに一貫性が明確です。 3Dノードは明るい赤、2Dノードは青、UIノードは緑です。 ネーミングに問題があるユーザーは常に存在します。 これは終わりのない問題であり、コミュニティの規模に基づく乗法的問題です。

OPで提案された変更に関して：2dノードにはすでに「2D」サフィックスが適用されています。これは、_本質的に、対応するものが3dであることを意味します_。

ただし、 LabelからTextLabelような変更には賛成です。 （ @MuffinManKenは素晴らしいポイントになります）

私はここで基本的にすべてを完全にサポートしていますが、「Sprite2D / Sprite3D」の質問に関しては、2Dサフィックスが余分な量のIMOを追加する以外の理由がない場合は、SpriteをSpriteのままにしておくことをお勧めします。

@girngが言うように、我々は避けるの混乱に偉大な長さに行く必要はありませんので、2D / 3Dの分化は、すでにカラーコーディングによるかなり明確です。 Godot開発者の観点からは、プロジェクト内の名前が変更されていない

その色分けは、さまざまな形の色覚異常を持つ人々に役立ちますか？
（ダイアログからノードを追加するのではなく）コードを入力するときは、絶対に役に立ちません。

@reduzお返事ありがとう

しかし、繰り返しになりますが、もっと明確なものを好むかどうかを自由に提案し、すべてを常に2D / 3Dにします。

明示的は暗黙的よりも優れています。

ただし、コードを記述しているときは、エディターで異なる色の@ girng @ AlexHoratioノードは役に立ちません。 ここで混乱が生じると思います。

（Sprite3Dが存在する必要がある理由はまだわかりません。他のエンジンは、同じ目的でクアッドメッシュを使用するだけです。スプライトが排他的に2D用語であると、より簡単になります）。

@ gimg 、 @ AlexHoratio人口の4.5％が

名前を変更するのは良い考えだと思います。
2Dから3Dへの移行がはるかに簡単になります。 少なくとも2Dから始める人にとっては（そしておそらくその逆も）

問題があることは明らかであり、コミュニティはそれが良い考えだと考えています。 私はgodotに偏っていて、あまりにも感情的に執着しています。 この状態にあることは、他の人にはあまり意味がないが、私には完璧に意味のある考えを美しい方法で生み出します。 説明するのは難しい。 私の考えを表明させてくれてありがとう

一貫性を保つために名前を変更する価値があるという一般的なコンセンサスに同意します。 今のところ、ノードの1つのセットが「ファーストクラス」で、もう1つのセットが「セカンドクラス」であるという外部的な印象を与える可能性があります。あるいは、最初のノードに基づいてハッキングされて存在する可能性もあります。

個人的には、 Sprite -> Sprite2Dは、完全に厳密な明示的な名前変更の不幸な犠牲者になると思いますが、疲れるまで、作成するすべてのシーンでいつでも手動でスプライトに名前を変更できると思いますそれの。

CanvasLayerとCanvasItemがグループ化されておらず、他の人が指摘しているように、 Node2Dがコントロール付きのCanvasItemの内部にあることは不快だと思います。

@ akien-mgaがこれはノードの名前変更のためだけだと言ったことは知っていますが、少なくともpositionとtranslationについての議論がここで関係していると思います。 APIが大幅に異なる場合（座標系などの違いを除く）、ノードの名前を変更する目的はややフラットになると思います。したがって、ノードの名前は、どのようなものであっても、間違いなく同じである必要があります。 ここに行く方法として「位置」に投票したいのですが、「翻訳」と比べて誤解を招くとのコメントがありました。 「翻訳」は、単なる座標ではなく、変形や動きを意味するため、誤解を招くと思います。 位置は直感的に相対的です、imo（コンパスの方向に対して椅子をまっすぐにするのではなく、部屋の壁に対してまっすぐにします）。

変数には両方の位置という名前を付ける必要があると思いますが、 translate関数はそのままにして、 Node2D move_local関数をtranslate_localに変更します。それを翻訳と呼びます。 物理学の動きと幾何学的な平行移動を区別するために、物理学に関連するノードにはmoveを使い続けます。

この後半の多くは＃16863にも関連しています

また、 @ reduz 、C＃がエンジンで機能を取得するにつれて、ますます多くの人々がC＃の名前空間を必要とするようになると思います。また、C＃に入ると、多くのgdscriptユーザーがそれらを使用したいと考えて言語を切り替える必要がないことを想像できます。機能のために。 名前空間は最終的なC＃サポートに完全に不可欠だと思いますが、gdscriptの場合、メリットはそれほど劇的ではありませんが、ユーザーの心配なしにプラグアンドプレイパッケージが可能になります。

これが実装された場合、「単純なノード名」と呼ばれるエディター設定を持つことができます。これは、新しく作成されたノードの名前にサフィックスがないことを意味します。たとえば、新しい「Whatever2D」を作成すると、名前を「Whatever」に設定しますが、そのノードのスクリプトには「extendsWhatever2D」などと表示されます。ノードを作成してから手動で名前を変更するのと同じです。

これにより、ユーザーが有効にすることを選択した場合に、階層に「2D」または「3D」のデフォルト名が表示されることを回避できますが、コードの一貫性と明示性は向上します。 「3D」を含む3Dノードがないと、これは混乱を招きますが、デフォルトでは最後に「3D」を使用するのが理にかなっています。

@aaronfrankeそれはかなり堅実な考えだと思います。 これは、コードベースの一貫性と明確さを維持しながら、ユーザーが階層から余分な雑然としたものを排除できるようにする妥協案のようです。 名前の変更のアイデアに対する反対意見の多くは、名前自体に対する反対意見ではなく、階層に与える影響から来ていると思います。

@aaronfranke賢明なアイデアを台無しにする人にはなり

@aspenforestマッピングを追加することは大きなオーバーヘッドになるとは思いませんが、エンジンのアーキテクチャがわからないので、おそらく私は素朴です

@aaronfrankeのアイデアから簡単に作成できるのは、作成時にノードの名前を変更することです。 （新しいのでsnake_caseや背骨の場合に、新しく作成されたノード名を変更ProjectSettingsで既存の設定と同様にMeshInstanceノードに自動的に命名されますmesh_instanceの代わりにMeshInstance ）、ノードサフィックスに別の設定を追加すると、ノード名から「2D」または「3D」サフィックスが削除されます（したがって、新しいSprite2Dノードの名前はSpriteだけになります）。

KinematicBody2DやParticles2Dなどに不要な「2D」サフィックスがあることについて誰も文句を言わなかったので、「3D」サフィックスの追加を回避するために機能を追加する必要がある理由がわかりません相手に...ユーザーがこれらのサフィックスを最初から存在させたくない場合は、この提案を破棄する必要があります。外観上の理由でIDEのノードの名前を変更する方法を回避する必要はありません...

@ akien-mgaこれは、新しいノード名を「回避」することではなく、私にとっては、一貫した命名スキームを備えた非ハッキーなものであり、一番上の肉汁です。 コーディング、ノードの追加、またはドキュメントの検索を行うときのために、そこに接尾辞が必要です。 しかし、それらがシーンに入ると、私はそれらが何であるかを知っており、とにかく多くのものがカスタム名を取得します。

名前を一貫させるか、名前をシンプルにするためのエディター機能を取得するかを選択することになった場合、前者を選択しますが、 @ aaronfrankeは、この提案に対する異議は基本的に気付いていたと思います。そして彼の提案は、地下の一貫性を犠牲にすることなく、このアイデアが実際にあることを扱っています。

私は間違いなく、エディター機能を追加することはそれ自身の問題/ prであり、これを含めるために必要なものではないと思います。

SpatialMaterialは奇妙な名前だったので、最初は避けま​​した。 しかし、それはとても強力なクラスです。 代わりに、3層マップのアルベド+ ao +法線を使用してシェーダーをコーディングする方法を学び始めました。 次に、SpatialMaterialですべての作業を実行し、それをコードに変換してより良い結果を得ることができたので、私が行ったすべての作業が無駄であることに気付きました。 したがって、よりわかりやすい名前が必要です。

明示的な2D / 3D名の場合は+1。

将来的に非推奨になる可能性があると思われる1つのノードについて質問があります。また、名前の観点から、誰の存在が混乱する可能性があるかを想像できます。 新しいアニメーションシステムが廃止されたため、AnimationTreeとAnimationTreePlayerという名前の2つのノードができました。これらのノードは、基本的に相互に関係がありません。 これに対処するための最良の方法は何かについての考えはありますか？

@SaracenOneこれはそのような質問をするのに適切な場所ではありません。 ごめん。 このスレッドは、2D / 3Dサフィックスについてのみ説明するためのものです。

名前の変更についてより一般的に議論するための別の問題がありますhttps://github.com/godotengine/godot/issues/16863

4.0で許容できる互換性の破損の範囲を超えている可能性があるため、おそらく実行不可能/許容できないと考えていましたが、コメントするよりも経験豊富な人がいるかどうかを確認するために言及したいと思いました。

これらすべての2D / 3Dノードは、2Dまたは3Dのいずれかの単一ノードタイプから継承できると想像しました。 このようなノードのAPIには、いずれかのバージョンに期待されるすべての関数が含まれ、それらの実装は、この特定のノードが2Dであるか3Dであるかによって異なります。

理論的には、そのようなシステムは次のことができます。

1. 2D / 3Dの対応物間で一貫したAPIを作成していることを確認してください。 これは、私が見ているように、メリットとデメリットの両方です。この一貫性にもかかわらず、一方に含める必要はないが、もう一方には含まれているものがある可能性があるためです。
2. 2つの異なるタイプが相互作用しやすくするか、ノードの2Dバージョンと3Dバージョンの両方にアタッチするカスタムスクリプトを作成します。

「SomeClass2Dにはx、y、zが実装されているが、SomeClass3Dにはそのようなものはない」という状況を回避するのに適していて、命名の問題を別の方法で解決します。 これは、私が今考えていないいくつかの理由でおそらく記念碑的に愚かですが、私はそれをそこに捨てると思いました。

@vortexofdoomそれはすでに起こっていることです。 Node2Dはすべての2Dノードに継承され、Spatialはすべての3Dノードに継承されます。 問題は、すべてを何と呼ぶか​​です。

そして、さらに重要なことに、 SpatialとNode2D両方がNodeから継承します。

@vortexofdoomのアイデアには、クラス階層だけではカバーされていないものがあると思いますが、それが何であるかを正確に判断することはできません。

疑問に思っているのは、 Resource派生したすべてのクラスに- Resサフィックスを追加することが有益だと思いますか？

@aaronfranke各タイプのノード（単にKinematicBodyまたはSprite）を1つ持つというアイデアを指し、一番上のノードは、それらの動作を決定するある種のNode2D3Dです。 それがうまく説明されていなかったらごめんなさい。 したがって、2D階層と3D階層ではなく、2D / 3D階層があります。 だから私はそれがおそらく許容できるよりも大きなリファクタリングになるだろうと言ったのです。

基本型を単独で使用できないようにすることで機能する可能性がありますが、実際のノードになるには2D / 3Dとして実装する必要があります。その場合、ノード名の正方形に戻りますが、継承はより多くなります。 2Dと3Dの間で自動的に直接接続され、システム間の相互作用はさらに優れていると思います（私は思います）。

@vortexofdoomしかし、実際には2Dと3Dの間で何も共有されていません。 それらは同じノードタイプのいくつかを持ち、同じメソッド名を持っているかもしれませんが、ほとんどすべての実装は完全に異なります。 私が期待できる最も共有できるのはインターフェースです。あなたのアイデアにはif (is2d) { do 2d stuff } else { do 3d stuff }が含まれ、コードファイルの長さが2倍になり、非常に読みにくくなり、何のメリットもありません。

動作が可変の単一クラスの実現可能性は、トップレベルの2D / 3Dノードが実行できる重労働の量に確実に依存し、抽象化をさらに下に送信します。 現在一緒に存在するクラスをマッシュアップすることは、間違いなく問題の価値がないでしょう、私は確信しています。 再編成を実行するためにインターフェイスを使用してもかまいませんが、それでも、さまざまなタイプに対して少なくともある程度の標準化が適用されます。

このアイデアは、ノードの一般的なバージョンから継承できるという怠惰な願いによって促されたため、2Dバージョンと3Dバージョンを並行して実行しているプロジェクトですべてを2回実装する必要はありませんでした。 ノードは唯一の共通の祖先であるため、現時点では、ノードから継承し、何らかの方法でそれを行うためにいくつかのキャストを行う必要があります。

Node2D3D （それがいかにばかげているように聞こえるかは知っています）は、2つの座標系を互いによりうまく機能させる方法としてだけでも、ある程度の価値があると思いますが、それはまったく別の設計上の問題に近づいていますこのスレッドより。 脇道になってすみません。

@RandomShaper特にその単純な名前のオプションがある場合、私は間違いなくその利点を見ることができました。

コメントは後世のために残しておきますが、階層をほとんどそのままにして、厳密な2D / 3D命名スキームを支持して提案を撤回します。

その理由は、すべてのノードの名前を変更すると、それらのクラス名がすべてユーザーが使用できるように解放されるためです。つまり、 KinematicBodyやCollisionObjectなどの独自のクラスのセットを作成することで、探していた機能を実装できます。関連する機能を引き出して受け継ぐことができる

しかし、そのエッジケースの外でも、簡単な例としてRoomGroupようなものを考案する代わりに、 Areaようなクラスを作成することができます。

これが議論されていることをとてもうれしく思います。 私はそれが成し遂げられることを望んでいます。

それが言われたかどうかはわかりませんが、一貫性を保つために名前を変更する場合は、（人間的に可能な限り）完全な一貫性を保ち、特定のメソッドの名前を変更することもできます。

例：

Geometry.get_closest_point_to_segment()    # <-- this is the 3D version
Geometry.get_closest_point_to_segment_2d()

ノードとメソッドに加えて、データ構造はどうですか？ 私はと仮定Transformに変更されますTransform3Dと並ぶようにTransform2Dが、 Basis多分をする必要はありませんBasis3D Transform2Dすべて含まれているため、 Basis2Dがないためです。

@RandomShaper

疑問に思っているのは、 Resource派生したすべてのクラスに- Resサフィックスを追加することが有益だと思いますか？

少し少なすぎるようです。 コードの強調表示、tbhの提案（＃31054）にリソースを含めることに投票したいと思います。 それらを別の色にすることで、クラス名の入力が完了するとすぐに基本タイプが反映されます（VectorsやAABBなどの組み込みタイプの場合と同じです）。

2Dと3Dに別々のプロジェクトはどうですか。

（2dをUIに、3dをSceneに置き換える画像の提案について）。

プロジェクトを開始するときに、作業するプロジェクトを選択します。
クラス名にこれ以上のサフィックス（2D、3D）は必要ありません。

したがって、そのようにして、ある種の名前空間が作成され、これらのタイプが混在することはなくなります。

Godot2Dを使用する;
Godot3Dを使用する;

3Dまたは2Dプロジェクトにいるとき-UIをクリックすると、GUIを編集するためのUI（2D）ウィンドウが表示されます。シーンをクリックすると-シーンにいます（2Dまたは3Dはプロジェクトの種類によって異なります）。

したがって、このようにして、どのプロジェクトでもUIの2Dモードを維持しますが、Sceneは2Dまたは3Dウィンドウを開きます

このウィンドウでは、プロジェクトタイプ（2dまたは3d）に関連する、または両方で使用している場合は共有されるエンティティのみが使用可能になります

UIモードの場合、新しいノードを追加すると、UIに関連するコンポーネントのみが表示されたこのウィンドウが表示されます。
シーンモードのUIコントロールが表示されていない場合、シーンに適用できるもののみ

@dmitryuck投稿した画像の場合、3DゲームでもUIなどにGodotの2Dモードを使用する必要があるため、2Dボタンは常に必要です。 そして、とにかく2Dと3Dを混在させることができることが望ましいです。 技術的には、2Dゲームは3Dボタンを使用する必要はありませんが、非表示にする必要はほとんどありません。

視覚的に不要なサフィックスを回避するために、階層内でノード名を外観的に変更できることを上で提案しましたが、コードが常に明示的である方がよいでしょう。

@aaronfranke以前のコメントで私が何を意味したかについて少し広く説明を追加しました。

状況によってノード名の表示が違うと混乱するのではないかと思います。

人々は一目でスクリプトとシーンツリーを理解できるはずです。 コラボレーションや明確なチュートリアルなどには必須だと思います。

@dmitryuck一部のプロジェクトでは、2Dと3Dの混合が必要になる場合があります。また、一部のゲームには3DのUIがあります。

@Skarutsは、このエディターのようにコンポーネントを実装することで、3Dシーンで2Dビューに切り替えることができます

もちろん、UIモードは両方のタイプのプロジェクトに存在する必要がありますが、グリッド、拡張スナップ、ルーラーなどのUI用に特別に作成されたツールを備えた独立したウィンドウである場合があります。

@reduzの名前変更は良いことですが、 。

@xxmatxx名前の変更が短い移行期間で行われた場合は、古い名前のドラッグを停止することをお
また、変更を十分に文書化し、Godotにとらわれている人々が変更について知っていることを確認します。 非推奨バージョンのノード名を使用していることを通知する編集者の警告も、これを忘れた場合に役立ちます。

私は同意します、それが長くかかるほど、人々を混乱させる可能性が長くなります。 @AtomaFajrovulpoが提案したように、一定期間、エディターが非推奨のものを許可しているが警告を発している場合、チュートリアルとドキュメントはすぐに古くなることはありません。 私が思うこれらの線に沿った何か：

Node type 'Spatial' is deprecated and replaced by 'Node3D'. 

と

Method 'clip_polygon()' is deprecated and replaced by 'clip_polygon_3d()'. 

昨日、定数がすべて同じケースに従うわけではないことがわかりました。 たとえば、 Color.blackとVector3.UPます。 これを4.0で一貫させるべきではありませんか？

@BenjaminNavarro色定数の大文字への変更についても、 https：//github.com/godotengine/godot/pull/14704の下部で説明されてい

また、この問題は特にノード名に関するものであるため、メソッド/シグナル/定数の名前変更については＃16863で説明する必要があります。

@Calinouありがとう、私は他の問題があるとかなり確信していましたが、それらを見つけることができませんでした。

私はむしろ4.0で名前を変更し、それを終わらせて、私が取り組んでいるプロジェクトがさらに成長した後にそれが後で来ることを知っていることを望みます。

メジャーリリースがそれを行う時期ではない場合、それは何ですか。

SemVer：バージョン番号MAJOR.MINOR.PATCHを指定して、次をインクリメントします。
互換性のないAPIを変更した場合のメジャーバージョン、
下位互換性のある方法で機能を追加する場合のマイナーバージョン、および
下位互換性のあるバグ修正を行う場合のPATCHバージョン。

これでどこまで行きますか？

次に、GridMapはTileMap3Dになり、たとえばTilemap Tilemap2Dになりますか？

また、node2Dとnode3Dは少し一般的なようですが、Spatial2DとSpatial3Dを使用しないのはなぜですか？

node2DとコントロールはCanvasItemから継承されますが、UXの大きな違いは、コントロール、node2D、spatialが、名前が何であれ、新しいノードダイアログのノードの下に直接アクセスできることだと思います。 とにかくCanvasItemをツリーに直接追加することはできないので、そのダイアログに表示されるべきではないかもしれません。

そして、メソッドに関する限り、それらに2Dまたは3Dの接尾辞を追加する必要はないと思います。これは、メソッドを正しく呼び出すものを知っているからです。

リソースのインポートが遅いことへの対処や、GDスクリプトのパフォーマンスの最適化など、いくつかの有用な更新を行いたいと思っています。 現在、1Gリソースのインポートには約1時間かかります。 10Gリソースをインポートする場合は、コンピューターの前に座って2日間スリープする必要があります。 ただし、700M-1Gインポートのリソースエディタファイルシステムブラウザが壊れており、何も表示されません。 ファイルリスト、これはエディター自体の欠点かもしれないので、既存の問題を最適化して解決することがGodotにとってより良い方法だと思います。 1億から5億のリソースしかインポートできない場合、Godotは大規模なゲームを開発できない運命にありますが、現在はパスがブロックされており、先に進むことができません。 次のバージョンがそのような問題を解決することを願っています、私はGodotがますます良くなることを願っています！

@ qq715152910まったく関係のない情報を含む長いスレッドにはコメントしないでください。 この問題にコメントしたすべての人にpingが送信され、コメントはノードの名前変更の提案とは関係ありません。 結果として、私はあなたのコメントを隠します。

私たちに役立つ名前の変更について意見を述べます（主にC＃を使用します）

強くお勧めする名前の変更：

1. Transform.origin -> transform.origin

（変換プロパティへのアクセスを小文字にする）

どうして？
たとえば、空間にはアクセスできるTransformがありますが、読みやすくするために「this.Transform.origin」と書くことがよくあります。「Transform」を「transform」に変更すると、「this」をすべて使用する必要はありません。時間。 それが私たちの個人的な意見です。

1. 「Label」を「TextLabel」のようなものに変更することもサポートしています。 または、少なくとも新しいノードを追加するときに「テキスト」で検索すると、完全に関連しているため、「ラベル」が表示されます。

2. いくつかのpredifined色の定数はでアクセスする必要がありますColorに反しでColors 。

提案されている名前の変更の残りの部分については、コミュニティがより良いと考えるものを楽しみにしています。

AtlasTexture-> TextureAtlas

AtlasTextureという名前は、通常の<Type>Texture規則に従っており、 <Type>はImage 、 Viewport 、 Stream 、…

AtlasTexture-> TextureAtlas

AtlasTextureという名前は、通常の<Type>Texture規則に従っており、 <Type>はImage 、 Viewport 、 Stream 、…

これは、「Atlas」と入力したときに表示されるものです。

これは、Textureと入力するとどうなるかです。

編集：私たちはなぜその慣習を理解しています。 2番目のスクリーンショットでは、 AtlasTextureは、 <Type>Texture規則に従う他のものと非常によく似ています。 その後、その点は以前の投稿から削除されました。 この特定のケースでは、まだオートコンプリートにあまり適していません。 しかし、私たちはそれを受け入れます。 。

@bigmonteこの問題により、Godot 4.0ではTransform構造体の名前がTransform3Dに変更される可能性があるため、プロパティであることを明確にするためにthis.は不要になります。

編集： https ：

いくつかのpredifined色の定数はでアクセスする必要がありますColorに反しでColors 。

そもそも私がそれを提案したのですが、強く反対します。 でオートコンプリートを使用すると、 Colorの静的メンバー（現在はColor8 、 ColorN 、およびFromHsv ）の検出可能性が高まるため、これらを分離しておくことをお勧めします。さまざまなIDE。 一貫性を保つために、GDScriptでColor.redなど-> Colors.RED名前変更を提案することも検討しています。

ちなみに、＃16863を探していたと思います。