私には退屈すぎますが、動詞として使用される場合、 instanceをinstantiateとして修正する人にはGodspeedが必要です。

16116

Sprite.set_region（val）-> Sprite.set_region_enabled（val）
Sprite.is_region（）-> Sprite.is_region_enabled（）

TileMap.set_y_sort_mode（val）-> TileMap.set_y_sort_enabled（val）
TileMap.is_y_sort_mode_enabled（）-> TileMap.is_y_sort_enabled（）

rect_min_size
Control.set_custom_minimum_size（value）-> Control.set_rect_min_size（value）
Control.get_custom_minimum_size（）-> Control.get_rect_min_size

Controlクラスには、さらに多くのget / setが変数と同じ名前である必要があり、変数名を知っているたびにドックをチェックするのは面倒です。

TileMapクラスには、それぞれのプロパティと一致しない一連のgetterメソッドとsetterメソッドがあります。 実際、そのクラスのほとんどのゲッターとセッターの名前を変更することをお勧めします。そうすれば、それらは他のクラスの名前と同様にそれらのプロパティに同意します。

Animation.track_remove_key_at_positionは
Animation.track_remove_key_at_time

メソッド

• OS ： executeは、ブロッキングと非ブロッキングの2つの異なる方法に分割する必要があります。
  例：名前： execute / exec_process （ブロック）およびspawn_process （非ブロック）＃19302

LineEditには「text_changed」にパラメータnew_textがありますが、TextEditにはありません。

https://github.com/godotengine/godot/blob/master/scene/gui/text_edit.cpp#L6104
https://github.com/godotengine/godot/blob/master/scene/gui/line_edit.cpp#L1466

VBoxContainer / HBoxContainer / GridContainerの名前を単純なVBox / HBox / Gridに変更したいのですが...

そして、pos-> position：Dのように短すぎるため、後で名前が変更されます。

彼らはあなたが正しいと少し長いです。

Godotは現在、メソッド名に2つの異なる命名規則があることに気づきました。

[action][object]()形式のようなC＃やJavaなどの言語のAPIに見られる一般的な規則に従う場合があります。

• Mesh.GetBlendShapeName()
• AnimationPlayer.GetCurrentAnimation()
• Button.GetButtonIcon()

ただし、他の場所では、次のような[prefix][action][object]()別の規則に従います。

• Mesh.SurfaceGetFormat()
• AnimationTreePlayer.NodeGetInputCount()
• CollisionObject.ShapeOwnerGetOwner()

それらは多くのうちのほんの数例です。

将来、互換性を壊すような大幅な変更を行う余裕があれば、単一の明確に定義された命名規則に従うように名前を変更できるようにしたいと思います（前者は、Godotの内部と外部の両方でより頻繁に使用されるためです）。

ただし、他の場所では、次のような[prefix][action][object]()別の規則に従います。

• Mesh.SurfaceGetFormat()
• AnimationTreePlayer.NodeGetInputCount()
• CollisionObject.ShapeOwnerGetOwner()

すべての使用法を再確認したわけではありませんが、このスタイルのメソッドの命名は少し厄介ですが、特定の規則に従っています。 たとえば、 shape_owner_getメソッド：

doc/classes/CollisionObject.xml
101:            <method name="shape_owner_get_owner" qualifiers="const">
110:            <method name="shape_owner_get_shape" qualifiers="const">
121:            <method name="shape_owner_get_shape_count" qualifiers="const">
130:            <method name="shape_owner_get_shape_index" qualifiers="const">
141:            <method name="shape_owner_get_transform" qualifiers="const">

「プレフィックス」は最初の引数を指し、 get後の部分は、実際にそのプレフィックスで取得されるものです。 たとえば、 shape_owner_get_shape_index(owner_id, shape_id)は概念的にはget_shape_owner(owner_id)->get_shape_index(shape_id)に似ていますが、スクリプトAPIに公開されるShapeOwnerないため、この「ショートカット」になります。

surface_getメソッドについても同じ話です。

doc/classes/ArrayMesh.xml
88:             <method name="surface_get_array_index_len" qualifiers="const">
97:             <method name="surface_get_array_len" qualifiers="const">
106:            <method name="surface_get_arrays" qualifiers="const">
114:            <method name="surface_get_blend_shape_arrays" qualifiers="const">
122:            <method name="surface_get_format" qualifiers="const">
131:            <method name="surface_get_material" qualifiers="const">
140:            <method name="surface_get_name" qualifiers="const">
148:            <method name="surface_get_primitive_type" qualifiers="const">

doc/classes/VisualServer.xml
2363:           <method name="mesh_surface_get_aabb" qualifiers="const">
2374:           <method name="mesh_surface_get_array" qualifiers="const">
2385:           <method name="mesh_surface_get_array_index_len" qualifiers="const">
2396:           <method name="mesh_surface_get_array_len" qualifiers="const">
2407:           <method name="mesh_surface_get_arrays" qualifiers="const">
2418:           <method name="mesh_surface_get_blend_shape_arrays" qualifiers="const">
2429:           <method name="mesh_surface_get_format" qualifiers="const">
2440:           <method name="mesh_surface_get_index_array" qualifiers="const">
2451:           <method name="mesh_surface_get_material" qualifiers="const">
2462:           <method name="mesh_surface_get_primitive_type" qualifiers="const">
2473:           <method name="mesh_surface_get_skeleton_aabb" qualifiers="const">

またはATPの*node_getメソッド：

doc/classes/AnimationTreePlayer.xml
35:             <method name="animation_node_get_animation" qualifiers="const">
44:             <method name="animation_node_get_master_animation" qualifiers="const">
53:             <method name="animation_node_get_position" qualifiers="const">
109:            <method name="blend2_node_get_amount" qualifiers="const">
146:            <method name="blend3_node_get_amount" qualifiers="const">
172:            <method name="blend4_node_get_amount" qualifiers="const">
225:            <method name="mix_node_get_amount" qualifiers="const">
255:            <method name="node_get_input_count" qualifiers="const">
264:            <method name="node_get_input_source" qualifiers="const">
275:            <method name="node_get_position" qualifiers="const">
284:            <method name="node_get_type" qualifiers="const">
315:            <method name="oneshot_node_get_autorestart_delay" qualifiers="const">
324:            <method name="oneshot_node_get_autorestart_random_delay" qualifiers="const">
333:            <method name="oneshot_node_get_fadein_time" qualifiers="const">
342:            <method name="oneshot_node_get_fadeout_time" qualifiers="const">
478:            <method name="timescale_node_get_scale" qualifiers="const">
523:            <method name="transition_node_get_current" qualifiers="const">
532:            <method name="transition_node_get_input_count" qualifiers="const">
541:            <method name="transition_node_get_xfade_time" qualifiers="const">

これまでに提供された提案のほとんどでOPを更新しました。

VBoxContainer / HBoxContainer / GridContainerの名前を単純なVBox / HBox / Gridに変更したいのですが

私は確信していません。Godotでは、すべてに明示的な名前を付けようとしています。たとえば、 Gridは、それがコンテナであることを教えてくれません。 VBoxとHBox 、ボックスは定義上コンテナであると主張できますが、 Containerと同じではないBoxContainerがあるので、冗長性はまだ保証されています。

LineEditには「text_changed」にパラメータnew_textがありますが、TextEditにはありません。

テキストエディットにnew_textを追加するのtext_changedに含めるべきではないとさえ主張します。 ただし、新しい文字が押されたときに複数行のテキストエディットの全文を使用するよりも、入力時にラインエディットの全文を使用する方が一般的です。

@ akien-mga

すべての使用法を再確認したわけではありませんが、このスタイルのメソッドの命名は少し厄介ですが、特定の規則に従っています。

私はそれがそれ自身の命名規則であるという事実を知っています。 しかし、それでもGodotの外部で一般的に使用されるものではなく、2つの異なる命名規則に従うメソッドでBlendShapeような同じ単語が使用されることがあるため、少し混乱します。

個人的には、一貫性を保つために、それらすべての名前をGetPrefix*とSetPrefix*してもらいたいのですが、他の人がそれについて異なる意見を持っている可能性があります。

メソッドは＃16757で変更されました。 引数の順序はより理にかなっていますが、3.0と3.1の間のAPIの互換性が失われます（＃19648）。

もう一度＃9128を上げます。3Dのtranslation positionと2Dの
3.0より前に育てられましたが、3.0が出た後、... 3.0が出たために閉鎖されました。

OS.executeはposix_spawnを使用する必要があります。

もう1つは、制御ノードの「マージン」の名前を「オフセット」に変更することです。
右側のマージンが負であるため、特にStyleBoxと比較した場合、これは人々を誤解させます

@groudオフセットは一般的すぎると思いますが、最初に導入されたとき、マージンは右側に負の方向を向いていなかったため、以前は正しい単語でした。

@groudオフセットは一般的すぎると思いますが、マージンは良い用語でした（そして最初に導入されたときはマイナスではありませんでした）

さて、マージンはマイナスになっているので誤解を招きます。 オフセットは一般的ですが、より理にかなっています。 制御ノードのコンテキストにあるので、それらが一般的であることは問題ではないと思います。
とにかく、私はより良い提案を受け入れています。 このようなプロパティ名の変更はすでに提案されているので、このアイデアをここにドロップしたかっただけです。 たとえば、ここを参照してください。

ボックス/キューブのサイズに一貫性のない名前が付けられています。
衝突のBoxShapeはエクステントを使用します。
CubeMeshには、それぞれエクステントの半分であるx、y、zのサイズプロパティがあります。
CSGBoxには、CubeMeshのx、y、zサイズのように定義されたWidth、Height、およびDepthプロパティがあります。

sizeプロパティに加えて、「Cube」が使用されることもあれば、「Box」が使用されることもあります。 CubeMeshのx、y、zは個別に設定でき、ボックスでもあるため、すべてに「ボックス」を使用するのが理にかなっています。

たとえば、ターゲットとしてHTML5とUWPがありますが、これらは正確にはオペレーティングシステムではないため、OSの名前をPlatform（PlatformWindows、PlatformUnixなど）に変更することを提案します。
OS /ディスプレイの分割でも意味があります。

この＃20228から、 Label.clip_textはもう必要ありません。 Button.clip_textでも同じだと思います。

Camera2Dには現在、2つの異なるプロパティがあります。どちらもoffset （通常のオフセットとVとHに分割されたもの）という名前で、まったく異なる2つのプロパティです。これは非常に紛らわしいことです。

メソッド

- Dictionary ： erase_checkedを削除する必要があります（このメソッドはスクリプトに公開されていません）。
- Dictionary ： eraseを変更して、指定されたキーを持つペアが削除されたかどうかを判断するためにboolを返すようにする必要があります（ erase_checked実装を参照）。

20945

@neikeqこれはIMOで実行できるようになりました。 Dictionary.eraseの戻り値をvoidからboolも、プロジェクトが中断することはありません。

@ akien-mgaですが、GDNativeAPIの互換性が損なわれますね。

@ akien-mgaそれは互換性を壊しませんか？ 3.0などの古いバージョンで3.1スクリプトが機能しない可能性のある変更を加えることはできますか？

@neikeqはい、3.1スクリプトはすでに3.0と互換性がありません（ class_name 、新しいオプションのパラメーターまたは新しいプロパティ/メソッド、新しいクラスなどによる大量のAPI変更）。 下位互換性のみを考慮し、前方互換性は考慮しません。

ああなるほど！ その場合は、これらの変更を今すぐ行います。

リストに1つ追加できれば、LineEditコントロールノードとTextEditコントロールノードは、（ほとんど）互換的に使用できるように、相互に一貫したAPIを使用することで本当にメリットがあります。 今のところ、それらを一緒に操作しようとすると混乱しているように感じます。一方のノードを見ると、もう一方のノードについて混乱するほどです。

@ eska014さらに、 sconsオプションはすでにplatformです。 一貫していることは理にかなっています。

プロジェクト設定display/window/size/test_widthおよびtest_heightは、名前をwindow_widthおよびwindow_height変更する必要があります。 また、 widthとheight設定の名前を変更することも検討する必要があります。おそらく、 render_widthとrender_heightです。

カメラのnearプロパティとfarプロパティの名前は、setter / getterとは異なります（例：set_znear / set_zfar）。 これを変更する必要がありますか？

znearとzfarは紛らわしいです。 ワールドスペースのZ軸とは何の関係もありません。 クリッピングプレーンを制御するため、 clip_nearとclip_farに変更することも、 nearとfarだけに変更することもできます。

ええ、この問題を解決するには2つの方法があります。

バイナリリソース拡張を取り除く（または真剣に議論する）必要があります。（RES_BASE_EXTENSION）

gdscript_function.cppとgdscript_functions.cppは非常によく似た名前ですが、私はそれらを混同し続けています。 名前を変更する価値はありますか？ @vnen

https://github.com/godotengine/godot/pull/21425を変更して、「decimals」の名前を「step_decimals」に変更しましたが、エイリアスとして「decimals」を保持しています。 マージされたと仮定すると、次の互換性の破損で「10進数」を削除できますが、そうでない場合は、名前を変更するだけです。

@mysticfall私の意見では、不要な場合はメソッド名に「get」という単語を含めない方がよいと思います。

プロパティを取得と設定の両方にできるようにしたいが、アクセスを制御したい場合があります。 C＃では、プロパティを使用すると、フィールドであるかのように読み取りと割り当てを行うだけで、これを実行してアクセスを制御できます。これはすばらしいことです。

 var thing = CollisionObject.ShapeOwner;
 CollisionObject.ShapeOwner = thing;

ただし、GDScriptでは、プロパティは重要ではありません（？）。 getという単語なしでメソッド名を付けることもできます。 ほとんどのメソッドは何かを返すので、set-nessよりも暗黙的なget-nessを使用する方が適切です。GDScriptにはプロパティがあるため、より頻繁に使用することをお勧めします。 これに関するドキュメントが見つからなかったことに注意してください。 setgetを使用してGDScript内でそれを行う方法に関するドキュメントを見つけましたが、C ++を介して追加するのはどうですか？

一言で言えば、一貫性のない場所に「get」を配置するのは良くないことに同意しますが、私の意見では、GDScriptプロパティは実際には不可能です。または、「get」を削除して「set」を維持することもできます。 。

@aaronfranke GDScriptには、ある意味でプロパティがあります。これは、エンジンクラスがゲッターとセッター（またはゲッターのみ）を定義し、GDScriptにプロパティとして公開できるためです。 とはいえ、1）名前が明確になり、2）ゲッターとセッターが区別されるため、メソッドからgetとsetを削除することには反対です。 たとえば、 Mesh.SurfaceFormat()は「表面をフォーマットする」メソッドのように聞こえますが、「フォーマットを取得する」メソッドではありません。 また、それらのほとんど（すべてではないにしても）は無視して、とにかく代わりにプロパティとして使用できます。

さて、私はgdscript_function.cppとgdscript_functions.cppについてはそれほど気にしません。 1つにはGDScriptFunctionクラスがあり、もう1つにはGDScript関数の定義が含まれていますが、どちらがどちらであるかは常にわかります（私はそれに慣れていますが）。 また、これは重大な変更ではないため、ここにある必要はありません。

はい、GDScriptにはプロパティがあります。 C＃プロパティは、GDScriptが取得するClassDBから生成されます。

RigidBodyはいくつかのメソッドがあり、一貫性を保つためにパラメーターを交換する必要がある関連クラスは次のとおりです。

• RigidBody.add_force(force, position)からadd_force(position, force)
• PhysicsDirectBodyState.add_force(force, position)からadd_force(position, force)
• PhysicsServer.body_add_force(force, position)からadd_force(position, force)

クラスとメソッドのリスト

@TGRCdev add_forceを（position、force）に変更するよりも、 apply_impulseを（force、position）に変更する方がはるかに好きです。 力の位置はオプションのパラメータなので、最後に配置する必要があります。 ただし、すべての力とインパルスには力ベクトルが必要です。

@aaronfrankeフェアポイント。 その場合、必要なスワップのリストは次のとおりです。

