Слишком утомительно для меня, но удачи всем, кто исправляет instance как instantiate в качестве глагола.

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 (значение) -> Control.set_rect_min_size (значение)
Control.get_custom_minimum_size () -> Control.get_rect_min_size

В классе Control гораздо больше, у всех get / set должно быть то же имя, что и у переменной, которую раздражает проверять доки каждый раз, когда вы знаете имя переменной.

Класс TileMap имеет несколько методов получения и установки, которые не согласуются с их соответствующими свойствами. Фактически, я бы предложил переименовать большинство методов получения и установки в этом классе, чтобы они согласились со своими свойствами, а также с именами в других классах.

Animation.track_remove_key_at_position должен быть
Animation.track_remove_key_at_time

Методы

• OS : execute следует разделить на два разных метода: один блокирующий, а другой неблокирующий.
  например, имена: execute / exec_process (блокировка) и spawn_process (неблокирующая) # 19302

LineEdit имеет параметр new_text на "text_changed", а TextEdit - нет.

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

Хотелось бы, чтобы VBoxContainer / HBoxContainer / GridContainer переименовали в простой VBox / HBox / Grid ...

А позже он будет снова переименован, потому что он слишком короткий, как pos-> position: D

Они длинноваты, вы правы.

Я заметил, что в настоящее время в именах методов Godot используются два разных соглашения об именах.

Иногда он следует общему соглашению, которое можно найти в API таких языков, как C # или Java, например [action][object]() form: т.е.)

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

Однако в других местах он следует другому соглашению [prefix][action][object]() , например:

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

Это всего лишь несколько примеров из многих.

Если мы сможем позволить в будущем внести радикальные изменения, нарушающие совместимость, я бы хотел, чтобы их можно было переименовать, чтобы они соответствовали единому, четко определенному соглашению об именах (надеюсь, первое, поскольку оно чаще используется как внутри, так и вне Godot).

Однако в других местах он следует другому соглашению [prefix][action][object]() , например:

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

Я не проверял все способы использования дважды, но, судя по тому, что я видел, этот стиль именования методов, хотя и немного неудобный, также следует определенному соглашению. Например, методы shape_owner_get :

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

«Префикс» относится к первому аргументу, а часть после get - это то, что вы фактически получите в этом префиксе. Например, shape_owner_get_shape_index(owner_id, shape_id) концептуально похож на get_shape_owner(owner_id)->get_shape_index(shape_id) , но ShapeOwner предоставляется API сценариев, отсюда и этот «ярлык».

Та же история и с методами 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">

Или методы *node_get в 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">

Я обновил OP с большинством предложений, сделанных до сих пор.

Хотелось бы, чтобы VBoxContainer / HBoxContainer / GridContainer переименовали в простой VBox / HBox / Grid

Я не уверен, что в Godot мы стараемся давать всему явные имена, и, например, Grid не сообщает мне, что это Контейнер. Для VBox и HBox можно утверждать, что коробки являются контейнерами по определению, но поскольку у нас есть BoxContainer что не то же самое, что Container , я думаю, что многословие по-прежнему оправдано.

LineEdit имеет параметр new_text на "text_changed", а TextEdit - нет.

Не думаю, что было бы полезно добавлять в TextEdit new_text . В LineEdit он просто содержит весь текст LineEdit, а не текст, который был изменен, поэтому я бы даже сказал, что его не должно быть в LineEdit text_changed . Тем не менее, чаще вы хотите использовать полный текст LineEdit при вводе, чем делать что-то с полным текстом многострочного TextEdit при нажатии нового символа.

@ akien-mga

Я не проверял все способы использования дважды, но, судя по тому, что я видел, этот стиль именования методов, хотя и немного неудобный, также следует определенному соглашению.

Я знаю, что это собственное соглашение об именах. Но это все еще не то, что обычно используется за пределами Godot, а также немного сбивает с толку, потому что иногда одно и то же слово, например BlendShape , используется в методах, которые следуют двум различным соглашениям об именах.

Лично я бы хотел, чтобы все они были переименованы в GetPrefix* и SetPrefix* для единообразия, но, возможно, у других людей могут быть другие мнения по этому поводу.

Методы изменены в # 16757. Порядок аргументов имеет больше смысла, но нарушает совместимость API между 3.0 и 3.1 (# 19648).

Я снова подниму # 9128: translation в 3D против position в 2D - странное отличие.
Он был повышен в возрасте до 3.0, но был закрыт после того, как 3.0 вышел из-за отсутствия ... 3.0.

OS.execute следует использовать posix_spawn .

Другой может переименовать «маржу» в «смещение» для узлов управления.
Поскольку поля справа отрицательны, это вводит людей в заблуждение, особенно при сравнении со стилем.

@groud Я считаю, что смещение слишком универсально, поля были правильным словом, потому что они не были негативно ориентированы с правой стороны при первом введении

@groud Я считаю, что смещение слишком универсально, поля были хорошим термином (и не были отрицательными при первом введении)

Что ж, теперь маржа вводит в заблуждение, потому что она отрицательная. Смещение является общим, но имеет больше смысла. Я не думаю, что проблема в том, что они являются общими, поскольку они относятся к узлам управления.
В любом случае я открыт для лучших предложений. Я просто хотел отбросить эту идею здесь, поскольку такое изменение имени свойства уже предлагалось. См. Например здесь .

Размер ящиков / кубиков назван противоречиво.
BoxShape для столкновений использует экстенты.
CubeMesh имеет свойство размера с координатами x, y и z, каждая из которых составляет половину экстентов.
CSGBox имеет свойства Width, Height и Depth, которые определены как размеры x, y и z в CubeMesh.

В дополнение к свойству размера иногда используется «Куб», а иногда «Коробка». Было бы разумно использовать "Box" для всего, так как x, y и z для CubeMesh могут быть установлены независимо, и, таким образом, это также поле.

Поскольку в качестве целей у нас есть, например, HTML5 и UWP, которые не совсем операционные системы, я предлагаю переименовать ОС в Platform (PlatformWindows, PlatformUnix, ...).
Имеет смысл и с разделением OS / Display.

Начиная с этого # 20228, Label.clip_text больше не требуется. Я считаю, что то же самое и с Button.clip_text.

В настоящее время Camera2D имеет два разных свойства с именами offset (Обычное смещение и одно, разделенное на V и H), которые представляют собой две совершенно разные вещи, это действительно сбивает с толку.

Методы

- Dictionary : erase_checked следует удалить (этот метод не доступен для скриптов).
- Dictionary : erase следует изменить так, чтобы он возвращал bool чтобы определить, была ли удалена пара с указанным ключом (см. Реализацию erase_checked ).

20945

@neikeq Это можно сделать сейчас, ИМО, изменение возвращаемого значения Dictionary.erase с void на bool не должно нарушить работу какого-либо проекта.

@ akien-mga, но это нарушит совместимость GDNative API, не так ли?

@ akien-mga Разве это не нарушит совместимость? Разрешено ли нам вносить изменения, которые потенциально могут привести к тому, что скрипты 3.1 не будут работать в более старых версиях, таких как 3.0?

@neikeq Да, скрипты 3.1 уже несовместимы с 3.0 ( class_name , тонны изменений API с новыми необязательными параметрами или совершенно новыми свойствами / методами, новыми классами и т. д.). Мы заботимся только об обратной совместимости, а не об обратной совместимости.

О, я вижу! Если это так, я внесу эти изменения сейчас.

Если бы я мог добавить один в список, узлы управления LineEdit и TextEdit действительно выиграли бы от наличия согласованных API-интерфейсов друг с другом, чтобы их можно было использовать (в основном) взаимозаменяемо. Сейчас я чувствую себя беспорядком, пытаясь работать с ними вместе, до такой степени, что взгляд на один узел сбивает меня с толку о другом.

@ eska014 Кроме того, опция scons уже равна platform . Имеет смысл быть последовательным.

Настройки проекта display/window/size/test_width и test_height следует переименовать в window_width и window_height . Мы также должны рассмотреть возможность переименования настроек width и height , возможно, render_width и render_height .

Свойства камеры near и far имеют разные имена, чем ее сеттеры / получатели (например, set_znear / set_zfar). Это нужно изменить?

znear и zfar сбивают с толку. Это не имеет ничего общего с осью Z в мировом пространстве. Его можно изменить на clip_near и clip_far поскольку они управляют плоскостями отсечения, или просто на near и far .

Да, есть два способа решить эту проблему.

Мы должны избавиться (или серьезно обсудить) расширения двоичных ресурсов .. (RES_BASE_EXTENSION)

gdscript_function.cpp и gdscript_functions.cpp имеют очень похожие названия, я все время путаю их. Стоит переименовать? @vnen

Я изменил https://github.com/godotengine/godot/pull/21425, чтобы переименовать "decimals" в "step_decimals", но оставил "decimals" в качестве псевдонима. Предполагая, что он объединен, мы можем удалить «десятичные дроби» в следующем нарушении совместимости, если нет, просто переименовав.

@mysticfall На мой взгляд, лучше не использовать слово «get» в именах методов, когда это не нужно.

Иногда требуется, чтобы свойство можно было одновременно получать и устанавливать, но при этом контролировать доступ. В C # свойства позволяют делать это и контролировать доступ, просто читая и присваивая, как если бы это было поле, что приятно.

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

Однако в GDScript свойства - это не вещь (?). У нас также может быть имя метода без слова get. Большинство методов что-то возвращают, поэтому лучше иметь неявное получение, чем набор: поскольку GDScript имеет свойства, я предлагаю использовать их чаще. Обратите внимание, что мне не удалось найти никакой документации по этому поводу. Я нашел документацию о том, как это сделать внутри GDScript с помощью setget но как насчет добавления через C ++?

Вкратце, я согласен с тем, что нехорошо иметь "get" в несогласованных местах, но, на мой взгляд, идеальное решение на данный момент невозможно в свойствах иначе мы могли бы удалить "get" и оставить "set" .

@aaronfranke GDScript действительно имеет свойства, поскольку классы движка могут определять геттер и сеттер (или только геттер) и предоставлять GDScript как свойства. Тем не менее, я против удаления get и set из методов, потому что 1) это делает имя более понятным и 2) делает различие между получателем и установщиком. Например, Mesh.SurfaceFormat() звучит как метод, который «форматирует поверхность», а не метод, который «получает формат». Кроме того, большинство (если не все) из них в любом случае можно игнорировать и использовать как свойства.

Теперь меня не особо волнуют gdscript_function.cpp и gdscript_functions.cpp . В одном есть класс GDScriptFunction, в другом - определение функций GDScript, мне всегда ясно, что есть что (хотя я к этому привык). Это также не критическое изменение, поэтому его здесь не должно быть.

Да, у GDScript есть свойства. Свойства C # генерируются из ClassDB, откуда GDScript их получает.

Есть несколько методов для RigidBody и связанных с ним классов, параметры которых следует поменять местами для согласованности:

• RigidBody.add_force(force, position) в add_force(position, force)
• PhysicsDirectBodyState.add_force(force, position) до add_force(position, force)
• PhysicsServer.body_add_force(force, position) до add_force(position, force)

Список классов и методов

@TGRCdev Я бы предпочел изменить apply_impulse на (force, position), а не заменять add_force на (position, force). Положение силы - это необязательный параметр, поэтому он должен идти в конце. Но все силы и импульсы должны иметь вектор силы.

@aaronfranke Справедливый пункт. В этом случае список необходимых свопов:

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

@aaronfranke Я согласен с тем, что использование Get- или Set- - это своего рода "яваизм", которого лучше избегать в C #.

Меня больше всего беспокоило использование «префикса домена», например shape_owner_get_shape или node_get_input_count , поэтому, если мы можем переопределить их как правильные свойства C # без Get- или Set- Префиксы

Кстати, я всегда считал довольно странным, что свойства в Godot C # API имеют совпадающий набор геттеров и сеттеров, например, Node.Name и Node.GetName() / Node.SetName() .

Мне это кажется излишним, но если есть какая-то причина, по которой мы придерживаемся такого соглашения, я полагаю, мы бы в любом случае получили и NodeInputCount и GetNodeInputCount() / SetNodeInputCount() , если бы мы чтобы переименовать node_get_input_count как предложено.

Ребята, продолжайте обсуждение C # API и обычных соглашений, выходящих за рамки этой проблемы, которая сосредоточена на Godot API. API-интерфейс Godot (C ++, C и GDScript) не будет адаптирован для C #, если он не является улучшением для других языков.

@ akien-mga Я не думаю, что обсуждение того, может ли node_get_input_count быть переименовано в что-то вроде get_node_input_count связано именно с C #.

Нет, я имею в виду, что в этом выпуске не должно быть ничего специфичного для C #. При необходимости может возникнуть другая проблема для специфичных для C # сбоев совместимости (хотя уже есть несколько таких IINM).

Как насчет переименования Spatial в Node3D? Мне всегда это казалось странным.

@KoBeWi Схема именования, которую в настоящее время использует Godot, - это «Thing2D» для 2D-материалов и просто «Thing» для 3D-материалов, так что она вполне согласуется с остальной частью 2D-кода. Конечно, тогда логичным называть «Пространственным» было бы «Узел», следуя шаблону удаления «2D», но это имя, конечно, уже занято.

