Demasiado tedioso para mí, pero gracias a quien corrija instance como instantiate donde se usa como verbo.

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

Hay muchos más en la clase Control, el get / set debería tener el mismo nombre que la variable, es molesto revisar los muelles cada vez que conoce el nombre de la variable.

La clase TileMap tiene un montón de métodos getter y setter que no concuerdan con sus respectivas propiedades. De hecho, sugeriría cambiar el nombre de la mayoría de los captadores y definidores en esa clase, para que estén de acuerdo con sus propiedades, así como con el nombre en otras clases.

Animation.track_remove_key_at_position debe ser
Animation.track_remove_key_at_time

Métodos

• OS : execute debe dividirse en dos métodos diferentes, uno con bloqueo y el otro sin bloqueo.
  por ejemplo, nombres: execute / exec_process (bloqueo) y spawn_process (sin bloqueo) # 19302

LineEdit tiene un parámetro new_text en "text_changed" pero TextEdit no.

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

Me gustaría si se cambia el nombre de VBoxContainer / HBoxContainer / GridContainer a simple VBox / HBox / Grid ...

Y luego se le cambiará el nombre nuevamente porque es demasiado corto como pos-> position: D

Son un poco largos, tienes razón.

Noté que Godot actualmente tiene dos convenciones de nomenclatura diferentes en los nombres de sus métodos.

A veces, sigue una convención común que se puede encontrar en las API de lenguajes como C # o Java, como [action][object]() formulario: es decir)

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

Sin embargo, en otros lugares, sigue una convención diferente de [prefix][action][object]() , como:

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

Son solo algunos ejemplos entre muchos.

Si podemos permitirnos hacer cambios radicales que rompen la compatibilidad en algún momento en el futuro, me gustaría ver que se puedan cambiar de nombre para seguir una convención de nomenclatura única y bien definida (con suerte, la primera, ya que se usa con más frecuencia tanto dentro como fuera de Godot).

Sin embargo, en otros lugares, sigue una convención diferente de [prefix][action][object]() , como:

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

No verifiqué todos los usos, pero por lo que he visto, este estilo de denominación de métodos, aunque un poco incómodo, también sigue una convención específica. Por ejemplo, los métodos shape_owner_get :

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

El "prefijo" se refiere al primer argumento, y la parte después de get es lo que realmente obtendrá en ese prefijo. Por ejemplo, shape_owner_get_shape_index(owner_id, shape_id) es conceptualmente similar a get_shape_owner(owner_id)->get_shape_index(shape_id) , pero no hay ShapeOwner expuestos a la API de scripting, de ahí este "atajo".

Misma historia para los métodos surface_get :

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

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

O los métodos *node_get en 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">

Actualicé el OP con la mayoría de las sugerencias dadas hasta ahora.

Me gustaría si se cambia el nombre de VBoxContainer / HBoxContainer / GridContainer a simple VBox / HBox / Grid

No estoy convencido, en Godot intentamos darle un nombre explícito a todo, y por ejemplo Grid no me dice que es un Container. Para VBox y HBox se podría argumentar que las cajas son contenedores por definición, pero como tenemos BoxContainer que no es lo mismo que Container , creo que la verbosidad todavía está justificada.

LineEdit tiene un parámetro new_text en "text_changed" pero TextEdit no.

No creo que sea útil agregar new_text a TextEdit. En LineEdit, simplemente contiene todo el texto de LineEdit, no el texto que cambió, por lo que incluso diría que no debería estar allí en text_changed LineEdit. Sin embargo, es más común que desee utilizar el texto completo de un LineEdit en la entrada, que hacer cosas con el texto completo de un TextEdit de varias líneas cuando se presiona un nuevo carácter.

@ akien-mga

No verifiqué todos los usos, pero por lo que he visto, este estilo de denominación de métodos, aunque un poco incómodo, también sigue una convención específica.

Soy consciente del hecho de que es una convención de nomenclatura propia. Pero todavía no es algo que se use comúnmente fuera de Godot, y también es un poco confuso porque a veces se usa la misma palabra como BlendShape en métodos que siguen dos convenciones de nomenclatura diferentes.

Personalmente, me gustaría verlos a todos renombrados como GetPrefix* y SetPrefix* por coherencia, pero tal vez otras personas puedan tener diferentes opiniones al respecto.

Los métodos cambiaron en # 16757. El orden de los argumentos tiene más sentido, pero rompe la compatibilidad de API entre 3.0 y 3.1 (# 19648).

Subiré # 9128 nuevamente: translation en 3D vs position en 2D es una diferencia extraña.
Se elevó a edades anteriores a 3.0, pero se cerró después de que 3.0 se apagó debido a que ... 3.0 se eliminó.

OS.execute debe usar posix_spawn .

Otro podría cambiar el nombre de "margen" a "desplazamiento" para los nodos de control.
Dado que los márgenes son negativos en el lado derecho, esto engaña a la gente, especialmente cuando se compara con StyleBoxes.

@groud Creo que el desplazamiento es demasiado genérico, los márgenes solían ser la palabra correcta porque no estaban orientados negativamente en el lado derecho cuando se introdujeron por primera vez

@groud Creo que el desplazamiento es demasiado genérico, los márgenes eran un buen término (y no eran negativos cuando se introdujeron por primera vez)

Bueno, el margen es engañoso ahora que son negativos. La compensación es genérica, pero tiene más sentido. No creo que sea un problema que sean genéricos, ya que está en el contexto de los nodos de control.
De todos modos, estoy abierto a mejores sugerencias. Solo quería dejar esta idea aquí, ya que ya se ha sugerido dicho cambio de nombre de propiedad. Vea aquí por ejemplo.

El tamaño de las cajas / cubos se nombra de manera incoherente.
BoxShape para colisiones utiliza extensiones.
CubeMesh tiene una propiedad de tamaño con x, y y z, que son la mitad de las extensiones.
CSGBox tiene una propiedad Width, Height y Depth que se definen como el tamaño x, y, z en CubeMesh.

Además de la propiedad de tamaño, a veces se usa "Cubo" y otras veces se usa "Caja". Tendría sentido usar "Box" para todo, ya que x, yyz para CubeMesh se pueden configurar de forma independiente y, por lo tanto, también es un cuadro.

Dado que tenemos, por ejemplo, HTML5 y UWP como objetivos, que no son exactamente sistemas operativos, propongo cambiar el nombre del sistema operativo a Platform (PlatformWindows, PlatformUnix, ...).
También tiene sentido con la división OS / Display.

A partir de este # 20228, Label.clip_text ya no es necesario. Creo que es lo mismo para Button.clip_text.

Camera2D actualmente tiene dos propiedades diferentes, ambas llamadas offset (Desplazamiento regular y la que se divide en V y H) que son dos cosas totalmente diferentes, esto es realmente confuso.

Métodos

- Dictionary : erase_checked debe eliminarse (este método no está expuesto a los scripts).
- Dictionary : erase debe cambiarse para devolver bool para determinar si el par con la clave especificada se eliminó o no (consulte la implementación de erase_checked ).

20945

@neikeq Esto podría hacerse ahora la OMI, el cambio de Dictionary.erase 's valor de retorno de void a bool no debe romper cualquier proyecto.

@ akien-mga, pero rompería la compatibilidad de la API GDNative, ¿no es así?

@ akien-mga ¿No rompería eso la compatibilidad? ¿Se nos permite realizar cambios que potencialmente hagan que los scripts 3.1 no funcionen en versiones anteriores como 3.0?

@neikeq Sí, los scripts 3.1 ya son incompatibles con 3.0 ( class_name , toneladas de cambios de API con nuevos parámetros opcionales o propiedades / métodos nuevos, nuevas clases, etc.). Solo nos ocupamos de la compatibilidad hacia atrás, no hacia adelante.

¡Oh ya veo! Si ese es el caso, haré esos cambios ahora.

Si puedo agregar uno a la lista, los nodos de control LineEdit y TextEdit realmente se beneficiarían de tener API consistentes entre sí para que se puedan usar (en su mayoría) indistintamente. En este momento se siente como un desastre tratar de trabajar con ellos juntos, hasta el punto en que mirar un nodo me confunde con el otro.

@ eska014 Además, la opción scons ya es platform . Tiene sentido ser coherente.

La configuración del proyecto display/window/size/test_width y test_height debe cambiarse de nombre a window_width y window_height . También deberíamos considerar cambiar el nombre de las configuraciones width y height , tal vez render_width y render_height .

Las propiedades cercanas y lejanas de la cámara tienen nombres diferentes a los de sus establecedores / captadores (por ejemplo, set_znear / set_zfar). ¿Esto debería cambiarse?

znear y zfar son confusos. No tiene nada que ver con el eje Z en el espacio mundial. Se podría cambiar a clip_near y clip_far ya que controlan los planos de recorte, o simplemente near y far .

Sí, hay dos formas de resolver este problema.

Deberíamos deshacernos (o discutir seriamente) las extensiones de recursos binarios .. (RES_BASE_EXTENSION)

gdscript_function.cpp y gdscript_functions.cpp tienen nombres muy similares, los sigo confundiendo. ¿Vale la pena cambiarle el nombre? @vnen

Cambié https://github.com/godotengine/godot/pull/21425 para cambiar el nombre de "decimales" a "step_decimals" pero mantener "decimales" como alias. Suponiendo que se haya fusionado, podemos eliminar los "decimales" en la próxima ruptura de compatibilidad, si no, simplemente cambiando el nombre.

@mysticfall En mi opinión, es mejor no tener la palabra "get" en los nombres de los métodos cuando sea innecesario.

A veces desea que una propiedad pueda ser obtenida y configurada, pero controle el acceso. En C #, las propiedades le permiten hacer esto y controlar el acceso con solo leer y asignar como si fuera un campo, lo cual es bueno.

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

Sin embargo, en GDScript, las propiedades no son una cosa (?). También podríamos tener un nombre de método sin la palabra get. La mayoría de los métodos devuelven algo, por lo que es mejor tener un get-ness implícito que un set-ness: dado que GDScript tiene propiedades, sugiero usarlas con más frecuencia. Tenga en cuenta que no pude encontrar ninguna documentación sobre esto. Encontré documentación sobre cómo hacerlo dentro de GDScript con setget pero ¿qué hay de agregar a través de C ++?

En pocas palabras, estoy de acuerdo en que no es bueno tener "get" en lugares inconsistentes, pero la solución ideal en mi opinión no es GDScript , o podríamos eliminar "get" y mantener "set" .

@aaronfranke GDScript tiene propiedades de alguna manera, ya que las clases de motor pueden definir un getter y setter (o solo un getter) y exponer a GDScript como propiedades. Dicho esto, estoy en contra de eliminar get y set de los métodos porque 1) aclara el nombre y 2) hace una distinción entre getter y setter. Por ejemplo, Mesh.SurfaceFormat() suena como un método que "formatea la superficie", y no uno que "obtiene el formato". Además, la mayoría (si no todos) de ellos pueden ignorarse y usarse como propiedades de todos modos.

Ahora, no me importan mucho gdscript_function.cpp y gdscript_functions.cpp . Uno tiene la clase GDScriptFunction, el otro contiene la definición de las funciones GDScript, siempre tengo claro cuál es cuál (aunque estoy acostumbrado). Tampoco es un cambio importante, por lo que no es necesario que esté aquí.

Sí, GDScript tiene propiedades. Las propiedades de C # se generan a partir de ClassDB, que es de donde las obtiene GDScript.

Hay algunos métodos para RigidBody y sus clases relacionadas cuyos parámetros deben intercambiarse para mantener la coherencia:

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

Lista de clases y métodos

@TGRCdev Preferiría mucho cambiar apply_impulse a (fuerza, posición) en lugar de cambiar add_force a (posición, fuerza). La posición de la fuerza es un parámetro opcional, por lo que debe ir al final. Pero todas las fuerzas e impulsos deben tener un vector de fuerza.

@aaronfranke Punto justo. En ese caso, la lista de intercambios requeridos es:

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

@aaronfranke Estoy de acuerdo en que usar los prefijos Get- o Set- es una especie de 'javaismo' que es mejor evitar en C #.

Mi principal preocupación era el uso de 'prefijo de dominio' como en el caso de shape_owner_get_shape o node_get_input_count , por lo que si podemos volver a implementarlos como propiedades C # adecuadas sin Get- o Set- prefijos, sería aún mejor.

En una nota al margen, siempre pensé que era bastante extraño que las propiedades en la API C # de Godot tengan un conjunto coincidente de captadores y definidores, como por ejemplo, Node.Name y Node.GetName() / Node.SetName() .

Me parece bastante redundante, pero si hay alguna razón por la que mantenemos tal convención, supongo que obtendríamos tanto NodeInputCount como GetNodeInputCount() / SetNodeInputCount() todos modos, si estamos para cambiar el nombre de node_get_input_count como se sugiere.

Chicos, mantengan conversaciones sobre la API de C # y las convenciones habituales fuera de este tema, que se centra en la API de Godot. La API de Godot (C ++, C y GDScript) no se adaptará por el bien de C #, a menos que también sea una mejora para otros lenguajes.

@ akien-mga No creo que sea algo específico de C # discutir si node_get_input_count podría cambiarse de nombre a algo como get_node_input_count .

No, me refiero a que cualquier cosa específica de C # no debería estar en este número. Puede haber otro problema para las fallas de compatibilidad específicas de C # si es necesario (aunque ya hay varios de esos IINM).