• RigidBody.apply_impulse(position, impulse)からapply_impulse(impulse, position)
• RigidBody2D.add_force(position, force)からadd_force(force, position)
• RigidBody2D.apply_impulse(position, impulse)からapply_impulse(impulse, position)
• PhysicsDirectBodyState.apply_impulse(position, impulse)からapply_impulse(impulse, position)
• Physics2DDirectBodyState.add_force(position, force)からadd_force(force, position)
• Physics2DDirectBodyState.apply_impulse(position, impulse)からapply_impulse(impulse, position)
• PhysicsServer.body_apply_impulse(position, impulse)からbody_apply_impulse(impulse, position)
• Physics2DServer.body_add_force(position, force)からbody_add_force(force, position)
• Physics2DServer.body_apply_impulse(position, impulse)からbody_apply_impulse(impulse, position)

@aaronfranke Get-またはSet-プレフィックスの使用は、C＃では避ける方がよい「Javaism」のようなものであることに同意します。

私の主な関心事は、 shape_owner_get_shapeやnode_get_input_countような場合のように、「ドメインプレフィックス」の使用Get-やSet-なしで適切なC＃プロパティとして再実装できる場合

ちなみに、GodotのC＃APIのプロパティに、たとえばNode.NameとNode.GetName() / Node.SetName()ように、一致するゲッターとセッターのセットがあるのはかなり奇妙だといつも思っていました。

それは私にはかなり冗長に感じますが、私たちがそのような慣習を守る理由があれば、私たちがそうであれば、とにかくNodeInputCountとGetNodeInputCount() / SetNodeInputCount()両方を得ると思います提案どおりにnode_get_input_count名前を変更します。

皆さん、Godot APIに焦点を当てた、この問題以外のC＃APIと通常の規則について議論を続けてください。 Godot API（C ++、C、およびGDScript）は、他の言語の改善でもない限り、C＃のために適応されません。

@ akien-mga node_get_input_count get_node_input_countような名前に変更できるかどうかを議論するのは、C＃固有のことではないと思います。

いいえ、C＃固有のものはこの問題に含まれるべきではないという意味です。 必要に応じて、C＃固有の互換性の破損について別の問題が発生する可能性があります（ただし、これらのIINMはすでにいくつかあります）。

Spatialの名前をNode3Dに変更するのはどうですか？ 私はいつもそれが変だと思った。

@KoBeWi Godotが現在使用している命名スキームは、2Dのものには「Thing2D」、3Dのものには「Thing」だけなので、他の2Dコードとかなり一貫しています。 もちろん、「空間」と呼ぶ論理的なものは、「2D」を削除するパターンに従った「ノード」ですが、その名前はもちろんすでに使用されています。

Godotが現在使用している命名スキームは、2Dのものには「Thing2D」、3Dのものには「Thing」です。

では、すべての3Dを「Thing3D」に変更するのではないでしょうか。 それも頭をよぎったが、やり過ぎのようだ。
とにかく、私はちょうど提案しました。 それが非常に重要であるようではありません。 また、Spatial2DはSpatialよりもさらに悪いです。

したがって、String.right（）は、指定された位置からn個の右文字を返します。 右から数えてn文字しか返されない方が直感的ではないでしょうか。

"abcdef".right(2)
「cdef」の代わりに「ef」を返します。 IMOそれはより良いでしょう。

私は同じことを期待していました。

Pythonには、ほとんどのユーザーがGDScriptをPythonと比較するのと同じ方法があります。 それはおそらくそれをさらに変えることを混乱させるでしょう。

@KoBeWi同意します。 現在の実装とサブストリングの違いはわかりません。

Godot substrは、右側にすべてを表示したい場合は、文字列のサイズを指定するように強制します。

@Zylannほとんどの実装では、2番目のパラメーターを省略できます。 これはGodot側の問題だと思います。 その上、私はsubstr 、別の名前の新しいメソッドよりも2番目のパラメーターをオプションにするようにしています。

@Zylann @neikeqこれは、オーバーロードできないメソッドがあることの不幸な結果です。長さの指定と長さの指定の両方を持つ方法は

@aaronfrankeええと、しかしデフォルトの引数は存在します。 0または-1は、長さが指定されていないものとしてカウントされる可能性があります。

削除する必要がget_selected_id()からOptionButton現在、それは常に-1を返します。 https://github.com/godotengine/godot/pull/21837がマージされた後、 get_selected_id()はget_selected()と同じものを返します。

毎回trueを返すトゥイーンメソッドはたくさんありますが、おそらく無効にする必要があります。

WindowDialog.get_close_button（）
ConfirmationDialog.get_cancel（）-> ConfirmationDialog.get_cancel_button（）
AcceptDialog.get_ok（）-> AcceptDialog.get_ok_button（）

Treeノードにはget_selected()関数があり、フォーカスされたTreeItemを返すようです。 フォーカスと選択は異なるため、名前をget_active()ような名前に変更する価値があるかもしれません。

InputMapのload_from_globals()はload_from_project_settings()必要があります。

OPに統合されたすべての提案に：tada：リアクションを追加して、より良い概要を示します。

一貫性を保ち、すべてのrotateメソッドが「rotate」で始まるように、 global_rotate名前をrotate_global 、 rotate_object_local名前をrotate_local変更する必要があります。

一貫性を保ち、すべてのrotateメソッドが「rotate」で始まるように、global_rotateの名前をrotate_globalに変更し、rotate_object_localの名前をrotate_localに変更する必要があります。

一方、オートコンプリートの提案では、グローバル関連の関数（global_position、global_scale、global_transformなど）が隣り合っているのが好きです。 どちらのソリューションも私見に意味があります。

tree_exiting名前をtree_exited変更することもできます。これは、今では混乱を招いているようです。 ＃22840を参照してください。

@groudすでにtree_exited信号がありますよね？

@groudすでにtree_exitedシグナルがありますよね？

くそーあなたは正しい。 ＃22840のリクエストは有効だと思います

MenuItems.MENU_MAXはLineEditとTextEditで使用されることはありませんが、削除する必要がありますか？

Tabs.ALIGN_MAXについても同じhttps://github.com/godotengine/godot/blob/master/scene/gui/tabs.cpp#L750

Position3D Position2DノードとPositionHintとPositionHint2Dか、 Gizmoような他の単語に変更する必要があります。これは、エディターのみのギズモであるため、またはAxisMarkerように見えるためです。小さな軸マーカー。

それらの名前がGizmo変更された場合、おそらくより一般的な用途が与えられる可能性があります。

コントロールツリーの同じノードはReferenceRectであるため、 ReferenceAxis/2D可能性があることに注意してください。

今この問題を愛しています。 後で破損が​​実際に発生したときにそれを嫌う可能性があります;）

謙虚なArrayクラスのいくつかの提案：

• duplicate → copyまたはcloneいずれか。 この概念を「複製」と呼ぶ言語はありません。 copyはPythonとC ++で呼ばれているので、Godotにとって自然な選択です。 cloneはJavaとJavaScriptからのものであり、おそらくもう少し正確です。
• invert → reverse 。 ドキュメントはそれを「逆」とさえ説明しているので、本当に言い訳はありません。
• removeとeraseは紛らわしいです。 提案： remove_atおよびremove_value 。

最後の2つは、すべてのPool*Arrayクラスにも適用されます。

注：複製→コピー/クローンは辞書にも適用されます。

Rect2 ：

• clip → intersection

AABBはintersectionメソッドがありますが、 clipはありません。クリッピングは通常、どちらのクラスにも実装されていない何かを切り取ることを意味します。 ドキュメントでは、次のように説明されています。

Returns the intersection of this Rect2 and b.

名前を変更することもできます：

• intersects → overlaps
  実際のintersection操作と混同しないように：

Returns true if the Rect2 overlaps with another.

grabber_area -> slider_progress
slider -> slider_background

謙虚な配列クラスのいくつかの提案：
複製→コピーまたはクローン。
..。
注：複製→コピー/クローンは辞書にも適用されます。

およびノー​​ドとリソース（基本的に、スクリプトで公開されたデータ構造オブジェクト、afaik）。

私は「クローン」という言葉が好きです、それが何をするのかについてもっと明確だと思います。

朝！ @ akien-mga instance名前をnewではなくinstantiateか？ たとえば、 PackedSceneにObjectと同じインターフェイスを使用すると、プラグイン作成の定型文が削除されますが、おそらくより一般的です。 @willnationsdevどう思いますか？ 私はあなたが以前にこれに遭遇したことを知っています。

申し訳ありませんが、これについての話がどこかですでにある場合、私はそれをざっと見て見つけることができませんでした。

grabber_area -> slider_progress
slider -> slider_background

あるいは単に：
grabber_area -> progress
slider -> background ？

これが議論されているかどうかはわかりませんが、 AnimationPlayerはroot_nodeとset_root ＆ get_root 、おそらくset/get_root_nodeはずです。

CanvasItem.visible名前をCanvasItem.is_visible （およびそれが使用されている他のすべての場所）に変更しますか？ すべての（またはほとんどの、おそらく私はいくつかを逃した） boolプロパティと一致するために？

Tween.tween_completed名前をTween.tween_finishedますか？ Animation.animation_finished ？ 一般的に_completedよりも_finishedを好む？ started/finishedはstarted/completedよりも緊密な関係にあるように感じます-競技スポーツからのバイアス： start/finish -多分：D

クラスの名前をJavaScriptからHTML5などに変更することを検討してください。
このクラスには単一のメソッドがあり、 Scriptから拡張されておらず、他のプラットフォームでは使用されていません。

JavaScriptは、将来的にJavaScript言語バインディングのクラス名として使用できます。

@clayjohnが指摘しているWORLD_MATRIXは、実際にはモデルビューマトリックスです。 @reduzは、4.0では、実際のモデルとビューのマトリックス、たとえばCANVAS_MATRIXとITEM_MATRIX置き換える必要があることに同意します。

名前の変更を検討Array.invertするArray.reverse 。 反転は、逆さままたは「逆数」タイプのものに似ています。 https://docs.godotengine.org/en/latest/classes/class_color.html#class-color-method-invertedを参照して

CanvasItem.visibility_changed()シグナルをCanvasItem.visibility_changed(visibility: bool)に変更します。 可視性ステータスを一緒に送信します。 これで十分なので、 CanvasItem.hide()信号を削除します

Resource::notify_change_to_owners 、 Resource::{un}register_owner削除します。
これらはGridMapとCollisionShapeでのみ使用され、残りのコードは"changed"シグナルを使用します。

Rect2 ： has_no_area名前をhas_area変更する必要があります。これにより、条件付きで二重否定ロジックが反対をチェックするのを防ぐことができます。 同じことがAABB ： has_no_surface当てはまります。

@lupoDharkaelが言ったことに

parse_input_event（InputEvent event）
InputEventをゲームにフィードします。 コードから入力イベントを人為的にトリガーするために使用できます。

解析は誤解を招く可能性があり、解析は受信と処理になりますが、説明は入力の送信またはトリガーを示しています

＃24153のとおり- CanvasLayerは、レイヤーを使用して、ノードを描画するレイヤーを記述します。 しかし、他のほぼすべての2Dノードは、「Zインデックス」（ z_index ）という用語を使用して、同じこと（最初は何であるか）を説明します。 @swarnimarunが提案したように、 https： //github.com/godotengine/godot/issues/24153#issuecomment-444950584レイヤーの名前を改善します。

OS.has_feature（）/ Platform.has_feature（）は、OSについて何も伝えていないので、ProjectSettingsのようなものでより賢明でしょうか？

set_cell_itemの名前をset_cellに変更して、GridMapをTileMapと統合できますか？

set_cell_itemの名前をset_cellに変更して、GridMapをTileMapと統合できますか？

考えてみると、GridMapsにもset_cellvがあるはずですか？

ARVRInterface：

• ar_is_anchor_detection_enabled -> anchor_detectionまたは同様のもの
• interface_is_initialized -> is_initializedまたはis_interface_initialized

AnimationPlayer：

• play_backwards playにはオプションのブール値があるため、 play_backwardsは削除できます。

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D：

• disabledブール値をenabledブール値に変更します。

Bone2​​D：

• get_index_in_skeleton -> get_skeleton_index

• play_backwards playにはオプションのブール値があるため、 play_backwardsは削除できます。

少なくとも＃6866が実装されていない限り、これは読みやすさにとっては悪いことです。 名前付きパラメーターをサポートしているため、C＃では問題ありません。

id_pressed( int ID )およびid_focused( int ID ) IDは小文字である必要があります。

^
その変更は実際には互換性を損なうことはありません。 おそらく別の問題が発生する可能性があります。

^
その変更は実際には互換性を損なうことはありません。 おそらく別の問題が発生する可能性があります。

それは正しい！

28746- Node.replace_byは名前として混乱する可能性があります。 しかし、正確に何がより良い名前であるかはわかりません。

@ bojidar-bg多分replace_selfまたはswap_by ？ しかし、混乱を避ける唯一の方法は、それを適切に文書化することだと思います。

私が持っている場合はNode2Dが含まれ添付のスクリプトでclass_name MyNode2D 、 get_class()メソッドが返すNode2Dの代わりにMyNode2D 。 これは意図的なものかもしれませんが、混乱を招き、誤解を招く恐れがあります。

編集： https ：

@aaronfranke get_native_class()多分？ 次に、スクリプト名があれば、 get_script().global_nameから取得できます。

make_convex_from_brothers()
「兄弟」は「兄弟」に変更する必要があると思います。これは、兄弟ノードのあらゆる場所で使用されている単語です。

ARVRPositionalTracker： get_type() -> get_tracker_type()

• get_tracker_type()はより明確です- get_type()はget_class()と混同される可能性があります

• GetType()は、ここに記載されてます。

これは、戻りTrackerType 、またあるget_hand()その戻りTrackerHandつまりも変更することができるように、 get_tracker_hand()所望であれば、整合性のために。

ARVRPositionalTracker列挙型TrackerHand： TRACKER_LEFT_HAND -> TRACKER_HAND_LEFT （および右手）。 または、一貫している限り、 TRACKER_HAND_UNKNOWN -> TRACKER_UNKNOWN_HAND 。

Node.NOTIFICATION_TRANSLATION_CHANGEDはおそらくNOTIFICATION_LOCALE_CHANGEDになるはずです。これは、空間ノードで「翻訳」が「言語」ではなく「位置」を意味するために使用されるためです。

set_as_toplevel()はset_as_top_level()に名前を変更できますが、その動作を確認する必要があります。

この変更は壊れている可能性があるため、TouchScreenButtonは4.0で確認する必要があります： https ：

CanvasItemメソッド：

RID get_canvas_item（）const
VisualServerがこのアイテムに使用するキャンバスアイテムのRIDを返します。

その後、名前をget_rid()変更する必要があります。

get_canvas_item()は、すでにCanvasItemノードにいるため、混乱を招きます。 また、他のクラスにも同様のget_rid()メソッドがすでにあるため、一貫性が保証されます： CollisionObject 、 Resource 。

LabelをTextLabel変更する必要がありますか？ 何度かテキストオブジェクトを置きたいと思っていたので、それが何と呼ばれていたかを忘れたので、「テキスト」を検索すると、 RichTextLabel表示されます。 TextLabelはRichTextLabelとより一貫性があります。これは、テキストのままですが、リッチがないためです。

参考までに、UnityにはTextとTextMeshがあり、私は個人的にラベルではなくテキストと呼んでいます。

また、 TreeとGraphNode名前がTreeViewとGraphEditNodeに変更されるのではないかと思っていました。
Tree場合、その理由は、グローバルGUIノードIMOの名前が広すぎるためです。私が知っている他のすべてのGUIフレームワークはTreeViewます。
GraphNode場合、最近実際のグラフ構造を含むいくつかのプロトタイプに取り組んだため、 NodeもGraphNodeも使用できず、非常に面倒でした。

@Zylannグラフノードは（ツリーではなく）グラフのビジュアル/コントロールであるため、GraphContainerの方が適している場合があります。 GraphNodeについてはよくわかりません。

lerpc代わりにColor/Vector2/3.linear_interpolate lerpf / lerpv / lerpc Color/Vector2/3.linear_interpolateですか？ 少なくともColor/Vector2/3.linear_interpolate名前をColor/Vector2/3.lerp

＃29598で述べたようにhttp_escape / http_unescapeからuri_encode / uri_decode

Vector2/3.linear_interpolate代わりにlerpfとlerpv Vector2/3.linear_interpolateですか？ 少なくともVector2/3.linear_interpolate名前をVector2/3.lerp

vector.lerp（）への短縮は良いですね。 少なくともhttps://github.com/godotengine/godot/pull/16106の時点で、スクリプトでのlerp()には、ベクトルと色をサポートするためのスイッチがあります。