Схема именования, которую в настоящее время использует Годо, - это «Thing2D» для 2D-материалов и просто «Thing» для 3D-материалов.

Так может быть, поменять все 3D на «Thing3D»? Это тоже пришло мне в голову, но звучит как перебор.
В любом случае, я только что предложил. Не то чтобы это было очень важно. Кроме того, Spatial2D даже хуже, чем Spatial.

Итак, String.right () возвращает n правильных символов из заданной позиции. Разве не было бы более интуитивно понятным, если бы он возвращал всего n символов, считая справа?

"abcdef".right(2)
Вместо cdef вернет ef. ИМО было бы лучше.

Я ожидал того же.

У Python есть тот же метод, который большинство пользователей предпочитают сравнивать GDScript с Python. Возможно, его изменение запутало бы еще больше.

@KoBeWi Я согласен. Я не вижу разницы между текущей реализацией и подстрокой.

Godot substr заставляет вас указать размер строки, если вы хотите, чтобы все было справа.

@Zylann Большинство реализаций позволяют опускать второй параметр. Я бы считал это проблемой на стороне Годо. Кроме того, я предпочитаю substr сделать второй параметр необязательным, чем новый метод с другим именем.

@Zylann @neikeq Это неудачный результат наличия неперегружаемых методов, нет возможности иметь как указание длины, так и указание длины.

@aaronfranke Эм, но аргументы по умолчанию существуют. 0 или -1 могут считаться неопределенной длиной.

Необходимо удалить get_selected_id() из OptionButton настоящее время он всегда возвращает -1. После объединения https://github.com/godotengine/godot/pull/21837 get_selected_id() вернет то же самое, что и get_selected() .

Есть много методов промежуточного кадра, которые каждый раз возвращают истину, их, вероятно, следует сделать недействительными.

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

Узел Tree имеет функцию get_selected() которая, кажется, возвращает сфокусированный элемент TreeItem. Возможно, стоит переименовать его во что-то вроде get_active() , поскольку фокус и выбор - разные вещи.

load_from_globals() в InputMap должно быть load_from_project_settings() .

Я добавлю: tada: реакцию на все предложения, которые были интегрированы в OP, для лучшего обзора.

global_rotate следует переименовать в rotate_global а rotate_object_local следует переименовать в rotate_local для согласованности и чтобы все методы поворота начинались с "поворота".

global_rotate следует переименовать в rotate_global, а rotate_object_local следует переименовать в rotate_local для единообразия и чтобы все методы поворота начинались с "rotate".

Ну, с другой стороны, мне нравится, что глобальные функции (например, global_position, global_scale и global_transform) находятся рядом друг с другом в предложениях автозаполнения. Оба решения имеют смысл ИМХО.

Возможно, tree_exiting можно было бы переименовать в tree_exited поскольку, похоже, это уже вызывает некоторую путаницу. См. № 22840.

@groud Уже есть сигнал tree_exited верно?

@groud Там уже есть сигнал tree_exited, верно?

Блин ты прав. Полагаю, запрос в # 22840 действителен тогда

MenuItems.MENU_MAX никогда не используется в LineEdit и TextEdit , следует ли его удалить?

То же самое для Tabs.ALIGN_MAX https://github.com/godotengine/godot/blob/master/scene/gui/tabs.cpp#L750

Узлы Position3D и Position2D немного неоднозначны. Не читая описания, можно было бы предположить, что они похожи на Spatial и Node2D, но без поворота и масштабирования. Вероятно, их следует переименовать в PositionHint и PositionHint2D или, возможно, какое-нибудь другое слово, например Gizmo поскольку это штуковина только в редакторе, или AxisMarker потому что это выглядит как маленький маркер оси.

Если бы они были переименованы в Gizmo возможно, им можно было бы найти более широкое применение.

Обратите внимание, что тот же узел в дереве элементов управления - это ReferenceRect , поэтому ReferenceAxis/2D может работать.

Люблю эту проблему прямо сейчас. Может потом возненавидеть, когда поломка действительно случится;)

Некоторые предложения для скромного класса Array :

• duplicate → либо copy либо clone . Я не знаю ни одного языка, на котором это понятие называется «дублирование». copy - это то, что называется в Python и C ++, поэтому это было бы естественным выбором для Godot. clone взят из Java и JavaScript и, возможно, немного более точен.
• invert → reverse . В документации это даже описывается как «обратное», так что оправдания здесь нет.
• remove против erase сбивает с толку. Предложение: remove_at и remove_value .

Последние два также применимы ко всем классам Pool*Array .

Примечание. Дублировать → копировать / клонировать также применимо к словарям.

Rect2 :

• clip → intersection

AABB имеет метод intersection но не clip , отсечение обычно означает, что мы вырезаем что-то, что, кстати, не реализовано ни в одном из классов. Документация описывает это как:

Returns the intersection of this Rect2 and b.

Можно также переименовать:

• intersects → overlaps
  чтобы не путать с фактической операцией intersection :

Returns true if the Rect2 overlaps with another.

grabber_area -> slider_progress
slider -> slider_background

Некоторые предложения для скромного класса Array:
дублировать → либо копировать, либо клонировать.
...
Примечание. Дублировать → копировать / клонировать также применимо к словарям.

А также узлы и ресурсы (в основном любой объект структуры данных, представленный сценарием, afaik).

Я предпочитаю слово «клон», я думаю, оно более понятно, что оно делает.

Утро! @ akien-mga, нельзя ли переименовать instance в new вместо instantiate ? Наличие того же интерфейса на PackedScene что и Object s, например, удаляет некоторые шаблоны для создания плагинов, особенно, но, вероятно, в более общем плане. @willnationsdev что ты думаешь? Я знаю, что вы сталкивались с этим раньше.

Извините, если где-то уже есть разговоры об этом, я не смог найти его, просматривая.

grabber_area -> slider_progress
slider -> slider_background

или просто:
grabber_area -> progress
slider -> background ?

Я не знаю, обсуждалось ли это, но AnimationPlayer имеет root_node с set_root & get_root , они, вероятно, должны быть set/get_root_node

Переименовать CanvasItem.visible в CanvasItem.is_visible (и все другие места, где он используется)? чтобы соответствовать всем (или большинству, может быть, я кое-что пропустил) bool свойствам?

Переименовать Tween.tween_completed в Tween.tween_finished ? Прямо как Animation.animation_finished ? Обычно предпочитают _finished _completed ? Похоже, что у started/finished более тесные отношения, чем у started/completed - с предвзятым отношением к соревновательным видам спорта: start/finish - возможно: D

Пожалуйста, подумайте о переименовании класса JavaScript в HTML5 или что-нибудь еще.
У этого класса есть единственный метод, он не расширяется от Script и не используется на других платформах.

JavaScript будущем может использоваться как имя класса для привязок языка JavaScript.

Как указывает @clayjohn , WORLD_MATRIX в шейдерах CanvasItem на самом деле является матрицей просмотра модели. @reduz соглашается, что в 4.0 мы должны заменить его фактическими матрицами модели и просмотра, например, CANVAS_MATRIX и ITEM_MATRIX .

Попробуйте переименовать Array.invert в Array.reverse . Перевернуть больше похоже на перевернутый или «обратный» тип вещей. См. Https://docs.godotengine.org/en/latest/classes/class_color.html#class -color-method-инвертированный

Измените CanvasItem.visibility_changed() signal на CanvasItem.visibility_changed(visibility: bool) , т.е. отправьте с ним статус видимости. Поскольку этого будет достаточно, удалите CanvasItem.hide() signal

Удалите Resource::notify_change_to_owners , Resource::{un}register_owner .
Они используются только GridMap и CollisionShape, остальной код использует сигнал "changed" .

Rect2 : has_no_area следует переименовать в has_area , чтобы логика двойного отрицания не проверяла обратное в условных выражениях. То же самое относится к AABB : has_no_surface .

Основываясь на том, что сказал @lupoDharkael , в Godot есть несколько мест, где используются двойные отрицания. Ошибки типа «Condition! Math :: is_nan (x) is false» сбивают с толку.

parse_input_event (событие InputEvent)
Подает в игру событие InputEvent. Может использоваться для искусственного запуска событий ввода из кода.

синтаксический анализ вводит в заблуждение, синтаксический анализ будет получать и обрабатывать, но в описании указывается отправка или запуск ввода

Согласно # 24153 - CanvasLayer использует слой, чтобы описать, на каком слое рисовать свои узлы. Но почти каждый другой 2D-узел использует терминологию «Z Index» ( z_index ) для описания (что на первый взгляд кажется) того же самого. Как предложил @swarnimarun https://github.com/godotengine/godot/issues/24153#issuecomment -444950584, улучшая имена для слоев.

Будет ли OS.has_feature () / Platform.has_feature () более разумной в чем-то вроде ProjectSettings, поскольку они ничего не передают исключительно об ОС?

set_cell_item можно переименовать в set_cell, чтобы объединить GridMap с TileMap?

set_cell_item можно переименовать в set_cell, чтобы объединить GridMap с TileMap?

Если подумать, может быть, также должна быть set_cellv для GridMaps?

ARVRИнтерфейс:

• ar_is_anchor_detection_enabled -> anchor_detection или аналогичный
• interface_is_initialized -> is_initialized или is_interface_initialized

AnimationPlayer:

• play_backwards можно удалить, потому что play имеет для этого необязательный логический тип.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D:

• Измените disabled bool на enabled bool.

Bone2D:

• get_index_in_skeleton -> get_skeleton_index

• play_backwards можно удалить, потому что play имеет для этого необязательный логический символ.

Это было бы плохо для удобочитаемости, по крайней мере, до тех пор, пока не будет реализован # 6866. В C # это не проблема, поскольку он поддерживает именованные параметры.

ID в id_pressed( int ID ) и id_focused( int ID ) должен быть в нижнем регистре.

^
Это изменение на самом деле не нарушит совместимость. Вероятно, это может стать отдельной проблемой.

^
Это изменение на самом деле не нарушит совместимость. Вероятно, это может стать отдельной проблемой.

Верно!

28746 - Node.replace_by может сбивать с толку как имя. Не уверен, что может быть лучшим именем.

@ bojidar-bg может быть replace_self или swap_by ? но я думаю, что единственный способ избежать путаницы - это правильно задокументировать.

Если у меня есть Node2D с прикрепленным скриптом, который содержит class_name MyNode2D , метод get_class() возвращает Node2D вместо MyNode2D . Это может быть намеренно, но сбивает с толку и вводит в заблуждение.

РЕДАКТИРОВАТЬ: https://github.com/godotengine/godot/issues/26980

@aaronfranke get_native_class() возможно? Затем вы можете получить имя сценария из get_script().global_name если оно есть.

make_convex_from_brothers()
Я полагаю, что «братья» следует заменить на «братья и сестры», поскольку это слово используется везде для одноуровневых узлов.

ARVRPositionalTracker: get_type() -> get_tracker_type()

• get_tracker_type() более явный - get_type() можно спутать с get_class()

• GetType() уже используется для чего-то еще в C #, как указано здесь .

Он возвращает TrackerType , а также get_hand() который возвращает TrackerHand , поэтому при желании его также можно изменить на get_tracker_hand() для согласованности.

ARVRPositionalTracker enum TrackerHand: TRACKER_LEFT_HAND -> TRACKER_HAND_LEFT (и правая рука). В качестве альтернативы, TRACKER_HAND_UNKNOWN -> TRACKER_UNKNOWN_HAND , если это согласовано.

Node.NOTIFICATION_TRANSLATION_CHANGED вероятно, должно стать NOTIFICATION_LOCALE_CHANGED , поскольку «перевод» используется в пространственных узлах для обозначения «позиции», а не «языка».

set_as_toplevel() можно переименовать в set_as_top_level() , но следует изучить его поведение.

TouchScreenButton следует искать для версии 4.0, так как это изменение может нарушить работу: https://github.com/godotengine/godot/issues/28814

CanvasItem метод:

RID get_canvas_item () const
Возвращает RID элемента холста, используемый VisualServer для этого элемента.

Затем следует переименовать в get_rid() .

get_canvas_item() сбивает с толку, потому что я уже на узле CanvasItem . Это также обеспечивает согласованность, поскольку другие классы уже имеют аналогичный метод get_rid() : CollisionObject , Resource .

Следует ли изменить Label на TextLabel ? Несколько раз я хотел поместить текстовый объект и забыл, как он назывался, поэтому я ищу «текст» и обнаруживаю только RichTextLabel . TextLabel будет более согласованным с RichTextLabel поскольку это все еще текст, но без расширенных возможностей.

Для справки, в Unity есть Text и TextMesh , и я лично называю это текстом, а не меткой.

Мне также было интересно, что Tree и GraphNode были переименованы в TreeView и GraphEditNode .
Для Tree причина в том, что это слишком широкое название для глобального GUI-узла IMO, все другие GUI-фреймворки, о которых я знаю, используют TreeView .
Для GraphNode это связано с тем, что я недавно работал над несколькими прототипами с реальными структурами графов, и я не мог использовать ни Node ни GraphNode что меня сильно раздражало.

@Zylann, поскольку узлы Graph являются визуальными / элементами управления для графиков (а не деревьев), GraphContainer может быть лучше. Не уверен насчет GraphNode.

