Muito entediante para mim, mas boa sorte para quem conserta instance como instantiate quando usado como verbo.

16116

Sprite.set_region (val) -> Sprite.set_region_enabled (val)
Sprite.is_region () -> Sprite.is_region_enabled ()

TileMap.set_y_sort_mode (val) -> TileMap.set_y_sort_enabled (val)
TileMap.is_y_sort_mode_enabled () -> TileMap.is_y_sort_enabled ()

rect_min_size
Control.set_custom_minimum_size (valor) -> Control.set_rect_min_size (valor)
Control.get_custom_minimum_size () -> Control.get_rect_min_size

Existem muitos mais na classe Control, o get / set deve ter o mesmo nome da variável, é irritante verificar os docks toda vez que você sabe o nome da variável.

A classe TileMap tem vários métodos getter e setter que não concordam com suas respectivas propriedades. Na verdade, eu sugiro renomear a maioria dos getters e setters nessa classe, para que eles concordem com suas propriedades e também com a nomenclatura em outras classes.

Animation.track_remove_key_at_position deve ser
Animation.track_remove_key_at_time

Métodos

• OS : execute deve ser dividido em dois métodos diferentes, um bloqueador e outro não bloqueador.
  por exemplo, nomes: execute / exec_process (bloqueio) e spawn_process (não bloqueio) # 19302

LineEdit tem um parâmetro new_text em "text_changed", mas o TextEdit não.

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

Gostaria que VBoxContainer / HBoxContainer / GridContainer fosse renomeado para VBox / HBox / Grid simples ...

E mais tarde ele será renomeado novamente porque é muito curto como pos-> position: D

Eles são um pouco longos, você está certo.

Percebi que Godot atualmente tem duas convenções de nomenclatura diferentes em seus nomes de métodos.

Às vezes, segue uma convenção comum que pode ser encontrada em APIs de linguagens como C # ou Java, como [action][object]() form: ie)

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

No entanto, em outros lugares, segue uma convenção diferente de [prefix][action][object]() , como:

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

Eles são apenas alguns exemplos entre muitos.

Se pudermos fazer alterações radicais de quebra de compatibilidade em algum momento no futuro, gostaria de ver que eles podem ser renomeados para seguir uma convenção de nomenclatura única e bem definida (espero que a primeira, já que é mais usada dentro e fora de Godot).

No entanto, em outros lugares, segue uma convenção diferente de [prefix][action][object]() , como:

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

Não verifiquei novamente todos os usos, mas pelo que vi esse estilo de nomenclatura de método, embora um pouco estranho, também segue uma convenção específica. Por exemplo, os métodos shape_owner_get :

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

O "prefixo" se refere ao primeiro argumento, e a parte após get é o que você realmente obterá nesse prefixo. Por exemplo, shape_owner_get_shape_index(owner_id, shape_id) é conceitualmente semelhante a get_shape_owner(owner_id)->get_shape_index(shape_id) , mas não há ShapeOwner exposto à API de script, daí este "atalho".

Mesma história para os métodos surface_get :

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

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

Ou os métodos *node_get em 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">

Eu atualizei o OP com a maioria das sugestões dadas até agora.

Gostaria que VBoxContainer / HBoxContainer / GridContainer fosse renomeado para VBox / HBox / Grid simples

Não estou convencido, em Godot tentamos dar nomes explícitos a tudo e, por exemplo, Grid não me diz que é um Container. Para VBox e HBox pode-se argumentar que as caixas são contêineres por definição, mas como temos BoxContainer que não é o mesmo que Container , acho que verbosidade ainda é garantida.

LineEdit tem um parâmetro new_text em "text_changed", mas o TextEdit não.

Não acho que seria útil adicionar new_text ao TextEdit. No LineEdit, ele simplesmente contém todo o texto do LineEdit, não o texto que mudou, então eu até diria que ele não deveria estar lá no text_changed do LineEdit. No entanto, é mais comum que você queira usar o texto completo de um LineEdit na entrada do que fazer coisas com o texto completo de um TextEdit de várias linhas quando um novo caractere é pressionado.

@ akien-mga

Não verifiquei todos os usos, mas pelo que vi este estilo de nomenclatura de método, embora um pouco estranho, também segue uma convenção específica

Estou ciente do fato de que é uma convenção de nomenclatura própria. Mas ainda não é algo comumente usado fora de Godot, e também um pouco confuso porque às vezes a mesma palavra como BlendShape é usada em métodos que seguem duas convenções de nomenclatura diferentes.

Pessoalmente, gostaria de ver todos eles renomeados para GetPrefix* e SetPrefix* para consistência, mas talvez outras pessoas possam ter opiniões diferentes sobre isso.

Os métodos mudaram em # 16757. A ordem dos argumentos faz mais sentido, mas quebra a compatibilidade da API entre 3.0 e 3.1 (# 19648).

Vou aumentar # 9128 novamente: translation em 3D vs position em 2D é uma diferença estranha.
Foi criado muito antes de 3.0, mas foi fechado depois que 3.0 saiu devido ao ... 3.0 estar fora.

OS.execute deve usar posix_spawn .

Outro pode ser renomear "margem" para "deslocamento" para os nós de controle.
Uma vez que as margens são negativas no lado direito, isso engana as pessoas, especialmente ao comparar com caixas de estilo

@groud Acho que offset é muito genérico, as margens costumavam ser a palavra correta porque não eram negativamente orientadas no lado direito quando introduzidas pela primeira vez

@groud, acho que offset é muito genérico, margens eram um bom termo (e não eram negativos quando introduzidos pela primeira vez)

Bem, a margem é enganosa agora que eles são negativos. O deslocamento é genérico, mas faz mais sentido. Não acho que seja um problema que eles sejam genéricos, uma vez que está no contexto de nós de controle.
De qualquer forma estou aberto a sugestões melhores. Eu só queria largar essa ideia aqui, uma vez que essa mudança de nome de propriedade já foi sugerida. Veja aqui por exemplo.

O tamanho das caixas / cubos é nomeado de forma inconsistente.
BoxShape para colisões usa extensões.
CubeMesh tem uma propriedade de tamanho com x, y e z, que são cada metade das extensões.
CSGBox tem uma propriedade Width, Height e Depth que são definidas como o tamanho x, y e z em CubeMesh.

Além da propriedade de tamanho, às vezes "Cube" é usado e às vezes "Caixa" é usado. Faria sentido usar "Box" para tudo, uma vez que x, y e z para CubeMesh podem ser configurados independentemente e, portanto, também é uma caixa.

Uma vez que temos, por exemplo, HTML5 e UWP como destinos, que não são exatamente sistemas operacionais, proponho renomear o sistema operacional para Plataforma (PlatformWindows, PlatformUnix, ...).
Faz sentido com a divisão OS / Display também.

Deste # 20228, Label.clip_text não é mais necessário. Acredito que seja o mesmo para Button.clip_text.

Camera2D atualmente tem duas propriedades diferentes, ambas chamadas offset (deslocamento regular e aquele dividido em V e H) que são duas coisas totalmente diferentes, isso é realmente confuso.

Métodos

- Dictionary : erase_checked deve ser removido (este método não é exposto a scripts).
- Dictionary : erase deve ser alterado para retornar bool para determinar se o par com a chave especificada foi removido ou não (ver erase_checked implementação).

20945

@neikeq Isso poderia ser feito agora IMO, mudando Dictionary.erase 's valor de retorno de void a bool não deve quebrar qualquer projeto.

@ akien-mga, mas quebraria a compatibilidade da API GDNative, não é?

@ akien-mga Isso não quebraria a compatibilidade avançada? Temos permissão para fazer alterações que potencialmente fazem com que os scripts 3.1 não funcionem em versões mais antigas como a 3.0?

@neikeq Sim, os scripts 3.1 já são incompatíveis com 3.0 ( class_name , toneladas de alterações de API com novos parâmetros opcionais ou propriedades / métodos totalmente novos, novas classes, etc.). Nós apenas cuidamos da compatibilidade com versões anteriores, não com versões anteriores.

Oh, eu vejo! Se for esse o caso, farei essas alterações agora.

Se eu puder ter um adicionado à lista, os nós de controle LineEdit e TextEdit realmente se beneficiariam de ter APIs consistentes entre si para que possam ser usados ​​(principalmente) de forma intercambiável. No momento, parece uma bagunça tentar trabalhar com eles juntos, a ponto de olhar para um nó me deixar confuso sobre o outro.

@ eska014 Além disso, a opção scons já é platform . Faz sentido ser consistente.

As configurações do projeto display/window/size/test_width e test_height devem ser renomeadas para window_width e window_height . Também devemos considerar renomear as configurações width e height , talvez render_width e render_height .

As propriedades de perto e de longe da câmera têm nomes diferentes de seus setters / getters (por exemplo, set_znear / set_zfar). Isso deve ser alterado?

znear e zfar são confusos. Não tem nada a ver com o eixo Z no espaço mundial. Ele poderia ser alterado para clip_near e clip_far já que eles controlam os planos de recorte, ou apenas near e far .

Sim, existem duas maneiras de resolver esse problema.

Devemos eliminar (ou discutir seriamente) as extensões de recursos binários. (RES_BASE_EXTENSION)

gdscript_function.cpp e gdscript_functions.cpp têm nomes muito parecidos, eu sempre os confundo. Vale a pena renomear? @vnen

Mudei https://github.com/godotengine/godot/pull/21425 para renomear "decimais" para "step_decimals", mas mantive "decimais" como um alias. Supondo que esteja mesclado, podemos remover "decimais" na próxima quebra de compatibilidade, se não, apenas renomeando.

@mysticfall Na minha opinião, é melhor não ter a palavra "get" nos nomes dos métodos quando desnecessário.

Às vezes, você deseja que uma propriedade possa ser obtida e definida, mas controlar o acesso. Em C #, as propriedades permitem que você faça isso e controle o acesso apenas lendo e atribuindo como se fosse um campo, o que é bom.

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

No entanto, em GDScript, as propriedades não são uma coisa (?). Também poderíamos ter um nome de método sem a palavra get. A maioria dos métodos retorna algo, então é melhor ter um get-ness implícito do que set-ness: como o GDScript tem propriedades, sugiro usá-los com mais frequência. Observe que não consegui encontrar nenhuma documentação sobre isso. Eu encontrei documentação sobre como fazer isso dentro do GDScript com setget mas que tal adicionar via C ++?

Resumindo, concordo que não é bom ter "get" em lugares inconsistentes, mas a solução ideal na minha opinião não é GDScript , ou poderíamos remover "get" e manter "set" .

@aaronfranke GDScript tem propriedades de certa forma, uma vez que classes de mecanismo podem definir um getter e setter (ou apenas um getter) e expor ao GDScript como propriedades. Dito isso, sou contra a remoção de get e set dos métodos porque 1) torna o nome mais claro e 2) faz uma distinção entre getter e setter. Por exemplo, Mesh.SurfaceFormat() soa como um método que "formata a superfície", e não um que "obtém o formato". Além disso, a maioria (senão todos) deles podem ser ignorados e usados ​​como propriedades de qualquer maneira.

Agora, eu não me importo muito com gdscript_function.cpp e gdscript_functions.cpp . Um tem a classe GDScriptFunction, o outro contém a definição das funções GDScript, está sempre claro para mim qual é qual (embora esteja acostumado com isso). Também não é uma alteração significativa, por isso não precisa estar aqui.

Sim, GDScript tem propriedades. As propriedades C # são geradas a partir do ClassDB, que é de onde o GDScript as obtém.

Existem alguns métodos para RigidBody e suas classes relacionadas cujos parâmetros devem ser trocados para consistência:

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

Lista de classes e métodos

@TGRCdev Eu preferiria muitíssimo mudar apply_impulse para (forçar, posição) ao invés de mudar add_force para (posição, força). A posição da força é um parâmetro opcional, por isso deve ir no final. Mas todas as forças e impulsos devem ter um vetor de força.

@aaronfranke Fair point. Nesse caso, a lista de trocas necessárias é:

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

@aaronfranke Eu concordo que usar Get- ou Set- prefixos é uma espécie de 'Javaismo' que é melhor ser evitado em C #.

Minha principal preocupação era o uso de 'prefixo de domínio' como no caso de shape_owner_get_shape ou node_get_input_count , então se pudermos reimplementá-los como propriedades C # adequadas sem Get- ou Set- Prefixos

Por outro lado, sempre achei um tanto estranho que as propriedades na API C # de Godot tenham um conjunto correspondente de getters e setters, como, por exemplo, Node.Name e Node.GetName() / Node.SetName() .

Parece bastante redundante para mim, mas se houver alguma razão para mantermos tal convenção, suponho que receberíamos NodeInputCount e GetNodeInputCount() / SetNodeInputCount() qualquer maneira, se formos para renomear node_get_input_count conforme sugerido.

Pessoal, por favor, mantenham as discussões sobre a API C # e convenções usuais fora deste assunto, que é focado na API Godot. A API Godot (C ++, C e GDScript) não será adaptada para o bem do C #, a menos que também seja uma melhoria para outras linguagens.

@ akien-mga Não acho que seja específico do C # discutir se node_get_input_count poderia ser renomeado para algo como get_node_input_count .