Vector2.angle_to_point()名前を変更する必要があります。 その名前は現在の説明と一致していません。 良い名前が何であるか、そしてこの関数が維持する価値があるかどうかわからない。

元の問題：＃16307

@ razcore-artこのhttps://github.com/godotengine/godot/pull/20371についてはすでにPRが公開されており、下位互換性が保たれています（私は思います）。

編集：もうしません。

Areaは、3Dであるため、実際にはVolumeである必要があります。 そして、 Area2DはAreaます。 エリアは本質的に2Dです。

GridMapはおそらくCubeMapます。 これについてはよくわかりませんが、その「グリッド」は私には2Dのように聞こえます。

CheckButtonコントロールはSwitchButtonか何かである必要があります。 Checkboxもあるので、混乱します。 または、完全に削除する必要があるかもしれません。 私の知る限り、それはとにかくチェックボックスと同じ機能を果たします。

私はre：CheckButtonに同意します、そして他のものは単なる表面的なものです。

または、完全に削除する必要があるかもしれません。 私の知る限り、それはとにかくチェックボックスと同じ機能を果たします。

UXに関しては、チェックボックスとチェックボタンは同じ機能を持っているにもかかわらず、異なるものです。
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@ Rodeo-McCabe Areaは、2Dの対応物との一貫性を保つためにそのように呼ばれ、 areaの定義の1つもa particular extent of space or surfaceです。
キューブマップは3D画像であり、構文の正確さはコンテキストに基づいている必要があります。そうしないと、混乱が生じます。

grabber_area -> slider_progress
slider -> slider_background

あるいは単に：
grabber_area -> progress
slider -> background ？

多分：
grabber_area -> progress_areaまたはprogressed_area
slider -> progress_background ？

キューブマップは3D画像であり、構文の正確さはコンテキストに基づいている必要があります。そうしないと、混乱が生じます。

@ eon-sまあまあ、私はそれを知りませんでした。

エリアは、2Dの対応物との一貫性のためにそのように呼ばれます

問題は、2Dの対応物にも一貫性がないことです。 数学では、面積は長さ*高さであり、3次元はありません。 したがって、Area2Dと言っても意味がありません。これは、エリアであるために2Dである必要があるためです。 「面積」のもう1つのより数学的な定義は、次のとおりです。

一連の線に含まれるサーフェス、具体的には、サーフェスと測定値が等しい単位正方形の数

同様に、数学の3D空間は「ボリューム」と呼ばれます。 Areaが実際には3Dノードであることに気付いたとき、最初は混乱しました。代わりに、Areaは奇妙なことに「Area2D」と呼ばれていました。 これはゲームエンジンであるため、数学の定義を採用する必要があります。

その理由は理解できますが、特に新しい人にとって、名前を変更することに特別なメリットがあるかどうかはわかりません。 これには「ボリューム」の方が適切な用語かもしれませんが、3Dの場合は「ボリューム」、2Dの場合は「エリア」を使用すると少し混乱するかもしれません。 結局のところ、2Dと3Dの両方のバリアントを持つ多くのノードには「

そもそもネーミングスキームが存在するということは（ほとんどの場合スキームに固執するノードもあるのと同じくらい）、あるバリアントの別の用語で例外が発生する場合でも、ルールに例外がないことを意味すると思います。そうしないと、ユーザーを混乱させる可能性があります。

ただし、可能であれば...おそらくArea2D名前をAreaに変更し、 Area名前をArea3Dますか？

編集：<>をエスケープしない限り、<>で囲まれたテキストは表示されないようです

@ Rodeo-McCabeノードの命名の意図は、数学ではなく人間の言語で物事を表現することであるという印象を受けます。 したがって、「エリア」は幾何学的なものではなく、レベルやステージの内部のような場所を意味します。 IE-エリア1。

ノード自体は直接ジオメトリを持たないか、それ自体がジオメトリであるため、私のような他の人は、ノードを作成するときにその領域/ボリュームがどこにあるのか疑問に思います。それでは、なぜ領域とボリューム（形状）を領域にアタッチする必要があるのでしょうか。音量？

幾何学的な領域と混同しないように名前を変更する場合は、同義語が最適です。

それらは呼ばれるかもしれません：

• Region2D / 3D
• Space2D / 3D
• Zone2D / 3D
• Field2D / 3D
• NS。

ところで、このトラッカーはメソッド、プロパティ、シグナル（ノードではない）専用であることに@ reduzは最近、4.0での互換性の破損を最小限に抑える意図があると述べたため、追加を続ける前に、おそらくこの膨大なリストをコア開発者からのレビューが必要になる可能性があります物事は終末...

目標は今のままにしておくことだと思われるので、このようなものは4.0以降の次のメジャーバージョンまでキックバックされる可能性がありますか？

この問題は主要な貢献者に任せてください。あちこちで大きな名前の変更を提案する場所ではありません。目的は、APIを煩わしくする実際の不整合を修正することです。

OPで概説されている変更は、大きな互換性の破損ではなく、ほとんどが4.0で行われます。 @ reduzが言及しているのは、2.1から3.0の間の「プロジェクトをもう開くことができない」種類の互換性の破損です（もっとたくさんオーディオとパーティクルシステムが完全に書き直されたり、インポートシステムが変更されたりするなど、当時の名前が変更されただけではありません。

4.0では互換性が損なわれる可能性があります。そうでない場合、4.0とは呼ばれません。 シーンやスクリプトで使用する場合、名前が変更されたプロパティ、メソッド、およびシグナルが適切に変換されるようにするためのコンバーターを使用すると、合理的で移植が容易になります。 とにかくそれを議論する場所ではありません:)

Controlの_set_anchor()も、先頭の「_」を削除する必要があります。

PopupMenuにはindex_pressed(index)とid_pressed(id)あり、これらは正常に機能しますが、アイテムのIDではなくインデックスで実際に発行されるid_focusedあります。

これについてはまだ問題はありませんが、今日Akienに提案した後、リストに載せる価値があります。

XRServerと呼ばれるようにARVRServerをリファクタリングします。 XRという用語を設計したとき、VRとARの両方がまだ広く使用されていないことを示しています。 いいえ、MRServerには行きません;）

RayCastには「有効」ではなく「無効」プロパティが必要ですか？ CollisionShapeには、デフォルトでfalse 「無効」があります（つまり、デフォルトで有効になっています）。 対照的に、RayCastの「有効」プロパティはデフォルトでfalse 、デフォルトで無効になっています。

または、ポジティブフォーム（全体的に混乱が少ないと思います）を使用するには、CollisionShapeに「Disabled」ではなく「Enabled」プロパティ（デフォルトではtrueを設定する必要がありますか？

@Calinou別の問題が必要かどうかは保つ必要がある場合は、そのようなブール値を常にEnabledすることをお勧めします。 ブール値をtrueに設定して何かを無効にすると、混乱することがよくあります。

@Calinou @Zylannの二重否定は混乱を招くため、可能な限り避ける必要があることに同意します。 代わりに、「無効」のブールを「有効」のブールに変更する必要があります。 何かのデフォルト値が「true」であれば問題ありません。 私は＃17212と＃21822でこの議論をしました。

マウスおよびタッチ入力イベントのspeedプロパティは、Vector2であるため、名前をvelocity変更する必要があります。

InputMap ： get_action_list( String action )関数名は、その機能についてあまり説明していません。
特定のアクションに関連付けられたEventInputsを返すため、 get_action_events(String action)なる可能性があります

また、 InputMapはget_actions( )という別の関数があり、両方の名前が文脈から外れて同じことを意味する可能性があるため、混乱を避けるのに役立ちます。

＃30736に正直に関連しているので、2つのGodot物理エンジンの名前を「GodotPhysics2D」や「GodotPhysics3D」などに変更する必要があります。

Object._init()名前をObject._new()どうですか？

get — _get
get_property_list — _get_property_list
notification — _notification
set — _set

new — _init

_init実際にはPythonの__init__ _initに従っていると思いますが、 newはインスタンスではなく、クラスのメソッドです。

String ： empty() -> is_empty()のようなものは、このスレッドに適していますか？ 最初は文字列をクリアする機能だといつも思っています。

@vortexofdoomメソッド名の不整合や名前の

StringとNodePathには、それぞれ同じことを行うemptyとis_emptyメソッドがあることを追加できます。 残りのコア組み込み型はempty名前を好むようです。したがって、 is_empty名前をNodePathして、すべての組み込み型で一貫性を持たせることができます。深刻な互換性の破損を伴う可能性があると思います。

最初は文字列をクリアする機能だといつも思っています。

ほとんどのメソッドは、そのためにGodotでclear名前を使用します。

@Xrayez 、

ほとんどのメソッドは、そのためにGodotで明確な名前を使用します。

emptyは形容詞であると同時に動詞でもあるという事実を参照するだけで、 is_を追加すると、どちらが意味するのかが明確になります。

そのブール値のすべての組み込みでis_emptyを使用することに賛成です。

Godot 3.0および3.1では、C＃にSetメソッドがありました。 ただし、これらは実際にはコンストラクターと割り当てを使用する場合と比較して実際の機能を追加しませんでしたが、コードがサイレントに失敗することを許可したため、廃止されました。 Quatのメソッドはすでに存在していたため、これらは一貫性を保つために私が追加したものがほとんどでした。これは、メソッドが設定されたコアからのものでした。 詳細については、＃30744を参照してください

GDScriptにはset_eulerとset_axis_angleがありますが、同じことを行うためのコンストラクターもあります（ q.set_axis_angle(myvec3, myval)はq = Quat(myvec3, myval)置き換えることができます。コアにもこれらのメソッドがありますベーシス用ですが、GDScriptには公開されていません。

問題は、これについて何をすべきかということです。 Quat setメソッドは、コンストラクターを優先して非推奨にし、C＃との一貫性を保つ必要がありますか、それとも実行中の操作について明示的に保つ価値がありますか？ 後者の場合、ベーシスメソッドも公開する必要がありますか？

@aaronfranke私はいつも、これらのコンストラクターが基本的に他に何もしないときに専用のメソッドを持っているのは奇妙だと思っていたので、可能であれば前者のルートを取ることにしました。

@aaronfrankeこの問題は、エンジンの機能やバグではなく、APIの名前を変更することに関するものです。

Geometryのpoint_is_inside_triangle()からis_point_in_triangle()まで、同じクラスでbool返す他のメソッドと一致します。

TreeItem.get_children()名前をget_first_child()変更する必要があります。 ドキュメントは、子アイテムを返さないことも説明する必要があります。 子はget_next()を使用して繰り返されます。

＃31976で作業しているときに、シャドウアトラスの値は2の累乗でなければならないことに気付きました（指向性シャドウとオムニ/スポットシャドウの両方）。 ただし、メソッドは任意の整数値を受け入れます。 2の累乗でない場合、メソッドは2の最も近い累乗に切り上げます。プロジェクト設定でユーザーフレンドリーな方法で表示できるように、値の列挙型を受け入れるようにする必要があります。

同様に、異方性フィルタリングレベルは列挙型（2倍、4倍、8倍、16倍）である必要があります。これは、2の累乗の値のみがここで意味をなすためです。

VisualServerのinstance_create2()は、実際にinstance_create()とは異なる動作を説明するように変更する必要があります。

オブジェクト相対変換の場合、 Spatialはtranslate_object_localあり、これはVector3を取ります。また、 Node2Dはmove_local_xとmove_local_y 、フロートを取ります。 SpatialとNode2D両方に、それぞれSpatial Vector3とVector2を取るメソッドが必要であり、 translate_localまたはlocal_translateかがtranslate_object_localよりも単純な名前にします。

@leonkrause render_widthとrender_height代わりに、 render_width viewport_widthとviewport_height 、またはおそらくcanvas_widthとcanvas_heightと呼ぶ方が理にかなっています。

@ akien-mgaは、ツリーナビゲーションメソッドをリストに追加することを検討してください。 それらは非常に紛らわしい名前であり、十分に文書化されていません。

それらに最初に遭遇したとき、get_child（）とget_next（）を考えましたが、get_prev（）は、ディレクトリが機能するのと同じようにイテレータを操作しました。 私は自分でテストを行って、呼び出されるたびに同じポインターを生成するだけであることを確認する必要がありました。

get_children（）の名前をget_first_child（）に変更する必要があります。

get_next（）およびget_prev（）の名前をget_next_sibling（）およびget_prev_sibling（）に変更する必要があります

プロジェクト設定との一貫性をEngine.physics_fpsために、 Engine.iterations_per_second名前をEngine.physics_fpsするのはどうですか？

is_processing ：

処理が有効になっている場合はtrueを返します。

can_process ：

シーンツリーが一時停止している間にノードが処理できる場合はtrueを返します

これは、名前を変更する方がよいかもしれませんcan_processのようなものにcan_process_pausedとの混同を避けるために、 is_processing方法。

----
String print( Variant value, String indent="", bool sort_keys=false )

このメソッドの名前を変更する必要があると思います。

@dalexeev名前を何に変更する必要がありますか、またその理由は何ですか？

@Calinouこのメソッドは、実際には画面に何も出力しません。 文字列を返します。 最初の考えは、 JSON.print Node.print_treeまたはOS.print_all_resourcesと同じように、または他のすべてのprint*メソッドと同じように機能するということです。

名前を何に変更する必要がありますか？ わからない。 JavaScriptはこれにJSON.stringifyを使用します。 PHPにはjson_encode関数があります。 GDScriptに直接、同様の関数（ to_jsonます。

UPD。 JSON.serializeも可能ですが、文字数ではJSON.stringifyと同じです。 ：笑顔：

「シリアル化」という言葉は通常バイナリシリアル化に使用されるため、このような出力には、その形式を取得するための追加の手順が必要になるため、お勧めします。

このクラスにはJSONタイプとVariantタイプの間を行き来するためのメソッドが2つしかないため、 jsonという単語を含むメソッドは無意味なので、使用しないことをお勧めします。

さて、良い名前になるものについては、既存のparseメソッドには実際には明確な反対の言葉がありません（ここを参照）。 おそらくこれらの1つ： encode 、 create 、 compose 、 generate ？ encodeを使用する場合は、他のメソッドの名前をdecodeに変更するのが理にかなっています。

formatとwriteがparse逆として使用されているのを見てきました。 ただし、 stringifyは、JavaScriptで使用されるため、開発者の間でよく知られているという利点があります。

formatとwriteがparse逆として使用されているのを見てきました。 ただし、 stringifyは、JavaScriptで使用されるため、開発者の間でよく知られているという利点があります。

str2varはVariantParserあり、 var2strは内部的にVariantWriter （たとえば、＃33241を参照してください。同じ用語を使用して説明しています）。

だから私はwrite 、一貫性が勝ちます。 😛

@Xrayez printをwriteますか？ PythonからPascalへ？ ：笑い：

https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552で提案されているように、 clear_colorに関連するすべての名前をbackground_colorに変更するのが理にかなっている場合があります（プロジェクト設定）。

4.0は、パフォーマンスの向上、GIプローブの改善、一般的な誇大宣伝などにより、新しい人々の大きな波をGodotにもたらすと期待しています。

これらの変更が4.0で行われた場合、既存のチュートリアル（公式の「最初のゲーム」チュートリアルを除く）がほとんど機能しなくなるため、これらの人々はハードランディングします。

これらの変更が4.0以降に行われた場合、たとえば4.1で行われた場合、それらの人々にとっては非常にでこぼこした乗り物になります。 彼らは新しいエンジンの基本を学んだばかりで、今はそれを再学習する必要があります。 初めは難しいです。次から次へとこれを2回繰り返す必要があると、完全に諦めるほどイライラする可能性があります。

したがって、4.0リリースの前に「3.3」または「3.9」バージョンを使用して、互換性を損なうAPIの変更をすべて行うことは意味がありませんが、チュートリアルの作成者は、新しいユーザーが大量に流入する前に、チュートリアルを作成するのに十分な時間を確保できますか？

これが適切な場所であるかどうかはわかりませんが、これは名前の変更の問題に対する部分的な解決策になる可能性があるため、ここで提案します。
必要な名前変更をすべて行ってから、GodotOldNames / GodotPre4.0という新しい言語を翻訳に追加して、すべての変更にすべての古い名前を付けてみませんか。
このようにして、古いチュートリアルに存在する古い名前が見つからない場合は、言語をGodotPre4.0に変更するだけです。 これにより、新しい名前への切り替えも簡単になります。
これは問題全体を解決するわけではありませんが、＃4397と一緒に機能する可能性があります。

