Terlalu membosankan bagi saya, tapi Insya Allah siapa pun yang memperbaiki instance sebagai instantiate mana digunakan sebagai kata kerja.

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(nilai) -> Control.set_rect_min_size(nilai)
Control.get_custom_minimum_size() -> Control.get_rect_min_size

Ada banyak lagi di kelas Kontrol, get/set semuanya harus memiliki nama yang sama dengan variabel, menjengkelkan untuk memeriksa dok setiap kali Anda mengetahui nama variabel.

Kelas TileMap memiliki banyak metode pengambil dan penyetel yang tidak sesuai dengan propertinya masing-masing. Sebenarnya saya menyarankan mengganti nama sebagian besar getter dan setter di kelas itu, jadi mereka setuju dengan properti mereka serta penamaan di kelas lain.

Animation.track_remove_key_at_position seharusnya
Animation.track_remove_key_at_time

Metode

• OS : execute harus dibagi dalam dua metode yang berbeda, satu memblokir dan yang lainnya non-blokir.
  misalnya nama: execute / exec_process (memblokir) dan spawn_process (tidak memblokir) #19302

LineEdit memiliki parameter new_text pada "text_changed" tetapi TextEdit tidak.

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

Saya ingin jika VBoxContainer/HBoxContainer/GridContainer diubah namanya menjadi VBox/HBox/Grid sederhana...

Dan nanti akan di rename lagi karena terlalu pendek seperti pos->posisi :D

Mereka agak panjang Anda benar.

Saya perhatikan bahwa Godot saat ini memiliki dua konvensi penamaan yang berbeda dalam nama metodenya.

Terkadang, ini mengikuti konvensi umum yang dapat ditemukan di API bahasa seperti C# atau Java, seperti [action][object]() form: yaitu)

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

Namun, di tempat lain, ini mengikuti konvensi yang berbeda dari [prefix][action][object]() , seperti:

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

Mereka hanyalah beberapa contoh dari banyak contoh.

Jika kita mampu melakukan perubahan besar-besaran yang melanggar kompatibilitas di masa mendatang, saya ingin melihat mereka dapat diganti namanya untuk mengikuti konvensi penamaan tunggal yang terdefinisi dengan baik (semoga yang pertama, karena lebih sering digunakan baik di dalam maupun di luar Godot).

Namun, di tempat lain, ini mengikuti konvensi yang berbeda dari [prefix][action][object]() , seperti:

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

Saya tidak memeriksa ulang semua penggunaan, tetapi dari apa yang saya lihat gaya penamaan metode ini, meskipun agak canggung, juga mengikuti konvensi tertentu. Misalnya metode 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">

"Awalan" mengacu pada argumen pertama, dan bagian setelah get adalah apa yang sebenarnya akan Anda dapatkan di awalan itu. Misalnya, shape_owner_get_shape_index(owner_id, shape_id) secara konseptual mirip dengan get_shape_owner(owner_id)->get_shape_index(shape_id) , tetapi tidak ada ShapeOwner terpapar ke API skrip, oleh karena itu "jalan pintas" ini.

Cerita yang sama untuk metode 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">

Atau metode *node_get di ATP:

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

Saya telah memperbarui OP dengan sebagian besar saran yang diberikan sejauh ini.

Saya ingin jika VBoxContainer/HBoxContainer/GridContainer diubah namanya menjadi VBox/HBox/Grid sederhana

Saya tidak yakin, di Godot kami mencoba memberikan semua nama eksplisit, dan misalnya Grid tidak memberi tahu saya bahwa itu adalah sebuah Container. Untuk VBox dan HBox orang dapat berargumen bahwa kotak adalah wadah menurut definisi, tetapi karena kami memiliki BoxContainer yang tidak sama dengan Container , saya pikir verbositas masih dibenarkan.

LineEdit memiliki parameter new_text pada "text_changed" tetapi TextEdit tidak.

Saya tidak berpikir akan berguna untuk menambahkan new_text ke TextEdit. Di LineEdit, itu hanya berisi seluruh teks LineEdit, bukan teks yang berubah, jadi saya bahkan berpendapat bahwa itu tidak boleh ada di text_changed LineEdit. Namun, lebih umum jika Anda ingin menggunakan teks lengkap dari LineEdit pada input, daripada melakukan sesuatu dengan teks lengkap dari TextEdit multibaris saat karakter baru ditekan.

@akien-mga

Saya tidak memeriksa ulang semua penggunaan, tetapi dari apa yang saya lihat gaya penamaan metode ini, meskipun agak canggung, juga mengikuti konvensi tertentu

Saya menyadari fakta bahwa itu adalah konvensi penamaan sendiri. Tapi itu masih bukan sesuatu yang umum digunakan di luar Godot, dan juga agak membingungkan karena terkadang kata yang sama seperti BlendShape digunakan dalam metode yang mengikuti dua konvensi penamaan yang berbeda.

Secara pribadi, saya ingin melihat mereka semua berganti nama menjadi GetPrefix* dan SetPrefix* untuk konsistensi, tetapi mungkin orang lain mungkin memiliki pendapat yang berbeda tentang hal itu.

Metode berubah di #16757. Urutan argumen lebih masuk akal, tetapi merusak kompatibilitas API antara 3.0 dan 3.1 (#19648).

Saya akan menaikkan #9128 lagi: translation dalam 3D vs position dalam 2D ​​adalah perbedaan yang aneh.
Itu dinaikkan usia sebelum 3.0 tetapi ditutup setelah 3.0 keluar karena... 3.0 sedang keluar.

OS.execute harus menggunakan posix_spawn .

Yang lain mungkin mengganti nama "margin" menjadi "offset" untuk node kontrol.
Karena margin negatif di sisi kanan, ini menyesatkan orang, terutama ketika membandingkan dengan StyleBox

@groud Saya merasa offset terlalu umum, margin dulu adalah kata yang benar karena tidak berorientasi negatif di sisi kanan saat pertama kali diperkenalkan

@groud Saya merasa offset terlalu umum, margin adalah istilah yang baik (dan tidak negatif ketika pertama kali diperkenalkan)

Nah, margin menyesatkan sekarang karena mereka negatif. Offset bersifat umum, tetapi lebih masuk akal. Saya tidak berpikir itu masalah bahwa mereka generik karena dalam konteks node kontrol.
Pokoknya saya terbuka untuk saran yang lebih baik. Saya hanya ingin membuang ide ini di sini karena perubahan nama properti seperti itu telah disarankan. Lihat di sini misalnya.

Ukuran kotak/kubus diberi nama secara tidak konsisten.
BoxShape untuk tabrakan menggunakan luasan.
CubeMesh memiliki properti ukuran dengan x, y dan z, yang masing-masing setengah dari luasan.
CSGBox memiliki properti Width, Height dan Depth yang didefinisikan seperti ukuran x, y dan z di CubeMesh.

Selain properti ukuran, terkadang "Kubus" digunakan dan terkadang "Kotak" digunakan. Masuk akal untuk menggunakan "Kotak" untuk semuanya karena x, y dan z untuk CubeMesh dapat diatur secara independen dan dengan demikian juga merupakan sebuah kotak.

Karena kami memiliki misalnya HTML5 dan UWP sebagai target, yang sebenarnya bukan sistem operasi, saya mengusulkan untuk mengganti nama OS menjadi Platform (PlatformWindows, PlatformUnix,...).
Masuk akal dengan pemisahan OS/Tampilan juga.

Dari #20228 ini, Label.clip_text tidak diperlukan lagi. Saya percaya itu sama untuk Button.clip_text.

Camera2D saat ini memiliki dua properti berbeda yang keduanya bernama offset (Offset reguler dan yang terpisah dalam V dan H) yang merupakan dua hal yang sama sekali berbeda, ini benar-benar membingungkan.

Metode

- Dictionary : erase_checked harus dihapus (metode ini tidak terkena skrip).
- Dictionary : erase harus diubah untuk mengembalikan bool untuk menentukan apakah pasangan dengan kunci yang ditentukan telah dihapus atau tidak (lihat implementasi erase_checked ).

20945

@neikeq Ini bisa dilakukan sekarang IMO, mengubah nilai pengembalian Dictionary.erase dari void menjadi bool seharusnya tidak merusak proyek apa pun.

@akien-mga tapi itu akan merusak kompatibilitas API GDNative, bukan?

@akien-mga Bukankah itu akan merusak kompatibilitas? Apakah kami diizinkan membuat perubahan yang berpotensi membuat skrip 3.1 tidak berfungsi di versi lama seperti 3.0?

@neikeq Ya, skrip 3.1 sudah tidak kompatibel dengan 3.0 ( class_name , banyak perubahan API dengan parameter opsional baru atau properti/metode baru, kelas baru, dll.). Kami hanya mengurus kompatibilitas ke belakang, bukan ke depan.

Oh begitu! Jika itu masalahnya, saya akan membuat perubahan itu sekarang.

Jika saya dapat menambahkan satu ke daftar, node kontrol LineEdit dan TextEdit akan benar-benar mendapat manfaat dari memiliki API yang konsisten satu sama lain sehingga mereka dapat digunakan (kebanyakan) secara bergantian. Saat ini rasanya berantakan mencoba bekerja dengan mereka bersama-sama, sampai pada titik di mana melihat satu simpul membuat saya bingung tentang yang lain.

@eska014 Selain itu, opsi scons sudah platform . Masuk akal untuk menjadi konsisten.

Pengaturan proyek display/window/size/test_width dan test_height harus diubah namanya menjadi window_width dan window_height . Kita juga harus mempertimbangkan untuk mengganti nama pengaturan width dan height , mungkin render_width dan render_height .

Properti dekat dan jauh kamera memiliki nama yang berbeda dari setter/getternya (misalnya set_znear/set_zfar). Ini harus diubah?

znear dan zfar membingungkan. Itu tidak ada hubungannya dengan sumbu Z di ruang dunia. Itu bisa diubah menjadi clip_near dan clip_far karena mereka mengontrol bidang kliping, atau hanya near dan far .

Ya, ada dua cara untuk mengatasi masalah ini.

Kita harus menyingkirkan (atau serius mendiskusikan) ekstensi sumber daya biner.. (RES_BASE_EXTENSION)

gdscript_function.cpp dan gdscript_functions.cpp memiliki nama yang sangat mirip, saya terus mencampuradukkannya. Layak diganti namanya? @vnen

Saya mengubah https://github.com/godotengine/godot/pull/21425 untuk mengganti nama "desimal" menjadi "step_decimals" tetapi tetap menggunakan "desimal" sebagai alias. Dengan asumsi itu digabungkan, kita dapat menghapus "desimal" di kerusakan kompatibilitas berikutnya, jika tidak, cukup ganti nama.

@mysticfall Menurut pendapat saya lebih baik tidak ada kata "dapatkan" di nama metode jika tidak perlu.

Terkadang Anda ingin sebuah properti bisa mendapatkan dan mengatur, tetapi mengontrol akses. Di C#, properti memungkinkan Anda untuk melakukan ini dan mengontrol akses hanya dengan membaca dan menetapkan seolah-olah itu adalah bidang, yang bagus.

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

Namun, dalam GDScript, properti bukanlah sesuatu (?). Kita juga bisa memiliki nama metode tanpa kata get. Sebagian besar metode mengembalikan sesuatu sehingga lebih baik untuk memiliki keteraturan Perhatikan bahwa saya tidak dapat menemukan dokumentasi tentang ini. Saya memang menemukan dokumentasi tentang cara melakukannya di dalam GDScript dengan setget tetapi bagaimana dengan menambahkan melalui C++?

Singkatnya, saya setuju bahwa tidak baik memiliki "get" di tempat yang tidak konsisten, tetapi solusi ideal menurut saya tidak benar-benar mungkin saat ini di properti atau kita bisa menghapus "get" dan tetap "set" .

@aaronfranke GDScript memang memiliki properti dengan cara tertentu, karena kelas mesin dapat mendefinisikan pengambil dan penyetel (atau hanya pengambil) dan mengekspos ke GDScript sebagai properti. Yang mengatakan, saya menentang menghapus get dan set dari metode karena 1) itu membuat nama lebih jelas dan 2) itu membuat perbedaan antara pengambil dan penyetel. Misalnya Mesh.SurfaceFormat() terdengar seperti metode yang "memformat permukaan", dan bukan metode yang "mendapatkan format". Juga, sebagian besar (jika tidak semua) dapat diabaikan dan digunakan sebagai properti.

Sekarang, saya tidak terlalu peduli tentang gdscript_function.cpp dan gdscript_functions.cpp . Satu memiliki kelas GDScriptFunction, yang lain berisi definisi fungsi GDScript, selalu jelas bagi saya yang mana (meskipun saya sudah terbiasa). Ini juga bukan perubahan yang melanggar, jadi tidak perlu di sini.

Ya, GDScript memiliki properti. Properti C# dihasilkan dari ClassDB, dari situlah GDScript mendapatkannya.

Ada beberapa metode untuk RigidBody dan itu adalah kelas terkait yang parameternya harus ditukar untuk konsistensi:

• RigidBody.add_force(force, position) ke add_force(position, force)
• PhysicsDirectBodyState.add_force(force, position) ke add_force(position, force)
• PhysicsServer.body_add_force(force, position) hingga add_force(position, force)

Daftar kelas dan metode

@TGRCdev Saya lebih suka mengubah apply_impulse menjadi (kekuatan, posisi) daripada mengubah add_force menjadi (posisi, kekuatan). Posisi gaya adalah parameter opsional sehingga harus di akhir. Tetapi semua gaya dan impuls harus memiliki vektor gaya.

@aaronfranke Poin yang adil. Dalam hal ini, daftar swap yang diperlukan adalah:

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

@aaronfranke Saya setuju bahwa menggunakan awalan Get- atau Set- adalah semacam 'Javaisme' yang sebaiknya dihindari di C#.

Perhatian utama saya adalah penggunaan 'awalan domain' seperti dalam kasus seperti shape_owner_get_shape atau node_get_input_count , jadi jika kita dapat mengimplementasikannya kembali sebagai properti C# yang tepat tanpa Get- atau Set- awalan, itu akan lebih baik.

Di samping catatan, saya selalu berpikir agak aneh bahwa properti di Godot's C# API memiliki set getter dan setter yang cocok, seperti misalnya, Node.Name dan Node.GetName() / Node.SetName() .

Rasanya agak berlebihan bagi saya, tetapi jika ada alasan mengapa kita mempertahankan konvensi seperti itu, saya kira kita akan mendapatkan NodeInputCount dan GetNodeInputCount() / SetNodeInputCount() , jika kita untuk mengganti nama node_get_input_count seperti yang disarankan.

Teman-teman, tolong teruskan diskusi tentang C# API dan konvensi biasa di luar masalah ini, yang difokuskan pada Godot API. Godot API (C++, C dan GDScript) tidak akan diadaptasi untuk C#, kecuali itu juga merupakan peningkatan untuk bahasa lain.

@akien-mga Saya tidak berpikir itu adalah hal khusus C# yang membahas apakah node_get_input_count dapat diubah namanya menjadi sesuatu seperti get_node_input_count .

Tidak, maksud saya apa pun yang spesifik C# tidak boleh ada dalam masalah ini. Mungkin ada masalah lain untuk kerusakan kompatibilitas khusus C# jika perlu (walaupun sudah ada beberapa IINM tersebut).

Bagaimana dengan mengganti nama Spatial ke Node3D? Saya selalu merasa aneh.