Должны ли мы иметь lerpf / lerpv / lerpc вместо Color/Vector2/3.linear_interpolate ? По крайней мере, переименуйте Color/Vector2/3.linear_interpolate в Color/Vector2/3.lerp

Как упоминалось в # 29598 от http_escape / http_unescape до uri_encode / uri_decode

Должны ли мы иметь lerpf & lerpv вместо Vector2/3.linear_interpolate ? По крайней мере, переименуйте Vector2/3.linear_interpolate в Vector2/3.lerp

Сокращение до vector.lerp () звучит хорошо. По крайней мере, с https://github.com/godotengine/godot/pull/16106 использование lerp() в скрипте имеет переключатель для поддержки векторов и цветов.

Vector2.angle_to_point() следует переименовать. Его название не соответствует текущему описанию. Не уверен, какое хорошее имя было бы, и стоит ли сохранять эту функцию.

Исходный выпуск: # 16307

@ razcore-art Уже открыто пиар по этому поводу https://github.com/godotengine/godot/pull/20371 , и он сохраняет обратную совместимость (я думаю).

РЕДАКТИРОВАТЬ: больше нет.

Area действительно должно быть Volume , поскольку это 3D. Тогда Area2D должно быть Area . Область по своей природе 2D.

GridMap должно быть CubeMap . Не уверен в этом, просто эта «сетка» для меня звучит как 2D вещь.

CheckButton control должно быть SwitchButton или что-то в этом роде. Это сбивает с толку, потому что есть еще Checkbox . А может, его стоит вообще удалить. Насколько я могу судить, он в любом случае выполняет ту же функцию, что и Checkbox.

Я согласен с re: CheckButton, а остальные - просто косметическими.

А может, его стоит вообще удалить. Насколько я могу судить, он в любом случае выполняет ту же функцию, что и Checkbox.

С точки зрения UX CheckBox и CheckButton - разные вещи, несмотря на одинаковую функциональность.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@ Rodeo-McCabe Area называется так для согласованности с 2D-аналогом, также одно из определений area - a particular extent of space or surface .
Кубические карты - это трехмерные изображения, правильность синтаксиса должна зависеть от контекста, иначе это просто добавит путаницы.

grabber_area -> slider_progress
slider -> slider_background

или просто:
grabber_area -> progress
slider -> background ?

Может быть:
grabber_area -> progress_area или progressed_area
slider -> progress_background ?

Кубические карты - это трехмерные изображения, правильность синтаксиса должна зависеть от контекста, иначе это просто добавит путаницы.

@ eon-s Достаточно честно, я этого не знал.

Площадь называется так для согласования с 2D-аналогом.

Проблема в том, что двумерный аналог также несовместим. В математике площадь равна длине * высоте, никакого третьего измерения просто нет. Поэтому нет смысла говорить Area2D, потому что он должен быть 2D в силу того, что он является областью. Другое, более математическое определение «площади»:

поверхность, включенная в набор линий, а именно: количество единичных квадратов, равных по размеру поверхности

Точно так же трехмерное пространство в математике называется «объемом». Сначала я был сбит с толку, когда обнаружил, что Area на самом деле является трехмерным узлом, вместо этого области были странно названы "Area2D". Поскольку это игровой движок, нам следует принять математические определения.

Хотя я понимаю причины, я не знаю, будет ли какая-то особая польза от изменения имени, особенно для новых людей. Я согласен с тем, что «Объем» может быть более подходящим термином для этого, но мне кажется, что использование «Объем» для 3D и «Площадь» для 2D может немного сбивать с толку. В конце концов, многие узлы, имеющие как 2D-, так и 3D-варианты, будут названы "

Я думаю, что наличие схемы именования в первую очередь (поскольку есть некоторые узлы, которые в основном придерживаются схемы) означает, что у нас не должно быть исключения из правила, даже если другой термин для одного варианта сделает больше смысла, иначе это может сбить с толку пользователей.

Однако, если можно ... возможно, переименовать Area2D в Area , а Area в Area3D ?

Изменить: кажется, что текст, окруженный <>, не отображается, если вы не экранируете <>

@ Rodeo-McCabe У меня сложилось впечатление, что цель именования узлов состоит в том, чтобы выражать вещи на человеческом языке, а не на математическом. Таким образом, «область» не должна быть геометрической, это место, где можно находиться, например, внутри уровня или сцены. IE - Площадь 1.

Сам узел напрямую не имеет какой-либо геометрии или сам является геометрией, поэтому другие, подобные мне, могут задаться вопросом, где находится его площадь / объем при его создании, а затем зачем мне прикреплять области и объемы (формы) к области и объем?

Если бы его переименовали, чтобы не путать с геометрической площадью, синонимы, вероятно, были бы лучшим вариантом.

Их можно было бы назвать:

• Регион2D / 3D
• Space2D / 3D
• Zone2D / 3D
• Поле2D / 3D
• и т.п.

Кстати, помимо того, что этот трекер предназначен только для методов, свойств и сигналов (не для узлов), @reduz недавно упомянул, что есть намерения минимизировать

Похоже, цель состоит в том, чтобы оставить все как есть сейчас, поэтому подобные вещи могут быть отложены до следующей основной версии после 4.0?

Пожалуйста, оставьте эту проблему для основных участников, это не место, где можно делать предложения о большом переименовании повсюду, цель состоит в том, чтобы исправить фактические несоответствия, которые делают API громоздким.

Изменения, описанные в OP, не являются серьезным нарушением совместимости, и большинство из них будет сделано для 4.0, то, что упоминал нарушением совместимости типа «ваш проект больше не может быть открыт» между 2.1 и 3.0 (намного больше изменилось, чем просто переименование вещей тогда, таких как полное переписывание системы звука и частиц, изменение системы импорта и т. д.).

В 4.0 будут некоторые нарушения совместимости, иначе он не назывался бы 4.0. Это будет разумно, и перенос будет простым, вероятно, с конвертером, чтобы гарантировать правильное преобразование переименованных свойств, методов и сигналов при использовании в сценах и скриптах. Обсуждать это в любом случае не место :)

Control _set_anchor() также должно опустить начало "_".

PopupMenu имеет index_pressed(index) и id_pressed(id) которые работают нормально, но также id_focused который фактически генерируется с индексом вместо идентификатора элемента.

Для этого пока нет проблем, но после того, как он предложил это Акиену сегодня, стоит включить его в список.

Выполните рефакторинг ARVRServer, чтобы он назывался XRServer. Когда мы разработали его, термин XR, чтобы обозначить, что и VR, и AR еще не получили широкого распространения. И нет, я не собираюсь использовать MRServer;)

Должен ли RayCast иметь свойство «Отключено» вместо «Включено»? CollisionShape имеет «Disabled», который по умолчанию равен false (что означает, что они включены по умолчанию). Напротив, свойство RayCast "Enabled" по умолчанию равно false , что делает их отключенными по умолчанию.

Или, если использовать положительную форму (что, на мой взгляд, в целом менее запутанно), должно ли CollisionShape иметь свойство «Включено» (по умолчанию true ) вместо «Отключено»?

@Calinou Я не знаю, потребуется ли для этого отдельная проблема, но если нам нужно быть последовательными, я бы действительно предпочел, чтобы такие логические значения всегда были Enabled . Установка логического значения true для отключения чего-то часто меня смущала.

@Calinou Я согласен с @Zylann, что двойные отрицания сбивают с толку, и их следует по возможности избегать. Вместо этого мы должны изменить bools с "Disabled" на "Enabled". Ничего страшного, если значение чего-то по умолчанию - «истина». Я обсуждал это в # 17212 и # 21822.

Свойство speed событий мыши и сенсорного ввода следует переименовать в velocity поскольку это Vector2.

InputMap : get_action_list( String action ) имя функции мало что говорит о том, что она делает.
Поскольку он возвращает EventInputs, связанные с данным действием, это может быть get_action_events(String action)

Также может помочь избежать возможной путаницы, поскольку InputMap имеет другую функцию с именем get_actions( ) и оба имени могут означать одно и то же вне контекста.

По касательной к # 30736, мы должны переименовать два физических движка Godot во что-то вроде «GodotPhysics2D» и «GodotPhysics3D», поскольку высказывание о том, что что-то не работает с «GodotPhysics», может означать две очень разные вещи.

Как насчет переименования Object._init() в Object._new() ?

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

new - _init

Я предполагаю, что _init самом деле следует за __init__ Python, в то время как new - это метод класса, а не его экземпляр.

Подходит ли для этой темы что-то вроде String : empty() -> is_empty() ? Я всегда думаю, что сначала нужно очистить строку.

@vortexofdoom, если говорить о несоответствиях в названиях методов и / или о том, как они должны называться, тогда да.

Я мог бы добавить, что String и NodePath имеют методы empty и is_empty соответственно, которые делают то же самое. Остальные основные встроенные типы, похоже, предпочитают empty name, поэтому, возможно, is_empty можно переименовать в NodePath чтобы сделать это согласованным для всех встроенных типов, но это Я думаю, потенциально это может привести к серьезному нарушению совместимости.

Я всегда думаю, что сначала нужно очистить строку.

Большинство методов используют для этого clear name в Godot.

@Xrayez ,

В большинстве методов для этого используется понятное имя в Godot.

Я знаю, просто ссылаясь на тот факт, что empty - это глагол, а также прилагательное, и добавление is_ проясняет, какой из них имеется в виду.

Я бы поддержал использование is_empty во всех встроенных модулях для этого bool.

В Godot 3.0 и 3.1 у нас были методы Set на C #. Однако они на самом деле не добавляли никакой реальной функциональности по сравнению с простым использованием конструктора и присваивания, но позволяли коду молча терпеть неудачу, поэтому они устарели. В основном они были добавлены мной, чтобы попытаться быть последовательными, поскольку метод для Quat уже существовал, который исходил из ядра, имеющего установленные методы. Для получения дополнительной информации см. # 30744.