Não, quero dizer qualquer coisa específica de C # não deve estar neste problema. Pode haver outro problema para quebras de compatibilidade específicas do C #, se necessário (embora já existam vários desses IINM).

Que tal renomear Spatial para Node3D? Sempre achei estranho.

@KoBeWi O esquema de nomenclatura que Godot usa atualmente é "Thing2D" para coisas 2D e apenas "Coisa" para coisas 3D, então é bastante consistente com o resto do código 2D. Claro, então, a coisa lógica a chamar de "Espacial" seria "Nó" seguindo o padrão de remoção de "2D", mas esse nome já está sendo usado, é claro.

O esquema de nomenclatura que Godot usa atualmente é "Thing2D" para coisas 2D e apenas "Coisa" para coisas 3D

Então, talvez mude tudo 3D para "Thing3D"? Isso também passou pela minha cabeça, mas soa como um exagero.
De qualquer forma, acabei de sugerir. Não que seja muito importante. Além disso, Spatial2D é ainda pior do que Spatial.

Portanto, String.right () retorna n caracteres corretos de uma determinada posição. Não seria mais intuitivo se ele retornasse apenas n caracteres contando a partir da direita?

"abcdef".right(2)
Em vez de "cdef", retornaria "ef". IMO, seria melhor.

Eu esperava o mesmo.

Python tem o mesmo método que a maioria dos usuários gosta para comparar GDScript com Python. Provavelmente confundiria ainda mais mudá-lo.

@KoBeWi eu concordo. Não vejo diferença entre a implementação atual e a substring.

O Godot substr força você a indicar o tamanho da string se você quiser tudo à direita.

@Zylann A maioria das implementações permite omitir o segundo parâmetro. Eu consideraria isso uma questão do lado de Godot. Além disso, prefiro que substr torne o segundo parâmetro opcional do que um novo método com um nome diferente.

@Zylann @neikeq Este é um resultado infeliz de ter métodos não sobrecarregáveis, não há como ter especificação de comprimento e nenhuma especificação de comprimento.

@aaronfranke Hum, mas os argumentos padrão existem. 0 ou -1 pode contar como nenhum comprimento especificado.

Precisa remover get_selected_id() de OptionButton atualmente ele sempre retorna -1. Depois que https://github.com/godotengine/godot/pull/21837 for mesclado, get_selected_id() retornará o mesmo que get_selected() .

Existem muitos métodos de interpolação que sempre retornam verdadeiros, eles provavelmente deveriam ser invalidados.

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

O nó Tree tem uma função get_selected() parece retornar o TreeItem focalizado. Pode valer a pena renomeá-lo para algo como get_active() , uma vez que o foco e a seleção são coisas diferentes.

load_from_globals() no InputMap deve ser load_from_project_settings() .

Vou adicionar uma: tada: reação a todas as sugestões que foram integradas ao OP, para ter uma melhor visão geral.

global_rotate deve ser renomeado para rotate_global e rotate_object_local deve ser renomeado para rotate_local para consistência e para que todos os métodos de rotação comecem com "rotate".

global_rotate deve ser renomeado rotate_global e rotate_object_local deve ser renomeado rotate_local para consistência e para que todos os métodos de rotação comecem com "rotate".

Bem, por outro lado, gosto que as funções relacionadas ao global (como global_position, global_scale e global_transform) estejam próximas umas das outras nas sugestões de preenchimento automático. Ambas as soluções fazem sentido IMHO.

Talvez tree_exiting pudesse ser renomeado para tree_exited , pois parece que já está causando alguma confusão. Consulte # 22840.

@groud Já existe um sinal tree_exited certo?

@groud Já existe um sinal tree_exited certo?

Droga, você está certo. Eu acho que a solicitação em # 22840 é válida então

MenuItems.MENU_MAX nunca é usado em LineEdit e TextEdit , devemos removê-lo?

O mesmo vale para Tabs.ALIGN_MAX https://github.com/godotengine/godot/blob/master/scene/gui/tabs.cpp#L750

Os nós Position3D e Position2D são um pouco ambíguos. Sem ler a descrição, pode-se supor que eles são como Spatial e Node2D, mas sem rotação ou escala. Eles provavelmente devem ser renomeados para PositionHint e PositionHint2D ou talvez alguma outra palavra como Gizmo pois é um gizmo apenas no editor ou AxisMarker porque parece um pequeno marcador de eixo.

Se eles fossem renomeados para Gizmo então talvez eles pudessem ter usos mais gerais.

Observe que o mesmo nó na árvore de controle é ReferenceRect , portanto, ReferenceAxis/2D pode funcionar.

Estou adorando esse problema agora. Pode odiar mais tarde, quando a quebra realmente acontecer;)

Algumas propostas para a humilde classe Array :

• duplicate → copy ou clone . Não conheço nenhuma linguagem que chame esse conceito de "duplicação". copy é como é chamado em Python e em C ++, portanto, seria a escolha natural para Godot. clone vem de Java e JavaScript e talvez seja um pouco mais preciso.
• invert → reverse . A documentação até o descreve como "reverso", então realmente não há desculpa.
• remove vs. erase é confuso. Sugestão: remove_at e remove_value .

Os dois últimos também se aplicam a todas as classes Pool*Array .

Nota: Duplicar → copiar / clonar também se aplica a Dicionários.

Rect2 :

• clip → intersection

AABB tem o método intersection , mas não clip , recortar geralmente significa que cortamos algo, o que não é implementado em nenhuma das classes btw. A documentação o descreve como:

Returns the intersection of this Rect2 and b.

Pode muito bem renomear:

• intersects → overlaps
  para não ser confundido com a operação intersection real:

Returns true if the Rect2 overlaps with another.

grabber_area -> slider_progress
slider -> slider_background

Algumas propostas para a humilde classe Array:
duplicate → copie ou clone.
...
Nota: Duplicar → copiar / clonar também se aplica a Dicionários.

E nós e recursos (basicamente qualquer objeto de estrutura de dados exposto por script, afaik).

Prefiro a palavra "Clone", acho mais claro o que ela faz.

Manhã! @ akien-mga não poderíamos renomear instance para new vez de instantiate ? Ter a mesma interface em PackedScene como Object s tem, por exemplo, remove alguns clichês especialmente para a criação de plug-ins, mas provavelmente de forma mais geral. @willnationsdev o que você acha? Eu sei que você já encontrou isso antes.

Desculpe se já há uma conversa sobre isso em algum lugar, não consegui encontrar folheando.

grabber_area -> slider_progress
slider -> slider_background

ou apenas:
grabber_area -> progress
slider -> background ?

Não sei se isso foi discutido, mas AnimationPlayer tem root_node com set_root & get_root , eles provavelmente deveriam ser set/get_root_node

Renomear CanvasItem.visible para CanvasItem.is_visible (e todos os outros lugares onde é usado)? para estar alinhado com todas (ou a maioria, talvez eu tenha esquecido algumas) bool propriedades?

Renomear Tween.tween_completed para Tween.tween_finished ? Assim como Animation.animation_finished ? Geralmente prefere _finished vez de _completed ? Parece que started/finished tem uma relação mais estreita do que started/completed - enviesado por esportes de competição: start/finish - talvez: D

Considere renomear a classe JavaScript para HTML5 ou outra coisa.
Esta classe possui método único e não se estende de Script e não é usada em outras plataformas.

O JavaScript pode ser usado como o nome da classe de ligações de linguagem JavaScript no futuro.

Como apontado por @clayjohn , WORLD_MATRIX em shaders CanvasItem é na verdade uma matriz modelview. @reduz concorda que no 4.0 devemos substituí-lo por modelos reais e matrizes de visão, por exemplo, CANVAS_MATRIX e ITEM_MATRIX .

Considere renomear Array.invert para Array.reverse . Inverter é mais como de cabeça para baixo ou o tipo de coisa "recíproca". Consulte https://docs.godotengine.org/en/latest/classes/class_color.html#class -color-method-inverted

Altere o sinal CanvasItem.visibility_changed() para CanvasItem.visibility_changed(visibility: bool) , ou seja. envie o status de visibilidade com ele. Como isso será suficiente, remova o sinal CanvasItem.hide()

Remova Resource::notify_change_to_owners , Resource::{un}register_owner .
Eles são usados ​​apenas por GridMap e CollisionShape, o resto do código usa o sinal "changed" .

Rect2 : has_no_area deve ser renomeado para has_area evitar que a lógica de dupla negação verifique o oposto nas condicionais. O mesmo se aplica a AABB : has_no_surface .

Com base no que @lupoDharkael disse, Godot tem vários lugares onde negativos duplos são usados. Erros como "Condition! Math :: is_nan (x) is false" são confusos.

parse_input_event (evento InputEvent)
Alimenta um InputEvent para o jogo. Pode ser usado para acionar artificialmente eventos de entrada a partir do código.

parse é enganoso, parse estaria recebendo e processando, mas a descrição indica o envio ou acionamento de uma entrada

De acordo com # 24153 - CanvasLayer usa camada para descrever em qual camada desenhar seus nós. Mas quase todos os outros nós 2D usam a terminologia "Índice Z" ( z_index ) para descrever (o que parece ser) a mesma coisa. Como @swarnimarun sugeriu https://github.com/godotengine/godot/issues/24153#issuecomment -444950584 melhorando os nomes das camadas.

OS.has_feature () / Platform.has_feature () seria mais sensato em algo como ProjectSettings, uma vez que eles não transmitem nada exclusivamente sobre o sistema operacional?

set_cell_item pode ser renomeado para set_cell para unificar GridMap com TileMap?

set_cell_item pode ser renomeado para set_cell para unificar GridMap com TileMap?

Pensando bem, talvez devesse haver set_cellv para GridMaps também?

ARVRInterface:

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

AnimationPlayer:

• play_backwards pode ser removido porque play tem um bool opcional para isso.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D:

• Altere o bool disabled para um enabled bool.

Bone2D:

• get_index_in_skeleton -> get_skeleton_index

• play_backwards pode ser removido porque play tem um bool opcional para isso.

Isso seria ruim para a legibilidade, pelo menos enquanto # 6866 não estiver implementado. Não é um problema em C #, pois oferece suporte a parâmetros nomeados.

ID em id_pressed( int ID ) e id_focused( int ID ) deve estar em minúsculas.

^
Essa mudança, na verdade, não quebraria nenhuma compatibilidade. Provavelmente, poderia ter um problema separado.

^
Essa mudança, na verdade, não quebraria nenhuma compatibilidade. Provavelmente, poderia ter um problema separado.

Isso mesmo!

28746 - Node.replace_by pode ser confuso como nome. Não tenho certeza do que exatamente poderia ser um nome melhor.

@ bojidar-bg talvez replace_self ou swap_by ? mas acho que a única maneira de evitar qualquer tipo de confusão é documentando-o adequadamente.

Se eu tiver um Node2D com um script anexado que contém class_name MyNode2D , o método get_class() retorna Node2D vez de MyNode2D . Isso pode ser intencional, mas é confuso e enganoso.

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

@aaronfranke get_native_class() talvez? Então você poderia obter o nome do script de get_script().global_name se ele tiver um.

make_convex_from_brothers()
Eu acho que "irmãos" deve ser alterado para "irmãos", já que essa é a palavra usada em todos os lugares para nódulos de irmãos.

ARVRPositionalTracker: get_type() -> get_tracker_type()

• get_tracker_type() é mais explícito - get_type() pode ser confundido com get_class()

• GetType() já é usado para outra coisa em C #, conforme observado aqui .

Ele retorna TrackerType , e também há get_hand() que retorna TrackerHand , de modo que também pode ser alterado para get_tracker_hand() para consistência, se desejado.

ARVRPositionalTracker enum TrackerHand: TRACKER_LEFT_HAND -> TRACKER_HAND_LEFT (e mão direita). Alternativamente, TRACKER_HAND_UNKNOWN -> TRACKER_UNKNOWN_HAND , contanto que seja consistente.

Node.NOTIFICATION_TRANSLATION_CHANGED provavelmente deve se tornar NOTIFICATION_LOCALE_CHANGED , já que "tradução" é usada em nós espaciais para significar "posição" e não "idioma".

set_as_toplevel() poderia ser renomeado para set_as_top_level() , mas seu comportamento deve ser examinado .

TouchScreenButton deve ser analisado para 4.0, pois essa alteração pode estar quebrando: https://github.com/godotengine/godot/issues/28814

Método CanvasItem :

RID get_canvas_item () const
Retorna o item de tela RID usado pelo VisualServer para este item.

Deve ser renomeado para get_rid() então.

get_canvas_item() é confuso porque já estou no nó CanvasItem . Também garante a consistência, visto que outras classes já têm um método get_rid() semelhante: CollisionObject , Resource .

Label ser alterado para TextLabel ? Várias vezes já quis colocar um objeto de texto e esqueci o nome dele, então procuro por "texto" e apenas RichTextLabel aparece. TextLabel seria mais consistente com RichTextLabel porque ainda é texto, mas sem os ricos.

Para referência, o Unity tem Text e TextMesh , e eu pessoalmente me refiro a ele como texto em vez de rótulo.