@KoBeWi Skema penamaan yang Godot gunakan saat ini adalah "Thing2D" untuk barang 2D dan hanya "Benda" untuk barang 3D, jadi cukup konsisten dengan kode 2D lainnya. Tentu saja hal logis untuk memanggil "Spasial" adalah "Node" mengikuti pola penghapusan "2D", tetapi nama itu sudah diambil tentu saja.

Skema penamaan yang Godot gunakan saat ini adalah "Thing2D" untuk barang 2D dan hanya "Benda" untuk barang 3D

Jadi mungkin mengubah semuanya 3D menjadi "Thing3D"? Itu juga terlintas di pikiranku, tapi terdengar seperti berlebihan.
Bagaimanapun, saya hanya menyarankan. Tidak seperti itu sangat penting. Juga, Spatial2D bahkan lebih buruk dari Spasial.

Jadi, String.right() mengembalikan n karakter kanan dari posisi yang diberikan. Bukankah akan lebih intuitif jika hanya mengembalikan n karakter yang dihitung dari kanan?

"abcdef".right(2)
Alih-alih "cdef" akan mengembalikan "ef". IMO itu akan lebih baik.

Saya mengharapkan hal yang sama.

Python memiliki metode yang sama kebanyakan pengguna suka membandingkan GDScript dengan Python. Mungkin akan lebih membingungkan untuk mengubahnya.

@KoBeWi saya setuju. Saya tidak melihat perbedaan antara implementasi dan substring saat ini.

Godot substr memaksa Anda untuk menunjukkan ukuran string jika Anda ingin semuanya di sebelah kanan.

@Zylann Sebagian besar implementasi memungkinkan untuk menghilangkan parameter kedua. Saya akan menganggap ini sebagai masalah di pihak Godot. Selain itu, saya lebih suka substr membuat parameter kedua opsional daripada metode baru dengan nama yang berbeda.

@Zylann @neikeq Ini adalah hasil yang disayangkan dari memiliki metode yang tidak dapat dimuat berlebih, tidak ada cara untuk memiliki spesifikasi panjang dan tidak ada spesifikasi panjang.

@aaronfranke Um, tetapi argumen default memang ada. 0 atau -1 dapat dihitung sebagai tidak ada panjang yang ditentukan.

Perlu menghapus get_selected_id() dari OptionButton saat ini selalu mengembalikan -1. Setelah https://github.com/godotengine/godot/pull/21837 digabungkan get_selected_id() akan kembali sama dengan get_selected() .

Ada banyak tween metode yang selalu mengembalikan true, mereka mungkin harus dibatalkan.

WindowDialog.get_close_button()
ConfirmationDialog.get_cancel() -> ConfirmationDialog.get_cancel_button()
AcceptDialog.get_ok() -> AcceptDialog.get_ok_button()

Node Pohon memiliki fungsi get_selected() dengan tampaknya mengembalikan TreeItem yang terfokus. Mungkin layak untuk mengganti namanya menjadi sesuatu seperti get_active() , karena fokus dan pemilihan adalah hal yang berbeda.

load_from_globals() di InputMap harus load_from_project_settings() .

Saya akan menambahkan :tada: reaksi terhadap semua saran yang telah diintegrasikan ke dalam OP, untuk mendapatkan gambaran yang lebih baik.

global_rotate harus diganti namanya rotate_global dan rotate_object_local harus diganti namanya rotate_local untuk konsistensi dan agar semua metode rotasi dimulai dengan "rotate".

global_rotate harus diganti namanya rotate_global dan rotate_object_local harus diganti namanya rotate_local untuk konsistensi dan agar semua metode rotasi dimulai dengan "rotate".

Nah, di sisi lain saya suka fungsi terkait global (seperti global_position, global_scale dan global_transform) yang bersebelahan dalam saran pelengkapan otomatis. Kedua solusi masuk akal IMHO.

Mungkin tree_exiting dapat diganti namanya menjadi tree_exited karena tampaknya menyebabkan kebingungan sekarang. Lihat #22840.

@groud Sudah ada sinyal tree_exited kan?

@groud Sudah ada sinyal tree_exited kan?

Sialan kau benar. Saya kira permintaan di #22840 valid kalau begitu

MenuItems.MENU_MAX tidak pernah digunakan di LineEdit dan TextEdit , haruskah kita menghapusnya?

Sama untuk Tabs.ALIGN_MAX https://github.com/godotengine/godot/blob/master/scene/gui/tabs.cpp#L750

Node Position3D dan Position2D agak ambigu. Tanpa membaca deskripsi, orang mungkin berasumsi bahwa mereka seperti Spasial dan Node2D tetapi tanpa rotasi atau skala. Mereka mungkin harus diganti namanya menjadi PositionHint dan PositionHint2D atau mungkin beberapa kata lain seperti Gizmo karena ini hanya alat di editor atau AxisMarker karena sepertinya penanda sumbu kecil.

Jika mereka diubah namanya menjadi Gizmo maka mungkin mereka dapat diberikan penggunaan yang lebih umum.

Perhatikan bahwa simpul yang sama di pohon Kontrol adalah ReferenceRect , jadi, ReferenceAxis/2D mungkin juga berfungsi.

Mencintai masalah ini sekarang. Mungkin benci nanti ketika kerusakan benar-benar menghantam;)

Beberapa proposal untuk kelas Array :

• duplicate → copy atau clone . Saya tidak tahu bahasa apa pun yang menyebut konsep ini "menduplikasi". copy adalah apa yang disebut dalam Python dan C++ jadi itu akan menjadi pilihan alami untuk Godot. clone berasal dari Java dan JavaScript dan mungkin sedikit lebih tepat.
• invert → reverse . Dokumentasi bahkan menggambarkannya sebagai "kebalikan" sehingga benar-benar tidak ada alasan.
• remove vs. erase membingungkan. Saran: remove_at dan remove_value .

Dua yang terakhir juga berlaku untuk semua kelas Pool*Array .

Catatan: Duplikat → salin/kloning juga berlaku untuk Kamus.

Rect2 :

• clip → intersection

AABB memiliki intersection metode tetapi tidak clip , kliping umumnya berarti bahwa kita memotong sesuatu, yang tidak diimplementasikan di kedua kelas btw. Dokumentasi menggambarkannya sebagai:

Returns the intersection of this Rect2 and b.

Mungkin juga mengganti nama:

• intersects → overlaps
  agar tidak bingung dengan operasi intersection :

Returns true if the Rect2 overlaps with another.

grabber_area -> slider_progress
slider -> slider_background

Beberapa proposal untuk kelas Array sederhana:
duplikat → baik salin atau klon.
...
Catatan: Duplikat → salin/kloning juga berlaku untuk Kamus.

Dan Node dan Sumber Daya (pada dasarnya semua objek struktur data yang terpapar skrip, afaik).

Saya lebih suka kata "Klon", saya pikir itu lebih jelas tentang apa yang dilakukannya.

Pagi! @akien-mga tidak bisakah kita mengganti nama instance menjadi new bukannya instantiate ? Memiliki antarmuka yang sama pada PackedScene seperti yang dilakukan Object misalnya menghapus beberapa boilerplate untuk pembuatan plugin khususnya, tetapi mungkin lebih umum. @willnationsdev bagaimana menurutmu? Saya tahu Anda pernah mengalami ini sebelumnya.

Maaf jika sudah ada pembicaraan tentang ini di suatu tempat, saya tidak dapat menemukannya dengan membaca sekilas.

grabber_area -> slider_progress
slider -> slider_background

atau hanya:
grabber_area -> progress
slider -> background ?

Saya tidak tahu apakah ini telah dibahas tetapi AnimationPlayer memiliki root_node dengan set_root & get_root , mereka mungkin seharusnya set/get_root_node

Ganti nama CanvasItem.visible menjadi CanvasItem.is_visible (dan semua tempat lain yang menggunakannya)? agar sejalan dengan semua (atau sebagian besar, mungkin saya melewatkan beberapa) properti bool ?

Ganti nama Tween.tween_completed menjadi Tween.tween_finished ? Sama seperti Animation.animation_finished ? Umumnya lebih suka _finished daripada _completed ? Rasanya started/finished memiliki hubungan yang lebih erat dari started/completed - bias dari olahraga kompetisi: start/finish - mungkin :D

Harap pertimbangkan untuk mengganti nama kelas JavaScript menjadi HTML5 atau yang lainnya.
Kelas ini memiliki metode tunggal dan tidak diperpanjang dari Script dan tidak digunakan di platform lain.

JavaScript dapat digunakan sebagai nama kelas binding bahasa JavaScript di masa mendatang.

Seperti yang ditunjukkan oleh @clayjohn , WORLD_MATRIX di shader CanvasItem sebenarnya adalah matriks modelview. @reduz setuju bahwa di 4.0 kita harus menggantinya dengan model aktual dan melihat matriks, misalnya CANVAS_MATRIX dan ITEM_MATRIX .

Pertimbangkan untuk mengganti nama Array.invert menjadi Array.reverse . Invert lebih seperti terbalik atau "timbal balik" jenis hal. Lihat https://docs.godotengine.org/en/latest/classes/class_color.html#class -color-method-inverted

Ubah sinyal CanvasItem.visibility_changed() menjadi CanvasItem.visibility_changed(visibility: bool) , mis. mengirim status visibilitas dengan itu. Karena ini sudah cukup maka hapus sinyal CanvasItem.hide()

Hapus Resource::notify_change_to_owners , Resource::{un}register_owner .
Mereka hanya digunakan oleh GridMap dan CollisionShape, kode lainnya menggunakan sinyal "changed" .

Rect2 : has_no_area harus diganti namanya has_area yang akan mencegah logika negasi ganda memeriksa kebalikannya dalam kondisional. Hal yang sama berlaku untuk AABB : has_no_surface .

Berdasarkan apa yang dikatakan @lupoDharkael , Godot memiliki beberapa tempat di mana negatif ganda digunakan. Kesalahan seperti "Kondisi !Math::is_nan(x) is false" membingungkan.

parse_input_event( Acara InputEvent )
Memberi makan InputEvent ke game. Dapat digunakan untuk memicu peristiwa input secara artifisial dari kode.

parse menyesatkan, parse akan menerima dan memproses tetapi deskripsi menunjukkan pengiriman atau memicu input

Sesuai #24153 - CanvasLayer menggunakan lapisan untuk menjelaskan lapisan apa yang akan digunakan untuk menggambar simpulnya. Tetapi hampir setiap simpul 2D lainnya menggunakan terminologi "Indeks Z" ( z_index ) untuk menggambarkan (apa yang tampak pada awalnya) hal yang sama. Seperti yang disarankan @swarnimarun https://github.com/godotengine/godot/issues/24153#issuecomment -444950584 meningkatkan nama untuk lapisan.

Apakah OS.has_feature() / Platform.has_feature() lebih masuk akal dalam sesuatu seperti ProjectSettings, karena mereka tidak secara eksklusif menyampaikan apa pun tentang OS?

set_cell_item dapat diubah namanya menjadi set_cell untuk menyatukan GridMap dengan TileMap ?

set_cell_item dapat diubah namanya menjadi set_cell untuk menyatukan GridMap dengan TileMap ?

Kalau dipikir-pikir, mungkin harus ada set_cellv untuk GridMaps juga?

Antarmuka ARVR:

• ar_is_anchor_detection_enabled -> anchor_detection atau serupa
• interface_is_initialized -> is_initialized atau is_interface_initialized

Pemain Animasi:

• play_backwards dapat dihapus karena play memiliki bool opsional untuk itu.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D:

• Ubah bool disabled menjadi enabled bool.

Tulang2D:

• get_index_in_skeleton -> get_skeleton_index

• play_backwards dapat dihapus karena play memiliki bool opsional untuk itu.

Itu akan buruk untuk keterbacaan, setidaknya selama #6866 tidak diterapkan. Ini bukan masalah di C# karena mendukung parameter bernama.

ID di id_pressed( int ID ) dan id_focused( int ID ) harus huruf kecil.

^
Perubahan itu sebenarnya tidak akan merusak kompatibilitas apa pun. Itu bisa mendapatkan masalah terpisah mungkin.

^
Perubahan itu sebenarnya tidak akan merusak kompatibilitas apa pun. Itu bisa mendapatkan masalah terpisah mungkin.

Betul sekali!

28746 - Node.replace_by mungkin membingungkan sebagai sebuah nama. Tidak yakin apa sebenarnya yang bisa menjadi nama yang lebih baik.

@bojidar-bg mungkin replace_self atau swap_by ? tetapi saya pikir satu-satunya cara untuk menghindari segala jenis kebingungan adalah dengan mendokumentasikannya dengan benar.

Jika saya memiliki Node2D dengan skrip terlampir yang berisi class_name MyNode2D , metode get_class() mengembalikan Node2D alih-alih MyNode2D . Ini mungkin disengaja tetapi membingungkan dan menyesatkan.

EDIT: https://github.com/godotengine/godot/issues/26980

@aaronfranke get_native_class() mungkin? Kemudian Anda bisa mendapatkan nama skrip dari get_script().global_name jika ada.

make_convex_from_brothers()
Saya kira "saudara" harus diubah menjadi "saudara", karena itulah kata yang digunakan di mana-mana untuk simpul saudara.

ARVRPpositionalTracker: get_type() -> get_tracker_type()

• get_tracker_type() lebih eksplisit - get_type() dapat dikacaukan dengan get_class()

• GetType() sudah digunakan untuk hal lain di C# seperti yang disebutkan di sini .

Ini mengembalikan TrackerType , dan ada juga get_hand() yang mengembalikan TrackerHand , sehingga juga dapat diubah menjadi get_tracker_hand() untuk konsistensi jika diinginkan.

ARVRPositionalTracker enum TrackerHand: TRACKER_LEFT_HAND -> TRACKER_HAND_LEFT (dan tangan kanan). Atau, TRACKER_HAND_UNKNOWN -> TRACKER_UNKNOWN_HAND , asalkan konsisten.

Node.NOTIFICATION_TRANSLATION_CHANGED mungkin seharusnya menjadi NOTIFICATION_LOCALE_CHANGED , karena "terjemahan" digunakan dalam simpul spasial yang berarti "posisi" dan bukan "bahasa".

set_as_toplevel() dapat diubah namanya menjadi set_as_top_level() , tetapi perilakunya harus dilihat .

TouchScreenButton harus dilihat untuk 4.0, karena perubahan ini dapat merusak: https://github.com/godotengine/godot/issues/28814

CanvasItem metode:

RID get_canvas_item() const
Mengembalikan RID item kanvas yang digunakan oleh VisualServer untuk item ini.

Harus diganti namanya menjadi get_rid() kemudian.

get_canvas_item() membingungkan karena saya sudah berada di node CanvasItem . Itu juga memastikan konsistensi karena kelas lain sudah memiliki metode get_rid() serupa: CollisionObject , Resource .

Haruskah Label diubah menjadi TextLabel ? Beberapa kali sekarang saya ingin meletakkan objek teks dan lupa apa namanya, jadi saya mencari "teks" dan hanya RichTextLabel muncul. TextLabel akan lebih konsisten dengan RichTextLabel karena masih berupa teks tetapi tanpa rich.

Untuk referensi, Unity memiliki Text dan TextMesh , dan saya pribadi menyebutnya sebagai teks daripada label.

Saya juga bertanya-tanya tentang Tree dan GraphNode diubah namanya menjadi TreeView dan GraphEditNode .
Untuk Tree , alasannya adalah nama yang terlalu luas untuk node GUI global IMO, semua kerangka kerja GUI lain yang saya tahu digunakan TreeView .
Untuk GraphNode , itu karena saya baru-baru ini mengerjakan beberapa prototipe yang melibatkan struktur grafik aktual, dan saya tidak dapat menggunakan Node atau GraphNode yang cukup mengganggu.