¿Qué tal cambiar el nombre de Spatial a Node3D? Siempre me pareció extraño.

@KoBeWi El esquema de nombres que Godot usa actualmente es "Thing2D" para cosas 2D y simplemente "Thing" para cosas 3D, por lo que es bastante consistente con el resto del código 2D. Por supuesto, entonces lo lógico para llamar "Espacial" sería "Nodo" siguiendo el patrón de eliminar "2D", pero ese nombre ya está tomado por supuesto.

El esquema de nombres que Godot usa actualmente es "Thing2D" para cosas 2D y simplemente "Thing" para cosas 3D.

Entonces, ¿quizás cambiar todo 3D a "Thing3D"? Eso también se me pasó por la cabeza, pero suena exagerado.
De todos modos, solo sugerí. No es muy importante. Además, Spatial2D es incluso peor que Spatial.

Entonces, String.right () devuelve n caracteres correctos desde la posición dada. ¿No sería más intuitivo si devolviera solo n caracteres contando desde la derecha?

"abcdef".right(2)
En lugar de "cdef" devolvería "ef". En mi opinión sería mejor.

Yo esperaba lo mismo.

Python tiene el mismo método que a la mayoría de los usuarios les gusta para comparar GDScript con Python. Probablemente confundiría aún más cambiarlo.

@KoBeWi Estoy de acuerdo. No veo la diferencia entre la implementación actual y la subcadena.

Godot substr te obliga a indicar el tamaño de la cadena si quieres que todo esté a la derecha.

@Zylann La mayoría de las implementaciones permiten omitir el segundo parámetro. Consideraría esto un problema del lado de Godot. Además, prefiero que substr haga que el segundo parámetro sea opcional que un nuevo método con un nombre diferente.

@Zylann @neikeq Este es un resultado desafortunado de tener métodos que no se pueden sobrecargar, no hay forma de tener una especificación de longitud y ninguna especificación de longitud.

@aaronfranke Um, pero existen argumentos predeterminados. 0 o -1 podría contar como una longitud no especificada.

Necesita eliminar get_selected_id() de OptionButton actualmente siempre devuelve -1. Después de que https://github.com/godotengine/godot/pull/21837 se fusionó, get_selected_id() devolverá lo mismo que get_selected() .

Hay muchos métodos de interpolación que se vuelven verdaderos cada vez, probablemente deberían anularse.

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

El nodo Tree tiene una función get_selected() que parece devolver el TreeItem enfocado. Podría valer la pena cambiarle el nombre a algo como get_active() , ya que el enfoque y la selección son cosas diferentes.

load_from_globals() en InputMap debe ser load_from_project_settings() .

Agregaré una reacción: tada: a todas las sugerencias que se han integrado en el OP, para tener una mejor visión general.

global_rotate debe renombrar rotate_global y rotate_object_local debe renombrar rotate_local para mantener la coherencia y para que todos los métodos de rotación comiencen con "rotar".

global_rotate debería cambiarse a rotate_global y rotate_object_local debería cambiarse a rotate_local para mantener la coherencia y para que todos los métodos de rotación comiencen con "rotate".

Bueno, por otro lado, me gusta que las funciones relacionadas con el nivel global (como global_position, global_scale y global_transform) estén una al lado de la otra en las sugerencias de autocompletar. Ambas soluciones tienen sentido en mi humilde opinión.

Quizás tree_exiting podría cambiarse de nombre a tree_exited ya que parece que a estas alturas causa cierta confusión. Ver # 22840.

@groud Ya hay una señal tree_exited , ¿verdad?

@groud Ya hay una señal de tree_exited, ¿verdad?

Maldita sea, tienes razón. Supongo que la solicitud en # 22840 es válida entonces

MenuItems.MENU_MAX nunca se usa en LineEdit y TextEdit , ¿deberíamos eliminarlo?

Lo mismo para Tabs.ALIGN_MAX https://github.com/godotengine/godot/blob/master/scene/gui/tabs.cpp#L750

Los nodos Position3D y Position2D son un poco ambiguos. Sin leer la descripción, se podría suponer que son como Spatial y Node2D pero sin rotación ni escala. Probablemente deberían cambiarse el nombre a PositionHint y PositionHint2D o tal vez alguna otra palabra como Gizmo ya que es un artilugio solo en el editor o AxisMarker porque parece un pequeño marcador de eje.

Si se les cambiara el nombre a Gizmo , quizás se les podrían dar usos más generales.

Tenga en cuenta que el mismo nodo en el árbol de control es ReferenceRect , por lo que ReferenceAxis/2D podría funcionar.

Me encanta este problema ahora mismo. Puede que lo odie más tarde cuando la rotura realmente golpee;)

Algunas propuestas para la humilde clase Array :

• duplicate → ya sea copy o clone . No conozco ningún idioma que llame a este concepto "duplicación". copy es como se llama en Python y en C ++, por lo que sería la elección natural para Godot. clone es de Java y JavaScript y es quizás un poco más preciso.
• invert → reverse . La documentación incluso lo describe como "inverso", por lo que realmente no hay excusa.
• remove frente a erase es confuso. Sugerencia: remove_at y remove_value .

Los dos últimos también se aplican a todas las clases Pool*Array .

Nota: Duplicar → copiar / clonar también se aplica a los diccionarios.

Rect2 :

• clip → intersection

AABB tiene intersection método pero no clip , el recorte generalmente significa que cortamos algo, que no está implementado en ninguna de las clases por cierto. La documentación lo describe como:

Returns the intersection of this Rect2 and b.

También podría cambiar el nombre:

• intersects → overlaps
  para no confundirse con la operación intersection real:

Returns true if the Rect2 overlaps with another.

grabber_area -> slider_progress
slider -> slider_background

Algunas propuestas para la humilde clase Array:
duplicar → copiar o clonar.
...
Nota: Duplicar → copiar / clonar también se aplica a los diccionarios.

Y nodos y recursos (básicamente cualquier objeto de estructura de datos expuesto a un script, afaik).

Prefiero la palabra "Clonar", creo que es más claro lo que hace.

¡Mañana! @ akien-mga, ¿no podríamos cambiar el nombre de instance a new lugar de instantiate ? Tener la misma interfaz en PackedScene que Object s hace, por ejemplo, elimina algunos estándares para la creación de complementos, especialmente, pero probablemente de manera más general. @willnationsdev ¿qué piensas? Sé que te has encontrado con esto antes.

Lo siento si ya hay una charla sobre esto en alguna parte, no pude encontrarla hojeando.

grabber_area -> slider_progress
slider -> slider_background

o solo:
grabber_area -> progress
slider -> background ?

No sé si esto se ha discutido, pero AnimationPlayer tiene root_node con set_root & get_root , probablemente deberían ser set/get_root_node

¿Cambiar el nombre de CanvasItem.visible a CanvasItem.is_visible (y todos los demás lugares donde se usa)? para estar en línea con todas (o la mayoría, tal vez me perdí algunas) bool propiedades?

Cambiar el nombre de Tween.tween_completed a Tween.tween_finished ? ¿Como Animation.animation_finished ? Generalmente prefieres _finished sobre _completed ? Parece que started/finished tienen una relación más estrecha que started/completed - sesgado de los deportes de competición: start/finish - tal vez: D

Considere cambiar el nombre de la clase JavaScript a HTML5 o algo más.
Esta clase tiene un método único y no se extiende desde Script y no se usa en otras plataformas.

JavaScript se puede utilizar como nombre de clase de enlaces de lenguaje JavaScript en el futuro.

Como lo señaló @clayjohn , WORLD_MATRIX en los sombreadores CanvasItem es en realidad una matriz de vista de modelo. @reduz está de acuerdo en que en 4.0 deberíamos reemplazarlo por el modelo real y las matrices de vista, por ejemplo, CANVAS_MATRIX y ITEM_MATRIX .

Considere cambiar el nombre de Array.invert a Array.reverse . Invertir es más como al revés o el tipo de cosa "recíproca de". Ver https://docs.godotengine.org/en/latest/classes/class_color.html#class -color-method-inverted

Cambie la señal CanvasItem.visibility_changed() a CanvasItem.visibility_changed(visibility: bool) , es decir. envíe el estado de visibilidad con él. Dado que esto será suficiente, elimine la señal CanvasItem.hide()

Quitar Resource::notify_change_to_owners , Resource::{un}register_owner .
Solo los usan GridMap y CollisionShape, el resto del código usa la señal "changed" .

Rect2 : has_no_area debe renombrar has_area que evitaría que la lógica de doble negación verifique lo contrario en los condicionales. Lo mismo se aplica a AABB : has_no_surface .

Sobre la base de lo que dijo @lupoDharkael , Godot tiene varios lugares donde se usan dobles negativos. Errores como "Condition! Math :: is_nan (x) is false" son confusos.

parse_input_event (evento InputEvent)
Envía un InputEvent al juego. Se puede utilizar para activar artificialmente eventos de entrada desde el código.

el análisis es engañoso, el análisis sería recibir y procesar, pero la descripción indica el envío o activación de una entrada

Según # 24153 - CanvasLayer usa layer para describir en qué capa dibujar sus nodos. Pero casi todos los demás nodos 2D usan la terminología "Índice Z" ( z_index ) para describir (lo que al principio parece ser) lo mismo. Como sugirió @swarnimarun https://github.com/godotengine/godot/issues/24153#issuecomment -444950584 mejorando los nombres de las capas.

¿OS.has_feature () / Platform.has_feature () sería más sensato en algo como ProjectSettings, ya que no transmiten exclusivamente nada sobre el sistema operativo?

set_cell_item se puede renombrar a set_cell para unificar GridMap con TileMap?

set_cell_item se puede renombrar a set_cell para unificar GridMap con TileMap?

Ahora que lo pienso, ¿quizás también debería haber un set_cellv para GridMaps?

ARVRInterfaz:

• ar_is_anchor_detection_enabled -> anchor_detection o similar
• interface_is_initialized -> is_initialized o is_interface_initialized

AnimationPlayer:

• play_backwards se puede eliminar porque play tiene un bool opcional para eso.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D:

• Cambie el disabled bool por un enabled bool.

Bone2D:

• get_index_in_skeleton -> get_skeleton_index

• play_backwards se puede eliminar porque play tiene un bool opcional para eso.

Eso sería malo para la legibilidad, al menos mientras no se implemente # 6866. No es un problema en C # ya que admite parámetros con nombre.

ID en id_pressed( int ID ) y id_focused( int ID ) deben estar en minúsculas.

^
Ese cambio en realidad no rompería ninguna compatibilidad. Probablemente podría tener un problema separado.

^
Ese cambio en realidad no rompería ninguna compatibilidad. Probablemente podría tener un problema separado.

¡Eso es correcto!

28746 - Node.replace_by puede resultar confuso como nombre. Sin embargo, no estoy seguro de cuál podría ser exactamente un nombre mejor.

@ bojidar-bg tal vez replace_self o swap_by ? pero creo que la única forma de evitar cualquier tipo de confusión es documentarlo adecuadamente.

Si tengo un Node2D con un script adjunto que contiene class_name MyNode2D , el método get_class() devuelve Node2D lugar de MyNode2D . Esto puede ser intencional, pero es confuso y engañoso.

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

@aaronfranke get_native_class() ¿quizás? Entonces podría obtener el nombre del script de get_script().global_name si tiene uno.

make_convex_from_brothers()
Supongo que "hermanos" debería cambiarse por "hermanos", ya que esa es la palabra que se usa en todas partes para los nodos hermanos.

ARVRPositionalTracker: get_type() -> get_tracker_type()

• get_tracker_type() es más explícito - get_type() podría confundirse con get_class()

• GetType() ya se usa para otra cosa en C # como se indica aquí .

Devuelve TrackerType , y también hay get_hand() que devuelve TrackerHand , por lo que también podría cambiarse a get_tracker_hand() para mantener la coherencia si se desea.

ARVRPositionalTracker enumeración TrackerHand: TRACKER_LEFT_HAND -> TRACKER_HAND_LEFT (y mano derecha). Alternativamente, TRACKER_HAND_UNKNOWN -> TRACKER_UNKNOWN_HAND , siempre que sea consistente.

Node.NOTIFICATION_TRANSLATION_CHANGED probablemente debería convertirse en NOTIFICATION_LOCALE_CHANGED , ya que "traducción" se usa en los nodos espaciales para significar "posición" y no "idioma".

set_as_toplevel() podría cambiarse de nombre a set_as_top_level() , pero se debe analizar su comportamiento.

TouchScreenButton debe buscarse en 4.0, ya que este cambio podría romperse: https://github.com/godotengine/godot/issues/28814

CanvasItem método:

RID get_canvas_item () const
Devuelve el elemento de lienzo RID utilizado por VisualServer para este elemento.

Entonces debería cambiarse el nombre a get_rid() .

get_canvas_item() es confuso porque ya estoy en el nodo CanvasItem . También asegura la consistencia ya que otras clases ya tienen un método get_rid() similar: CollisionObject , Resource .

¿Debe cambiarse Label a TextLabel ? Varias veces he querido dejar un objeto de texto y olvidé cómo se llamaba, así que busqué "texto" y solo aparece RichTextLabel . TextLabel sería más consistente con RichTextLabel ya que sigue siendo texto pero sin los ricos.

Como referencia, Unity tiene Text y TextMesh , y personalmente me refiero a él como texto en lugar de etiqueta.