Também estive pensando se Tree e GraphNode foram renomeados para TreeView e GraphEditNode .
Para Tree , o motivo é que é um nome muito amplo para um nó GUI global IMO, todas as outras estruturas GUI que conheço usam TreeView .
Para GraphNode , é porque trabalhei em alguns protótipos recentemente envolvendo estruturas de gráficos reais, e não pude usar Node nem GraphNode que era muito chato.

@Zylann uma vez que os nós do Graph são visuais / controles para gráficos (não árvores), GraphContainer pode ser melhor. Não tenho certeza sobre GraphNode.

Devemos ter lerpf / lerpv / lerpc vez de Color/Vector2/3.linear_interpolate ? Renomeie pelo menos Color/Vector2/3.linear_interpolate para Color/Vector2/3.lerp

Conforme mencionado em # 29598 http_escape / http_unescape a uri_encode / uri_decode

Devemos ter lerpf & lerpv vez de Vector2/3.linear_interpolate ? Renomeie pelo menos Vector2/3.linear_interpolate para Vector2/3.lerp

Encurtar para vector.lerp () parece bom. Pelo menos a partir de https://github.com/godotengine/godot/pull/16106, o uso de lerp() no script tem um switch para suportar vetores e cores.

Vector2.angle_to_point() deve ser renomeado. Seu nome não é consistente com a descrição atual. Não tenho certeza do que seria um bom nome e se vale a pena manter essa função.

Edição original: # 16307

@ razcore-art Já é um PR aberto sobre este https://github.com/godotengine/godot/pull/20371 , e mantém compatibilidade retroativa (eu acho).

EDIT: Não faz mais.

Area deveria realmente ser Volume , já que é 3D. E Area2D deve ser Area . Uma área é 2D por natureza.

GridMap deve talvez ser CubeMap . Não tenho certeza sobre este, apenas que "grade" soa como uma coisa 2D para mim.

CheckButton controle SwitchButton ou algo assim. É confuso porque também existe Checkbox . Ou talvez deva ser removido completamente. De qualquer forma, ele tem a mesma função que Checkbox, pelo que eu posso dizer.

Eu concordo com relação a: CheckButton e os outros são apenas cosméticos.

Ou talvez deva ser removido completamente. De qualquer forma, ele tem a mesma função que Checkbox, pelo que eu posso dizer.

Em termos de UX, CheckBox e CheckButton são coisas diferentes, apesar de terem a mesma funcionalidade.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@ Área de Rodeo-McCabe é chamada assim para consistência com a contraparte 2D, também uma das definições de area é a particular extent of space or surface .
Cubemaps são imagens 3D, a correção da sintaxe deve estar no contexto ou apenas adiciona confusão.

grabber_area -> slider_progress
slider -> slider_background

ou apenas:
grabber_area -> progress
slider -> background ?

Pode ser:
grabber_area -> progress_area ou progressed_area
slider -> progress_background ?

Cubemaps são imagens 3D, a correção da sintaxe deve estar no contexto ou apenas adiciona confusão.

@eon-s Bastante justo, eu não sabia disso.

A área é chamada assim para consistência com a contraparte 2D

O problema é que a contraparte 2D também é inconsistente. Em matemática, uma área é comprimento * altura, simplesmente não existe uma terceira dimensão. Portanto, não faz sentido dizer Area2D, porque deveria ser 2D em virtude de ser uma área. Outra definição mais matemática de "área" é:

a superfície incluída dentro de um conjunto de linhas, especificamente: o número de quadrados unitários igual em medida à superfície

Da mesma forma, um espaço 3D em matemática é chamado de "volume". Fiquei confuso no início quando descobri que a Área era na verdade um nó 3D; em vez disso, as áreas eram estranhamente chamadas de "Área2D". Sendo este um motor de jogo, as definições matemáticas são as que devemos tomar.

Embora eu compreenda o raciocínio, não sei se haveria algum benefício particular em mudar o nome, especialmente para novas pessoas. Eu concordo que "Volume" pode ser um termo mais apropriado para isso, mas acho que ter "Volume" para 3D e "Área" para 2D pode ser um pouco confuso. Afinal, muitos nós que possuem variantes 2D e 3D serão nomeados "

Eu acho que o esquema de nomenclatura de estar lá em primeiro lugar (tanto quanto há alguns nós que só concentram-se o esquema) significa que não devemos ter uma exceção à regra, mesmo quando um outro termo para uma variante faria mais sentido, caso contrário, pode confundir os usuários.

Se eu puder, entretanto ... talvez renomear Area2D para Area e Area para Area3D ?

Editar: parece que o texto cercado por <> não aparece, a menos que você escape do <>

@ Rodeo-McCabe Tenho a impressão de que a intenção da nomenclatura de nós é expressar coisas em linguagem humana e não matemática. Portanto, a "área" não pretende ser geométrica, mas um lugar para estar, como dentro de um nível ou palco. IE - Área 1.

O nó em si não tem nenhuma geometria diretamente ou é ele mesmo uma geometria, então outros como eu se perguntariam onde está sua área / volume ao criá-lo, e então por que eu teria que anexar áreas e volumes (formas) a uma área e volume?

Se fosse necessário renomear para evitar confundi-lo com área geométrica, provavelmente os sinônimos seriam o caminho a percorrer.

Eles podem ser chamados de:

• Region2D / 3D
• Space2D / 3D
• Zone2D / 3D
• Field2D / 3D
• etc.

A propósito, além de este rastreador ser apenas para métodos, propriedades e sinais (não Nodes), @reduz mencionou recentemente que há intenções de minimizar a quebra de compatibilidade no 4.0, então provavelmente esta lista enorme pode precisar de uma revisão dos desenvolvedores principais antes de continuarmos adicionando coisas ad eternum ...

Parece que o objetivo é deixar as coisas como estão agora, então coisas como essa podem ser adiadas até a próxima versão principal após a 4.0?

Deixe este problema para os contribuidores principais, não é um lugar para fazer sugestões de grandes renomeações em todos os lugares, o objetivo é corrigir inconsistências reais que tornam a API complicada.

As mudanças delineadas no OP não são uma grande quebra de compatibilidade e a maioria será feita para 4.0, o que @reduz se referiu é quebra de compatibilidade do tipo "seu projeto não pode mais ser aberto" entre 2.1 e 3.0 (muito mais mudou do que apenas coisas sendo renomeadas naquela época, como os sistemas de áudio e partículas sendo completamente reescritos, a mudança do sistema de importação, etc.).

Haverá alguma quebra compatibilidade 4.0, caso contrário ele não seria chamado 4.0. Será razoável e a portabilidade será fácil, provavelmente com um conversor para garantir que propriedades, métodos e sinais renomeados sejam convertidos corretamente se usados ​​em cenas e scripts. Não é o lugar para discutir isso em qualquer caso :)

Control 's _set_anchor() também deve descartar o início "_".

O PopupMenu's tem index_pressed(index) e id_pressed(id) que funcionam bem, mas também id_focused que é realmente emitido com o índice em vez do id do item.

Não há problema para isso ainda, mas depois de sugerir a Akien hoje, vale a pena colocá-lo na lista.

Refatore o ARVRServer para que seja chamado de XRServer. Quando o projetamos, o termo XR para indicar VR e AR ainda não era amplamente utilizado. E não, eu não estou indo para o MRServer;)

O RayCast deve ter uma propriedade "Desativado" em vez de "Ativado"? CollisionShape tem um "Disabled" que é false por padrão (o que significa que eles estão habilitados por padrão). Em contraste, a propriedade "Enabled" de RayCast é false por padrão, tornando-os desabilitados por padrão.

Ou, para usar a forma positiva (que acho menos confusa no geral), o CollisionShape deve ter uma propriedade "Enabled" ( true por padrão) em vez de "Disabled"?

@Calinou Não sei se isso exigiria um problema separado, mas se precisarmos ser consistentes, eu realmente prefiro que esses booleanos sejam Enabled sempre. Definir um booleano como true para desabilitar algo me confundiu frequentemente.

@Calinou Eu concordo com @Zylann negativos duplos são confusos e devem ser evitados sempre que possível. Em vez disso, devemos alterar os bools "Desativados" para os "Ativados". Tudo bem se o valor padrão de algo for "verdadeiro". Tive essa discussão nos números 17212 e 21822.

A propriedade speed dos eventos de entrada de mouse e toque deve ser renomeada para velocity pois é um Vector2.

InputMap : get_action_list( String action ) o nome da função não diz muito sobre o que ela faz.
Uma vez que retorna os EventInputs associados a uma determinada ação, poderia ser get_action_events(String action)

Também pode ajudar a evitar possíveis confusões, já que InputMap tem outra função chamada get_actions( ) e ambos os nomes podem significar a mesma coisa fora do contexto.

Tangencialmente relacionado a # 30736, devemos renomear os dois motores de física Godot para algo como "GodotPhysics2D" e "GodotPhysics3D", já que dizer que algo está quebrado com "GodotPhysics" pode significar duas coisas muito diferentes.

Que tal renomear Object._init() para Object._new() ?

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

new - _init

Eu acho que _init realmente seguiu __init__ do Python, enquanto new é um método da classe, não a instância.

Algo como String : empty() -> is_empty() um bom ajuste para este tópico? Eu sempre acho que é uma função limpar uma string no início.

@vortexofdoom se estiver falando sobre inconsistências de nomes de métodos e / ou como eles devem ser nomeados, então sim.

Eu poderia adicionar que String e NodePath têm empty e is_empty métodos respectivamente que fazem a mesma coisa. O resto dos principais tipos integrados parecem preferir empty name, então talvez is_empty pudesse ser renomeado em NodePath para tornar isso consistente em todos os tipos integrados, mas isso poderia envolver potencialmente alguma quebra de compatibilidade séria, eu acho.

Eu sempre acho que é uma função limpar uma string no início.

A maioria dos métodos usa clear name em Godot para isso.

@Xrayez ,

A maioria dos métodos usa um nome claro em Godot para isso.

Eu sei, apenas referindo-se ao fato de que empty é um verbo e também um adjetivo, e adicionar is_ deixa claro qual é o significado.

Eu seria a favor de usar is_empty em todos os recursos internos desse bool.

Em Godot 3.0 e 3.1, tínhamos Set métodos em C #. No entanto, na verdade, eles não adicionavam nenhuma funcionalidade real em comparação com apenas o uso de um construtor e atribuição, mas permitiam que o código falhasse silenciosamente, então ficaram obsoletos. Eles foram adicionados principalmente por mim para tentar ser consistente, uma vez que já existia um método para o Quat, que veio do núcleo com métodos definidos. Para obter mais informações, consulte # 30744