@Anutrixこれは多くの複雑さを追加します（英語以外の言語はどうですか？）。 さらに、エディタに表示されるすべての文字列が最初からローカライズ可能であるとは限りません。

物理学「レイヤー」、レンダリング「レイヤー」

Godotを学んだ最初の数週間、この貧しい人とまったく同じ混乱を経験したことを覚えています。

物理学の「レイヤー」、レンダリングの「レイヤー」は、オブジェクト指向デザインの人には意味があるかもしれませんが、他の人には非常に混乱します。 「層」という用語は、塗料の複数のコーティング、または布地の布のコート、タマネギ（または鬼）の皮膚のコート、惑星表面の堆積物のコートなどを説明するときに使用されます。
レイヤー（単一のレイヤーではなく複数）は、これらすべての場合に互いに積み重ねられていることを意味しているようです。

多くの人にとって、特に2Dグラフィックスやアニメーションを操作する場合の「レイヤー」とは、前景、背景、およびその中間または上部のレイヤーを操作することを意味します。 多くの人は、レイヤーを背景の上にあるセロロイドフィルムと考えていますが、実際、Godotは、他の多くのゲームエンジンと同様に、このタスクを実行するためにさまざまな「並べ替え」方法を使用しています。

PhysicsオブジェクトまたはRenderオブジェクトが共有する可能性のある抽象的な共通性を「レイヤー」と呼ぶという事実は、同時にこれらの抽象的な共通性は視覚的なレイヤーの積み重ねの外観（つまり「ソート」）とは何の関係もありません。一部の人にはとても混乱します。

Physics "Layer"、Render "Layer"の実際の使用法と意味を理解したとき、なぜこれらがPhysics Group、Render Groupではないのか疑問に思いましたが、正直なところ、まだわかりません。 それらは確かに互いに積み重ね可能な関係を持っていません。つまり、それらの順序や相互の関係は完全に無関係です。 それらにレイヤーという名前を付けると、imhoは、混乱を招く人々、「グループ」、「グループの影響を受ける」、またはマスクの「グループの影響を受ける」など、今は考えられない他の用語の方が正確です。

AnimationPlayerメソッド
.stop（false）は.pause（true）と呼ばれる必要があり
それがそれがすることだからです。

プロジェクト>プロジェクト設定>表示>ウィンドウ>ストレッチ>モード：

ストレッチモード「2D」は、ストレッチモード「ディスプレイ」または「汎用」と呼ばれる必要があります
これは、3Dユースケースでも同様に機能する場合に2Dと呼ぶのは混乱しますが、すべての2Dユースケースでは実際にはうまく機能しないためです（ピクセルアートプロジェクトのように、Godot 2Dプロジェクトのほぼ半分はピクセルアートのように見えます）。
「ディスプレイ」は、実際の動作をよりわかりやすく説明します。2Dグラフィックス、3Dオブジェクト、2Dメッシュ、Line2D、ポリゴンなど、すべてのグラフィックスをディスプレイ解像度でレンダリングします。
詳しくはこちらを

ループ、リピート、ワンショット、animationplayer、timer、および同様のノードを明確にすることができます。

ループすること、繰り返すこと、そしてワンショットではないことは、すべて同じことです。

私はそれを思います
is_a_parent_of()
名前を変更する必要があります
is_parent_of()

@KoBeWiは＃19801の議論を参照してください。

私はそれを思います
is_a_parent_of（）
名前を変更する必要があります
is_parent_of（）

そうは思いませんが、is_parent_of（）は、関数がすべての親を再帰的にチェックする一方で、最初の親のみを考慮に入れることを提案しています。

@groudその場合、 is_ancestor_of()と呼ばれる必要があります。 逆の対応する関数もある場合は、 is_descendant_of()と呼ばれる必要があります。

@groudその場合、is_ancestor_of（）と呼ばれる必要があります。 逆の対応する関数もある場合は、is_descendant_of（）を呼び出す必要があります。

はい。ただし、違いは「呼び出し元」オブジェクトと関数の引数を切り替えるだけであるため、両方の関数を用意する必要はあまりありません。 たぶん、関数をis_descendant_of()ようなものに置き換えるだけで、完了です。

push_error()とpush_warning()名前をそれぞれprint_error()とprint_warning()に変更したい場合があります。 これにより、オートコンプリートのおかげでそれらがより見つけやすくなります：slightly_smiling_face：

@Calinou print_error()はprinterr()と混同される可能性があります

TreeItem.get_children()メソッドの名前を変更することを検討してください。この名前は、子のコレクションが戻り値であることを示しています。実際には、それが最初に返される子であり、その後、残りの子を繰り返す必要があります。それらはget_next() （＃19796で説明されています）。

＃ 31404から

[ rpc() / rset()名前を] remote_call() / remote_set()ますか？
これらのメソッドにも実際には短い名前があり、エイリアスで十分かどうかはわかりません。 3文字の識別子を正当化するために、スクリプトごとにこれらの呼び出しを大量に使用してマルチプレイヤーを実際に行う必要があります（これはほとんどのゲームではそうではないと確信しています）。

編集（2020-01-03）：考え直してみると、 call_deferred()とset_deferred()すでにあるので、 call_remote()とset_remote()方が理にかなっているかもしれません。

編集：下の閉じ/再開を気にしないでください、私はあまりにも速くクリックしました。

以下の方法

OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

メソッドとの一貫性を保つために、 OSクラスからInputクラスに移動する必要があります。

Input.get_joy_axis_index_from_string
Input.get_joy_axis_string
Input.get_joy_button_index_from_string
Input.get_joy_button_string

TabContainer 、 tab_close tab_hover信号と

• LightOccluder2D light_mask -> occluder_light_mask
• CPUParticles Flags列挙型-> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker get_name -> get_tracker_name
• PathFollow2D rotate ->他の何か
• ArrayMesh ArrayType列挙型->これを削除
• メッシュBlendShapeMode列挙型-> ArrayMeshに与える

https://github.com/godotengine/godot/issues/15763#issuecomment-568908661の説明

RichTextLabelのmeta_hover_startedおよびmeta_hover_endedシグナルは、他のほとんどの同様の命名規則に一致するように名前を変更する必要があります： meta_hover_enteredおよびmeta_hover_exited 。 これにより、Godot APIの残りの部分をより厳密に模倣できるだけでなく、現在の命名スキームでは、アルファベット順であるため、順序が逆になります。 明らかに、操作の時系列の流れは最初に入力してから終了することであるため、ドキュメントを読んでいるときにこれは少し混乱しています。 それは、それを変更するための読みやすさと一貫性を向上させます。

Texture.sizeプロパティがないことに気づきました。 代わりに、Texture.get_size（）ゲッターを呼び出す必要がありました。

私はDiscordでこれが意図されているかどうか尋ねました。 1つの提案は、これをプロパティに変換する必要があるかどうかを尋ねる投稿でした。もう1つの提案は、これには「セッター」がないため、get_size（）を使用することが現在予想される動作であるというものでした。

@jmbjr （getterメソッドだけでなく）プロパティとして公開されている読み取り専用プロパティはありますか？ 読み取り専用プロパティを設定しようとすると、組み込みのエラーハンドラが表示されたのを覚えています。 そもそもGDScriptに公開されているかどうかはわかりません。

ええ、読み取り専用の公開プロパティのサポートを開始する場合は、USAGEフラグが必要であり、それをサポートするGDScriptパーサー/コンパイラコードも追加する必要があると思います。

SoftBodyにはareaAngular_stiffnessがあります。これはarea_angular_stiffnessある必要があります（関連するすべてのメソッドで同じです）。

Input.joy_connection_changed （メソッド）は、スクリプトAPIに公開されるべきではないようです。これは、各プラットフォームのジョイスティック処理コードによって内部的に呼び出されます。

@ akien-mga Godotを発見してから非常に早い段階でそのメソッドを最初に見たとき、私は同じような考えを持っていました。それから、児島がこれに非常に似ているはずのメソッドを中心にMetalGearSolidで伝説的なゲームプレイを構築した方法を思い出しました。 Godotは、児島のように1行のコードで4番目の壁をくちばしにする手段さえ私に与えてくれます、それはなんて素晴らしいことでしょう！」

LabelとRichTextLabelは、一貫性のないテーマプロパティがあります。

Label:
int line_spacing [default: 3]
Color font_color [default: Color( 1, 1, 1, 1 )]

RTL:
int line_separation [default: 1]
Color default_color [default: Color( 1, 1, 1, 1 )]

また、デフォルト値が異なるため、同じフォントのLabelとRichTextLabel高さが異なります。

テキストエディットのrequest_completion信号は、過去形を使用するためにcompletion_requestedに名前を変更できます。 現在のバージョンは、シグナルのコールバックyの性質とは対照的に、やや必須に聞こえます。

物理学の身体信号との別の矛盾

領域：

area_shape_entered（int area_id、Area area、int area_shape、int self_shape）
area_shape_exited（int area_id、Area area、int area_shape、int self_shape）
body_shape_entered（int body_id、Node body、int body_shape、int area_shape）
body_shape_exited（int body_id、Node body、int body_shape、int area_shape）

これらの最後の2つのarea_shapeはself_shapeである必要があると思いますか？ また ...

剛体：

body_shape_entered（int body_id、Node body、int body_shape、int local_shape）
body_shape_exited（int body_id、Node body、int body_shape、int local_shape）

ここではlocal_shapeと呼ばれます...

@FrederickDesimpel私の知る限り、互換性を損なうことなく引数の名前を変更できます。 このためのプルリクエストを自由に開いてください：slightly_smiling_face：

バリエーション：

実数->浮動小数点
なし->ヌル？

「float」という用語は特に32ビットfloatによく使用されるため、個人的には「real」の名前が好きですが、Variantのrealはdoubleであり、ほとんどのエンジンはreal_tを使用します。

PS私たちはすでに2017年にその名前を逆に変更しました。

これらの名前を変更することを検討しましたか？
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterialは、マスターですでにStandardMaterial3Dに名前が変更されています。

必要がありますlimit_の値はCamera2Dに変更することがRect2i ？ 現在、それらはたった4つのintです。

編集：ドラッグマージンもRect2変更できます。

String::begins_withからString::starts_with 。

本格的なプログラミング言語（Java、Pythonなど）のように。

InputEvent.is_action_pressed to InputEvent.is_action_just_pressed
InputEvent.is_action_released to InputEvent.is_action_just_released

https://github.com/godotengine/godot-proposals/issues/316#issuecomment -589426014

「just」という単語はありませんが、event.is_action _...（）はInput.is_action_just ...（）に対応しています。

Node.add_child_below_node()の最初の2つの引数を入れ替えて、最初の引数がNode.add_child()と同じになるようにする必要があります。 ＃19642を参照してください。

_セマンティックアテロフォビアスピーキング…_

Node2D.draw_circleは円ではなくディスクを描画するため、 Node2D.draw_diskする必要がありますか？
Node2D.draw_circleは、 0からTAUへのdraw_arcショートカットとして引き続き存在する可能性があります。

@Goutte英語では、「円」は

英語では、「円」は白抜きの円または塗りつぶされた円のいずれかを指します。

これをサポートするものが見つかりません。 この主張の出典はありますか、それとも腸の感覚ですか？

発見可能性については、まだdraw_circleを使用できます。これは、ディスクではなく、単に円を描くだけです。

これをサポートするものが見つかりません。 この主張の出典はありますか、それとも腸の感覚ですか？

https://www.merriam-webster.com/dictionary/circle

1 b：閉じた平面（平面エントリ6センス2bを参照）曲線のすべての点が曲線内の固定点から等距離（等距離センス1を参照）
1 c：そのような曲線で囲まれた平面

（1 b）は数学の円（周囲長）、（1 c）は数学の円盤（表面）です。

APIに関しては、 draw_rect() 、 draw_filled_rect() 、 draw_circle() 、 draw_disk()よりもdraw_rect() draw_rect(bool filled)とdraw_circle(bool filled)方がIMOの方が使いやすいです。 draw_disk() （または塗りつぶされた長方形の数学的な名前は何ですか？）

編集：実際には、 draw_circle()はまだfilled引数がありません。 円（周囲）と円盤（塗りつぶされた円）の両方を描画できるように、1つ追加する必要があると思います。

よかった、ありがとう。 私の生徒のほとんどはフランス人で、全員がこれに混乱していました。私もそうです。彼らはゴドットを非難しました。もちろん、私は彼らを許すことができませんでした。

塗りつぶされた長方形の数学的な名前は何でしょうか？

それはかなり良い質問です; 私が見つけることができるのは「長方形の領域」または「長方形の内部」だけであり、どれも適切ではありません。 ウィキは、ほとんどの人が_polygon_という用語を_ポリゴンの内部_を意味するために悪用していると述べていますが、別の言葉を提供することはありません。

filled引数はあいまいさを軽減するのに役立つと思いますが、引数のリストのどこに配置するかを決めるのは面倒です。

@Goutteですが、引数のリストのどこに配置するかを決めるのは

これはオプションの引数（デフォルト値があります）であり、 draw_rectとの一貫性を

コントロールノードがモーダルノードと呼ばれる場合があります。 https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal主にViewport.get_modal_stack_top（）関数に関連しています

EditorInterfaceのget_selected_path get_current_pathメソッドと

これらのメソッドは、同じ名前のFileSystemDockのメソッドの上にある単なる薄いレイヤーです。

String FileSystemDock::get_selected_path() const {
    if (path.ends_with("/"))
        return path;
    else
        return path.get_base_dir();
}

String FileSystemDock::get_current_path() const {
    return path;
}

それらは両方とも「選択された」または「現在の」（または他の何か、しかし両方のために）どちらかを適応させる必要があり、一方はget_*_pathで、もう一方はget_*_dirです。

@Goutte Solid Rectangleは、塗りつぶされた長方形の代わりになりませんか？

OPは2019年6月以降に投稿された提案で更新されますか？ これは大変な作業だと理解していますが

OPを更新することは、投稿された提案がチームによって価値のあるものとして受け入れられることも意味します。

@Anutrixの「充填済み」は、「固体」よりも使用するのに適した単語です。「固体」は「液体または気体ではない」ことを意味する場合があるためです。

@pycbouh各号のPRがあれば、それをリンクするのも良い考えです。 OPはすでにこれを行っていますが、その下のコメントについては行っていません。

それが発生したかどうかはわかりませんが、このドキュメントのドキュメントを覗き見するのをやめる頻度が

• Array.remove => remove_at （C＃など）をインデックスで削除
• Array.erase => remove_value 、またはremove （C＃など）で値で削除

（またはeraseを使用したそのバリアント）

今のところ、 eraseとremoveは私にとって同じ意味ですが、一方がインデックスで、もう一方が値であるという点を除いて、どちらがどちらかを忘れ続けています。

すでに育てられた、私の悪い。 気づかなかった、Githubがスレッドを折りたたんでいる、私のCtrl + F検索がそれを見逃したxD
まだOPにはありません

@Zylannどうぞ： https ：

Zylannを出向させて、私は削除がインデックスによるものであることを忘れ続けています...

ButtonList列挙型はマウスボタンであるため、おそらくMouseButtonList名前を変更する必要があります。

JoystickList列挙型を分割する必要がありますか？ ボタンと軸の両方が含まれているため、 JoypadButtonListやJoypadAxisListなどの方が理にかなっている場合があります。

質問ですが、なぜMouseButtonないのですか？
ボタン== MouseButton.LEFTの場合：
より良い読み
ボタン== MouseButtonList.LEFTの場合：

良いアイデア。 その場合、 KeyList -> Key 、 MidiMessageList -> MidiMessageもあり、ジョイスティックのものはList削除する必要があります。

私はいくつかのメソッド/プロパティを使用して気づいたnormal_map他の人が使うのに対し、 normalmap 。 これらのいずれかを決定する必要がありますが、おそらく両方を決定することはできません。 normal_mapがいいのですが、 normalmapでも大丈夫です。

GDScript

range_lerp（）= map（）
シード= set_seed（）

map（）は、おそらく新しい関数型プログラミング機能のために予約されています。