@Zylann karena Graph node adalah visual/kontrol untuk grafik (bukan pohon), GraphContainer mungkin lebih baik. Tidak yakin tentang GraphNode.

Haruskah kita memiliki lerpf / lerpv / lerpc bukannya Color/Vector2/3.linear_interpolate ? Setidaknya ganti nama Color/Vector2/3.linear_interpolate menjadi Color/Vector2/3.lerp

Seperti disebutkan dalam #29598 http_escape / http_unescape hingga uri_encode / uri_decode

Haruskah kita memiliki lerpf & lerpv bukannya Vector2/3.linear_interpolate ? Setidaknya ganti nama Vector2/3.linear_interpolate menjadi Vector2/3.lerp

Memperpendek ke vector.lerp() terdengar bagus. Setidaknya pada https://github.com/godotengine/godot/pull/16106 penggunaan lerp() dalam skrip memiliki sakelar untuk mendukung vektor dan warna.

Vector2.angle_to_point() harus diganti namanya. Namanya tidak sesuai dengan deskripsi saat ini. Tidak yakin apa nama yang bagus, dan apakah fungsi ini layak dipertahankan.

Edisi asli: #16307

@razcore-art Sudah PR terbuka tentang ini https://github.com/godotengine/godot/pull/20371 , dan itu membuat kompatibilitas mundur (saya pikir).

EDIT: Tidak lagi.

Area seharusnya benar-benar Volume , karena ini 3D. Dan Area2D seharusnya Area . Suatu area pada dasarnya adalah 2D.

GridMap mungkin seharusnya CubeMap . Tidak yakin yang satu ini, hanya saja "kisi" itu terdengar seperti hal 2D bagi saya.

CheckButton kontrol harus SwitchButton atau sesuatu. Ini membingungkan karena ada juga Checkbox . Atau mungkin harus dihilangkan sama sekali. Ini melayani fungsi yang sama dengan Kotak centang, sejauh yang saya tahu.

Saya setuju kembali: CheckButton, dan yang lainnya hanya kosmetik.

Atau mungkin harus dihilangkan sama sekali. Ini melayani fungsi yang sama dengan Kotak centang, sejauh yang saya tahu.

Dari segi UX, CheckBox dan CheckButton adalah hal yang berbeda, meskipun memiliki fungsi yang sama.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@Rodeo-McCabe Area disebut seperti itu untuk konsistensi dengan mitra 2D, juga salah satu definisi dari area adalah a particular extent of space or surface .
Cubemaps adalah gambar 3D, kebenaran sintaks harus sesuai konteks atau hanya menambah kebingungan.

grabber_area -> slider_progress
slider -> slider_background

atau hanya:
grabber_area -> progress
slider -> background ?

Mungkin:
grabber_area -> progress_area atau progressed_area
slider -> progress_background ?

Cubemaps adalah gambar 3D, kebenaran sintaks harus sesuai konteks atau hanya menambah kebingungan.

@eon-s Cukup adil, saya tidak tahu itu.

Area disebut seperti itu untuk konsistensi dengan pasangan 2D

Masalahnya adalah mitra 2D juga tidak konsisten. Dalam matematika suatu luas adalah panjang * tinggi, hanya saja tidak ada dimensi ketiga. Jadi tidak masuk akal untuk mengatakan Area2D, karena seharusnya 2D berdasarkan area. Definisi lain yang lebih matematis dari "area" adalah:

permukaan termasuk dalam serangkaian garis, khususnya: jumlah kuadrat satuan yang ukurannya sama dengan permukaan

Demikian pula, ruang 3D dalam matematika disebut "volume". Saya bingung pada awalnya ketika saya menemukan Area sebenarnya adalah simpul 3D, sebaliknya area anehnya disebut "Area2D". Karena ini adalah mesin permainan, definisi matematika adalah yang harus kita ambil.

Sementara saya memahami alasannya, saya tidak tahu apakah akan ada manfaat khusus untuk mengubah nama, terutama untuk orang baru. Saya setuju bahwa "Volume" mungkin istilah yang lebih tepat untuk ini, tetapi saya merasa memiliki "Volume" untuk 3D dan "Area" untuk 2D mungkin sedikit membingungkan. Lagi pula, banyak node yang memiliki varian 2D dan 3D akan diberi nama "

Saya pikir skema penamaan yang ada di tempat pertama (sebanyak ada beberapa node yang hanya sebagian besar menempel pada skema) berarti bahwa kita tidak boleh memiliki pengecualian terhadap aturan, bahkan di mana istilah lain untuk satu varian akan dibuat lebih masuk akal, karena jika tidak, kemungkinan akan membingungkan pengguna.

Namun jika boleh... mungkin mengganti nama Area2D menjadi Area , dan Area menjadi Area3D ?

Sunting: Tampaknya teks yang dikelilingi oleh <> tidak muncul kecuali Anda keluar dari <>

@Rodeo-McCabe Saya mendapat kesan niat penamaan simpul adalah untuk mengekspresikan hal-hal dalam bahasa manusia dan bukan matematika. Jadi "area" tidak dimaksudkan untuk menjadi geometris, tetapi suatu tempat, seperti di dalam tingkat atau panggung. IE - Area 1.

Node itu sendiri tidak secara langsung memiliki geometri atau geometri itu sendiri, jadi orang lain seperti saya akan bertanya-tanya di mana area/volumenya saat membuatnya, lalu mengapa saya harus melampirkan area dan volume (Bentuk) ke suatu area dan volume?

Jika harus menjalani penggantian nama untuk menghindari kebingungan dengan area geometris, sinonim mungkin akan menjadi cara yang tepat.

Mereka mungkin disebut:

• Wilayah2D/3D
• Ruang2D/3D
• Zona2D/3D
• Bidang2D/3D
• dll.

Btw, selain pelacak ini hanya untuk metode, properti, dan sinyal (bukan Node), @reduz baru-baru ini menyebutkan bahwa ada niat untuk meminimalkan kerusakan kompatibilitas pada 4.0, jadi mungkin daftar besar ini mungkin perlu ditinjau dari pengembang inti sebelum kami melanjutkan menambahkan hal-hal yang kekal...

Kedengarannya seperti tujuannya adalah untuk meninggalkan hal-hal seperti sekarang, jadi hal-hal seperti ini mungkin akan ditendang kembali hingga versi utama berikutnya setelah 4.0?

Harap tinggalkan masalah ini untuk kontributor inti, ini bukan tempat untuk membuat saran penggantian nama besar di semua tempat, tujuannya adalah untuk memperbaiki inkonsistensi aktual yang membuat API menjadi rumit.

Perubahan yang diuraikan dalam OP bukanlah kerusakan kompatibilitas besar dan sebagian besar akan dilakukan untuk 4.0, yang dimaksud @reduz adalah kerusakan kompatibilitas jenis "proyek Anda tidak dapat dibuka lagi" seperti antara 2.1 dan 3.0 (lebih banyak berubah dari sekadar hal-hal yang diganti namanya saat itu, seperti sistem audio dan partikel yang sepenuhnya ditulis ulang, sistem impor berubah, dll.).

Akan ada beberapa kerusakan kompatibilitas di 4.0, jika tidak maka tidak akan disebut 4.0. Ini akan masuk akal dan porting akan mudah, kemungkinan dengan konverter untuk memastikan bahwa properti, metode, dan sinyal yang diubah namanya dikonversi dengan benar jika digunakan dalam adegan dan skrip. Ini bukan tempat untuk membahasnya dalam hal apapun :)

Control 's _set_anchor() juga harus menghilangkan awalan "_".

PopupMenu memiliki index_pressed(index) dan id_pressed(id) yang berfungsi dengan baik, tetapi juga id_focused yang sebenarnya dipancarkan dengan indeks alih-alih id item.

Belum ada masalah untuk ini, tetapi setelah menyarankannya kepada Akien hari ini, layak untuk dimasukkan ke dalam daftar.

Refactor ARVRServer sehingga disebut XRServer. Saat kami mendesainnya, istilah XR untuk menunjukkan VR dan AR belum digunakan secara luas. Dan tidak, saya tidak akan menggunakan MRServer ;)

Haruskah RayCast memiliki properti "Nonaktif" alih-alih "Diaktifkan"? CollisionShape memiliki "Nonaktif" yaitu false secara default (yang berarti diaktifkan secara default). Sebaliknya, properti "Enabled" RayCast adalah false secara default, membuatnya dinonaktifkan secara default.

Atau, untuk menggunakan bentuk positif (yang menurut saya kurang membingungkan secara keseluruhan), haruskah CollisionShape memiliki properti "Diaktifkan" ( true secara default) alih-alih "Nonaktif"?

@Calinou Saya tidak tahu apakah itu memerlukan masalah terpisah, tetapi jika kita harus konsisten, saya lebih suka boolean seperti itu selalu Enabled . Menyetel boolean ke true untuk menonaktifkan sesuatu yang sering membuat saya bingung.

@Calinou Saya setuju dengan @Zylann negatif ganda membingungkan dan harus dihindari bila memungkinkan. Sebagai gantinya, kita harus mengubah bool "Nonaktif" menjadi yang "Diaktifkan". Tidak apa-apa jika nilai default dari sesuatu adalah "benar". Saya melakukan diskusi ini di #17212 dan #21822.

Properti speed dari mouse dan event input sentuh harus diganti namanya menjadi velocity karena ini adalah Vector2.

InputMap : get_action_list( String action ) nama fungsi tidak memberi tahu banyak tentang fungsinya.
Karena itu mengembalikan EventInputs yang terkait dengan tindakan tertentu, itu bisa menjadi get_action_events(String action)

Juga dapat membantu menghindari kemungkinan kebingungan karena InputMap memiliki fungsi lain yang disebut get_actions( ) dan kedua nama dapat berarti hal yang sama di luar konteks.

Secara tangensial terkait dengan #30736, kita harus mengganti nama kedua mesin fisika Godot menjadi sesuatu seperti "GodotPhysics2D" dan "GodotPhysics3D", karena mengatakan bahwa ada sesuatu yang rusak dengan "GodotPhysics" dapat berarti dua hal yang sangat berbeda.

Bagaimana dengan mengganti nama Object._init() menjadi Object._new() ?

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

new — _init

Saya kira _init benar-benar mengikuti __init__ Python, sedangkan new adalah metode kelas, bukan instance.

Apakah sesuatu seperti String : empty() -> is_empty() cocok untuk utas ini? Saya selalu berpikir itu adalah fungsi untuk menghapus string pada awalnya.

@vortexofdoom jika berbicara tentang inkonsistensi nama metode dan/atau bagaimana mereka harus dinamai, maka ya.

Saya dapat menambahkan bahwa String dan NodePath masing-masing memiliki metode empty dan is_empty yang melakukan hal yang sama. Jenis bawaan inti lainnya tampaknya lebih menyukai nama empty jadi mungkin is_empty dapat diganti namanya menjadi NodePath untuk membuat ini konsisten di semua jenis bawaan, tetapi ini berpotensi melibatkan beberapa kerusakan kompatibilitas yang serius, saya pikir.

Saya selalu berpikir itu adalah fungsi untuk menghapus string pada awalnya.

Sebagian besar metode menggunakan nama clear di Godot untuk itu.

@Xrayez ,

Sebagian besar metode menggunakan nama yang jelas di Godot untuk itu.

Saya tahu, hanya mengacu pada fakta bahwa empty adalah kata kerja dan juga kata sifat, dan menambahkan is_ memperjelas mana yang dimaksud.

Saya lebih suka menggunakan is_empty di semua bawaan untuk bool itu.

Di Godot 3.0 dan 3.1, kami memiliki metode Set di C#. Namun, ini sebenarnya tidak menambahkan fungsionalitas aktual apa pun dibandingkan dengan hanya menggunakan konstruktor dan penugasan, namun membiarkan kode gagal secara diam-diam, jadi mereka sudah usang. Mereka sebagian besar ditambahkan oleh saya untuk mencoba dan konsisten, karena metode untuk Quat sudah ada, yang berasal dari inti yang memiliki metode yang ditetapkan. Untuk info lebih lanjut lihat #30744