GDScript tem set_euler e set_axis_angle , mas também existem construtores para fazer a mesma coisa ( q.set_axis_angle(myvec3, myval) pode ser substituído por q = Quat(myvec3, myval) . Core também tem estes métodos para Basis, mas eles não estão expostos a GDScript.

A questão é, então, o que deve ser feito sobre isso? Os métodos de conjunto Quat devem ser preteridos em favor dos construtores e para serem consistentes com C #, ou vale a pena mantê-los explícitos sobre a operação que está sendo executada? Neste último caso, os métodos Basis também devem ser expostos?

@aaronfranke Eu sempre achei estranho que os construtores tivessem métodos dedicados quando basicamente nada mais o faz, então

@aaronfranke Esse problema é sobre renomear coisas na API, não funcionalidade do mecanismo ou bugs.

Geometry 's point_is_inside_triangle() to is_point_in_triangle() , para combinar com os outros métodos que também retornam bool s na mesma classe.

TreeItem.get_children() deve ser renomeado para get_first_child() . O documento também deve explicar que NÃO está retornando os itens filho. As crianças são iteradas usando get_next() .

Ao trabalhar em # 31976, percebi que o valor do atlas de sombra deve ser uma potência de 2 (tanto para sombras direcionais quanto para sombras omni / pontuais). No entanto, os métodos aceitam qualquer valor inteiro; se não for uma potência de 2, o método o arredondará para a potência mais próxima de 2. Provavelmente devemos fazê-lo aceitar um enum de valores, para que possa ser apresentado de uma maneira amigável nas configurações do projeto.

Da mesma forma, o nível de filtragem anisotrópica deve ser um enum (2 ×, 4 ×, 8 ×, 16 ×), uma vez que apenas valores de potência de dois fazem sentido aqui.

VisualServer 's instance_create2() deve ser alterado para realmente descrever o que faz de forma diferente de instance_create() .

Para traduções relativas a objetos, Spatial tem translate_object_local que leva Vector3 , e Node2D tem move_local_x e move_local_y , que pegam flutuadores. Ambos Spatial e Node2D deveriam ter métodos que levassem Vector3 e Vector2 respectivamente, e translate_local ou local_translate teriam sejam nomes mais simples do que translate_object_local .

@leonkrause Em vez de render_width e render_height , faria mais sentido chamá-lo de viewport_width e viewport_height , ou talvez canvas_width e canvas_height , uma vez que é a resolução de referência usada para a janela de visualização do canvas e não afeta a renderização.

@ akien-mga considere adicionar os métodos de navegação em árvore à sua lista. Eles têm nomes muito confusos e não são bem documentados.

Quando os encontrei pela primeira vez, pensei que get_child () e get_next (), get_prev () operavam um iterador muito parecido com o modo como o Directory funciona. Tive de fazer meus próprios testes para descobrir que tudo o que eles fazem é produzir o mesmo ponteiro cada vez que são chamados.

get_children () deve ser renomeado para get_first_child ().

get_next () e get_prev () devem ser renomeados para get_next_sibling () e get_prev_sibling ()

Que tal renomear Engine.iterations_per_second para Engine.physics_fps para consistência com as configurações do projeto?

is_processing :

Retorna verdadeiro se o processamento estiver habilitado.

can_process :

Retorna verdadeiro se o nó puder processar enquanto a árvore da cena estiver pausada

Pode ser melhor renomear can_process para algo como can_process_paused para evitar confusão com o método is_processing .

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

Acho que esse método deve ser renomeado.

@dalexeev Como deve ser renomeado e por quê?

@Calinou Este método não imprime nada na tela; ele retorna uma string. O primeiro pensamento é que JSON.print funciona exatamente como Node.print_tree ou OS.print_all_resources ou como todos os outros print* métodos.

Como deve ser renomeado? Não tenho certeza. JavaScript usa JSON.stringify para isso. PHP tem uma função json_encode . Diretamente no GDScript, existe uma função semelhante - to_json .

UPD. JSON.serialize também é possível, mas pelo número de caracteres é o mesmo que JSON.stringify . :sorriso:

Eu sugeriria contra a palavra "serializar", uma vez que geralmente é usada para serialização binária, e tal saída precisaria de etapas adicionais para entrar nessa forma.

Uma vez que esta classe tem apenas dois métodos para ir entre os tipos JSON e Variant, eu sugeriria métodos que contenham a palavra json pois é inútil.

Agora, para coisas que seriam um bom nome, o método parse não tem realmente uma palavra oposta clara ( veja aqui ). Talvez um destes: encode , create , compose , generate ? Se encode for usado, faria sentido renomear o outro método para decode .

Eu vi format e write sendo usados ​​como o inverso de parse . stringify tem a vantagem de ser mais conhecido entre os desenvolvedores por ser usado em JavaScript.

Eu vi format e write sendo usados ​​como o inverso de parse . stringify tem a vantagem de ser mais conhecido entre os desenvolvedores por ser usado em JavaScript.

str2var é VariantParser e var2str é VariantWriter internamente (ver # 33241 por exemplo, eu até usei o mesmo termo para descrevê-lo).

Portanto, estou a favor de write , a consistência vence. 😛

@Xrayez Altere print para write ? De Python a Pascal? :rindo:

Conforme sugerido em https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552, pode fazer sentido renomear tudo relacionado a clear_color para background_color (incluindo o configurações do projeto).

Eu esperaria que o 4.0 trouxesse uma grande onda de novas pessoas para Godot devido ao melhor desempenho, melhorias nas sondas GI, hype geral e assim por diante.

Se essas mudanças forem feitas com o 4.0, essas pessoas terão um pouso difícil, já que quase nenhum tutorial existente (além do tutorial oficial do "primeiro jogo") funcionará mais para eles.

Se essas mudanças forem feitas depois do 4.0, digamos no 4.1, será uma jornada extremamente acidentada para essas pessoas. Eles acabaram de aprender o básico de um novo motor, que agora precisam reaprender. O começo é difícil, ter que passar por isso duas vezes logo após a outra pode ser frustrante o suficiente para desistir de vez.

Portanto, não faria sentido ter uma versão "3.3" ou "3.9" antes do lançamento 4.0 que tem todas as alterações de API que quebram a compatibilidade, no entanto, dá aos criadores do tutorial tempo suficiente para criar alguns tutoriais antes do influxo maciço esperado de novos usuários?

Não tenho certeza se este é o lugar certo ou não, mas uma vez que essa pode ser uma possível solução parcial para problemas de renomeação, irei apresentá-la aqui.
Por que não fazer todas as alterações de renomeação necessárias e, em seguida, adicionar um novo idioma às traduções chamado GodotOldNames / GodotPre4.0, que contém todos os nomes antigos para todas as alterações.
Desta forma, caso alguém não encontre os nomes antigos presentes em tutoriais antigos, pode apenas alterar o idioma para GodotPre4.0. Isso também tornaria a troca para novos nomes mais fácil.
Isso não resolve todo o problema, mas pode funcionar junto com # 4397.

@Anutrix Isso adicionaria muita complexidade (e quanto aos idiomas não ingleses?). Além disso, nem todas as strings exibidas no editor são localizáveis ​​em primeiro lugar.

Física " Camada ", Renderização " Camada "

Lembro-me de ter passado exatamente pela mesma confusão que essa pobre pessoa durante minhas primeiras semanas de aprendizado sobre Godot.

Física "Camada", Renderização "Camada" pode fazer sentido para alguém vindo do Design Orientado a Objetos , mas para qualquer outra pessoa é muito confuso. O termo "camadas" é usado para descrever várias camadas de tinta, ou camadas de tecido em um tecido, camadas de pele em uma cebola (ou ogro), camadas de sedimentos na superfície do planeta, ...
Camadas (plural, opostas a uma única camada), parecem implicar em serem empilhadas umas sobre as outras em todos esses casos.

Para muitas pessoas, "camadas", especialmente ao trabalhar com gráficos ou animações 2D, implica trabalhar com primeiro plano, plano de fundo e camadas intermediárias ou superiores. Muitas pessoas pensam em camadas como filmes de celolóide em cima de um fundo, quando na verdade Godot, como muitos outros mecanismos de jogo, usa várias formas de "classificação" para realizar essa tarefa.

O fato de chamarmos a semelhança abstrata de que objetos físicos ou objetos Render podem compartilhar "camadas", enquanto ao mesmo tempo essas semelhanças abstratas não têm nada a ver com a aparência de empilhamento de camadas visuais (isso é "classificação"), é o que torna isso tão confuso para alguns.

Quando eu entendi o real uso e significado de Physics "Layer", Render "Layer", eu imediatamente me perguntei por que não eram Physics Group, Render Group, e para ser honesto, ainda não sei. Eles certamente não têm nenhuma relação empilhável no topo, o que significa que sua ordem ou relação é completamente irrelevante. Nomeando-os de camada, imho arquiva nada além de confundir as pessoas, "grupo", "afetado por grupo" para máscaras, ou talvez algum outro termo que eu não consigo pensar agora seria mais preciso.

Método AnimationPlayer
.stop (falso) deve ser chamado .pause (verdadeiro)
porque é isso que faz.

Projeto> Configurações do projeto> Exibir> Janela> Esticar> Modo:

O Modo de alongamento "2D" deve ser chamado de Modo de alongamento "exibição" ou "uso geral"
porque é confuso chamá-lo de 2D quando funciona tão bem para casos de uso 3D, mas não muito bem para todos os casos de uso 2D (como projetos pixelart, enquanto quase metade dos projetos 2D Godot parecem ser pixelart).
"display" também seria mais descritivo para o que realmente faz: renderizar todos os gráficos, sejam gráficos 2D, objetos 3D, malhas 2D, Line2D e polígonos na resolução da tela.
Mais sobre isso aqui .

loop, repeat, oneshot, de animador, cronômetro e nós semelhantes, podem ser esclarecidos.

looping, repetição e não ser um one-shot são todas as mesmas coisas.

eu penso isso
is_a_parent_of()
deve ser renomeado para
is_parent_of()

@KoBeWi veja a discussão em # 19801.

eu penso isso
is_a_parent_of ()
deve ser renomeado para
is_parent_of ()

Acho que não, is_parent_of () sugere que leva em consideração apenas o primeiro pai, enquanto a função verifica todos os pais recursivamente.

@groud Nesse caso, ele deve ser chamado de is_ancestor_of() . Se também houver uma função correspondente ao contrário, ela deve ser chamada de is_descendant_of() .

@groud Nesse caso, ele deve ser chamado is_ancestor_of (). Se também houver uma função correspondente ao contrário, ela deve ser chamada de is_descendant_of ().

Sim, mas pensando nisso não há muita necessidade de ter as duas funções, pois a diferença seria apenas uma questão de trocar o objeto "chamador" e o argumento da função. Talvez pudéssemos simplesmente substituir a função por algo como is_descendant_of() e pronto.

Podemos querer renomear push_error() e push_warning() para print_error() e print_warning() respectivamente. Isso os tornaria mais detectáveis ​​graças ao preenchimento automático: ligeiramente_smiling_face:

@Calinou print_error() pode ser confundido com printerr()

Por favor, considere alterar o nome do método TreeItem.get_children() , já que o nome indica uma coleção de filhos para ser o valor de retorno, quando na prática é o primeiro filho que é retornado e então você tem que iterar sobre o resto do usando get_next() (conforme descrito em # 19796).

Citando @Zylann de # 31404:

[Renomear rpc() / rset() para] remote_call() / remote_set() ?
Esses métodos também têm nomes curtos, não tenho certeza se um alias é o suficiente. Você realmente tem que fazer muito multiplayer com toneladas dessas chamadas por script para justificar identificadores de 3 caracteres (o que tenho certeza que a maioria dos jogos não faz).

Edit (2020-01-03): Pensando bem, call_remote() e set_remote() podem fazer mais sentido, pois já temos call_deferred() e set_deferred() .

Edit: Não se preocupe com o fechamento / reabertura abaixo, eu cliquei muito rápido.

Métodos a seguir

OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

deve ser movido da classe OS para a classe Input para consistência com os métodos:

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

TabContainer deve ter seus sinais tab_close e tab_hover editados também.

• LightOccluder2D light_mask -> occluder_light_mask
• CPUParticles Flags enum -> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker get_name -> get_tracker_name
• PathFollow2D rotate -> algo mais
• ArrayMesh ArrayType enum -> excluir isto
• Malha BlendShapeMode enum -> dar a ArrayMesh

Explicações em https://github.com/godotengine/godot/issues/15763#issuecomment -568908661

Os sinais meta_hover_started e meta_hover_ended RichTextLabel devem ser renomeados para corresponder à maioria das outras convenções de nomenclatura semelhantes: meta_hover_entered e meta_hover_exited . Isso não apenas faz com que ele imite mais de perto o resto da API Godot, mas o esquema de nomenclatura atual, devido à classificação alfabética, faz com que sua ordem seja invertida. Isso é um pouco desorientador quando você está lendo os documentos, já que, claramente, o fluxo cronológico das operações é primeiro entrar e depois sair. Tudo ao redor melhora a legibilidade e consistência para alterá-lo.

Percebi que não há propriedade Texture.size. Eu precisava chamar o getter Texture.get_size () em vez disso.

Eu perguntei em Discord se isso era intencional ou não. Uma sugestão foi postar aqui perguntando se isso precisa ser convertido em uma propriedade, a outra sugestão foi que, como não há um 'setter' para isso, usar get_size () é o comportamento esperado atualmente.

@jmbjr Temos alguma propriedade somente leitura exposta como propriedades (em vez de apenas métodos getter)? Lembro-me de ter visto um manipulador de erros integrado ao tentar definir uma propriedade somente leitura. Só não tenho certeza se ele foi exposto ao GDScript em primeiro lugar.

Sim, acho que se você fosse começar a oferecer suporte a propriedades expostas somente leitura, então precisaria de um sinalizador USAGE para isso e também adicionar o código do analisador / compilador GDScript que o suporta.

SoftBody tem um areaAngular_stiffness que deve ser area_angular_stiffness (o mesmo para todos os métodos relacionados).

Input.joy_connection_changed (o método) parece que não deve ser exposto à API de script, é chamado internamente pelo código de manipulação de joystick de cada plataforma.

@ akien-mga Quando vi esse método pela primeira vez, muito cedo depois de descobrir Godot, tive pensamentos semelhantes, então me lembrei de como Kojima construiu uma jogabilidade lendária no MetalGearSolid em torno de um método que deve ser muito semelhante a este e pensei: " Godot até me dá os meios para fazer o bico na 4ª parede, assim como o Kojima, com uma única linha de código, como isso é incrível! "

Label e RichTextLabel têm propriedades de tema inconsistentes:

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

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

Além disso, devido a valores padrão diferentes, a mesma fonte tem alturas diferentes em Label e RichTextLabel .

O sinal request_completion do TextEdit pode ser renomeado para completion_requested para usar o tempo passado. A versão atual parece um tanto imperativa, ao contrário da natureza dos sinais de retorno de chamada.

outra inconsistência com os sinais físicos do corpo

Área:

area_shape_entered (int area_id, area area, int area_shape, int self_shape)
area_shape_exited (int area_id, area area, int area_shape, int self_shape)
body_shape_entered (int body_id, Node body, int body_shape, int area_shape)
body_shape_exited (int body_id, Node body, int body_shape, int area_shape)

Suponho que area_shape nestes dois últimos deve ser self_shape? ou ...

Corpo rígido:

body_shape_entered (int body_id, Node body, int body_shape, int local_shape)
body_shape_exited (int body_id, Node body, int body_shape, int local_shape)

aqui é chamado local_shape ...

@FrederickDesimpel Pelo que eu sei, os argumentos podem ser renomeados sem quebrar a compatibilidade. Sinta-se à vontade para abrir uma solicitação pull para isso: ligeiramente_smiling_face:

Na variante:

Real -> Float
Nulo -> Nulo?

Eu gosto do nome "real" pessoalmente, já que o termo "float" é freqüentemente usado para floats de 32 bits especificamente, mas o real do Variant é um duplo, e a maior parte do mecanismo usa real_t que pode ser qualquer um.

PS Já fizemos essa mudança de nome ao contrário em 2017.

Será que consideramos renomear estes:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial já foi renomeado para StandardMaterial3D no master.

Os valores de limit_ em Camera2D devem ser alterados para Rect2i ? No momento, eles têm apenas quatro ints.

EDITAR: a margem de arrasto também pode ser alterada para Rect2 .

String::begins_with a String::starts_with .

Como em linguagens de programação sérias (Java, Python etc).

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

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

Embora a palavra "apenas" esteja faltando, event.is_action _... () corresponde a Input.is_action_just ... ().

Provavelmente deveríamos trocar os primeiros dois argumentos de Node.add_child_below_node() forma que o primeiro argumento seja igual a Node.add_child() . Veja # 19642.

_atelofobia semântica falando ... _

Deveria Node2D.draw_circle ser Node2D.draw_disk uma vez que desenha um disco e não um círculo?
Node2D.draw_circle ainda pode existir como um atalho para draw_arc de 0 para TAU .

@Goutte Em inglês, "círculo" pode se referir a um círculo vazio ou a um círculo preenchido. Acho que o nome atual é mais detectável, então não o mudaria.

Em inglês, "círculo" pode se referir a um círculo vazio ou a um círculo cheio.

Não consigo encontrar nada que apóie isso . Você tem alguma fonte para esta afirmação ou é um pressentimento?

Sobre a descoberta, ainda podemos ter draw_circle , isso simplesmente desenharia um círculo, e não um disco.

Não consigo encontrar nada que apóie isso . Você tem alguma fonte para esta afirmação ou é um pressentimento?

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

1 b: um plano fechado (ver entrada do plano 6 sentido 2b) curva em que cada ponto é equidistante (ver sentido equidistante 1) de um ponto fixo dentro da curva
1 c: a superfície plana delimitada por tal curva

(1b) é um círculo matemático (perímetro), (1c) é um disco matemático (superfície).

Em termos de API, é IMO mais amigável ter draw_rect(bool filled) e draw_circle(bool filled) que draw_rect() , draw_filled_rect() , draw_circle() e draw_disk() (ou qual seria o nome matemático de um retângulo preenchido?).

Editar: Na verdade, draw_circle() ainda não tem um argumento filled . Acho que devemos adicionar um, de modo que possa ser usado para desenhar círculos (perímetro) e discos (círculo preenchido).

Legal, obrigado. A maioria dos meus alunos é francesa e todos ficaram confusos com isso, e eu também, e culparam Godot e eu não pude deixar, é claro.

qual seria o nome matemático de um retângulo preenchido?

Essa é uma pergunta muito boa; tudo que posso encontrar é "área do retângulo" ou "interior do retângulo", e nenhum é adequado. O wiki ainda afirma que a maioria das pessoas abusam do termo _polígono_ para significar o _interior de um polígono_, sem fornecer outra palavra para isso.

Eu acho que um argumento filled poderia ajudar a aliviar a ambigüidade, mas vai ser um saco decidir onde colocá-lo na lista de argumentos.

@Goutte, mas vai ser um saco decidir onde colocá-lo na lista de argumentos.

Como é um argumento opcional (tem um valor padrão), e também para consistência com draw_rect , ele deve ser colocado no final.

Existem casos em que os nós de controle são chamados de nós modais. https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal Principalmente em relação à função Viewport.get_modal_stack_top ()

EditorInterface s get_selected_path e get_current_path métodos são confusos no nome e na função. Eles também não têm documentação.

Esses métodos são apenas uma camada fina sobre os métodos de FileSystemDock de mesmo nome:

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

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

Ambos devem se adaptar "selecionado" ou "atual" (ou qualquer outra coisa, mas para ambos) com um sendo get_*_path e o outro get_*_dir .

@Goutte O retângulo sólido não é uma alternativa ao retângulo preenchido?

O OP será atualizado com sugestões postadas após junho de 2019? Eu entendo que isso é muito trabalhoso, mas esse tipo de rastreador também é perfeito para os contribuidores trabalharem juntos. E suponho que já seja o momento em que podemos começar a trabalhar na renomeação de mais coisas?

Atualizar o OP também significaria que a sugestão postada é aceita como válida pela equipe.

@Anutrix "preenchido" é uma palavra melhor do que "sólido", porque "sólido" pode significar "não líquido ou gasoso".

@pycbouh Também seria uma boa ideia vincular PRs para cada problema, se houver. O OP já faz isso, mas não pelos comentários abaixo.

Não sei se foi levantado , mas não percebi quantas vezes paro para dar uma olhada no documento para este:

• Array.remove => remove_at (como C #) para remover por índice
• Array.erase => remove_value , ou apenas remove (como C #) para remover por valor

(ou variantes disso com erase )

Porque agora erase e remove significam o mesmo para mim, exceto que um é por índice, o outro por valor, eu continuo esquecendo qual é qual.

Já foi criado, meu mal. Não percebi, o Github está dobrando o tópico, minha pesquisa Ctrl + F errou xD
Ainda não está no OP

@Zylann Aqui está: https://github.com/godotengine/godot/issues/16863#issuecomment -441376010

Apoiando Zylann, sempre esqueço que a remoção é por índice ...

O ButtonList enum provavelmente deve ser renomeado para MouseButtonList pois são botões do mouse.

O JoystickList enum deve ser dividido? Ele contém botões e eixos, pode fazer mais sentido como JoypadButtonList e JoypadAxisList ou similar.

Só uma pergunta, por que não MouseButton ?
if button == MouseButton.LEFT:
lê melhor do que
if button == MouseButtonList.LEFT:

Boa ideia. Nesse caso, também há KeyList -> Key , MidiMessageList -> MidiMessage , e os joysticks precisam ter List removidos .

Notei que alguns métodos / propriedades usam normal_map , enquanto outros usam normalmap . Devemos escolher qualquer um deles, mas provavelmente não ambos. Eu preferiria normal_map , mas estou OK com normalmap também.

GDScript

range_lerp () = map ()
seed = set_seed ()

map () é provavelmente reservado para os novos recursos de programação funcional.

Vector2.tangent() é descrito nos documentos como: Returns a perpendicular vector. , essa é a definição de orthogonal ou orthonormal se o vetor retornado for normalizado. Uma vez que Vector2.tangent() retorna um vetor não normalizado, proponho que devemos renomeá-lo para Vector2.orthogonal() ou mesmo Vector2.perpendicular() se as pessoas tiverem algo contra a nomenclatura matemática ou talvez até Vector2.normal() , mas as pessoas podem ficar confusas entre normalized() e normal()

Anedótica do meu lado, mas minha primeira vez procurando por isso, minhas primeiras pesquisas nos documentos foram por _perpendicular_.

Você também pode manter .tangent() apenas como um apelido para .perpendicular() , não?

Não gosto do nome orthogonal porque não é uma palavra comum em inglês em comparação com as outras. Eu não vi um problema com tangent antes, mas acho que perpendicular é um nome melhor de qualquer maneira.

Sim, ortogonal é raro. Eu voto em .perpendicular (), mas MANTENDO o alias tangente () para compat também, é mais curto.

@ Zireael07 Eu preferiria que tivéssemos apenas uma maneira de obter a tangente. Não acho que seja uma operação muito comum, afinal.

Você ficaria surpreso com a frequência com que eu o uso em meus scripts procgen :)

Não esperava que isso gerasse um debate, mas pessoalmente sou contra Vector2.tangent() pois é um uso incorreto do termo matemático usual. O produto de Vector2.tangent() é simplesmente errado por definição. O nome deste segmento é a próxima quebra de compatibilidade planejada, então não vejo nenhuma razão pela qual deveríamos voltar atrás para manter a compatibilidade. Pessoalmente, estou bem com Vector2.perpendicular() .

Sugestão: torne find_node() 's owner parâmetro falso por padrão.

Sugestão: renomear os métodos / sinais de Tree para serem menos confusos com relação a, por exemplo, termos / status de "selecionado", "focado" e "nada".

Acho que Tree::ensure_cursor_is_visible é enganoso e deveria ser renomeado para algo como ensure_focused_item_visible ou ensure_selected_item_visible .

Até a referência da classe diz:

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() retorna especificamente o tipo nativo por baixo. Agora que nomeamos as classes de script, faz mais sentido renomear para get_native_type() pois a "base" do script pode ser potencialmente o nome de um script. É enganoso.

@willnationsdev Também há get_class() https://github.com/godotengine/godot/issues/16863#issuecomment -491421079

@aaronfranke Bem, com get_class() é universalmente usado para se referir a "qual é o nome da coisa que estou olhando no momento?". Portanto, no caso de Script , eu esperaria receber de volta "GDScript" , "CSharpScript" ou algo dessa natureza. Mas sim, com classes não Script , deve ser um método que retorna o nome da classe de script real, se ela for nomeada. Há até uma edição específica para isso. https://github.com/godotengine/godot/issues/21789#issuecomment -618588900

Editar: Oh, acho que, se tivermos get_class() , get_base_class() e get_native_class() , você realmente precisa de get_instance_base_type() para se tornar get_instance_native_class() para siga a convenção de nomenclatura e esclareça que é a instância, e não as informações do script.

Acho que autotile_coord (propriedades e métodos) de TileMap deve ser renomeado para tile_coord ou tile_coordinate porque AUTO_TILE e ATLAS_TILE use isso e o nome pode ser confuso para novos usuários. O Documentos também precisará de uma atualização. Posso fazer essa alteração se não houver problema.

Considere a remoção do argumento new_text de LineEdit.text_changed pois ele tem o mesmo comportamento que LineEdit.text .

Considere também adicionar old_text em adição ou como uma substituição de new_text .

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

Renomeie " camadas de colisão", " camadas VisualInstance", " camada de renderização", etc. para
" grupo de colisão", " grupo VisualInstance", " grupo de renderização", " grupo de luz"

A confusão sobre por que essas "camadas" não estão se acumulando surge como um relógio de minuto nos canais da comunidade.

Observe que eles são chamados de camadas em Maya, Lumberyard e Unity.

Só porque outra pessoa faz algo não significa que ainda não cause
confusão e é uma boa ideia.

Na segunda-feira, 18 de maio de 2020, 13h09, Jummit [email protected] escreveu:

Observe que eles são chamados de camadas em Maya, Lumberyard e Unity.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

Estou surpreso que ninguém mencionou ainda, mas
Camera2D.zoom
o zoom da câmera é reduzido quando o zoom é maior, o que não é como o "zoom" funciona e é contra-intuitivo. Não tenho certeza de como renomeá-lo, talvez view_scale ou algo semelhante.

@KoBeWi Em vez de renomear zoom , não deveríamos inverter sua escala para que amplie quando você aumentar o valor?

Isso interromperá a compatibilidade, assim como faria com a renomeação da propriedade. Se seguirmos a rota da "escala invertida", isso não pode ser corrigido automaticamente, infelizmente. Ainda assim, pode resultar em menos confusão a longo prazo.

@Calinou @KoBeWi Existe um caso de uso para usar essa propriedade de zoom diretamente, ou todos precisariam invertê-la a cada vez para aplicar à escala?

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

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

Talvez, mas onde traçamos o limite com isso e algo como Node2D.get_position_2d() ?

Talvez pudéssemos nomear a classe Viewport2D, mas isso não seria necessário a menos que fizéssemos um Viewport3D.

@nathanfranke Eu propus este método porque apenas no nome não há como saber se é 2D ou 3D, considerando que existem 2 tipos de Transform . (Enquanto outros membros já têm canvas_ ou mouse_ )

@Zylann Este método é realmente muito estranho. Existem propriedades chamadas canvas_transform e global_canvas_transform , e a descrição de canvas_transform é esta:

A transformação da tela da janela de visualização, útil para alterar as posições na tela de todos os CanvasItems filhos. Isso é relativo à transformação global da tela da janela de visualização.

Portanto, você esperaria que get_final_transform obtivesse ambas as transformações combinadas. No entanto, se você olhar o código, não é exatamente isso que ele faz.

O código para isso é return stretch_transform * global_canvas_transform; . Tenho tentado descobrir para que serve stretch_transform e não tenho ideia, não está exposto e certamente não está definido ao alterar canvas_transform . Também existe um método chamado _stretch_transform que não usa stretch_transform . É chamado por set_size , que pega o valor gerado por _stretch_transform e o atribui a stretch_transform . Há também canvas_transform_override que eu nem sequer mencionei e não está exposto, mas é usado internamente.

No final, acho que toda essa classe deveria ser examinada. Viewport tem 4 membros Transform2D diferentes, 4 membros Rect2 (i), 9 membros Vector2 (i) e 2 membros Transform (3D). Já são 264 bytes (com flutuações de precisão simples) de apenas estruturas de dados que armazenam as informações de transformação, se você somar todos os ponteiros e tal, provavelmente estará perto de 1 KB. Talvez o Viewport precise de tudo isso, mas parece complicado demais e, pelo menos, deveria haver comentários (há muito poucos neste arquivo).

Node2D / Node3D to_global e to_local devem ser removidos? Dei feedback sobre o nº 38902, que propôs a adição de métodos que funcionam apenas com a base, mas existem alguns problemas com eles.

Nos projetos de demonstração, to_local não é usado em nenhum lugar, e $ grep -RIn "to_global" retorna apenas 5 resultados, todos os quais estão na GUI na demonstração 3D, e o desempenho da demonstração pode ser melhorado alterando isso para que ele armazene em cache a transformação global e use xform vez de usar to_global .

Em suma, a preocupação com esses métodos é que eles são usados ​​de forma incomum e também porque eles incentivam a escrita de código com desempenho ruim, uma vez que recalcula a transformação global várias vezes.

27509

AnimationPlayer 's animation_started e animation_finished são um pouco contra-intuitivos. O primeiro é chamado para todas as animações na fila, enquanto o último só é chamado ao atingir o final da fila. Não está claramente mencionado na documentação.

Se quisermos detectar quando uma animação em particular termina, temos que usar animation_changed e animation_finished que não é conveniente.

Eu realmente gosto da sugestão de @txigreman nessa edição: podemos usar animation_finished sempre que uma única animação na fila terminar e adicionar um novo sinal animation_all_finished (semelhante a Tween ' s tween_all_completed ) que dispara apenas quando alcançamos o fim da fila.

E quanto a animation_queue_finished e / ou animation_queue_started ?

Eu não consigo encontrar aqui, então eu proporia,
find e findn par.

imagem da última versão 3.2 estável.

Talvez possamos renomear um para mencionar sua natureza de lidar com a diferenciação de maiúsculas e minúsculas.

Diga, find_ignorecase vez de findn ?

@swarnimarun Temos muitos outros métodos que não n . Se renomearmos um deles, devemos renomear todos eles.

Esses métodos ( find / findn etc.) basicamente fazem o mesmo. Poderíamos apenas adicionar um argumento se eles devem ser sensíveis a maiúsculas ou não.

@Calinou Eu preferiria muito que usar GDScript depois de abandoná-lo por alguns meses meio que me deu uma nova perspectiva para a API, eu diria,

Quanto mais óbvio, melhor. Lembrar da API para tudo é difícil por si só, um pouco mais de detalhamento na nomenclatura de funções parece uma mudança lógica.

@KoBeWi ser capaz de dizer com o nome da função o que ela faz ao invés de ter que se lembrar de adicionar outro campo ou enquanto lê o código (depois de esquecer / não saber essa parte da API) é bastante apreciado.

Portanto, ainda preferiria uma função diferente, mesmo que a outra função apenas chamasse a primeira com argumentos diferentes ou algo assim.

EditorInterface.get_editor_viewport() => get_editor_main_container()

Esta função não retorna um Viewport , apenas um Control que por acaso é o central que contém os editores de scripts 2D, 3D e a Biblioteca de ativos. Para o registro, o nó retornado é até VBoxContainer* , mas é abstraído (ainda é importante saber, porque afeta suas escolhas de configurações).
O documento também está errado, pois sua descrição se vincula à classe Viewport . https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class -editorinterface-method-get-editor-viewport

@Zylann Deve ser get_editor_main_screen() pois não é um Container, mas é a tela principal .

@aaronfranke que também é um nó Container , na verdade ^^ mas sim ... a tela principal também pode funcionar

Eu quero perguntar: alguém rastreia propostas neste tópico?

Por exemplo, acima (https://github.com/godotengine/godot/issues/16863#issuecomment-557657413), propus renomear o método JSON.print . Várias opções foram sugeridas, mas nenhuma delas apareceu na primeira postagem.

Só estou preocupado que ideias úteis se percam em tantos posts. :sorriso:

@dalexeev Recentemente, fiz uma primeira atualização da primeira postagem, mas ainda não

Eu tenho um que potencialmente corrige alguns bugs em RichTextLabel . Atualmente temos bbcode_text e text , mas ambos usam internamente a mesma estrutura de dados. Apenas os métodos chamados são diferentes, enquanto set_bbcode volta para set_text quando use_bbcode não está habilitado. Então, fui em frente e os removi em # 39148. Eu adicionei alguns outros pontos lá.

GetSceneInstanceLoadPlaceholder() no Node parece muito errado, primeiro ele não retorna um marcador como o nome pode sugerir, mas um bool e, em segundo lugar, isso vaza detalhes de implementações herdadas na classe base sem nenhum requisito real (teste para o tipo do nó é possível de outras maneiras)

RayShape → SeparationRayShape , como sugerido inicialmente em godotengine / godot-propostas # 711.

Que tal remover sort_custom e fazer sort aceitar um Callable opcional?

Devemos remover OS.get_ticks_msec() e OS.delay_msec() em favor de OS.get_ticks_usec() e OS.delay_usec() respectivamente? Isso evitaria ter duas maneiras de conseguir a mesma coisa. Se você precisar de um valor em milissegundos, poderá multiplicá-lo ou dividi-lo por 1000.

Além disso, GDScript e C ++ permitem adicionar separadores em literais inteiros, o que torna os valores grandes mais legíveis.

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

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

Além disso, GDScript e C ++ permitem adicionar separadores em literais inteiros, o que torna os valores grandes mais legíveis.

Se a remoção acontecer, get_ticks_usec() description deve mencionar os separadores.

@Calinou Por um lado, você está certo, mas por outro - na maioria dos casos, essa grande precisão não é necessária.

'Tesoura alfa' no material espacial deve se tornar o 'clipe alfa' padrão

@Flavelius Eu não vi o termo "clipe alfa" ser usado com frequência. No entanto, tenho visto o "teste alfa" usado com muito mais frequência do que tanto o "clipe alfa" quanto a "tesoura alfa".

É muita coisa para mudar! Alguém está trabalhando na implementação dessas sugestões?

@MCrafterzz As pessoas abrem solicitações pull para renomear coisas regularmente. Isso é feito de forma incremental, em vez de de uma só vez.

Textura (Texture2D) e imagem

• get_data () em Texture (Texture2D) deve ser nomeado get_image () e get_data () em Image deve ser nomeado get_bytes () para ser autoexplicativo.

IMO: get_image yes, get_bytes no.

texture.get_image().get_data()

Mesh / MeshInstance

• No Mesh, você obtém / define materiais com esses métodos:
  surface_get_material/surface_set_material
• Em MeshInstance, você obtém / define esses métodos:
  get_surface_material/set_surface_material

Deve ser o mesmo nome, eu acho?

@Coldragon Deve ser get_surface_material / set_surface_material e uma propriedade de surface_material .

@Coldragon Deve ser get_surface_material / set_surface_material e uma propriedade de surface_material .

Não é set / get "normal", eles têm um índice para a superfície alvo (é um vetor dentro da classe Mesh)

Array devemos renomear empty() para is_empty() para ilustrar melhor que é booleano

String devemos abandonar find_last() em favor de rfind() . Não é exatamente uma renomeação, mas ainda vale a pena discutir qual manter.

Para números únicos, temos stepify . Para Vector2 / Vector3, temos snapped .

Eles fazem a mesma coisa, os vetores chamam stepify para cada componente. Um nome deve ser escolhido, mas qual?

Enquete:: heart: = ambos devem ser stepify ,: rocket: = ambos devem ser snapped ,: -1: = não renomeie.

AABB tem intersection , enquanto Rect2 tem clip . Eles fazem a mesma coisa. Um nome deve ser escolhido, mas qual?

Enquete:: heart: = ambos devem ser intersection ,: rocket: = ambos devem ser clip ,: -1: = não renomeie.

@aaronfranke sim, já sugeri o nome intersection em https://github.com/godotengine/godot/issues/16863#issuecomment -449628319. Temos então intersects que poderia ser renomeado para overlaps em Rect2 , mas não temos certeza sobre AABB relação a intersects → overlaps rename.

Acho que find_node e / ou get_node devem ser renomeados porque os nomes não indicam nenhuma diferença entre os 2.
Já que find_node só olha para crianças, talvez find_child_node?
Não tenho certeza de qual seria um bom nome alternativo para get_node. Meu primeiro pensamento foi get_tree_node, uma vez que pode obter um nó de qualquer lugar na árvore, mas também pode ser usado fora da árvore de cena com caminhos relativos.

Acho get_node bom, mas find_node poderia ser renomeado para find_child

@MuffinManKen Eu acho que get_node é perfeitamente compreensível, uma vez que, como você afirmou, ele pode buscar qualquer nó, em qualquer lugar, desde que esteja conectado com a mesma árvore do nó dado, independentemente de eles fazerem parte de o SceneTree ou não.

@Coldragon Não tenho certeza se gosto de renomear find_node para find_child , pois isso me dá a impressão de que funciona apenas com filhos diretos por algum motivo. A alternativa seria chamá-lo de find_descendant ou algo assim, mas isso é muito prolixo / complexo. Cortar para apenas find() também não faz sentido, pois não está claro o que estamos procurando. Dessa forma, acho que, a menos que outra alternativa seja procurada, find_node deve permanecer como está. Ele deve apenas ter diferenças claras documentadas no comportamento para os documentos da API.

No Godot 3.1, adicionei uma tag de recurso standalone que avalia true quando o projeto está sendo executado a partir de um binário de modelo de exportação (depuração ou liberação). O oposto é editor , que avalia como true quando o projeto está sendo executado a partir de um binário do editor.

No entanto, com o tempo, acho que seria melhor renomear standalone para runner , pois é mais curto e um pouco mais autoexplicativo. O que você acha?

E quanto a exported ou release ?

@aaronfranke exported implica que o projeto foi exportado, o que não é necessariamente o caso. Você pode usar um binário de modelo de exportação para executar um projeto diretamente de seus arquivos de origem, desde que os ativos tenham sido importados antecipadamente.

Além disso, release já é usado para binários de modo de lançamento (em contraste com debug , que é usado para binários de modo de depuração).

runner não parece muito claro para mim. standalone está ok. Também não haveria problema em removê-lo, porque você pode apenas usar !OS.get_feature("editor") .

Também não haveria problema em removê-lo, porque você pode apenas usar !OS.get_feature("editor") .

Isso não pode ser usado para sobrescrever as configurações do projeto, já que não há seletor .not lá. Provavelmente é viável trocando a configuração padrão e sua substituição, mas parece um pouco mais complicado.

Por que não app ou game em contraste com editor então? Ou isso seria apenas mais confuso? Talvez tenha um sinalizador de recurso para no-editor para ser mais explícito?

@willnationsdev game implica que Godot só pode ser usado para jogos. Muitas pessoas estão usando Godot com sucesso para aplicativos que não sejam de jogos, então eu prefiro usar um termo mais inclusivo: ligeiramente_smiling_face:

Além disso, não é realmente autoexplicativo: as pessoas podem pensar que ainda se aplica a projetos executados no editor (afinal, você está executando o "jogo" no editor). O mesmo vale para app .

Que tal "independente"?

Sábado, 25 de julho de 2020, 5h49. Hugo Locurcio, notificaçõ[email protected]
escreveu:

@willnationsdev https://github.com/willnationsdev jogo implica Godot
só pode ser usado para jogos, o que provou não ser o caso 🙂

Além disso, não é realmente autoexplicativo: as pessoas podem pensar que ainda
aplica-se a projetos executados no editor. O mesmo vale para o app.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
.

@MuffinManKen independent não me parece muito autoexplicativo.

Editor vs autônomo é provavelmente a nomenclatura padrão (pelo menos um que vejo em muitos motores diferentes), portanto, não há razão para reinventar o imho de roda.

Get_node não se limita a obter descendentes, então isso seria muito
nome enganoso. Os 2 métodos precisam de nomes muito diferentes porque o que eles
fazer é muito diferente.

No sábado, 25 de julho de 2020, 3:14 pm golddotasksquestions, <
notificaçõ[email protected]> escreveu:

Lembro-me da confusão que tive por muito tempo no início com
find_node e get_node. Eu realmente gostaria de find_descendant e
get_descendant, pois seriam verdadeiros e informativos @willnationsdev
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
O "prolixo" pode não agradar a todos, mas imho não é realmente um
problema, pois há autocomplete e abreviação "$".

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
.

Acho que tanto Transform quanto Transform2D métodos inverse e xform_inv devem ser renomeados / removidos porque o que esses métodos realmente fazem não é o que as pessoas esperam que façam . Mais detalhes: https://github.com/godotengine/godot/issues/39433#issuecomment -664024521.

RayCast.cast_to deve ser renomeado para RayCast.segment ou algo assim. Acabei de ouvir alguém dizer que levou 40 minutos para perceber que é uma propriedade e não uma função. Provavelmente porque é um verbo também.

E quanto a RayCast.target ?

@ razcore-art Recentemente respondi a uma pergunta relacionada ao lançamento de raios e usei segment palavra para descrevê-la, então acho que faz sentido. Mas isso também poderia ser reescrito como direction e length , então realmente se tornará algo mais próximo de um raio em vez de um segmento, falando geometricamente (ou apenas fornecer propriedades alternativas que poderiam coexistir) . O problema é que não há como definir facilmente um vetor de direção normalizado no inspetor. Eu escrevi uma proposta para fazer uma, pelo menos para 2D: godotengine / godot-propostas # 397, mas talvez isso seja muito improvável.

EDITAR: Pensando melhor, segment não faria muito sentido em termos de RayCast node , mas faria sentido em termos de Physics2DDirectSpaceState.intersect_ray() .

E quanto a RayCast.target ?

@nathanfranke Presumo que o alvo seja Node ou NodePath . Portanto, pelo menos isso poderia ser RayCast.target_position . Talvez RayCast.cast_position ou RayCast.cast_offset . Não se esqueça de que a projeção de raio pode girar, o que pode mudar a posição real da projeção em coordenadas globais.

PhysX API confirma minha ideia de unidade de direção + comprimento para configurar raycasts. 😛

Dito isso, estou inclinado a cast_position ... Porque reescrever como funciona a fundição de raios requer mais mudanças básicas.

@Xrayez Eu evitaria usar a palavra "lançar" no início de uma propriedade, já que naturalmente leio isso como o verbo "lançar" e não o substantivo "lançar" e, portanto, cast_position provavelmente não teria resolveu o problema original de não saber que se trata de uma propriedade e não de um método (seria fácil supor que cast_position é um método que converte para uma posição). Eu gosto de target_position .

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

Pode renomear KEY_BACK para KEY_MEDIA_BACK e KEY_FORWARD para KEY_MEDIA_FORWARD . Pode haver outras chaves de mídia que podem usar um prefixo MEDIA .

Devemos considerar a mudança de String begins_with() para starts_with() .

É assim em Java, C #, Python, JavaScript, etc.

Edição do Bugsquad: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool , float , int são os únicos tipos / classes cujos nomes começam com uma letra minúscula. Acho que eles deveriam ser renomeados (em GDScript) para Bool , Float , Int . Isso corrigirá automaticamente o problema com o realce de sintaxe de tipo incorreto.

E bool , float , int deve ser usado apenas para funções do tipo Python integradas da página len e str ).

Observe que a situação é semelhante com str / String : str(x) e String(x) dando o mesmo resultado.

ADICIONAR. Deveria ser assim:

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

@dalexeev Estão em letras minúsculas porque são tipos primitivos. Você verá isso na maioria dos outros idiomas.
Aulas como Node são tipos de referência e não são copiados na tarefa.

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

Devemos considerar renomear String para string pois String não é mutável e se comporta de forma mais semelhante a int do que Node .

Redigindo isso por agora, já que esse também seria o caso de Vector2 , Vector3 , etc.

@nathanfranke Em diferentes idiomas é diferente. Por exemplo, em Kotlin, Haxe, os nomes de Ada de todos os tipos são escritos em maiúscula.

Além disso, a primitividade é um conceito condicional. Para mim String , Color , Vector2 , etc. são tipos primitivos, especialmente porque são passados ​​por valor e não por referência.

O único obstáculo é a violação da compatibilidade com versões anteriores.

já que String não é mutável

Surpreendentemente, as strings no GDScript são mutáveis:

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

Vector2 não é um primitivo porque é composto por 2 float . No entanto, Vector2 e float são tipos de variantes incorporados .

@Zylann É uma diferença tão fundamental que deveria estar refletida no nome do tipo?

(Para mim, 'primitivo' é 'simples', não 'uma peça única'.)

Não quero interpretar isso a meu favor, mas:

nomes de tipos primitivos são capitalizados. :sorriso:

Aqui estão os termos como eu os entendo:

| Nome do tipo | Tipo primitivo | Tipo de valor | Tipo mutável | Tipo embutido |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| int | Sim | Sim | N / A | Sim |
| Vector2 | Não Sim | N / A | Sim |
| Node | Não Não Sim | Sim |
| String | Não Não Não Sim |

Independentemente disso, esses nomes não serão alterados. Eles estão bem no estado em que se encontram e são familiares para programadores de várias linguagens. Devemos encerrar a discussão aqui para evitar encher este rastreador com discussões inúteis.

A coluna do tipo mutável está errada: apenas derivado de objeto, dicionário e matriz são mutáveis. ( Vector2 pode parecer mutável, pois você pode fazer vec2.x = 0 , mas na verdade se traduz em algo como vec2 = vec2.with_x(0) )

Renomear ShortCut para Shortcut

Os seguintes métodos devem ser alterados
Inconsistências entre

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

para

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

para consistência com
e

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

precisa ser corrigido.

PS : Parti do princípio "Quanto menos métodos semelhantes, melhor".

@dalexeev Os parâmetros booleanos são geralmente menos legíveis do que ter métodos diferentes, uma vez que true e false não têm contexto.

Sim, mas consistência também seria bom. Livrar-se dos parâmetros booleanos em InputEvent, então?

@Calinou Na maioria dos casos, você não precisa verificar eventos de eco.

Não vejo isso como um grande problema. Quando você digita o código, a dica do argumento é exibida. Ao ler o código, você pode usar Shift + Clique. Os argumentos para funções usadas com frequência são fáceis de lembrar (por exemplo, String.split ).

Além disso, 208 argumentos booleanos opcionais foram encontrados no diretório doc/classes (este é apenas o núcleo, e também 16 módulos têm um diretório aninhado 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 você pode considerar colocar isso em um spoiler para tornar a rolagem mais fácil para nós?

@dalexeev Existem muitos casos em que é necessário verificar se uma tecla foi pressionada e não apenas se acabou de ser pressionada. Por exemplo, um script para mover um personagem precisa fazer isso com WASD ou as teclas de seta. Quase todo jogo precisará processar entrada, então não acho que seja um desperdício ter apenas dois métodos para essas coisas.

Ao ler o código, você pode usar Shift + Clique.

Não se você estiver vendo diffs no GitHub. Se o código requer um IDE para ser legível, não é um bom código.

@aaronfranke Para os outros 207 casos, você também sugere a criação de funções separadas? Se não, então este argumento não é conclusivo. Além disso, escrevi acima que, se você pode especificar o nome do parâmetro, ele se torna legível sem um IDE.

Existem muitos casos em que é necessário verificar se uma tecla foi pressionada e não apenas se acabou de ser pressionada.

Freqüentemente, mas não com mais freqüência do que sem eco.

A presença de três métodos ( is_action_just_pressed , is_action_just_released , is_action_pressed ) é confusa porque você espera que haja um método is_action_released .

ADICIONAR. Qual opção é mais fácil, pelo menos visualmente?

is_action_released pode ser alcançado com not is_action_pressed . Isso não é verdade para os métodos just .

Como mencionado acima, bools brutos devem ser evitados. Um sinalizador como INPUT_ALLOW_ECHO / INPUT_NO_ECHO seria muito melhor do que um bool.

@dalexeev Isso apenas introduziria confusão. is_action_pressed() e eco são 2 coisas diferentes. Você pode verificar se os eventos de eco são recebidos após um pequeno atraso após o primeiro toque, enquanto is_action_pressed() não tem atraso.

@KoBeWi Você pode estar certo e

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

deve ser alterado para

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

uma vez que isso não é consistente com

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 O que você propõe não está correto. Quando falamos sobre eventos de eco, falamos sobre eventos repetidos de teclado enquanto pressionamos uma tecla, usar o termo aqui faz pouco sentido, uma vez que o sistema de ação não depende do evento diretamente, seu estado é atualizado por quadro. Além disso, as ações também podem funcionar com outros dispositivos, como controladores ou botões do mouse, onde o evento "echo" não existe.

O get_children () de TreeItem retorna apenas o primeiro filho e nem todos os filhos como o nome (ou a descrição nos documentos) sugerem.

[Editar]
Nvm the docs. A descrição do método é atualizada no master, desculpe.

Eu recomendo que local_to_scene do Resource deve ser local_to_instance ou unique_per_instance . "Local to Scene" denota o comportamento como local para a cena, quando na verdade é por instância de uma cena.

Renomear Image.load() → Image.load_from_file() .

1. Ajuda a aliviar possível confusão com load("image.png") arquivos via código, consulte as alterações na documentação em # 42412.
2. Image.load() não será mais destacado como um nome GDScript embutido: # 28866.
3. Consistente com Image.load_*_from_buffer() por formato de imagem. Os métodos relacionados ao buffer podem ser potencialmente unificados na mesma interface para evitar o inchaço da API, mas esse é outro tópico para discussão.

@Xrayez Também pode valer a pena remover load no GDScript: https://github.com/godotengine/godot-proposals/issues/263

A variável registering_order e o método relacionado set_registering_order em ProjectSettings não são usados.

RandomNumberGenerator deve ser renomeado para Random e funções aleatórias globais como randf e rand_range devem ser descontinuadas ou removidas.

Eu vejo possíveis problemas onde alguém chama uma função não confiável enquanto a semente aleatória é especificada

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

funções aleatórias globais como randf e rand_range devem ser descontinuadas ou removidas.

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

Eu preferiria que esses métodos aleatórios básicos estivessem em um escopo global para fins de acessibilidade e prototipagem, pelo menos alguns deles. Mas seed() e rand_seed() podem ser removidos com certeza.

Parece que FuncRef se tornou redundante desde que Callable foi adicionado.

Eu descobri os métodos property_can_revert e property_get_revert no Inspetor e os relatei em # 43078. No entanto, acho que eles devem ser renomeados com sublinhados à esquerda para seguir as convenções de _get , _set e _get_property_list .

EditorImportPlugin e EditorExportPlugin parecem estar relacionados, porém um é sobre importação de recursos e o outro é sobre exportação de um projeto. Sugiro renomear EditorImportPlugin para EditorResourceImportPlugin ou algo parecido.

Editar: E EditorPlugin.add_import_plugin deve ser renomeado de acordo.

Por que não ResourceImportPlugin ? Muitas (a maioria?) Classes de editor já não contêm a palavra "Editor", como SceneTreeDock ou todas as coisas de animação.

O Tracking_status enum em ARVRInterface deve ser renomeado para TrackingStatus , para ser consistente com os estilos de outros nomes de enum.

Olhando para ARVRInterface acima, a qualidade dos nomes é muito baixa em geral. Aqui estão minhas sugestões de renomeações também:

• ar_is_anchor_detection_enabled → anchor_detection_enabled (propriedade)
• interface_is_initialized → initialized (propriedade, poderia ser reescrita para enabled , pois tem um setter)
• interface_is_primary → primary (propriedade)
• get_render_targetsize() → get_render_target_size() (método)
• uninitialize() → finalize() (método)

Caso contrário, a documentação está errada. 🙂

Observe que eu nunca usei essa classe, mas esses nomes parecem estranhos apenas de olhar para a classe.

Devemos renomear Control.MOUSE_FILTER_PASS para Control.MOUSE_FILTER_PASSTHROUGH ? Isso tornaria mais óbvio que o evento será passado através do nó de controle para os nós localizados abaixo dele. Não tenho certeza se vale a pena renomeá-lo, no entanto.

@Calinou Não imagino que

@Calinou Acho o comportamento atual incomum. Esta configuração de cena produz "Click Child2, Click Scene"

(Observe, todos estão configurados para Pass)

: smile: Proposta A : Talvez algo como Control.MOUSE_FILTER_PASSPARENTS para o comportamento atual, uma vez que os eventos de entrada parecem ser enviados apenas aos pais.

: rocket: Proposição B : Altere as constantes para estas:

• STOP: Current Behavior - Take event e parar toda a propagação
• PASS_PARENT: Mesmo comportamento que PASS atualmente
• PASS_ALL: IGNORE, mas leva eventos
• IGNORE: comportamento atual - não toma evento, mas ainda se propaga

: olhos: Proposição C : Se o nó recebe ou não entradas gui não é realmente relevante, já que não se pode simplesmente conectar nenhum sinal (ou usar um sinalizador booleano). Podemos alterar a opção para Control.propagation_mode e ter estas constantes:

• NENHUM
• PAI
• TUDO

Isso pareceria muito mais limpo na minha opinião.

Isso está além da renomeação e deve ser discutido como uma proposta.

Por que todas essas renomeações são tão longas? Você está mudando algo simples e curto para algo muito longo.

Você está alterando clip para intersection duas vezes mais para digitar.
Você também está mudando Control.MOUSE_FILTER_PASS para Control.MOUSE_FILTER_PASSTHROUGH
etc

Eu preferiria mudanças mais simples e mais curtas e menos detalhadas. É um nome de função, não também uma descrição da função.

Eu preferiria mudanças mais simples e mais curtas e menos detalhadas. É um nome de função, não também uma descrição da função.

O nome deve ser descritivo. Além disso, o comprimento não importa se você tirar vantagem do preenchimento automático (que está embutido no editor Godot).

Eu mencionei isso uma vez no IRC e não obtive uma resposta, mas TextureRect tem um modo de extensão chamado "Scale On Expand (Compat)". Isso soa como algo que pode ser removido.

"Menos prolixo" definitivamente não está no menu se quisermos ter bases de código robustas em nossos projetos Godot. Ferramentas de codificação modernas fornecem preenchimento automático e outros recursos inteligentes que permitem que você digite rapidamente, mesmo se o nome for longo. Além disso, se você ler os argumentos para essas mudanças, há um objetivo de tornar essas funções menos ambíguas para os desenvolvedores que as usam. O nome curto pode ser agradável, mas confuso e menos detectável.

E lembre-se sempre: digitar o código é a parte rápida do desenvolvimento de software. Ler e entender o código depois é muito mais importante. É como conceber e criar um filho, respectivamente.

Eu discordo de vocês dois. Eu sou um usuário Godot e uso Godot especificamente porque GDScript é conciso e rápido de escrever. Se você fizer o dobro do tempo, a vantagem da velocidade será perdida, pois serei forçado a escrever o dobro e teria que rolar o dobro para ver toda a linha de código horizontalmente.

Quando você está codificando, não quer digitar nomes de funções ou variáveis ​​incrivelmente longos. Algumas dessas alterações propostas adicionam nomes de funções e variáveis ​​extremamente longos para "clareza" em detrimento de todo o resto. Você pode ler a ajuda integrada se tiver alguma dúvida. Além disso, programar é aprender uma API. Você sempre pesquisará uma função na primeira vez que a usar, independentemente do nome. Considerar printf em C é conciso e simples. Em Godot, você a chamaria de send_formatted_string_to_standard_out. Não apenas você está forçando todos a reaprender a API, mas algumas dessas mudanças nem mesmo têm uma visão unificada. Parece-me que um monte de pessoas se juntou e cada uma trocou uma parte do motor.

Pegue o Array, por exemplo
remove -> remove_at O que _at adiciona aqui? Você já tem remove_value. O que mais você pode remover?
erase -> remove_value Ainda não está claro o suficiente. Em documentos "Remove a primeira ocorrência de um valor da matriz." Além disso, as pessoas podem pensar que você pode remover um único valor de todo o array. Para maior clareza, deveria ser remove_first_occurance_of_value porque é isso que a função realmente faz. Então você tornou a função mais longa e igualmente confusa, apenas mais longa.

Você tem remove e erase duas funções diferentes, mas as transforma na mesma variação em remove com letras extras. Mas eles funcionam funcionam de forma diferente. Remover remove de um índice específico onde como apagar remove a primeira instância de um valor encontrado.

Tudo bem, mas não é realmente útil, a não ser forçar as pessoas a atualizarem seu código.
inverter -> inverter
duplicar -> clone
vazio -> is_empty

Se não estiver quebrado, não conserte.

@CarlGustavAlbertDwarfsteinYung, mas você não vai digitar o dobro. Depois de digitar as primeiras 3 letras, autocopletion vai entrar em ação e você seleciona o que precisa ao invés de digitar palavras inteiras.

Quanto a outros nomes, por exemplo, quando você der uma olhada em empty -> is_empty mudança é necessária para fornecer um esclarecimento sobre o que ele faz. Quando você olha para empty você pode dizer se este é um método que esvazia algo, é um livro que verifica se algo está vazio, é outra coisa? Com is_empty você pode ver rapidamente que este é um bool que é verdadeiro se algo estiver vazio e falso quando não está. Você deve saber o que função ou variáveis ​​fazem apenas lendo seus nomes. Você não pode fazer isso com nomes como empty

@Feniks-Gaming, posso dizer que empty ou is_empty são igualmente confusos, apenas um é mais longo do que o outro.

@CarlGustavAlbertDwarfsteinYung empty pode ser uma ação se for lida como um verbo. is_empty é definitivamente uma qualidade. Claro que essa confusão pode depender do seu nível de inglês.

Além disso, mesmo se uma função foi chamada send_formatted_string_to_standard_out em um editor de código moderno, ela pode ser digitada como sfstso , ou qualquer outra combinação das letras intermediárias, se você desejar e o preenchimento automático fornecerá a única opção.

@pycbouh As pessoas usam esse mecanismo há quantos anos? E eu não ouvi uma pessoa vir até mim dizendo que você sabe qual é o maior problema com este motor. O fato de que os arrays têm empty vez de is_empty .

Vocês estão sentados aqui consertando coisas que ninguém queria ou pediu. Sim, o texto é confuso, mas não é realmente um problema e nunca foi um problema desde que comecei a usar este mecanismo em 2015. Algumas das alterações propostas são bem-vindas e para ser justo eu uso is_. Se estiver vazio, tudo bem. Mas algumas mudanças são muito longas e igualmente confusas. Eu estava falando especificamente sobre essas mudanças, não todas.

Toda a existência deste megathread é a evidência de que as pessoas estão pedindo por ele. Esses problemas podem ser insignificantes para você ou outra pessoa, mas as pessoas têm problemas em entender a API por causa de nomes incorretos. E esse é o tipo de problema que essa edição coleta. Quanto à importância dessas mudanças em geral, acredite ou não, mas rastrear e implementá-las não está tirando do outro tempo de desenvolvimento.

E veja o exemplo que você deu e tentou explicar:

Remover remove de um índice específico onde como apagar remove a primeira instância de um valor encontrado.

Você escreve isso e não vê razão para melhorar a nomenclatura para ser pelo menos um pouco mais claro para todos os usuários atuais e futuros do Godot?

@pycbouh E na verdade eu até dei o exemplo do array remove_at e remove_value . remove_value não é o mesmo que a descrição de apagar e ainda é igualmente confuso. Remover valor de onde? Remover valor do final, remover do início? Remover todas as ocorrências de um valor da matriz?

se você realmente precisa mudar as coisas, use remove e remove_first_occurence que o torna conciso e descritivo.

@pycbouh Não estou pedindo por isso. A existência desse thread é porque algumas pessoas estão sobrecarregadas de engenharia e consertando coisas que não estão quebradas no estilo clássico de programador. E quanto aos futuros usuários? E eles? Já fui um futuro usuário e aprendi a API. Não tive problemas com a nomenclatura de funções. 50% dos comentários são pessoas que discordam das alterações propostas. Parece que a maioria dessas mudanças são impulsionadas por um pequeno número de membros da comunidade empurrando essas mudanças para todos. Podemos votar nas mudanças propostas?

Na verdade, aqui está uma proposta. Quaisquer alterações na nomenclatura da API devem incluir opiniões de contribuidores / doadores / usuários. Se todos concordarem, também estou a bordo. Faça enquetes e veja o que todo mundo faz. Não tente adivinhar o que as outras pessoas desejam. O que é bom para você pode não ser bom para outra pessoa.

Sou contra cerca de 50% das mudanças propostas aqui pelo que tenho visto.

50% dos comentários são pessoas que discordam das alterações propostas.

Podemos deixar as estatísticas inventadas na porta, por favor?

Podemos votar nas mudanças propostas?

É para isso que servem a discussão e as reações.

Sou contra cerca de 50% das mudanças propostas aqui pelo que tenho visto.

Se você for contra eles apenas porque "aprendi assim, então quero que todos depois de mim sofram o mesmo", então é uma crítica inválida à proposição e será ignorada.

O que é bom para você pode não ser bom para outra pessoa.

Idem.

Podemos deixar as estatísticas inventadas na porta, por favor?

Gosta dessa afirmação sobre toda a comunidade?

Esses problemas podem ser insignificantes para você ou outra pessoa, mas as pessoas têm problemas em entender a API por causa de nomes incorretos.

Como você sabe com que as pessoas têm problemas? Você perguntou a eles? Houve uma enquete, estudo ou questionário sobre isso? Como você obteve essa informação?

Eu sou um desses usuários, comecei do zero e aprendi a API. Não tive problemas com a nomenclatura. Todas as APIs têm algumas convenções de nomenclatura estranhas. Todas as funções precisam ser um tanto concisas para que você possa escrevê-las em código.

@pycbouh Se você está tentando me convencer de que todas as sugestões de nomes aqui apresentadas são boas, terei que discordar respeitosamente de você. Este é um tópico que discute mudanças e eu estou aqui para dizer que algumas das mudanças propostas não são apenas desnecessárias / ou solicitadas, mas apenas mais longas e igualmente confusas. Alguns são realmente bons e são bem-vindos. Não vamos renomear tudo em massa só porque algumas pessoas como você pensam que toda a comunidade tem problemas com nomes de API. Eu não fiz e nunca tive e comecei como um iniciante. E eu conheço um punhado de outras pessoas que também não. Acredito que algumas dessas mudanças são significativas e devem ser revisadas por pares por toda a comunidade ou pelo menos por colaboradores antes de um lançamento completo.

Como você sabe com que as pessoas têm problemas? Você perguntou a eles?

A maioria das entradas neste tópico são geradas por pessoas que vêm com problemas, seja aqui no GitHub (e nesses casos os problemas estão vinculados) ou usando outra comunidade ou canais pessoais. Não presuma que estamos apenas sentados aqui lambendo nossas próprias partes íntimas porque não temos nada melhor a fazer a não ser refletir sobre que outra função ou propriedade devemos renomear no motor.

Além disso, muitas das mudanças propostas aqui nem mesmo foram postas em prática, não houve PRs ou qualquer outra atividade. Eles estão listados e é isso. Fique de olho nos RPs e, se aparecer algum ofensivo, não hesite em comentar. Depois disso, cabe ao PM de Godot aprovar e mesclar as alterações. Seja construtivo e você pode evitar algumas modificações indesejadas, mas não se esqueça do que você mesmo disse uma vez:

O que é bom para você pode não ser bom para outra pessoa.

Portanto, mesmo que você não tenha tido problemas com a API até este ponto, isso não significa que os outros não tiveram nenhum ou que não teriam problemas no futuro.

Todas as APIs têm algumas convenções de nomenclatura estranhas.

Isso é bom se houver uma convenção para falar. Mas algumas das APIs em Godot foram nomeadas muito antes de se tornarem código-fonte aberto e podem não ser tão bem pensadas quanto seria de se esperar. Mais uma vez, peço que você não presuma que as pessoas aqui sugiram mudanças.

Por favor, não tenha esse tipo de discussão aqui. Se você deseja discutir alterações específicas da API, tudo bem, mas as declarações gerais de que você não gosta das sugestões aqui não são úteis.

Os desenvolvedores principais revisarão cada uma dessas sugestões, uma por uma. É provável que muitos acabem não sendo aceitos.

Bloqueando temporariamente, irá desbloquear mais tarde.

Poderíamos ter os seguintes pontos adicionados à lista?

• AnimationPlayer : Renomear stop() para pause() (https://github.com/godotengine/godot/issues/16863#issuecomment-562363660, godotengine / godot-propostas # 287)
• AnimatedSprite : Renomear stop() para pause() (# 31168) (já adicionado)
• AnimatedSprite3D : Renomear stop() para pause() (# 31168) (já adicionado)
• Tween : Renomear stop() para pause() , stop_all() para pause_all() (PR # 41794, # 43442)

Tween: Renomeie stop () para pause (), stop_all () para pause_all () (# 43442)

Isso é coberto por # 41794

@ opl- isso também é discutido aqui: https://github.com/godotengine/godot-proposals/issues/287

Algumas renomeações que podem deixar mais claro o que essas funções RNG de escopo global fazem:

• seed() -> set_seed() (talvez adicione get_seed() também para corresponder a RandomNumberGenerator) - Atualmente, não está claro se esta é uma função setter.
• rand_seed() -> rand_from_seed() - atualmente, parece que pode tornar a semente aleatória ou algo assim, quando na verdade dá um número aleatório com base na semente fornecida.

rand_seed () -> rand_from_seed () - atualmente, parece que pode tornar a semente aleatória ou algo assim, quando na verdade dá um número aleatório baseado na semente fornecida.

Exceto que torna a semente aleatória. Leia a documentação.

rand_seed () -> rand_from_seed () - atualmente, parece que pode tornar a semente aleatória ou algo assim, quando na verdade dá um número aleatório baseado na semente fornecida.

Exceto que torna a semente aleatória. Leia a documentação.

Desculpa. O que eu quis dizer é que parece que apenas randomiza a semente. Talvez devesse ser rand_int_from_seed() , já que retorna um int? Na verdade, os documentos não especificam o tipo de retorno, mencionando apenas um "número aleatório ...". É um int?

Então ele gera uma nova semente com base em uma semente que você passa e depois gera um novo número com base nessa nova semente? Não tenho certeza sobre uma renomeação, mas a descrição pode usar algum retrabalho lá, se é o que está acontecendo.

Se for assim, parece que este método deve ser dividido em 2 métodos menores que fazem uma coisa em vez de serem renomeados

Control :: pending_resize

Não utilizado.

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

Eu entendo agora que este método é principalmente equivalente a GDScript is (que era extends btw), mas C ++ requer mais explicitação.

A confusão que encontrei é verificar se determinado objeto é do tipo existente ( sem herança):

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

A implementação subjacente usa macros / modelos "herdam" em todo o lugar, então faz sentido para mim renomear isso para inherits_class .

Veja também https://github.com/godotengine/godot/issues/21461#issuecomment -416155187:

get_class() e is_class() são confusos para mim em geral