Vector2.tangent()は、ドキュメントでは次のように説明されています： Returns a perpendicular vector. 、これは、返されたベクトルが正規化されている場合のorthogonalまたはorthonormalの定義です。 以来Vector2.tangent()戻り、私は提案している非正規化ベクトルは、我々はそれを名前を変更する必要がありますVector2.orthogonal()あるいはVector2.perpendicular()人々は、おそらく数学の命名法に対して何かかを持っている場合でも、 Vector2.normal() 、しかし人々はnormalized()とnormal()間で混乱するかもしれません

私の側では逸話的ですが、これを初めて探したとき、ドキュメントでの最初の検索は_perpendicular_でした。

.tangent()を.perpendicular()単なるエイリアスとして保持することもできますね。

orthogonalという名前は、他の単語と比べて一般的な英語の単語ではないため、好きではありません。 以前はtangentに問題はありませんperpendicularが、とにかく

ええ、直交はまれです。 私は.perpendicular（）に投票しますが、compatのtangent（）エイリアスを維持するだけでなく、より短くなります。

@ Zireael07接線を取得する方法が1つしかない場合は希望します。 結局、あまり一般的な操作ではないと思います。

procgenスクリプトで頻繁に使用していることに驚かれることでしょう:)

これが議論を引き起こすとは思っていませんでしたが、通常の数学用語の誤った使用法であるため、個人的にVector2.tangent()維持することに反対しています。 Vector2.tangent()の積は、定義上、間違っています。 このスレッドの名前は次に計画されている互換性の破損であるため、互換性を維持するために後方に曲げる必要がある理由はわかりません。 私はVector2.perpendicular()個人的に元気です。

提案：デフォルトでfind_node()のownerパラメーターをfalseにします。

提案： Treeのメソッド/シグナルの名前を変更して、「選択済み」、「フォーカス済み」、「なし」などの用語/ステータスに関して混乱を少なくします。

Tree::ensure_cursor_is_visibleは誤解を招くため、 ensure_focused_item_visibleやensure_selected_item_visibleなどの名前に変更する必要があると思います。

クラスリファレンスでさえ、次のように述べています。

Makes the currently focused cell visible.

This will scroll the tree if necessary. In SELECT_ROW mode, this will not do horizontal scrolling, as all the cells in the selected row is focused logically.

Note: Despite the name of this method, the focus cursor itself is only visible in SELECT_MULTI mode.

Script::get_instance_base_type()は、具体的にはその下のネイティブ型を返します。 スクリプトクラスに名前を付けたので、スクリプトの「ベース」がスクリプトの名前である可能性があるため、これをget_native_type()名前変更する方が理にかなっています。 誤解を招く恐れがあります。

@willnationsdev get_class() https：//github.com/godotengine/godot/issues/16863#issuecomment-491421079もあり

@aaronfrankeええと、 get_class()では、「私が現在見ているものの名​​前は何ですか？」を指すために広く使用されています。 したがって、 Script場合、 "GDScript" 、 "CSharpScript" 、またはそのような性質のものが返されることを期待します。 ただし、 Scriptクラスでは、名前が付けられている場合は実際のスクリプトクラスの名前を返すメソッドである必要があります。 専用の問題もあります。 https://github.com/godotengine/godot/issues/21789#issuecomment -618588900

編集：ああ、私たちがget_class() 、 get_base_class() 、およびget_native_class()を持っている場合、 get_instance_base_type()になるにはget_instance_native_class() get_instance_base_type()が本当に必要です命名規則に従い、スクリプトの情報ではなくインスタンスであることを明確にします。

AUTO_TILEとATLAS_TILE両方があるため、 TileMap autotile_coord （プロパティとメソッド）の名前をtile_coordまたはtile_coordinateに変更する必要があると思いますATLAS_TILEこれを使用すると、名前が新しいユーザーを混乱させる可能性があります。 ドキュメントも更新する必要があります。 問題がなければ、この変更を行うことができます。

LineEdit.textと同じ動作をするため、 LineEdit.text_changedからnew_text引数を削除することを検討してください。

また、 old_textに加えて、またはnew_text代わりとして、 old_text追加することを検討してください。

https://github.com/godotengine/godot/issues/16863#issuecomment-394745886に関連

「衝突レイヤー」、「VisualInstanceレイヤー」、「レンダリングレイヤー」の名前を「ect」に変更します。
「衝突グループ」、「VisualInstanceグループ」、「レンダリンググループ」、「ライトグループ」

これらの「レイヤー」がスタックされていない理由についての混乱は、コミュニティチャネルでの細かい時計仕掛けのように発生します。

Maya、Lumberyard、Unityではレイヤーと呼ばれていることに注意してください。

他の誰かが何かをしたからといって、それがまだ起こらないという意味ではありません
混乱し、良い考えです。

月、2020年5月18日には、1：09 PM Jummitの[email protected]は書きました：

Maya、Lumberyard、Unityではレイヤーと呼ばれていることに注意してください。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
。

まだ誰も言及していないことに驚いています
Camera2D.zoom
ズームが大きくなるとカメラがズームアウトします。これは「ズーム」の仕組みではなく、直感に反します。 名前を何に変更するかわからない、おそらくview_scaleまたは同様のもの。

@KoBeWi zoomの名前を変更する代わりに、値を大きくするとズームインするようにスケールを反転するべきではありませんか？

これにより、プロパティの名前を変更するのと同じように互換性が失われます。 「スケールを反転」ルートにすると、残念ながら自動的に修正できません。 それでも、長期的には混乱が少なくなる可能性があります。

@Calinou @KoBeWiただし、このズームプロパティを直接使用するユースケースはありますか、それともスケールに適用するために毎回反転する必要がありますか？

Viewport.get_final_transform() => Viewport.get_final_transform_2d() ？

Viewport.get_final_transform() => Viewport.get_final_transform_2d() ？

たぶん、でもそれとNode2D.get_position_2d()ようなものでどこに線を引くのでしょうか？

クラスにViewport2Dという名前を付けることもできますが、Viewport3Dを作成しない限り、その名前は必要ありません。

@nathanfranke Transform 2つのタイプがあることを考えると、名前だけでは2Dか3Dかを判断する方法がないため、この方法を提案しました。 （他のメンバーはすでにcanvas_またはmouse_持っていますが）

@Zylannこの方法は実際には本当に奇妙です。 canvas_transformとglobal_canvas_transformというプロパティがあり、 canvas_transformは次のとおりです。

ビューポートのキャンバス変換。すべての子CanvasItemの画面上の位置を変更するのに役立ちます。 これは、ビューポートのグローバルキャンバス変換に関連しています。

したがって、 get_final_transformは、これらの変換の両方を組み合わせることが期待されます。 ただし、コードを見ると、実際にはそうではありません。

このためのコードはreturn stretch_transform * global_canvas_transform;です。 私はstretch_transformが何のためにあるのかを理解しようとしてきましたが、私にはわかりません。公開されておらず、 canvas_transform変更しても設定されていません。 stretch_transform使用しない_stretch_transformというメソッドもあります。 これはset_sizeによって呼び出され、 _stretch_transformによって生成された値を取得し、それをstretch_transform割り当てます。 canvas_transform_overrideもありますが、これについては触れておらず、公開もされていませんが、内部で使用されています。

結局、このクラス全体を見渡すべきだと思います。 ビューポートには、4つの異なるTransform2Dメンバー、4つのRect2（i）メンバー、9つのVector2（i）メンバー、および2つのTransform（3D）メンバーがあります。 これは、変換情報を格納するデータ構造だけですでに264バイト（単精度浮動小数点数を含む）です。すべてのポインターを合計すると、おそらく1KBに近くなります。 たぶんViewportはこれをすべて必要としますが、それは複雑すぎるようで、少なくともコメントがあるはずです（このファイルには少なすぎます）。

Node2D / Node3D to_globalとto_localを削除する必要がありますか？ 基礎でのみ機能するメソッドの追加を提案した＃38902についてフィードバックを提供しましたが、これらにはいくつかの問題があります。

デモプロジェクトでは、 to_localはどこにも使用されておらず、 $ grep -RIn "to_global"は5つの結果のみを返します。これらはすべて、3DデモのGUIにあり、変更することでデモのパフォーマンスを向上させることができます。これにより、グローバル変換がキャッシュされ、 to_globalを使用する代わりにxformが使用されます。

一言で言えば、これらのメソッドの懸念は、それらがまれにしか使用されないことと、グローバル変換を数回再計算するためにパフォーマンスが悪いコードを書くことを奨励することの両方です。

27509

AnimationPlayerのanimation_startedとanimation_finishedは、少し直感に反します。 前者はキュー内のすべてのアニメーションに対して呼び出され、後者はキューの最後に到達したときにのみ呼び出されます。 ドキュメントには明確に記載されていません。

特定のアニメーションがいつ終了するかを検出したい場合は、 animation_changedとanimation_finished両方を使用する必要がありますが、これは便利ではありません。

その問題からの@txigremanの提案が本当に好きanimation_finished使用して、新しいシグナルanimation_all_finishedを追加できます（ Tweenと同様） ■ tween_all_completed ）これは、キューの最後に到達したときにのみ起動します。

animation_queue_finishedおよび/またはanimation_queue_startedどうですか？

ここで見つからないので提案します、
findとfindnペア。

3.2の最後の安定したビルドからのイメージ。

大文字と小文字を区別する性質に言及するために、名前を変更できるかもしれません。

たとえば、 find_ignorecase代わりにfindn ？

@swarnimarun n終わる他の多くの大文字と小文字を区別しないメソッドがあります。 それらの1つを名前変更する場合は、すべての名前を変更する必要があります。

これらのメソッド（ find / findnなど）は基本的に同じです。 大文字と小文字を区別する必要があるかどうかについて、引数を追加するだけで済みます。

@Calinou数か月間ドロップした後、GDScriptを使用することで、APIに対する新しい視点が得られたと思います。

明白であればあるほど良い。 すべてのAPIを覚えておくのはそれだけでは難しいので、関数の名前付けの冗長性を少し高めることは、まともな変更のように思えます。

@KoBeWiは、別のフィールドを追加することを覚えたり、コードを読んだりしているときに（APIのその部分を忘れた/知らなかった後）、関数名で何をするのかを伝えることができて非常にありがたいです。

したがって、他の関数が異なる引数などで最初の関数を呼び出す場合でも、別の関数を使用することをお勧めします。

EditorInterface.get_editor_viewport() => get_editor_main_container()

この関数はViewport返しません。たまたま、2D、3D、スクリプトエディター、およびアセットライブラリを保持する中心的な関数であるControlのみを返します。 記録として、返されるノードはVBoxContainer*ですが、抽象化されています（ただし、設定の選択に影響するため、知っておくことが重要です）。
説明がViewportクラスにリンクしているため、ドキュメントも間違っています。 https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class -editorinterface-method-get-editor-viewport

@Zylannはコンテナではないのでget_editor_main_screen()必要がありますが、メイン画面です。

@aaronfrankeはContainerノードでもありますが、実際には^^でもそうです...メイン画面も機能します

質問したいのですが、このトピックの提案を追跡している人はいますか？

たとえば、上記（https://github.com/godotengine/godot/issues/16863#issuecomment-557657413）では、 JSON.printメソッドの名前を変更することを提案しました。 いくつかのオプションが提案されましたが、最初の投稿にはどれも表示されませんでした。

たくさんの投稿で役に立つアイデアが失われるのではないかと心配しています。 ：笑顔：

@dalexeev最近、最初の投稿を更新する際に最初のパスを実行しましたが、まだすべてのコメントを確認していません。

RichTextLabelいくつかのバグを修正する可能性のあるものがあります。 現在、 bbcode_textとtextがありますが、どちらも内部的に同じデータ構造を使用しています。 呼び出されたメソッドのみが異なりますが、 use_bbcodeが有効になっていない場合、 set_bbcodeはset_textにフォールバックします。 だから私は先に進んで＃39148でそれらを削除しました。 そこに他のポイントをいくつか追加しました。

NodeのGetSceneInstanceLoadPlaceholder()は非常に間違っているように見えます。最初は名前が示すようにプレースホルダーを返しませんが、ブール値と次にこれは継承された実装の詳細を実際の要件なしで基本クラスにリークします（タイプのテストノードのは他の方法で可能です）

RayShape → SeparationRayShape 、godotengine / godot-proposals＃711で最初に提案されたとおり。

sort_customを削除し、 sortにオプションのCallableを使用させるのはどうですか？

OS.get_ticks_msec()とOS.delay_msec()を削除して、それぞれOS.get_ticks_usec()とOS.delay_usec()を優先する必要がありますか？ これにより、同じことを実現する2つの方法が回避されます。 ミリ秒単位の値が必要な場合は、その値を1000で乗算または除算できます。

また、GDScriptとC ++はどちらも、整数リテラルに区切り文字を追加できるため、大きな値が読みやすくなります。

# Since Godot 3.2.
OS.delay_usec(123_456_789)

// Since C++14.
OS::get_singleton()->delay_usec(123'456'789);

また、GDScriptとC ++はどちらも、整数リテラルに区切り文字を追加できるため、大きな値が読みやすくなります。

削除が発生した場合は、 get_ticks_usec()説明に区切り文字を記載する必要があります。

@Calinou一方では正しいですが、他方では、ほとんどの場合、そのような高い精度は必要ありません。

空間素材の「アルファシザー」は標準の「アルファクリップ」になるはずです

@Flavelius 「アルファクリップ」という言葉がよく使われるのを見たことがありません。 確かに、「アルファテスト」は「アルファクリップ」と「アルファシザー」の両方よりもはるかに頻繁に使用されています。

それは変更することがたくさんあります！ 誰かがこれらの提案の実装に取り​​組んでいますか？

@MCrafterzz人々はプルリクエストを開いて、定期的に名前を変更します。 これは、一度にすべてではなく、段階的に実行されます。

テクスチャ（Texture2D）と画像

• Texture（Texture2D）のget_data（）はget_image（）という名前にする必要があり、Imageのget_data（）はget_bytes（）という名前にする必要があります。

IMO： get_imageはい、 get_bytesいいえ。

texture.get_image().get_data()

メッシュ/ MeshInstance

• メッシュでは、これらのメソッドを使用してマテリアルを取得/設定します。
  surface_get_material/surface_set_material
• MeshInstanceでは、これらのメソッドを使用して取得/設定します。
  get_surface_material/set_surface_material

私が推測するのと同じ名前にする必要がありますか？

@Coldragon get_surface_material / set_surface_materialで、プロパティはsurface_materialます。

@Coldragon get_surface_material / set_surface_materialで、プロパティはsurface_materialます。

これは「通常の」set / getではなく、ターゲットSurfaceのインデックスを持っています（Meshクラス内のVectorです）

Arrayブール値をわかりやすく説明するために、 empty()名前をis_empty()する必要があります

String find_last()を優先して、 rfind() find_last()を削除する必要があります。 正確には名前の変更ではありませんが、どちらを保持するかを検討する価値はあります。

単一の数値の場合、 stepifyます。 Vector2 / Vector3の場合、 snappedます。

それらは同じことを行い、ベクトルは各コンポーネントに対してstepifyを呼び出します。 1つの名前を選択する必要がありますが、どれを選択しますか？

ポーリング:: heart：=両方をstepifyにする必要があります、：rocket：=両方をsnappedにする必要があります、：-1：=名前を変更しないでください。

AABBにはintersection 、Rect2にはclipます。 彼らは同じことをします。 1つの名前を選択する必要がありますが、どれを選択しますか？

ポーリング:: heart：=両方をintersectionにする必要があります、：rocket：=両方をclipにする必要があります、：-1：=名前を変更しないでください。

@aaronfrankeはい、私は以前https://github.com/godotengine/godot/issues/16863#issuecomment-449628319でintersection名前を提案しました。 次に、 intersectsあり、 Rect2でoverlapsに名前を変更できますが、 intersects → overlapsに関してintersects AABBについてはわかりません。 overlaps名前を変更します。

find_nodeやget_nodeの名前は、2つの違いをまったく示していないため、名前を変更する必要があると思います。
find_nodeは子のみを参照するので、おそらくfind_child_node？
get_nodeの適切な代替名が何であるかわかりません。 最初に考えたのはget_tree_nodeでした。これは、ツリー内のどこからでもノードを取得できるためですが、相対パスを使用してシーンツリーの外部で使用することもできます。

get_node良いと思いますが、 find_node名前をfind_child変更できます