GDScript memang memiliki set_euler dan set_axis_angle , tetapi ada juga konstruktor untuk melakukan hal yang sama ( q.set_axis_angle(myvec3, myval) dapat diganti dengan q = Quat(myvec3, myval) . Core juga memiliki metode ini untuk Basis, tetapi mereka tidak terpapar ke GDScript.

Pertanyaannya kemudian, apa yang harus dilakukan tentang ini? Haruskah metode set Quat tidak digunakan lagi demi konstruktor dan konsisten dengan C#, atau apakah bermanfaat untuk membuatnya eksplisit tentang operasi yang dilakukan? Jika yang terakhir, haruskah metode Basis diekspos juga?

@aaronfranke Saya selalu merasa aneh bahwa konstruktor itu memiliki metode khusus ketika pada dasarnya tidak ada yang melakukannya, jadi saya akan mengambil rute sebelumnya jika memungkinkan.

@aaronfranke Masalah ini adalah tentang mengganti nama hal-hal di API, bukan fungsi mesin atau bug.

Geometry 's point_is_inside_triangle() ke is_point_in_triangle() , untuk mencocokkan metode lain yang juga mengembalikan bool s di kelas yang sama.

TreeItem.get_children() harus diganti namanya get_first_child() . Doc juga harus menjelaskan bahwa itu TIDAK mengembalikan item anak. Anak-anak diulang menggunakan get_next() .

Saat mengerjakan #31976, saya perhatikan nilai shadow atlas harus pangkat 2 (baik untuk directional shadows dan omni/spot shadows). Namun, metode menerima nilai integer apa pun; jika bukan pangkat 2, metode ini akan membulatkannya ke pangkat 2 terdekat. Kita mungkin harus membuatnya menerima enum nilai, sehingga dapat disajikan dengan cara yang ramah pengguna di Pengaturan Proyek.

Demikian juga, tingkat penyaringan anisotropik harus enum (2×, 4×, 8×, 16×), karena hanya nilai pangkat dua yang masuk akal di sini.

VisualServer 's instance_create2() harus diubah untuk benar-benar menggambarkan apa yang dilakukannya secara berbeda dari instance_create() .

Untuk terjemahan objek-relatif, Spatial memiliki translate_object_local yang mengambil Vector3 , dan Node2D memiliki move_local_x dan move_local_y , yang mengambil pelampung. Baik Spatial dan Node2D harus memiliki metode yang masing-masing menggunakan Vector3 dan Vector2 , dan translate_local atau local_translate akan menjadi nama yang lebih sederhana dari translate_object_local .

@leonkrause Alih-alih render_width dan render_height akan lebih masuk akal untuk menyebutnya viewport_width dan viewport_height , atau mungkin canvas_width dan canvas_height , karena ini adalah resolusi referensi yang digunakan untuk area pandang kanvas, dan sebenarnya tidak memengaruhi rendering.

@akien-mga harap pertimbangkan untuk menambahkan metode navigasi Pohon ke daftar Anda. Nama-nama tersebut sangat membingungkan dan tidak didokumentasikan dengan baik.

Ketika saya pertama kali menemukannya, saya pikir get_child() dan get_next(), get_prev() mengoperasikan iterator seperti cara kerja Directory. Saya harus melakukan pengujian sendiri untuk mengetahui bahwa yang mereka lakukan hanyalah menghasilkan pointer yang sama setiap kali mereka dipanggil.

get_children() harus diganti namanya menjadi get_first_child().

get_next() dan get_prev() harus diganti namanya menjadi get_next_sibling() dan get_prev_sibling()

Bagaimana dengan mengganti nama Engine.iterations_per_second menjadi Engine.physics_fps untuk konsistensi dengan Pengaturan Proyek?

is_processing :

Mengembalikan nilai true jika pemrosesan diaktifkan.

can_process :

Mengembalikan nilai true jika node dapat memproses saat pohon adegan dijeda

Mungkin lebih baik untuk mengganti nama can_process menjadi sesuatu seperti can_process_paused untuk menghindari kebingungan dengan metode is_processing .

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

Saya pikir metode ini harus diganti namanya.

@dalexeev Apa yang harus diganti namanya, dan mengapa?

@Calinou Metode ini sebenarnya tidak mencetak apa pun ke layar; itu mengembalikan string. Pikiran pertama adalah bahwa JSON.print bekerja seperti Node.print_tree atau OS.print_all_resources atau seperti semua metode print* .

Apa yang harus diganti namanya? Saya tidak yakin. JavaScript menggunakan JSON.stringify untuk ini. PHP memiliki fungsi json_encode . Langsung di GDScript ada fungsi serupa - to_json .

UPD. JSON.serialize juga dimungkinkan, tetapi jumlah karakternya sama dengan JSON.stringify . :senyum:

Saya akan menyarankan untuk tidak menggunakan kata "serialize" karena itu biasanya digunakan untuk serialisasi biner, dan output seperti itu perlu memiliki langkah lebih lanjut untuk mendapatkan formulir itu.

Karena kelas ini hanya memiliki dua metode untuk beralih antara tipe JSON dan Varian, saya sarankan untuk tidak menggunakan metode yang mengandung kata json karena tidak ada gunanya.

Sekarang, untuk hal-hal yang akan menjadi nama yang baik, metode parse yang ada tidak benar-benar memiliki lawan kata yang jelas ( lihat di sini ). Mungkin salah satunya: encode , create , compose , generate ? Jika encode digunakan, masuk akal untuk mengganti nama metode lain menjadi decode .

Saya telah melihat format dan write digunakan sebagai kebalikan dari parse . stringify memiliki keuntungan lebih dikenal di kalangan pengembang karena digunakan dalam JavaScript.

Saya telah melihat format dan write digunakan sebagai kebalikan dari parse . stringify memiliki keuntungan lebih dikenal di kalangan pengembang karena digunakan dalam JavaScript.

str2var adalah VariantParser dan var2str adalah VariantWriter internal (lihat #33241 misalnya, saya bahkan menggunakan istilah yang sama untuk menggambarkannya).

Jadi saya untuk write , konsistensi menang. 😛

@Xrayez Ubah print menjadi write ? Dari Python ke Pascal? :tertawa:

Seperti yang disarankan di https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552 , mungkin masuk akal untuk mengganti nama semua yang terkait dengan clear_color menjadi background_color (termasuk pengaturan proyek).

Saya berharap 4.0 membawa gelombang besar orang baru ke Godot karena kinerja yang lebih baik, peningkatan penyelidikan GI, hype umum, dan sebagainya.

Jika perubahan tersebut dilakukan dengan 4.0, orang-orang ini akan mendapatkan arahan yang sulit karena hampir tidak ada tutorial yang ada (selain tutorial "permainan pertama" resmi) yang akan berfungsi untuk mereka lagi.

Jika perubahan itu dilakukan setelah 4.0, katakanlah di 4.1, itu akan menjadi perjalanan yang sangat bergelombang bagi orang-orang itu. Mereka baru saja mempelajari dasar-dasar mesin baru, yang sekarang harus mereka pelajari kembali. Permulaan itu sulit, harus melalui ini dua kali terlalu cepat setelah yang lain bisa cukup membuat frustrasi untuk menyerah sama sekali.

Oleh karena itu, apakah tidak masuk akal untuk memiliki versi "3.3" atau "3.9" sebelum rilis 4.0 yang memiliki semua kompatibilitas yang melanggar perubahan API, namun memberi pembuat tutorial cukup waktu untuk membuat beberapa tutorial sebelum diharapkan masuknya pengguna baru secara besar-besaran?

Tidak yakin apakah ini tempat yang tepat atau tidak, tetapi karena ini bisa menjadi solusi parsial yang mungkin untuk masalah penggantian nama, saya akan mengajukannya di sini.
Mengapa tidak membuat semua perubahan nama yang diperlukan dan kemudian menambahkan bahasa baru ke terjemahan yang disebut GodotOldNames/GodotPre4.0 yang memiliki semua nama lama untuk semua perubahan.
Dengan cara ini jika seseorang tidak menemukan nama lama yang ada di tutorial lama, mereka dapat mengubah bahasa menjadi GodotPre4.0 . Ini juga akan membuat beralih ke nama baru lebih mudah.
Ini tidak menyelesaikan seluruh masalah tetapi mungkin cocok dengan #4397.

@Anutrix Ini akan menambah banyak kerumitan (bagaimana dengan bahasa non-Inggris?). Selain itu, tidak semua string yang ditampilkan di editor dapat dilokalkan.

Fisika " Lapisan ", Render " Lapisan "

Saya ingat mengalami kebingungan yang sama persis dengan orang malang ini selama beberapa minggu pertama saya belajar Godot.

"Lapisan" Fisika, Render "Lapisan" mungkin masuk akal bagi seseorang yang berasal dari Desain Berorientasi Objek , tetapi bagi orang lain itu sangat membingungkan. Istilah "lapisan" digunakan ketika menggambarkan beberapa lapisan cat, atau lapisan kain pada kain, lapisan kulit pada bawang (atau raksasa), lapisan sedimen di permukaan planet, ...
Lapisan (jamak, bertentangan dengan satu lapisan), tampaknya menyiratkan ditumpuk di atas satu sama lain dalam semua kasus itu.

Bagi banyak orang, "melapisi" terutama ketika bekerja dengan grafik atau animasi 2D menyiratkan bekerja dengan latar depan, latar belakang, dan lapisan di antara atau di atas. Banyak orang menganggap lapisan sebagai film seloloid di atas latar belakang, padahal sebenarnya Godot seperti banyak mesin permainan lainnya menggunakan berbagai cara "penyortiran" untuk menyelesaikan tugas ini.

Fakta bahwa kita menyebut kesamaan abstrak bahwa objek Fisika atau objek Render mungkin berbagi "Lapisan", sementara pada saat yang sama kesamaan abstrak ini tidak ada hubungannya dengan tampilan tumpukan lapisan visual (itulah "penyortiran"), adalah apa yang membuat ini begitu membingungkan bagi sebagian orang.

Ketika saya memahami kegunaan dan arti sebenarnya dari "Lapisan" Fisika, Render "Lapisan", saya langsung bertanya-tanya mengapa ini bukan Grup Fisika, Grup Render, dan sejujurnya, saya masih tidak tahu. Mereka tentu saja tidak memiliki hubungan ontop-stackable satu sama lain, yang berarti urutan atau hubungan mereka satu sama lain sama sekali tidak relevan. Memberi nama mereka lapisan, saya hanya mengarsipkan orang-orang yang membingungkan, "grup", "dipengaruhi oleh grup" untuk topeng, atau mungkin istilah lain yang tidak dapat saya pikirkan saat ini akan lebih akurat.

Metode AnimationPlayer
.stop(false) harus dipanggil .pause(true)
karena itulah yang dilakukannya.

Proyek > Pengaturan Proyek > Tampilan > Jendela > Peregangan > Mode:

Stretch Mode "2D" harus disebut Stretch Mode "display" , atau "general purpose"
karena membingungkan untuk menyebutnya 2D ketika berfungsi dengan baik untuk kasus penggunaan 3D, tetapi tidak terlalu baik untuk semua kasus penggunaan 2D (seperti proyek pixelart, sementara hampir separuh proyek Godot 2D tampaknya menjadi pixelart.)
"tampilan" juga akan lebih deskriptif untuk apa yang sebenarnya dilakukannya: Merender semua grafik baik itu grafik 2D, objek 3D, jerat 2D, Line2D, dan Poligon pada resolusi tampilan.
Lebih lanjut tentang itu di sini .

loop, repeat, oneshot, dari animationplayer, timer, dan node serupa, dapat diklarifikasi.

perulangan, pengulangan, dan tidak menjadi oneshot, semuanya adalah hal yang sama.

Saya pikir itu
is_a_parent_of()
harus diganti namanya menjadi
is_parent_of()

@KoBeWi lihat diskusi di #19801.

Saya pikir itu
is_a_parent_of()
harus diganti namanya menjadi
is_parent_of()

Saya rasa tidak, is_parent_of() menyarankan itu hanya memperhitungkan orang tua pertama, sedangkan fungsi memeriksa semua orang tua secara rekursif.

@groud Dalam hal ini, itu harus disebut is_ancestor_of() . Jika ada juga fungsi yang sesuai untuk sebaliknya, maka itu harus disebut is_descendant_of() .

@groud Dalam hal ini, itu harus disebut is_ancestor_of(). Jika ada juga fungsi yang sesuai untuk sebaliknya, maka itu harus disebut is_descendant_of().

Ya, tetapi memikirkannya, tidak banyak kebutuhan untuk memiliki kedua fungsi, karena perbedaannya hanya masalah pengalihan objek "panggilan" dan argumen fungsi. Mungkin kita bisa mengganti fungsinya dengan sesuatu seperti is_descendant_of() dan selesai.

Kita mungkin ingin mengganti nama push_error() dan push_warning() menjadi print_error() dan print_warning() . Ini akan membuatnya lebih mudah ditemukan berkat pelengkapan otomatis :slightly_smiling_face:

@Calinou print_error() mungkin bingung dengan printerr()

Tolong, pertimbangkan untuk mengubah nama metode TreeItem.get_children() , karena namanya menyiratkan kumpulan anak-anak menjadi nilai pengembalian, ketika dalam praktiknya itu adalah anak pertama yang dikembalikan dan kemudian Anda harus mengulangi sisanya mereka menggunakan get_next() (seperti yang dijelaskan dalam #19796).

Mengutip @Zylann dari #31404:

[Ganti nama rpc() / rset() menjadi] remote_call() / remote_set() ?
Metode-metode itu juga memiliki nama yang sangat pendek, tidak yakin apakah alias sudah cukup. Anda harus benar-benar banyak melakukan multipemain dengan banyak panggilan ini per skrip untuk membenarkan pengidentifikasi 3 karakter (yang saya yakin sebagian besar game tidak).

Sunting (2020-01-03): Setelah dipikir-pikir, call_remote() dan set_remote() mungkin lebih masuk akal karena kita sudah memiliki call_deferred() dan set_deferred() .

Sunting: Jangan pedulikan penutupan/pembukaan kembali di bawah ini, saya mengklik terlalu cepat.

Metode berikut

OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

harus dipindahkan dari kelas OS ke kelas Input untuk konsistensi dengan metode:

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 harus memiliki sinyal tab_close dan tab_hover diedit juga.

• LightOccluder2D light_mask -> occluder_light_mask
• CPUParticles Flags enum -> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker get_name -> get_tracker_name
• PathFollow2D rotate -> sesuatu yang lain
• ArrayMesh ArrayType enum -> hapus ini
• Mesh BlendShapeMode enum -> berikan ke ArrayMesh

Penjelasan di https://github.com/godotengine/godot/issues/15763#issuecomment -568908661

Sinyal meta_hover_started dan meta_hover_ended RichTextLabel harus diganti namanya agar sesuai dengan sebagian besar konvensi penamaan serupa lainnya: meta_hover_entered dan meta_hover_exited . Ini tidak hanya membuatnya lebih mirip dengan API Godot lainnya, tetapi skema penamaan saat ini, karena pengurutan abjad, menyebabkan urutannya dibalik. Ini sedikit membingungkan ketika Anda membaca dokumen karena, jelas, alur kronologis operasi adalah pertama masuk dan kemudian keluar. Itu hanya di sekitar meningkatkan keterbacaan dan konsistensi untuk mengubahnya.

Saya perhatikan bahwa tidak ada properti Texture.size. Saya perlu memanggil pengambil Texture.get_size() sebagai gantinya.

Saya bertanya di Discord apakah ini dimaksudkan atau tidak. Satu saran adalah memposting di sini menanyakan apakah ini perlu dikonversi ke properti, saran lainnya adalah karena tidak ada 'penyetel' untuk ini, menggunakan get_size() adalah perilaku yang diharapkan saat ini.

@jmbjr Apakah kita memiliki properti read-only yang diekspos sebagai properti (bukan hanya metode pengambil)? Saya ingat pernah melihat penangan kesalahan bawaan saat mencoba menyetel properti hanya-baca. Saya hanya tidak yakin apakah itu terkena GDScript di tempat pertama.

Ya, saya pikir jika Anda akan mulai mendukung properti terbuka hanya-baca, maka Anda memerlukan flag USAGE untuk itu dan juga menambahkan kode pengurai/kompiler GDScript yang mendukungnya.

SoftBody memiliki areaAngular_stiffness yang seharusnya area_angular_stiffness (sama untuk semua metode terkait).

Input.joy_connection_changed (metode) sepertinya tidak boleh diekspos ke API skrip, ini dipanggil secara internal oleh kode penanganan joystick setiap platform.

@akien-mga Ketika saya pertama kali melihat metode itu, sangat awal setelah menemukan Godot, saya memiliki pemikiran yang sama, kemudian saya ingat bagaimana Kojima telah membangun beberapa gameplay legendaris di MetalGearSolid di sekitar metode yang pasti sangat mirip dengan ini dan saya berpikir: " Godot bahkan memberiku cara untuk menembus tembok ke-4 seperti Kojima dengan satu baris kode, betapa hebatnya itu!"

Label dan RichTextLabel memiliki properti tema yang tidak konsisten:

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 )]

Juga, karena nilai default yang berbeda, font yang sama memiliki ketinggian yang berbeda di Label dan RichTextLabel .

Sinyal request_completion TextEdit dapat diubah namanya menjadi completion_requested untuk menggunakan bentuk lampau. Versi saat ini terdengar agak penting, bertentangan dengan sifat sinyal callback-y.

inkonsistensi lain dengan sinyal tubuh fisika

Daerah:

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 )

saya kira area_shape dalam dua yang terakhir ini harus self_shape ? atau ...

Tubuh kaku:

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 )

di sini disebut local_shape ...

@FrederickDesimpel Sejauh yang saya tahu, argumen dapat diganti namanya tanpa merusak kompatibilitas. Jangan ragu untuk membuka permintaan tarik untuk ini :slightly_smiling_face:

Dalam Varian:

Nyata -> Mengapung
nihil -> nol?

Saya suka nama "asli" secara pribadi, karena istilah "float" sering digunakan untuk float 32-bit secara khusus, tetapi real Variant adalah ganda, dan sebagian besar mesin menggunakan real_t yang dapat berupa keduanya.

PS Kami sudah melakukan itu mengubah nama sebaliknya pada tahun 2017.

Apakah kami mempertimbangkan untuk mengganti nama ini:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial sudah diganti namanya menjadi StandardMaterial3D di master.

Haruskah nilai limit_ pada Camera2D diubah menjadi Rect2i ? Saat ini mereka hanya empat int.

EDIT: Seret margin juga dapat diubah, menjadi Rect2 .

String::begins_with ke String::starts_with .

Seperti dalam bahasa pemrograman yang serius (Java, Python dll).

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

