Zu mühsam für mich, aber Gott sei Dank für denjenigen, der instance als instantiate wo es als Verb verwendet wird.

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

Es gibt noch viel mehr in der Control-Klasse, die Get/Set sollten alle denselben Namen haben wie die Variable. Es ist ärgerlich, jedes Mal die Docks zu überprüfen, wenn Sie den Variablennamen kennen.

Die Klasse TileMap hat eine Reihe von Getter- und Setter-Methoden, die nicht mit ihren jeweiligen Eigenschaften übereinstimmen. Tatsächlich würde ich vorschlagen, die meisten Getter und Setter in dieser Klasse umzubenennen, damit sie mit ihren Eigenschaften sowie der Benennung in anderen Klassen übereinstimmen.

Animation.track_remove_key_at_position sollte sein
Animation.track_remove_key_at_time

Methoden

• OS : execute sollte in zwei verschiedene Methoden aufgeteilt werden, eine blockierende und die andere nicht blockierend.
  zB Namen: execute / exec_process (blockierend) und spawn_process (nicht blockierend) #19302

LineEdit hat einen Parameter new_text auf "text_changed", TextEdit jedoch nicht.

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

Ich möchte, wenn VBoxContainer/HBoxContainer/GridContainer in einfache VBox/HBox/Grid umbenannt wird...

Und später wird es wieder umbenannt, weil es zu kurz ist wie pos->position :D

Sie sind etwas lang, du hast recht.

Mir ist aufgefallen, dass Godot derzeit zwei verschiedene Namenskonventionen in seinen Methodennamen hat.

Manchmal folgt es einer gemeinsamen Konvention, die in APIs solcher Sprachen wie C# oder Java zu finden ist, wie die Form [action][object]() : dh)

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

An anderen Stellen folgt es jedoch einer anderen Konvention von [prefix][action][object]() , wie zum Beispiel:

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

Sie sind nur einige Beispiele von vielen.

Wenn wir es uns leisten können, irgendwann in der Zukunft umfassende Kompatibilitätsänderungen vorzunehmen, würde ich gerne sehen, dass sie umbenannt werden können, um einer einzigen, gut definierten Namenskonvention zu folgen (hoffentlich erstere, da sie sowohl innerhalb als auch außerhalb von Godot häufiger verwendet wird).

An anderen Stellen folgt es jedoch einer anderen Konvention von [prefix][action][object]() , wie zum Beispiel:

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

Ich habe nicht alle Verwendungen überprüft, aber nach allem, was ich gesehen habe, folgt dieser Stil der Methodenbenennung, obwohl er etwas umständlich ist, auch einer bestimmten Konvention. Zum Beispiel die shape_owner_get Methoden:

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

Das "Präfix" bezieht sich auf das erste Argument, und der Teil nach get ist das, was Sie tatsächlich in diesem Präfix erhalten. Zum Beispiel ist shape_owner_get_shape_index(owner_id, shape_id) konzeptionell ähnlich zu get_shape_owner(owner_id)->get_shape_index(shape_id) , aber es gibt kein ShapeOwner für die Skript-API, daher diese "Verknüpfung".

Gleiches gilt für die surface_get Methoden:

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

Oder die *node_get Methoden in 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">

Ich habe das OP mit den meisten der bisher gegebenen Vorschläge aktualisiert.

Ich möchte, dass VBoxContainer/HBoxContainer/GridContainer in einfache VBox/HBox/Grid umbenannt wird

Ich bin nicht überzeugt, in Godot versuchen wir, alles eindeutige Namen zu geben, und zum Beispiel Grid sagt mir nicht, dass es ein Container ist. Für VBox und HBox könnte man argumentieren, dass Boxen per Definition Container sind, aber da wir BoxContainer was nicht dasselbe ist wie Container , denke ich, dass die Ausführlichkeit ist weiterhin gewährleistet.

LineEdit hat einen Parameter new_text auf "text_changed", TextEdit jedoch nicht.

Ich glaube nicht, dass es sinnvoll wäre, new_text zu TextEdit hinzuzufügen. Bei LineEdit enthält es einfach den gesamten Text von LineEdit, nicht den Text, der sich geändert hat, daher würde ich sogar argumentieren, dass er nicht in text_changed LineEdit enthalten sein sollte. Es ist jedoch üblicher, dass Sie den Volltext eines LineEdits bei der Eingabe verwenden möchten, als den Volltext eines mehrzeiligen TextEdits, wenn ein neues Zeichen gedrückt wird.

@akien-mga

Ich habe nicht alle Verwendungen überprüft, aber nach allem, was ich gesehen habe, folgt dieser Stil der Methodenbenennung, obwohl er etwas umständlich ist, auch einer bestimmten Konvention

Mir ist bewusst, dass es sich um eine eigene Namenskonvention handelt. Aber es wird außerhalb von Godot immer noch nicht häufig verwendet und ist auch etwas verwirrend, da manchmal dasselbe Wort wie BlendShape in Methoden verwendet wird, die zwei verschiedenen Namenskonventionen folgen.

Persönlich würde ich sie alle aus Konsistenzgründen gerne in GetPrefix* und SetPrefix* umbenennen, aber vielleicht haben andere Leute andere Meinungen dazu.

Die Methoden wurden in #16757 geändert. Die Argumentreihenfolge ist sinnvoller, aber sie unterbricht die API-Kompatibilität zwischen 3.0 und 3.1 (#19648).

Ich erwähne #9128 noch einmal: translation in 3D vs. position in 2D ist eine seltsame Unähnlichkeit.
Es wurde vor 3.0 angehoben, aber nach 3.0 geschlossen, weil ... 3.0 nicht mehr da war.

OS.execute sollte posix_spawn .

Eine andere könnte die Umbenennung von "margin" in "offset" für Steuerknoten sein.
Da die Ränder auf der rechten Seite negativ sind, führt dies in die Irre, insbesondere beim Vergleich mit StyleBoxen

@groud Ich glaube jedoch, dass Offset zu allgemein ist, Ränder waren früher das richtige Wort, weil sie bei der ersten Einführung nicht negativ auf der rechten Seite ausgerichtet waren

@groud Ich glaube jedoch, dass Offset zu allgemein ist, Margen waren ein guter Begriff (und waren bei der ersten Einführung nicht negativ)

Nun, die Marge ist irreführend, da sie jetzt negativ sind. Offset ist allgemein, aber sinnvoller. Ich denke nicht, dass es ein Problem ist, dass sie generisch sind, da es sich um Kontrollknoten handelt.
Für bessere Vorschläge bin ich jedenfalls offen. Ich wollte diese Idee hier nur fallen lassen, da eine solche Namensänderung bereits vorgeschlagen wurde. Siehe hier zum Beispiel.

Die Größe der Boxen/Würfel ist inkonsistent benannt.
BoxShape für Kollisionen verwendet Ausdehnungen.
CubeMesh hat eine Größeneigenschaft mit x, y und z, die jeweils die Hälfte der Ausdehnungen sind.
CSGBox hat eine Width-, Height- und Depth-Eigenschaft, die wie die x-, y- und z-Größe in CubeMesh definiert sind.

Zusätzlich zur Größeneigenschaft wird manchmal "Cube" und manchmal "Box" verwendet. Sinnvoll wäre für alles "Box" zu verwenden, da x, y und z für CubeMesh unabhängig voneinander gesetzt werden können und es somit auch eine Box ist.

Da wir zB HTML5 und UWP als Ziele haben, die nicht gerade Betriebssysteme sind, schlage ich vor, OS in Platform (PlatformWindows, PlatformUnix,...) umzubenennen.
Macht auch beim OS/Display Split Sinn.

Ab diesem #20228 ist Label.clip_text nicht mehr notwendig. Ich glaube, das gilt auch für Button.clip_text.

Camera2D hat derzeit zwei verschiedene Eigenschaften, die beide als offset (regulärer Offset und der in V und H aufgeteilte), die zwei völlig unterschiedliche Dinge sind, das ist wirklich verwirrend.

Methoden

- Dictionary : erase_checked sollte entfernt werden (diese Methode ist nicht für Skripte verfügbar).
- Dictionary : erase sollte so geändert werden, dass bool um festzustellen, ob das Paar mit dem angegebenen Schlüssel entfernt wurde oder nicht (siehe Implementierung von erase_checked ).

20945

@neikeq Dies könnte jetzt IMO getan werden, das Ändern des Rückgabewerts von Dictionary.erase von void in bool sollte kein Projekt zerstören .

@akien-mga, aber es würde die GDNative API-Kompatibilität beeinträchtigen, nicht wahr?

@akien-mga Würde das nicht die Vorwärtskompatibilität beeinträchtigen? Dürfen wir Änderungen vornehmen, die möglicherweise dazu führen, dass 3.1-Skripte in älteren Versionen wie 3.0 nicht funktionieren?

@neikeq Ja, 3.1-Skripte sind bereits mit 3.0 nicht kompatibel ( class_name , Tonnen von API-Änderungen mit neuen optionalen Parametern oder brandneue Eigenschaften/Methoden, neue Klassen usw.). Wir kümmern uns nur um die Abwärtskompatibilität, nicht um die Vorwärtskompatibilität.

Ach, ich verstehe! Wenn das der Fall ist, werde ich diese Änderungen jetzt vornehmen.

Wenn ich einen zur Liste hinzufügen kann, würden die Kontrollknoten LineEdit und TextEdit wirklich davon profitieren, konsistente APIs miteinander zu haben, sodass sie (meistens) austauschbar verwendet werden können. Im Moment fühlt es sich wie ein Durcheinander an, mit ihnen zusammenzuarbeiten, bis zu dem Punkt, an dem mich der Blick auf einen Knoten über den anderen verwirrt.

@eska014 Außerdem ist die Option scons bereits platform . Es ist sinnvoll, konsequent zu sein.

Die Projekteinstellungen display/window/size/test_width und test_height sollten in window_width und window_height . Wir sollten auch erwägen, die Einstellungen width und height umzubenennen, vielleicht render_width und render_height .

Kamera nah und fern Eigenschaften haben unterschiedliche Namen als sein Setter / Getter (zB set_znear / set_zfar). Dies sollte geändert werden?

znear und zfar sind verwirrend. Es hat nichts mit der Z-Achse im Weltraum zu tun. Es könnte in clip_near und clip_far geändert werden, da sie Clipping-Ebenen steuern, oder nur near und far .

Ja, es gibt zwei Möglichkeiten, dieses Problem zu lösen.

Wir sollten binäre Ressourcenerweiterungen loswerden (oder ernsthaft diskutieren). (RES_BASE_EXTENSION)

gdscript_function.cpp und gdscript_functions.cpp sind sehr ähnlich benannt, ich verwechsele sie immer wieder. Lohnt sich eine Umbenennung? @vnen

Ich habe https://github.com/godotengine/godot/pull/21425 geändert, um "decimals" in "step_decimals" umzubenennen, aber "decimals" als Alias ​​beizubehalten. Vorausgesetzt, es ist zusammengeführt, können wir "Dezimalstellen" beim nächsten Kompatibilitätsbruch entfernen, wenn nicht, einfach umbenennen.

@mysticfall Meiner Meinung nach ist es besser, das Wort "get" nicht in Methodennamen zu verwenden, wenn es unnötig ist.

Manchmal möchten Sie, dass eine Eigenschaft sowohl abgerufen als auch festgelegt werden kann, aber den Zugriff steuert. In C# ermöglichen Ihnen Eigenschaften, dies zu tun und den Zugriff zu steuern, indem Sie einfach lesen und zuweisen, als ob es ein Feld wäre, was nett ist.

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

In GDScript sind Eigenschaften jedoch kein Ding (?). Wir könnten auch einen Methodennamen ohne das Wort get haben. Die meisten Methoden geben etwas zurück, daher ist es besser, eine implizite Get-Ness als Set-Ness zu verwenden: Da GDScript Eigenschaften hat, empfehle ich, sie häufiger zu verwenden. Beachten Sie, dass ich dazu keine Dokumentation finden konnte. Ich habe eine Dokumentation dazu gefunden, wie man es in GDScript mit setget aber was ist mit dem Hinzufügen über C++?

Zusammenfassend stimme ich zu, dass es nicht gut ist, "get" an inkonsistenten Stellen zu haben, aber die ideale Lösung ist meiner Meinung nach im Moment in den GDScript- Eigenschaften oder wir könnten "get" entfernen und "set" beibehalten. .

@aaronfranke GDScript hat in get und set aus den Methoden zu entfernen, weil 1) es den Namen klarer macht und 2) es zwischen Getter und Setter unterscheidet. Mesh.SurfaceFormat() klingt wie eine Methode, die "die Oberfläche formatiert" und nicht eine, die "das Format erhält". Außerdem können die meisten (wenn nicht alle) davon ignoriert und stattdessen sowieso als Eigenschaften verwendet werden.

Ich kümmere mich nicht so sehr um gdscript_function.cpp und gdscript_functions.cpp . Der eine hat die Klasse GDScriptFunction, der andere enthält die Definition der GDScript-Funktionen, mir ist immer klar, welche welche ist (obwohl ich daran gewöhnt bin). Es ist auch keine bahnbrechende Veränderung, also muss es nicht hier sein.

Ja, GDScript hat Eigenschaften. C#-Eigenschaften werden aus der ClassDB generiert, von der GDScript sie bezieht.

Es gibt einige Methoden für RigidBody und die zugehörigen Klassen, deren Parameter aus Konsistenzgründen ausgetauscht werden sollten:

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

Klassen- und Methodenliste

@TGRCdev Ich würde es sehr vorziehen, apply_impulse in (force, position) zu ändern, anstatt add_force in (position, force) zu ändern. Die Position der Kraft ist ein optionaler Parameter, daher sollte sie am Ende stehen. Aber alle Kräfte und Impulse müssen einen Kraftvektor haben.

@aaronfranke Fairer Punkt. In diesem Fall lautet die Liste der erforderlichen Swaps:

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

@aaronfranke Ich stimme zu, dass die Verwendung von Get- oder Set- Präfixen eine Art "Javaismus" ist, der in C# besser vermieden werden sollte.

Mein Hauptanliegen war die Verwendung von 'Domänenpräfix' wie im Fall shape_owner_get_shape oder node_get_input_count , also ob wir sie als richtige C#-Eigenschaften ohne Get- oder Set- reimplementieren können

Nebenbei bemerkt fand ich es immer ziemlich seltsam, dass Eigenschaften in Godots C#-API übereinstimmende Getter und Setter haben, wie zum Beispiel Node.Name und Node.GetName() / Node.SetName() .

Es fühlt sich für mich ziemlich überflüssig an, aber wenn es einen Grund gibt, warum wir eine solche Konvention beibehalten, würden wir wahrscheinlich sowohl NodeInputCount als auch GetNodeInputCount() / SetNodeInputCount() , wenn wir es wären um node_get_input_count wie vorgeschlagen umzubenennen.

Leute, bitte diskutieren Sie die C#-API und die üblichen Konventionen außerhalb dieser Ausgabe, die sich auf die Godot-API konzentriert. Die Godot-API (C++, C und GDScript) wird nicht um C# willen angepasst, es sei denn, es handelt sich um eine Verbesserung für andere Sprachen.

@akien-mga Ich glaube nicht, dass es C#-spezifisch ist, zu diskutieren, ob node_get_input_count in etwas wie get_node_input_count .

Nein, ich meine, alles, was C# spezifisch ist, sollte in diesem Problem nicht enthalten sein. Es kann bei Bedarf ein weiteres Problem für C#-spezifische Kompatibilitätsbrüche geben (obwohl es bereits mehrere dieser IINM gibt).

Wie wäre es, Spatial in Node3D umzubenennen? Ich fand es immer komisch.