También me he estado preguntando acerca de que Tree y GraphNode sean renombrados TreeView y GraphEditNode .
Por Tree , la razón es que es un nombre demasiado amplio para un nodo de GUI global IMO, todos los demás marcos de GUI que conozco usan TreeView .
Por GraphNode , es porque recientemente trabajé en algunos prototipos que involucraban estructuras gráficas reales, y no pude usar Node ni GraphNode cual fue bastante molesto.

@Zylann dado que los nodos Graph son visuales / controles para gráficos (no árboles), GraphContainer puede ser mejor. No estoy seguro acerca de GraphNode.

¿Deberíamos tener lerpf / lerpv / lerpc lugar de Color/Vector2/3.linear_interpolate ? Al menos cambie el nombre de Color/Vector2/3.linear_interpolate a Color/Vector2/3.lerp

Como se menciona en # 29598 http_escape / http_unescape a uri_encode / uri_decode

¿Deberíamos tener lerpf & lerpv lugar de Vector2/3.linear_interpolate ? Al menos cambie el nombre de Vector2/3.linear_interpolate a Vector2/3.lerp

Acortarlo a vector.lerp () suena bien. Al menos a partir de https://github.com/godotengine/godot/pull/16106, el uso de lerp() en el script tiene un interruptor para admitir vectores y colores.

Vector2.angle_to_point() debería cambiarse de nombre. Su nombre no coincide con la descripción actual. No estoy seguro de cuál sería un buen nombre y si vale la pena mantener esta función.

Emisión original: # 16307

@ razcore-art Ya un PR abierto sobre este https://github.com/godotengine/godot/pull/20371 , y mantiene la compatibilidad con versiones anteriores (creo).

EDITAR: Ya no lo hace.

Area realmente debería ser Volume , ya que es 3D. Y Area2D debería ser Area . Un área es 2D por naturaleza.

GridMap quizás debería ser CubeMap . No estoy seguro en este caso, solo que la "cuadrícula" me suena como algo en 2D.

CheckButton control debe ser SwitchButton o algo así. Es confuso porque también hay Checkbox . O tal vez debería eliminarse por completo. De todos modos, cumple la misma función que la casilla de verificación, por lo que puedo decir.

Estoy de acuerdo con: CheckButton, y los demás son solo cosméticos.

O tal vez debería eliminarse por completo. De todos modos, cumple la misma función que la casilla de verificación, por lo que puedo decir.

En cuanto a UX, CheckBox y CheckButton son cosas diferentes, a pesar de tener la misma funcionalidad.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@ Rodeo-McCabe Area se llama así por coherencia con la contraparte 2D, también una de las definiciones de area es a particular extent of space or surface .
Los mapas de cubos son imágenes en 3D, la corrección de la sintaxis debe estar en el contexto o simplemente agregaría confusión.

grabber_area -> slider_progress
slider -> slider_background

o solo:
grabber_area -> progress
slider -> background ?

Quizás:
grabber_area -> progress_area o progressed_area
slider -> progress_background ?

Los mapas de cubos son imágenes en 3D, la corrección de la sintaxis debe estar en el contexto o simplemente agregaría confusión.

@ eon-s Bastante justo, no sabía eso.

El área se llama así por coherencia con la contraparte 2D

El problema es que la contraparte 2D también es inconsistente. En matemáticas, un área es longitud * altura, simplemente no hay una tercera dimensión. Entonces no tiene sentido decir Area2D, porque debería ser 2D en virtud de ser un área. Otra definición más matemática de "área" es:

la superficie incluida dentro de un conjunto de líneas, específicamente: el número de unidades cuadradas iguales en medida a la superficie

De manera similar, un espacio 3D en matemáticas se llama "volumen". Al principio estaba confundido cuando descubrí que Area era en realidad un nodo 3D, en cambio, las áreas se llamaban extrañamente "Area2D". Dado que este es un motor de juego, las definiciones matemáticas son las que debemos tomar.

Si bien entiendo el razonamiento, no sé si habría algún beneficio en particular al cambiar el nombre, especialmente a personas nuevas. Estoy de acuerdo en que "Volumen" podría ser un término más apropiado para esto, pero creo que tener "Volumen" para 3D y "Área" para 2D puede resultar un poco confuso. Después de todo, muchos nodos que tienen variantes 2D y 3D serán nombrados "

Creo que el esquema de nomenclatura que está allí en primer lugar (por mucho que haya algunos nodos que solo se adhieren al esquema en su mayoría ) significa que no deberíamos tener una excepción a la regla, incluso cuando otro término para una variante haría más sentido, ya que de lo contrario es probable que confunda a los usuarios.

Sin embargo, si puedo ... ¿quizás cambiar el nombre de Area2D a Area , y Area a Area3D ?

Editar: parece que el texto rodeado por <> no aparece a menos que escape el <>

@ Rodeo-McCabe Tengo la impresión de que la intención del nombre del nodo es expresar cosas en lenguaje humano y no matemático. Entonces, el "área" no está destinada a ser geométrica, sino a un lugar para estar, como dentro de un nivel o escenario. IE - Área 1.

El nodo en sí no tiene directamente ninguna geometría o es en sí mismo una geometría, por lo que otros como yo se preguntan dónde está su área / volumen al crearlo, y luego por qué tendría que adjuntar áreas y volúmenes (formas) a un área y ¿volumen?

Si tuviera que cambiar el nombre para evitar confundirlo con el área geométrica, los sinónimos probablemente serían el camino a seguir.

Podrían llamarse:

• Región2D / 3D
• Espacio2D / 3D
• Zone2D / 3D
• Field2D / 3D
• etc.

Por cierto, aparte de que este rastreador es solo para métodos, propiedades y señales (no para nodos), @reduz mencionó recientemente que hay intenciones de minimizar la ruptura de compatibilidad en 4.0, por lo que probablemente esta enorme lista necesite una revisión de los desarrolladores principales antes de continuar agregando cosas ad eternum ...

Parece que el objetivo es dejar las cosas como están ahora, por lo que cosas como esta podrían retroceder hasta la próxima versión principal después de la 4.0.

Deje este problema para los colaboradores principales, no es un lugar para hacer sugerencias de grandes cambios de nombre por todas partes, el objetivo es corregir las inconsistencias reales que hacen que la API sea engorrosa.

Los cambios descritos en el OP no son una gran ruptura de compatibilidad y la mayoría se hará para 4.0, a lo que @reduz se refirió es ruptura de compatibilidad del tipo "su proyecto ya no se puede abrir" entre 2.1 y 3.0 (mucho más cambiado que el cambio de nombre de las cosas en ese entonces, como la reescritura completa de los sistemas de audio y partículas, el cambio del sistema de importación, etc.).

Habrá alguna rotura en la compatibilidad 4.0, de lo contrario no sería llamado 4.0. Será razonable y la migración será fácil, probablemente con un convertidor para garantizar que las propiedades, métodos y señales renombrados se conviertan correctamente si se utilizan en escenas y scripts. En cualquier caso, no es el lugar para discutirlo :)

Control 's _set_anchor() también debería eliminar el principio "_".

PopupMenu's tiene index_pressed(index) y id_pressed(id) que funcionan bien, pero también id_focused que en realidad se emite con el índice en lugar de la identificación del elemento.

No hay problema para esto todavía, pero después de sugerirlo a Akien hoy, vale la pena ponerlo en la lista.

Refactorice ARVRServer para que se llame XRServer. Cuando lo diseñamos, el término XR para indicar que tanto la realidad virtual como la realidad aumentada aún no se usaban ampliamente. Y no, no voy por MRServer;)

¿Debería RayCast tener una propiedad "Deshabilitado" en lugar de "Habilitado"? CollisionShape tiene un "Deshabilitado" que es false de forma predeterminada (lo que significa que están habilitados de forma predeterminada). Por el contrario, la propiedad "Habilitada" de RayCast es false de forma predeterminada, lo que las desactiva de forma predeterminada.

O, para usar la forma positiva (que creo que es menos confusa en general), ¿CollisionShape debe tener una propiedad "Enabled" ( true por defecto) en lugar de "Disabled"?

@Calinou No sé si eso requeriría un problema por separado, pero si necesitamos ser consistentes, realmente preferiría que esos valores booleanos sean Enabled siempre. Establecer un booleano en true para deshabilitar algo me confundía a menudo.

@Calinou Estoy de acuerdo con @Zylann Los dobles negativos son confusos y deben evitarse siempre que sea posible. En su lugar, deberíamos cambiar los bools "Disabled" por "Enabled". Está bien si el valor predeterminado de algo es "verdadero". Tuve esta discusión en # 17212 y # 21822.

La propiedad speed del mouse y los eventos de entrada táctil deben cambiarse de nombre a velocity ya que es un Vector2.

InputMap : get_action_list( String action ) el nombre de la función no dice mucho sobre lo que hace.
Dado que devuelve los EventInputs asociados a una acción determinada, podría ser get_action_events(String action)

También podría ayudar a evitar posibles confusiones, ya que InputMap tiene otra función llamada get_actions( ) y ambos nombres podrían significar lo mismo fuera de contexto.

Relacionado tangencialmente con # 30736, deberíamos cambiar el nombre de los dos motores de física Godot a algo como "GodotPhysics2D" y "GodotPhysics3D", ya que decir que algo está roto con "GodotPhysics" puede significar dos cosas muy diferentes.

¿Qué hay de cambiar el nombre de Object._init() a Object._new() ?

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

new - _init

Supongo que _init realidad siguió a __init__ Python, mientras que new es un método de la clase, no la instancia.

¿Es algo como String : empty() -> is_empty() un buen ajuste para este hilo? Siempre creo que es una función borrar una cadena al principio.

@vortexofdoom si habla de inconsistencias en el nombre del método y / o cómo deben nombrarse, entonces sí.

Podría agregar que String y NodePath tienen métodos empty y is_empty respectivamente que hacen lo mismo. El resto de los tipos integrados principales parecen preferir empty name, por lo que tal vez is_empty pueda renombrar en NodePath para que esto sea coherente en todos los tipos integrados, pero esto Creo que podría implicar potencialmente alguna ruptura de compatibilidad grave.

Siempre creo que es una función borrar una cadena al principio.

La mayoría de los métodos usan clear name en Godot para eso.

@Xrayez ,

La mayoría de los métodos usan un nombre claro en Godot para eso.

Lo sé, solo refiriéndome al hecho de que empty es un verbo además de un adjetivo, y agregar is_ deja en claro cuál es el significado.

Yo estaría a favor de usar is_empty en todos los componentes integrados para ese bool.

En Godot 3.0 y 3.1, teníamos métodos Set en C #. Sin embargo, estos en realidad no agregaron ninguna funcionalidad real en comparación con solo usar un constructor y una asignación, pero permitieron que el código fallara silenciosamente, por lo que han quedado obsoletos. En su mayoría fueron agregados por mí para tratar de ser consistentes, ya que ya existía un método para Quat, que provenía del núcleo con métodos establecidos. Para obtener más información, consulte # 30744