Meskipun kata "hanya" tidak ada, event.is_action_...() sesuai dengan Input.is_action_just...().

Kita mungkin harus menukar dua argumen pertama Node.add_child_below_node() sehingga argumen pertama sama dengan Node.add_child() . Lihat #19642.

_ bicara atelofobia semantik…_

Haruskah Node2D.draw_circle menjadi Node2D.draw_disk karena ia menggambar disk dan bukan lingkaran?
Node2D.draw_circle masih bisa ada sebagai jalan pintas untuk draw_arc dari 0 ke TAU .

@Goutte Dalam bahasa Inggris, "lingkaran" dapat merujuk ke lingkaran kosong atau lingkaran penuh. Saya pikir nama saat ini lebih mudah ditemukan, jadi saya tidak akan mengubahnya.

Dalam bahasa Inggris, "lingkaran" dapat merujuk ke lingkaran kosong atau lingkaran penuh.

Saya tidak dapat menemukan apa pun yang mendukung ini . Apakah Anda memiliki sumber untuk klaim ini atau itu firasat?

Tentang kemampuan untuk ditemukan, kita masih dapat memiliki draw_circle , itu hanya akan menggambar lingkaran, dan bukan disk.

Saya tidak dapat menemukan apa pun yang mendukung ini . Apakah Anda memiliki sumber untuk klaim ini atau itu firasat?

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

1 b : sebuah bidang tertutup (lihat entri bidang 6 pengertian 2b) kurva yang setiap titiknya berjarak sama (lihat pengertian jarak yang sama 1) dari titik tetap di dalam kurva
1 c : permukaan bidang dibatasi oleh kurva seperti itu

(1 b) adalah lingkaran matematika (perimeter), (1 c) adalah piringan matematika (permukaan).

Dalam hal API, IMO lebih ramah pengguna untuk memiliki draw_rect(bool filled) dan draw_circle(bool filled) daripada draw_rect() , draw_filled_rect() , draw_circle() dan draw_disk() (atau apa nama matematika untuk persegi panjang yang terisi?).

Sunting: Sebenarnya draw_circle() belum memiliki argumen filled . Saya pikir kita harus menambahkan satu, sehingga dapat digunakan untuk menggambar lingkaran (perimeter) dan disk (lingkaran penuh).

Terima kasih banyak. Sebagian besar siswa saya adalah orang Prancis dan mereka semua bingung dengan ini, begitu juga saya, dan mereka menyalahkan Godot dan saya tidak bisa membiarkan mereka, tentu saja.

apa nama matematika untuk persegi panjang yang diisi?

Itu pertanyaan yang cukup bagus; yang bisa saya temukan hanyalah "area persegi panjang" atau "interior persegi panjang", dan tidak ada yang memadai. Wiki bahkan menyatakan bahwa kebanyakan orang menyalahgunakan istilah _poligon_ untuk mengartikan _interior poligon_, tanpa memberikan kata lain untuk itu.

Saya kira argumen filled dapat membantu meringankan ambiguitas, tetapi akan sulit untuk memutuskan di mana harus memasukkannya ke dalam daftar argumen.

@Goutte tetapi akan sulit untuk memutuskan di mana harus memasukkannya ke dalam daftar argumen.

Karena ini adalah argumen opsional (memiliki nilai default), dan juga untuk konsistensi dengan draw_rect , itu harus di akhir.

Ada kasus di mana node Kontrol dirujuk sebagai node Modal. https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal Sebagian besar terkait dengan fungsi Viewport.get_modal_stack_top()

EditorInterface 's get_selected_path dan get_current_path metode membingungkan dalam nama dan fungsi. Mereka juga kekurangan dokumentasi.

Metode ini hanyalah lapisan tipis di atas metode FileSystemDock dengan nama yang sama:

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;
}

Mereka berdua harus mengadaptasi "terpilih" atau "saat ini" (atau sesuatu yang lain, tetapi untuk keduanya) dengan yang satu get_*_path dan yang lainnya get_*_dir .

@Goutte Bukankah Solid Rectangle merupakan alternatif untuk persegi panjang yang diisi?

Apakah OP akan diperbarui dengan saran yang diposting setelah Juni 2019? Saya mengerti bahwa ini banyak pekerjaan, tetapi jenis pelacak ini juga sempurna untuk ditangani bersama oleh kontributor. Dan saya berasumsi sudah saatnya kita bisa mulai mengganti nama lebih banyak barang?

Memperbarui OP juga berarti bahwa saran yang diposting diterima sebagai bermanfaat oleh tim.

@Anutrix "diisi" adalah kata yang lebih baik untuk digunakan daripada "padat", karena "padat" dapat berarti "bukan cair atau gas".

@pycbouh Ini juga merupakan ide bagus untuk menautkan PR untuk setiap masalah jika ada. OP sudah melakukan ini, tetapi tidak untuk komentar di bawahnya.

Saya tidak tahu apakah itu dinaikkan , tetapi saya tidak menyadari seberapa sering saya berhenti untuk mengintip ke dalam dokumen untuk yang satu ini:

• Array.remove => remove_at (seperti C#) untuk dihapus berdasarkan indeks
• Array.erase => remove_value , atau hanya remove (seperti C#) untuk dihapus berdasarkan nilai

(atau variannya dengan erase )

Karena sekarang, erase dan remove artinya sama bagi saya, kecuali satu berdasarkan indeks, yang lain berdasarkan nilai, saya terus lupa yang mana.

Dibesarkan sudah, saya buruk. Tidak menyadarinya, Github sedang melipat utasnya, pencarian Ctrl+F saya melewatkannya xD
Belum di OP

@Zylann Ini dia: https://github.com/godotengine/godot/issues/16863#issuecomment -441376010

Menempatkan Zylann, saya terus lupa bahwa penghapusan adalah dengan indeks ...

Enum ButtonList kemungkinan harus diganti namanya menjadi MouseButtonList karena itu adalah tombol mouse.

Haruskah enum JoystickList dipecah? Ini berisi tombol dan sumbu, mungkin lebih masuk akal sebagai JoypadButtonList dan JoypadAxisList atau serupa.

Hanya sebuah pertanyaan, mengapa tidak MouseButton ?
jika tombol == MouseButton.LEFT:
membaca lebih baik dari
jika tombol == MouseButtonList.LEFT:

Ide bagus. Dalam hal ini, ada juga KeyList -> Key , MidiMessageList -> MidiMessage , dan joystick harus List dihapus .

Saya perhatikan beberapa metode/properti menggunakan normal_map , sedangkan yang lain menggunakan normalmap . Kita harus menyelesaikan salah satu dari ini, tetapi mungkin tidak keduanya. Saya lebih suka normal_map , tapi saya juga setuju dengan normalmap .

Skrip GD

range_lerp() = peta()
benih = set_seed()

map() mungkin dicadangkan untuk fitur pemrograman fungsional baru.

Vector2.tangent() dijelaskan dalam dokumen sebagai: Returns a perpendicular vector. , itulah definisi orthogonal atau orthonormal jika vektor yang dikembalikan dinormalisasi. Karena Vector2.tangent() mengembalikan vektor yang tidak dinormalisasi, saya mengusulkan agar kita mengganti namanya menjadi Vector2.orthogonal() atau bahkan Vector2.perpendicular() jika orang menentang tata nama matematika atau bahkan mungkin Vector2.normal() , tetapi orang mungkin bingung antara normalized() dan normal()

Anekdot di pihak saya, tetapi pertama kali saya mencari ini, pencarian pertama saya di dokumen adalah untuk _tegak lurus_.

Anda juga dapat menyimpan .tangent() hanya sebagai alias untuk .perpendicular() , bukan?

Saya tidak suka nama orthogonal karena itu bukan kata bahasa Inggris yang umum dibandingkan dengan yang lain. Saya tidak melihat masalah dengan tangent sebelumnya, tetapi saya pikir perpendicular adalah nama yang lebih baik.

Ya, ortogonal jarang terjadi. Saya memilih .perpendicular() tapi MENJAGA tangen() alias untuk compat juga, itu lebih pendek.

@ Zireael07 Saya lebih suka jika kita hanya memiliki satu cara untuk mendapatkan garis singgung. Saya tidak berpikir itu adalah operasi yang sangat umum.

Anda akan terkejut betapa sering saya menggunakannya dalam skrip procgen saya :)

Saya tidak mengharapkan ini untuk menimbulkan perdebatan, tetapi saya pribadi menentang mempertahankan Vector2.tangent() karena ini adalah penggunaan istilah matematika yang biasa yang salah. Produk dari Vector2.tangent() hanya salah menurut definisi. Nama utas ini adalah kerusakan kompatibilitas yang direncanakan berikutnya jadi saya tidak melihat alasan mengapa kita harus berusaha sekuat tenaga untuk menjaga kompatibilitas. Saya pribadi baik-baik saja dengan Vector2.perpendicular() .

Saran: buat parameter find_node() 's owner salah secara default.

Saran: ganti nama metode/sinyal Tree agar tidak terlalu membingungkan sehubungan dengan misalnya istilah/status "terpilih", "fokus", dan "tidak ada".

Saya pikir Tree::ensure_cursor_is_visible menyesatkan dan harus diganti namanya menjadi ensure_focused_item_visible atau ensure_selected_item_visible .

Bahkan referensi kelas mengatakan:

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() secara khusus mengembalikan tipe asli di bawahnya. Sekarang setelah kami menamai kelas skrip, lebih masuk akal jika ini diganti namanya menjadi get_native_type() karena "basis" skrip berpotensi menjadi nama skrip. Ini menyesatkan.

@willnationsdev Ada juga get_class() https://github.com/godotengine/godot/issues/16863#issuecomment -491421079

@aaronfranke Nah, dengan get_class() secara universal digunakan untuk merujuk ke "apa nama benda yang sedang saya lihat?". Jadi, dalam kasus Script , saya berharap untuk mendapatkan kembali "GDScript" , "CSharpScript" , atau sesuatu seperti itu. Tapi ya, dengan kelas non- Script , itu harus menjadi metode yang mengembalikan nama kelas skrip yang sebenarnya jika diberi nama. Bahkan ada masalah khusus untuk itu. https://github.com/godotengine/godot/issues/21789#issuecomment -618588900

Sunting: Oh, saya kira, jika kita memiliki get_class() , get_base_class() , dan get_native_class() , Anda benar-benar membutuhkan get_instance_base_type() untuk menjadi get_instance_native_class() untuk tetap dengan konvensi penamaan dan klarifikasi bahwa itu adalah instance daripada info skrip.

Saya pikir autotile_coord (properti dan metode) dari TileMap harus diganti namanya menjadi tile_coord atau tile_coordinate karena AUTO_TILE dan ATLAS_TILE gunakan ini dan namanya mungkin membingungkan bagi pengguna baru. Dokumen juga memerlukan pembaruan. Saya dapat membuat perubahan ini jika tidak ada masalah.

Pertimbangkan untuk menghapus argumen new_text dari LineEdit.text_changed karena memiliki perilaku yang sama dengan LineEdit.text .

Pertimbangkan juga untuk menambahkan old_text sebagai tambahan atau sebagai pengganti new_text .

Terkait dengan https://github.com/godotengine/godot/issues/16863#issuecomment -394745886

Ganti nama " lapisan tabrakan", " lapisan VisualInstance", " lapisan render", dll menjadi
" grup tabrakan", " grup VisualInstance", " grup render", " grup ringan"

Kebingungan tentang mengapa "Lapisan" itu tidak menumpuk muncul seperti jarum jam di saluran komunitas.

Perhatikan bahwa mereka disebut lapisan di Maya, Lumberyard dan Unity.

Hanya karena orang lain melakukan sesuatu bukan berarti itu tetap tidak menyebabkan
kebingungan dan merupakan ide yang bagus.

Pada Senin, 18 Mei 2020, 13:09 Pemberitahuan [email protected] menulis:

Perhatikan bahwa mereka disebut lapisan di Maya, Lumberyard dan Unity.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

Saya terkejut bahwa belum ada yang menyebutkannya buuut
Camera2D.zoom
kamera diperkecil ketika zoom lebih besar, yang bukan cara kerja "zoom" dan itu kontra-intuitif. Tidak yakin apa namanya, mungkin view_scale atau yang serupa.

@KoBeWi Alih-alih mengganti nama zoom , bukankah seharusnya kita membalikkan skalanya sehingga memperbesar ketika Anda meningkatkan nilainya?

Ini akan merusak kompatibilitas seperti mengganti nama properti. Jika kita menggunakan rute "skala terbalik", sayangnya tidak dapat diperbaiki secara otomatis. Namun, itu mungkin menghasilkan lebih sedikit kebingungan dalam jangka panjang.

@Calinou @KoBeWi Apakah ada kasus penggunaan untuk menggunakan properti zoom ini secara langsung, atau apakah semua orang perlu membalikkannya setiap kali untuk menerapkan skala?

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

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

Mungkin, tapi di mana kita menarik garis dengan itu dan sesuatu seperti Node2D.get_position_2d() ?

Mungkin kita bisa memberi nama kelas Viewport2D tapi itu tidak akan diperlukan kecuali kita membuat Viewport3D.

@nathanfranke Saya mengusulkan metode ini karena dalam namanya saja tidak ada cara untuk mengetahui apakah itu 2D atau 3D, mengingat ada 2 jenis Transform . (Sementara anggota lain sudah memiliki canvas_ atau mouse_ )

@Zylann Metode ini sebenarnya sangat aneh. Ada properti yang disebut canvas_transform dan global_canvas_transform , dan deskripsi canvas_transform adalah ini:

Transformasi kanvas dari viewport, berguna untuk mengubah posisi di layar dari semua CanvasItems anak. Ini relatif terhadap transformasi kanvas global dari viewport.

Jadi, Anda akan mengharapkan get_final_transform untuk menggabungkan kedua transformasi ini. Namun, jika Anda melihat kodenya, sebenarnya bukan itu fungsinya.

Kode untuk ini adalah return stretch_transform * global_canvas_transform; . Saya sudah mencoba mencari tahu untuk apa stretch_transform itu dan saya tidak tahu, itu tidak diekspos, dan tentu saja tidak disetel ketika mengubah canvas_transform . Ada juga metode yang disebut _stretch_transform yang tidak menggunakan stretch_transform . Itu disebut oleh set_size , yang mengambil nilai yang dihasilkan oleh _stretch_transform dan menetapkannya ke stretch_transform . Ada juga canvas_transform_override yang bahkan belum saya sebutkan dan tidak diekspos, tetapi digunakan secara internal.

Pada akhirnya saya pikir seluruh kelas ini harus dilihat. Viewport memiliki 4 anggota Transform2D yang berbeda, 4 anggota Rect2(i), 9 anggota Vector2(i), dan 2 anggota Transform (3D). Itu sudah 264 byte (dengan float presisi tunggal) dari hanya struktur data yang menyimpan informasi transformasi, jika Anda menambahkan semua pointer dan semacamnya, itu mungkin mendekati 1 KB. Mungkin Viewport memang membutuhkan semua ini, tetapi tampaknya terlalu rumit, dan setidaknya harus ada komentar (terlalu sedikit dalam file ini).

Haruskah Node2D/Node3D to_global dan to_local dihapus? Saya memberikan umpan balik pada #38902 yang mengusulkan metode penambahan yang hanya berfungsi dengan basis, tetapi ada beberapa masalah dengan ini.

Dalam proyek demo, to_local tidak digunakan di mana pun, dan $ grep -RIn "to_global" hanya mengembalikan 5 hasil, semuanya ada di GUI dalam demo 3D, dan kinerja demo dapat ditingkatkan dengan mengubah ini sehingga men-cache transformasi global dan menggunakan xform alih-alih menggunakan to_global .

Singkatnya, kekhawatiran dengan metode ini adalah keduanya jarang digunakan, dan juga bahwa mereka mendorong penulisan kode yang berkinerja buruk karena menghitung ulang transformasi global beberapa kali.

27509

AnimationPlayer 's animation_started dan animation_finished agak kontra-intuitif. Yang pertama dipanggil untuk semua animasi dalam antrian sedangkan yang terakhir hanya dipanggil untuk mencapai akhir antrian. Itu tidak disebutkan dengan jelas dalam dokumentasi.

Jika kita ingin mendeteksi kapan animasi tertentu berakhir, kita harus menggunakan animation_changed dan animation_finished yang tidak nyaman.

Saya sangat menyukai saran @txigreman dari masalah itu: Kita dapat menggunakan animation_finished setiap kali animasi dalam antrian berakhir dan menambahkan sinyal baru animation_all_finished (mirip dengan Tween ' s tween_all_completed ) yang diaktifkan hanya ketika kita mencapai akhir antrian.

Bagaimana dengan animation_queue_finished dan/atau animation_queue_started ?

Saya tidak dapat menemukannya di sini jadi saya akan mengusulkan,
Pasangan find dan findn .

gambar dari 3.2 build stabil terakhir.

Mungkin kita bisa mengganti nama satu untuk menyebutkan sifat mereka dalam menangani sensitivitas kasus.

Katakanlah, find_ignorecase bukannya findn ?

@swarnimarun Kami memiliki banyak metode case-insensitive lainnya yang diakhiri dengan n . Jika kita mengganti nama salah satunya, kita harus mengganti nama semuanya.

Metode-metode ini ( find / findn dll.) pada dasarnya melakukan hal yang sama. Kami hanya bisa menambahkan argumen apakah mereka harus peka huruf besar-kecil atau tidak.

@Calinou Saya lebih suka itu, menggunakan GDScript setelah menjatuhkannya selama beberapa bulan agaknya telah memberi saya perspektif baru ke API yang akan saya katakan,

Semakin jelas semakin baik. Mengingat API untuk semuanya itu sulit sendiri, sedikit lebih banyak verbositas dalam penamaan fungsi sepertinya merupakan perubahan yang waras.

@KoBeWi dapat mengetahui dengan nama fungsi apa yang dilakukannya daripada harus mengingat untuk menambahkan bidang lain atau saat membaca kode (setelah lupa/tidak mengetahui bagian API itu) cukup dihargai.

Jadi saya masih lebih suka fungsi yang berbeda, bahkan jika fungsi lain hanya memanggil yang pertama dengan argumen yang berbeda atau sesuatu.

EditorInterface.get_editor_viewport() => get_editor_main_container()

Fungsi ini tidak mengembalikan Viewport , hanya Control yang kebetulan menjadi pusat yang memegang 2D, 3D, editor Skrip dan Pustaka Aset. Sebagai catatan, simpul yang dikembalikan bahkan VBoxContainer* , tetapi diabstraksikan (namun penting untuk diketahui, karena itu memengaruhi pilihan pengaturan Anda).
Doc juga salah, karena deskripsinya tertaut ke kelas Viewport . https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class -editorinterface-method-get-editor-viewport

@Zylann Harus get_editor_main_screen() karena ini bukan Wadah, tapi layar utama .

@aaronfranke yang juga merupakan node Container , sebenarnya^^ tapi ya... layar utama juga bisa bekerja

Saya ingin bertanya: apakah ada yang melacak proposal dalam topik ini?

Misalnya, di atas (https://github.com/godotengine/godot/issues/16863#issuecomment-557657413) saya mengusulkan penggantian nama metode JSON.print . Beberapa opsi disarankan, tetapi tidak ada yang muncul di posting pertama.

Saya hanya khawatir bahwa ide-ide yang berguna hilang dalam banyak posting. :senyum:

@dalexeev Saya baru-baru ini melakukan pass pertama untuk memperbarui posting pertama, tetapi saya belum membaca semua komentar.

Saya punya satu yang berpotensi memperbaiki beberapa bug di RichTextLabel . Saat ini kami memiliki bbcode_text dan text , tetapi keduanya menggunakan struktur data yang sama secara internal. Hanya metode yang dipanggil yang berbeda, sementara set_bbcode kembali ke set_text ketika use_bbcode tidak diaktifkan. Jadi saya melanjutkan dan menghapusnya di #39148. Saya menambahkan beberapa poin lain di sana.

GetSceneInstanceLoadPlaceholder() di Node terlihat sangat salah, pertama tidak mengembalikan placeholder seperti namanya, tetapi bool dan kedua ini membocorkan detail implementasi yang diwarisi ke kelas dasar tanpa persyaratan nyata (menguji tipe dari node dimungkinkan dengan cara lain)

RayShape → SeparationRayShape , seperti yang disarankan pada awalnya di godotengine/godot-proposals#711.

Bagaimana dengan menghapus sort_custom dan membuat sort menggunakan Callable opsional?

Haruskah kita menghapus OS.get_ticks_msec() dan OS.delay_msec() -masing demi OS.get_ticks_usec() dan OS.delay_usec() ? Ini akan menghindari memiliki dua cara untuk mencapai hal yang sama. Jika Anda membutuhkan nilai dalam milidetik, Anda dapat mengalikannya atau membaginya dengan 1000.

Juga, baik GDScript dan C++ memungkinkan penambahan pemisah dalam literal integer, yang membuat nilai besar lebih mudah dibaca.

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

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

Juga, baik GDScript dan C++ memungkinkan penambahan pemisah dalam literal integer, yang membuat nilai besar lebih mudah dibaca.

Jika penghapusan terjadi, deskripsi get_ticks_usec() harus menyebutkan pemisah.

@Calinou Di satu sisi, Anda benar, tetapi di sisi lain - dalam banyak kasus, akurasi tinggi seperti itu tidak diperlukan.

'Alpha scissor' dalam materi spasial harus menjadi 'alpha clip' standar

@Flavelius Saya belum pernah melihat istilah "klip alfa" sering digunakan. Saya telah melihat "tes alfa" digunakan lebih sering daripada "klip alfa" dan "gunting alfa" pasti.

Banyak hal yang harus diubah! Apakah seseorang bekerja untuk mengimplementasikan saran-saran ini?

@MCrafterzz Orang-orang membuka permintaan tarik untuk mengganti nama sesuatu secara teratur. Ini dilakukan secara bertahap, bukan sekaligus.

Tekstur (Tekstur2D) dan Gambar

• get_data() dalam Tekstur (Texture2D) harus diberi nama get_image() dan get_data() dalam Gambar harus diberi nama get_bytes() untuk mendeskripsikan diri sendiri.

IMO: get_image ya, get_bytes tidak.

texture.get_image().get_data()

Mesh / Instance Mesh

• Di Mesh Anda mendapatkan/mengatur Bahan dengan metode tersebut:
  surface_get_material/surface_set_material
• Di MeshInstance Anda mendapatkan/mengatur dengan metode-metode itu:
  get_surface_material/set_surface_material

Seharusnya penamaan yang sama kurasa?

@Coldragon Seharusnya get_surface_material / set_surface_material dan properti surface_material .

@Coldragon Seharusnya get_surface_material / set_surface_material dan properti surface_material .

Ini bukan set/get "normal", mereka memiliki indeks untuk Surface target (ini adalah kelas Vector di dalam Mesh)

Array kita harus mengganti nama empty() menjadi is_empty() untuk lebih menggambarkan boolean

String kita harus menjatuhkan find_last() demi rfind() . Bukan ganti nama, tapi masih layak didiskusikan mana yang harus disimpan.

Untuk nomor tunggal, kami memiliki stepify . Untuk Vector2/Vector3, kami memiliki snapped .

Mereka melakukan hal yang sama, vektor memanggil stepify untuk setiap komponen. Satu nama harus dipilih, tapi yang mana?

Poll: :heart: = keduanya harus stepify , :rocket: = keduanya harus snapped , :-1: = jangan ganti nama.

AABB memiliki intersection , sedangkan Rect2 memiliki clip . Mereka melakukan hal yang sama. Satu nama harus dipilih, tapi yang mana?

Poll: :heart: = keduanya harus intersection , :rocket: = keduanya harus clip , :-1: = jangan ganti nama.

@aaronfranke ya, saya sebelumnya menyarankan nama intersection di https://github.com/godotengine/godot/issues/16863#issuecomment -449628319. Kami kemudian memiliki intersects yang dapat diubah namanya menjadi overlaps di Rect2 , tetapi tidak yakin tentang AABB mengenai intersects → overlaps ganti nama.

Saya pikir find_node dan/atau get_node harus diganti namanya karena namanya sama sekali tidak menunjukkan perbedaan antara keduanya.
Karena find_node hanya melihat anak-anak, mungkin find_child_node?
Saya tidak yakin apa nama alternatif yang bagus untuk get_node. Pikiran pertama saya adalah get_tree_node karena bisa mendapatkan simpul dari mana saja di pohon, tetapi juga bisa digunakan di luar pohon adegan dengan jalur relatif.

Saya menemukan get_node bagus, tetapi find_node dapat diganti namanya find_child

@MuffinManKen Saya pikir get_node sangat dapat dimengerti karena, seperti yang Anda nyatakan, ia dapat mengambil simpul apa pun, di mana saja, selama itu terhubung dengan pohon yang sama dengan simpul yang diberikan, terlepas dari apakah mereka bagian dari SceneTree atau tidak.

@Coldragon Saya tidak yakin saya suka mengganti nama find_node menjadi find_child juga, karena itu memberi saya kesan bahwa itu hanya berfungsi dengan anak-anak langsung untuk beberapa alasan. Alternatifnya adalah membuatnya disebut find_descendant atau sesuatu, tapi itu terlalu bertele-tele/rumit. Memotongnya menjadi hanya find() juga tidak masuk akal karena tidak jelas apa yang kita cari. Karena itu, saya pikir kecuali jika alternatif lain dicari, find_node harus tetap seperti itu juga. Seharusnya hanya ada perbedaan perilaku yang terdokumentasi dengan jelas untuk dokumen API.

Di Godot 3.1, saya menambahkan tag fitur standalone yang bernilai true ketika proyek dijalankan dari biner templat ekspor (debug atau rilis). Kebalikannya adalah editor , yang dievaluasi menjadi true ketika proyek dijalankan dari biner editor.

Namun, seiring waktu, saya pikir akan lebih baik untuk mengganti nama standalone menjadi runner karena lebih pendek dan sedikit lebih jelas. Bagaimana menurutmu?

Bagaimana dengan exported atau release ?

@aaronfranke exported menyiratkan proyek telah diekspor, yang belum tentu demikian. Anda dapat menggunakan biner templat ekspor untuk menjalankan proyek langsung dari file sumbernya, selama aset diimpor sebelumnya.

Juga, release sudah digunakan untuk binari mode rilis (berbeda dengan debug , yang digunakan untuk binari mode debug).

runner tampaknya tidak terlalu jelas bagi saya. standalone -baik saja. Menghapusnya juga tidak masalah, karena Anda bisa menggunakan !OS.get_feature("editor") .

Menghapusnya juga tidak masalah, karena Anda bisa menggunakan !OS.get_feature("editor") .

Ini tidak dapat digunakan untuk mengesampingkan pengaturan proyek, karena tidak ada pemilih .not sana. Ini mungkin layak dengan menukar pengaturan default dan penggantiannya, tetapi rasanya sedikit lebih berbelit-belit.

Mengapa tidak app atau game sebagai kebalikan dari editor ? Atau justru akan lebih membingungkan? Mungkin memiliki tanda fitur untuk no-editor agar lebih eksplisit?

@willnationsdev game menyiratkan bahwa Godot hanya dapat digunakan untuk game. Banyak orang yang berhasil menggunakan Godot untuk aplikasi non-game, jadi saya lebih suka menggunakan istilah yang lebih inklusif :slightly_smiling_face:

Juga, itu tidak terlalu jelas: orang mungkin berpikir itu masih berlaku untuk proyek yang dijalankan dari editor (bagaimanapun juga Anda menjalankan "permainan" dari editor). Hal yang sama berlaku untuk app .

Bagaimana dengan "mandiri"?

Pada Sabtu, 25 Juli 2020, 5:49 pagi Hugo Locurcio, [email protected]
menulis:

@willnationsdev https://github.com/willnationsdev game menyiratkan Godot
hanya bisa digunakan untuk game, yang terbukti tidak demikian

Juga, itu tidak terlalu jelas: orang mungkin masih berpikir begitu
berlaku untuk proyek yang berjalan dari editor. Hal yang sama berlaku untuk aplikasi.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
.

@MuffinManKen independent juga tidak terdengar cukup jelas bagi saya.

Editor vs standalone mungkin penamaan standar (setidaknya satu yang saya lihat di banyak mesin yang berbeda) jadi tidak ada alasan untuk menemukan kembali roda imho.

Get_node tidak terbatas untuk mendapatkan keturunan, jadi itu akan sangat
nama yang menyesatkan. 2 metode membutuhkan nama yang sangat berbeda karena apa yang mereka?
lakukan sangat berbeda.

Pada Sabtu, 25 Juli 2020, 15:14 golddotasksquestions, <
[email protected]> menulis:

Saya ingat kebingungan yang saya miliki untuk waktu yang lama pada awalnya dengan
find_node dan get_node. Saya sangat ingin find_descendant dan
get_descendant, karena ini benar dan informatif @willnationsdev
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
The "bertele-tele" mungkin bukan teh untuk semua orang, tetapi saya tidak benar-benar
masalah karena ada pelengkapan otomatis dan singkatan "$".

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
.

Saya pikir dalam metode Transform dan Transform2D inverse dan xform_inv harus diganti namanya / dihapus karena apa yang sebenarnya dilakukan metode ini bukanlah apa yang orang harapkan dari mereka . Lebih detail: https://github.com/godotengine/godot/issues/39433#issuecomment -664024521.

RayCast.cast_to harus diganti namanya menjadi RayCast.segment atau apalah. Saya baru saja mendengar seseorang mengatakan bahwa dia membutuhkan waktu 40 menit untuk menyadari bahwa itu adalah properti dan bukan fungsi. Mungkin karena itu kata kerja juga.

Bagaimana dengan RayCast.target ?

@razcore-art Saya baru-baru ini menjawab pertanyaan terkait dengan ray casting , dan saya menggunakan kata segment untuk menggambarkannya, jadi saya pikir masuk akal. Tapi ini juga bisa ditulis ulang sebagai direction dan length , jadi itu benar-benar akan menjadi sesuatu yang lebih dekat ke sinar daripada segmen, berbicara secara geometris (atau hanya memberikan properti alternatif yang bisa hidup berdampingan) . Masalahnya adalah tidak ada cara untuk mengatur vektor arah yang dinormalisasi dengan mudah di inspektur. Saya menulis proposal untuk membuatnya, setidaknya untuk 2D: godotengine/godot-proposals#397, tapi mungkin itu terlalu berlebihan.

EDIT: Setelah berpikir lebih jauh, segment tidak akan masuk akal dalam hal RayCast node , tetapi masuk akal dalam hal Physics2DDirectSpaceState.intersect_ray() .

Bagaimana dengan RayCast.target ?

@nathanfranke Saya akan menganggap target sebagai Node atau NodePath . Jadi setidaknya ini bisa menjadi RayCast.target_position . Mungkin RayCast.cast_position atau RayCast.cast_offset . Jangan lupa bahwa pancaran sinar dapat berputar, yang dapat menggeser posisi pancaran aktual dalam koordinat global.

PhysX API mengonfirmasi ide saya tentang arah unit + panjang untuk mengonfigurasi raycast. 😛

Yang mengatakan, saya condong ke arah cast_position ... Karena menulis ulang cara kerja ray casting membutuhkan lebih banyak perubahan inti.

@Xrayez Saya akan menghindari penggunaan kata "cast" di awal properti, karena saya secara alami membacanya sebagai kata kerja "cast" dan bukan kata benda "cast", dan oleh karena itu cast_position kemungkinan tidak akan memiliki memecahkan masalah awal tidak mengetahui ini adalah properti dan bukan metode (akan mudah untuk mengasumsikan cast_position adalah metode yang dilemparkan ke suatu posisi). Saya suka target_position .

Dari https://github.com/godotengine/godot/issues/19325#issuecomment -394155128:

Dapat mengganti nama KEY_BACK menjadi KEY_MEDIA_BACK dan KEY_FORWARD menjadi KEY_MEDIA_FORWARD . Mungkin ada kunci media lain yang dapat menggunakan awalan MEDIA .

Kita harus mempertimbangkan untuk mengubah String begins_with() menjadi starts_with() .

Begitulah di Java, C#, Python, JavaScript, dll.

Pengeditan bugsquad: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool , float , int adalah satu-satunya tipe/kelas yang namanya dimulai dengan huruf kecil. Saya pikir mereka harus diganti namanya (dalam GDScript) menjadi Bool , Float , Int . Ini akan secara otomatis memperbaiki masalah dengan penyorotan sintaks jenis yang salah.

Dan bool , float , int harus digunakan hanya untuk fungsi seperti Python bawaan dari halaman len dan str ).

Perhatikan bahwa situasinya mirip dengan str / String : str(x) dan String(x) memberikan hasil yang sama.

MENAMBAHKAN. Seharusnya terlihat seperti ini:

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

@dalexeev Mereka adalah huruf kecil karena mereka adalah tipe primitif. Anda akan melihat ini di sebagian besar bahasa lain.
Kelas seperti Node adalah tipe referensi dan tidak menyalin tugas.

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

Jika ada, kita harus mempertimbangkan untuk mengganti nama String menjadi string karena String tidak dapat diubah dan berperilaku lebih mirip dengan int daripada mengatakan Node .

Redaksi ini untuk saat ini, karena itu juga akan terjadi pada Vector2 , Vector3 , dll.

@nathanfranke Dalam bahasa yang berbeda itu berbeda. Misalnya, di Kotlin, Haxe, Ada nama semua jenis ditulis dengan huruf besar.

Selain itu, primitif adalah konsep kondisional. Bagi saya String , Color , Vector2 , dll. adalah tipe primitif, terutama karena diteruskan dengan nilai dan bukan dengan referensi.

Satu-satunya kendala adalah pelanggaran kompatibilitas ke belakang.

karena String tidak dapat diubah

Anehnya, string dalam GDScript bisa berubah:

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

Vector2 bukan primitif karena disusun oleh 2 float . Namun, Vector2 dan float built-in jenis varian.

@Zylann Apakah ini perbedaan mendasar sehingga harus tercermin dalam nama tipe?

(Bagi saya, 'primitif' adalah 'sederhana', bukan 'satu potong'.)

Saya tidak ingin menafsirkan ini untuk kepentingan saya, tetapi:

nama tipe primitif ditulis dengan huruf kapital. :senyum:

Berikut adalah istilah yang saya pahami:

| Ketik nama | Tipe primitif | Jenis nilai | Jenis yang bisa berubah | Tipe bawaan |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| int | Ya | Ya | T/A | Ya |
| Vektor2 | Tidak | Ya | T/A | Ya |
| simpul | Tidak | Tidak | Ya | Ya |
| String | Tidak | Tidak | Tidak | Ya |

Apapun, nama-nama ini tidak akan berubah. Mereka baik-baik saja, dan akrab bagi programmer dari berbagai bahasa. Kita harus mengakhiri diskusi di sini untuk menghindari mengisi pelacak ini dengan diskusi yang tidak berguna.

Kolom tipe Mutable salah: hanya Object-derived, Dictionary, dan Array yang bisa berubah. ( Vector2 mungkin terlihat bisa berubah karena Anda dapat melakukan vec2.x = 0 , tetapi sebenarnya diterjemahkan menjadi sesuatu seperti vec2 = vec2.with_x(0) )

Ganti nama ShortCut menjadi Shortcut

Metode berikut harus diubah:
Inkonsistensi antara

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

ke

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

untuk konsistensi dengan
dan

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

perlu dikoreksi.

PS I berangkat dari prinsip "Semakin sedikit metode serupa, semakin baik".

@dalexeev Parameter Boolean seringkali kurang dapat dibaca daripada memiliki metode yang berbeda, karena true dan false tidak memiliki konteks.

Ya, tapi konsistensi juga bagus. Singkirkan parameter boolean di InputEvent?

@Calinou Dalam kebanyakan kasus, Anda tidak perlu memeriksa peristiwa gema.

Saya tidak melihat ini sebagai masalah besar. Saat Anda mengetik kode, petunjuk argumen muncul. Saat membaca kode, Anda dapat menggunakan Shift + Klik. Argumen untuk fungsi yang sering digunakan cepat diingat (misalnya, String.split ).

Selain itu, 208 argumen boolean opsional ditemukan di direktori doc/classes (ini hanya inti, dan juga 16 modul memiliki direktori bersarang 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 dapatkah Anda mempertimbangkan untuk memasukkannya ke dalam spoiler untuk mempermudah pengguliran bagi kami?

@dalexeev Ada banyak kasus di mana Anda perlu memeriksa apakah tombol ditekan dan tidak hanya jika baru saja ditekan. Misalnya, skrip untuk memindahkan karakter perlu melakukannya dengan WASD atau tombol panah. Hampir setiap game perlu memproses input, jadi saya rasa tidak sia-sia hanya memiliki dua metode untuk hal-hal ini.

Saat membaca kode, Anda dapat menggunakan Shift + Klik.

Tidak jika Anda melihat perbedaan di GitHub. Jika kode memerlukan IDE agar dapat dibaca, itu bukan kode yang baik.

@aaronfranke Untuk 207 kasus lainnya, apakah Anda juga menyarankan membuat fungsi terpisah? Jika tidak, maka argumen ini tidak konklusif. Selain itu, saya menulis di atas bahwa jika Anda dapat menentukan nama parameter, maka itu menjadi dapat dibaca tanpa IDE.

Ada banyak kasus di mana Anda perlu memeriksa apakah tombol ditekan dan tidak hanya ditekan saja.

Seringkali, tetapi tidak lebih sering daripada tanpa gema.

Kehadiran tiga metode ( is_action_just_pressed , is_action_just_released , is_action_pressed ) membingungkan karena Anda mengharapkan ada metode is_action_released .

MENAMBAHKAN. Opsi mana yang lebih mudah, setidaknya secara visual?

is_action_released dapat dicapai dengan not is_action_pressed . Ini tidak berlaku untuk metode just .

Seperti disebutkan di atas, bool mentah harus dihindari. Bendera seperti INPUT_ALLOW_ECHO/INPUT_NO_ECHO akan jauh lebih baik daripada bool.

@dalexeev Itu hanya akan menimbulkan kebingungan. is_action_pressed() dan echo adalah 2 hal yang berbeda. Anda dapat memeriksa sendiri bahwa kejadian gema diterima setelah sedikit penundaan setelah penekanan pertama, sementara is_action_pressed() tidak memiliki penundaan.

@KoBeWi Anda mungkin benar dan

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

harus diubah menjadi

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

karena ini tidak sesuai dengan

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 Apa yang Anda usulkan tidak benar. Ketika kita berbicara tentang peristiwa gema, kita berbicara tentang peristiwa keyboard yang berulang sambil menekan tombol, menggunakan istilah di sini tidak masuk akal, karena sistem tindakan tidak bergantung pada peristiwa secara langsung, statusnya diperbarui dalam mode per-bingkai. Selain itu, tindakan juga dapat bekerja dengan perangkat lain seperti pengontrol atau tombol mouse, di mana peristiwa "gema" tidak ada.

get_children() TreeItem hanya mengembalikan anak pertama dan tidak semua anak seperti yang disarankan oleh nama (atau deskripsi dalam dokumen).

[Sunting]
Nvm dokumen. Deskripsi metode diperbarui di master, maaf.

Saya merekomendasikan local_to_scene Resource harus local_to_instance atau unique_per_instance . "Lokal ke Adegan" menunjukkan perilaku sebagai lokal ke adegan, padahal sebenarnya per kejadian adegan.

Ganti nama Image.load() → Image.load_from_file() .

1. Membantu mengurangi kemungkinan kebingungan dengan file load("image.png") melalui kode, lihat perubahan dokumentasi di #42412.
2. Image.load() tidak akan disorot sebagai nama bawaan GDScript lagi: #28866.
3. Konsisten dengan Image.load_*_from_buffer() per format gambar. Metode terkait buffer dapat berpotensi disatukan ke dalam antarmuka yang sama untuk mencegah API mengasapi, tapi itu topik lain untuk diskusi.

@Xrayez Mungkin juga layak untuk menghapus load di GDScript: https://github.com/godotengine/godot-proposals/issues/263

Variabel registering_order dan metode terkait set_registering_order di ProjectSettings tidak digunakan.

RandomNumberGenerator harus diganti namanya menjadi Random dan fungsi acak global seperti randf dan rand_range harus ditinggalkan atau dihapus.

Saya melihat kemungkinan masalah di mana seseorang memanggil fungsi yang tidak dipercaya sementara benih acak ditentukan

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

fungsi acak global seperti randf dan rand_range harus ditinggalkan atau dihapus.

Dibahas sebagai bagian dari godotengine/godot-proposals#1590.

Saya lebih suka metode acak dasar ini berada pada lingkup global untuk aksesibilitas dan tujuan pembuatan prototipe, setidaknya beberapa di antaranya. Tapi seed() dan rand_seed() pasti bisa dihapus.

Sepertinya FuncRef telah menjadi berlebihan sejak Callable ditambahkan.

Saya menemukan metode property_can_revert dan property_get_revert di Inspektur dan melaporkannya di #43078. Namun, saya pikir mereka harus diganti namanya dengan garis bawah utama untuk mengikuti konvensi _get , _set , dan _get_property_list .

EditorImportPlugin dan EditorExportPlugin tampaknya terkait, namun yang satu adalah tentang mengimpor sumber daya dan yang lainnya tentang mengekspor proyek. Saya sarankan kita mengganti nama EditorImportPlugin menjadi EditorResourceImportPlugin atau sesuatu seperti itu.

Sunting: Dan EditorPlugin.add_import_plugin harus diganti namanya juga.

Mengapa tidak ResourceImportPlugin ? Banyak (kebanyakan?) kelas editor belum berisi kata "Editor", seperti SceneTreeDock atau semua hal animasi.

Tracking_status enum di ARVRInterface harus diganti namanya menjadi TrackingStatus , agar konsisten dengan gaya nama enum lainnya.

Melihat ARVRInterface atas, kualitas nama secara umum cukup buruk. Berikut adalah penggantian nama yang saya sarankan juga:

• ar_is_anchor_detection_enabled → anchor_detection_enabled (properti)
• interface_is_initialized → initialized (properti, dapat ditulis ulang lebih lanjut menjadi enabled , karena memiliki setter)
• interface_is_primary → primary (properti)
• get_render_targetsize() → get_render_target_size() (metode)
• uninitialize() → finalize() (metode)

Kalau tidak, dokumentasinya salah. 🙂

Perhatikan bahwa saya belum pernah menggunakan kelas ini sama sekali, tetapi nama-nama itu terlihat aneh hanya dengan melihat kelasnya.

Haruskah kita mengganti nama Control.MOUSE_FILTER_PASS menjadi Control.MOUSE_FILTER_PASSTHROUGH ? Ini akan membuatnya lebih jelas bahwa acara tersebut akan diteruskan melalui node Kontrol ke node yang terletak di bawahnya. Saya tidak yakin apakah itu benar-benar layak untuk diganti namanya.

@Calinou Saya tidak membayangkan itu akan menyakitkan, jadi saya akan mendukung. Seperti yang Anda sebutkan, perubahan itu akan membuatnya sedikit lebih jelas secara sekilas apa yang dilakukan mode filter mouse itu.

@Calinou Saya menemukan perilaku saat ini tidak biasa. Pengaturan adegan ini menghasilkan "Klik Anak2, Klik Adegan"

(Catatan, semua diatur ke Lulus)

:smile: Proposisi A : Mungkin sesuatu seperti Control.MOUSE_FILTER_PASSPARENTS untuk perilaku saat ini, karena kejadian input sepertinya hanya dikirim ke orang tua.

:rocket: Proposisi B : Ubah konstanta menjadi ini:

• BERHENTI: Perilaku Saat Ini - Ambil acara dan hentikan semua propagasi
• PASS_PARENT: Perilaku yang sama seperti PASS saat ini
• PASS_ALL: ABAIKAN, tetapi ambil acara
• ABAIKAN: Perilaku Saat Ini - Jangan mengambil acara, tetapi tetap menyebar

:eyes: Proposisi C : Apakah node mengambil input gui atau tidak tidak terlalu relevan, karena seseorang tidak dapat menghubungkan sinyal apa pun (atau menggunakan flag boolean). Kita dapat mengubah opsi menjadi Control.propagation_mode dan memiliki konstanta berikut:

• TIDAK ADA
• INDUK
• SEMUA

Itu akan terlihat jauh lebih bersih menurut saya.

Itu di luar penggantian nama dan harus didiskusikan sebagai proposal.

Mengapa semua penggantian nama ini begitu panjang? Anda mengubah sesuatu yang sederhana dan pendek menjadi sesuatu yang sangat panjang.

Anda mengubah clip menjadi intersection dua kali lebih panjang untuk mengetik.
Anda juga mengubah Control.MOUSE_FILTER_PASS menjadi Control.MOUSE_FILTER_PASSTHROUGH
dll

Saya lebih suka perubahan verbose yang lebih sederhana dan lebih pendek. Itu nama fungsi bukan juga deskripsi fungsi.

Saya lebih suka perubahan verbose yang lebih sederhana dan lebih pendek. Itu nama fungsi bukan juga deskripsi fungsi.

Nama harus deskriptif sekalipun. Panjangnya juga tidak masalah jika Anda memanfaatkan pelengkapan otomatis (yang sudah ada di editor Godot).

Saya menyebutkannya sekali di IRC dan tidak mendapat balasan, tetapi TextureRect memiliki mode peregangan yang disebut "Scale On Expand (Compat)". Ini terdengar seperti sesuatu yang bisa dihilangkan.

"Kurang bertele-tele" jelas tidak ada dalam menu jika kami ingin memiliki basis kode yang kuat di seluruh proyek Godot kami. Alat pengkodean modern menyediakan pelengkapan otomatis dan fitur cerdas lainnya yang memungkinkan Anda mengetik dengan cepat meskipun namanya panjang. Plus, jika Anda membaca argumen untuk perubahan tersebut, ada tujuan untuk membuat fungsi tersebut tidak terlalu ambigu bagi pengembang yang menggunakannya. Nama pendek mungkin manis, tetapi membingungkan dan kurang mudah ditemukan.

Dan selalu ingat: mengetik kode adalah bagian cepat dari pengembangan perangkat lunak. Membaca dan memahami kode setelahnya jauh lebih penting. Ini seperti mengandung dan membesarkan anak masing-masing.

Saya tidak setuju dengan Anda berdua. Saya adalah pengguna Godot dan saya menggunakan Godot secara khusus karena GDScript singkat dan cepat untuk ditulis. Jika Anda akan membuatnya dua kali lebih lama maka keuntungan kecepatannya hilang karena saya akan dipaksa dua menulis dua kali lebih banyak dan harus menggulir dua kali lebih jauh untuk melihat seluruh baris kode secara horizontal.

Saat Anda membuat kode, Anda tidak ingin mengetik nama fungsi atau variabel yang sangat panjang. Beberapa perubahan yang diusulkan ini menambahkan fungsi dan nama variabel yang sangat panjang demi "kejelasan" dengan mengorbankan yang lainnya. Anda dapat membaca bantuan bawaan jika Anda ragu. Pemrograman Plus adalah tentang mempelajari API. Anda akan selalu mencari fungsi pertama kali Anda menggunakannya terlepas dari namanya. Ambil printf di C singkat dan sederhana. Di Godot Anda akan menamakannya send_formatted_string_to_standard_out. Tidak hanya Anda memaksa semua orang untuk mempelajari kembali api tetapi beberapa dari perubahan ini bahkan tidak memiliki visi yang sama. Sepertinya saya seperti sekelompok besar orang berkumpul dan masing-masing mengubah satu bagian dari mesin.

Ambil Array misalnya
remove -> remove_at Apa yang _at tambahkan di sini? Anda sudah memiliki remove_value. Apa lagi yang bisa Anda hapus?
erase -> remove_value Masih belum cukup jelas. Dari dokumen "Menghapus kemunculan pertama nilai dari larik." Juga orang mungkin berpikir Anda dapat menghapus satu nilai tunggal dari seluruh array. Untuk kejelasan, seharusnya remove_first_occurance_of_value karena itulah fungsi sebenarnya. Jadi Anda membuat fungsinya lebih lama dan sama-sama membingungkan lebih lama.

Anda memiliki remove dan erase dua fungsi yang berbeda tetapi Anda mengubah keduanya dalam variasi yang sama pada remove dengan huruf tambahan. Tetapi mereka berfungsi bekerja secara berbeda. Hapus menghapus dari indeks tertentu di mana sebagai menghapus menghapus contoh pertama dari nilai yang ditemukan.

Ini tidak apa-apa hanya saja tidak terlalu berguna selain memaksa orang untuk memperbarui kode mereka.
membalikkan -> membalikkan
duplikat -> klon
kosong -> is_kosong

Jika tidak rusak jangan diperbaiki.

@CarlGustavAlbertDwarfsteinYung tetapi Anda tidak akan mengetik dua kali lebih banyak. Setelah 3 huruf pertama Anda mengetik autocopletion akan menendang dan Anda memilih apa yang Anda butuhkan daripada mengetik seluruh kata.

Adapun nama lain misalnya ketika Anda melihat empty -> is_empty perubahan diperlukan untuk memberikan klarifikasi tentang apa yang dilakukannya. Ketika Anda melihat empty dapatkah Anda mengetahui apakah ini adalah metode yang mengosongkan sesuatu, apakah ini buku yang memeriksa apakah ada yang kosong, apakah itu sesuatu yang lain? Dengan is_empty Anda dapat melihat sekilas bahwa ini adalah bool yang benar jika ada sesuatu yang kosong dan salah jika tidak. Anda harus tahu fungsi atau variabel apa yang dilakukan hanya dengan membaca namanya. Anda tidak dapat melakukannya dengan nama seperti empty

@Feniks-Gaming Saya dapat memberitahu Anda kosong atau is_empty sama-sama membingungkan hanya satu lebih panjang dari yang lain.

@CarlGustavAlbertDwarfsteinYung empty dapat berupa tindakan jika dibaca sebagai kata kerja. is_empty jelas merupakan kualitas. Tentu saja kebingungan itu mungkin tergantung pada tingkat bahasa Inggris Anda.

Juga, bahkan jika suatu fungsi dipanggil send_formatted_string_to_standard_out dalam editor kode modern, itu dapat diketik sebagai sfstso , atau kombinasi huruf perantara lainnya, jika Anda menginginkannya dan pelengkapan otomatis akan memberi Anda satu-satunya pilihan.

@pycbouh Orang-orang telah menggunakan mesin ini selama berapa tahun sekarang? Dan saya belum pernah mendengar satu orang pun datang kepada saya mengatakan Anda tahu apa masalah terbesar dengan mesin ini. Fakta bahwa array memiliki empty bukannya is_empty .

Kalian duduk di sini memperbaiki hal-hal yang tidak diinginkan atau diminta siapa pun. Ya, kata-katanya membingungkan tetapi sebenarnya bukan masalah dan tidak pernah menjadi masalah sejak saya mulai menggunakan mesin ini pada tahun 2015. Beberapa perubahan yang diusulkan cukup diterima dan sejujurnya saya menggunakan is_ . Kosong akan baik-baik saja. Tetapi beberapa perubahan terlalu panjang dan sama-sama membingungkan. Saya secara khusus berbicara tentang perubahan itu tidak semua.

Seluruh keberadaan megathread ini adalah bukti bahwa orang-orang memintanya. Masalah ini mungkin tidak signifikan bagi Anda atau orang lain, tetapi orang memiliki masalah dalam memahami API karena penamaan yang buruk. Dan ini adalah jenis masalah yang dikumpulkan oleh masalah ini. Adapun pentingnya perubahan ini secara keseluruhan, percaya atau tidak, tetapi pelacakan dan penerapan ini tidak menghilangkan waktu pengembangan lainnya.

Dan lihat contoh yang Anda berikan dan coba jelaskan:

Hapus menghapus dari indeks tertentu di mana sebagai menghapus menghapus contoh pertama dari nilai yang ditemukan.

Anda menulis itu dan tidak melihat alasan untuk meningkatkan penamaan menjadi setidaknya sedikit lebih jelas untuk semua pengguna Godot saat ini dan masa depan ?

@pycbouh Dan sebenarnya saya bahkan memberikan contoh array remove_at dan remove_value . remove_value tidak sama dengan deskripsi penghapusan dan masih sama membingungkannya. Hapus nilai dari mana? Hapus nilai dari akhir, rmeove dari awal? Hapus semua kemunculan nilai dari array?

jika Anda benar-benar perlu mengubah sesuatu gunakan remove dan remove_first_occurence yang membuatnya singkat dan deskriptif.

@pycbouh saya tidak memintanya. Adanya thread ini karena beberapa orang over engineering dan memperbaiki hal-hal yang tidak dilanggar oleh programmer klasik fashion. Bagaimana dengan pengguna masa depan? Bagaimana dengan mereka? Saya adalah pengguna masa depan sekali dan saya mempelajari api. Saya tidak punya masalah dengan penamaan fungsi. 50% dari komentar adalah orang-orang yang tidak setuju dengan perubahan yang diusulkan. Sepertinya sebagian besar perubahan ini didorong oleh sejumlah kecil anggota komunitas yang mendorong perubahan ini pada semua orang. Bisakah kita memberikan suara pada perubahan yang diusulkan?

Sebenarnya di sini adalah proposal. Setiap perubahan pada penamaan API harus menyertakan pendapat kontributor/donator/pengguna. Jika mereka semua setuju maka saya juga ikut. Memiliki jajak pendapat dan melihat apa yang semua orang hal. Jangan mencoba menebak apa yang orang lain inginkan. Apa yang baik untuk Anda mungkin tidak baik untuk orang lain.

Saya menentang sekitar 50% dari perubahan yang diusulkan di sini dari apa yang saya lihat.

50% dari komentar adalah orang-orang yang tidak setuju dengan perubahan yang diusulkan.

Bisakah kita meninggalkan statistik yang dibuat-buat di depan pintu?

Bisakah kita memberikan suara pada perubahan yang diusulkan?

Itulah gunanya diskusi dan reaksi.

Saya menentang sekitar 50% dari perubahan yang diusulkan di sini dari apa yang saya lihat.

Jika Anda hanya menentang mereka karena "Saya telah mempelajarinya dengan cara ini, jadi saya ingin semua orang setelah saya menderita hal yang sama", maka itu adalah kritik yang tidak valid terhadap proposisi dan akan diabaikan.

Apa yang baik untuk Anda mungkin tidak baik untuk orang lain.

Dito.

Bisakah kita meninggalkan statistik yang dibuat-buat di depan pintu?

Seperti klaim ini tentang seluruh komunitas?

Masalah ini mungkin tidak signifikan bagi Anda atau orang lain, tetapi orang memiliki masalah dalam memahami API karena penamaan yang buruk.

Bagaimana Anda tahu apa yang orang punya masalah? Apakah Anda bertanya kepada mereka? Apakah ada jajak pendapat atau studi atau kuesioner tentang ini? Bagaimana Anda mendapatkan informasi ini?

Saya adalah salah satu pengguna yang memulai dari nol dan mempelajari API. Tidak punya masalah dengan penamaan. Semua API memiliki beberapa konvensi penamaan yang aneh. Semua fungsi harus agak singkat sehingga Anda dapat menulisnya dalam kode.

@pycbouh Jika Anda mencoba meyakinkan saya bahwa semua saran penamaan di sini bagus, saya harus dengan hormat tidak setuju dengan Anda. Ini adalah utas yang membahas perubahan dan saya di sini untuk mengatakan bahwa beberapa perubahan yang diusulkan tidak hanya tidak perlu/atau diminta tetapi hanya lebih lama dan sama-sama membingungkan. Beberapa memang bagus dan dipersilakan. Jangan semua massal mengubah nama semuanya hanya karena beberapa orang seperti Anda berpikir seluruh komunitas memiliki masalah dengan nama API. Saya tidak dan tidak pernah dan saya mulai sebagai pemula. Dan saya tahu beberapa orang lain yang juga tidak. Saya yakin beberapa dari perubahan ini signifikan dan harus ditinjau oleh seluruh komunitas atau setidaknya oleh kontributor sebelum rilis penuh.

Bagaimana Anda tahu apa yang orang punya masalah? Apakah Anda bertanya kepada mereka?

Sebagian besar entri di utas ini dihasilkan oleh orang-orang yang datang dengan masalah, baik itu di sini di GitHub (dan dalam kasus itu, masalah terkait) atau menggunakan saluran komunitas atau pribadi lainnya. Jangan berasumsi kita hanya duduk di sini menjilati bagian pribadi kita sendiri karena tidak ada yang lebih baik untuk dilakukan selain merenungkan fungsi atau properti apa lagi yang akan diganti namanya di mesin.

Selain itu, banyak usulan perubahan di sini bahkan belum ditindaklanjuti, tidak ada PR atau kegiatan lainnya. Mereka terdaftar dan hanya itu. Awasi PR dan jika ada yang menyinggung Anda, jangan ragu untuk mengomentarinya. Setelah itu terserah kepada PM Godot untuk menyetujui dan menggabungkan perubahan. Bersikaplah konstruktif dan Anda dapat mencegah beberapa modifikasi yang tidak diinginkan, tetapi jangan lupa apa yang Anda sendiri pernah katakan:

Apa yang baik untuk Anda mungkin tidak baik untuk orang lain.

Jadi, bahkan jika Anda tidak memiliki masalah dengan API hingga saat ini, itu tidak berarti bahwa orang lain tidak memilikinya atau mereka tidak akan memiliki masalah di masa mendatang.

Semua API memiliki beberapa konvensi penamaan yang aneh.

Itu bagus jika ada konvensi untuk dibicarakan. Tetapi beberapa API di Godot telah diberi nama jauh sebelum menjadi open source dan mungkin tidak dipikirkan dengan matang seperti yang diharapkan. Sekali lagi saya meminta Anda untuk tidak berasumsi bahwa orang-orang di sini menyarankan perubahan.

Tolong jangan lakukan diskusi seperti ini di sini. Jika Anda ingin mendiskusikan perubahan API tertentu, tidak apa-apa, tetapi pernyataan menyeluruh yang tidak Anda sukai sarannya di sini tidak membantu.

Pengembang inti akan meninjau setiap saran ini satu per satu. Kemungkinan banyak yang akhirnya tidak diterima.

Mengunci sementara, akan terbuka nanti.

Bisakah kita menambahkan poin-poin berikut ke dalam daftar?

• AnimationPlayer : Ganti nama stop() menjadi pause() (https://github.com/godotengine/godot/issues/16863#issuecomment-562363660, godotengine/godot-proposals#287)
• AnimatedSprite : Ganti nama stop() menjadi pause() (#31168) (sudah ditambahkan)
• AnimatedSprite3D : Ganti nama stop() menjadi pause() (#31168) (sudah ditambahkan)
• Tween : Ganti nama stop() menjadi pause() , stop_all() menjadi pause_all() (PR #41794, #43442)

Tween: Ganti nama stop() menjadi pause(), stop_all() menjadi pause_all() (#43442)

Ini dicakup oleh #41794

@opl- ini juga dibahas di sini: https://github.com/godotengine/godot-proposals/issues/287

Beberapa penggantian nama yang mungkin memperjelas apa yang dilakukan fungsi RNG lingkup global ini:

• seed() -> set_seed() (mungkin tambahkan get_seed() juga untuk mencocokkan RandomNumberGenerator) – Saat ini, tidak jelas apakah ini adalah fungsi setter.
• rand_seed() -> rand_from_seed() – saat ini, sepertinya itu akan mengacak benih atau sesuatu, ketika itu benar-benar memberikan nomor acak berdasarkan benih yang disediakan.

rand_seed() -> rand_from_seed() – saat ini, sepertinya akan mengacak seed atau sesuatu, padahal sebenarnya memberikan nomor acak berdasarkan seed yang disediakan.

Kecuali itu mengacak benih. Baca dokumentasi.

rand_seed() -> rand_from_seed() – saat ini, sepertinya akan mengacak seed atau sesuatu, padahal sebenarnya memberikan nomor acak berdasarkan seed yang disediakan.

Kecuali itu mengacak benih. Baca dokumentasi.

Maaf. Maksud saya adalah sepertinya itu hanya mengacak benih. Mungkin seharusnya rand_int_from_seed() , karena mengembalikan int? Sebenarnya, dokumen tidak menentukan jenis yang dikembalikan, hanya menyebutkan "Acak...angka". Apakah itu int?

Jadi itu menghasilkan benih baru berdasarkan benih yang Anda berikan dan kemudian menghasilkan nomor baru berdasarkan benih baru itu? Tidak yakin tentang penggantian nama, tetapi deskripsi dapat menggunakan beberapa pengerjaan ulang di sana, jika itu yang terjadi.

Jika itu yang dilakukannya, metode ini harus dipecah menjadi 2 metode yang lebih kecil untuk melakukan satu hal daripada mengganti namanya

Kontrol::pending_resize

Tidak terpakai.

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

Saya mengerti sekarang bahwa metode ini sebagian besar setara dengan GDScript is (yang extends btw), tetapi C++ membutuhkan lebih eksplisit.

Kebingungan yang saya alami adalah memeriksa apakah objek tertentu adalah tipe yang ada ( tanpa warisan):

// 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...
}

Implementasi yang mendasarinya menggunakan makro/templat "mewarisi" di semua tempat, jadi masuk akal bagi saya untuk mengganti nama ini menjadi inherits_class .

Lihat juga https://github.com/godotengine/godot/issues/21461#issuecomment -416155187:

get_class() dan is_class() membingungkan saya secara umum