@KoBeWi Das Namensschema, das Godot derzeit verwendet, ist "Thing2D" für 2D-Zeug und nur "Thing" für 3D-Zeug, daher ist es ziemlich konsistent mit dem Rest des 2D-Codes. Natürlich wäre es dann logisch, "Räumlich" zu nennen, "Knoten" nach dem Muster des Entfernens von "2D", aber dieser Name ist natürlich bereits vergeben.

Das Namensschema, das Godot derzeit verwendet, ist "Thing2D" für 2D-Zeug und einfach "Thing" für 3D-Zeug

Also vielleicht alles 3D in "Thing3D" ändern? Das kam mir auch in den Sinn, klingt aber nach Overkill.
Jedenfalls habe ich es nur vorgeschlagen. Nicht als ob es sehr wichtig wäre. Außerdem ist Spatial2D noch schlimmer als Spatial.

String.right() gibt also n rechte Zeichen von der gegebenen Position zurück. Wäre es nicht intuitiver, wenn es nur n Zeichen von rechts zurückgeben würde?

"abcdef".right(2)
Anstelle von "cdef" würde "ef" zurückgegeben. IMO wäre es besser.

Das gleiche habe ich erwartet.

Python hat dieselbe Methode, die die meisten Benutzer gerne verwenden, um GDScript mit Python zu vergleichen. Es würde wahrscheinlich noch mehr verwirren, es zu ändern.

@KoBeWi Ich stimme zu. Ich sehe den Unterschied zwischen der aktuellen Implementierung und der Teilzeichenfolge nicht.

Der Godot substr zwingt Sie, die Größe des Strings anzugeben, wenn alles rechts angezeigt werden soll.

@Zylann Bei den meisten Implementierungen kann der zweite Parameter substr den zweiten Parameter lieber optional machen als eine neue Methode mit einem anderen Namen.

@Zylann @neikeq Dies ist ein unglückliches Ergebnis von nicht gibt keine Möglichkeit, sowohl eine Längenangabe als auch keine Längenangabe zu haben.

@aaronfranke Ähm , aber Standardargumente existieren. 0 oder -1 könnte als keine Längenangabe gelten.

Muss get_selected_id() aus OptionButton entfernen, derzeit gibt es immer -1 zurück. Nachdem https://github.com/godotengine/godot/pull/21837 zusammengeführt wurde, wird get_selected_id() dasselbe wie get_selected() .

Es gibt viele Tween-Methoden, die jedes Mal true zurückgeben, sie sollten wahrscheinlich void gemacht werden.

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

Der Tree-Knoten hat eine get_selected() Funktion, die anscheinend das fokussierte TreeItem zurückgibt. Es könnte sich lohnen, es in get_active() umzubenennen, da Fokus und Auswahl verschiedene Dinge sind.

load_from_globals() in InputMap sollte load_from_project_settings() .

Ich füge eine :tada:-Reaktion auf alle Vorschläge hinzu, die in das OP integriert wurden, um eine bessere Übersicht zu haben.

global_rotate sollten aus Konsistenzgründen in rotate_global und rotate_object_local in rotate_local umbenannt werden, damit alle Rotationsmethoden mit "rotate" beginnen.

global_rotate sollte aus Gründen der Konsistenz in rotate_global und rotate_object_local in rotate_local umbenannt werden, damit alle rotate-Methoden mit "rotate" beginnen.

Auf der anderen Seite gefällt mir, dass globale Funktionen (wie global_position, global_scale und global_transform) in den Vorschlägen zur automatischen Vervollständigung nebeneinander stehen. Beide Lösungen machen IMHO Sinn.

Vielleicht könnte tree_exiting in tree_exited da es mittlerweile einige Verwirrung zu stiften scheint. Siehe #22840.

@groud Es gibt bereits ein tree_exited Signal, oder?

@groud Es gibt bereits ein tree_exited-Signal, oder?

Verdammt du hast recht. Ich denke, die Anfrage in #22840 ist dann gültig

MenuItems.MENU_MAX wird nie in LineEdit und TextEdit , sollten wir es entfernen?

Gleiches für Tabs.ALIGN_MAX https://github.com/godotengine/godot/blob/master/scene/gui/tabs.cpp#L750

Die Knoten Position3D und Position2D sind etwas mehrdeutig. Ohne die Beschreibung zu lesen, könnte man annehmen, dass sie wie Spatial und Node2D sind, jedoch ohne Rotation oder Skalierung. Sie sollten wahrscheinlich in PositionHint und PositionHint2D oder vielleicht ein anderes Wort wie Gizmo da es nur im Editor ein Gizmo ist oder AxisMarker weil es so aussieht eine kleine Achsenmarkierung.

Wenn sie in Gizmo umbenannt würden, könnten sie vielleicht allgemeiner verwendet werden.

Beachten Sie, dass derselbe Knoten im Control-Baum ReferenceRect , also könnte ReferenceAxis/2D auch funktionieren.

Ich liebe dieses Thema jetzt. Kann es später hassen, wenn der Bruch tatsächlich trifft ;)

Einige Vorschläge für die bescheidene Array Klasse:

• duplicate → entweder copy oder clone . Ich kenne keine Sprache, die dieses Konzept "Duplizieren" nennt. copy heißt es in Python und in C++, daher wäre es die natürliche Wahl für Godot. clone stammt aus Java und JavaScript und ist vielleicht etwas genauer.
• invert → reverse . Die Dokumentation beschreibt es sogar als "umgekehrt", also gibt es wirklich keine Entschuldigung.
• remove vs. erase ist verwirrend. Vorschlag: remove_at und remove_value .

Die letzten beiden gelten auch für alle Pool*Array Klassen.

Hinweis: Duplizieren → Kopieren/Klonen gilt auch für Wörterbücher.

Rect2 :

• clip → intersection

AABB hat intersection Methode aber nicht clip , Clipping bedeutet im Allgemeinen, dass wir etwas ausschneiden, was übrigens in keiner der Klassen implementiert ist. Die Dokumentation beschreibt es als:

Returns the intersection of this Rect2 and b.

Könnte genauso gut umbenennen:

• intersects → overlaps
  um nicht mit der eigentlichen intersection Operation zu verwechseln:

Returns true if the Rect2 overlaps with another.

grabber_area -> slider_progress
slider -> slider_background

Einige Vorschläge für die bescheidene Array-Klasse:
duplizieren → entweder kopieren oder klonen.
...
Hinweis: Duplizieren → Kopieren/Klonen gilt auch für Wörterbücher.

Und Knoten und Ressourcen (im Grunde jedes Skript-exponierte Datenstrukturobjekt, afaik).

Ich bevorzuge das Wort "Klon", ich denke, es ist klarer, was es tut.

Morgen! @akien-mga könnten wir nicht instance in new statt instantiate umbenennen? Die gleiche Schnittstelle auf PackedScene wie Object haben, entfernt beispielsweise einige Boilerplates für die Plugin-Erstellung, insbesondere, aber wahrscheinlich allgemeiner. @willnationsdev was denkst du? Ich weiß, dass Sie das schon einmal erlebt haben.

Entschuldigung, wenn es irgendwo schon eine Diskussion darüber gibt, ich konnte es beim Durchblättern nicht finden.

grabber_area -> slider_progress
slider -> slider_background

oder nur:
grabber_area -> progress
slider -> background ?

Ich weiß nicht, ob das schon diskutiert wurde, aber AnimationPlayer hat root_node mit set_root & get_root , sie sollten wahrscheinlich set/get_root_node

CanvasItem.visible in CanvasItem.is_visible (und alle anderen Orte, an denen es verwendet wird)? mit allen (oder den meisten, vielleicht habe ich einige übersehen) bool Eigenschaften übereinstimmen?

Tween.tween_completed in Tween.tween_finished umbenennen? Genau wie Animation.animation_finished ? Ziehen Sie im Allgemeinen _finished gegenüber _completed ? Es fühlt sich an, als ob started/finished eine engere Beziehung haben als started/completed - voreingenommen vom Wettkampfsport: start/finish - vielleicht :D

Bitte benennen Sie die Klasse JavaScript in HTML5 oder etwas anderes um.
Diese Klasse hat eine einzelne Methode und wird nicht von Script und wird auf anderen Plattformen nicht verwendet.

Das JavaScript kann in Zukunft als Klassenname von JavaScript-Sprachbindungen verwendet werden.

Wie von @clayjohn betont , ist WORLD_MATRIX in CanvasItem-Shadern eigentlich eine Modelview-Matrix. @reduz stimmt zu, dass wir es in 4.0 durch das tatsächliche Modell und die Ansichtsmatrizen ersetzen sollten, z. B. CANVAS_MATRIX und ITEM_MATRIX .

Ziehen Sie in Erwägung, Array.invert in Array.reverse . Invertieren ist eher wie verkehrt herum oder die Art der "Kehrseite von". Siehe https://docs.godotengine.org/en/latest/classes/class_color.html#class -color-method-inverted

Ändere das CanvasItem.visibility_changed() Signal in CanvasItem.visibility_changed(visibility: bool) , dh. senden Sie den Sichtbarkeitsstatus mit. Da dies ausreicht, entfernen Sie das CanvasItem.hide() Signal

Entferne Resource::notify_change_to_owners , Resource::{un}register_owner .
Sie werden nur von GridMap und CollisionShape verwendet, der Rest des Codes verwendet das Signal "changed" .

Rect2 : has_no_area sollte in has_area , um zu verhindern, dass die doppelte Negationslogik das Gegenteil in Bedingungen prüft. Gleiches gilt für AABB : has_no_surface .

Aufbauend auf dem, was @lupoDharkael gesagt hat, hat Godot mehrere Orte, an denen doppelte Negative verwendet werden. Fehler wie "Bedingung !Math::is_nan(x) ist falsch" sind verwirrend.

parse_input_event( InputEvent-Ereignis )
Füttert ein InputEvent in das Spiel. Kann verwendet werden, um Eingabeereignisse aus Code künstlich auszulösen.

parse ist irreführend, parse würde empfangen und verarbeitet werden, aber die Beschreibung zeigt an, dass eine Eingabe gesendet oder ausgelöst wird

Gemäß #24153 - CanvasLayer verwendet Layer, um zu beschreiben, auf welchem ​​Layer seine Knoten gezeichnet werden sollen. Aber fast jeder andere 2D-Knoten verwendet die Terminologie "Z-Index" ( z_index ), um (was auf den ersten Blick erscheint) dasselbe zu beschreiben. Wie @swarnimarun vorgeschlagen hat https://github.com/godotengine/godot/issues/24153#issuecomment -444950584 Verbesserung der Namen für Ebenen.

Wäre OS.has_feature() / Platform.has_feature() in so etwas wie ProjectSettings sinnvoller, da sie nicht ausschließlich etwas über das Betriebssystem vermitteln?

set_cell_item kann in set_cell umbenannt werden, um GridMap mit TileMap zu vereinheitlichen?

set_cell_item kann in set_cell umbenannt werden, um GridMap mit TileMap zu vereinheitlichen?

Wenn ich darüber nachdenke, sollte es vielleicht auch ein set_cellv für GridMaps geben?

ARVRSchnittstelle:

• ar_is_anchor_detection_enabled -> anchor_detection oder ähnlich
• interface_is_initialized -> is_initialized oder is_interface_initialized

AnimationPlayer:

• play_backwards kann entfernt werden, weil play dafür einen optionalen bool hat.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D:

• Ändern Sie das Bool disabled in ein Bool enabled .

Knochen2D:

• get_index_in_skeleton -> get_skeleton_index

• play_backwards kann entfernt werden, weil play dafür einen optionalen bool hat.

Das wäre schlecht für die Lesbarkeit, zumindest solange #6866 nicht implementiert ist. In C# ist dies kein Problem, da es benannte Parameter unterstützt.

ID in id_pressed( int ID ) und id_focused( int ID ) sollte klein geschrieben werden.

^
Diese Änderung würde tatsächlich keine Kompatibilität beeinträchtigen. Es könnte wahrscheinlich ein separates Problem bekommen.

^
Diese Änderung würde tatsächlich keine Kompatibilität beeinträchtigen. Es könnte wahrscheinlich ein separates Problem bekommen.

Korrekt!

28746 - Node.replace_by kann als Name verwirrend sein. Ich bin mir jedoch nicht sicher, was genau ein besserer Name sein könnte.

@bojidar-bg vielleicht replace_self oder swap_by ? aber ich denke, dass der einzige Weg, jede Art von Verwirrung zu vermeiden, darin besteht, sie richtig zu dokumentieren.

Wenn ich ein Node2D mit einem angehängten Skript habe, das class_name MyNode2D , gibt die Methode get_class() Node2D anstelle von MyNode2D . Dies mag beabsichtigt sein, ist aber verwirrend und irreführend.

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

@aaronfranke get_native_class() vielleicht? Dann könnten Sie den Skriptnamen von get_script().global_name wenn es einen gibt.

make_convex_from_brothers()
Ich denke, "Brüder" sollte in "Geschwister" geändert werden, da dies das Wort ist, das überall für Geschwisterknoten verwendet wird.

ARVRPositionalTracker: get_type() -> get_tracker_type()

• get_tracker_type() ist expliziter - get_type() könnte mit get_class() verwechselt werden

• GetType() wird in C# bereits für etwas anderes verwendet, wie hier angegeben .

Es gibt TrackerType , und es gibt auch get_hand() das TrackerHand zurückgibt, so dass dies bei Bedarf auch in get_tracker_hand() geändert werden könnte.

ARVRPositionalTracker enum TrackerHand: TRACKER_LEFT_HAND -> TRACKER_HAND_LEFT (und rechte Hand). Alternativ TRACKER_HAND_UNKNOWN -> TRACKER_UNKNOWN_HAND , solange es konsistent ist.

Node.NOTIFICATION_TRANSLATION_CHANGED sollte wahrscheinlich NOTIFICATION_LOCALE_CHANGED , da "Übersetzung" in räumlichen Knoten verwendet wird, um "Position" und nicht "Sprache" zu bedeuten.

set_as_toplevel() könnte in set_as_top_level() , aber sein Verhalten sollte untersucht werden .

TouchScreenButton sollte für 4.0 betrachtet werden, da diese Änderung schädlich sein könnte: https://github.com/godotengine/godot/issues/28814

CanvasItem Methode:

RID get_canvas_item() const
Gibt die Zeichenbereichselement-RID zurück, die von VisualServer für dieses Element verwendet wird.

Sollte dann in get_rid() .

get_canvas_item() ist verwirrend, weil ich bereits am Knoten CanvasItem bin. Es stellt auch die Konsistenz sicher, da andere Klassen bereits ähnliche get_rid() Methoden haben: CollisionObject , Resource .

Sollte Label in TextLabel geändert werden? Ich wollte jetzt schon mehrmals ein Textobjekt ablegen und habe vergessen, wie es heißt, also suche ich nach "text" und es wird nur RichTextLabel angezeigt. TextLabel wäre konsistenter mit RichTextLabel da es immer noch Text ist, aber ohne Rich.

Als Referenz hat Unity Text und TextMesh , und ich persönlich bezeichne es eher als Text als als Label.

Ich habe mich auch gefragt, ob Tree und GraphNode in TreeView und GraphEditNode .
Für Tree ist der Name viel zu breit für einen globalen GUI-Knoten IMO, alle anderen GUI-Frameworks, die ich kenne, verwenden TreeView .
Für GraphNode liegt es daran, dass ich kürzlich an einigen Prototypen gearbeitet habe, die tatsächliche Graphenstrukturen beinhalten, und ich weder Node noch GraphNode was ziemlich nervig war.

@Zylann Da die Graph-Knoten visuelle / Steuerelemente für Graphen (nicht Bäume) sind, ist GraphContainer möglicherweise besser. Bei GraphNode bin ich mir nicht sicher.