@MuffinManKen get_nodeは完全に理解できると思います。あなたが言ったように、ノードがその一部であるかどうかに関係なく、指定されたノードと同じツリーに接続されている限り、どこでも任意のノードをフェッチできるからです。 SceneTreeかどうか。

@Coldragon find_node名前をfind_child変更するのが好きかどうかはわかりません。これは、何らかの理由で直接の子でのみ機能するという印象を与えるためです。 別の方法は、それをfind_descendantか何かと呼ぶことですが、それはあまりにも言葉遣い/複雑です。 find()減らすことも、何を探しているのかが不明確になるため、意味がありません。 そのため、別の代替案が求められない限り、 find_nodeもそのままにしておくべきだと思います。 APIドキュメントの動作の違いが明確に文書化されている必要があります。

Godot 3.1では、プロジェクトがエクスポートテンプレートバイナリ（デバッグまたはリリース）から実行されている場合にtrueと評価されるstandalone機能タグを追加しました。 反対はeditorで、プロジェクトがエディターバイナリから実行されている場合はtrueと評価されます。

ただし、時間の経過とともに、 standalone名前をrunnerに変更する方がよいと思います。これは、短く、少しわかりやすいためです。 どう思いますか？

exportedまたはreleaseどうですか？

@aaronfranke exportedは、プロジェクトがエクスポートされたことを意味しますが、必ずしもそうであるとは限りません。 アセットが事前にインポートされている限り、エクスポートテンプレートバイナリを使用して、ソースファイルから直接プロジェクトを実行できます。

また、 releaseはリリースモードのバイナリにすでに使用されています（デバッグモードのバイナリに使用されるdebugとは対照的です）。

runnerは私にはあまり明確ではないようです。 standaloneは大丈夫です。 !OS.get_feature("editor")使用できるので、削除しても問題ありません。

!OS.get_feature("editor")使用できるので、削除しても問題ありません。

ただし、 .notセレクターがないため、これをプロジェクト設定のオーバーライドに使用することはできません。 デフォルト設定とそのオーバーライドを入れ替えることでおそらく実現可能ですが、もう少し複雑に感じます。

gameとは対照的に、なぜappまたはgame editorはないのでしょうか。 それとももっと混乱するでしょうか？ おそらく、 no-editor機能フラグをより明確にするために持っていますか？

@willnationsdev game 、Godotがゲームにのみ使用できることを意味します。 多くの人がゲーム以外のアプリケーションにGodotをうまく使用しているので、より包括的な用語を使用したいと思います：slightly_smiling_face：

また、それは実際には自明ではありません。人々は、それがエディターから実行されているプロジェクトにも当てはまると思うかもしれません（結局、エディターから「ゲーム」を実行しているのです）。 同じことがappます。

「独立」についてはどうですか？

2020年7月25日土曜日、午前5時49分Hugo Locurcio、 notifications @ github.com
書きました：

@willnationsdevhttps ：//github.com/willnationsdevゲームはGodotを意味し
ゲームにのみ使用できますが、そうではないことが証明されています🙂

また、それは本当に自明ではありません：人々はそれをまだ考えるかもしれません
エディターから実行されているプロジェクトに適用されます。 同じことがアプリにも当てはまります。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
。

@MuffinManKen independentも、私にはあまり自明ではありません。

エディターとスタンドアロンはおそらく標準的な名前付けであるため（少なくとも1つは多くの異なるエンジンで見られます）、車輪の再発明を行う理由はありません。

Get_nodeは子孫の取得に限定されていないため、非常に
誤解を招く名前。 2つのメソッドには、非常に異なる名前が必要です。
doは非常に異なります。

2020年7月25日（土）午後3時14分golddotasksquestions、<
[email protected]>は次のように書いています：

私は最初に私が長い間持っていた混乱を覚えています
find_nodeおよびget_node。 私は本当にfind_descendantと
get_descendant、これらは真実で有益な@willnationsdevであるため
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
「言葉遣い」はお茶のみんなのcuではないかもしれませんが、imhoは本当にではありません
オートコンプリートと省略形の「$」があるため、問題が発生します。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
。

TransformとTransform2D両方のメソッドで、 inverseとxform_inv名前を変更/削除する必要があると思います。これらのメソッドが実際に行うことは、人々が期待することではないためです。 。 詳細： https ：//github.com/godotengine/godot/issues/39433#issuecomment-664024521。

RayCast.cast_to名前をRayCast.segmentなどに変更する必要があります。 私は誰かに、それが機能ではなくプロパティであることに気付くのに40分かかったと言ってもらいました。 おそらく動詞でもあるからでしょう。

RayCast.targetどうですか？

@ razcore-art最近、レイキャスティングにsegmentという単語を使用して説明したので、理にかなっていると思います。 ただし、これはdirectionおよびlengthと書き直すこともできるため、幾何学的に言えば、実際にはセグメントではなく光線に近いものになります（または共存できる代替プロパティを提供するだけです）。 。 問題は、インスペクターで正規化された方向ベクトルを簡単に設定する方法がないことです。 少なくとも2D用に1つ作成する提案を書きました：godotengine / godot-proposals＃397ですが、おそらくそれは行き過ぎです。

編集：さらに考えてみると、 segmentはRayCastノードに関してはあまり意味がありませんが、 Physics2DDirectSpaceState.intersect_ray()に関しては意味があります。

RayCast.targetどうですか？

@nathanfrankeターゲットはNodeまたはNodePathと想定します。 したがって、少なくともこれはRayCast.target_positionなる可能性があります。 たぶんRayCast.cast_positionまたはRayCast.cast_offset 。 レイキャストは回転できることを忘れないでください。これにより、グローバル座標で実際のキャスト位置がシフトする可能性があります。

PhysX APIは、レイキャストを構成するためのユニットの方向と長さについての私の考えを確認します。 😛

そうは言っても、私はcast_position傾いています...レイキャスティングの仕組みを書き直すには、より多くのコアの変更が必要になるためです。

@Xrayezプロパティの先頭に「cast」という単語を使用することは避けます。これは、名詞「cast」ではなく動詞「cast」として自然に読み取るため、 cast_positionはない可能性が高いためです。これがプロパティであり、メソッドではないことを知らないという元の問題を解決しました（ cast_positionが位置にキャストするメソッドであると簡単に推測できます）。 私はtarget_position好きです。

https://github.com/godotengine/godot/issues/19325#issuecomment -394155128から：

KEY_BACK名前をKEY_MEDIA_BACK 、 KEY_FORWARD名前をKEY_MEDIA_FORWARDます。 MEDIAプレフィックスを使用できる他のメディアキーが存在する可能性があります。

String begins_with()をstarts_with()変更することを検討する必要があります。

Java、C＃、Python、JavaScriptなどではそのようになっています。

Bugsquad編集： https ： //github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool 、 float 、 intは、名前が小文字で始まる唯一のタイプ/クラスです。 （GDScriptで） Bool 、 Float 、 Intに名前を変更する必要があると思います。 これにより、タイプ構文の強調表示が正しくないという問題が自動的に修正されます。

また、 bool 、 float 、 intは、 @ GDScriptページのlenとstrも含まれます）

状況はstr / Stringと似ていることに注意してください： str(x)とString(x)は同じ結果になります。

追加。 次のようになっているはずです。

# `Int` is type.
func get_key() -> Int:
    # `int` is Python-like function.
    return int(config.get_value("sect", "key"))

@dalexeevプリミティブ型であるため、小文字です。 これは他のほとんどの言語で表示されます。
Nodeようなクラスは参照型であり、割り当て時にコピーされません。

var a := Node2D()
var b = a
a.position = Vector2(2, 2)
print(b.position) # (2, 2)

どちらかといえば、 String名前をstring変更することを検討する必要があります。これは、 Stringは変更可能ではなく、 Nodeと言うよりもintと同様に動作するためです。

Vector2 、 Vector3などにも当てはまるので、今のところこれを編集します。

@nathanfranke異なる言語では、それは異なります。 たとえば、Kotlin、Haxeでは、すべてのタイプのAda名が大文字になっています。

さらに、原始性は条件付きの概念です。 私にとって、 String 、 Color 、 Vector2などは、特に参照ではなく値によって渡されるため、プリミティブ型です。

唯一の障害は、下位互換性の違反です。

Stringは変更できないため

驚いたことに、GDScriptの文字列は変更可能です。

var s = "abc"
s[0] = "xyz"
print(s) # xyzbc

Vector2は、2つのfloat構成されているため、プリミティブではありません。 ただし、 Vector2とfloatは組み込みのバリアントタイプです。

@Zylannそれはタイプ名に反映されるべきであるという根本的な違いですか？

（私にとって、「プリミティブ」は「ワンピース」ではなく「シンプル」です。）

私はこれを私に有利に解釈したくありませんが、：

プリミティブ型の名前は大文字になります。 ：笑顔：

私が理解している用語は次のとおりです。

| タイプ名| プリミティブ型| 値のタイプ| 可変タイプ| ビルトインタイプ|
| ------------- | ------------- | ------------- | ------------- | ------------- |
| int | はい| はい| 該当なし| はい|
| Vector2 | いいえ| はい| 該当なし| はい|
| ノード| いいえ| いいえ| はい| はい|
| 文字列| いいえ| いいえ| いいえ| はい|

とにかく、これらの名前は変更されません。 それらはそのままで問題なく、さまざまな言語のプログラマーに馴染みがあります。 このトラッカーが無意味な議論でいっぱいになるのを避けるために、ここで議論を終了する必要があります。

可変タイプの列が間違っています。オブジェクトから派生したもの、辞書、および配列のみが可変です。 （ Vector2は、 vec2.x = 0実行できるため、変更可能に見えるかもしれませんが、実際にはvec2 = vec2.with_x(0)ように変換されます）

ShortCut名前をShortcut

以下の方法を変更する必要があります
間の矛盾

Input.is_action_just_pressed(action: String) -> bool
Input.is_action_just_released(action: String) -> bool
Input.is_action_pressed(action: String) -> bool

に

Input.is_action_pressed(action: String, allow_echo: bool = false) -> bool
Input.is_action_released(action: String) -> bool

との一貫性のために
と

InputEvent.is_action_pressed(action: String, allow_echo: bool = false) -> bool
InputEvent.is_action_released(action: String) -> bool

修正する必要があります。

PS私は「類似した方法が少ないほど良い」という原則から進んだ。

@dalexeevブールパラメータは、 trueとfalseコンテキストがないため、多くの場合、異なるメソッドを使用するよりも読みにくくなります。

ええ、でも一貫性もいいでしょう。 次に、InputEventのブールパラメータを削除しますか？

@Calinouほとんどの場合、エコーイベントをチェックする必要はありません。

これは大きな問題ではないと思います。 コードを入力すると、引数のヒントが表示されます。 コードを読むときは、Shift + Clickを使用できます。 頻繁に使用される関数の引数はすぐに覚えられます（たとえば、 String.split ）。

さらに、208個のオプションのブール引数がdoc/classesディレクトリで見つかりました（これはコアのみであり、16個のモジュールにもネストされたディレクトリdoc_classes ）。

AcceptDialog.xml

17:         <argument index="1" name="right" type="bool" default="false">

AnimatedSprite2D.xml

26:         <argument index="1" name="backwards" type="bool" default="false">

AnimationNode.xml

53:         <argument index="5" name="optimize" type="bool" default="true">
74:         <argument index="6" name="optimize" type="bool" default="true">

AnimationPlayer.xml

146:            <argument index="3" name="from_end" type="bool" default="false">
201:            <argument index="1" name="update" type="bool" default="false">
223:            <argument index="0" name="reset" type="bool" default="true">

Animation.xml

349:            <argument index="2" name="exact" type="bool" default="false">

Array.xml

130:            <argument index="1" name="before" type="bool" default="true">
146:            <argument index="3" name="before" type="bool" default="true">
172:            <argument index="0" name="deep" type="bool" default="false">
366:            <argument index="3" name="deep" type="bool" default="false">

AStar2D.xml

79:         <argument index="2" name="bidirectional" type="bool" default="true">
114:            <argument index="1" name="include_disabled" type="bool" default="false">
276:            <argument index="1" name="disabled" type="bool" default="true">

AStar.xml

74:         <argument index="2" name="bidirectional" type="bool" default="true">
94:         <argument index="2" name="bidirectional" type="bool" default="true">
113:            <argument index="2" name="bidirectional" type="bool" default="true">
131:            <argument index="1" name="include_disabled" type="bool" default="false">
293:            <argument index="1" name="disabled" type="bool" default="true">

Camera3D.xml

15:         <argument index="0" name="enable_next" type="bool" default="true">

CanvasItem.xml

274:            <argument index="2" name="filled" type="bool" default="true">
376:            <argument index="4" name="transpose" type="bool" default="false">
403:            <argument index="4" name="transpose" type="bool" default="false">
411:            <argument index="8" name="clip_uv" type="bool" default="true">

ClassDB.xml

55:         <argument index="1" name="no_inheritance" type="bool" default="false">
66:         <argument index="1" name="no_inheritance" type="bool" default="false">
88:         <argument index="1" name="no_inheritance" type="bool" default="false">
110:            <argument index="1" name="no_inheritance" type="bool" default="false">
134:            <argument index="2" name="no_inheritance" type="bool" default="false">

CodeHighlighter.xml

19:         <argument index="3" name="p_line_only" type="bool" default="false">

Color.xml

251:            <argument index="0" name="with_alpha" type="bool" default="true">

Control.xml

586:            <argument index="2" name="keep_margin" type="bool" default="false">
588:            <argument index="3" name="push_opposite_anchor" type="bool" default="true">
605:            <argument index="3" name="push_opposite_anchor" type="bool" default="false">
629:            <argument index="1" name="keep_margins" type="bool" default="false">
720:            <argument index="1" name="keep_margins" type="bool" default="false">
758:            <argument index="1" name="keep_margins" type="bool" default="false">
779:            <argument index="1" name="keep_margins" type="bool" default="false">

CryptoKey.xml

26:         <argument index="1" name="public_only" type="bool" default="false">
38:         <argument index="1" name="public_only" type="bool" default="false">
49:         <argument index="1" name="public_only" type="bool" default="false">
59:         <argument index="0" name="public_only" type="bool" default="false">

Curve2D.xml

121:            <argument index="1" name="cubic" type="bool" default="false">

Curve3D.xml

145:            <argument index="1" name="cubic" type="bool" default="false">
158:            <argument index="1" name="apply_tilt" type="bool" default="false">

Dictionary.xml

89:         <argument index="0" name="deep" type="bool" default="false">

Directory.xml

127:            <argument index="0" name="skip_navigational" type="bool" default="false">
129:            <argument index="1" name="skip_hidden" type="bool" default="false">

DisplayServer.xml

647:            <argument index="2" name="multiline" type="bool" default="false">

EditorInterface.xml

212:            <argument index="1" name="with_preview" type="bool" default="true">

EditorNode3DGizmoPlugin.xml

40:         <argument index="3" name="cancel" type="bool" default="false">
60:         <argument index="1" name="billboard" type="bool" default="false">
73:         <argument index="2" name="on_top" type="bool" default="false">
88:         <argument index="2" name="billboard" type="bool" default="false">
90:         <argument index="3" name="on_top" type="bool" default="false">
92:         <argument index="4" name="use_vertex_color" type="bool" default="false">

EditorNode3DGizmo.xml

37:         <argument index="2" name="billboard" type="bool" default="false">
39:         <argument index="3" name="secondary" type="bool" default="false">
53:         <argument index="2" name="billboard" type="bool" default="false">
66:         <argument index="1" name="billboard" type="bool" default="false">
103:            <argument index="2" name="cancel" type="bool" default="false">

EditorProperty.xml

30:         <argument index="3" name="changing" type="bool" default="false">

Expression.xml

36:         <argument index="2" name="show_error" type="bool" default="true">

File.xml

211:            <argument index="0" name="allow_objects" type="bool" default="false">
439:            <argument index="1" name="full_objects" type="bool" default="false">

Font.xml

47:         <argument index="5" name="outline" type="bool" default="false">

GIProbe.xml

19:         <argument index="1" name="create_visual_debug" type="bool" default="false">

HTTPClient.xml

32:         <argument index="2" name="use_ssl" type="bool" default="false">
34:         <argument index="3" name="verify_host" type="bool" default="true">

HTTPRequest.xml

110:            <argument index="2" name="ssl_validate_domain" type="bool" default="true">

ImageTexture.xml