В GDScript есть set_euler и set_axis_angle , но есть и конструкторы, которые делают то же самое ( q.set_axis_angle(myvec3, myval) можно заменить на q = Quat(myvec3, myval) . Core также имеет эти методы для Basis, но они не доступны для GDScript.

Тогда возникает вопрос, что с этим делать? Должны ли методы набора Quat быть устаревшими в пользу конструкторов и быть совместимыми с C #, или стоит оставить их явными в отношении выполняемой операции? Если последнее, следует ли раскрывать и методы Basis?

@aaronfranke Мне всегда казалось странным, что у конструкторов есть специальные методы, хотя в принципе ничего другого не делает, поэтому я

@aaronfranke Эта проблема

Geometry 's point_is_inside_triangle() to is_point_in_triangle() , чтобы соответствовать другим методам, которые также возвращают bool s в том же классе.

TreeItem.get_children() следует переименовать в get_first_child() . В документе также следует объяснить, что он НЕ возвращает дочерние элементы. Дочерние элементы повторяются с использованием get_next() .

При работе над # 31976 я заметил, что значение атласа теней должно быть степенью 2 (как для направленных теней, так и для теней всенаправленных / точечных). Однако методы принимают любое целочисленное значение; если это не степень двойки, метод округлит ее до ближайшей степени 2. Нам, вероятно, следует заставить его принимать перечисление значений, чтобы оно могло быть представлено в удобной для пользователя форме в настройках проекта.

Точно так же уровень анизотропной фильтрации должен быть перечислением (2 ×, 4 ×, 8 ×, 16 ×), поскольку здесь имеет смысл только значения степени двойки.

VisualServer instance_create2() следует изменить, чтобы на самом деле описывать то, что он делает иначе, чем instance_create() .

Для объектно-относительных переводов Spatial имеет translate_object_local который принимает Vector3 , а Node2D имеет move_local_x и move_local_y , которые принимают поплавки. И Spatial и Node2D должны иметь методы, которые принимают Vector3 и Vector2 соответственно, и либо translate_local либо local_translate будут быть более простыми именами, чем translate_object_local .

@leonkrause Вместо render_width и render_height было бы разумнее называть его viewport_width и viewport_height или, возможно, canvas_width и canvas_height , поскольку это эталонное разрешение, используемое для области просмотра холста, и фактически не влияет на рендеринг.

@ akien-mga, пожалуйста, рассмотрите возможность добавления методов навигации по дереву в свой список. Они очень запутанно названы и плохо документированы.

Когда я впервые столкнулся с ними, я подумал, что get_child () и get_next (), get_prev () управляют итератором так же, как и Directory. Мне пришлось провести собственное тестирование, чтобы убедиться, что все, что они делают, - это выдает один и тот же указатель при каждом вызове.

get_children () следует переименовать в get_first_child ().

get_next () и get_prev () следует переименовать в get_next_sibling () и get_prev_sibling ()

Как насчет переименования Engine.iterations_per_second в Engine.physics_fps для согласования с настройками проекта?

is_processing :

Возвращает истину, если обработка включена.

can_process :

Возвращает истину, если узел может работать, пока дерево сцены приостановлено.

Возможно, лучше переименовать can_process во что-то вроде can_process_paused чтобы избежать путаницы с методом is_processing .

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

Думаю, этот метод надо переименовать.

@dalexeev Во что его переименовать и почему?

@Calinou Этот метод фактически ничего не выводит на экран; он возвращает строку. Первая мысль заключается в том, что JSON.print работает так же, как Node.print_tree или OS.print_all_resources или как все другие методы print* .

Во что его переименовать? Я не уверен. JavaScript использует для этого JSON.stringify . В PHP есть функция json_encode . Непосредственно в GDScript есть аналогичная функция - to_json .

UPD. JSON.serialize тоже возможно, но по количеству символов совпадает с JSON.stringify . :улыбка:

Я бы посоветовал не использовать слово «сериализовать», поскольку оно обычно используется для двоичной сериализации, и для получения такого вывода в такой форме потребуются дальнейшие шаги.

Поскольку у этого класса есть только два метода для перехода между типами JSON и Variant, я бы посоветовал не использовать методы, содержащие слово json поскольку это бессмысленно.

Теперь, для вещей, которые были бы хорошим названием, существующий метод parse самом деле не имеет четкого противоположного слова ( см. Здесь ). Возможно одно из таких: encode , create , compose , generate ? Если используется encode имеет смысл переименовать другой метод в decode .

Я видел, как format и write использовались как обратные parse . stringify более известен среди разработчиков благодаря использованию в JavaScript.

Я видел, как format и write использовались как обратные parse . stringify более известен среди разработчиков благодаря использованию в JavaScript.

str2var - это VariantParser а var2str - это VariantWriter внутри (см., Например, # 33241, я даже использовал тот же термин для его описания).

Так что я за write , последовательность выигрывает. 😛

@Xrayez Измените print на write ? От Python к Паскалю? :смеющийся:

Как предлагается в https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552, может иметь смысл переименовать все, что связано с clear_color в background_color (включая настройки проекта).

Я ожидал, что 4.0 принесет большую волну новых людей в Godot из-за лучшей производительности, улучшений GI-зондов, общей шумихи и так далее.

Если эти изменения будут внесены в 4.0, эти люди получат жесткую посадку, так как почти никакие существующие учебные пособия (кроме официального учебного пособия по «первой игре») для них больше не будут работать.

Если эти изменения будут внесены после 4.0, скажем, в 4.1, это будет чрезвычайно ухабистая поездка для этих людей. Они только что изучили основы нового движка, и теперь им придется заново учиться. Начинать сложно, и необходимость пройти через это дважды слишком быстро после другого может быть достаточно разочаровывающим, чтобы полностью отказаться от этого.

Следовательно, не имеет ли смысла иметь версию «3.3» или «3.9» до выпуска 4.0, в которой есть все эти изменения API, нарушающие совместимость, но при этом у создателей учебников будет достаточно времени для создания некоторых руководств до ожидаемого массового притока новых пользователей?

Не уверен, что это подходящее место или нет, но поскольку это могло быть возможным частичным решением проблем с переименованием, я представлю его здесь.
Почему бы не внести все необходимые изменения в переименование, а затем добавить новый язык к переводам под названием GodotOldNames / GodotPre4.0, который имеет все старые имена для всех изменений.
Таким образом, если кто-то не найдет старые имена, присутствующие в старых руководствах, они могут просто изменить язык на GodotPre4.0. Это также упростило бы переход на новые имена.
Это не решает всей проблемы, но может работать вместе с # 4397.

@Anutrix Это добавило бы много сложностей (как насчет неанглийских языков?). Более того, не все строки, отображаемые в редакторе, изначально можно локализовать.

Физика « Слой », рендер « Слой »

Я помню, как в первые несколько недель изучения Годо я испытал то же замешательство, что и этот бедняк .

Физический «Слой», «Слой» рендеринга может иметь смысл для кого-то, кто работает с объектно-ориентированным дизайном , но для всех остальных это очень сбивает с толку. Термин «слои» используется при описании нескольких покрытий из краски или слоев ткани на ткани, слоев кожи на луковице (или огре), слоев осадка на поверхности планеты и т. Д.
Слои (множественное число, а не один слой), похоже, во всех этих случаях подразумевают наложение друг на друга.

Для многих людей «наслоение», особенно при работе с 2D-графикой или анимацией, подразумевает работу с передним планом, фоном и слоями между ними или поверх них. Многие люди думают о слоях как о целлоидных фильмах поверх фона, тогда как на самом деле Годо, как и многие другие игровые движки, использует различные способы «сортировки» для выполнения этой задачи.

Тот факт, что мы называем абстрактную общность, которую объекты Physics или объекты Render могут совместно использовать "Layers", в то время как эти абстрактные общности не имеют ничего общего с наложением визуальных слоев (то есть "сортировкой"), - вот что делает это это так сбивает с толку некоторых.

Когда я понял реальное использование и значение Physics «Layer», Render «Layer», я сразу задумался, почему это не Physics Group, Render Group, и, честно говоря, я до сих пор не знаю. У них определенно нет никаких взаимосвязей друг с другом, а это означает, что их порядок или отношение друг к другу совершенно не имеет значения. Называя их слоем, imho архивирует ничего, кроме сбивающих с толку людей, «группа», «затронутые группой» для масок или, может быть, какой-то другой термин, о котором я не могу сейчас вспомнить, был бы более точным.

AnimationPlayer метод
.stop (false) следует называть .pause (true)
потому что это то, что он делает.

Проект> Настройки проекта> Дисплей> Окно> Растянуть> Режим:

Режим растяжения «2D» следует называть « режим растяжения» «дисплей» или «универсальный».
потому что сложно называть это 2D, когда он работает так же хорошо для 3D-вариантов использования, но не совсем хорошо для всех 2D-сценариев (например, проекты пиксельной графики, в то время как почти вдвое проекты Godot 2D кажутся пиксельными).
«display» также был бы более описательным для того, что он на самом деле делает: рендеринг всей графики, будь то 2D-графика, 3D-объекты, 2D-сетки, Line2D и Polygons с разрешением дисплея.
Подробнее об этом здесь .

loop, repeat, oneshot, animationplayer, timer и подобные узлы могут быть уточнены.

зацикливание, повторение и отсутствие единого кадра - это одно и то же.

я думаю что
is_a_parent_of()
следует переименовать в
is_parent_of()

@KoBeWi см. Обсуждение на # 19801.

я думаю что
is_a_parent_of ()
следует переименовать в
is_parent_of ()

Я так не думаю, is_parent_of () предполагает, что учитывает только первого родителя, в то время как функция проверяет всех родителей рекурсивно.

@groud В этом случае он должен называться is_ancestor_of() . Если есть и другая соответствующая функция, то она должна называться is_descendant_of() .

@groud В этом случае он должен называться is_ancestor_of (). Если есть также соответствующая функция для другого пути, то ее следует называть is_descendant_of ().

Да, но если подумать, нет особой необходимости иметь обе функции, так как разница будет только в переключении «вызывающего» объекта и аргумента функции. Может быть, мы могли бы просто заменить функцию чем-то вроде is_descendant_of() и все готово.

Мы можем захотеть переименовать push_error() и push_warning() в print_error() и print_warning() соответственно. Это сделает их более доступными для обнаружения благодаря автозаполнению: слегка_smiling_face:

@Calinou print_error() можно спутать с printerr()

Пожалуйста, подумайте об изменении имени метода TreeItem.get_children() , поскольку имя подразумевает, что набор дочерних элементов будет возвращаемым значением, когда на практике возвращается первый дочерний элемент, а затем вам нужно перебирать остальную часть их с помощью get_next() (как описано в # 19796).

Цитата @Zylann из № 31404:

[Переименовать rpc() / rset() в] remote_call() / remote_set() ?
У этих методов тоже очень короткие имена, и я не уверен, достаточно ли псевдонима. Вам действительно нужно много играть в многопользовательском режиме с множеством этих вызовов на скрипт, чтобы оправдать трехсимвольные идентификаторы (что, я уверен, в большинстве игр нет).

Изменить (2020-01-03): если подумать, call_remote() и set_remote() могут иметь больше смысла, поскольку у нас уже есть call_deferred() и set_deferred() .

Изменить: не обращайте внимания на закрытие / повторное открытие ниже, я щелкнул слишком быстро.

Следующие методы

OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

следует переместить из класса OS класс Input для согласованности с методами:

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

TabContainer должны быть отредактированы сигналы tab_close и tab_hover .

• LightOccluder2D light_mask -> occluder_light_mask
• CPUParticles Flags перечисление -> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker get_name -> get_tracker_name
• PathFollow2D rotate -> что-то еще
• ArrayMesh ArrayType enum -> удалить это
• Сетка BlendShapeMode enum -> передать в ArrayMesh

Пояснения в https://github.com/godotengine/godot/issues/15763#issuecomment -568908661

Сигналы meta_hover_started и meta_hover_ended RichTextLabel следует переименовать, чтобы они соответствовали большинству других аналогичных соглашений об именах: meta_hover_entered и meta_hover_exited . Это не только делает его более близким к имитации остальной части API Godot, но и текущая схема именования из-за алфавитной сортировки заставляет их порядок быть обратным. Это немного дезориентирует, когда вы читаете документацию, поскольку очевидно, что хронологический поток операций состоит в том, чтобы сначала войти, а затем выйти. Это просто улучшает читаемость и последовательность, чтобы изменить это.

Я заметил, что нет свойства Texture.size. Вместо этого мне нужно было вызвать геттер Texture.get_size ().

Я спросил в Discord, было ли это задумано или нет. Одно предложение заключалось в том, чтобы опубликовать здесь вопрос, нужно ли преобразовать это в свойство, другое предложение заключалось в том, что, поскольку для этого нет «установщика», использование get_size () является ожидаемым в настоящее время поведением.

@jmbjr Есть ли у нас какие-либо свойства только для чтения, представленные как свойства (а не только методы получения)? Я помню, что видел встроенный обработчик ошибок при попытке установить свойство только для чтения. Я просто не уверен, что он вообще доступен для GDScript.

Да, я думаю, что если вы собираетесь начать поддерживать свойства, доступные только для чтения, вам понадобится флаг USAGE для этого, а также добавить код парсера / компилятора GDScript, который его поддерживает.

SoftBody имеет areaAngular_stiffness который должен быть area_angular_stiffness (то же самое для всех связанных методов).

Input.joy_connection_changed (метод) кажется, что он не должен подвергаться воздействию скриптового API, он вызывается изнутри кодом обработки джойстика каждой платформы.

@ akien-mga Когда я впервые увидел этот метод, очень рано после открытия Годо, у меня были похожие мысли, потом я вспомнил, как Кодзима построил легендарный игровой процесс в MetalGearSolid вокруг метода, который, должно быть, был очень похож на этот, и я подумал: " Годо даже дает мне возможность преодолеть 4-ю стену, как Кодзима, с помощью одной строчки кода, как это круто! "

Label и RichTextLabel имеют несовместимые свойства темы:

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

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

Кроме того, из-за разных значений по умолчанию один и тот же шрифт имеет разную высоту в Label и RichTextLabel .

Сигнал request_completion TextEdit можно переименовать в completion_requested чтобы использовать прошедшее время. Текущая версия звучит несколько императивно, вопреки природе сигналов обратного вызова.

еще одно несоответствие с физикой сигналов тела

Площадь:

area_shape_entered (int area_id, Площадь области, int area_shape, int self_shape)
area_shape_exited (int area_id, Площадь области, int area_shape, int self_shape)
body_shape_entered (int body_id, тело узла, int body_shape, int area_shape)
body_shape_exited (int body_id, тело узла, int body_shape, int area_shape)

Я полагаю, что area_shape в последних двух должна быть self_shape? или ...

Жесткое тело:

body_shape_entered (int body_id, тело узла, int body_shape, int local_shape)
body_shape_exited (int body_id, тело узла, int body_shape, int local_shape)

здесь это называется local_shape ...

@FrederickDesimpel Насколько я знаю, аргументы можно переименовывать без нарушения совместимости. Не стесняйтесь открывать для этого пул-реквест: немного_smiling_face:

В варианте:

Реальный -> Плавающий
Nil -> Null?

Мне лично нравится «настоящее» имя, так как термин «float» часто используется специально для 32-битных чисел с плавающей запятой, но реальное значение Variant является двойным, и большая часть движка использует real_t которое может быть любым.

PS Мы уже делали это переименование наоборот в 2017 году.

Рассматривали ли мы их переименование:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial уже был переименован в StandardMaterial3D в мастере.

Следует ли изменить значения limit_ в Camera2D на Rect2i ? Сейчас их всего четыре целых.

РЕДАКТИРОВАТЬ: маржа перетаскивания также может быть изменена на Rect2 .

String::begins_with на String::starts_with .

Как в серьезных языках программирования (Java, Python и т. Д.).

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

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

Хотя слово «просто» отсутствует, event.is_action _... () соответствует Input.is_action_just ... ().

Вероятно, нам следует поменять местами первые два аргумента Node.add_child_below_node() чтобы первый аргумент был таким же, как Node.add_child() . См. №19642.

_Семантическая ателофобия, говоря ... _

Должен ли Node2D.draw_circle быть Node2D.draw_disk поскольку он рисует диск, а не круг?
Node2D.draw_circle все еще может существовать как ярлык для draw_arc от 0 до TAU .

@Goutte На английском языке «круг» может относиться как к полому, так и к закрашенному кругу. Я думаю, что текущее имя легче обнаружить, поэтому я бы не стал его менять.

На английском языке «круг» может относиться как к полому, так и к закрашенному кругу.

Я не могу найти ничего, подтверждающего это . Есть ли у вас какой-либо источник этого утверждения или это интуитивное предчувствие?

Что касается обнаруживаемости, у нас все еще может быть draw_circle , он просто нарисовал бы круг, а не диск.

Я не могу найти ничего, подтверждающего это . Есть ли у вас какой-либо источник этого утверждения или это интуитивное предчувствие?

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

1b: замкнутая плоскость (см. Вход в плоскость 6, смысл 2b), каждая точка которой эквидистантна (см. Значение 1) от фиксированной точки внутри кривой
1 c: плоская поверхность, ограниченная такой кривой

(1 б) - математический круг (периметр), (1 в) - математический диск (поверхность).

С точки зрения API, для ИМО удобнее иметь draw_rect(bool filled) и draw_circle(bool filled) чем draw_rect() , draw_filled_rect() , draw_circle() и draw_disk() (или какое математическое имя будет для заполненного прямоугольника?).

Изменить: на самом деле draw_circle() еще не имеет аргумента filled . Я думаю, мы должны добавить один, чтобы его можно было использовать для рисования как кругов (периметр), так и дисков (закрашенный круг).

Хорошо, спасибо. Большинство моих студентов - французы, и все они были сбиты с толку, и я тоже, и они винили Годо, и я, конечно, не мог им позволить.

каково было бы математическое имя заполненного прямоугольника?

Это довольно хороший вопрос; все, что я могу найти, это «область прямоугольника» или «внутренняя часть прямоугольника», и ни один из них не подходит. В вики даже говорится, что большинство людей злоупотребляют термином «многоугольник» для обозначения «внутренней части многоугольника», не давая для этого другого слова.

Я предполагаю, что аргумент filled может помочь устранить двусмысленность, но будет сложно решить, где поместить его в список аргументов.

@Goutte, но будет

Поскольку это необязательный аргумент (он имеет значение по умолчанию), а также для согласованности с draw_rect , он должен идти в конце.

Бывают случаи, когда управляющие узлы называются модальными узлами. https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal В основном в отношении функции Viewport.get_modal_stack_top ()

Методы EditorInterface get_selected_path и get_current_path сбивают с толку как по названию, так и по функциям. У них также отсутствует документация.

Эти методы представляют собой лишь тонкий слой поверх одноименных методов FileSystemDock :

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

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

Они оба должны адаптировать либо «selected», либо «current» (или что-то еще, но для них обоих), причем один будет get_*_path а другой get_*_dir .

@Goutte Разве Solid Rectangle не является альтернативой заполненному прямоугольнику?

Будет ли OP обновляться предложениями, опубликованными после июня 2019 года? Я понимаю, что это большая работа, но этот тип трекера также идеально подходит для совместной работы участников. И я полагаю, что уже время, когда мы можем приступить к переименованию большего количества вещей?

Обновление OP также будет означать, что опубликованное предложение будет принято командой как стоящее.

@Anutrix «заполненный» - более

@pycbouh Также было бы неплохо связать PR по каждой проблеме, если таковая имеется. OP уже делает это, но не для комментариев под ним.

Я не знаю, поднимался ли он , но я не понимал, как часто я останавливаюсь, чтобы заглянуть в документ для этого:

• Array.remove => remove_at (например, C #) для удаления по индексу
• Array.erase => remove_value или просто remove (например, C #) для удаления по значению

(или варианты этого с erase )

Потому что сейчас erase и remove для меня означают одно и то же, за исключением того, что один по индексу, другой по значению, я все время забываю, что есть что.

Вырастила уже моя плохая. Не заметил, Github сворачивает нить, мой поиск Ctrl + F пропустил xD
Еще не в ОП

@Zylann Держите: https://github.com/godotengine/godot/issues/16863#issuecomment -441376010

Вторя Зилану, я все время забываю, что удаление выполняется по индексу ...

Перечисление ButtonList вероятно, следует переименовать в MouseButtonList поскольку это кнопки мыши.

Следует ли разделить перечисление JoystickList ? Он содержит как кнопки, так и оси, это может иметь больше смысла как JoypadButtonList и JoypadAxisList или аналогичные.

Просто вопрос, а почему бы не MouseButton ?
если кнопка == MouseButton.LEFT:
читает лучше, чем
если кнопка == MouseButtonList.LEFT:

Отличная идея. В этом случае также есть KeyList -> Key , MidiMessageList -> MidiMessage , а для джойстиков необходимо удалить List .

Я заметил, что некоторые методы / свойства используют normal_map , тогда как другие используют normalmap . Мы должны остановиться на одном из них, но, вероятно, не на обоих. Я бы предпочел normal_map , но меня тоже устраивает normalmap .

GDScript

range_lerp () = карта ()
семя = set_seed ()

map (), вероятно, зарезервирован для новых функций функционального программирования.

Vector2.tangent() описывается в документации как: Returns a perpendicular vector. , это определение orthogonal или orthonormal если возвращаемый вектор нормализован. Поскольку Vector2.tangent() возвращает ненормализованный вектор, я предлагаю переименовать его в Vector2.orthogonal() или даже в Vector2.perpendicular() если у людей есть что-то против математической номенклатуры или, возможно, даже в Vector2.normal() , но люди могут запутаться между normalized() и normal()

С моей стороны анекдотично, но я впервые искал это, мои первые поиски в документации были для _perpendicular_.

Вы также можете оставить .tangent() как псевдоним для .perpendicular() , не так ли?

Мне не нравится имя orthogonal потому что это не обычное английское слово по сравнению с другими. Раньше я не видел проблем с tangent , но я думаю, что perpendicular в любом случае лучше.

Ага, ортогональность бывает редко. Я голосую за .perpendicular (), но СОХРАНЯЯ псевдоним tangent () для compat, а также он короче.

@ Zireael07 Я бы предпочел, чтобы у нас был только один способ получить касательную. В конце концов, я не думаю, что это очень распространенная операция.

Вы удивитесь, как часто я использую его в своих скриптах procgen :)

Я не ожидал, что это вызовет споры, но я лично против сохранения Vector2.tangent() поскольку это неправильное использование обычного математического термина. Произведение Vector2.tangent() просто неверно по определению. Название этой ветки - следующее запланированное нарушение Vector2.perpendicular() .

Предложение: сделать параметр find_node() owner по умолчанию ложным.

Предложение: переименуйте методы / сигналы Tree чтобы они были менее запутанными в отношении, например, терминов / статусов «выбранный», «сфокусированный» и «ничего».

Я думаю, что Tree::ensure_cursor_is_visible вводит в заблуждение и его следует переименовать в что-то вроде ensure_focused_item_visible или ensure_selected_item_visible .

Даже ссылка на класс говорит:

Makes the currently focused cell visible.

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

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

Script::get_instance_base_type() специально возвращает собственный тип внизу. Теперь, когда мы назвали классы сценариев, имеет смысл переименовать их в get_native_type() поскольку «базой» сценария потенциально может быть имя сценария. Это заблуждение.

@willnationsdev Также есть get_class() https://github.com/godotengine/godot/issues/16863#issuecomment -491421079

@aaronfranke Ну, с get_class() он повсеместно используется для обозначения «как называется вещь, на которую я сейчас смотрю?». Итак, в случае Script я ожидал бы получить обратно "GDScript" , "CSharpScript" или что-то в этом роде. Но да, с классами, отличными от Script , это должен быть метод, который возвращает имя фактического класса скрипта, если он назван. Для этого есть даже специальный выпуск. https://github.com/godotengine/godot/issues/21789#issuecomment -618588900

Изменить: О, я думаю, если у нас есть get_class() , get_base_class() и get_native_class() , вам действительно нужно get_instance_base_type() чтобы стать get_instance_native_class() чтобы соблюдайте соглашение об именах и поясняйте, что это экземпляр, а не информация скрипта.

Я думаю, что autotile_coord (свойства и методы) TileMap следует переименовать в tile_coord или tile_coordinate потому что оба AUTO_TILE и ATLAS_TILE используйте это, и имя может ввести в заблуждение новых пользователей. Документам также потребуется обновление. Я могу внести это изменение, если нет проблем.

Рассмотрите возможность удаления аргумента new_text из LineEdit.text_changed поскольку он ведет себя так же, как LineEdit.text .

Также рассмотрите возможность добавления old_text в дополнение или вместо new_text .

Относится к https://github.com/godotengine/godot/issues/16863#issuecomment -394745886

Переименуйте " слои столкновения", " слои VisualInstance", " слой рендеринга" и т. Д. На
" группа столкновений", " группа VisualInstance", " группа рендеринга", " группа освещения"

Заблуждение о том, почему эти «слои» не складываются, возникает на каналах сообщества как часы.

Обратите внимание, что в Maya, Lumberyard и Unity они называются слоями.

То, что кто-то что-то делает, еще не означает, что это еще не вызывает
путаница и это хорошая идея.

В пн, 18 мая 2020 г., 13:09 Jummit [email protected] написал:

Обратите внимание, что в Maya, Lumberyard и Unity они называются слоями.

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

Я удивлен, что об этом еще никто не упомянул, но
Camera2D.zoom
камера уменьшается при увеличении масштаба, что не так, как работает «масштабирование», и это противоречит интуиции. Не уверен, как его переименовать, может быть, view_scale или что-то подобное.

@KoBeWi Вместо того, чтобы переименовывать zoom , разве мы не должны инвертировать его масштаб, чтобы он увеличивался при увеличении значения?

Это нарушит совместимость, как и переименование свойства. Если мы пойдем по пути «инвертировать масштаб», к сожалению, это не может быть исправлено автоматически. Тем не менее, в долгосрочной перспективе это может привести к меньшей путанице.

@Calinou @KoBeWi Есть ли

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

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

Может быть, но где провести черту с этим и чем-то вроде Node2D.get_position_2d() ?

Возможно, мы могли бы назвать класс Viewport2D, но это не потребуется, если мы не создадим Viewport3D.

@nathanfranke Я предложил этот метод, потому что по одному названию невозможно определить, 2D он или 3D, учитывая, что существует 2 типа Transform . (Пока у других участников уже есть canvas_ или mouse_ )

@Zylann Этот метод действительно очень странный. Есть свойства, называемые canvas_transform и global_canvas_transform , а описание canvas_transform таково:

Преобразование холста области просмотра, полезное для изменения положения на экране всех дочерних элементов CanvasItem. Это относительно глобального преобразования холста области просмотра.

Итак, вы ожидаете, что get_final_transform объединит оба этих преобразования. Однако, если вы посмотрите на код, на самом деле это не то, что он делает.

Код для этого - return stretch_transform * global_canvas_transform; . Я пытался выяснить, для чего нужен stretch_transform и я понятия не имею, он не отображается, и, конечно же, не устанавливается при изменении canvas_transform . Существует также метод _stretch_transform который не использует stretch_transform . Он вызывается set_size , который принимает значение, сгенерированное _stretch_transform и присваивает его stretch_transform . Также есть canvas_transform_override которых я даже не упомянул и не раскрывается, но используется внутри компании.

В конце концов, я думаю, что весь этот класс следует просмотреть. Область просмотра имеет 4 различных члена Transform2D, 4 члена Rect2 (i), 9 членов Vector2 (i) и 2 члена Transform (3D). Это уже 264 байта (с числами с плавающей запятой с одинарной точностью) только структур данных, хранящих информацию о преобразовании, если вы сложите все указатели и т.д., это, вероятно, ближе к 1 КБ. Возможно, Viewport все это и нужно, но это кажется чрезмерно сложным, и, по крайней мере, должны быть комментарии (их слишком мало в этом файле).

Следует ли удалять Node2D / Node3D to_global и to_local ? Я дал отзыв о # 38902, в котором предлагалось добавить методы, которые работают только с базисом, но с ними есть некоторые проблемы.

В демонстрационных проектах to_local нигде не используется, а $ grep -RIn "to_global" возвращает только 5 результатов, все из которых находятся в графическом интерфейсе пользователя в 3D-демонстрации, и производительность демонстрации можно улучшить, изменив это так, что он кэширует глобальное преобразование и использует xform вместо to_global .

Короче говоря, эти методы вызывают озабоченность как в том, что они используются редко, так и в том, что они поощряют написание кода, который работает плохо, поскольку он несколько раз пересчитывает глобальное преобразование.

27509

AnimationPlayer animation_started и animation_finished немного противоречат интуиции. Первая вызывается для всех анимаций в очереди, а вторая вызывается только при достижении самого конца очереди. Это явно не упоминается в документации.

Если мы хотим определить, когда заканчивается какая-либо конкретная анимация, мы должны использовать как animation_changed и animation_finished что неудобно.

Мне очень нравится предложение @txigreman из этой проблемы: мы можем использовать animation_finished всякий раз, когда заканчивается какая-либо отдельная анимация в очереди, и добавлять новый сигнал animation_all_finished (аналогично Tween ' s tween_all_completed ), который срабатывает, только когда мы достигаем конца очереди.

А как насчет animation_queue_finished и / или animation_queue_started ?

Я не могу найти его здесь, поэтому предлагаю,
find и пара findn .

образ из последней стабильной сборки 3.2.

Возможно, мы можем переименовать один, чтобы упомянуть их природу работы с чувствительностью к регистру.

Скажем, find_ignorecase вместо findn ?

@swarnimarun У нас есть много других методов без n . Если мы переименуем один из них, мы должны переименовать их все.

Эти методы ( find / findn и т. Д.) В основном делают то же самое. Мы могли бы просто добавить аргумент, должны ли они быть чувствительны к регистру или нет.

@Calinou Я бы очень предпочел, чтобы использование GDScript после отказа от него в течение нескольких месяцев как бы дало мне новый взгляд на API, я бы сказал,

Чем очевиднее, тем лучше. Запоминать API для всего сложно само по себе, немного больше подробностей в именовании функций кажется разумным изменением.

@KoBeWi может сказать по имени функции, что она делает, вместо того, чтобы помнить о добавлении другого поля или во время чтения кода (после того, как забыл / не знал об этой части API), очень ценится.

Поэтому я все равно предпочел бы другую функцию, даже если другая функция просто вызывает первую с другими аргументами или чем-то еще.

EditorInterface.get_editor_viewport() => get_editor_main_container()

Эта функция не возвращает Viewport , только Control который является центральным, содержащим редакторы 2D, 3D, скриптов и библиотеку активов. Для записи, возвращаемый узел - это даже VBoxContainer* , но он абстрагирован (но это важно знать, потому что он влияет на ваш выбор настроек).
Документ также неверен, поскольку его описание ссылается на класс Viewport . https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class -editorinterface-method-get-editor-viewport

@Zylann Должен быть get_editor_main_screen() поскольку это не контейнер, а главный экран .

@aaronfranke, который также является узлом Container , на самом деле ^^ но да ... главный экран тоже может работать

Хочу спросить: кто-нибудь отслеживает предложения в этой теме?

Например, выше (https://github.com/godotengine/godot/issues/16863#issuecomment-557657413) я предложил переименовать метод JSON.print . Было предложено несколько вариантов, но ни один из них не появился в первом посте.

Меня просто беспокоит, что полезные идеи теряются в таком количестве сообщений. :улыбка:

@dalexeev Недавно я сделал первый

У меня есть один, который потенциально исправляет некоторые ошибки в RichTextLabel . В настоящее время у нас есть bbcode_text и text , но оба используют одну и ту же структуру данных. Различаются только вызываемые методы, тогда как set_bbcode возвращается к set_text когда use_bbcode не активирован. Я удалил их в # 39148. Я добавил туда еще несколько моментов.

GetSceneInstanceLoadPlaceholder() в Node выглядит очень неправильно, во-первых, он не возвращает заполнитель, как можно предположить из названия, но логическое значение, а во-вторых, это утекает детали унаследованных реализаций в базовый класс без каких-либо реальных требований (тестирование для типа узла можно и другими способами)

RayShape → SeparationRayShape , как изначально было предложено в godotengine / godot-предложения # 711.

Как насчет того, чтобы удалить sort_custom и заставить sort использовать необязательный Callable?

Должны ли мы удалить OS.get_ticks_msec() и OS.delay_msec() в пользу OS.get_ticks_usec() и OS.delay_usec() соответственно? Это позволило бы избежать двух способов достижения одного и того же. Если вам нужно значение в миллисекундах, вы можете умножить его или разделить на 1000.

Кроме того, как GDScript, так и C ++ позволяют добавлять разделители в целочисленные литералы, что делает большие значения более удобочитаемыми.

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

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

Кроме того, как GDScript, так и C ++ позволяют добавлять разделители в целочисленные литералы, что делает большие значения более удобочитаемыми.

Если удаление произойдет, в описании get_ticks_usec() должны быть указаны разделители.

@Calinou С одной стороны, вы правы, но с другой - в большинстве случаев такой большой точности не требуется.

«Альфа-ножницы» в пространственном материале должны стать стандартным «альфа-клипом».

@Flavelius Я не часто встречал термин «альфа-клип». Я наверняка видел, что «альфа-тест» используется гораздо чаще, чем «альфа-клип» и «альфа-ножницы».

Здесь много всего, что нужно изменить! Кто-то работает над реализацией этих предложений?

@MCrafterzz Люди реквесты для переименования вещей. Это делается постепенно, а не сразу.

Текстура (Texture2D) и изображение

• get_data () в текстуре (Texture2D) должен называться get_image (), а get_data () в изображении должен называться get_bytes () для самоописания.

ИМО: get_image да, get_bytes нет.

texture.get_image().get_data()

Сетка / MeshInstance

• В Mesh вы получаете / устанавливаете материалы с помощью следующих методов:
  surface_get_material/surface_set_material
• В MeshInstance вы получаете / устанавливаете с помощью следующих методов:
  get_surface_material/set_surface_material

Полагаю, это должно быть то же название?

@Coldragon Это должно быть get_surface_material / set_surface_material и свойство surface_material .

@Coldragon Это должно быть get_surface_material / set_surface_material и свойство surface_material .

Это не "нормальный" набор / получение, у них есть индекс для целевой поверхности (это вектор внутри класса Mesh)

Array мы должны переименовать empty() в is_empty() чтобы лучше проиллюстрировать это логическим значением

String мы должны отказаться от find_last() в пользу rfind() . Не совсем переименование, но все же стоит обсудить, какое оставить.

Для одиночных чисел у нас есть stepify . Для Vector2 / Vector3 у нас есть snapped .

Они делают то же самое, векторы вызывают stepify для каждого компонента. Следует выбрать одно имя, но какое?

Опрос:: heart: = оба должны быть stepify ,: rocket: = оба должны быть snapped ,: -1: = не переименовывать.

В AABB есть intersection , а в Rect2 - clip . Они делают то же самое. Следует выбрать одно имя, но какое?

Опрос:: heart: = оба должны быть intersection ,: rocket: = оба должны быть clip ,: -1: = не переименовывать.

@aaronfranke да, я ранее предлагал имя intersection в https://github.com/godotengine/godot/issues/16863#issuecomment -449628319. Затем у нас есть intersects который можно переименовать в overlaps в Rect2 , но мы не уверены насчет AABB относительно intersects → overlaps переименовать.

Я думаю, что find_node и / или get_node следует переименовать, потому что имена вообще не указывают на различия между ними.
Поскольку find_node смотрит только на детей, возможно, find_child_node?
Я не уверен, какое было бы хорошее альтернативное имя для get_node. Моей первой мыслью было get_tree_node, поскольку он может получить узел из любого места в дереве, но его также можно использовать за пределами дерева сцены с относительными путями.

Я считаю get_node хорошим, но find_node можно переименовать в find_child

@MuffinManKen Я думаю, что get_node вполне понятно, поскольку, как вы заявили, он может извлекать любой узел в любом месте, если он связан с тем же деревом, что и данный узел, независимо от того, являются ли они частью SceneTree или нет.

@Coldragon Я не уверен, что мне нравится переименовывать find_node в find_child , так как тогда у меня создается впечатление, что он по какой-то причине работает только с прямыми дочерними элементами . Альтернативой было бы называть его find_descendant или что-то в этом роде, но это слишком многословно / сложно. Сокращать его до find() тоже не имеет смысла, поскольку тогда неясно, что мы ищем. Таким образом, я думаю, что, если не будет найдена другая альтернатива, find_node тоже следует оставить как есть. Он должен просто иметь четко задокументированные различия в поведении документации API.

В Godot 3.1 я добавил тег функции standalone который оценивается как true когда проект выполняется из двоичного файла шаблона экспорта (отладка или выпуск). Противоположным является editor , которое оценивается как true когда проект выполняется из двоичного файла редактора.

Однако со временем, я думаю, было бы лучше переименовать standalone в runner поскольку он короче и немного понятнее. Что вы думаете?

А как насчет exported или release ?

@aaronfranke exported означает, что проект был экспортирован, что не всегда так. Вы можете использовать двоичный файл шаблона экспорта для запуска проекта непосредственно из исходных файлов, если ресурсы были импортированы заранее.

Кроме того, release уже используется для двоичных файлов в режиме выпуска (в отличие от debug , который используется для двоичных файлов в режиме отладки).

runner мне не очень понятно. standalone в порядке. Его тоже можно удалить, потому что вы можете просто использовать !OS.get_feature("editor") .

Его тоже можно удалить, потому что вы можете просто использовать !OS.get_feature("editor") .

Однако это нельзя использовать для переопределения настроек проекта, поскольку там нет селектора .not . Вероятно, это возможно, если поменять местами настройку по умолчанию и ее переопределение, но это кажется немного более запутанным.

Почему бы тогда не app или game в отличие от editor ? Или это еще больше сбивает с толку? Может быть, есть более точный флаг функции для no-editor ?

@willnationsdev game подразумевает, что Godot можно использовать только для игр. Многие люди успешно используют Godot для неигровых приложений, поэтому я бы предпочел использовать более всеобъемлющий термин: слегка_smiling_face:

Кроме того, это не совсем самоочевидно: люди могут подумать, что это все еще применимо к проектам, запускаемым из редактора (в конце концов, вы запускаете «игру» из редактора). То же самое и с app .

А что насчет «независимого»?

Сб., 25 июля 2020 г., 5:49 Hugo Locurcio, [email protected]
написал:

Игра @willnationsdev https://github.com/willnationsdev подразумевает Годо
может использоваться только для игр, что оказалось не так 🙂

Кроме того, это не совсем очевидно: люди могут подумать, что это все еще
применяется к проектам, запускаемым из редактора. То же самое и с приложением.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
.

@MuffinManKen independent мне тоже не очень понятно .

Editor vs standalone - это, вероятно, стандартное именование (по крайней мере, одно, которое я вижу во многих разных движках), поэтому нет причин изобретать колесо, imho.

Get_node не ограничивается получением потомков, так что это было бы очень
вводящее в заблуждение имя. Этим двум методам нужны очень разные имена, потому что они
делать очень разные.

Сб., 25 июля 2020 г., 15:14 golddotasksquestions, <
[email protected]> написал:

Я помню, какое замешательство у меня было вначале с
find_node и get_node. Мне бы очень хотелось find_descendant и
get_descendant, так как это будет правдой и информативно @willnationsdev
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
"Многословие" может быть не всем, но имхо не совсем
проблема, так как есть автозаполнение и сокращение "$".

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
.

Я думаю, что в обоих методах Transform и Transform2D inverse и xform_inv следует переименовать / удалить, потому что то, что на самом деле делают эти методы, не соответствует ожиданиям людей. . Подробнее: https://github.com/godotengine/godot/issues/39433#issuecomment -664024521.

RayCast.cast_to следует переименовать в RayCast.segment или что-то в этом роде. Мне только что кто-то сказал, что ему потребовалось 40 минут, чтобы понять, что это свойство, а не функция. Наверное, потому что это тоже глагол.

А как насчет RayCast.target ?

@ razcore-art Недавно я ответил на вопрос, связанный с литьем лучей , и использовал слово segment чтобы описать его, так что я думаю, что это имеет смысл. Но это также можно было бы переписать как direction и length , так что на самом деле он станет чем-то ближе к лучу, а не к сегменту, говоря геометрически (или просто предоставит альтернативные свойства, которые могут сосуществовать) . Проблема в том, что нет возможности легко установить нормализованный вектор направления в инспекторе. Я написал предложение сделать его хотя бы для 2D: godotengine / godot-sizes # 397, но, возможно, это слишком надумано.

РЕДАКТИРОВАТЬ: после дальнейшего размышления, segment не будет иметь большого смысла с точки зрения RayCast node , но имеет смысл с точки зрения Physics2DDirectSpaceState.intersect_ray() .

А как насчет RayCast.target ?

@nathanfranke Я бы предположил, что целью является Node или NodePath . По крайней мере, это может быть RayCast.target_position . Может быть, RayCast.cast_position или RayCast.cast_offset . Не забывайте, что приведения лучей могут вращаться, что может сдвигать фактическое положение приведения в глобальных координатах.

PhysX API подтверждает мое представление о единичном направлении + длине для настройки лучей. 😛

Тем не менее, я склоняюсь к cast_position ... Потому что переписывание того, как работает кастинг лучей, требует дополнительных основных изменений.

@Xrayez Я бы избегал использовать слово «cast» в начале свойства, поскольку я, естественно, читал это как глагол «cast», а не существительное «cast», и поэтому в cast_position вероятно, не было бы решил исходную проблему незнания, что это свойство, а не метод (было бы легко предположить, что cast_position - это метод, приводящий к позиции). Мне нравится target_position .

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

Можно переименовать KEY_BACK в KEY_MEDIA_BACK и KEY_FORWARD в KEY_MEDIA_FORWARD . Могут быть и другие медиа-ключи, которые могут использовать префикс MEDIA .

Нам следует подумать об изменении String begins_with() на starts_with() .

Так обстоит дело в Java, C #, Python, JavaScript и т. Д.

Редактирование команды ошибок: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool , float , int - единственные типы / классы, имена которых начинаются со строчной буквы. Думаю, их следует переименовать (в GDScript) в Bool , Float , Int . Это автоматически решит проблему с неправильным выделением синтаксиса типа.

И bool , float , int следует использовать только для встроенных Python-подобных функций со страницы @GDScript (они также включают len и str ).

Обратите внимание, что ситуация аналогична с str / String : str(x) и String(x) дают тот же результат.

ДОБАВИТЬ. Это должно было выглядеть так:

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

@dalexeev Они строчные, потому что являются примитивными типами. Вы увидите это на большинстве других языков.
Такие классы, как Node являются ссылочными типами и не копируются при назначении.

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

Во всяком случае, нам следует подумать о переименовании String в string поскольку String не является изменяемым и ведет себя более похоже на int чем, скажем, Node .

Отредактируем это сейчас, так как это также относится к Vector2 , Vector3 и т. Д.

@nathanfranke В разных языках это разное. Например, в Kotlin, Haxe, Ada имена всех типов пишутся с заглавной буквы.

Более того, примитивность - понятие условное. Для меня String , Color , Vector2 и т. Д. Являются примитивными типами, тем более что они передаются по значению, а не по ссылке.

Единственное препятствие - это нарушение обратной совместимости.

поскольку String неизменяем

Удивительно, но строки в GDScript изменчивы:

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

Vector2 не является примитивом, потому что он состоит из 2 float . Однако Vector2 и float являются встроенными вариантными типами.

@Zylann Это настолько принципиальная разница, что она должна отражаться в названии типа?

(Для меня «примитивный» - это «простой», а не «цельный».)

Я не хочу интерпретировать это в свою пользу, но:

имена примитивных типов пишутся с заглавной буквы. :улыбка:

Вот термины, как я их понимаю:

| Введите имя | Примитивный тип | Тип значения | Мутабельный тип | Встроенного типа |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| int | Да | Да | N / A | Да |
| Vector2 | Нет | Да | N / A | Да |
| Узел | Нет | Нет | Да | Да |
| Строка | Нет | Нет | Нет | Да |

Тем не менее, эти имена не будут изменены. Они прекрасны как есть и знакомы программистам, владеющим разными языками. На этом мы должны закончить обсуждение, чтобы не забивать трекер бессмысленным обсуждением.

Столбец Mutable type неверен: изменяемыми являются только Object-производные, Dictionary и Array. ( Vector2 может выглядеть изменчивым, поскольку вы можете сделать vec2.x = 0 , но на самом деле это означает что-то вроде vec2 = vec2.with_x(0) )

Переименуйте ShortCut в Shortcut

Следующие методы следует изменить
Несоответствия между

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

к

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

для согласования с
а также

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

нужно исправить.

PS Я исходил из принципа «Чем меньше подобных методов, тем лучше».

@dalexeev Логические параметры часто менее читабельны, чем другие методы, поскольку true и false имеют контекста.

Да, но последовательность тоже была бы хороша. Тогда избавьтесь от логических параметров в InputEvent?

@Calinou В большинстве случаев вам не нужно проверять эхо-события.

Я не вижу в этом большой проблемы. Когда вы набираете код, появляется подсказка аргумента. При чтении кода вы можете использовать Shift + Click. Аргументы часто используемых функций легко запоминаются (например, String.split ).

Более того, в каталоге doc/classes было найдено 208 необязательных логических аргументов (это только ядро, а также 16 модулей имеют вложенный каталог doc_classes ).

AcceptDialog.xml

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

AnimatedSprite2D.xml

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

AnimationNode.xml

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

AnimationPlayer.xml

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

Animation.xml

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

Array.xml

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

AStar2D.xml

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

AStar.xml

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

Camera3D.xml

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

CanvasItem.xml

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

ClassDB.xml

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

CodeHighlighter.xml

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

Color.xml

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

Control.xml

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

CryptoKey.xml

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

Curve2D.xml

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

Curve3D.xml

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

Dictionary.xml

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

Directory.xml

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

DisplayServer.xml

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

EditorInterface.xml

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

EditorNode3DGizmoPlugin.xml

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

EditorNode3DGizmo.xml

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

EditorProperty.xml

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

Expression.xml

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

File.xml

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

Font.xml

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

GIProbe.xml

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

HTTPClient.xml

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

HTTPRequest.xml

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

ImageTexture.xml

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

Image.xml

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

ImmediateGeometry3D.xml

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

InputEvent.xml

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

Input.xml

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

InstancePlaceholder.xml

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

ItemList.xml

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

JavaScript.xml

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

JSONRPC.xml

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

JSON.xml

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

KinematicBody2D.xml

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

KinematicBody3D.xml

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

Marshalls.xml

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

Navigation2D.xml

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

Navigation3D.xml

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

NavigationServer3D.xml

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

Node2D.xml

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

Node.xml

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

Object.xml

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

OS.xml

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

PacketPeerDTLS.xml

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

PacketPeer.xml

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

PCKPacker.xml

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

PhysicsDirectSpaceState2D.xml

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

PhysicsDirectSpaceState3D.xml

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

PhysicsServer2D.xml

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

PhysicsServer3D.xml

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

PopupMenu.xml

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

ProjectSettings.xml

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

Rect2.xml

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

RenderingDevice.xml

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

RenderingServer.xml

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

ResourceLoader.xml

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

Resource.xml

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

RigidBody2D.xml

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

SceneState.xml

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

SceneTree.xml

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

ScriptCreateDialog.xml

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

Script.xml

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

Skeleton3D.xml

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

SkeletonIK3D.xml

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

StreamPeerSSL.xml

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

StreamPeer.xml

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

String.xml

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

SurfaceTool.xml

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

TextEdit.xml

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

Texture2D.xml

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

TileMap.xml

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

TileSet.xml

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

TreeItem.xml

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

UndoRedo.xml

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

Viewport.xml

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

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

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

@dalexeev, можете ли вы поместить это в спойлер, чтобы упростить нам прокрутку?

@dalexeev Во многих случаях вам нужно проверить, нажата ли клавиша, и не только если она была нажата только что. Например, скрипт для перемещения персонажа должен делать это с помощью WASD или клавиш со стрелками. Обработка входных данных потребуется практически в каждой игре, поэтому я не думаю, что иметь два метода для этих целей будет бесполезным.

При чтении кода вы можете использовать Shift + Click.

Нет, если вы просматриваете различия на GitHub. Если код требует, чтобы IDE была читабельной, это не лучший код.

@aaronfranke Для остальных 207 случаев вы также предлагаете создать отдельные функции? Если нет, то этот аргумент неубедителен. Кроме того, я писал выше, что если можно указать имя параметра, то он станет читаемым без IDE.

Есть много случаев, когда вам нужно проверить, нажата ли клавиша, и не только, если она была нажата только что.

Часто, но не чаще, чем без эха.

Наличие трех методов ( is_action_just_pressed , is_action_just_released , is_action_pressed ) сбивает с толку, потому что вы ожидаете, что будет метод is_action_released .

ДОБАВИТЬ. Какой вариант проще хотя бы визуально?

is_action_released можно получить с помощью not is_action_pressed . Это не относится к методам just .

Как упоминалось выше, следует избегать сырых булл. Флаг типа INPUT_ALLOW_ECHO / INPUT_NO_ECHO был бы намного лучше, чем bool.

@dalexeev Это только внесет путаницу. is_action_pressed() и эхо - это разные вещи. Вы можете сами убедиться, что эхо-события принимаются с небольшой задержкой после первого нажатия, в то время как is_action_pressed() не имеет задержки.

@KoBeWi Возможно, ты прав и

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

следует изменить на

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

поскольку это не согласуется с

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

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

@dalexeev То, что вы предлагаете, неверно. Когда мы говорим об эхо-событиях, мы говорим о повторяющихся событиях клавиатуры при нажатии клавиши, использование этого термина здесь не имеет особого смысла, поскольку система действий не зависит от события напрямую, его состояние обновляется покадрово. Кроме того, действия также могут работать с другими устройствами, такими как контроллеры или кнопки мыши, где событие «эхо» не существует.

Get_children () TreeItem возвращает только первого дочернего элемента, а не всех дочерних элементов, таких как имя (или описание в документации).

[Редактировать]
Nvm docs. Описание метода обновлено в мастере, извините.

Я рекомендую local_to_scene ресурса local_to_instance или unique_per_instance . «Local to Scene» обозначает поведение как локальное для сцены, когда оно действительно для каждого экземпляра сцены.

Переименуйте Image.load() → Image.load_from_file() .

1. Помогает устранить возможную путаницу с файлами load("image.png") через код, см. Изменения документации на # 42412.
2. Image.load() больше не будет выделяться как встроенное имя GDScript: # 28866.
3. Соответствует формату изображения Image.load_*_from_buffer() . Связанные с буфером методы могут быть потенциально объединены в один и тот же интерфейс, чтобы предотвратить раздувание API, но это другая тема для обсуждения.

@Xrayez Может также стоить удалить load в GDScript: https://github.com/godotengine/godot-proposals/issues/263

Переменная registering_order и связанный с ней метод set_registering_order в ProjectSettings не используются.

RandomNumberGenerator следует переименовать в Random а глобальные случайные функции, такие как randf и rand_range следует исключить или удалить.

Я вижу возможные проблемы, когда вызывается ненадежная функция, когда задано случайное начальное число.

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

глобальные случайные функции, такие как randf и rand_range следует исключить или удалить.

Обсуждается в рамках godotengine / godot-questions # 1590.

Я бы предпочел, чтобы эти базовые случайные методы были в глобальном масштабе для целей доступности и прототипирования, по крайней мере, некоторые из них. Но seed() и rand_seed() наверняка можно удалить.

Похоже, что FuncRef стало избыточным после добавления Callable .

Я обнаружил в Инспекторе методы property_can_revert и property_get_revert и сообщил о них в # 43078. Однако я думаю, что они должны быть переименованы с подчеркиванием в начале, чтобы следовать соглашениям _get , _set и _get_property_list .

EditorImportPlugin и EditorExportPlugin выглядят связанными, однако один касается импорта ресурсов, а другой - экспорта проекта. Я предлагаю переименовать EditorImportPlugin в EditorResourceImportPlugin или что-то в этом роде.

Изменить: и EditorPlugin.add_import_plugin необходимо переименовать.

Почему не ResourceImportPlugin ? Многие (большинство?) Классов редакторов уже не содержат слова «редактор», например SceneTreeDock или все прочие анимационные материалы.

Перечисление Tracking_status в ARVRInterface следует переименовать в TrackingStatus , чтобы оно соответствовало стилям других имен перечислений.

Если посмотреть на ARVRInterface выше, качество имен в целом довольно низкое. Вот и предлагаемые мной переименования:

• ar_is_anchor_detection_enabled → anchor_detection_enabled (свойство)
• interface_is_initialized → initialized (свойство, в дальнейшем можно переписать на enabled , так как оно имеет сеттер)
• interface_is_primary → primary (свойство)
• get_render_targetsize() → get_render_target_size() (метод)
• uninitialize() → finalize() (метод)

В противном случае документация неверна. 🙂

Обратите внимание, что я вообще не использовал этот класс, но эти имена выглядят странно, просто взглянув на класс.

Стоит ли переименовать Control.MOUSE_FILTER_PASS в Control.MOUSE_FILTER_PASSTHROUGH ? Это сделало бы более очевидным, что событие будет передано через узел Control узлам, расположенным под ним. Однако я не уверен, стоит ли его переименовывать.

@Calinou Я не думаю, что это будет больно, поэтому я поддержу. Как вы упомянули, это изменение сделало бы более очевидным с первого взгляда, что делает этот режим фильтра мыши.

@Calinou Я нахожу нынешнее поведение необычным. Эта настройка сцены дает "Click Child2, Click Scene"

(Обратите внимание, что все настроены на Pass)

: smile: Предложение A : Возможно что-то вроде Control.MOUSE_FILTER_PASSPARENTS для текущего поведения, поскольку события ввода, кажется, отправляются только родителям.

: rocket: Предложение Б : замените константы на эти:

• STOP: Current Behavior - принять событие и остановить все распространение
• PASS_PARENT: то же поведение, что и PASS в настоящее время
• PASS_ALL: IGNORE, но принимает события
• IGNORE: Current Behavior - Не принимать событие, но продолжать распространять

: eyes: Предложение C : Независимо от того, принимает ли узел входные данные графического интерфейса, на самом деле не имеет значения, так как можно просто не подключать какие-либо сигналы (или использовать логический флаг). Мы можем изменить параметр на Control.propagation_mode и получить следующие константы:

• НИКТО
• РОДИТЕЛЬ
• ВСЕ

На мой взгляд, это выглядело бы намного чище.

Это не подлежит переименованию и должно обсуждаться как предложение.

Почему все эти переименования такие длинные? Вы меняете что-то простое и короткое на действительно длинное.

Вы изменяете clip на intersection вдвое дольше, чем нужно набирать.
Вы также меняете Control.MOUSE_FILTER_PASS на Control.MOUSE_FILTER_PASSTHROUGH
так далее

Я бы предпочел более простые и короткие, менее подробные изменения. Это имя функции, а не описание функции.

Я бы предпочел более простые и короткие, менее подробные изменения. Это имя функции, а не описание функции.

Однако имя должно быть описательным. Также длина не имеет значения, если вы воспользуетесь автозаполнением (встроенным в редактор Godot).

Я упоминал об этом однажды в IRC и не получил ответа, но в TextureRect есть режим растяжения, называемый «Масштабировать при расширении (совместимость)». Это похоже на то, что можно удалить.

«Менее подробный» определенно не входит в меню, если мы хотим иметь надежную кодовую базу для наших проектов Godot. Современные инструменты кодирования предоставляют автозаполнение и другие интеллектуальные функции, которые позволяют быстро печатать, даже если имя длинное. Кроме того, если вы читаете аргументы в пользу этих изменений, есть цель сделать эти функции менее неоднозначными для разработчиков, использующих их. Краткое название может показаться приятным, но запутанным и менее заметным.

И всегда помните: набор кода - это быстрая часть разработки программного обеспечения. Гораздо важнее потом прочитать и понять код. Это как зачать и растить ребенка соответственно.

Я не согласен с вами обоими. Я пользуюсь Godot и использую Godot специально потому, что GDScript краток и быстро пишет. Если вы сделаете их вдвое длиннее, то преимущество в скорости будет потеряно, так как я буду вынужден писать вдвое больше, и мне придется прокручивать вдвое дальше, чтобы увидеть всю строку кода по горизонтали.

Когда вы пишете код, вам не нужно вводить невероятно длинные имена функций или переменных. Некоторые из этих предлагаемых изменений добавляют очень длинные имена функций и переменных для «ясности» за счет всего остального. Если у вас есть сомнения, вы можете прочитать встроенную справку. Плюс программирование - это изучение API. Вы всегда будете искать функцию при первом использовании, независимо от имени. Взять printf на C кратко и просто. В Godot вы бы назвали это send_formatted_string_to_standard_out. Не только вы заставляете всех заново изучать api, но некоторые из этих изменений даже не имеют единого видения. Мне кажется, что собралась целая группа людей, и каждый поменял одну часть двигателя.

Возьмем, к примеру, массив
remove -> remove_at Что здесь добавляет _at? У вас уже есть remove_value. Что еще можно убрать?
erase -> remove_value Все еще недостаточно ясно. Из документов «Удаляет первое вхождение значения из массива». Также люди могут подумать, что вы можете удалить одно значение из всего массива. Для ясности на самом деле это должно быть remove_first_occurance_of_value потому что это то, что функция на самом деле делает. Таким образом, вы сделали функцию длиннее и в равной степени запутанной, только дольше.

У вас есть remove и erase две разные функции, но вы превращаете их обе в один и тот же вариант remove с дополнительными буквами. Но они работают по-разному. Remove удаляет из определенного индекса, а as erase удаляет первый экземпляр найденного значения.

Это нормально, но они не особо полезны, кроме как заставлять людей обновлять свой код.
инвертировать -> инвертировать
дубликат -> клон
пустой -> is_empty

Если не сломано, не чините.

@CarlGustavAlbertDwarfsteinYung, но вы не собираетесь печатать вдвое больше. После первых трех букв, которые вы вводите, сработает автозаполнение, и вы выберете то, что вам нужно, а не вводите целые слова.

Что касается других имен, например, когда вы смотрите на empty -> is_empty change необходимо для пояснения того, что он делает. Когда вы смотрите на empty можете ли вы сказать, что это метод, который что-то очищает, это проверка книги, если что-то пусто, что-то еще? С помощью is_empty вы можете сразу увидеть, что это логическое значение, которое истинно, если что-то пусто, и ложно, когда это не так. Вы должны знать, что делают функция или переменные, просто прочитав их имя. Вы не можете сделать это с таким именем, как empty

@ Feniks-Gaming Я могу вам сказать, что empty или is_empty одинаково сбивают с толку, только один длиннее другого.

@CarlGustavAlbertDwarfsteinYung empty может быть действием, если его читать как глагол. is_empty определенно качество. Конечно, это заблуждение может зависеть от вашего уровня английского.

Кроме того, даже если функция была названа send_formatted_string_to_standard_out в современном редакторе кода, ее можно ввести как sfstso или любую другую комбинацию промежуточных букв, если вы того пожелаете, и автозаполнение даст вам единственный вариант.

@pycbouh Сколько лет люди используют этот движок? И я не слышал, чтобы кто-то подошел ко мне и сказал, что вы знаете, в чем самая большая проблема с этим двигателем. Дело в том, что у массивов empty вместо is_empty .

Вы, ребята, сидите здесь и чините вещи, которые никто не хотел и не просил. Да, формулировка сбивает с толку, но на самом деле это не проблема и никогда не было проблемой с тех пор, как я начал использовать этот движок в 2015 году. Некоторые из предложенных изменений можно только приветствовать, и, честно говоря, я использую is_. Пусто. Но некоторые изменения слишком долгие и столь же запутанные. Я конкретно говорил не обо всех этих изменениях.

Само существование этого мегапотока свидетельствует о том, что люди об этом просят. Эти проблемы могут быть незначительными для вас или кого-то еще, но у людей действительно есть проблемы с пониманием API из-за плохого именования. И это тип проблем, которые собираются в этом выпуске. Что касается значимости этих изменений в целом, хотите верьте, хотите нет, но их отслеживание и реализация не отнимают время у других разработчиков.

И посмотрите на пример, который вы привели и пытались объяснить:

Remove удаляет из определенного индекса, а as erase удаляет первый экземпляр найденного значения.

Вы пишете это и не видите причин для улучшения именования, чтобы оно было хотя бы немного более понятным для всех нынешних и будущих пользователей Godot?

@pycbouh А на самом деле я даже привел пример массива remove_at и remove_value . remove_value - это не то же самое, что описание стирания, и по-прежнему сбивает с толку. Удалить значение откуда? Удалить значение с конца, продолжить с начала? Удалить все вхождения значения из массива?

если вам действительно нужно что-то изменить, используйте remove и remove_first_occurence что делает его кратким и описательным.

@pycbouh Я не прошу об этом. Эта ветка существует потому, что некоторые люди чрезмерно занимаются разработкой и исправлением вещей, которые не нарушают классический стиль программирования. А как насчет будущих пользователей? Что насчет них? Когда-то я был будущим пользователем и изучил api. У меня не было проблем с именованием функций. 50% комментариев - это люди, не согласные с предлагаемыми изменениями. Похоже, что большинство этих изменений вызвано небольшим количеством членов сообщества, которые навязывают эти изменения всем. Можем ли мы проголосовать за предложенные изменения?

Фактически это предложение. Любые изменения в именовании API должны включать мнения участников / жертвователей / пользователей. Если они все согласны, то я тоже согласен. Проведите опросы и посмотрите, что у всех на уме. Не пытайтесь угадать, чего хотят другие люди. То, что хорошо для вас, может не подойти кому-то другому.

Я против примерно 50% предложенных здесь изменений из того, что я видел.

50% комментариев - это люди, не согласные с предлагаемыми изменениями.

Можем ли мы оставить сфабрикованную статистику у дверей, пожалуйста?

Можем ли мы проголосовать за предложенные изменения?

Вот для чего нужны обсуждения и отзывы.

Я против примерно 50% предложенных здесь изменений из того, что я видел.

Если вы против них только потому, что «я научился этому таким образом, поэтому я хочу, чтобы все после меня страдали так же», то это недействительная критика предложения и будет проигнорирована.

То, что хорошо для вас, может не подойти кому-то другому.

То же.

Можем ли мы оставить сфабрикованную статистику у дверей, пожалуйста?

Нравится это утверждение обо всем сообществе?

Эти проблемы могут быть незначительными для вас или кого-то еще, но у людей действительно есть проблемы с пониманием API из-за плохого именования.

Как узнать, с чем у людей проблемы? Вы их спрашивали? Был ли по этому поводу опрос, исследование или анкета? Как вы узнали об этой информации?

Я один из таких пользователей начал с нуля и изучил API. Проблем с наименованием не было. У всех API есть странные соглашения об именах. Все функции должны быть краткими, чтобы вы могли писать их в коде.

@pycbouh Если вы пытаетесь убедить меня, что все предложения по именованию здесь хороши, мне придется с уважением не согласиться с вами. Это ветка, в которой обсуждаются изменения, и я здесь, чтобы сказать, что некоторые из предлагаемых изменений не только не являются необходимыми / или запрашиваются, но просто более длинными и столь же запутанными. Некоторые действительно хороши и приветствуются. Давайте не будем все массово переименовывать все только потому, что некоторые люди, такие как вы, думают, что у всего сообщества проблемы с именами API. У меня нет и никогда не было, и я начинал как новичок. И я знаю горстку других людей, которые тоже этого не делают. Я считаю, что некоторые из этих изменений значительны и должны быть рассмотрены всем сообществом или, по крайней мере, участниками до полного выпуска.

Как узнать, с чем у людей проблемы? Вы их спрашивали?

Большинство записей в этой ветке создаются людьми, которые приходят с проблемами, будь то здесь, на GitHub (и в этих случаях проблемы связаны) или через другие сообщества или личные каналы. Не думайте, что мы просто сидим здесь, облизывая свои личные части, потому что нам нечего делать, кроме как обдумывать, какую еще функцию или свойство нужно переименовать в движке.

Кроме того, многие из предложенных здесь изменений даже не были реализованы, не было никаких PR или какой-либо другой деятельности. Они перечислены и все. Следите за PR, и если появится кто-то, кто вас обидит, не стесняйтесь его комментировать. После этого премьер-министр Godot должен утвердить и объединить изменения. Будьте конструктивны, и вы можете предотвратить некоторые нежелательные изменения, но не забывайте, что вы сами однажды сказали:

То, что хорошо для вас, может не подойти кому-то другому.

Таким образом, даже если у вас не было проблем с API до этого момента, это не значит, что у других не было ни того, ни другого или что у них не будет проблем в будущем.

У всех API есть странные соглашения об именах.

Это хорошо, если есть о чем говорить. Но некоторые API-интерфейсы в Godot были названы задолго до того, как он стал открытым исходным кодом и, возможно, не так продуман, как можно было бы надеяться. Еще раз прошу вас не предполагать, что люди здесь предлагают изменения, черт возьми.

Пожалуйста, не ведите здесь подобных дискуссий. Если вы хотите обсудить конкретные изменения API, это нормально, но общие утверждения, которые вам не нравятся, приведенные здесь предложения бесполезны.

Основные разработчики рассмотрят каждое из этих предложений одно за другим. Вполне вероятно, что многие в конечном итоге не будут приняты.

Временно блокируется, разблокируется позже.

Можно ли добавить в список следующие пункты?

• AnimationPlayer : переименовать stop() в pause() (https://github.com/godotengine/godot/issues/16863#issuecomment-562363660, godotengine / godot-предложения # 287)
• AnimatedSprite : переименовать stop() в pause() (# 31168) (уже добавлено)
• AnimatedSprite3D : переименовать stop() в pause() (# 31168) (уже добавлено)
• Tween : переименовать stop() в pause() , stop_all() в pause_all() (PR # 41794, # 43442)

Анимация: переименуйте stop () в pause (), stop_all () в pause_all () (# 43442)

Это покрывается # 41794

@ opl- это тоже обсуждается здесь: https://github.com/godotengine/godot-proposals/issues/287

Несколько переименований, которые могут прояснить, что делают эти функции ГСЧ с глобальной областью видимости:

• seed() -> set_seed() (возможно, добавьте get_seed() чтобы соответствовать RandomNumberGenerator) - в настоящее время не ясно, является ли это функцией установки.
• rand_seed() -> rand_from_seed() - в настоящее время это звучит так, как будто это может рандомизировать начальное число или что-то в этом роде, когда оно фактически дает случайное число на основе предоставленного начального числа.

rand_seed () -> rand_from_seed () - в настоящее время похоже, что он может рандомизировать семя или что-то в этом роде, когда на самом деле выдает случайное число на основе предоставленного семени.

За исключением того, что он рандомизирует семя. Прочтите документацию.

rand_seed () -> rand_from_seed () - в настоящее время похоже, что он может рандомизировать семя или что-то в этом роде, когда на самом деле выдает случайное число на основе предоставленного семени.

За исключением того, что он рандомизирует семя. Прочтите документацию.

Извините. Я имел в виду, что это звучит так, будто это только рандомизирует семя. Может быть, это должно быть rand_int_from_seed() , поскольку оно возвращает int? Фактически, в документации не указывается, какой тип он возвращает, а упоминается только «Случайное… число». Это int?

Значит, он генерирует новое семя на основе семени, которое вы ему передаете, а затем генерирует новое число на основе этого нового семени? Не уверен насчет переименования, но описание может быть немного переработано, если это то, что происходит.

Если это так, похоже, этот метод следует разделить на 2 меньших метода, которые будут делать что-то одно, а не переименовывать

Control :: pending_resize

Не используется.

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

Теперь я понимаю, что этот метод в основном эквивалентен GDScript is (который был extends btw), но C ++ требует большей ясности.

Путаницы я столкнулся проверяют ли конкретный объект существующего типа (без наследования):

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

Базовая реализация повсюду использует «наследуемые» макросы / шаблоны, поэтому для меня имеет смысл переименовать это в inherits_class .

См. Также https://github.com/godotengine/godot/issues/21461#issuecomment -416155187:

get_class() и is_class() меня вообще сбивают с толку