Sollten wir lerpf / lerpv / lerpc anstelle von Color/Vector2/3.linear_interpolate ? Benennen Sie mindestens Color/Vector2/3.linear_interpolate in Color/Vector2/3.lerp

Wie in #29598 http_escape / http_unescape bis uri_encode / uri_decode mentioned erwähnt

Sollten wir lerpf & lerpv statt Vector2/3.linear_interpolate ? Benennen Sie mindestens Vector2/3.linear_interpolate in Vector2/3.lerp

Die Verkürzung auf vector.lerp() hört sich gut an. Zumindest seit https://github.com/godotengine/godot/pull/16106 hat die Verwendung von lerp() im Skript einen Schalter zur Unterstützung von Vektoren und Farben.

Vector2.angle_to_point() sollte umbenannt werden. Der Name stimmt nicht mit der aktuellen Beschreibung überein. Ich bin mir nicht sicher, was ein guter Name wäre und ob es sich lohnt, diese Funktion beizubehalten.

Originalausgabe: #16307

@razcore-art Bereits eine PR zu diesem Thema geöffnet https://github.com/godotengine/godot/pull/20371 , und es bleibt Abwärtskompatibilität (glaube ich).

EDIT: Geht nicht mehr.

Area sollte eigentlich Volume , da es 3D ist. Und Area2D sollte dann Area . Ein Gebiet ist von Natur aus 2D.

GridMap sollte vielleicht CubeMap . Ich bin mir nicht sicher, nur dieses "Gitter" klingt für mich wie ein 2D-Ding.

CheckButton Kontrolle sollte SwitchButton oder so sein. Es ist verwirrend, weil es auch Checkbox . Oder vielleicht sollte es ganz entfernt werden. Es erfüllt sowieso die gleiche Funktion wie Checkbox, soweit ich das beurteilen kann.

Ich stimme zu: CheckButton, und die anderen sind nur kosmetisch.

Oder vielleicht sollte es ganz entfernt werden. Es erfüllt sowieso die gleiche Funktion wie Checkbox, soweit ich das beurteilen kann.

UX-technisch sind CheckBox und CheckButton unterschiedliche Dinge, obwohl sie die gleiche Funktionalität haben.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@Rodeo-McCabe Area wird aus Gründen der Konsistenz mit dem 2D-Gegenstück so genannt, auch eine der Definitionen von area ist a particular extent of space or surface .
Cubemaps sind 3D-Bilder, die Syntax-Korrektheit muss im Kontext stehen oder es fügt nur Verwirrung hinzu.

grabber_area -> slider_progress
slider -> slider_background

oder nur:
grabber_area -> progress
slider -> background ?

Vielleicht:
grabber_area -> progress_area oder progressed_area
slider -> progress_background ?

Cubemaps sind 3D-Bilder, die Syntax-Korrektheit muss im Kontext stehen oder es fügt nur Verwirrung hinzu.

@eon-s Fair genug, das wusste ich nicht.

Fläche wird aus Gründen der Konsistenz mit dem 2D-Gegenstück so genannt

Das Problem ist, dass das 2D-Gegenstück auch inkonsistent ist. In der Mathematik ist eine Fläche Länge * Höhe, es gibt einfach keine dritte Dimension. Daher macht es keinen Sinn, Area2D zu sagen, weil es 2D sein sollte , weil es ein Bereich ist. Eine andere, mathematischere Definition von "Fläche" ist:

die Fläche, die in einer Reihe von Linien enthalten ist, insbesondere: die Anzahl der Einheitsquadrate, die dem Maß der Fläche entsprechen

In ähnlicher Weise wird ein 3D-Raum in der Mathematik als "Volumen" bezeichnet. Ich war zuerst verwirrt, als ich herausfand, dass Area eigentlich ein 3D-Knoten war, stattdessen wurden Areas seltsamerweise "Area2D" genannt. Da dies eine Spiel-Engine ist, sollten wir die mathematischen Definitionen verwenden.

Obwohl ich die Argumentation verstehe, weiß ich nicht, ob es einen besonderen Vorteil hätte, den Namen zu ändern, insbesondere für neue Leute. Ich stimme zu, dass "Volumen" ein passenderer Begriff dafür sein könnte, aber ich habe das Gefühl, dass "Volumen" für 3D und "Fläche" für 2D ein wenig verwirrend sein kann. Immerhin werden viele Knoten, die sowohl 2D- als auch 3D-Varianten haben, als "

Ich denke, dass das Namensschema in erster Linie vorhanden ist (sowie es einige Knoten gibt, die sich nur größtenteils an das Schema halten), bedeutet, dass wir keine Ausnahme von der Regel machen sollten, selbst wenn ein anderer Begriff für eine Variante ausreichen würde sinnvoller, da es sonst die Benutzer verwirren könnte.

Wenn ich jedoch darf... vielleicht Area2D in Area und Area in Area3D umbenennen?

Bearbeiten: Scheint, dass Text, der von <> umgeben ist, nicht angezeigt wird, es sei denn, Sie entkommen dem <>

@Rodeo-McCabe Ich habe den Eindruck, dass die Absicht der Knotenbenennung darin besteht, Dinge in menschlicher Sprache und nicht in mathematischer Sprache auszudrücken. Der "Bereich" soll also kein geometrischer sein, sondern ein Ort, an dem man sich befinden kann, wie innerhalb eines Levels oder einer Bühne. IE - Bereich 1.

Der Knoten selbst hat keine Geometrie oder ist selbst eine Geometrie, daher würden sich andere wie ich fragen, wo seine Fläche / sein Volumen ist, wenn er erstellt wird, und warum sollte ich dann Flächen und Volumen (Formen) an eine Fläche anhängen und Volumen?

Wenn es umbenannt werden sollte, um eine Verwechslung mit dem geometrischen Bereich zu vermeiden, wären Synonyme wahrscheinlich der richtige Weg.

Sie könnten heißen:

• Region2D/3D
• Weltraum2D/3D
• Zone2D/3D
• Feld2D/3D
• usw.

Übrigens, abgesehen davon, dass dieser Tracker nur für Methoden, Eigenschaften und Signale (nicht Nodes) gedacht ist , hat

Es hört sich so an, als ob das Ziel darin besteht, die Dinge so zu belassen, wie sie jetzt sind, also könnten solche Dinge bis zur nächsten Hauptversion nach 4.0 verschoben werden?

Bitte überlassen Sie dieses Thema den Hauptmitwirkenden, es ist kein Ort, um überall Vorschläge für große Umbenennungen zu machen, das Ziel ist es, tatsächliche Inkonsistenzen zu beheben, die die API umständlich machen.

Die im OP beschriebenen Änderungen sind kein großer Kompatibilitätsbruch und die meisten werden für 4.0 durchgeführt. Was @reduz bezog, ist ein Kompatibilitätsbruch der Art "Ihr Projekt kann nicht mehr geöffnet werden" zwischen 2.1 und 3.0 (viel mehr geändert, als dass Dinge damals nur umbenannt wurden, wie das Audio- und Partikelsystem komplett neu geschrieben wurde, das Importsystem geändert wurde usw.).

In 4.0 wird es einige Kompatibilitätsprobleme geben, sonst würde es nicht 4.0 heißen. Es wird vernünftig sein und die Portierung wird einfach sein, wahrscheinlich mit einem Konverter, um sicherzustellen, dass umbenannte Eigenschaften, Methoden und Signale richtig konvertiert werden, wenn sie in Szenen und Skripten verwendet werden. Es ist sowieso nicht der Ort, um darüber zu diskutieren :)

Control _set_anchor() sollte auch den Anfang "_" weglassen.

PopupMenu's hat index_pressed(index) und id_pressed(id) die gut funktionieren, aber auch id_focused das tatsächlich mit dem Index statt der ID des Elements ausgegeben wird.

Noch kein Problem, aber nachdem es Akien heute vorgeschlagen wurde, lohnt es sich, es auf die Liste zu setzen.

Refaktorieren Sie den ARVRServer, sodass er als XRServer bezeichnet wird. Als wir es entworfen haben, war der Begriff XR, um sowohl VR als auch AR anzuzeigen, noch nicht weit verbreitet. Und nein, ich gehe nicht für MRServer ;)

Sollte RayCast eine "Disabled"-Eigenschaft anstelle von "Enabled" haben? CollisionShape hat ein "Deaktiviert", das standardmäßig false ist (was bedeutet, dass sie standardmäßig aktiviert sind). Im Gegensatz dazu ist die Eigenschaft "Enabled" von RayCast standardmäßig false , wodurch sie standardmäßig deaktiviert sind.

Oder, um die positive Form zu verwenden (die meiner Meinung nach insgesamt weniger verwirrend ist), sollte CollisionShape eine "Enabled"-Eigenschaft (standardmäßig true ) anstelle von "Disabled" haben?

@Calinou Ich weiß nicht, ob dies ein separates Problem erfordern würde, aber wenn wir konsistent sein müssen, würde ich es wirklich vorziehen, dass solche Booleschen immer Enabled . Einen booleschen true auf

@Calinou Ich stimme @Zylann zu. Doppelte Negative sind verwirrend und sollten nach Möglichkeit vermieden werden. Wir sollten stattdessen "Disabled"-Booles in "Enabled" ändern. Es ist in Ordnung, wenn der Standardwert von etwas "true" ist. Ich hatte diese Diskussion in #17212 und #21822.

Die Eigenschaft speed der Maus- und Berührungseingabeereignisse sollte in velocity da es sich um einen Vector2 handelt.

InputMap : get_action_list( String action ) Der Funktionsname sagt nicht viel darüber aus, was er tut.
Da es die einer bestimmten Aktion zugeordneten EventInputs zurückgibt, könnte es get_action_events(String action)

Könnte auch helfen, mögliche Verwirrung zu vermeiden, da InputMap eine weitere Funktion namens get_actions( ) und beide Namen außerhalb des Kontextes dasselbe bedeuten könnten.

Tangential mit #30736 verwandt, sollten wir die beiden Godot-Physik-Engines in etwas wie "GodotPhysics2D" und "GodotPhysics3D" umbenennen, da die Aussage, dass etwas mit "GodotPhysics" kaputt ist, zwei sehr unterschiedliche Dinge bedeuten kann.

Wie wäre es mit der Umbenennung von Object._init() in Object._new() ?

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

new — _init

Ich vermute, dass _init tatsächlich __init__ Python gefolgt ist, während new eine Methode der Klasse ist, nicht die Instanz.

Passt etwas wie String : empty() -> is_empty() gut zu diesem Thread? Ich denke immer, es ist eine Funktion, um zuerst einen String zu löschen.

@vortexofdoom Wenn Sie über Inkonsistenzen bei Methodennamen sprechen und / oder wie sie benannt werden sollten, dann ja.

Ich könnte hinzufügen, dass String und NodePath die Methoden empty bzw. is_empty haben, die dasselbe tun. Der Rest der integrierten Kerntypen scheint den Namen empty zu bevorzugen, also könnte is_empty vielleicht in NodePath , um dies für alle integrierten Typen konsistent zu machen, aber dies könnte möglicherweise einen ernsthaften Kompatibilitätsbruch mit sich bringen, denke ich.

Ich denke immer, es ist eine Funktion, um zuerst einen String zu löschen.

Die meisten Methoden verwenden dafür clear name in Godot.

@Xrayez ,

Die meisten Methoden verwenden dafür einen Klarnamen in Godot.

Ich weiß, wenn ich mich nur darauf beziehe, dass empty ein Verb als auch ein Adjektiv ist, und das Hinzufügen von is_ macht deutlich, welches gemeint ist.

Ich wäre dafür, is_empty alle Built-Ins für diesen Bool zu verwenden.

In Godot 3.0 und 3.1 hatten wir Set Methoden in C#. Diese fügten jedoch im Vergleich zur bloßen Verwendung eines Konstruktors und einer Zuweisung keine tatsächliche Funktionalität hinzu, ließen jedoch Code im Hintergrund fehlschlagen, sodass sie veraltet waren. Sie wurden hauptsächlich von mir hinzugefügt, um konsistent zu sein, da es bereits eine Methode für Quat gab, die aus dem Kern stammte, der Methoden festgelegt hat. Weitere Informationen finden Sie unter #30744