GDScript tiene set_euler y set_axis_angle , pero también hay constructores para hacer lo mismo ( q.set_axis_angle(myvec3, myval) se puede reemplazar con q = Quat(myvec3, myval) . Core también tiene estos métodos para Basis, pero no están expuestos a GDScript.

La pregunta es, entonces, ¿qué se debe hacer al respecto? ¿Deberían dejar de utilizarse los métodos de conjunto de Quat en favor de los constructores y ser coherentes con C #, o vale la pena mantenerlos explícitos sobre la operación que se está realizando? Si es lo último, ¿deberían exponerse también los métodos básicos?

@aaronfranke Siempre me pareció extraño que esos constructores tuvieran métodos dedicados cuando básicamente nada más lo hace, así que estoy a favor de tomar la ruta anterior si es posible.

@aaronfranke Este problema se trata de cambiar el nombre de las cosas en la API, no de la funcionalidad del motor o errores.

Geometry point_is_inside_triangle() a is_point_in_triangle() , para que coincida con los otros métodos que también devuelven bool s en la misma clase.

TreeItem.get_children() debería cambiarse get_first_child() nombre get_next() .

Cuando trabajaba en # 31976, noté que el valor del atlas de sombras debe ser una potencia de 2 (tanto para sombras direccionales como para sombras omnidireccionales / puntuales). Sin embargo, los métodos aceptan cualquier valor entero; si no es una potencia de 2, el método la redondeará a la potencia más cercana de 2. Probablemente deberíamos hacer que acepte una enumeración de valores, para que pueda presentarse de una manera fácil de usar en la Configuración del proyecto.

Del mismo modo, el nivel de filtrado anisotrópico debe ser una enumeración (2 ×, 4 ×, 8 ×, 16 ×), ya que solo los valores de potencia de dos tienen sentido aquí.

VisualServer de instance_create2() debe cambiarse para describir realmente lo que hace de manera diferente a instance_create() .

Para traducciones relativas a objetos, Spatial tiene translate_object_local que toma Vector3 , y Node2D tiene move_local_x y move_local_y , que llevan flotadores. Tanto Spatial como Node2D deben tener métodos que tomen Vector3 y Vector2 respectivamente, y translate_local o local_translate ser nombres más simples que translate_object_local .

@leonkrause En lugar de render_width y render_height , tendría más sentido llamarlo viewport_width y viewport_height , o quizás canvas_width y canvas_height , ya que es la resolución de referencia utilizada para la ventana gráfica del lienzo y en realidad no afecta al renderizado.

@ akien-mga, considere agregar los métodos de navegación del árbol a su lista. Tienen nombres muy confusos y no están bien documentados.

Cuando los encontré por primera vez, pensé que get_child () y get_next (), get_prev () operaban un iterador de manera muy similar a como funciona Directory. Tuve que hacer mis propias pruebas para descubrir que todo lo que hacen es producir el mismo puntero cada vez que se les llama.

get_children () debe cambiarse de nombre a get_first_child ().

get_next () y get_prev () deben cambiarse de nombre a get_next_sibling () y get_prev_sibling ()

¿Qué hay de cambiar el nombre de Engine.iterations_per_second a Engine.physics_fps para mantener la coherencia con la configuración del proyecto?

is_processing :

Devuelve verdadero si el procesamiento está habilitado.

can_process :

Devuelve verdadero si el nodo puede procesar mientras el árbol de escenas está en pausa

Sería mejor cambiar el nombre de can_process a algo como can_process_paused para evitar confusiones con el método is_processing .

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

Creo que este método debería cambiarse de nombre.

@dalexeev ¿

@Calinou Este método en realidad no imprime nada en la pantalla; devuelve una cadena. El primer pensamiento es que JSON.print funciona igual que Node.print_tree o OS.print_all_resources o como todos los demás métodos print* .

¿A qué debería renombrarse? No estoy seguro. JavaScript usa JSON.stringify para esto. PHP tiene una función json_encode . Directamente en GDScript hay una función similar: to_json .

UPD. JSON.serialize también es posible, pero por el número de caracteres es lo mismo que JSON.stringify . :sonrisa:

Sugeriría contra la palabra "serializar" ya que se usa generalmente para serialización binaria, y tal salida necesitaría tener más pasos para entrar en esa forma.

Dado que esta clase solo tiene dos métodos para ir entre los tipos JSON y Variant, sugeriría contra los métodos que contienen la palabra json ya que no tiene sentido.

Ahora, para las cosas que serían un buen nombre, el método actual parse no tiene realmente una palabra opuesta clara ( ver aquí ). Quizás uno de estos: encode , create , compose , generate ? Si se usa encode , tendría sentido cambiar el nombre del otro método a decode .

He visto que format y write se usan como un inverso de parse . Sin embargo, stringify tiene la ventaja de ser más conocido entre los desarrolladores debido a su uso en JavaScript.

He visto que format y write se usan como un inverso de parse . Sin embargo, stringify tiene la ventaja de ser más conocido entre los desarrolladores debido a su uso en JavaScript.

str2var es VariantParser y var2str es VariantWriter internamente (vea # 33241 por ejemplo, incluso he usado el mismo término para describirlo).

Así que estoy a favor de write , la consistencia gana. 😛

@Xrayez ¿ Cambiar print a write ? ¿De Python a Pascal? :risa:

Como se sugiere en https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552, podría tener sentido cambiar el nombre de todo lo relacionado con clear_color a background_color (incluido el configuración del proyecto).

Esperaría que 4.0 traiga una gran ola de gente nueva a Godot debido a un mejor rendimiento, mejoras en las sondas GI, publicidad generalizada, etc.

Si esos cambios se realizan con 4.0, estas personas tendrán un aterrizaje forzoso ya que casi ningún tutorial existente (además del tutorial oficial del "primer juego") ya funcionará para ellos.

Si esos cambios se realizan después de 4.0, digamos en 4.1, será un viaje extremadamente accidentado para esas personas. Acaban de aprender los conceptos básicos de un nuevo motor, que ahora tienen que volver a aprender. Los comienzos son difíciles, tener que pasar por esto dos veces y poco después de otro puede ser lo suficientemente frustrante como para darse por vencido por completo.

Por lo tanto, ¿no tendría sentido tener una versión "3.3" o "3.9" antes de la versión 4.0 que tiene todos esos cambios de API que rompen la compatibilidad, pero les da a los creadores de tutoriales tiempo suficiente para crear algunos tutoriales antes de la afluencia masiva esperada de nuevos usuarios?

No estoy seguro de si este es el lugar correcto o no, pero dado que esta podría ser una posible solución parcial a los problemas de cambio de nombre, la presentaré aquí.
¿Por qué no hacer todos los cambios de nombre necesarios y luego agregar un nuevo idioma a las traducciones llamado GodotOldNames / GodotPre4.0 que tiene todos los nombres antiguos para todos los cambios?
De esta manera, en caso de que alguien no encuentre los nombres antiguos presentes en los tutoriales antiguos, simplemente puede cambiar el idioma a GodotPre4.0. Esto también facilitaría el cambio a nuevos nombres.
Esto no resuelve todo el problema, pero podría funcionar junto con # 4397.

@Anutrix Esto agregaría mucha complejidad (¿qué pasa con los idiomas que no son el inglés?). Además, no todas las cadenas que se muestran en el editor son localizables en primer lugar.

Física " Capa ", Renderizar " Capa "

Recuerdo haber pasado exactamente por la misma confusión que esta pobre persona durante mis primeras semanas de aprendizaje de Godot.

La "Capa" de Física, la "Capa" de Renderizado pueden tener sentido para alguien que viene del Diseño Orientado a Objetos , pero para cualquier otra persona es muy confuso. El término "capas" se utiliza para describir múltiples capas de pintura, o capas de tela en una tela, capas de piel sobre una cebolla (u ogro), capas de sedimento en la superficie del planeta, ...
Las capas (en plural, opuesto a una sola capa), parecen implicar estar apiladas una encima de la otra en todos esos casos.

Para muchas personas, las "capas", especialmente cuando se trabaja con gráficos o animaciones 2D, implica trabajar con un primer plano, un fondo y capas intermedias o superiores. Mucha gente piensa en las capas como películas de celoloide sobre un fondo, cuando en realidad Godot, como muchos otros motores de juegos, utiliza varias formas de "ordenar" para realizar esta tarea.

El hecho de que llamemos "Capas" a la similitud abstracta de que los objetos de Física o los objetos de Render pueden compartir, mientras que, al mismo tiempo, estas similitudes abstractas no tienen nada que ver con la apariencia de apilamiento de las capas visuales (eso es "ordenar"), es lo que hace que esto tan confuso para algunos.

Cuando comprendí el uso real y el significado de "Capa" de Física, "Capa" de Render, inmediatamente me pregunté por qué no son Grupo de Física, Grupo de Render, y para ser honesto, todavía no lo sé. Ciertamente, no tienen ninguna relación apilable en la parte superior entre sí, lo que significa que su orden o relación entre ellos es completamente irrelevante. Nombrarlos capa, en mi humilde opinión no archiva nada más que confundir a las personas, "grupo", "afectado por el grupo" para las máscaras, o tal vez algún otro término en el que no puedo pensar en este momento sería más exacto.

Método AnimationPlayer
.stop (falso) debería llamarse .pause (verdadero)
porque eso es lo que hace.

Proyecto> Configuración del proyecto> Visualización> Ventana> Estirar> Modo:

El modo de estiramiento "2D" debe llamarse "visualización" del modo de estiramiento o "propósito general"
porque es confuso llamarlo 2D cuando funciona igual de bien para los casos de uso 3D, pero no muy bien para todos los casos de uso 2D (como los proyectos de pixelart, mientras que casi la mitad de los proyectos de Godot 2D parecen ser pixelart).
"display" también sería más descriptivo de lo que realmente hace: renderizar todos los gráficos, ya sean gráficos 2D, objetos 3D, mallas 2D, Line2D y polígonos a la resolución de pantalla.
Más sobre eso aquí .

loop, repeat, oneshot, de animationplayer, timer y nodos similares, podría aclararse.

bucle, repetir y no ser un one-shot, son todas las mismas cosas.

Creo que
is_a_parent_of()
debería ser renombrado a
is_parent_of()

@KoBeWi ver discusión en # 19801.

Creo que
es_un_padre_de ()
debería ser renombrado a
es_padre_de ()

No lo creo, is_parent_of () sugiere que solo tiene en cuenta el primer padre, mientras que la función comprueba todos los padres de forma recursiva.

@groud En ese caso, debería llamarse is_ancestor_of() . Si también hay una función correspondiente al revés, entonces debería llamarse is_descendant_of() .

@groud En ese caso, debería llamarse is_ancestor_of (). Si también hay una función correspondiente al revés, entonces debería llamarse is_descendant_of ().

Sí, pero pensándolo bien, no hay mucha necesidad de tener ambas funciones, ya que la diferencia solo sería una cuestión de cambiar el objeto de "llamada" y el argumento de la función. Quizás simplemente podríamos reemplazar la función por algo como is_descendant_of() y listo.

Es posible que deseemos cambiar el nombre de push_error() y push_warning() a print_error() y print_warning() respectivamente. Esto los haría más visibles gracias a la función de autocompletar: mild_smiling_face:

@Calinou print_error() podría confundirse con printerr()

Por favor, considere cambiar el nombre del método TreeItem.get_children() , ya que el nombre implica una colección de hijos como valor de retorno, cuando en la práctica es el primer hijo que se devuelve y luego debe iterar sobre el resto de ellos usando get_next() (como se describe en # 19796).

Citando a @Zylann de # 31404:

[Cambiar el nombre de rpc() / rset() a] remote_call() / remote_set() ?
Esos métodos también tienen nombres realmente cortos, no estoy seguro de si un alias es suficiente. Realmente tienes que jugar mucho en el modo multijugador con toneladas de estas llamadas por script para justificar los identificadores de 3 caracteres (que estoy seguro de que la mayoría de los juegos no lo hacen).

Editar (2020-01-03): pensándolo bien, call_remote() y set_remote() podrían tener más sentido ya que ya tenemos call_deferred() y set_deferred() .

Editar: No te preocupes por el cierre / reapertura a continuación, hice clic demasiado rápido.

Siguientes métodos

OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

debe moverse de la clase OS a la clase Input para mantener la coherencia con los métodos:

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 deberían tener sus señales tab_close y tab_hover editadas.

• LightOccluder2D light_mask -> occluder_light_mask
• CPUParticles Flags enumeración -> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker get_name -> get_tracker_name
• PathFollow2D rotate -> algo más
• ArrayMesh ArrayType enum -> eliminar esto
• Mesh BlendShapeMode enum -> dar a ArrayMesh

Explicaciones en https://github.com/godotengine/godot/issues/15763#issuecomment -568908661

Las señales meta_hover_started y meta_hover_ended RichTextLabel deben cambiarse de nombre para que coincidan con la mayoría de las otras convenciones de nomenclatura similares: meta_hover_entered y meta_hover_exited . Esto no solo hace que imite más de cerca al resto de la API de Godot, sino que el esquema de nomenclatura actual, debido a la clasificación alfabética, hace que su orden se invierta. Esto desorienta un poco cuando lee los documentos ya que, claramente, el flujo cronológico de las operaciones es entrar primero y luego salir. Simplemente mejora la legibilidad y la coherencia para cambiarlo.

Noté que no hay propiedad Texture.size. Necesitaba llamar al getter Texture.get_size () en su lugar.

Le pregunté en Discord si esto era intencionado o no. Una sugerencia fue publicar aquí preguntando si esto debe convertirse en una propiedad, la otra sugerencia fue que, dado que no hay un 'configurador' para esto, el uso de get_size () es el comportamiento esperado actualmente.

@jmbjr ¿Tenemos propiedades de solo lectura expuestas como propiedades (en lugar de solo métodos getter)? Recuerdo haber visto un controlador de errores incorporado al intentar establecer una propiedad de solo lectura. Simplemente no estoy seguro de si está expuesto a GDScript en primer lugar.

Sí, creo que si fuera a comenzar a admitir propiedades expuestas de solo lectura, necesitaría una marca USAGE para ello y también agregar el código del compilador / analizador GDScript que lo admita.

SoftBody tiene un areaAngular_stiffness que debería ser area_angular_stiffness (lo mismo para todos los métodos relacionados).

Input.joy_connection_changed (el método) parece que no debería estar expuesto a la API de scripting, es llamado internamente por el código de manejo del joystick de cada plataforma.

@ akien-mga Cuando vi ese método por primera vez, muy pronto después de descubrir a Godot, tuve pensamientos similares, luego recordé cómo Kojima ha construido una jugabilidad legendaria en MetalGearSolid en torno a un método que debe haber sido muy similar a este y pensé: " Godot incluso me da los medios para marcar la cuarta pared como Kojima con una sola línea de código, ¡qué asombroso es eso! "

Label y RichTextLabel tienen propiedades de tema inconsistentes:

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

Además, debido a los diferentes valores predeterminados, la misma fuente tiene diferentes alturas en Label y RichTextLabel .

La señal request_completion TextEdit podría cambiarse de nombre a completion_requested para usar el tiempo pasado. La versión actual suena algo imperativa, contrariamente a la naturaleza de devolución de llamada de las señales.

otra inconsistencia con las señales físicas del cuerpo

Zona:

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)

¿Supongo que area_shape en estos dos últimos debería ser self_shape? o ...

Cuerpo rígido:

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)

aquí se llama local_shape ...

@FrederickDesimpel Hasta donde yo sé, los argumentos se pueden renombrar sin romper la compatibilidad. No dude en abrir una solicitud de extracción para esto: mild_smiling_face:

En variante:

Real -> Flotar
Nil -> ¿Nulo?

Personalmente, me gusta el nombre "real", ya que el término "float" se usa a menudo para flotantes de 32 bits específicamente, pero el real de Variant es un doble, y la mayoría del motor usa real_t que puede ser cualquiera.

PD : Ya hicimos ese cambio de nombre al revés en 2017.

¿Consideramos cambiar el nombre de estos:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial ya fue renombrado a StandardMaterial3D en master.

¿Deben cambiarse los valores limit_ en Camera2D a Rect2i ? Ahora mismo son solo cuatro ints.

EDITAR: El margen de arrastre también se puede cambiar, a Rect2 .

String::begins_with a String::starts_with .

Como en los lenguajes de programación serios (Java, Python, etc.).

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

Aunque falta la palabra "sólo", event.is_action _... () corresponde a Input.is_action_just ... ().

Probablemente deberíamos intercambiar los dos primeros argumentos de Node.add_child_below_node() para que el primer argumento sea el mismo que Node.add_child() . Ver # 19642.

_atelofobia semántica hablando ... _

¿Debería Node2D.draw_circle ser Node2D.draw_disk ya que dibuja un disco y no un círculo?
Node2D.draw_circle aún podría existir como un atajo para draw_arc desde 0 a TAU .

@Goutte En inglés, "círculo" puede referirse a un círculo hueco o un círculo relleno. Creo que el nombre actual es más visible, por lo que no lo cambiaría.

En inglés, "círculo" puede referirse a un círculo hueco o un círculo relleno.

No puedo encontrar nada que apoye esto . ¿Tiene alguna fuente para esta afirmación o es un presentimiento?

Sobre la capacidad de descubrimiento, todavía podemos tener draw_circle , simplemente dibujaría un círculo y no un disco.

No puedo encontrar nada que apoye esto . ¿Tiene alguna fuente para esta afirmación o es un presentimiento?

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

1 b: un plano cerrado (ver entrada de plano 6 sentido 2b) curva cada punto de la cual es equidistante (ver sentido equidistante 1) desde un punto fijo dentro de la curva
1 c: la superficie plana delimitada por dicha curva

(1 b) es un círculo matemático (perímetro), (1 c) es un disco matemático (superficie).

En términos de API, IMO es más fácil de usar tener draw_rect(bool filled) y draw_circle(bool filled) que draw_rect() , draw_filled_rect() , draw_circle() y draw_disk() (¿o cuál sería el nombre matemático de un rectángulo relleno?).

Editar: En realidad, draw_circle() aún no tiene un argumento filled . Creo que deberíamos agregar uno, para que pueda usarse para dibujar tanto círculos (perímetro) como discos (círculo relleno).

Genial gracias. La mayoría de mis alumnos son franceses y todos estaban confundidos por esto, y yo también, y culparon a Godot y no podía dejarlos, por supuesto.

¿Cuál sería el nombre matemático de un rectángulo relleno?

Esa es una muy buena pregunta; todo lo que puedo encontrar es "área del rectángulo" o "interior del rectángulo", y ninguno es adecuado. La wiki incluso afirma que la mayoría de las personas abusan del término _polygon_ para significar el _interior de un polígono_, sin proporcionar otra palabra para describirlo.

Supongo que un argumento filled podría ayudar a aliviar la ambigüedad, pero será complicado decidir dónde ponerlo en la lista de argumentos.

@Goutte, pero será una molestia decidir dónde ponerlo en la lista de argumentos.

Dado que es un argumento opcional (tiene un valor predeterminado), y también por coherencia con draw_rect , debería ir al final.

Hay casos en los que los nodos de control se denominan nodos modales. https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal Principalmente en relación con la función Viewport.get_modal_stack_top ()

EditorInterface métodos get_selected_path y get_current_path son confusos en nombre y función. También carecen de documentación.

Estos métodos son solo una capa delgada sobre los métodos del mismo nombre de 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;
}