43:         <argument index="1" name="immediate" type="bool" default="false">

Image.xml

226:            <argument index="0" name="renormalize" type="bool" default="false">
415:            <argument index="0" name="square" type="bool" default="false">
433:            <argument index="1" name="grayscale" type="bool" default="false">

ImmediateGeometry3D.xml

24:         <argument index="3" name="add_uv" type="bool" default="true">

InputEvent.xml

54:         <argument index="1" name="allow_echo" type="bool" default="false">

Input.xml

40:         <argument index="1" name="update_existing" type="bool" default="false">

InstancePlaceholder.xml

16:         <argument index="0" name="replace" type="bool" default="false">
33:         <argument index="0" name="with_order" type="bool" default="false">

ItemList.xml

19:         <argument index="1" name="selectable" type="bool" default="true">
32:         <argument index="2" name="selectable" type="bool" default="true">
58:         <argument index="1" name="exact" type="bool" default="false">
235:            <argument index="1" name="single" type="bool" default="true">

JavaScript.xml

18:         <argument index="1" name="use_global_execution_context" type="bool" default="false">

JSONRPC.xml

59:         <argument index="1" name="recurse" type="bool" default="false">

JSON.xml

28:         <argument index="2" name="sort_keys" type="bool" default="false">

KinematicBody2D.xml

78:         <argument index="1" name="infinite_inertia" type="bool" default="true">
80:         <argument index="2" name="exclude_raycast_shapes" type="bool" default="true">
82:         <argument index="3" name="test_only" type="bool" default="false">
96:         <argument index="2" name="stop_on_slope" type="bool" default="false">
102:            <argument index="5" name="infinite_inertia" type="bool" default="true">
125:            <argument index="3" name="stop_on_slope" type="bool" default="false">
131:            <argument index="6" name="infinite_inertia" type="bool" default="true">
145:            <argument index="2" name="infinite_inertia" type="bool" default="true">

KinematicBody3D.xml

80:         <argument index="1" name="infinite_inertia" type="bool" default="true">
82:         <argument index="2" name="exclude_raycast_shapes" type="bool" default="true">
84:         <argument index="3" name="test_only" type="bool" default="false">
98:         <argument index="2" name="stop_on_slope" type="bool" default="false">
104:            <argument index="5" name="infinite_inertia" type="bool" default="true">
127:            <argument index="3" name="stop_on_slope" type="bool" default="false">
133:            <argument index="6" name="infinite_inertia" type="bool" default="true">
158:            <argument index="2" name="infinite_inertia" type="bool" default="true">

Marshalls.xml

35:         <argument index="1" name="allow_objects" type="bool" default="false">
65:         <argument index="1" name="full_objects" type="bool" default="false">

Navigation2D.xml

43:         <argument index="2" name="optimize" type="bool" default="true">

Navigation3D.xml

46:         <argument index="2" name="use_collision" type="bool" default="false">
65:         <argument index="2" name="optimize" type="bool" default="true">

NavigationServer3D.xml

209:            <argument index="3" name="use_collision" type="bool" default="false">

Node2D.xml

63:         <argument index="1" name="scaled" type="bool" default="false">
74:         <argument index="1" name="scaled" type="bool" default="false">

Node.xml

126:            <argument index="1" name="legible_unique_name" type="bool" default="false">
146:            <argument index="1" name="legible_unique_name" type="bool" default="false">
159:            <argument index="1" name="persistent" type="bool" default="false">
189:            <argument index="1" name="recursive" type="bool" default="true">
191:            <argument index="2" name="owned" type="bool" default="true">
540:            <argument index="2" name="parent_first" type="bool" default="false">
599:            <argument index="1" name="keep_data" type="bool" default="false">
737:            <argument index="1" name="recursive" type="bool" default="true">

Object.xml

378:            <argument index="1" name="reversed" type="bool" default="false">

OS.xml

73:         <argument index="2" name="blocking" type="bool" default="true">
77:         <argument index="4" name="read_stderr" type="bool" default="false">
141:            <argument index="0" name="utc" type="bool" default="false">
150:            <argument index="0" name="utc" type="bool" default="false">
303:            <argument index="0" name="utc" type="bool" default="false">
451:            <argument index="0" name="short" type="bool" default="false">

PacketPeerDTLS.xml

17:         <argument index="1" name="validate_certs" type="bool" default="true">

PacketPeer.xml

36:         <argument index="0" name="allow_objects" type="bool" default="false">
57:         <argument index="1" name="full_objects" type="bool" default="false">

PCKPacker.xml

33:         <argument index="0" name="verbose" type="bool" default="false">

PhysicsDirectSpaceState2D.xml

62:         <argument index="4" name="collide_with_bodies" type="bool" default="true">
64:         <argument index="5" name="collide_with_areas" type="bool" default="false">
89:         <argument index="5" name="collide_with_bodies" type="bool" default="true">
91:         <argument index="6" name="collide_with_areas" type="bool" default="false">
107:            <argument index="4" name="collide_with_bodies" type="bool" default="true">
109:            <argument index="5" name="collide_with_areas" type="bool" default="false">

PhysicsDirectSpaceState3D.xml

63:         <argument index="4" name="collide_with_bodies" type="bool" default="true">
65:         <argument index="5" name="collide_with_areas" type="bool" default="false">

PhysicsServer2D.xml

21:         <argument index="3" name="disabled" type="bool" default="false">
351:            <argument index="3" name="disabled" type="bool" default="false">

PhysicsServer3D.xml

21:         <argument index="3" name="disabled" type="bool" default="false">
351:            <argument index="3" name="disabled" type="bool" default="false">
426:            <argument index="1" name="init_sleeping" type="bool" default="false">

PopupMenu.xml

36:         <argument index="2" name="global" type="bool" default="false">
70:         <argument index="3" name="global" type="bool" default="false">
118:            <argument index="3" name="global" type="bool" default="false">
133:            <argument index="3" name="global" type="bool" default="false">
195:            <argument index="2" name="global" type="bool" default="false">
219:            <argument index="2" name="global" type="bool" default="false">
526:            <argument index="2" name="global" type="bool" default="false">

ProjectSettings.xml

93:         <argument index="1" name="replace_files" type="bool" default="true">

Rect2.xml

146:            <argument index="1" name="include_borders" type="bool" default="false">

RenderingDevice.xml

29:         <argument index="4" name="sync_with_draw" type="bool" default="true">
413:            <argument index="3" name="arg3" type="bool" default="false">
493:            <argument index="1" name="allow_cache" type="bool" default="true">
565:            <argument index="6" name="sync_with_draw" type="bool" default="false">
591:            <argument index="9" name="sync_with_draw" type="bool" default="false">
677:            <argument index="2" name="sync_with_draw" type="bool" default="false">
691:            <argument index="3" name="sync_with_draw" type="bool" default="false">

RenderingServer.xml

847:            <argument index="0" name="swap_buffers" type="bool" default="true">
1812:           <argument index="3" name="color_format" type="bool" default="false">
1814:           <argument index="4" name="custom_data_format" type="bool" default="false">
2455:           <argument index="3" name="use_filter" type="bool" default="true">
2557:           <argument index="2" name="is_2d_skeleton" type="bool" default="false">

ResourceLoader.xml

61:         <argument index="2" name="no_cache" type="bool" default="false">
100:            <argument index="2" name="use_sub_threads" type="bool" default="false">

Resource.xml

24:         <argument index="0" name="subresources" type="bool" default="false">

RigidBody2D.xml

106:            <argument index="1" name="infinite_inertia" type="bool" default="true">

SceneState.xml

142:            <argument index="1" name="for_parent" type="bool" default="false">

SceneTree.xml

65:         <argument index="1" name="pause_mode_process" type="bool" default="true">

ScriptCreateDialog.xml

25:         <argument index="2" name="built_in_enabled" type="bool" default="true">
27:         <argument index="3" name="load_enabled" type="bool" default="true">

Script.xml

107:            <argument index="0" name="keep_state" type="bool" default="false">

Skeleton3D.xml

238:            <argument index="3" name="persistent" type="bool" default="false">

SkeletonIK3D.xml

25:         <argument index="0" name="one_time" type="bool" default="false">

StreamPeerSSL.xml

33:         <argument index="1" name="validate_certs" type="bool" default="false">

StreamPeer.xml

128:            <argument index="0" name="allow_objects" type="bool" default="false">
274:            <argument index="1" name="full_objects" type="bool" default="false">

String.xml

587:            <argument index="0" name="with_prefix" type="bool" default="false">
855:            <argument index="1" name="allow_empty" type="bool" default="true">
924:            <argument index="1" name="allow_empty" type="bool" default="true">
947:            <argument index="1" name="allow_empty" type="bool" default="true">
957:            <argument index="0" name="left" type="bool" default="true">
959:            <argument index="1" name="right" type="bool" default="true">

SurfaceTool.xml

216:            <argument index="0" name="flip" type="bool" default="false">

TextEdit.xml

61:         <argument index="1" name="adjust_viewport" type="bool" default="true">
73:         <argument index="1" name="adjust_viewport" type="bool" default="true">
75:         <argument index="2" name="can_be_hidden" type="bool" default="true">

Texture2D.xml

23:         <argument index="3" name="transpose" type="bool" default="false">
50:         <argument index="4" name="transpose" type="bool" default="false">
77:         <argument index="4" name="transpose" type="bool" default="false">
89:         <argument index="10" name="clip_uv" type="bool" default="true">

TileMap.xml

137:            <argument index="1" name="ignore_half_ofs" type="bool" default="false">
153:            <argument index="3" name="flip_x" type="bool" default="false">
155:            <argument index="4" name="flip_y" type="bool" default="false">
157:            <argument index="5" name="transpose" type="bool" default="false">
183:            <argument index="2" name="flip_x" type="bool" default="false">
185:            <argument index="3" name="flip_y" type="bool" default="false">
187:            <argument index="4" name="transpose" type="bool" default="false">

TileSet.xml

323:            <argument index="3" name="one_way" type="bool" default="false">

TreeItem.xml

22:         <argument index="3" name="disabled" type="bool" default="false">
205:            <argument index="0" name="wrap" type="bool" default="false">
229:            <argument index="0" name="wrap" type="bool" default="false">
439:            <argument index="2" name="just_outline" type="bool" default="false">
567:            <argument index="4" name="expr" type="bool" default="false">

UndoRedo.xml

103:            <argument index="0" name="increase_version" type="bool" default="true">

Viewport.xml

117:            <argument index="1" name="in_local_coords" type="bool" default="false">
165:            <argument index="1" name="in_local_coords" type="bool" default="false">

if e.is_action_pressed("ui_left", allow_echo = true):
    velocity += Vector2.LEFT

var arr = s.split(",", allow_empty = false)

@dalexeevは、スクロールを簡単にするためにスポイラーに入れることを検討できますか？

@dalexeevキーが押されたばかりかどうかだけでなく、キーが押されたかどうかを確認する必要がある場合が多くあります。 たとえば、キャラクターを移動するためのスクリプトは、WASDまたは矢印キーを使用してこれを行う必要があります。 ほとんどすべてのゲームで入力を処理する必要があるので、これらの方法を2つだけ持つのは無駄ではないと思います。

コードを読むときは、Shift + Clickを使用できます。

GitHubで差分を表示している場合は違います。 コードがIDEを読み取り可能にする必要がある場合、それは適切なコードではありません。

@aaronfranke他の207のケースについては、別の関数を作成することもお勧めしますか？ そうでない場合、この議論は決定的なものではありません。 また、パラメータ名を指定できれば、IDEがなくても読めるようになると上記で書きました。

キーを押しただけでなく、キーが押されているかどうかを確認する必要がある場合が多くあります。

多くの場合、ただしエコーがない場合よりも頻繁ではありません。

3つのメソッド（ is_action_just_pressed 、 is_action_just_released 、 is_action_pressed ）の存在は、 is_action_releasedメソッドがあると予想されるため、混乱を招きます。

追加。 少なくとも視覚的には、どちらのオプションが簡単ですか？

is_action_releasedはnot is_action_pressedで実現できます。 これは、 justメソッドには当てはまりません。

上記のように、生のブールは避けるべきです。 INPUT_ALLOW_ECHO / INPUT_NO_ECHOのようなフラグは、ブール値よりもはるかに優れています。

@dalexeevそれは混乱をもたらすだけです。 is_action_pressed()とechoは2つの異なるものです。 is_action_pressed()には遅延がないのに対し、エコーイベントが最初に押してからわずかに遅れて受信されていることを確認できます。

@KoBeWiあなたは正しいかもしれませんそして

is_action_pressed(action: String, allow_echo: bool = false) -> bool

に変更する必要があります

is_action_pressed(action: String, allow_echo: bool = true) -> bool

これはと一致していないので

func _input(e):
    if !e.is_action("ui_left"):
        return
    $Label.text += "pressed: %s, echo: %s\n" % [e.is_pressed(), e.is_echo()]

pressed: True, echo: False
pressed: True, echo: True
pressed: True, echo: True
pressed: True, echo: True
pressed: False, echo: False

@dalexeevあなたが提案することは正しくありません。 エコーイベントについて話すときは、キーを押しながら繰り返されるキーボードイベントについて話します。ここでの用語の使用はほとんど意味がありません。アクションシステムはイベントに直接依存しないため、フレームごとに状態が更新されます。 また、アクションは、「エコー」イベントが存在しないコントローラーやマウスボタンなどの他のデバイスでも機能します。

TreeItemのget_children（）は最初の子のみを返し、名前（またはドキュメントの説明）が示唆するようなすべての子を返すわけではありません。

[編集]
ドキュメントをNvmします。 メソッドの説明がマスターで更新されました。申し訳ありません。

リソースのlocal_to_sceneはlocal_to_instanceまたはunique_per_instanceにすることをお勧めします。 「ローカルからシーン」は、実際にはシーンのインスタンスごとである場合の、シーンに対してローカルとしての動作を示します。

Image.load() → Image.load_from_file()名前を変更します。

1. コードを介してload("image.png")ファイルとの混同の可能性を軽減するのに役立ちます。＃42412のドキュメントの変更を参照してください。
2. Image.load()は、GDScriptの組み込み名として強調表示されなくなります：＃28866。
3. 画像形式ごとにImage.load_*_from_buffer()と一致します。 バッファー関連のメソッドは、APIの肥大化を防ぐために同じインターフェースに統合できる可能性がありますが、それは議論の別のトピックです。

@XrayezGDScriptでloadを削除する価値があるかもしれません： https ：

ProjectSettingsの変数registering_orderおよび関連するメソッドset_registering_orderは使用されていません。

RandomNumberGenerator名前をRandom変更し、 randfやrand_rangeなどのグローバルランダム関数を非推奨にするか削除する必要があります。

ランダムシードが指定されているときに信頼できない関数を呼び出すと、問題が発生する可能性があります

seed(123)
randf()
call_method() # This could change the seed for its own random reasons!
randf()

randfやrand_rangeなどのグローバルランダム関数は非推奨にするか、削除する必要があります。

godotengine / godot-proposals＃1590の一部として議論されています。

私は、これらの基本的なランダムメソッドが、アクセシビリティとプロトタイピングの目的でグローバルスコープにあることを望んでいます。少なくともそれらのいくつかはそうです。 ただし、 seed()とrand_seed()は確実に削除できます。

Callableが追加されてから、 FuncRefが冗長になっているようです。

インスペクターでメソッドproperty_can_revertとproperty_get_revertを見つけ、＃43078で報告しました。 ただし、 _get 、 _set 、および_get_property_listの規則に従うために、先頭にアンダースコアを付けて名前を変更する必要があると思います。

EditorImportPluginとEditorExportPluginは関連しているように見えますが、1つはリソースのインポートに関するもので、もう1つはプロジェクトのエクスポートに関するものです。 EditorImportPlugin名前をEditorResourceImportPluginなどに変更することをお勧めします。

編集：それに応じてEditorPlugin.add_import_plugin名前も変更する必要があります。

なぜResourceImportPluginないのですか？ 多くの（ほとんど？）エディタクラスには、 SceneTreeDockやすべてのアニメーションのように、「エディタ」という単語がまだ含まれていません。

Tracking_statusで列挙ARVRInterface名前に変更する必要がありますTrackingStatus他のenum名のスタイルと一致するように、。

上記のARVRInterface見ると、名前の品質は一般的にかなり劣っています。 これが私の提案された名前変更でもあります：