GDScript hat set_euler und set_axis_angle , aber es gibt auch Konstruktoren für das Gleiche ( q.set_axis_angle(myvec3, myval) kann durch q = Quat(myvec3, myval) . Core hat auch diese Methoden für Basis, aber sie sind nicht GDScript ausgesetzt.

Die Frage ist dann, was ist dagegen zu tun? Sollten die Quat-Set-Methoden zugunsten von Konstruktoren veraltet sein und mit C# konsistent sein, oder lohnt es sich, sie explizit bezüglich der ausgeführten Operation zu belassen? Wenn letzteres, sollten die Basis-Methoden auch exponiert werden?

@aaronfranke Ich fand es immer seltsam, dass diese Konstruktoren dedizierte Methoden hatten, wenn im Grunde nichts anderes funktioniert, also bin ich dafür, wenn möglich den ersten Weg zu nehmen.

@aaronfranke Bei diesem Problem geht es um das Umbenennen von Dingen in der API, nicht um Engine-Funktionalität oder Fehler.

Geometry s point_is_inside_triangle() bis is_point_in_triangle() , um den anderen Methoden zu entsprechen, die ebenfalls bool s in derselben Klasse zurückgeben.

TreeItem.get_children() sollte in get_first_child() . Das Dokument sollte auch erklären, dass die untergeordneten Elemente NICHT zurückgegeben werden. Untergeordnete Elemente werden mit get_next() iteriert.

Bei der Arbeit an #31976 ist mir aufgefallen, dass der Schattenatlaswert eine Potenz von 2 sein muss (sowohl für gerichtete Schatten als auch für Omni-/Spot-Schatten). Die Methoden akzeptieren jedoch jeden ganzzahligen Wert; Wenn es keine Potenz von 2 ist, rundet die Methode es auf die nächste Potenz von 2 auf. Wir sollten es wahrscheinlich eine Aufzählung von Werten akzeptieren, damit es in den Projekteinstellungen benutzerfreundlich dargestellt werden kann.

Ebenso sollte die anisotrope Filterstufe ein Enum sein (2×, 4×, 8×, 16×), da hier nur Zweierpotenzen sinnvoll sind.

VisualServer instance_create2() sollte geändert werden, um zu beschreiben, was es anders macht als instance_create() .

Für objektbezogene Übersetzungen hat Spatial translate_object_local was ein Vector3 , und Node2D hat move_local_x und move_local_y , die Schwimmer nehmen. Sowohl Spatial als auch Node2D sollten Methoden haben, die Vector3 bzw. Vector2 benötigen, und entweder translate_local oder local_translate würden einfachere Namen sein als translate_object_local .

@leonkrause Statt render_width und render_height wäre es sinnvoller viewport_width und viewport_height oder vielleicht canvas_width und canvas_height , da dies die Referenzauflösung ist, die für das Canvas-Ansichtsfenster verwendet wird und das Rendern nicht wirklich beeinflusst.

@akien-mga bitte erwägen Sie, die Baumnavigationsmethoden zu Ihrer Liste hinzuzufügen. Sie sind sehr verwirrend benannt und nicht gut dokumentiert.

Als ich ihnen zum ersten Mal begegnete, dachte ich, get_child() und get_next(), get_prev() betreiben einen Iterator, ähnlich wie Directory funktioniert. Ich musste meine eigenen Tests durchführen, um herauszufinden, dass sie nur bei jedem Aufruf denselben Zeiger produzieren.

get_children() sollte in get_first_child() umbenannt werden.

get_next() und get_prev() sollten in get_next_sibling() und get_prev_sibling() umbenannt werden

Wie wäre es mit der Umbenennung von Engine.iterations_per_second in Engine.physics_fps aus Gründen der Konsistenz mit den Projekteinstellungen?

is_processing :

Gibt true zurück, wenn die Verarbeitung aktiviert ist.

can_process :

Gibt true zurück, wenn der Knoten verarbeiten kann, während der Szenenbaum angehalten ist

Es könnte besser sein, can_process in can_process_paused umzubenennen, um Verwechslungen mit der Methode is_processing zu vermeiden.

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

Ich denke, diese Methode sollte umbenannt werden.

@dalexeev In was sollte es umbenannt werden und warum?

@Calinou Diese Methode druckt nicht wirklich etwas auf den Bildschirm; es gibt eine Zeichenfolge zurück. Der erste Gedanke ist, dass JSON.print genauso funktioniert wie Node.print_tree oder OS.print_all_resources oder wie alle anderen print* Methoden.

In was soll es umbenannt werden? Ich bin mir nicht sicher. JavaScript verwendet dafür JSON.stringify . PHP hat eine json_encode Funktion. Direkt in GDScript gibt es eine ähnliche Funktion - to_json .

UPD. JSON.serialize ist auch möglich, aber von der Anzahl der Zeichen her gleich JSON.stringify . :Lächeln:

Ich würde gegen das Wort "serialisieren" vorschlagen, da dies normalerweise für die binäre Serialisierung verwendet wird und eine solche Ausgabe weitere Schritte erfordern würde, um in diese Form zu gelangen.

Da diese Klasse nur über zwei Methoden zum Wechseln zwischen JSON- und Variant-Typen verfügt, würde ich gegen Methoden vorschlagen, die das Wort json da dies sinnlos ist.

Nun, für Dinge, die ein guter Name parse nicht wirklich ein klares Gegenwort ( siehe hier ). Vielleicht eines davon: encode , create , compose , generate ? Wenn encode verwendet wird, wäre es sinnvoll, die andere Methode in decode umzubenennen.

Ich habe gesehen, dass format und write als Umkehrung von parse . stringify hat jedoch den Vorteil, dass es unter Entwicklern bekannter ist, da es in JavaScript verwendet wird.

Ich habe gesehen, dass format und write als Umkehrung von parse . stringify hat jedoch den Vorteil, dass es unter Entwicklern bekannter ist, da es in JavaScript verwendet wird.

str2var ist VariantParser und var2str ist intern VariantWriter (siehe zum Beispiel #33241, ich habe sogar denselben Begriff verwendet, um es zu beschreiben).

Also bin ich für write , Konsistenz gewinnt. 😛

@Xrayez print in write ändern? Von Python zu Pascal? :Lachen:

Wie in https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552 vorgeschlagen, kann es sinnvoll sein, alles, was mit clear_color zu tun hat, in background_color umzubenennen (einschließlich der Projekt Einstellungen).

Ich würde erwarten, dass 4.0 aufgrund der besseren Leistung, der Verbesserung der GI-Sonden, des allgemeinen Hypes und so weiter eine große Welle neuer Leute in Godot bringen wird.

Wenn diese Änderungen mit 4.0 vorgenommen werden, werden diese Leute eine harte Landung bekommen, da fast kein existierendes Tutorial (außer dem offiziellen Tutorial für das erste Spiel) mehr für sie funktioniert.

Wenn diese Änderungen nach 4.0, sagen wir in 4.1, vorgenommen werden, wird es für diese Leute eine extrem holprige Fahrt. Sie haben gerade die Grundlagen einer neuen Engine erlernt, die sie nun wieder neu erlernen müssen. Der Anfang ist schwer, das zweimal zu kurz hintereinander durchmachen zu müssen, kann frustrierend genug sein, um ganz aufzugeben.

Wäre es daher nicht sinnvoll, vor dem Release 4.0 eine Version "3.3" oder "3.9" zu haben, die all diese kompatibilitätsbrechenden API-Änderungen enthält, den Tutorial-Erstellern jedoch genügend Zeit gibt, um einige Tutorials zu erstellen, bevor ein massiver Zustrom neuer Benutzer erwartet wird?

Ich bin mir nicht sicher, ob dies der richtige Ort ist oder nicht, aber da dies eine mögliche Teillösung für Umbenennungsprobleme sein könnte, werde ich es hier vorschlagen.
Warum nehmen Sie nicht alle erforderlichen Umbenennungsänderungen vor und fügen dann den Übersetzungen eine neue Sprache namens GodotOldNames/GodotPre4.0 hinzu, die alle alten Namen für alle Änderungen enthält.
Falls jemand die alten Namen in alten Tutorials nicht findet, kann er auf diese Weise einfach die Sprache in GodotPre4.0 ändern. Dies würde auch den Umstieg auf neue Namen erleichtern.
Dies löst nicht das ganze Problem, könnte aber zusammen mit #4397 funktionieren.

@Anutrix Dies würde eine Menge Komplexität hinzufügen (was ist mit nicht-englischen Sprachen?). Außerdem sind nicht alle im Editor angezeigten Strings von vornherein lokalisierbar.

Physik " Ebene ", Rendern " Ebene "

Ich erinnere mich, dass ich während meiner ersten Wochen, in denen ich Godot lernte, genau dieselbe Verwirrung durchgemacht habe wie dieser arme Mensch .

Physik "Layer", Render "Layer" mag für jemanden, der aus dem objektorientierten Design kommt , sinnvoll sein, aber für jeden anderen ist es sehr verwirrend. Der Begriff "Schichten" wird verwendet, wenn mehrere Farbschichten oder Stoffschichten in einem Stoff, Hautschichten einer Zwiebel (oder eines Ogers), Sedimentschichten auf der Planetenoberfläche, ...
Schichten (Plural, im Gegensatz zu einer einzelnen Schicht) scheinen in all diesen Fällen übereinander gestapelt zu sein.

Für viele Leute bedeutet "Layering", insbesondere wenn sie mit 2D-Grafiken oder -Animationen arbeiten, das Arbeiten mit einem Vordergrund, Hintergrund und Ebenen dazwischen oder darüber. Viele Leute denken an Schichten als Zelloloidfilme auf einem Hintergrund, obwohl Godot wie viele andere Spiel-Engines verschiedene Arten der "Sortierung" verwendet, um diese Aufgabe zu erfüllen.

Die Tatsache, dass wir die abstrakte Gemeinsamkeit, die Physik-Objekte oder Render-Objekte teilen könnten, "Ebenen" nennen, während diese abstrakten Gemeinsamkeiten gleichzeitig nichts mit dem Stapeln von visuellen Ebenen (das ist "Sortieren") zu tun haben, macht dies aus für manche so verwirrend.

Als ich die wahre Bedeutung und Verwendung von Physik "Layer", Render "Layer" verstanden habe, habe ich mich sofort gefragt, warum das nicht Physics Group, Render Group ist, und um ehrlich zu sein, weiß ich es immer noch nicht. Sie haben sicherlich keine übereinander stapelbare Beziehung zueinander, was bedeutet, dass ihre Reihenfolge oder Beziehung zueinander völlig irrelevant ist. Wenn ich sie als Layer benennen, archiviert imho nichts anderes als verwirrende Menschen, "Gruppe", "von Gruppe betroffen" für Masken oder vielleicht ein anderer Begriff, der mir gerade nicht einfällt, genauer wäre.

AnimationPlayer-Methode
.stop(false) sollte .pause(true) heißen
denn das tut es.

Projekt > Projekteinstellungen > Anzeige > Fenster > Strecken > Modus:

Der Dehnungsmodus "2D" sollte als Dehnungsmodus "Anzeige" oder "Allzweck" bezeichnet werden.
weil es verwirrend ist, es 2D zu nennen, wenn es für 3D-Anwendungsfälle genauso gut funktioniert, aber nicht wirklich gut für alle 2D-Anwendungsfälle (wie Pixelart-Projekte, während die Godot 2D-Projekte fast halbiert scheinen Pixelart zu sein.)
"display" wäre auch aussagekräftiger für das, was es tatsächlich tut: Rendern aller Grafiken, seien es 2D-Grafiken, 3D-Objekte, 2D-Meshes, Line2D und Polygons in der Display-Auflösung.
Mehr dazu hier .

loop, repeat, oneshot, von animationplayer, timer und ähnlichen knoten, könnten geklärt werden.

Schleifen, Wiederholen und kein One-Shot sein, sind alle dasselbe.

ich denke, dass
is_a_parent_of()
sollte umbenannt werden in
is_parent_of()

@KoBeWi siehe Diskussion unter #19801.

ich denke, dass
is_a_parent_of()
sollte umbenannt werden in
is_parent_of()

Ich glaube nicht, is_parent_of() schlägt vor, dass nur das erste Elternteil berücksichtigt wird, während die Funktion rekursiv nach allen Eltern sucht.

@groud In diesem Fall sollte es is_ancestor_of() heißen. Gibt es auch für umgekehrt eine entsprechende Funktion, dann sollte diese is_descendant_of() heißen.

@groud In diesem Fall sollte es is_ancestor_of() heißen. Gibt es auch für umgekehrt eine entsprechende Funktion, dann sollte diese is_descendant_of() heißen.

Ja, aber wenn man darüber nachdenkt, ist es nicht sehr notwendig, beide Funktionen zu haben, da der Unterschied nur darin besteht, das "aufrufende" Objekt und das Funktionsargument zu vertauschen. Vielleicht könnten wir die Funktion einfach durch etwas wie is_descendant_of() ersetzen und wir sind fertig.

Vielleicht möchten wir push_error() und push_warning() in print_error() bzw. print_warning() umbenennen. Dies würde sie dank der automatischen Vervollständigung besser auffindbar machen :slightly_smiling_face:

@Calinou print_error() könnte mit printerr() verwechselt werden

Bitte erwägen Sie, den Namen der Methode TreeItem.get_children() ändern, da der Name impliziert, dass eine Sammlung von Kindern der Rückgabewert ist, wenn in der Praxis das erste Kind zurückgegeben wird und Sie dann über den Rest iterieren müssen sie mit get_next() (wie in #19796 beschrieben).

Zitat von @Zylann aus #31404:

[ rpc() / rset() in] remote_call() / remote_set() ?
Diese Methoden haben auch sehr kurze Namen, nicht sicher, ob ein Alias ​​​​ausreicht. Sie müssen wirklich viel Multiplayer mit Tonnen dieser Aufrufe pro Skript machen, um 3-Zeichen-Identifikatoren zu rechtfertigen (was die meisten Spiele sicher nicht tun).

Bearbeiten (03.01.2020): Beim zweiten Nachdenken könnten call_remote() und set_remote() sinnvoller sein, da wir bereits call_deferred() und set_deferred() .

Bearbeiten: Das Schließen / Wiedereröffnen unten macht nichts aus, ich habe zu schnell geklickt.

Folgende Methoden

OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

sollte aus Konsistenzgründen mit den Methoden aus der Klasse OS Klasse Input verschoben werden:

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 sollten auch die Signale tab_close und tab_hover bearbeitet werden.

• LightOccluder2D light_mask -> occluder_light_mask
• CPUParticles Flags Aufzählung -> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker get_name -> get_tracker_name
• PathFollow2D rotate -> etwas anderes
• ArrayMesh ArrayType Aufzählung -> diese löschen
• Mesh BlendShapeMode enum -> an ArrayMesh weitergeben

Erläuterungen in https://github.com/godotengine/godot/issues/15763#issuecomment -568908661

Die Signale meta_hover_started und meta_hover_ended RichTextLabel sollten umbenannt werden, damit sie den meisten anderen ähnlichen Namenskonventionen entsprechen: meta_hover_entered und meta_hover_exited . Dadurch wird nicht nur der Rest der Godot-API besser imitiert, sondern das aktuelle Namensschema führt aufgrund der alphabetischen Sortierung dazu, dass ihre Reihenfolge umgekehrt wird. Dies ist ein wenig verwirrend, wenn Sie die Dokumente lesen, da der chronologische Ablauf der Operationen eindeutig darin besteht, zuerst einzutreten und dann zu beenden. Es verbessert einfach die Lesbarkeit und Konsistenz, um es zu ändern.

Mir ist aufgefallen, dass es keine Texture.size-Eigenschaft gibt. Ich musste stattdessen den Getter Texture.get_size() aufrufen.

Ich fragte in Discord, ob dies beabsichtigt war oder nicht. Ein Vorschlag war, hier zu posten, ob dies in eine Eigenschaft umgewandelt werden muss, der andere Vorschlag war, dass die Verwendung von get_size() das derzeit erwartete Verhalten ist, da es dafür keinen 'Setter' gibt.

@jmbjr Haben wir schreibgeschützte Eigenschaften als Eigenschaften

Ja, ich denke, wenn Sie beginnen würden, schreibgeschützte exponierte Eigenschaften zu unterstützen, benötigen Sie ein USAGE-Flag dafür und müssen auch GDScript-Parser/Compiler-Code hinzufügen, der dies unterstützt.

SoftBody hat ein areaAngular_stiffness das area_angular_stiffness (dasselbe gilt für alle verwandten Methoden).

Input.joy_connection_changed (die Methode) scheint nicht der Scripting-API ausgesetzt zu sein, sie wird intern vom Joystick-Handhabungscode jeder Plattform aufgerufen.

@akien-mga Als ich diese Methode zum ersten Mal sah, sehr früh nachdem ich Godot entdeckt hatte, hatte ich ähnliche Gedanken, dann erinnerte ich mich daran, wie Kojima ein legendäres Gameplay in MetalGearSolid um eine Methode herum aufgebaut hat, die dieser sehr ähnlich sein muss, und ich dachte: " Godot gibt mir sogar die Möglichkeit, die vierte Wand genau wie Kojima mit einer einzigen Codezeile zu überwinden, wie großartig ist das!"

Label und RichTextLabel haben inkonsistente Designeigenschaften:

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

Aufgrund unterschiedlicher Standardwerte hat dieselbe Schriftart auch unterschiedliche Höhen in Label und RichTextLabel .

Das request_completion Signal von TextEdit könnte in completion_requested , um die Vergangenheitsform zu verwenden. Die aktuelle Version klingt im Gegensatz zum Callback-Y-Charakter von Signalen etwas zwingend.

eine weitere Inkonsistenz mit physikalischen Körpersignalen

Bereich:

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 )

Ich nehme an, area_shape in den letzten beiden sollte self_shape sein? oder ...

Starrer Körper:

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 )

hier heißt es local_shape ...

@FrederickDesimpel Soweit ich weiß, können Argumente umbenannt werden, ohne die Kompatibilität zu

In Variante:

Real -> Float
Null -> Null?

Ich persönlich mag den "echten" Namen, da der Begriff "float" oft speziell für 32-Bit-Floats verwendet wird, aber der Real von Variant ist ein Double, und die meisten Engines verwenden real_t was beides sein kann.

PS Das haben wir bereits 2017 andersherum umbenannt.

Haben wir überlegt, diese umzubenennen:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial wurde im Master bereits in StandardMaterial3D umbenannt.

Sollen die limit_ Werte für Camera2D in Rect2i geändert werden? Im Moment sind es nur vier Ints.

BEARBEITEN: Der Ziehrand könnte auch in Rect2 geändert werden.

String::begins_with zu String::starts_with .

Wie in ernsthaften Programmiersprachen (Java, Python usw.).

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

Obwohl das Wort "just" fehlt, entspricht event.is_action_...() Input.is_action_just...().

Wir sollten wahrscheinlich die ersten beiden Argumente von Node.add_child_below_node() vertauschen, damit das erste Argument dasselbe ist wie Node.add_child() . Siehe #19642.

_semantische Atelophobie sprechen…_

Sollte Node2D.draw_circle Node2D.draw_disk da es eine Scheibe und keinen Kreis zeichnet?
Node2D.draw_circle könnte immer noch als Abkürzung für draw_arc von 0 bis TAU .

@Goutte Auf Englisch kann sich "Kreis" entweder auf einen hohlen Kreis oder einen gefüllten Kreis beziehen. Ich denke, der aktuelle Name ist besser auffindbar, also würde ich ihn nicht ändern.

Im Englischen kann sich "Kreis" entweder auf einen hohlen Kreis oder einen gefüllten Kreis beziehen.

Ich kann nicht finden , alles unterstützt dies . Hast du eine Quelle für diese Behauptung oder ist das ein Bauchgefühl?

Was die Auffindbarkeit betrifft, können wir immer noch draw_circle , es würde einfach einen Kreis und keine Scheibe zeichnen.

Ich kann nicht finden , alles unterstützt dies . Hast du eine Quelle für diese Behauptung oder ist das ein Bauchgefühl?

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

1 b : eine geschlossene Ebene (siehe Ebeneneintrag 6 Sinn 2b) Kurve, deren jeder Punkt äquidistant (siehe äquidistanten Sinn 1) von einem Fixpunkt innerhalb der Kurve ist
1 c : die durch eine solche Kurve begrenzte ebene Fläche

(1 b) ist ein mathematischer Kreis (Perimeter), (1 c) ist eine mathematische Scheibe (Fläche).

In Bezug auf die API ist es IMO benutzerfreundlicher, draw_rect(bool filled) und draw_circle(bool filled) als draw_rect() , draw_filled_rect() , draw_circle() und draw_disk() (oder wie wäre der mathematische Name für ein gefülltes Rechteck?).

Bearbeiten: Tatsächlich hat draw_circle() noch kein filled Argument. Ich denke, wir sollten eine hinzufügen, damit sie sowohl zum Zeichnen von Kreisen (Umfang) als auch von Scheiben (gefüllter Kreis) verwendet werden kann.

Nett, danke. Die meisten meiner Schüler sind Franzosen und alle waren davon verwirrt, und ich war es auch, und sie gaben Godot die Schuld und ich konnte sie natürlich nicht lassen.

Was wäre der mathematische Name für ein gefülltes Rechteck?

Das ist eine ziemlich gute Frage; Alles, was ich finden kann, ist "Rechteckfläche" oder "Rechteck-Innenraum", und keines ist ausreichend. Das Wiki gibt sogar an, dass die meisten Leute den Begriff _Polygon_ missbrauchen, um das _Innere eines Polygons_ zu bezeichnen, ohne ein anderes Wort dafür anzugeben.

Ich denke, ein filled Argument könnte helfen, die Mehrdeutigkeit zu verringern, aber es wird mühsam sein zu entscheiden, wo es in die Liste der Argumente aufgenommen werden soll.

@Goutte, aber es wird

Da es ein optionales Argument ist (es hat einen Standardwert) und auch aus Konsistenzgründen mit draw_rect sollte es am Ende stehen.

Es gibt Fälle, in denen Kontrollknoten als Modalknoten bezeichnet werden. https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal Meist in Bezug auf die Funktion Viewport.get_modal_stack_top()

EditorInterface Methoden get_selected_path und get_current_path EditorInterface sind in Namen und Funktion verwirrend. Ihnen fehlt auch die Dokumentation.

Diese Methoden sind nur eine dünne Schicht über den gleichnamigen Methoden von FileSystemDock :

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

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

Sie sollten beide entweder "ausgewählt" oder "aktuell" (oder etwas anderes, aber für beide) anpassen, wobei eines get_*_path und das andere get_*_dir .

@Goutte Ist Solid Rectangle nicht eine Alternative zum gefüllten Rechteck?

Wird das OP nach dem Juni 2019 mit Vorschlägen aktualisiert? Ich verstehe, dass dies viel Arbeit ist, aber diese Art von Tracker ist auch perfekt für Mitwirkende, um sie gemeinsam anzugehen. Und ich nehme an, es ist bereits die Zeit, in der wir daran arbeiten können, mehr Dinge umzubenennen?

Eine Aktualisierung des OP würde auch bedeuten, dass der gepostete Vorschlag vom Team als sinnvoll akzeptiert wird.

@Anutrix "gefüllt" ist ein besseres Wort als "fest", da "fest" "nicht flüssig oder

@pycbouh Es wäre auch eine gute Idee, PRs für jedes Problem zu verknüpfen, falls es eines gibt. Das OP tut dies bereits, aber nicht für die Kommentare darunter.

Ich weiß nicht, ob es angehoben wurde , aber mir war nicht klar, wie oft ich aufhöre, um in das Dokument zu schauen, um dieses hier zu sehen:

• Array.remove => remove_at (wie C#) nach Index entfernen
• Array.erase => remove_value , oder einfach remove (wie C#), um nach Wert zu entfernen

(oder Varianten davon mit erase )

Denn im remove bedeuten erase und remove das gleiche für mich, außer dass das eine nach Index und das andere nach Wert ist. Ich vergesse immer wieder, welches was ist.

Wurde schon erzogen, mein Böser. Habe nicht gemerkt, Github faltet den Thread, meine Strg+F-Suche hat es verpasst xD
Noch nicht im OP

@Zylann Los geht's: https://github.com/godotengine/godot/issues/16863#issuecomment -441376010

Als ich Zylann unterstütze, vergesse ich immer wieder, dass das Entfernen nach Index erfolgt...

Die Aufzählung ButtonList sollte wahrscheinlich in MouseButtonList da es sich um Maustasten handelt.

Soll die Aufzählung JoystickList aufgeteilt werden? Es enthält sowohl Schaltflächen als auch Achsen, es könnte sinnvoller sein als JoypadButtonList und JoypadAxisList oder ähnlich.

Nur eine Frage, warum nicht MouseButton ?
if button == MouseButton.LEFT:
liest sich schöner als
if button == MouseButtonList.LEFT:

Gute Idee. In diesem Fall gibt es auch KeyList -> Key , MidiMessageList -> MidiMessage , und die Joysticks müssen List entfernt werden .

Mir ist aufgefallen, dass einige Methoden/Eigenschaften normal_map , während andere normalmap . Wir sollten uns auf eines von beiden einigen, aber wahrscheinlich nicht auf beides. Ich würde normal_map bevorzugen, aber ich bin auch mit normalmap einverstanden.

GDScript

range_lerp() = map()
Samen = set_seed()

map() ist wahrscheinlich für die neuen Funktionen der funktionalen Programmierung reserviert.

Vector2.tangent() wird in den Dokumenten wie folgt beschrieben: Returns a perpendicular vector. , das ist die Definition von orthogonal oder orthonormal wenn der zurückgegebene Vektor normalisiert ist. Da Vector2.tangent() einen nicht normalisierten Vektor zurückgibt, schlage ich vor, dass wir ihn in Vector2.orthogonal() oder sogar Vector2.perpendicular() umbenennen sollten, wenn die Leute etwas gegen die mathematische Nomenklatur haben oder vielleicht sogar Vector2.normal() , aber die Leute könnten zwischen normalized() und normal() verwechselt werden

Anekdotisch auf meiner Seite, aber als ich zum ersten Mal danach suchte, waren meine ersten Recherchen in den Dokumenten nach _senkrecht_.

Sie könnten .tangent() auch nur als Alias ​​für .perpendicular() , nicht wahr?

Ich mag den Namen orthogonal weil er im Vergleich zu den anderen kein gebräuchliches englisches Wort ist. Ich habe vorher kein Problem mit tangent , aber ich denke, perpendicular ist sowieso ein besserer Name.

Ja, orthogonal ist selten. Ich stimme für .perpendicular (), aber auch den tangent ()-Alias ​​für compat BEHALTEN, es ist kürzer.

@Zireael07 Ich würde es vorziehen, wenn wir nur eine Möglichkeit hätten, die Tangente zu erhalten. Ich glaube nicht, dass es eine sehr häufige Operation ist.

Sie wären überrascht, wie oft ich es in meinen Procgen-Skripten verwende :)

Ich habe nicht erwartet, dass dies eine Debatte auslöst, aber ich persönlich bin dagegen, Vector2.tangent() da dies eine falsche Verwendung des üblichen mathematischen Begriffs ist. Das Produkt von Vector2.tangent() ist per Definition einfach falsch. Der Name dieses Threads ist der nächste geplante Kompatibilitätsbruch, daher sehe ich keinen Grund, warum wir uns nach hinten beugen sollten, um die Kompatibilität zu wahren. Mir persönlich geht es gut mit Vector2.perpendicular() .

Vorschlag: Machen Sie den Parameter owner von find_node() standardmäßig auf false.

Vorschlag: Benennen Sie die Methoden/Signale von Tree , damit sie weniger verwirrend sind, zB in Bezug auf Begriffe/Status von "ausgewählt", "fokussiert" und "nichts".

Ich denke, dass Tree::ensure_cursor_is_visible irreführend ist und in etwas wie ensure_focused_item_visible oder ensure_selected_item_visible .

Sogar die Klassenreferenz sagt:

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() speziell den darunter liegenden nativen Typ zurück. Nachdem wir Skriptklassen benannt haben, ist es sinnvoller, diese in get_native_type() da die "Basis" des Skripts möglicherweise der Name eines Skripts sein könnte. Es ist irreführend.

@willnationsdev Es gibt auch get_class() https://github.com/godotengine/godot/issues/16863#issuecomment -491421079

@aaronfranke Nun, mit get_class() es allgemein verwendet, um sich auf "Wie heißt das Ding, das ich gerade ansehe?", zu beziehen. Im Falle eines Script würde ich also erwarten, "GDScript" , "CSharpScript" oder so etwas zurückzubekommen. Aber ja, bei Nicht- Script Klassen sollte es eine Methode sein, die den Namen der tatsächlichen Skriptklasse zurückgibt, wenn sie benannt ist. Es gibt sogar ein eigenes Thema dafür. https://github.com/godotengine/godot/issues/21789#issuecomment -618588900

Bearbeiten: Oh, ich denke, wenn wir get_class() , get_base_class() und get_native_class() , brauchst du wirklich get_instance_base_type() um get_instance_native_class() zu werden Halten Sie sich an die Namenskonvention und stellen Sie klar, dass es sich um die Instanz und nicht um die Informationen des Skripts handelt.

Ich denke, autotile_coord (Eigenschaften und Methoden) von TileMap sollten in tile_coord oder tile_coordinate da sowohl AUTO_TILE als auch ATLAS_TILE Verwenden Sie dies und der Name kann für neue Benutzer verwirrend sein. Docs benötigt auch ein Update. Ich kann diese Änderung vornehmen, wenn es kein Problem gibt.

Ziehen Sie in Erwägung, das Argument new_text aus LineEdit.text_changed entfernen, da es das gleiche Verhalten wie LineEdit.text .

Ziehen Sie auch in Erwägung, old_text entweder zusätzlich zu oder als Ersatz für new_text hinzuzufügen.

Bezogen auf https://github.com/godotengine/godot/issues/16863#issuecomment -394745886

Umbenennen "Kollisions layers", "VisualInstance Schichten", "rendern layer", ect
„Kollisions Gruppe“, „VisualInstance Gruppe“, „Gruppe machen“, „Lichtgruppe“

Die Verwirrung darüber, warum sich diese "Ebenen" nicht stapeln, kommt auf den Community-Kanälen wie ein winziges Uhrwerk auf.

Beachten Sie, dass sie in Maya, Lumberyard und Unity als Ebenen bezeichnet werden.

Nur weil jemand anderes etwas tut, heißt das nicht, dass es trotzdem keine Ursache hat
Verwirrung und ist eine gute Idee.

Am Montag, 18. Mai 2020, 13:09 Uhr schrieb Jummit [email protected] :

Beachten Sie, dass sie in Maya, Lumberyard und Unity als Ebenen bezeichnet werden.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

Ich bin überrascht, dass es noch niemand erwähnt hat, aber
Camera2D.zoom
die Kamera wird herausgezoomt, wenn der Zoom größer ist, was "Zoom" nicht funktioniert und nicht intuitiv ist. Nicht sicher, wie es umbenannt werden soll, vielleicht view_scale oder etwas Ähnliches.

@KoBeWi Anstatt zoom umzubenennen , sollten wir die Skalierung nicht

Dadurch wird die Kompatibilität unterbrochen, genau wie beim Umbenennen der Eigenschaft. Wenn wir die Route "Skala invertieren" wählen, kann dies leider nicht automatisch behoben werden. Dennoch könnte es auf lange Sicht zu weniger Verwirrung führen.

@Calinou @KoBeWi Gibt es einen Anwendungsfall für die direkte Verwendung dieser Zoom-Eigenschaft, oder müsste jeder sie jedes Mal invertieren, um sie maßstabsgetreu anzuwenden?

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

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

Vielleicht, aber wo ziehen wir die Grenze dazu und so etwas wie Node2D.get_position_2d() ?

Vielleicht könnten wir die Klasse Viewport2D benennen, aber das wäre nicht erforderlich, es sei denn, wir erstellen ein Viewport3D.

@nathanfranke Ich habe diese Methode vorgeschlagen, weil allein der Name nicht sagt, ob es sich um 2D oder 3D handelt, wenn man bedenkt, dass es 2 Arten von Transform . (Während andere Mitglieder bereits canvas_ oder mouse_ )

@Zylann Diese Methode ist eigentlich wirklich seltsam. Es gibt Eigenschaften namens canvas_transform und global_canvas_transform , und die Beschreibung von canvas_transform lautet:

Die Canvas-Transformation des Viewports, nützlich zum Ändern der Bildschirmpositionen aller untergeordneten CanvasItems. Dies ist relativ zur globalen Leinwandtransformation des Ansichtsfensters.

Sie würden also erwarten, dass get_final_transform beide Transformationen kombiniert erhält. Wenn Sie sich jedoch den Code ansehen, ist dies nicht das, was er tut.

Der Code dafür ist return stretch_transform * global_canvas_transform; . Ich habe versucht herauszufinden, wofür stretch_transform ist, und ich habe keine Ahnung, es wird nicht angezeigt und es wird sicherlich nicht festgelegt, wenn canvas_transform . Es gibt auch eine Methode namens _stretch_transform die stretch_transform . Es wird von set_size aufgerufen, das den von _stretch_transform generierten Wert nimmt und ihn stretch_transform zuweist. Es gibt auch canvas_transform_override das ich noch nicht einmal erwähnt habe und nicht veröffentlicht wird, sondern intern verwendet wird.

Am Ende denke ich, dass diese ganze Klasse übersehen werden sollte. Viewport hat 4 verschiedene Transform2D-Mitglieder, 4 Rect2(i)-Mitglieder, 9 Vector2(i)-Mitglieder und 2 Transform (3D)-Mitglieder. Das sind bereits 264 Byte (mit Gleitkommazahlen einfacher Genauigkeit) von Datenstrukturen, die die Transformationsinformationen speichern, wenn Sie alle Zeiger addieren, und so ist es wahrscheinlich näher an 1 KB. Vielleicht braucht Viewport all dies, aber es scheint zu kompliziert zu sein, und zumindest sollte es Kommentare geben (in dieser Datei sind viel zu wenige).

Sollen Node2D/Node3D to_global und to_local entfernt werden? Ich habe Feedback zu #38902 gegeben, in dem vorgeschlagen wurde, Methoden hinzuzufügen, die nur mit der Basis funktionieren, aber es gibt einige Probleme mit diesen.

In den Demoprojekten wird to_local nirgendwo verwendet und $ grep -RIn "to_global" gibt nur 5 Ergebnisse zurück, die sich alle in der GUI in der 3D-Demo befinden, und die Leistung der Demo könnte durch Ändern verbessert werden Dies, damit es die globale Transformation zwischenspeichert und xform anstelle von to_global .

Kurz gesagt besteht die Sorge bei diesen Methoden sowohl darin, dass sie selten verwendet werden, als auch, dass sie das Schreiben von Code mit schlechter Leistung fördern, da er die globale Transformation mehrmals neu berechnet.

27509

AnimationPlayer animation_started und animation_finished sind etwas kontraintuitiv. Ersteres wird für alle Animationen in der Warteschlange aufgerufen, während letzteres nur aufgerufen wird, wenn das Ende der Warteschlange erreicht wird. Es wird in der Dokumentation nicht eindeutig erwähnt.

Wenn wir erkennen möchten, wann eine bestimmte Animation endet, müssen wir sowohl animation_changed als auch animation_finished was nicht praktisch ist.

Ich mag den Vorschlag von animation_finished wann immer eine einzelne Animation in der Warteschlange endet, und ein neues Signal hinzufügen animation_all_finished (ähnlich wie bei Tween ' s tween_all_completed ), die nur ausgelöst wird, wenn wir das Ende der Warteschlange erreichen.

Was ist mit animation_queue_finished und/oder animation_queue_started ?

Ich kann es hier nicht finden, also würde ich vorschlagen,
find und findn Paar.

Bild vom letzten stabilen Build 3.2.

Vielleicht können wir einen umbenennen, um zu erwähnen, dass die Groß-/Kleinschreibung beachtet wird.

Sagen wir, find_ignorecase statt findn ?

@swarnimarun Wir haben viele andere Methoden, bei denen die Groß-/Kleinschreibung nicht n enden. Wenn wir einen von ihnen umbenennen, sollten wir alle umbenennen.

Diese Methoden ( find / findn usw.) machen im Grunde dasselbe. Wir könnten einfach ein Argument hinzufügen, ob die Groß-/Kleinschreibung beachtet werden soll oder nicht.

@Calinou Ich würde es sehr vorziehen, GDScript zu verwenden, nachdem ich es für ein paar Monate fallengelassen habe, hat mir eine neue Perspektive auf die API gegeben, würde ich sagen,

Je offensichtlicher, desto besser. Sich an die API für alles zu erinnern, ist allein schon schwer, ein bisschen mehr Ausführlichkeit bei der Benennung von Funktionen scheint eine vernünftige Änderung zu sein.

@KoBeWi in der Lage zu sein, mit dem Funktionsnamen zu sagen, was er tut, anstatt daran zu denken, ein weiteres Feld hinzuzufügen oder beim Lesen von Code (nachdem dieser Teil der API vergessen / nicht bekannt ist) wird sehr geschätzt.

Ich würde also immer noch eine andere Funktion bevorzugen, auch wenn die andere Funktion nur die erste mit anderen Argumenten oder so aufruft.

EditorInterface.get_editor_viewport() => get_editor_main_container()

Diese Funktion gibt kein Viewport , sondern nur ein Control das zufällig die zentrale ist, die die 2D-, 3D-, Skript-Editoren und die Asset-Bibliothek enthält. Für die Aufzeichnung ist der zurückgegebene Knoten sogar ein VBoxContainer* , aber er ist abstrahiert (aber es ist wichtig zu wissen, da er Ihre Einstellungen beeinflusst).
Das Dokument ist auch falsch, da seine Beschreibung auf die Klasse Viewport verweist. https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class -editorinterface-method-get-editor-viewport

@Zylann Sollte get_editor_main_screen() da es sich nicht um einen Container, sondern um den Hauptbildschirm handelt .

@aaronfranke, das ist eigentlich auch ein Container Knoten^^ aber ja ... der Hauptbildschirm kann auch funktionieren

Ich möchte fragen: verfolgt jemand Vorschläge in diesem Thema?

Oben (https://github.com/godotengine/godot/issues/16863#issuecomment-557657413) habe ich beispielsweise vorgeschlagen, die Methode JSON.print umzubenennen. Es wurden mehrere Optionen vorgeschlagen, aber keine davon tauchte im ersten Beitrag auf.

Ich mache mir nur Sorgen, dass in so vielen Beiträgen nützliche Ideen verloren gehen. :Lächeln:

@dalexeev Ich habe vor kurzem einen ersten Durchgang beim Aktualisieren des ersten Beitrags gemacht, aber ich habe noch nicht alle Kommentare durchgegangen.

Ich habe einen, der möglicherweise einige Fehler in RichTextLabel behebt. Derzeit haben wir bbcode_text und text , aber beide verwenden intern dieselbe Datenstruktur. Nur die aufgerufenen Methoden sind unterschiedlich, während set_bbcode auf set_text zurückfällt, wenn use_bbcode nicht aktiviert ist. Also habe ich sie in #39148 entfernt. Ich habe dort noch einige andere Punkte hinzugefügt.

GetSceneInstanceLoadPlaceholder() in Node sehen sehr falsch aus, erstens wird kein Platzhalter zurückgegeben, wie der Name vermuten lässt, sondern ein Bool und zweitens werden Details von geerbten Implementierungen in die Basisklasse ohne wirkliche Anforderung (Testen des Typs) des Knotens ist auf andere Weise möglich)

RayShape → SeparationRayShape , wie ursprünglich in Godotengine/godot-proposals#711 vorgeschlagen.

Wie wäre es, wenn Sie sort_custom entfernen und sort optional aufrufbar machen?

Sollten wir OS.get_ticks_msec() und OS.delay_msec() zugunsten von OS.get_ticks_usec() bzw. OS.delay_usec() entfernen? Dies würde vermeiden, dass es zwei Möglichkeiten gibt, dasselbe zu erreichen. Wenn Sie einen Wert in Millisekunden benötigen, können Sie ihn multiplizieren oder durch 1000 dividieren.

Außerdem ermöglichen sowohl GDScript als auch C++ das Hinzufügen von Trennzeichen in ganzzahligen Literalen, wodurch große Werte besser lesbar werden.

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

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

Außerdem ermöglichen sowohl GDScript als auch C++ das Hinzufügen von Trennzeichen in ganzzahligen Literalen, wodurch große Werte besser lesbar werden.

Wenn die Entfernung stattfindet, sollte die Beschreibung in get_ticks_usec() die Trennzeichen enthalten.

@Calinou Einerseits hast du Recht, aber andererseits - in den meisten Fällen ist eine so große Genauigkeit nicht erforderlich.

'Alpha-Schere' in räumlichem Material sollte zum Standard-'Alpha-Clip' werden

@ Flavelius Ich habe den Begriff "

Das ist viel zu ändern! Arbeitet jemand an der Umsetzung dieser Vorschläge?

@MCrafterzz Leute öffnen regelmäßig Pull-Requests, um Dinge umzubenennen. Dies geschieht inkrementell und nicht auf einmal.

Textur (Texture2D) und Bild

• get_data() in Texture (Texture2D) sollte get_image() heißen und get_data() in Image sollte get_bytes() heißen, um selbstbeschreibend zu sein.

IMO: get_image ja, get_bytes nein.

texture.get_image().get_data()

Mesh / MeshInstance

• In Mesh erhalten/setzen Sie Materialien mit diesen Methoden:
  surface_get_material/surface_set_material
• In MeshInstance erhalten / setzen Sie mit diesen Methoden:
  get_surface_material/set_surface_material

Es sollte die gleiche Benennung sein, denke ich?

@Coldragon Es sollte get_surface_material / set_surface_material und eine Eigenschaft von surface_material .

@Coldragon Es sollte get_surface_material / set_surface_material und eine Eigenschaft von surface_material .

Es ist kein "normales" Set/Get, sie haben einen Index für die Zieloberfläche (es ist ein Vektor innerhalb der Mesh-Klasse).

Array wir sollten empty() in is_empty() umbenennen, um besser zu veranschaulichen, dass es boolesch ist

String wir sollten find_last() zugunsten von rfind() . Nicht gerade eine Umbenennung, aber es lohnt sich dennoch zu diskutieren, welche Sie behalten möchten.

Für einzelne Zahlen haben wir stepify . Für Vector2/Vector3 haben wir snapped .

Sie tun dasselbe, die Vektoren rufen stepify für jede Komponente auf. Ein Name sollte gewählt werden, aber welcher?

Umfrage: :heart: = beide sollten stepify , :rocket: = beide sollten snapped , :-1: = nicht umbenennen.

AABB hat intersection , während Rect2 clip . Sie tun dasselbe. Ein Name sollte gewählt werden, aber welcher?

Umfrage: :heart: = beide sollten intersection , :rocket: = beide sollten clip , :-1: = nicht umbenennen.

@aaronfranke ja, ich habe zuvor den Namen intersection in https://github.com/godotengine/godot/issues/16863#issuecomment -449628319 vorgeschlagen. Wir haben dann intersects das in overlaps in Rect2 , aber bei AABB bezüglich intersects nicht sicher ist → overlaps umbenennen.

Ich denke, find_node und/oder get_node sollten umbenannt werden, da die Namen nicht auf Unterschiede zwischen den 2 hinweisen.
Da find_node nur nach Kindern sucht, vielleicht find_child_node?
Ich bin mir nicht sicher, was ein guter alternativer Name für get_node wäre. Mein erster Gedanke war get_tree_node, da es einen Knoten von überall im Baum abrufen kann, aber auch außerhalb des Szenenbaums mit relativen Pfaden verwendet werden kann.

Ich finde get_node gut, aber find_node könnte in find_child

@MuffinManKen Ich denke, dass get_node vollkommen verständlich ist, da es, wie Sie gesagt haben, jeden Knoten überall abrufen kann, solange er mit demselben Baum wie der angegebene Knoten verbunden ist, unabhängig davon, ob er Teil davon ist den SceneTree oder nicht.

@Coldragon Ich bin mir nicht sicher, ob ich find_node in find_child umbenennen möchte, da ich dann den Eindruck habe, dass es aus irgendeinem Grund nur mit direkten Kindern funktioniert. Die Alternative wäre, es find_descendant oder so zu nennen, aber das ist viel zu wortreich/komplex. Es macht auch keinen Sinn, es auf nur find() zu reduzieren, da dann unklar ist, wonach wir suchen. Daher denke ich, dass find_node so bleiben sollte, wenn keine andere Alternative gesucht wird. Es sollte nur klar dokumentierte Unterschiede im Verhalten der API-Dokumente aufweisen.

In Godot 3.1 habe ich ein standalone Feature-Tag hinzugefügt, das zu true ausgewertet wird, wenn das Projekt von einer Exportvorlagen-Binärdatei (Debug oder Release) ausgeführt wird. Das Gegenteil ist editor , die zu true ausgewertet wird, wenn das Projekt von einer Editor-Binärdatei ausgeführt wird.

Mit der Zeit denke ich jedoch, dass es besser wäre, standalone in runner umzubenennen, da es kürzer und etwas selbsterklärender ist. Was denken Sie?

Was ist mit exported oder release ?

@aaronfranke exported impliziert, dass das Projekt exportiert wurde, was nicht unbedingt der Fall ist. Sie können eine Exportvorlagen- Binärdatei verwenden , um ein Projekt direkt aus seinen Quelldateien auszuführen, sofern zuvor Assets importiert wurden.

Außerdem wird release bereits für Binärdateien im Release-Modus verwendet (im Gegensatz zu debug , das für Binärdateien im Debug-Modus verwendet wird).

runner scheint mir nicht ganz klar. standalone ist in Ordnung. Es wäre auch in Ordnung, es zu entfernen, da Sie einfach !OS.get_feature("editor") .

Es wäre auch in Ordnung, es zu entfernen, da Sie einfach !OS.get_feature("editor") .

Dies kann jedoch nicht zum Überschreiben von Projekteinstellungen verwendet werden, da es dort keinen .not Selektor gibt. Es ist wahrscheinlich machbar, indem man die Standardeinstellung und ihre Überschreibung vertauscht, aber es fühlt sich etwas komplizierter an.

Warum dann nicht app oder game als Kontrast zu editor ? Oder wäre das nur verwirrender? Vielleicht haben Sie ein Feature-Flag für no-editor , um expliziter zu sein?

@willnationsdev game impliziert, dass Godot nur für Spiele verwendet werden kann. Viele Leute verwenden Godot erfolgreich für Nicht-Spiele-Anwendungen, daher würde ich es vorziehen, einen umfassenderen Begriff zu verwenden :slightly_smiling_face:

Außerdem ist es nicht wirklich selbsterklärend: Die Leute denken vielleicht, dass es immer noch für Projekte gilt, die vom Editor aus ausgeführt werden (Sie führen das "Spiel" schließlich vom Editor aus). Das gleiche gilt für app .

Wie wäre es mit "unabhängig"?

Am Sa., 25.07.2020, 5:49 Uhr Hugo Locurcio, [email protected]
schrieb:

@willnationsdev https://github.com/willnationsdev Spiel impliziert Godot
kann nur für Spiele verwendet werden, was sich als nicht der Fall erwiesen hat 🙂

Außerdem ist es nicht wirklich selbsterklärend: Die Leute könnten es immer noch denken
gilt für Projekte, die im Editor ausgeführt werden. Das gleiche gilt für App.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
.

@MuffinManKen independent klingt für mich auch nicht sehr selbsterklärend.

Editor vs Standalone ist wahrscheinlich die Standardbenennung (zumindest eine, die ich in vielen verschiedenen Engines sehe), also kein Grund, das Rad imho neu zu erfinden.

Get_node ist nicht darauf beschränkt, Nachkommen zu erhalten, das wäre also ein sehr
irreführender Name. Die 2 Methoden brauchen sehr unterschiedliche Namen, denn was sie
tun ist ganz anders.

Am Sa., 25.07.2020, 15:14 Uhr golddotasksquestions, <
[email protected]> schrieb:

Ich erinnere mich an die Verwirrung, mit der ich am Anfang lange Zeit hatte
find_node und get_node. Ich hätte wirklich gerne find_descendant und
get_descendant, da diese wahr und informativ wären @willnationsdev
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
Die "Wordyness" ist vielleicht nicht jedermanns Sache, aber imho ist es nicht wirklich ein
Problem, da es eine automatische Vervollständigung und die Abkürzung "$" gibt.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
.

Ich denke, in beiden Methoden Transform und Transform2D inverse und xform_inv umbenannt / entfernt werden, weil das, was diese Methoden tatsächlich tun, nicht das ist, was die Leute von ihnen erwarten . Weitere Informationen: https://github.com/godotengine/godot/issues/39433#issuecomment -664024521.

RayCast.cast_to sollte in RayCast.segment oder so umbenannt werden. Jemand hat mir gerade gesagt, dass er 40 Minuten gebraucht hat, um zu erkennen, dass es sich um eine Eigenschaft und nicht um eine Funktion handelt. Wahrscheinlich, weil es auch ein Verb ist.

Was ist mit RayCast.target ?

@razcore-art Ich habe kürzlich eine Frage zum Ray Casting beantwortet und das Wort segment , um es zu beschreiben, daher denke ich, dass es Sinn macht. Aber dies könnte auch als direction und length umgeschrieben werden, sodass es tatsächlich eher einem Strahl als einem Segment ähnelt (oder nur alternative Eigenschaften bereitstellen könnte, die nebeneinander existieren könnten). . Das Problem besteht darin, dass es im Inspektor keine einfache Möglichkeit gibt, einen normalisierten Richtungsvektor festzulegen. Ich habe einen Vorschlag geschrieben, um einen zumindest für 2D zu machen: godotengine/godot-proposals#397, aber das ist vielleicht zu weit hergeholt.

BEARBEITEN: Bei weiterem Nachdenken würde segment in Bezug auf RayCast Knoten nicht viel Sinn machen, aber in Bezug auf Physics2DDirectSpaceState.intersect_ray() Sinn machen.

Was ist mit RayCast.target ?

@nathanfranke Ich würde annehmen, dass das Ziel ein Node oder ein NodePath . Das könnte also zumindest RayCast.target_position . Vielleicht RayCast.cast_position oder RayCast.cast_offset . Vergessen Sie nicht, dass sich Raycasts drehen können, wodurch die tatsächliche Castposition in globalen Koordinaten verschoben werden kann.

Die PhysX-API bestätigt meine Vorstellung von Einheitenrichtung + Länge für die Konfiguration von Raycasts. 😛

Das heißt, ich tendiere zu cast_position ... Weil das Umschreiben der Funktionsweise von Ray Casting weitere grundlegende Änderungen erfordert.

@Xrayez Ich würde vermeiden, das Wort "cast" am Anfang einer Eigenschaft zu verwenden, da ich das natürlich als Verb "cast" und nicht als Nomen "cast" lese und daher cast_position wahrscheinlich nicht hätte hat das ursprüngliche Problem gelöst, nicht zu wissen, dass dies eine Eigenschaft und keine Methode ist (man könnte leicht annehmen, dass cast_position eine Methode ist, die in eine Position umwandelt). Ich mag target_position .

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

Kann KEY_BACK in KEY_MEDIA_BACK und KEY_FORWARD in KEY_MEDIA_FORWARD umbenennen. Möglicherweise gibt es andere Medienschlüssel, die ein MEDIA Präfix verwenden können.

Wir sollten in Erwägung ziehen, String begins_with() in starts_with() ändern.

So ist es in Java, C#, Python, JavaScript usw.

Bugsquad-Bearbeitung: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool , float , int sind die einzigen Typen/Klassen, deren Namen mit einem Kleinbuchstaben beginnen. Ich denke, sie sollten (in GDScript) in Bool , Float , Int . Dadurch wird das Problem mit der Hervorhebung der falschen Typsyntax automatisch behoben.

Und bool , float , int sollten nur für integrierte Python-ähnliche Funktionen von der @GDScript- Seite verwendet werden (sie enthalten auch len und str ).

Beachten Sie, dass die Situation bei str / String ähnlich ist: str(x) und String(x) ergeben dasselbe Ergebnis.

HINZUFÜGEN. Es hätte so aussehen sollen:

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

@dalexeev Sie werden in Kleinbuchstaben geschrieben, weil es sich um primitive Typen handelt. Sie werden dies in den meisten anderen Sprachen sehen.
Klassen wie Node sind Referenztypen und werden bei der Zuweisung nicht kopiert.

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

Wenn überhaupt, sollten wir in Erwägung ziehen, String in string da String nicht veränderbar ist und sich ähnlicher wie int verhält als Node .

Entfernen Sie dies vorerst, da dies auch bei Vector2 , Vector3 usw. der Fall wäre.

@nathanfranke In verschiedenen Sprachen ist das anders. Zum Beispiel werden in Kotlin, Haxe, Ada Namen aller Art großgeschrieben.

Darüber hinaus ist Primitivität ein bedingter Begriff. Für mich sind String , Color , Vector2 usw. primitive Typen, zumal sie als Wert und nicht als Referenz übergeben werden.

Das einzige Hindernis ist eine Verletzung der Abwärtskompatibilität.

da String nicht veränderbar ist

Überraschenderweise sind Strings im GDScript veränderbar:

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

Vector2 ist kein Primitiv, da es aus 2 float . Vector2 und float sind jedoch integrierte Variantentypen.

@Zylann Ist es ein so grundlegender Unterschied, dass er sich im

(Für mich ist 'primitiv' 'einfach', nicht 'einteilig'.)

Ich möchte dies nicht zu meinen Gunsten interpretieren, aber:

Namen primitiver Typen werden großgeschrieben. :Lächeln:

Hier sind die Begriffe, wie ich sie verstehe:

| Typname | Primitiver Typ | Werttyp | änderbarer Typ | Einbautyp |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| int | Ja | Ja | k.A. | Ja |
| Vektor2 | Nein | Ja | k.A. | Ja |
| Knoten | Nein | Nein | Ja | Ja |
| Zeichenfolge | Nein | Nein | Nein | Ja |

Unabhängig davon werden diese Namen nicht geändert. Sie sind in Ordnung, wie sie sind, und Programmierern verschiedener Sprachen vertraut. Wir sollten die Diskussion hier beenden, um diesen Tracker nicht mit sinnlosen Diskussionen zu füllen.

Die Spalte Mutable type ist falsch: Nur Object-derived, Dictionary und Array sind veränderbar. ( Vector2 sieht vielleicht veränderlich aus, da Sie vec2.x = 0 tun können, aber es bedeutet tatsächlich so etwas wie vec2 = vec2.with_x(0) )

Benennen Sie ShortCut in Shortcut

Die folgenden Methoden sollten geändert werden
Inkonsistenzen zwischen

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

zu

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

für Konsistenz mit
und

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

müssen korrigiert werden.

PS Ich bin nach dem Prinzip "Je weniger ähnliche Methoden, desto besser" ausgegangen.

@dalexeev Boolesche Parameter sind oft weniger lesbar als verschiedene Methoden, da true und false keinen Kontext haben.

Ja, aber Konsistenz wäre auch gut. Boolesche Parameter in InputEvent dann loswerden?

@Calinou In den meisten Fällen müssen Sie nicht nach

Ich sehe das nicht als großes Problem. Wenn Sie den Code eingeben, wird der Argumenthinweis angezeigt. Beim Lesen des Codes können Sie Umschalt + Klicken verwenden. Die Argumente für häufig verwendete Funktionen sind schnell zu merken (z. B. String.split ).

Außerdem wurden 208 optionale boolesche Argumente im Verzeichnis doc/classes (dies ist nur der Kern, und auch 16 Module haben ein verschachteltes Verzeichnis 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 kannst du erwägen, das in einen Spoiler zu setzen, um uns das Scrollen zu erleichtern?

@dalexeev Es gibt viele Fälle, in denen Sie überprüfen müssen, ob eine Taste gedrückt wird und nicht nur, ob sie gerade gedrückt wurde. Ein Skript zum Bewegen eines Charakters muss dies beispielsweise mit WASD oder den Pfeiltasten tun. So ziemlich jedes Spiel muss Eingaben verarbeiten, daher finde ich es nicht verschwenderisch, nur zwei Methoden für diese Dinge zu haben.

Beim Lesen des Codes können Sie Umschalt + Klicken verwenden.

Nicht, wenn Sie Diffs auf GitHub anzeigen. Wenn der Code eine lesbare IDE erfordert, ist es kein guter Code.

@aaronfranke Schlagen Sie für die anderen 207 Fälle auch vor, separate Funktionen zu erstellen? Wenn nicht, ist dieses Argument nicht schlüssig. Außerdem habe ich oben geschrieben, dass, wenn Sie den Parameternamen angeben können, dieser ohne IDE lesbar wird.

Es gibt viele Fälle, in denen Sie überprüfen müssen, ob eine Taste gedrückt wurde und nicht nur, ob sie gerade gedrückt wurde.

Oft, aber nicht öfter als ohne Echo.

Das Vorhandensein von drei Methoden ( is_action_just_pressed , is_action_just_released , is_action_pressed ) ist verwirrend, da Sie erwarten, dass es eine is_action_released Methode gibt.

HINZUFÜGEN. Welche Variante ist zumindest optisch einfacher?

is_action_released kann mit not is_action_pressed . Dies gilt nicht für die Methoden just .

Wie oben erwähnt, sollten rohe Bools vermieden werden. Ein Flag wie INPUT_ALLOW_ECHO/INPUT_NO_ECHO wäre viel besser als ein Bool.

@dalexeev Das würde nur Verwirrung is_action_pressed() und Echo sind 2 verschiedene Dinge. Sie können selbst überprüfen, ob Echoereignisse nach dem ersten Drücken leicht verzögert empfangen werden, während is_action_pressed() keine Verzögerung hat.

@KoBeWi Du magst Recht haben und

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

sollte geändert werden in

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

da dies nicht mit übereinstimmt

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 Was Sie vorschlagen, ist nicht richtig. Wenn wir über Echo-Ereignisse sprechen, sprechen wir von wiederholten Tastatur-Ereignissen beim Drücken einer Taste. Die Verwendung des Begriffs hier macht wenig Sinn, da das Aktionssystem nicht direkt auf Ereignisse angewiesen ist, sondern dessen Zustand pro Frame aktualisiert wird. Außerdem können Aktionen auch mit anderen Geräten wie Controllern oder Maustasten funktionieren, bei denen das Ereignis "Echo" nicht vorhanden ist.

get_children() von TreeItem gibt nur das erste Kind zurück und nicht alle Kinder, wie der Name (oder die Beschreibung in den Dokumenten) vermuten lässt.

[Bearbeiten]
Nvm die docs. Die Methodenbeschreibung wird im Master aktualisiert, sorry.

Ich empfehle local_to_scene Resource local_to_instance oder unique_per_instance . "Lokal zur Szene" bezeichnet das Verhalten als lokal zur Szene, wenn es tatsächlich pro Instanz einer Szene ist.

Benennen Sie Image.load() → Image.load_from_file() .

1. Hilft, mögliche Verwechslungen mit load("image.png") Dateien per Code zu vermeiden, siehe Dokumentationsänderungen unter #42412.
2. Image.load() wird nicht mehr als eingebauter Name von GDScript hervorgehoben: #28866.
3. Entspricht Image.load_*_from_buffer() pro Bildformat. Pufferbezogene Methoden können möglicherweise in derselben Schnittstelle vereint werden, um API-Aufblähungen zu verhindern, aber das ist ein anderes Diskussionsthema.

@Xrayez Es könnte sich auch lohnen, load in GDScript zu entfernen: https://github.com/godotengine/godot-proposals/issues/263

Die Variable registering_order und die zugehörige Methode set_registering_order in ProjectSettings werden nicht verwendet.

RandomNumberGenerator sollte in Random und globale Zufallsfunktionen wie randf und rand_range sollten veraltet oder entfernt werden.

Ich sehe mögliche Probleme, bei denen eine nicht vertrauenswürdige Funktion aufgerufen wird, während der zufällige Startwert angegeben ist

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

globale Zufallsfunktionen wie randf und rand_range sollten veraltet oder entfernt werden.

Besprochen im Rahmen von Godotengine/godot-proposals#1590.

Ich würde es vorziehen, wenn diese grundlegenden Zufallsmethoden aus Gründen der Zugänglichkeit und des Prototypings global verfügbar wären, zumindest einige davon. Aber seed() und rand_seed() können sicher entfernt werden.

Es sieht so aus, als ob FuncRef überflüssig geworden ist, seit Callable hinzugefügt wurde.

Ich habe die Methoden property_can_revert und property_get_revert im Inspektor entdeckt und in #43078 gemeldet. Ich denke jedoch, dass sie mit führenden Unterstrichen umbenannt werden sollten, um den Konventionen von _get , _set und _get_property_list zu folgen.

EditorImportPlugin und EditorExportPlugin scheinen verwandt zu sein, jedoch geht es bei einem um den Import von Ressourcen und bei dem anderen um den Export eines Projekts. Ich schlage vor, wir benennen EditorImportPlugin in EditorResourceImportPlugin oder so ähnlich.

Edit: Und EditorPlugin.add_import_plugin muss auch entsprechend umbenannt werden.

Warum nicht ResourceImportPlugin ? Viele (die meisten?) Editor-Klassen enthalten das Wort "Editor" noch nicht, wie SceneTreeDock oder all das Animationszeug.

Die Aufzählung Tracking_status in ARVRInterface sollte in TrackingStatus , um mit den Stilen anderer Aufzählungsnamen konsistent zu sein.

Wenn man sich ARVRInterface oben ansieht, ist die Qualität der Namen im Allgemeinen ziemlich schlecht. Hier sind auch meine vorgeschlagenen Umbenennungen:

• ar_is_anchor_detection_enabled → anchor_detection_enabled (Eigenschaft)
• interface_is_initialized → initialized (Eigenschaft, könnte weiter in enabled umgeschrieben werden, da sie einen Setter hat)
• interface_is_primary → primary (Eigenschaft)
• get_render_targetsize() → get_render_target_size() (Methode)
• uninitialize() → finalize() (Methode)

Ansonsten ist die Dokumentation falsch. 🙂

Beachten Sie, dass ich diese Klasse überhaupt nicht verwendet habe, aber diese Namen sehen schon beim Betrachten der Klasse seltsam aus.

Sollen wir Control.MOUSE_FILTER_PASS in Control.MOUSE_FILTER_PASSTHROUGH umbenennen? Dies würde deutlicher machen, dass das Ereignis durch den Control-Knoten an darunter liegende Knoten weitergegeben wird. Ich bin mir aber nicht sicher, ob sich eine Umbenennung wirklich lohnt.

@Calinou Ich kann mir nicht vorstellen, dass es weh tun würde, also würde ich unterstützen. Wie Sie bereits erwähnt haben, würde diese Änderung auf einen Blick deutlicher machen, was dieser Mausfiltermodus macht.

@Calinou Ich finde das aktuelle Verhalten ungewöhnlich. Dieses Szenen-Setup ergibt "Klick Child2, Click Scene"

(Beachten Sie, dass alle auf Pass eingestellt sind)

:smile: Proposition A : Vielleicht so etwas wie Control.MOUSE_FILTER_PASSPARENTS für das aktuelle Verhalten, da Eingabeereignisse nur an die Eltern gesendet werden.

:rocket: Proposition B : Ändere die Konstanten in diese:

• STOPP: Aktuelles Verhalten – Ereignis nehmen und jegliche Ausbreitung stoppen
• PASS_PARENT: Derzeit gleiches Verhalten wie PASS
• PASS_ALL: IGNORE, nimmt aber Ereignisse an
• IGNORIEREN: Aktuelles Verhalten - Ereignis nicht annehmen, aber dennoch verbreiten

:eyes: Proposition C : Ob der Knoten GUI-Eingaben entgegennimmt oder nicht, ist nicht wirklich relevant, da man einfach keine Signale verbinden kann (oder ein boolesches Flag verwenden). Wir können die Option in Control.propagation_mode ändern und haben diese Konstanten:

• KEINER
• ELTERNTEIL
• ALLE

Das würde meiner Meinung nach viel sauberer aussehen.

Das ist jenseits einer Umbenennung und sollte als Vorschlag diskutiert werden.

Warum sind all diese Umbenennungen so lang? Sie ändern etwas Einfaches und Kurzes in etwas wirklich Langes.

Sie ändern clip in intersection doppelt so lange, wie Sie eingeben müssen.
Außerdem änderst du Control.MOUSE_FILTER_PASS in Control.MOUSE_FILTER_PASSTHROUGH
etc

Ich würde einfachere und kürzere, weniger ausführliche Änderungen bevorzugen. Es ist ein Funktionsname, nicht auch eine Beschreibung der Funktion.

Ich würde einfachere und kürzere, weniger ausführliche Änderungen bevorzugen. Es ist ein Funktionsname, nicht auch eine Beschreibung der Funktion.

Der Name sollte jedoch beschreibend sein. Auch die Länge spielt keine Rolle, wenn Sie die Autovervollständigung (die im Godot-Editor integriert ist) nutzen.

Ich habe es einmal im IRC erwähnt und keine Antwort erhalten, aber TextureRect hat einen Dehnungsmodus namens "Scale On Expand (Compat)". Das klingt nach etwas, das entfernt werden könnte.

"Weniger ausführlich" steht definitiv nicht auf der Speisekarte, wenn wir in unseren Godot-Projekten robuste Codebasen haben wollen. Moderne Codierungstools bieten Autovervollständigung und andere intelligente Funktionen, mit denen Sie auch bei langen Namen schnell tippen können. Wenn Sie die Argumente für diese Änderungen lesen, besteht außerdem das Ziel, diese Funktionen für Entwickler, die sie verwenden, weniger eindeutig zu machen. Kurzname mag süß sein, aber verwirrend und weniger auffindbar.

Und denken Sie immer daran: Das Eintippen von Code ist der schnelle Teil der Softwareentwicklung. Viel wichtiger ist das anschließende Lesen und Verstehen des Codes. Es ist, als würde man ein Kind empfangen und großziehen.

Ich bin mit euch beiden nicht einverstanden. Ich bin ein Godot-Benutzer und verwende Godot speziell, weil GDScript knapp und schnell zu schreiben ist. Wenn Sie sie doppelt so lang machen, geht der Geschwindigkeitsvorteil verloren, da ich gezwungen bin, zweimal so viel zu schreiben, und doppelt so weit scrollen müsste, um die gesamte Codezeile horizontal zu sehen.

Wenn Sie codieren, möchten Sie keine unglaublich langen Funktions- oder Variablennamen eingeben. Einige dieser vorgeschlagenen Änderungen fügen aus Gründen der "Klarheit" auf Kosten von allem anderen extrem lange Funktions- und Variablennamen hinzu. Sie können die eingebaute Hilfe lesen, wenn Sie Zweifel haben. Beim Programmieren geht es um das Erlernen einer API. Sie werden immer nach einer Funktion suchen, wenn Sie sie zum ersten Mal verwenden, unabhängig vom Namen. Nehmen Sie printf in C ist knapp und einfach. In Godot würden Sie es send_formatted_string_to_standard_out. Sie zwingen nicht nur alle dazu, die API neu zu erlernen, sondern einige dieser Änderungen haben nicht einmal eine einheitliche Vision. Mir kommt es so vor, als hätten sich eine ganze Reihe von Leuten zusammengetan und jeder hat einen Teil des Motors geändert.

Nehmen Sie zum Beispiel Array
remove -> remove_at Was fügt _at hier hinzu? Sie haben bereits remove_value. Was können Sie noch entfernen?
erase -> remove_value Immer noch nicht klar genug. Aus Dokumenten "Entfernt das erste Vorkommen eines Werts aus dem Array." Die Leute denken vielleicht auch, dass Sie einen einzelnen Wert aus dem gesamten Array entfernen können. Der Übersichtlichkeit halber sollte es eigentlich remove_first_occurance_of_value denn genau das macht die Funktion. Du hast die Funktion also länger und ebenso verwirrend einfach länger gemacht.

Sie haben remove und erase zwei verschiedene Funktionen, aber Sie drehen beide in der gleichen Variation auf remove mit zusätzlichen Buchstaben. Aber sie funktionieren anders. Entfernen entfernt aus einem bestimmten Index, wobei mit Erase die erste Instanz eines gefundenen Werts entfernt wird.

Diese sind in Ordnung, nur nicht wirklich nützlich, außer die Leute zu zwingen, ihren Code zu aktualisieren.
invertieren -> umkehren
duplizieren -> klonen
leer -> ist_leer

Wenn es nicht kaputt ist, reparieren Sie es nicht.

@CarlGustavAlbertDwarfsteinYung, aber Sie werden nicht doppelt so viel tippen. Nach den ersten 3 Buchstaben, die Sie eingeben, wird die automatische Vervollständigung aktiviert und Sie wählen aus, was Sie brauchen, anstatt ganze Wörter einzugeben.

Bei anderen Namen, zum Beispiel, wenn Sie sich empty -> is_empty ansehen, ist eine Änderung erforderlich, um klarzustellen, was sie bewirkt. Wenn Sie sich empty ansehen, können Sie feststellen, ob dies eine Methode ist, die etwas leert, ob es ein Buch ist, das überprüft, ob etwas leer ist, oder etwas anderes? Mit is_empty können Sie auf einen Blick erkennen, dass dies ein Bool ist, das wahr ist, wenn etwas leer ist, und falsch, wenn es nicht leer ist. Sie sollten wissen, was Funktionen oder Variablen tun, indem Sie nur ihren Namen lesen. Das geht nicht mit Namen wie empty

@Feniks-Gaming Ich kann Ihnen sagen, dass empty oder is_empty gleichermaßen verwirrend sind, nur einer ist länger als der andere.

@CarlGustavAlbertDwarfsteinYung empty kann eine Aktion sein, wenn sie als Verb gelesen wird. is_empty ist definitiv eine Qualität. Diese Verwirrung kann natürlich von Ihrem Englischniveau abhängen.

Auch wenn eine Funktion in einem modernen Code-Editor send_formatted_string_to_standard_out aufgerufen wurde, kann sie als sfstso oder eine beliebige andere Kombination der Zwischenbuchstaben eingegeben werden, wenn Sie dies wünschen und die automatische Vervollständigung gibt Ihnen die einzige Möglichkeit.

@pycbouh Die Leute verwenden diese Engine schon seit wie vielen Jahren? Und ich habe noch keine Person gehört, die zu mir sagte, Sie wüssten, was das größte Problem mit diesem Motor ist. Die Tatsache, dass Arrays empty anstelle von is_empty .

Ihr sitzt hier und repariert Dinge, die niemand wollte oder verlangte. Ja, die Formulierung ist verwirrend, aber kein wirkliches Problem und nie ein Problem, seit ich diese Engine im Jahr 2015 verwende. Einige der vorgeschlagenen Änderungen sind sehr willkommen und um fair zu sein, verwende ich is_ . Ist leer wäre okay. Aber einige Änderungen sind viel zu lang und ebenso verwirrend. Ich habe speziell über diese Änderungen gesprochen, nicht alle.

Die ganze Existenz dieses Megathreads ist der Beweis dafür, dass die Leute danach fragen. Diese Probleme können für Sie oder jemand anderen unbedeutend sein, aber die Leute haben aufgrund einer schlechten Benennung Probleme, die API zu verstehen. Und dies ist die Art von Problemen, die in dieser Ausgabe gesammelt werden. Ob Sie es glauben oder nicht, was die Bedeutung dieser Änderungen insgesamt angeht, aber das Verfolgen und Implementieren dieser Änderungen nimmt die andere Entwicklungszeit nicht weg.

Und schau dir das Beispiel an, das du gegeben und versucht hast zu erklären:

Entfernen entfernt aus einem bestimmten Index, wobei mit Erase die erste Instanz eines gefundenen Werts entfernt wird.

Du schreibst das und siehst keinen Grund, die Namensgebung zu verbessern, um für alle aktuellen und zukünftigen Godot-Nutzer zumindest ein bisschen klarer zu sein?

@pycbouh Und tatsächlich habe ich sogar das Beispiel des Arrays remove_at und remove_value . remove_value ist nicht dasselbe wie die Beschreibung von Löschen und ist immer noch genauso verwirrend. Wert von wo entfernen? Wert vom Ende entfernen, vom Anfang entfernen? Alle Vorkommen eines Werts aus dem Array entfernen?

Wenn Sie wirklich etwas ändern müssen, verwenden Sie remove und remove_first_occurence , was es sowohl knapp als auch anschaulich macht.

@pycbouh Ich

Tatsächlich ist hier ein Vorschlag. Alle Änderungen an der API-Namensgebung sollten die Meinungen von Mitwirkenden/Spendern/Benutzern beinhalten. Wenn alle einverstanden sind, bin ich auch dabei. Machen Sie Umfragen und sehen Sie, was jeder sagt. Versuchen Sie nicht zu erraten, was andere Leute wollen. Was für Sie gut ist, kann für andere nicht gut sein.

Ich bin gegen etwa 50 % der hier vorgeschlagenen Änderungen, was ich gesehen habe.

50 % der Kommentare sind Personen, die mit den vorgeschlagenen Änderungen nicht einverstanden sind.

Können wir bitte die erfundene Statistik vor der Tür lassen?

Können wir über die vorgeschlagenen Änderungen abstimmen?

Dafür sind die Diskussion und die Reaktionen da.

Ich bin gegen etwa 50 % der hier vorgeschlagenen Änderungen, was ich gesehen habe.

Wenn Sie nur gegen sie sind, weil "Ich habe es auf diese Weise gelernt, also möchte ich, dass alle nach mir dasselbe leiden", dann ist dies eine ungültige Kritik an dem Vorschlag und wird ignoriert.

Was für Sie gut ist, kann für andere nicht gut sein.

Dito.

Können wir bitte die erfundene Statistik vor der Tür lassen?

Gefällt Ihnen diese Behauptung über die gesamte Community?

Diese Probleme können für Sie oder jemand anderen unbedeutend sein, aber die Leute haben aufgrund einer schlechten Benennung Probleme, die API zu verstehen.

Woher wissen Sie, womit die Leute Probleme haben? Hast du sie gefragt? Gab es hierzu eine Umfrage, eine Studie oder einen Fragebogen? Wie sind Sie zu dieser Information gekommen?

Ich bin ein solcher Benutzer, der bei Null angefangen hat und die API gelernt hat. Hatte keine Probleme mit der Namensgebung. Alle APIs haben einige seltsame Namenskonventionen. Alle Funktionen müssen etwas knapp sein, damit Sie sie in Code schreiben können.

@pycbouh Wenn Sie versuchen, mich davon zu überzeugen, dass alle Namensvorschläge hier gut sind, muss ich Ihnen respektvoll widersprechen. Dies ist ein Thread, in dem Änderungen diskutiert werden, und ich bin hier, um zu sagen, dass einige der vorgeschlagenen Änderungen nicht nur nicht notwendig / oder nicht erforderlich sind, sondern einfach länger und ebenso verwirrend sind. Einige sind in der Tat gut und willkommen. Lassen Sie uns nicht alles massenhaft umbenennen, nur weil ein paar Leute wie Sie denken, dass die gesamte Community ein Problem mit API-Namen hat. Ich habe und hatte nie und ich habe als Anfänger angefangen. Und ich kenne eine Handvoll anderer Leute, die das auch nicht tun. Ich glaube, dass einige dieser Änderungen bedeutend sind und vor einer vollständigen Veröffentlichung von der gesamten Community oder zumindest von Mitwirkenden überprüft werden sollten.

Woher wissen Sie, womit die Leute Probleme haben? Hast du sie gefragt?

Die meisten Einträge in diesem Thread werden von Leuten erzeugt, die Probleme haben, sei es hier auf GitHub (und in diesen Fällen werden Probleme verlinkt) oder über andere Community- oder persönliche Kanäle. Gehen Sie nicht davon aus, dass wir nur hier sitzen und unsere eigenen Geschlechtsteile lecken, weil wir nichts Besseres zu tun haben, als darüber nachzudenken, welche andere Funktion oder Eigenschaft wir in der Engine umbenennen sollen.

Außerdem wurden viele der hier vorgeschlagenen Änderungen nicht einmal umgesetzt, es gab keine PRs oder andere Aktivitäten. Sie sind aufgelistet und das wars. Behalten Sie die PRs im Auge und wenn eine Sie beleidigend erscheint, zögern Sie nicht, sie zu kommentieren. Danach liegt es am PM von Godot, die Änderungen zu genehmigen und zusammenzuführen. Seien Sie konstruktiv und Sie können einige unerwünschte Änderungen verhindern, aber vergessen Sie nicht, was Sie selbst einmal gesagt haben:

Was für Sie gut ist, kann für andere nicht gut sein.

Selbst wenn Sie bis zu diesem Zeitpunkt keine Probleme mit der API hatten, bedeutet dies nicht, dass andere keines von beiden hatten oder in Zukunft keine Probleme mehr haben würden.

Alle APIs haben einige seltsame Namenskonventionen.

Das ist gut, wenn es eine Konvention gibt. Aber einige der APIs in Godot wurden lange bevor es Open Source wurde benannt und sind möglicherweise nicht so durchdacht, wie man es sich erhoffen würde. Ich bitte Sie noch einmal, nicht davon auszugehen, dass die Leute hier zum Teufel Änderungen vorschlagen.

Bitte führen Sie hier keine Diskussionen dieser Art. Wenn Sie bestimmte API-Änderungen besprechen möchten, ist das in Ordnung, aber pauschale Aussagen, dass Ihnen die Vorschläge hier nicht gefallen, sind nicht hilfreich.

Die Core-Entwickler werden jeden dieser Vorschläge nacheinander überprüfen. Es ist wahrscheinlich, dass viele am Ende nicht akzeptiert werden.

Vorübergehend gesperrt, wird später entsperrt.

Könnten wir die folgenden Punkte in die Liste aufnehmen?

• AnimationPlayer : Benennen Sie stop() in pause() (https://github.com/godotengine/godot/issues/16863#issuecomment-562363660, godotengine/godot-proposals#287)
• AnimatedSprite : stop() umbenennen in pause() (#31168) (bereits hinzugefügt)
• AnimatedSprite3D : stop() umbenennen in pause() (#31168) (bereits hinzugefügt)
• Tween : Umbenennen von stop() in pause() , stop_all() in pause_all() (PR #41794, #43442)

Tween: Benennen Sie stop() in pause(), stop_all() in pause_all() um (#43442)

Dies wird durch #41794 abgedeckt

@opl- das wird auch hier diskutiert: https://github.com/godotengine/godot-proposals/issues/287

Ein paar Umbenennungen, die vielleicht klarer machen, was diese globalen RNG-Funktionen tun:

• seed() -> set_seed() (vielleicht auch get_seed() hinzufügen, um RandomNumberGenerator zu entsprechen) – Derzeit ist nicht klar, dass dies eine Setter-Funktion ist.
• rand_seed() -> rand_from_seed() – derzeit hört es sich so an, als ob es den Seed oder so etwas randomisiert, obwohl es tatsächlich eine Zufallszahl basierend auf dem bereitgestellten Seed liefert.

rand_seed() -> rand_from_seed() – derzeit hört es sich so an, als ob es den Seed randomisieren könnte oder so, wenn es tatsächlich eine Zufallszahl basierend auf dem bereitgestellten Seed gibt.

Außer dass es den Seed randomisiert. Lesen Sie die Dokumentation.

rand_seed() -> rand_from_seed() – derzeit hört es sich so an, als ob es den Seed randomisieren könnte oder so, wenn es tatsächlich eine Zufallszahl basierend auf dem bereitgestellten Seed gibt.

Außer dass es den Seed randomisiert. Lesen Sie die Dokumentation.

Es tut uns leid. Was ich meinte, ist, dass es so klingt, als ob es nur den Samen randomisiert. Vielleicht sollte es rand_int_from_seed() , da es ein int zurückgibt? Tatsächlich geben die Dokumente nicht an, welcher Typ zurückgegeben wird, sondern erwähnen nur eine "Zufallszahl". Ist es ein int?

Es generiert also einen neuen Startwert basierend auf einem Startwert, den Sie ihm übergeben, und generiert dann eine neue Zahl basierend auf diesem neuen Startwert? Bei einer Umbenennung bin ich mir nicht sicher, aber die Beschreibung kann dort etwas überarbeitet werden, wenn dies der Fall ist.

Wenn es so klingt, sollte diese Methode in 2 kleinere Methoden aufgeteilt werden, um eine Sache zu tun, anstatt sie umzubenennen

Kontrolle::pending_resize

Ungebraucht.

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

Ich verstehe jetzt, dass diese Methode größtenteils äquivalent zu GDScript is (was übrigens extends war), aber C++ erfordert mehr Deutlichkeit.

Die Verwirrung ich in lief überprüft , ob bestimmte Objekt Art von bestehenden (ohne Vererbung):

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

Die zugrunde liegende Implementierung verwendet "erbt" Makros/Vorlagen überall, daher ist es für mich sinnvoll, dies in inherits_class umzubenennen.

Siehe auch https://github.com/godotengine/godot/issues/21461#issuecomment -416155187:

get_class() und is_class() sind für mich generell verwirrend