Ambos deben adaptarse ya sea "seleccionado" o "actual" (o algo más, pero para ambos) siendo uno get_*_path y el otro get_*_dir .

@Goutte ¿No es Solid Rectangle una alternativa al rectángulo relleno?

¿Se actualizará el OP con sugerencias publicadas después de junio de 2019? Entiendo que esto es mucho trabajo, pero este tipo de rastreador también es perfecto para que los colaboradores lo aborden juntos. ¿Y supongo que ya es el momento en que podemos ponernos manos a la obra para cambiar el nombre de más cosas?

Actualizar el OP también significaría que el equipo acepta la sugerencia publicada como valiosa.

@Anutrix "lleno" es una mejor palabra que "sólido", porque "sólido" puede significar "no líquido ni gas".

@pycbouh También sería una buena idea vincular los RP para cada tema, si lo hubiera. El OP ya hace esto, pero no para los comentarios a continuación.

No sé si se planteó , pero no me di cuenta de la frecuencia con la que me detengo para echar un vistazo al documento de este:

• Array.remove => remove_at (como C #) para eliminar por índice
• Array.erase => remove_value , o solo remove (como C #) para eliminar por valor

(o variantes de eso con erase )

Porque en este momento, erase y remove significan lo mismo para mí, excepto que uno es por índice, el otro por valor, sigo olvidando cuál es cuál.

Ya se crió, mi mal. No me di cuenta, Github está doblando el hilo, mi búsqueda Ctrl + F lo perdió xD
Todavía no en el OP

@Zylann Aquí tienes: https://github.com/godotengine/godot/issues/16863#issuecomment -441376010

En segundo lugar a Zylann, sigo olvidando que eliminar es por índice ...

La enumeración ButtonList probablemente debería cambiarse de nombre a MouseButtonList ya que son botones del mouse.

¿Debería dividirse la enumeración JoystickList ? Contiene botones y ejes, podría tener más sentido como JoypadButtonList y JoypadAxisList o similar.

Solo una pregunta, ¿por qué no MouseButton ?
if button == MouseButton.LEFT:
lee mejor que
if button == MouseButtonList.LEFT:

Buena idea. En ese caso, también hay KeyList -> Key , MidiMessageList -> MidiMessage , y los del joystick deben eliminar List .

Noté que algunos métodos / propiedades usan normal_map , mientras que otros usan normalmap . Deberíamos conformarnos con cualquiera de estos, pero probablemente no con ambos. Preferiría normal_map , pero estoy de acuerdo con normalmap también.

GDScript

range_lerp () = mapa ()
semilla = set_seed ()

map () probablemente esté reservado para las nuevas características de programación funcional.

Vector2.tangent() se describe en los documentos como: Returns a perpendicular vector. , esa es la definición de orthogonal o orthonormal si el vector devuelto está normalizado. Dado que Vector2.tangent() devuelve un vector no normalizado, propongo que deberíamos cambiarle el nombre a Vector2.orthogonal() o incluso Vector2.perpendicular() si la gente tiene algo en contra de la nomenclatura matemática o tal vez incluso Vector2.normal() , pero la gente puede confundirse entre normalized() y normal()

Anecdótico por mi parte, pero la primera vez que busqué esto, mis primeras búsquedas en los documentos fueron para _perpendicular_.

También puede mantener .tangent() solo como un alias para .perpendicular() , ¿no?

No me gusta el nombre orthogonal porque no es una palabra común en inglés en comparación con las demás. No vi ningún problema con tangent antes, pero creo que perpendicular es un nombre mejor de todos modos.

Sí, ortogonal es raro. Voto por .perpendicular () pero MANTENIENDO el alias de tangent () para compat, así como, es más corto.

@ Zireael07 Preferiría que solo tuviéramos una forma de llegar a la tangente. Después de todo, no creo que sea una operación muy común.

Te sorprendería la frecuencia con la que lo uso en mis scripts procgen :)

No esperaba que esto generara un debate, pero personalmente estoy en contra de mantener Vector2.tangent() ya que es un uso incorrecto del término matemático habitual. El producto de Vector2.tangent() es simplemente incorrecto por definición. El nombre de este hilo es la próxima ruptura de compatibilidad planificada, por lo que no veo ninguna razón por la que debamos hacer todo lo posible para mantener la compatibilidad. Personalmente estoy bien con Vector2.perpendicular() .

Sugerencia: hacer find_node() 's owner parámetro false por defecto.

Sugerencia: cambie el nombre de los métodos / señales de Tree para que sean menos confusos con respecto a, por ejemplo, términos / estados de "seleccionado", "enfocado" y "nada".

Creo que Tree::ensure_cursor_is_visible es engañoso y debería cambiarse el nombre a algo como ensure_focused_item_visible o ensure_selected_item_visible .

Incluso la referencia de la clase dice:

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() devuelve específicamente el tipo nativo debajo. Ahora que hemos nombrado clases de script, tiene más sentido cambiar el nombre a get_native_type() ya que la "base" del script podría ser potencialmente el nombre de un script. Es engañoso.

@willnationsdev También hay get_class() https://github.com/godotengine/godot/issues/16863#issuecomment -491421079

@aaronfranke Bueno, con get_class() se usa universalmente para referirse a "¿cuál es el nombre de lo que estoy viendo actualmente?". Entonces, en el caso de un Script , esperaría recuperar "GDScript" , "CSharpScript" , o algo por el estilo. Pero sí, con clases que no son Script , debería ser un método que devuelva el nombre de la clase de secuencia de comandos real si se nombra. Incluso hay un tema específico para ello. https://github.com/godotengine/godot/issues/21789#issuecomment -618588900

Editar: Oh, supongo, si tenemos get_class() , get_base_class() y get_native_class() , realmente necesitas get_instance_base_type() para convertirte en get_instance_native_class() para siga la convención de nomenclatura y aclare que es la instancia en lugar de la información del script.

Creo que autotile_coord (propiedades y métodos) de TileMap deberían cambiarse de nombre por tile_coord o tile_coordinate porque tanto AUTO_TILE como ATLAS_TILE use esto y el nombre puede resultar confuso para los nuevos usuarios. Los documentos también necesitarán una actualización. Puedo hacer este cambio si no hay problema.

Considere eliminar el argumento new_text de LineEdit.text_changed ya que tiene el mismo comportamiento que LineEdit.text .

También considere agregar old_text además o como reemplazo de new_text .

Relacionado con https://github.com/godotengine/godot/issues/16863#issuecomment -394745886

Cambie el nombre de " capas de colisión", " capas de VisualInstance", " capa de procesamiento", etc.
" grupo de colisión", " grupo de VisualInstance", " grupo de renderizado", " grupo de luces"

La confusión acerca de por qué esas "capas" no se acumulan surge como un minucioso reloj en los canales de la comunidad.

Tenga en cuenta que se denominan capas en Maya, Lumberyard y Unity.

El hecho de que otra persona haga algo no significa que todavía no cause
confusión y es una buena idea.

El lunes 18 de mayo de 2020 a la 1:09 p.m., Jummit [email protected] escribió:

Tenga en cuenta que se denominan capas en Maya, Lumberyard y Unity.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

Me sorprende que nadie lo haya mencionado todavía, pero
Camera2D.zoom
la cámara se aleja cuando el zoom es mayor, que no es la forma en que funciona el "zoom" y es contrario a la intuición. No estoy seguro de a qué cambiarle el nombre, tal vez view_scale o algo similar.

@KoBeWi En lugar de cambiar el nombre de zoom , ¿no deberíamos invertir su escala para que se acerque cuando aumente el valor?

Esto romperá la compatibilidad al igual que lo haría al cambiar el nombre de la propiedad. Si seguimos la ruta de "escala invertida", no se puede arreglar automáticamente, desafortunadamente. Aún así, podría resultar en menos confusión a largo plazo.

@Calinou @KoBeWi ¿Existe un caso de uso para usar esta propiedad de zoom directamente, o todos tendrían que invertirla cada vez para aplicarla a la escala?

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

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

Tal vez, pero ¿dónde trazamos la línea con eso y algo como Node2D.get_position_2d() ?

Tal vez podríamos nombrar la clase Viewport2D, pero eso no sería necesario a menos que hagamos un Viewport3D.

@nathanfranke Propuse este método porque solo en el nombre no hay forma de saber si es 2D o 3D, considerando que hay 2 tipos de Transform . (Mientras que otros miembros ya tienen canvas_ o mouse_ )

@Zylann Este método es realmente extraño. Hay propiedades llamadas canvas_transform y global_canvas_transform , y la descripción de canvas_transform es la siguiente:

La transformación de lienzo de la ventana gráfica, útil para cambiar las posiciones en pantalla de todos los CanvasItems secundarios. Esto es relativo a la transformación de lienzo global de la ventana gráfica.

Por lo tanto, esperaría que get_final_transform combinara ambas transformaciones. Sin embargo, si miras el código, eso no es realmente lo que hace.

El código para esto es return stretch_transform * global_canvas_transform; . He estado tratando de averiguar para qué es stretch_transform y no tengo idea, no está expuesto y ciertamente no está configurado al cambiar canvas_transform . También hay un método llamado _stretch_transform que no usa stretch_transform . Es llamado por set_size , que toma el valor generado por _stretch_transform y lo asigna a stretch_transform . También hay canvas_transform_override que ni siquiera he mencionado y no está expuesto, pero se usa internamente.

Al final, creo que toda esta clase debería ser revisada. Viewport tiene 4 miembros Transform2D diferentes, 4 miembros Rect2 (i), 9 miembros Vector2 (i) y 2 miembros Transform (3D). Eso ya son 264 bytes (con flotantes de precisión simple) de solo estructuras de datos que almacenan la información de transformación, si suma todos los punteros y demás, probablemente esté más cerca de 1 KB. Quizás Viewport necesite todo esto, pero parece demasiado complicado, y al menos debería haber comentarios (hay muy pocos en este archivo).

¿Deben eliminarse Node2D / Node3D to_global y to_local ? Di comentarios sobre # 38902 que proponía agregar métodos que solo funcionan con la base, pero hay algunos problemas con estos.

En los proyectos de demostración, to_local no se usa en ninguna parte, y $ grep -RIn "to_global" devuelve solo 5 resultados, todos los cuales están en la GUI en demostración 3D, y el rendimiento de la demostración podría mejorarse cambiando esto para que almacene en caché la transformación global y use xform lugar de usar to_global .

En pocas palabras, la preocupación con estos métodos es que se usan con poca frecuencia y también que fomentan la escritura de código que funciona mal, ya que recalcula la transformación global varias veces.

27509

AnimationPlayer animation_started y animation_finished son un poco contrarios a la intuición. El primero se llama para todas las animaciones en la cola, mientras que el último solo se llama al llegar al final de la cola. No se menciona claramente en la documentación.

Si queremos detectar cuándo termina una animación en particular, tenemos que usar tanto animation_changed como animation_finished cual no es conveniente.

Realmente me gusta la sugerencia de @txigreman de ese número: podemos usar animation_finished siempre que termine una animación en la cola y agregar una nueva señal animation_all_finished (similar a Tween ' s tween_all_completed ) que se activa solo cuando llegamos al final de la cola.

¿Qué pasa con animation_queue_finished y / o animation_queue_started ?

No puedo encontrarlo aquí, así que lo propondría
find y findn par.

imagen de la última versión estable de 3.2.

Tal vez podamos cambiar el nombre de uno para mencionar su naturaleza de lidiar con la distinción entre mayúsculas y minúsculas.

Diga, find_ignorecase lugar de findn ?

@swarnimarun Tenemos muchos otros métodos que no distinguen entre mayúsculas y minúsculas y que terminan en n . Si cambiamos el nombre de uno de ellos, deberíamos cambiar el nombre de todos ellos.

Estos métodos ( find / findn etc.) básicamente hacen lo mismo. Podríamos simplemente agregar un argumento si deben distinguir entre mayúsculas y minúsculas o no.

@Calinou Preferiría mucho eso, usar GDScript después de dejarlo caer durante unos meses me ha dado una nueva perspectiva a la API, diría,

Cuanto más obvio, mejor. Recordar la API para todo es difícil por sí solo, un poco más de detalle en el nombre de las funciones parece un cambio sensato.

Se agradece que

Así que todavía preferiría una función diferente, incluso si la otra función solo llama a la primera con diferentes argumentos o algo así.

EditorInterface.get_editor_viewport() => get_editor_main_container()

Esta función no devuelve un Viewport , solo un Control que resulta ser el central que contiene los editores de secuencias de comandos 2D, 3D y la biblioteca de activos. Para el registro, el nodo devuelto es incluso un VBoxContainer* , pero se abstrae (sin embargo, es importante saberlo, porque afecta sus opciones de configuración).
El documento también es incorrecto, ya que su descripción se vincula a la clase Viewport . https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class -editorinterface-method-get-editor-viewport

@Zylann Debería ser get_editor_main_screen() ya que no es un contenedor, pero es la pantalla principal .

@aaronfranke, que también es un nodo Container , en realidad ^^ pero sí ... la pantalla principal también puede funcionar

Quiero preguntar: ¿alguien realiza un seguimiento de las propuestas en este tema?

Por ejemplo, arriba (https://github.com/godotengine/godot/issues/16863#issuecomment-557657413) propuse cambiar el nombre del método JSON.print . Se sugirieron varias opciones, pero ninguna de ellas apareció en la primera publicación.

Solo me preocupa que las ideas útiles se pierdan en tantas publicaciones. :sonrisa:

@dalexeev Recientemente hice un primer paso para actualizar la primera publicación, pero aún no

Tengo uno que potencialmente corrige algunos errores en RichTextLabel . Actualmente tenemos bbcode_text y text , pero ambos usan internamente la misma estructura de datos. Solo los métodos llamados son diferentes, mientras que set_bbcode vuelve a set_text cuando use_bbcode no está habilitado. Así que seguí adelante y los eliminé en el n. ° 39148. Agregué algunos otros puntos allí.

GetSceneInstanceLoadPlaceholder() en Node se ven muy mal, primero no devuelve un marcador de posición como sugiere el nombre, sino un bool y, en segundo lugar, esto filtra detalles de implementaciones heredadas en la clase base sin ningún requisito real (prueba para el tipo del nodo es posible de otras formas)

RayShape → SeparationRayShape , como se sugirió inicialmente en godotengine / godot-texts # 711.

¿Qué tal eliminar sort_custom y hacer que sort tome un Invocable opcional?

¿Deberíamos eliminar OS.get_ticks_msec() y OS.delay_msec() a favor de OS.get_ticks_usec() y OS.delay_usec() respectivamente? Esto evitaría tener dos formas de lograr lo mismo. Si necesita un valor en milisegundos, puede multiplicarlo o dividirlo por 1000.

Además, tanto GDScript como C ++ permiten agregar separadores en literales enteros, lo que hace que los valores grandes sean más legibles.

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

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

Además, tanto GDScript como C ++ permiten agregar separadores en literales enteros, lo que hace que los valores grandes sean más legibles.

Si ocurre la eliminación, la descripción de get_ticks_usec() debe mencionar los separadores.

@Calinou Por un lado, tiene razón, pero por el otro, en la mayoría de los casos, no se requiere tanta precisión.

La 'tijera alfa' en material espacial debería convertirse en el 'clip alfa' estándar

@ Flavelius No he visto el término "clip alfa" usado con frecuencia. Sin embargo, he visto que la "prueba alfa" se usa con mucha más frecuencia que el "clip alfa" y la "tijera alfa".

¡Eso es un montón de cosas para cambiar! ¿Alguien está trabajando para implementar estas sugerencias?

@MCrafterzz Las personas abren solicitudes de extracción para cambiar el nombre de las cosas de forma regular. Esto se hace de forma incremental en lugar de todo a la vez.

Textura (Texture2D) e Imagen

• get_data () en Texture (Texture2D) debe llamarse get_image () y get_data () en Image debe llamarse get_bytes () para ser autodescriptivo.

En mi opinión: get_image sí, get_bytes no.

texture.get_image().get_data()

Malla / MallaInstancia

• En Mesh obtienes / configuras Materiales con esos métodos:
  surface_get_material/surface_set_material
• En MeshInstance obtienes / configuras con esos métodos:
  get_surface_material/set_surface_material

Supongo que debería ser el mismo nombre.

@Coldragon Debe ser get_surface_material / set_surface_material y una propiedad de surface_material .

@Coldragon Debería ser get_surface_material / set_surface_material y una propiedad de surface_material .

No es un set / get "normal", tienen un índice para la superficie de destino (es un vector dentro de la clase Mesh)

Array deberíamos cambiar el nombre de empty() a is_empty() para ilustrar mejor que es booleano

String deberíamos eliminar find_last() a favor de rfind() . No es exactamente un cambio de nombre, pero vale la pena discutir cuál conservar.

Para números individuales, tenemos stepify . Para Vector2 / Vector3, tenemos snapped .

Hacen lo mismo, los vectores llaman stepify para cada componente. Se debe elegir un nombre, pero ¿cuál?

Encuesta:: corazón: = ambos deben ser stepify ,: cohete: = ambos deben ser snapped ,: -1: = no cambiar el nombre.

AABB tiene intersection , mientras que Rect2 tiene clip . Ellos hacen la misma cosa. Se debe elegir un nombre, pero ¿cuál?

Encuesta:: corazón: = ambos deben ser intersection ,: cohete: = ambos deben ser clip ,: -1: = no cambiar el nombre.

@aaronfranke sí, sugerí anteriormente el nombre intersection en https://github.com/godotengine/godot/issues/16863#issuecomment -449628319. Luego tenemos intersects que podría cambiarse de nombre a overlaps en Rect2 , pero no estoy seguro acerca de AABB respecto a intersects → overlaps renombrar.

Creo que find_node y / o get_node deberían cambiarse de nombre porque los nombres no indican diferencias entre los 2 en absoluto.
Dado que find_node solo mira a los niños, ¿tal vez find_child_node?
No estoy seguro de cuál sería un buen nombre alternativo para get_node. Mi primer pensamiento fue get_tree_node, ya que puede obtener un nodo desde cualquier lugar del árbol, pero también se puede usar fuera del árbol de la escena con rutas relativas.

Encuentro get_node bueno, pero find_node podría cambiarse find_child nombre

@MuffinManKen Creo que get_node es perfectamente comprensible ya que, como dijiste, puede buscar cualquier nodo, en cualquier lugar, siempre que esté conectado con el mismo árbol que el nodo dado, independientemente de si son parte de el SceneTree o no.

@Coldragon No estoy seguro de que me guste cambiar el nombre de find_node a find_child tampoco, ya que me da la impresión de que solo funciona con hijos directos por alguna razón. La alternativa sería llamarlo find_descendant o algo así, pero eso es demasiado prolijo / complejo. Reducirlo a solo find() tampoco tiene sentido, ya que no está claro qué estamos buscando. Como tal, creo que a menos que se busque otra alternativa, find_node debería permanecer como está también. Debería tener claras diferencias documentadas en el comportamiento de los documentos de la API.

En Godot 3.1, agregué una etiqueta de función standalone que se evalúa como true cuando el proyecto se ejecuta desde un binario de plantilla de exportación (depuración o lanzamiento). Lo opuesto es editor , que se evalúa como true cuando el proyecto se ejecuta desde un editor binario.

Sin embargo, con el tiempo, creo que sería mejor cambiar el nombre de standalone a runner ya que es más corto y un poco más claro. ¿Qué piensas?

¿Qué pasa con exported o release ?

@aaronfranke exported implica que el proyecto se ha exportado, lo que no es necesariamente el caso. Puede utilizar un binario de plantilla de exportación para ejecutar un proyecto directamente desde sus archivos de origen, siempre que los activos se hayan importado de antemano.

Además, release ya se usa para binarios en modo de lanzamiento (en contraste con debug , que se usa para binarios en modo de depuración).

runner no me parece muy claro. standalone está bien. Eliminarlo también estaría bien, porque solo puede usar !OS.get_feature("editor") .

Eliminarlo también estaría bien, porque solo puede usar !OS.get_feature("editor") .

Sin embargo, esto no se puede usar para anular la configuración del proyecto, ya que no hay .not selector

¿Por qué no app o game en contraste con editor entonces? ¿O sería más confuso? ¿Quizás tenga un indicador de función para que no-editor sea ​​más explícito?

@willnationsdev game implica que Godot solo se puede usar para juegos. Muchas personas están usando Godot con éxito para aplicaciones que no son de juegos, por lo que prefiero usar un término más inclusivo: mild_smiling_face:

Además, no se explica por sí mismo: la gente podría pensar que todavía se aplica a los proyectos que se ejecutan desde el editor (después de todo, estás ejecutando el "juego" desde el editor). Lo mismo ocurre con app .

¿Qué pasa con "independiente"?

El sábado 25 de julio de 2020 a las 5:49 am Hugo Locurcio, [email protected]
escribió:

@willnationsdev https://github.com/willnationsdev juego implica Godot
solo se puede usar para juegos, lo que ha demostrado no ser el caso 🙂

Además, no se explica por sí mismo: la gente podría pensar que todavía
se aplica a los proyectos que se ejecutan desde el editor. Lo mismo ocurre con la aplicación.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
.

@MuffinManKen independent tampoco me suena muy claro .

Editor vs independiente es probablemente un nombre estándar (al menos uno que veo en muchos motores diferentes), por lo que no hay razón para reinventar la rueda en mi humilde opinión.

Get_node no se limita a obtener descendientes, por lo que sería muy
nombre engañoso. Los 2 métodos necesitan nombres muy diferentes porque lo que
hacer es muy diferente.

El sábado 25 de julio de 2020 a las 3:14 pm golddotasksquestions, <
[email protected]> escribió:

Recuerdo la confusión que tuve durante mucho tiempo al principio con
find_node y get_node. Realmente me gustaría find_descendant y
get_descendant, ya que estos serían verdaderos e informativos @willnationsdev
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
La "palabrería" puede que no sea el gusto de todos, pero en mi humilde opinión no es realmente
problema ya que hay autocompletar y taquigrafía "$".

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
.

Creo que en los métodos Transform y Transform2D inverse y xform_inv deberían cambiarse el nombre / eliminarse porque lo que estos métodos realmente hacen no es lo que la gente espera que hagan . Más detalles: https://github.com/godotengine/godot/issues/39433#issuecomment -664024521.

RayCast.cast_to debería cambiarse de nombre a RayCast.segment o algo así. Alguien me dijo que le tomó 40 minutos darse cuenta de que es una propiedad y no una función. Probablemente porque también es un verbo.

¿Qué pasa con RayCast.target ?

@ razcore-art Recientemente respondí una pregunta relacionada con el casting de rayos , y usé la palabra segment para describirlo, así que creo que tiene sentido. Pero esto también podría reescribirse como direction y length , por lo que en realidad se convertirá en algo más cercano a un rayo en lugar de un segmento, hablando geométricamente (o simplemente proporcionar propiedades alternativas que podrían coexistir) . El problema es que no hay forma de establecer fácilmente un vector de dirección normalizado en el inspector. Escribí una propuesta para hacer una, al menos para 2D: godotengine / godot-proposiciones # 397, pero quizás eso sea demasiado inverosímil.

EDITAR: Después de pensarlo más, segment no tendría mucho sentido en términos de RayCast nodo , pero tiene sentido en términos de Physics2DDirectSpaceState.intersect_ray() .

¿Qué pasa con RayCast.target ?

@nathanfranke Asumiría que el objetivo es Node o NodePath . Entonces, al menos, esto podría ser RayCast.target_position . Quizás RayCast.cast_position o RayCast.cast_offset . No olvide que los rayos pueden rotar, lo que puede cambiar la posición real del lanzamiento en coordenadas globales.

PhysX API confirma mi idea de dirección de unidad + longitud para configurar raycasts. 😛

Dicho esto, me estoy inclinando hacia cast_position ... Porque reescribir cómo funciona el casting de rayos requiere más cambios centrales.

@Xrayez Evitaría usar la palabra "cast" al comienzo de una propiedad, ya que, naturalmente, lo leo como el verbo "cast" y no como el sustantivo "cast", y por lo tanto cast_position probablemente no habría resolvió el problema original de no saber que esto es una propiedad y no un método (sería fácil asumir que cast_position es un método que lanza a una posición). Me gusta target_position .

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

Puede cambiar el nombre de KEY_BACK a KEY_MEDIA_BACK y KEY_FORWARD a KEY_MEDIA_FORWARD . Puede haber otras claves de medios que pueden usar un prefijo MEDIA .

Deberíamos considerar cambiar String begins_with() a starts_with() .

Es así en Java, C #, Python, JavaScript, etc.

Edición de Bugsquad: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool , float , int son los únicos tipos / clases cuyos nombres comienzan con una letra minúscula. Creo que deberían cambiarse de nombre (en GDScript) a Bool , Float , Int . Esto solucionará automáticamente el problema con el resaltado de sintaxis de tipo incorrecto.

Y bool , float , int deben usarse solo para funciones integradas similares a @GDScript (también incluyen len y str ).

Tenga en cuenta que la situación es similar con str / String : str(x) y String(x) dan el mismo resultado.

AGREGAR. Debería haber tenido este aspecto:

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

@dalexeev Están en minúsculas porque son tipos primitivos. Verá esto en la mayoría de los otros idiomas.
Las clases como Node son tipos de referencia y no se copian en la asignación.

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

En todo caso, deberíamos considerar cambiar el nombre de String a string ya que String no es mutable y se comporta de manera más similar a int que decir Node .

Redactando esto por ahora, ya que ese también sería el caso con Vector2 , Vector3 , etc.

@nathanfranke En diferentes idiomas es diferente. Por ejemplo, en Kotlin, Haxe, los nombres de Ada de todos los tipos están en mayúscula.

Además, la primitividad es un concepto condicional. Para mí, String , Color , Vector2 , etc.son tipos primitivos, especialmente porque se pasan por valor y no por referencia.

El único obstáculo es una violación de la compatibilidad con versiones anteriores.

ya que String no es mutable

Sorprendentemente, las cadenas de GDScript son mutables:

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

Vector2 no es una primitiva porque está compuesta por 2 float . Sin embargo, Vector2 y float son tipos de variantes incorporados .

@Zylann ¿Es una diferencia tan fundamental que debería reflejarse en el nombre del tipo?

(Para mí, 'primitivo' es 'simple', no 'de una pieza').

No quiero interpretar esto a mi favor, pero:

los nombres de los tipos

Estos son los términos tal como los entiendo:

| Escriba el nombre | Tipo primitivo | Tipo de valor | Tipo mutable | Tipo incorporado |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| int | Si | Si | N / A | Si |
| Vector2 | No | Si | N / A | Si |
| Nodo | No | No | Si | Si |
| Cadena | No | No | No | Si |

Independientemente, estos nombres no se cambiarán. Están bien tal como están y son familiares para los programadores de varios lenguajes. Deberíamos terminar la discusión aquí para evitar llenar este rastreador de discusiones inútiles.

La columna de tipo mutable es incorrecta: solo derivado de objeto, diccionario y matriz son mutables. ( Vector2 puede parecer mutable ya que puede hacer vec2.x = 0 , pero en realidad se traduce en algo como vec2 = vec2.with_x(0) )

Cambiar el nombre de ShortCut a Shortcut

Los siguientes métodos deben cambiarse
Inconsistencias entre

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

para

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

por coherencia con
y

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

necesita ser corregido.

PD : Partí del principio "Cuantos menos métodos similares, mejor".

@dalexeev Los parámetros booleanos suelen ser menos legibles que tener métodos diferentes, ya que true y false no tienen contexto.

Sí, pero la consistencia también sería buena. ¿Deshacerse de los parámetros booleanos en InputEvent entonces?

@Calinou En la mayoría de los casos, no es necesario comprobar si hay eventos de eco.

No veo esto como un gran problema. Cuando escribe el código, aparece la sugerencia de argumento. Al leer el código, puede usar Shift + Click. Los argumentos de las funciones de uso frecuente se recuerdan rápidamente (por ejemplo, String.split ).

Además, se encontraron 208 argumentos booleanos opcionales en el directorio doc/classes (este es solo el núcleo, y también 16 módulos tienen un directorio anidado 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, ¿puedes considerar poner eso en un spoiler para que el desplazamiento sea más fácil para nosotros?

@dalexeev Hay muchos casos en los que es necesario comprobar si se presiona una tecla y no solo si se acaba de presionar. Por ejemplo, una secuencia de comandos para mover un personaje necesita hacer esto con WASD o las teclas de flecha. Prácticamente todos los juegos necesitarán procesar entradas, por lo que no creo que sea un desperdicio tener solo dos métodos para estas cosas.

Al leer el código, puede usar Shift + Click.

No si está viendo diferencias en GitHub. Si el código requiere un IDE para ser legible, no es un buen código.

@aaronfranke Para los otros 207 casos, ¿también sugiere crear funciones separadas? Si no, entonces este argumento no es concluyente. Además, escribí anteriormente que si puede especificar el nombre del parámetro, entonces se vuelve legible sin un IDE.

Hay muchos casos en los que es necesario comprobar si se presiona una tecla y no solo si se acaba de presionar.

A menudo, pero no más a menudo que sin eco.

La presencia de tres métodos ( is_action_just_pressed , is_action_just_released , is_action_pressed ) es confusa porque espera que haya un método is_action_released .

AGREGAR. ¿Qué opción es más fácil, al menos visualmente?

is_action_released se puede lograr con not is_action_pressed . Esto no es cierto para los métodos just .

Como se mencionó anteriormente, se deben evitar los bools crudos. Una bandera como INPUT_ALLOW_ECHO / INPUT_NO_ECHO sería mucho mejor que un bool.

@dalexeev Eso solo introduciría confusión. is_action_pressed() y echo son 2 cosas diferentes. Puede comprobar usted mismo que los eventos de eco se reciben después de un ligero retraso después de presionar por primera vez, mientras que is_action_pressed() no tiene retraso.

@KoBeWi Puede que tengas razón y

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

debería cambiarse a

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

ya que esto no es consistente con

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 Lo que propones no es correcto. Cuando hablamos de eventos de eco, hablamos de eventos de teclado repetidos mientras presionamos una tecla, usar el término aquí tiene poco sentido, ya que el sistema de acción no depende del evento directamente, su estado se actualiza por cuadro. Además, las acciones también pueden funcionar con otros dispositivos como controladores o botones del mouse, donde el evento "echo" no existe.

Get_children () de TreeItem solo devuelve el primer hijo y no todos los hijos como sugiere el nombre (o la descripción en los documentos).

[Editar]
Nvm los documentos. La descripción del método se actualiza en master, lo siento.

Recomiendo que local_to_scene Resource sea local_to_instance o unique_per_instance . "Local a la escena" denota el comportamiento como local a la escena, cuando en realidad es por instancia de una escena.

Cambiar el nombre de Image.load() → Image.load_from_file() .

1. Ayuda a aliviar la posible confusión con los archivos load("image.png") través del código, consulte los cambios en la documentación en # 42412.
2. Image.load() ya no se resaltará como un nombre integrado de GDScript: # 28866.
3. Consistente con Image.load_*_from_buffer() por formato de imagen. Los métodos relacionados con el búfer se pueden unificar potencialmente en la misma interfaz para evitar el exceso de API, pero ese es otro tema de discusión.

@Xrayez También podría valer la pena eliminar load en GDScript: https://github.com/godotengine/godot-proposals/issues/263

La variable registering_order y el método relacionado set_registering_order en ProjectSettings no se utilizan.

RandomNumberGenerator debe cambiarse de nombre a Random y las funciones aleatorias globales como randf y rand_range deben quedar obsoletas o eliminarse.

Veo posibles problemas en los que uno llama a una función que no es de confianza mientras se especifica la semilla aleatoria

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

Las funciones aleatorias globales como randf y rand_range deberían quedar obsoletas o eliminarse.

Discutido como parte de godotengine / godot-proposiciones # 1590.

Preferiría que estos métodos aleatorios básicos tengan un alcance global para fines de accesibilidad y creación de prototipos, al menos algunos de ellos. Pero seed() y rand_seed() seguramente se pueden eliminar.

Parece que FuncRef ha vuelto redundante desde que se agregó Callable .

Descubrí los métodos property_can_revert y property_get_revert en el Inspector y los informé en # 43078. Sin embargo, creo que deberían cambiarse el nombre con guiones bajos iniciales para seguir las convenciones de _get , _set y _get_property_list .

EditorImportPlugin y EditorExportPlugin parecen estar relacionados, sin embargo, uno se trata de importar recursos y el otro de exportar un proyecto. Sugiero que cambiemos el nombre de EditorImportPlugin a EditorResourceImportPlugin o algo por el estilo.

Editar: Y EditorPlugin.add_import_plugin debe renombrar en consecuencia.

¿Por qué no ResourceImportPlugin ? Muchas (¿la mayoría?) De las clases de editor ya no contienen la palabra "Editor", como SceneTreeDock o todas las cosas de animación.

La enumeración Tracking_status en ARVRInterface debe cambiarse de nombre a TrackingStatus , para que sea coherente con los estilos de otros nombres de enumeración.

Mirando ARVRInterface arriba, la calidad de los nombres es bastante mala en general. Aquí están mis cambios de nombre sugeridos también:

• ar_is_anchor_detection_enabled → anchor_detection_enabled (propiedad)
• interface_is_initialized → initialized (propiedad, podría reescribirse más a enabled , ya que tiene un setter)
• interface_is_primary → primary (propiedad)
• get_render_targetsize() → get_render_target_size() (método)
• uninitialize() → finalize() (método)

De lo contrario, la documentación es incorrecta. 🙂

Tenga en cuenta que no he usado esta clase en absoluto, pero esos nombres se ven raros con solo mirar la clase.

¿Deberíamos cambiar el nombre de Control.MOUSE_FILTER_PASS a Control.MOUSE_FILTER_PASSTHROUGH ? Esto haría más obvio que el evento pasará a través del nodo Control a los nodos ubicados debajo de él. Sin embargo, no estoy seguro de si realmente vale la pena cambiarle el nombre.

@Calinou No imagino que dolería, así que estaría a favor. Como mencionaste, ese cambio haría que fuera un poco más obvio de un vistazo lo que está haciendo ese modo de filtro del mouse.

@Calinou Encuentro el comportamiento actual inusual. Esta configuración de escena produce "Haga clic en Niño2, haga clic en Escena"

(Tenga en cuenta que todos están configurados para Aprobar)

: smile: Proposición A : Quizás algo como Control.MOUSE_FILTER_PASSPARENTS para el comportamiento actual, ya que los eventos de entrada solo parecen enviarse a los padres.

: cohete: Proposición B : Cambie las constantes a estas:

• DETENER: Comportamiento actual: tomar el evento y detener toda la propagación
• PASS_PARENT: el mismo comportamiento que PASS actualmente
• PASS_ALL: IGNORE, pero acepta eventos
• IGNORAR: Comportamiento actual: no tome el evento, pero aún así propague

: ojos: Proposición C : Si el nodo toma entradas de la interfaz gráfica de usuario o no, no es realmente relevante, ya que uno simplemente no puede conectar ninguna señal (o usar una bandera booleana). Podemos cambiar la opción a Control.propagation_mode y tener estas constantes:

• NINGUNO
• PADRE
• TODOS

Eso se vería mucho más limpio en mi opinión.

Eso va más allá de cambiar el nombre y debe discutirse como una propuesta.

¿Por qué todos estos cambios de nombre son tan largos? Estás cambiando algo simple y corto por algo realmente largo.

Estás cambiando clip a intersection doble de tiempo para escribir.
También está cambiando Control.MOUSE_FILTER_PASS a Control.MOUSE_FILTER_PASSTHROUGH
etc

Preferiría cambios más simples, cortos y menos detallados. Es un nombre de función, no también una descripción de la función.

Preferiría cambios más simples, cortos y menos detallados. Es un nombre de función, no también una descripción de la función.

Sin embargo, el nombre debe ser descriptivo. Además, la longitud no importa si aprovecha el autocompletado (que está integrado en el editor Godot).

Lo mencioné una vez en IRC y no obtuve respuesta, pero TextureRect tiene un modo de estiramiento llamado "Escala al expandir (Compat)". Esto suena como algo que podría eliminarse.

"Menos detallado" definitivamente no está en el menú si queremos tener bases de código robustas en nuestros proyectos de Godot. Las herramientas de codificación modernas proporcionan autocompletado y otras funciones inteligentes que le permiten escribir rápidamente incluso si el nombre es largo. Además, si lee los argumentos de esos cambios, existe el objetivo de hacer que esas funciones sean menos ambiguas para los desarrolladores que las utilicen. El nombre corto puede ser dulce, pero confuso y menos visible.

Y recuerde siempre: escribir código es la parte rápida del desarrollo del software. Leer y comprender el código posteriormente es mucho más importante. Es como concebir y criar a un hijo, respectivamente.

No estoy de acuerdo con los dos. Soy un usuario de Godot y utilizo Godot específicamente porque GDScript es conciso y rápido de escribir. Si va a hacerlos dos veces más largos, la ventaja de la velocidad se perderá, ya que me verán obligados a escribir dos veces más y tendré que desplazarme el doble para ver toda la línea de código horizontalmente.

Cuando está codificando, no quiere escribir nombres de funciones o variables increíblemente largos. Algunos de estos cambios propuestos agregan nombres de funciones y variables extremadamente largos en aras de la "claridad" a expensas de todo lo demás. Puede leer la ayuda incorporada si tiene alguna duda. Además, la programación se trata de aprender una API. Siempre buscará una función la primera vez que la use, independientemente del nombre. Tomar printf en C es conciso y simple. En Godot lo llamaría send_formatted_string_to_standard_out. No solo está obligando a todos a volver a aprender la API, sino que algunos de estos cambios ni siquiera tienen una visión unificada. Me parece que un montón de gente se reunió y cada uno cambió una parte del motor.

Tome Array por ejemplo
remove -> remove_at ¿Qué agrega _at aquí? Ya tienes remove_value. ¿Qué más puedes eliminar?
erase -> remove_value Aún no es lo suficientemente claro. De documentos "Elimina la primera aparición de un valor de la matriz". Además, la gente podría pensar que puede eliminar un solo valor de toda la matriz. Para mayor claridad, en realidad debería ser remove_first_occurance_of_value porque eso es lo que realmente hace la función. Así que hizo que la función fuera más larga e igualmente confusa, solo que más larga.

Tiene remove y erase dos funciones diferentes, pero las convierte en la misma variación en remove con letras adicionales. Pero funcionan funcionan de manera diferente. Eliminar elimina de un índice específico donde como borrar elimina la primera instancia de un valor encontrado.

Estos están bien, pero no son realmente útiles más que obligar a las personas a actualizar su código.
invertir -> invertir
duplicar -> clonar
vacío -> is_empty

Si no está roto, no lo arregles.

@CarlGustavAlbertDwarfsteinYung pero no vas a escribir el doble. Después de las primeras 3 letras que escriba, la función de autocompletado se activará y usted seleccionará lo que necesita en lugar de escribir palabras completas.

En cuanto a otros nombres, por ejemplo, cuando echas un vistazo a empty -> is_empty , se necesita empty ¿puedes decir si este es un método que vacía algo, es un libro que verifica si algo está vacío, es otra cosa? Con is_empty puede ver de un vistazo que este es un bool que es verdadero si algo está vacío y falso cuando no lo es. Debes saber qué función o variables hacen con solo leer su nombre. No puedes hacer eso con un nombre como empty

@ Feniks-Gaming Puedo decirte que vacío o is_empty son igualmente confusos, solo uno es más largo que el otro.

@CarlGustavAlbertDwarfsteinYung empty puede ser una acción si se lee como un verbo. is_empty definitivamente es una cualidad. Por supuesto, esa confusión puede depender de tu nivel de inglés.

Además, incluso si una función se llamó send_formatted_string_to_standard_out en un editor de código moderno, se puede escribir como sfstso , o cualquier otra combinación de las letras intermedias, si así lo desea y el autocompletado le dará la única opción.

@pycbouh ¿La gente ha estado usando este motor durante cuántos años? Y no he escuchado a una persona que me diga que sabe cuál es el mayor problema con este motor. El hecho de que las matrices tengan empty lugar de is_empty .

Ustedes están sentados aquí arreglando cosas que nadie quería o pidió. Sí, la redacción es confusa pero no es realmente un problema y nunca ha sido un problema desde que comencé a usar este motor en 2015. Algunos de los cambios propuestos son bienvenidos y, para ser justos, utilizo is_. Está vacío estaría bien. Pero algunos cambios son demasiado largos e igualmente confusos. Estaba hablando específicamente de esos cambios, no todos.

Toda la existencia de este megathread es la evidencia de que la gente lo está pidiendo. Estos problemas pueden ser insignificantes para usted o para otra persona, pero las personas tienen problemas para comprender la API debido a una mala denominación. Y este es el tipo de problemas que acumula este número. En cuanto a la importancia de estos cambios en general, lo crea o no, el seguimiento e implementación de estos no le quita tiempo al resto del desarrollo.

Y mira el ejemplo que diste y trataste de explicar:

Eliminar elimina de un índice específico donde como borrar elimina la primera instancia de un valor encontrado.

¿Escribes eso y no ves ninguna razón para mejorar el nombre para que sea al menos un poco más claro para todos los usuarios actuales y futuros de Godot?

@pycbouh Y de hecho incluso di el ejemplo de la matriz remove_at y remove_value . remove_value no es lo mismo que la descripción de borrar y sigue siendo igualmente confuso. ¿Quitar valor de dónde? ¿Quitar valor del final, rmeove del principio? ¿Eliminar todas las apariciones de un valor de la matriz?

si realmente necesita cambiar las cosas, use remove y remove_first_occurence lo que lo hace a la vez conciso y descriptivo.

@pycbouh No lo estoy pidiendo. La existencia de este hilo se debe a que algunas personas están sobre ingeniería y arreglando cosas que no están rotas a la moda del programador clásico. ¿Y los futuros usuarios? ¿Que hay de ellos? Una vez fui un futuro usuario y aprendí la API. No tuve ningún problema con la nomenclatura de funciones. El 50% de los comentarios son personas que no están de acuerdo con los cambios propuestos. Parece que la mayoría de estos cambios son impulsados ​​por un pequeño número de miembros de la comunidad que impulsan estos cambios a todos. ¿Podemos votar los cambios propuestos?

De hecho aquí hay una propuesta. Cualquier cambio en el nombre de la API debe incluir las opiniones de los contribuyentes / donantes / usuarios. Si todos están de acuerdo, también estoy de acuerdo. Haz encuestas y mira lo que todo el mundo hace. No intente adivinar lo que quieren los demás. Lo que es bueno para usted puede no serlo para otra persona.

Estoy en contra de aproximadamente el 50% de los cambios propuestos aquí por lo que he visto.

El 50% de los comentarios son personas que no están de acuerdo con los cambios propuestos.

¿Podemos dejar las estadísticas inventadas en la puerta, por favor?

¿Podemos votar los cambios propuestos?

Para eso están la discusión y las reacciones.

Estoy en contra de aproximadamente el 50% de los cambios propuestos aquí por lo que he visto.

Si solo está en contra de ellos porque "lo aprendí de esta manera, así que quiero que todos después de mí sufran lo mismo", entonces es una crítica inválida de la proposición y será ignorada.

Lo que es bueno para usted puede no serlo para otra persona.

Ídem.

¿Podemos dejar las estadísticas inventadas en la puerta, por favor?

¿Te gusta esta afirmación sobre toda la comunidad?

Estos problemas pueden ser insignificantes para usted o para otra persona, pero las personas tienen problemas para comprender la API debido a una mala denominación.

¿Cómo sabe con qué tiene problemas la gente? ¿Les preguntaste? ¿Hubo alguna encuesta, estudio o cuestionario sobre esto? ¿Cómo obtuvo esta información?

Soy uno de esos usuarios que comencé desde cero y aprendí la API. No tuve problemas para nombrar. Todas las API tienen algunas convenciones de nomenclatura extrañas. Todas las funciones deben ser algo concisas para que pueda escribirlas en código.

@pycbouh Si estás tratando de convencerme de que todas las sugerencias de nombres aquí son buenas, tendré que estar respetuosamente en desacuerdo contigo. Este es un hilo que discute los cambios y estoy aquí para decir que algunos de los cambios propuestos no solo no son necesarios / solicitados, sino que son más largos e igualmente confusos. Algunos son realmente buenos y bienvenidos. No todos cambiemos el nombre de todo en masa solo porque algunas personas como usted piensan que toda la comunidad tiene un problema con los nombres de las API. No lo hice y nunca lo hice y comencé como principiante. Y conozco a un puñado de personas que tampoco lo hacen. Creo que algunos de estos cambios son significativos y deberían ser revisados ​​por pares por toda la comunidad o al menos por los colaboradores antes de una versión completa.

¿Cómo sabe con qué tiene problemas la gente? ¿Les preguntaste?

La mayoría de las entradas en este hilo son generadas por personas que vienen con problemas, ya sea aquí en GitHub (y en esos casos los problemas están vinculados) o usando otros canales comunitarios o personales. No asuma que estamos sentados aquí lamiendo nuestras propias partes privadas porque no tenemos nada mejor que hacer que reflexionar sobre qué otra función o propiedad renombrar en el motor.

Además, muchos de los cambios propuestos aquí ni siquiera se han aplicado, no hubo RP ni ninguna otra actividad. Están listados y eso es todo. Esté atento a las relaciones públicas y si aparece alguno que le ofende, no dude en comentarlo. Después de eso, depende del primer ministro de Godot aprobar y fusionar los cambios. Sea constructivo y puede evitar algunas modificaciones no deseadas, pero no olvide lo que usted mismo dijo una vez:

Lo que es bueno para usted puede no serlo para otra persona.

Entonces, incluso si no tuvo problemas con la API hasta este punto, no significa que otros no lo hayan tenido ni que no tengan ningún problema en el futuro.

Todas las API tienen algunas convenciones de nomenclatura extrañas.

Eso es bueno si hay una convención de la que hablar. Pero algunas de las API en Godot se nombraron mucho antes de que se convirtieran en código abierto y es posible que no estén tan bien pensadas como cabría esperar. Una vez más les pido que no asuman que la gente aquí sugiere cambios por el gusto de hacerlo.

Por favor, no tenga este tipo de discusiones aquí. Si desea discutir cambios específicos de API, está bien, pero las declaraciones generales de que no le gustan las sugerencias aquí no son útiles.

Los desarrolladores principales revisarán cada una de estas sugerencias una por una. Es probable que muchos terminen no siendo aceptados.

Bloqueo temporal, se desbloqueará más tarde.

¿Podríamos agregar los siguientes puntos a la lista?

• AnimationPlayer : Cambiar el nombre de stop() a pause() (https://github.com/godotengine/godot/issues/16863#issuecomment-562363660, godotengine / godot-texts # 287)
• AnimatedSprite : Cambiar el nombre de stop() a pause() (# 31168) (ya agregado)
• AnimatedSprite3D : Cambiar el nombre de stop() a pause() (# 31168) (ya agregado)
• Tween : Cambiar el nombre de stop() a pause() , stop_all() a pause_all() (PR # 41794, # 43442)

Interpolación: cambie el nombre de stop () a pause (), stop_all () a pause_all () (# 43442)

Esto está cubierto por # 41794

@ opl- esto también se discute aquí: https://github.com/godotengine/godot-proposals/issues/287

Un par de cambios de nombre que podrían aclarar lo que hacen estas funciones de RNG de alcance global:

• seed() -> set_seed() (tal vez agregue get_seed() también para que coincida con RandomNumberGenerator) - Actualmente, no está claro que esta sea una función de establecimiento.
• rand_seed() -> rand_from_seed() - actualmente, parece que podría aleatorizar la semilla o algo así, cuando en realidad da un número aleatorio basado en la semilla proporcionada.

rand_seed () -> rand_from_seed () - actualmente, parece que podría aleatorizar la semilla o algo así, cuando en realidad da un número aleatorio basado en la semilla proporcionada.

Excepto que aleatoriza la semilla. Lea la documentación.

rand_seed () -> rand_from_seed () - actualmente, parece que podría aleatorizar la semilla o algo así, cuando en realidad da un número aleatorio basado en la semilla proporcionada.

Excepto que aleatoriza la semilla. Lea la documentación.

Perdón. Lo que quise decir es que parece que solo aleatoriza la semilla. Tal vez debería ser rand_int_from_seed() , ya que devuelve un int? En realidad, los documentos no especifican qué tipo devuelve, y solo mencionan un "Número ... aleatorio". ¿Es un int?

Entonces, ¿genera una nueva semilla basada en una semilla que le pasa y luego genera un nuevo número basado en esa nueva semilla? No estoy seguro acerca de un cambio de nombre, pero la descripción puede necesitar una revisión allí, si eso es lo que está sucediendo.

Si eso es lo que hace, parece que este método debería dividirse en 2 métodos más pequeños que hagan una cosa en lugar de renombrar

Control :: pendiente_resize

No usado.

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

Ahora entiendo que este método es mayormente equivalente a GDScript is (que era extends cierto), pero C ++ requiere más claridad.

La confusión con la que me encontré es verificar si el objeto en particular es de un tipo existente ( sin herencia):

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

La implementación subyacente usa macros / plantillas "heredadas" por todas partes, por lo que tiene sentido para mí cambiar el nombre a inherits_class .

Consulte también https://github.com/godotengine/godot/issues/21461#issuecomment -416155187:

get_class() y is_class() me confunden en general