• ar_is_anchor_detection_enabled → anchor_detection_enabled （プロパティ）
• interface_is_initialized → initialized （プロパティ、セッターがあるため、さらにenabledに書き換えることができます）
• interface_is_primary → primary （プロパティ）
• get_render_targetsize() → get_render_target_size() （メソッド）
• uninitialize() → finalize() （メソッド）

そうでなければ、ドキュメントは間違っています。 🙂

私はこのクラスをまったく使用していませんが、クラスを見るだけでそれらの名前は奇妙に見えることに注意してください。

私たちは、名前を変更する必要がありますControl.MOUSE_FILTER_PASSするControl.MOUSE_FILTER_PASSTHROUGH ？ これにより、イベントがコントロールノードを介してその下にあるノードに渡されることがより明確になります。 ただし、実際に名前を変更する価値があるかどうかはわかりません。

@Calinou痛いとは思わないので、応援させていただきます。 あなたが言ったように、その変更はそのマウスフィルターモードが何をしているのか一目でもう少し明白になるでしょう。

@Calinou現在の動作は異常だと思います。 このシーン設定では、「Click Child2、ClickScene」が生成されます。

（すべて合格に設定されていることに注意してください）

：smile：提案A ：入力イベントは親にのみ送信されるように見えるため、現在の動作ではおそらくControl.MOUSE_FILTER_PASSPARENTSようなものです。

：rocket：命題B ：定数を次のように変更します。

• 停止：現在の動作-イベントを取得し、すべての伝播を停止します
• PASS_PARENT：現在PASSと同じ動作
• PASS_ALL：無視しますが、イベントを取ります
• 無視：現在の動作-イベントを取得しませんが、それでも伝播します

：eyes：命題C ：ノードがGUI入力を受け取るかどうかは、信号を接続できない（またはブールフラグを使用できない）ため、実際には関係ありません。 オプションをControl.propagation_modeして、次の定数を使用できます。

• なし
• 親
• 全て

私の意見では、それはずっときれいに見えるでしょう。

これは名前の変更を超えており、提案として検討する必要があります。

なぜこれらすべての名前変更がとても長いのですか？ 単純で短いものを本当に長いものに変更しています。

入力する時間の2倍の長さのclipをintersectionします。
また、 Control.MOUSE_FILTER_PASSをControl.MOUSE_FILTER_PASSTHROUGH
NS

私は、より単純でより短く、冗長性の少ない変更を好みます。 これは関数名であり、関数の説明でもありません。

私は、より単純でより短く、冗長性の少ない変更を好みます。 これは関数名であり、関数の説明でもありません。

ただし、名前はわかりやすいものにする必要があります。 また、オートコンプリート（Godotエディターに組み込まれている）を利用する場合は、長さは関係ありません。

IRCで一度言及したのですが、返事がありませんでしたが、TextureRectには「ScaleOn Expand（Compat）」というストレッチモードがあります。 これは削除できるもののように聞こえます。

Godotプロジェクト全体で堅牢なコードベースを使用したい場合は、「冗長性が少ない」というメニューは絶対にありません。 最新のコーディングツールは、名前が長い場合でもすばやく入力できるオートコンプリートやその他のインテリジェントな機能を提供します。 さらに、これらの変更についての議論を読むと、それらを使用する開発者にとってこれらの関数のあいまいさを軽減するという目標があります。 短い名前は甘いかもしれませんが、紛らわしく、見つけにくいです。

そして、常に覚えておいてください。コードの入力は、ソフトウェア開発の迅速な部分です。 後でコードを読んで理解することは、はるかに重要です。 それはそれぞれ子供を妊娠し育てるようなものです。

私はあなたの両方に同意しません。 私はGodotユーザーであり、GDScriptが簡潔ですばやく記述できるため、特にGodotを使用しています。 それらを2倍の長さにすると、速度の利点が失われます。これは、2回の書き込みが2倍になり、コードの行全体を水平方向に表示するには2倍スクロールする必要があるためです。

コーディングするときは、信じられないほど長い関数名や変数名を入力したくありません。 これらの提案された変更の変更のいくつかは、他のすべてを犠牲にして「明確さ」のために非常に長い関数と変数名を追加します。 疑問がある場合は、組み込みのヘルプを読むことができます。 プラスプログラミングはAPIを学ぶことです。 名前に関係なく、初めて使用する関数は常に検索します。 Cでprintfを取得するのは簡潔で単純です。 Godotでは、 send_formatted_string_to_standard_out.という名前を付けます。すべての人にAPIの再学習を強制するだけでなく、これらの変更の一部には統一されたビジョンさえありません。 たくさんの人が集まって、それぞれがエンジンの一部を交換したように私には思えます。

アレイを例に取る
remove -> remove_at _atはここに何を追加しますか？ すでにremove_valueがあります。 他に何を削除できますか？
erase -> remove_valueまだ十分に明確ではありません。 ドキュメントから「配列から値の最初の出現を削除します。」 また、配列全体から1つの値を削除できると思われるかもしれません。 わかりやすくするために、実際にはremove_first_occurance_of_valueにする必要があります。これは、この関数が実際に行うことだからです。 そのため、関数を長くし、同じように混乱させるだけ長くしました。

removeとerase 2つの異なる関数がありますが、 removeの同じバリエーションで、余分な文字を使用して両方をオンにします。 ただし、機能は異なります。 Removeは特定のインデックスから削除しますが、eraseは見つかった値の最初のインスタンスを削除します。

これらは、人々にコードの更新を強制する以外は、実際には役に立たないだけです。
反転->反転
複製->クローン
空-> is_empty

壊れていない場合は修正しないでください。

@CarlGustavAlbertDwarfsteinYungですが、2倍入力することはありません。 最初の3文字の後に、autocopletionと入力すると、単語全体を入力するのではなく、必要なものを選択します。

他の名前については、たとえばempty -> is_empty見ると、それが何をするのかを明確にするために変更が必要です。 emptyを見ると、これが何かを空にする方法なのか、何かが空かどうかをチェックする本なのか、それとも他の何かなのかがわかりますか？ is_emptyを使用すると、これが空の場合はtrueであり、空でない場合はfalseであることが一目でわかります。 名前を読むだけで、関数や変数がどのように機能するかを知る必要があります。 emptyような名前でそれを行うことはできません

@ Feniks-ゲーム私はあなたに空かis_emptyが同じように混乱していると言うことができます。

@CarlGustavAlbertDwarfsteinYung emptyは、動詞として読み取られた場合、アクションになる可能性があります。 is_emptyは間違いなく品質です。 もちろん、その混乱はあなたの英語のレベルに依存するかもしれません。

また、関数が最新のコードエディタでsend_formatted_string_to_standard_outと呼ばれていたとしても、必要に応じて、 sfstso 、またはその他の中間文字の組み合わせとして入力できます。オートコンプリートを使用すると、唯一のオプション。

@pycbouh人々はこのエンジンを何年も使用していますか？ そして、このエンジンの最大の問題は何か知っていると言う人が私に来るのを聞いたことがありません。 配列は持っているという事実emptyの代わりにis_empty 。

あなたたちはここに座って、誰も望んでいないことや求めていないことを修正しています。 はい、言い回しは紛らわしいですが、実際には問題ではなく、2015年にこのエンジンを使い始めて以来、問題になったことはありません。提案された変更のいくつかは大歓迎で、公平を期すためにis_を使用します。 空でも大丈夫です。 しかし、いくつかの変更は長すぎて、同様に混乱します。 私はそれらの変更について具体的に話していましたが、すべてではありません。

このメガスレッドの存在全体は、人々がそれを求めている証拠です。 これらの問題はあなたや他の誰かにとっては重要ではないかもしれませんが、名前が間違っているためにAPIを理解するのに問題があります。 そして、これはこの問題が収集するタイプの問題です。 これらの変更の全体的な重要性については、信じられないかもしれませんが、これらの追跡と実装は、他の開発時間を奪うものではありません。

そして、あなたが与えて説明しようとした例を見てください：

Removeは特定のインデックスから削除しますが、eraseは見つかった値の最初のインスタンスを削除します。

あなたはそれを書いて、現在および将来のすべてのGodotユーザーにとって少なくとももう少し明確になるように命名を改善する理由がわかりませんか？

@pycbouhそして実際、私は配列remove_atとremove_value 。 remove_valueは消去の説明と同じではなく、それでも同様に混乱します。 どこから値を削除しますか？ 終わりから値を削除し、最初からrmeove？ 配列から値の出現をすべて削除しますか？

本当に変更が必要な場合は、 removeとremove_first_occurenceを使用してください。これにより、簡潔でわかりやすくなります。

@pycbouh私はそれを求めていません。 このスレッドの存在は、一部の人々が古典的なプログラマーのやり方を破っていないものをエンジニアリングして修正しているためです。 将来のユーザーはどうですか？ 彼らはどう？ 私はかつて将来のユーザーであり、APIを学びました。 関数の命名に問題はありませんでした。 コメントの50％は、提案された変更に同意しない人々です。 これらの変更のほとんどは、少数のコミュニティメンバーがこれらの変更をすべての人にプッシュすることによって推進されているようです。 提案された変更に投票できますか？

実際、ここに提案があります。 APIの命名に変更を加える場合は、寄稿者/寄付者/ユーザーの意見を含める必要があります。 彼ら全員が同意すれば、私も参加しています。 世論調査をして、みんなが何をしているのか見てみましょう。 他の人が何を望んでいるのか推測しようとしないでください。 あなたにとって良いことは、他の誰かにとっては良くないかもしれません。

私は、私が見たものからここで提案された変更の約50％に反対しています。

コメントの50％は、提案された変更に同意しない人々です。

作成した統計をドアに残していただけますか？

提案された変更に投票できますか？

それが議論と反応の目的です。

私は、私が見たものからここで提案された変更の約50％に反対しています。

「私はこのように学んだので、私の後のすべての人に同じように苦しんでもらいたい」という理由だけであなたが彼らに反対しているなら、それは提案の無効な批評であり、無視されるでしょう。

あなたにとって良いことは、他の誰かにとっては良くないかもしれません。

同上。

作成した統計をドアに残していただけますか？

コミュニティ全体についてのこの主張のように？

これらの問題はあなたや他の誰かにとっては重要ではないかもしれませんが、名前が間違っているためにAPIを理解するのに問題があります。

人々が問題を抱えていることをどうやって知るのですか？ あなたは彼らに尋ねましたか？ これについての世論調査や調査、またはアンケートはありましたか？ この情報をどのようにして入手しましたか？

私はそのようなユーザーの1人で、ゼロから始めてAPIを学びました。 ネーミングに問題はありませんでした。 すべてのAPIには、いくつかの奇妙な命名規則があります。 コードで記述できるように、すべての関数はやや簡潔にする必要があります。

@pycbouhここでのすべての命名の提案が良いことを私に納得させようとしているのなら、私はあなたに敬意を表して反対しなければなりません。 これは変更について議論するスレッドであり、提案された変更のいくつかは、必要である/要求されるだけでなく、より長く、等しく混乱するものであると私はここに言います。 確かに良いものもあり、大歓迎です。 コミュニティ全体でAPI名に問題があると考えている人がいるからといって、すべての名前をまとめて変更するわけではありません。 私は持っていなかったし、持っていなかったし、私は初心者として始めました。 そして、私はどちらもしない他の少数の人々を知っています。 これらの変更のいくつかは重要であり、完全なリリースの前に、コミュニティ全体または少なくとも寄稿者によるピアレビューが必要であると私は信じています。

人々が問題を抱えていることをどうやって知るのですか？ あなたは彼らに尋ねましたか？

このスレッドのエントリのほとんどは、GitHubで（この場合は問題がリンクされています）、他のコミュニティや個人のチャネルを使用して、問題を抱えている人々によって生み出されます。 エンジンで名前を変更する他の関数やプロパティについて考える以外に何もすることがないので、ここに座って自分のプライベートパーツを舐めていると思い込まないでください。

その上、ここで提案された変更の多くは実行されておらず、PRやその他の活動はありませんでした。 それらはリストされており、それだけです。 PRに注目し、問題が発生した場合は、遠慮なくコメントしてください。 その後、変更を承認してマージするのはGodotのPM次第です。 建設的であり、いくつかの不要な変更を防ぐことができますが、あなた自身がかつて言ったことを忘れないでください：

あなたにとって良いことは、他の誰かにとっては良くないかもしれません。

したがって、この時点までAPIに問題がなかったとしても、他の人が問題を抱えていなかった、または将来問題が発生しないという意味ではありません。

すべてのAPIには、いくつかの奇妙な命名規則があります。

話すべき慣習があれば、それは良いことです。 しかし、GodotのAPIのいくつかは、オープンソースになるずっと前に名前が付けられており、思ったほど考え抜かれていない可能性があります。 繰り返しになりますが、ここの人々がその全体の変更を提案していると思い込まないようにお願いします。

ここではこのような議論はしないでください。 特定のAPIの変更について話し合いたい場合は問題ありませんが、ここでの提案が気に入らないという包括的なステートメントは役に立ちません。

コア開発者は、これらの提案を1つずつ確認します。 多くの人が受け入れられなくなる可能性があります。

一時的にロックします。後でロックを解除します。

次の点をリストに追加してもらえますか？

• AnimationPlayer ： stop()名前をpause() （https://github.com/godotengine/godot/issues/16863#issuecomment-562363660、godotengine / godot-proposals＃287）
• AnimatedSprite ： stop()名前をpause() （＃31168） （すでに追加されています）
• AnimatedSprite3D ： stop()名前をpause() （＃31168）に変更（追加済み）
• Tween ： stop()名前をpause() 、 stop_all()をpause_all() （PR＃41794、＃43442）

トゥイーン：stop（）の名前をpause（）に、stop_all（）の名前をpause_all（）に変更します（＃43442）

これは＃41794でカバーされています

@ opl-これについてもここで説明します： https ：

これらのグローバルスコープのRNG関数が何をするかを明確にする可能性のあるいくつかの名前変更：

• seed() -> set_seed() （RandomNumberGeneratorと一致するようにget_seed()も追加する可能性があります）–現在、これがセッター関数であるかどうかは明らかではありません。
• rand_seed() -> rand_from_seed() –現在、提供されたシードに基づいて実際に乱数を与える場合、シードなどをランダム化する可能性があるようです。

rand_seed（）-> rand_from_seed（）–現在、提供されたシードに基づいて実際に乱数を与える場合、シードなどをランダム化する可能性があるようです。

シードをランダム化することを除いて。 ドキュメントを読んでください。

rand_seed（）-> rand_from_seed（）–現在、提供されたシードに基づいて実際に乱数を与える場合、シードなどをランダム化する可能性があるようです。

シードをランダム化することを除いて。 ドキュメントを読んでください。

ごめん。 私が意味したのは、シードをランダム化するだけのように聞こえるということです。 intを返すので、おそらくrand_int_from_seed()である必要がありますか？ 実際、ドキュメントでは、返されるタイプは指定されておらず、「乱数」についてのみ言及されています。 それはintですか？

それで、あなたがそれを渡すシードに基づいて新しいシードを生成し、次にその新しいシードに基づいて新しい番号を生成しますか？ 名前の変更についてはわかりませんが、それが起こっている場合は、説明でいくつかの手直しを使用できます。

このメソッドを2つの小さなメソッドに分割する必要があるように思われる場合は、名前を変更するのではなく、1つのことを実行します。

Control :: pending_resize

未使用。

Object::is_class(name) → Object::inherits_class(name) 。

このメソッドはGDScript is （ extends btw）とほぼ同等であることがわかりましたが、C ++ではより明確にする必要があります。

私が遭遇した混乱は、特定のオブジェクトなし）であるかどうかをチェックすることです。

// Use case: we're only interested in editing "Node2D" classes directly.
node = Object::cast_to<Node2D>(p_edited);
if (!node) {
    return;
}
if (node->get_class() != "Node2D") {
    return; // OK, any class other than "Node2D" is not edited.
}
// vs.
if (!node->is_class("Node2D")) {
    return; // ERROR: derived classes like "Sprite" will also be edited...
}

基盤となる実装では、あらゆる場所で「継承」マクロ/テンプレートを使用しているため、これをinherits_classに名前変更するのは理にかなっています。

https://github.com/godotengine/godot/issues/21461#issuecomment-416155187も参照して

get_class()とis_class()は一般的に私を混乱させます