Uso Godot profissionalmente há mais de um ano.

Eu concordo com tudo o que você disse, exceto:

Para alguns, acho que devemos manter a forma atual

Se tivermos essa oportunidade de ouro, vamos renomear tudo. Isso inclui Sprite2D e MeshInstance3D.

É sempre melhor um refatorador doloroso completo do que muitos refatores dolorosos parciais.

Por falar em renomeação: https://github.com/godotengine/godot/issues/16863

@ jahd2602 Pessoalmente , não me importo, podemos pesquisar isso no pior dos casos.

Eu definitivamente posso ver as pessoas incomodadas com isso simplesmente pelo fato de que é uma inconsistência, mas podemos pelo menos ver se eles são maioria ou minoria.

@Zylann Eu sei, se decidirmos algo aqui, vamos mover isso para lá.

Acho que a postura contra os namespaces é míope. Faz sentido da perspectiva do fluxo de trabalho do motor em geral, mas ignora a perspectiva dos criadores de ferramentas. O Godot Unit Testing (GUT) por bitwes, por exemplo, quebrou devido a um conflito de nomenclatura em uma de suas atualizações. É provável que isso pudesse ter sido evitado com um namespace GUT dedicado.

Eu também gostaria de namespaces para Waiting And Testing (WAT) para que eu pudesse usar nomes de classe como Test (acessado via WAT.Test) enquanto não executava outras estruturas (como GUT se fosse usar GUT.Test) ou apenas o script do usuário. Eu tentei várias vezes usar uma classe WAT que continha todos os scripts usados ​​como subclasses, mas isso é apenas um inferno de referência cíclica.

Se devemos ser encorajados a construir ferramentas de dentro do motor, então precisamos das ferramentas para fazer essas ferramentas no motor, mesmo que não sejam absolutamente necessárias para o próprio fluxo de trabalho do motor.

Em resumo, um sistema de namespace dedicado que pode ser acessado e definido a partir do motor (ou pelo menos o script do plug-in) para que os fabricantes de ferramentas não acabem se atrapalhando ou seus usos seriam uma dádiva de Deus.

@CodeDarigan Eu entendo que tem benefícios e não os estou negando, mas sinceramente acredito que os custos os superam.

Acrescente a isso que praticamente não tivemos reclamações significativas de usuários de GDScript, que preferem a abordagem atual, então isso os forçaria a um fluxo de trabalho indesejado e digitaria mais código em uma linguagem que se destina apenas a escrever coisas rápidas e sujas rapidamente. (Os usuários de C # parecem desejá-los, no entanto).

É por isso que quero dizer que eles podem existir como metadados para associações de linguagem de script e podemos até adicioná-los para GDNative C ++. Apenas não os adicione para o mecanismo C ++ principal.

Navegação -> Nagivagion3D
Isso é um erro de digitação?

@nitodico de fato

@reduz concordo com @ jahd2602. Mesmo que algumas coisas possam ser óbvias, para fins de consistência, devemos postfixar com 2D ou 3D.

Ainda estou começando com Godot e as alterações propostas parecem sensatas para mim - usar nomes sutilmente diferentes para a variante 2D ou 3D de um nó é algo que me causou um pouco de confusão enquanto aprendia qual extremidade era e passava para Thing2D / Thing3D ou Thing / Thing3D parece uma melhoria significativa em termos de clareza e compreensão.

Por favor faça.

Tbh essa mudança viria de qualquer maneira, então melhor fazer isso agora e ficar com ela. Para o 3d, não há tantos tuts assim, agora a mudança causará menos danos do que em um, dois anos depois.

Em relação aos materiais, seria bom ter algum tipo de Material Legado que usasse apenas recursos mínimos, como difuso e especular, isso seria útil para jogos 3D para celular.

Também sou a favor de renomear as coisas para serem explicitamente 3D ou 2D.

Não seria possível que os nomes originais ainda existissem como apelidos para os novos? Eles seriam ocultados do editor para que os nomes antigos não pudessem ser usados ​​(ou colocados sob o título "obsoleto"). Dessa forma, o código antigo ainda funcionaria, sem alterações e sem a necessidade de lógica adicional para converter nada.

Um aviso pode ser adicionado para o código usando os nomes de nós obsoletos e, em seguida, em 4.1 ou 4.2 eles podem ser removidos.

Se houver duas versões de um nó, eu sempre acrescentaria o sufixo 2D / 3D.

Além disso, eu ficaria feliz se Label -> TextLabel. Vou adicionar um nó para mostrar algum texto, então digito texto na barra de pesquisa e, claro, apenas RichTextLabel aparece, o que me lembra que o nó de texto padrão não tem realmente Texto no nome.

@ Janders1800 é assim que funciona agora, quanto menos recursos você usa no SpatialMaterial, menor é o sombreador que ele cria.

Eu sou uma pessoa 2d, portanto, para nós com aplicação principalmente 2d, manter os nomes dos nós sem um sufixo se já não tiver um parece bom para mim. Esta parece ser uma refatoração mais dolorosa para usuários 3D, mas faz muito sentido onde certos nós têm apenas um aplicativo 2d ou 3D na maioria das vezes que mantêm o nome mais curto para o domínio pretendido e têm um sufixo em outro lugar. Qualquer outra coisa que possa ser unificada seria bom ver unificada, especificamente Spatial .

Sou a favor do uso incondicional dos sufixos 2D / 3D também.

Embora seja verdade que para alguns nós parece uma oportunidade perdida de ter nomes mais "naturais", a consistência vence.

O que eu não gosto é que StandardMaterial3D não é ORM. Meu ponto é que ORM é mais fortemente apoiado por um padrão (pelo menos RM, que é o que você tem em glTF).

Mas ainda não posso sugerir uma nomenclatura melhor.

Talvez esta também seja uma oportunidade de fazer algo sobre a 'tela'. Achei esse conceito um pouco confuso às vezes.

Eu sei que é difícil, porque não tem contrapartida 3D: cenas 3D vivem em Spatial nodes, mas telas podem conter uma mistura de Node2D s e Control s.

No entanto, seria ótimo se pudéssemos definir alguns nomes que permitissem renomear CanvasItemMaterial para Material2D , mantendo-o significativo para o 2D "puro" e os reinos GUI.

Não sou necessariamente contra renomear, mas os nomes originais fazem sentido para mim, talvez por causa da minha formação.
O padrão em física ou engenharia é "3D". Você não diz um "corpo cinemático 3D", você diz um "corpo cinemático", a menos que esteja trabalhando em algum outro espaço.
No entanto, tenho certeza de que nem todos têm a mesma formação ou até concordam com isso, já que, afinal de contas, este é o motor do jogo e não precisa seguir estritamente as convenções de física ou engenharia.

para compatibilidade futura, em gdscript

um arquivo gdscript ...

estende Espacial
class_name Node3D

E assim por diante.

Você já pensou em renomear translation para nós espaciais para position ?

@BeayemX Acho que tradução é um termo comum para espaço 3D e posição é comum para desenvolvedores 2D: pensando:

Não sei se 4.0 será o melhor para mudanças de nomes de nós, haverá muitas coisas para lidar e muitas mudanças de 2 para 3, isso significa descontinuar livros, vídeos, cursos.
Mesmo a documentação não está completa, com mudanças no meio da conclusão, as correções vão atrasar muito as coisas ...

Sou a favor de renomear nós 3D conforme sugerido aqui. Não sei o quanto isso será um problema para os fabricantes de tutoriais. No mínimo, deve ser trivial refatorar as bases de código existentes. Em C #, podemos até abusar de ObsoleteAttribute no modo de depuração para torná-lo mais fácil (mas não tenho certeza se é uma boa ideia):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

Espero que adicionemos namespaces / categorias conforme discutido em # 18711. Quero separar a API C # em namespaces e talvez também em assemblies para possibilitar que os usuários escolham apenas o que precisam.
Meu plano para o 4.0 era codificar uma tabela de namespaces sozinho, se não houvesse outra escolha, mas eu preferiria que, em vez disso, pudesse obter essas informações de ClassDB.

@ eon-s Não acho que seja ... enquanto translation é tecnicamente válido para representar coordenadas, Godot é o primeiro motor onde vejo um termo diferente sendo usado aqui, caso contrário, sempre vi position independentemente de 2D ou 3D. Além disso, para mim translation está associado a movimento e está em conflito com outro termo relacionado à linguagem / transformação, o que o torna estranho. Isso também foi mencionado em https://github.com/godotengine/godot/issues/16863 .

Aliás, por que planejamos quebrar o mínimo possível? Eu entendo porque as pessoas não querem mais quebras de compatibilidade, especialmente aquelas que fazem tutoriais; mas se não aproveitarmos o 4.0 como uma oportunidade para quebrar a compatibilidade, quando vamos fazer isso? # 16863 já está acumulando muitas sugestões.

@neikeq não pode esperar por 5.0? já que nenhum recurso novo ou grande está planejado, caso contrário, as pessoas vão parar de fazer coisas e de comprar cursos para um motor que muda peças importantes a cada 1 ou 2 anos (para criadores de tutoriais em vídeo, isso significa refazer todo o seu trabalho) e com alguns meses de aviso ...

Sou a favor da renomeação para ter um sufixo 2D / 3D consistente e concordo com muitos neste tópico que isso deve ser feito para todos os nós para consistência. Ter uma convenção de nomenclatura consistente é extremamente útil para alguém que está aprendendo o mecanismo ou mudando do lado 2D para o 3D, ou vice-versa.

@ eon-s Com certeza, esperar até o 5.0 significa que haverá um corpo ainda maior de trabalho que precisa ser atualizado.

Por mais que os tutoriais sejam maravilhosos, eu votaria em tornar o mecanismo mais compreensível em vez de mantê-lo confuso por causa dos tutoriais existentes. Esperançosamente, scripts de correção ou aliases opcionais (conforme discutido anteriormente) podem ser usados ​​para suavizar o caminho de atualização.

Eu aprecio a diferença na nomenclatura entre Node e Spatial porque os nós de Node não têm conhecimento de espaço, ter Node, Node2D e Node3D seria confuso. A menos que você planeje se livrar do Node, então faria todo o sentido.

Eu sou por ter apenas um reino 2D ou 3D tendo que suportar ter um sufixo. No momento é 2D e a confusão entre 2D e 3D termina aí.

Não adicione o sufixo 3D. Vale realmente a pena a dor de cabeça pelo que isso acrescenta? Vale a pena o custo? de atualizar tudo ou ter tutoriais desatualizados? Tutoriais do youtube inalteráveis ​​e desatualizados? Isso trará mais confusão.

@dpalacio Estou usando Godot há apenas alguns meses, mas acho que é mais claro e conciso usar Node3D, Node2D e Node porque o Spatial atua como um Node3D e o Node não tem informações de espaço. Acho que adicionar sufixo para 3D será muito mais simples de entender, pois será denominado de forma "oposta". Sei que não são realmente opostos, mas não sei como me expressar melhor porque o inglês não é minha língua nativa. Colocar 3d versus 2d explicitamente parece ótimo para mim. Acho que será muito mais fácil para os iniciantes, e ainda mais para as pessoas que estão tendo o primeiro contato com uma engine de jogo. Os namespaces também são ótimos, principalmente para grandes projetos e plug-ins. Nomes conflitantes são uma dor de cabeça. Como um iniciante, acho que a quebra de compatibilidade deve ser mínima e automática porque é difícil manter a mudança de projetos entre as versões. Se tivermos muitas mudanças, precisaremos ter uma ferramenta de conversão automática e documentação para isso também.

@neikeq sim, a categoria deve ser substituída por namespace e devemos fazer os adequados.

Exatamente o que eu estava pensando quando experimentei Godot. Meu TOC me diz que deveria ser assim.

Você já pensou em renomear translation para nós espaciais para position ?

'posição' soa mais como uma posição absoluta em vez de uma posição relativa.
Chamar de posição pode ajudar novos desenvolvedores, mas, eventualmente, eles perceberão que deve ser chamado de tradução.

Estou meio em cima do muro com essa proposta, como alguém que está escrevendo tutoriais do Godot e usando o Godot para meus próprios projetos completos.

Sou totalmente a favor de alterar os nomes dos nós para permanecer consistente e concordo com outros que a consistência é importante, mesmo que torne as coisas um pouco mais prolixas. Eu preferiria adicionar 3D ou 2D ao final / início dos nós se isso tornasse as coisas mais consistentes na base de código e na documentação.

Aqui estão alguns nós que gostaria de ver alterados para permanecer consistente:

• MeshInstance -> MeshInstance3D (para permanecer consistente com MeshInstance2D )
• GridMap -> TileMap3D ou GridMap3D
• TileMap -> TileMap2D ou GridMap2D
• YSort -> YSort2D ou 2DSort (ou algo para mostrar que é para 2D)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (ou algo para mostrar que é para 3D)
• ReflectionProbe -> ReflectionProbe3D (ou algo para mostrar que é para 3D)
• SpatialMaterial -> PBRMaterial ou Godot3DMaterial ou StandardMaterial3D (apenas ideias)
• Label -> TextLabel (concordo com @MuffinManKen)

Aqui estão meus pensamentos sobre esta proposta, começando com os pontos positivos:

Acho que essa mudança tornará as coisas mais fáceis para aqueles que não têm experiência em Godot, mas apenas para aqueles que vierem depois dessas mudanças. Especialmente no lado 3D, um dos maiores problemas que encontro é que pode ser difícil encontrar de quais nós você precisa, e acho que renomear os nós usando um esquema de nomenclatura consistente tornará isso muito mais fácil para todos.

Muitas das vezes que ajudo outras pessoas com Godot, acho que uma das maneiras mais infalíveis de encontrar uma solução é consultar a documentação. No entanto, como os nomes dos nós nem sempre são consistentes, encontrar a página de documentação pode ser difícil para alguns nós, a menos que você já saiba o nome do nó que está procurando. As mudanças nesta proposta tornariam muito mais fácil encontrar o nó correto.

Outro benefício que posso ver com essa mudança é que ela define um padrão sobre como os nós devem ser nomeados, o que pode ser útil para os criadores de plug-ins e futuras contribuições do Godot Engine. Por exemplo, se estou fazendo um nó de decalque (por exemplo), então, com essa mudança, sei que devo nomeá-lo como Decal3D vez de apenas Decal .
Isso também pode ajudar com a nomenclatura de classes definidas em GDScript / C #.

Isso também tornaria a escrita de tutoriais no futuro um pouco mais fácil, já que você não precisa mais explicar que Spatial é basicamente um Node2D em 3D.

Agora, para os negativos:

Um dos maiores problemas que tenho com esta proposta é que parece muito cedo, especialmente considerando o quanto Godot 3.0+ mudou as coisas não muito tempo atrás. Acho que apenas alguns jogos usando Godot 3.0+ foram lançados, e muito poucos jogos Godot 3D.
Muitos dos grandes e impressionantes jogos 3D do showcase Godot ainda não foram lançados, e fazer uma grande mudança como essa significa que esses projetos precisarão ser atualizados também, atrasando ainda mais alguns jogos Godot 3D realmente fortes.

Além disso, tutoriais do Godot 3.0+ ainda estão sendo lançados. Especialmente no lado 3D, as coisas estão começando a ganhar força. Embora isso seja em parte devido ao lado 3D de Godot se tornar mais forte no Godot 3.0+, temo que muito do material que os escritores de tutoriais estão fazendo (ou estão trabalhando) de repente precisará de uma reformulação massiva para dar conta das mudanças de nome. Isso levará tempo para criar novos tutoriais, pois os antigos terão que ser descartados, refeitos ou reescritos.

A mudança de nomenclatura também tornaria os recursos existentes que não são tutoriais, apenas soluções simples encontradas para problemas, repentinamente desatualizados. Enquanto o lado 2D de Godot é indiscutivelmente muito forte e provavelmente pode se adaptar rapidamente, a comunidade que usa o lado 3D é visivelmente menor. Ao alterar os nomes dos nós, temo que isso atrapalhe o crescimento do usuário 3D de Godot e a capacidade de encontrar soluções para problemas relacionados ao 3D.

Eu concordo com @ eon-s: essas mudanças não podem esperar um pouco? As coisas já estão mudando dramaticamente, pelo menos na base de código, com Godot 4.0. Acho que adicionar outra mudança massiva só tornará o desenvolvimento mais difícil e redefinirá muitos progressos que as pessoas estão fazendo com o lado 3D de Godot.

Assim que o Godot 4.0 for lançado, acho que trabalhar para renomear os nós na versão 4.1 ou 5.0 seria excelente, mas na minha opinião acho que adicionar outra grande mudança como essa vai causar mais danos do que ajudar.

Uma coisa que pode tornar essa transição melhor é ter um alias / período de transição, talvez de Godot 4.0 para Godot 4.1, por exemplo. Isso não tornaria os tutoriais e recursos (especialmente os 3D) obsoletos instantaneamente e daria a todos a chance de se adaptar às mudanças que viriam e, ao mesmo tempo, ser capazes de se beneficiar das mudanças no Godot 4.0.

Usar um alias / período de transição permitiria que alterações de quebra de compatibilidade fossem feitas sem forçar repentinamente todos a atualizarem de uma vez. Isso também permitiria que alterações de quebra de compatibilidade fossem feitas com mais frequência, já que, teoricamente, uma vez que um sistema estivesse em vigor para as transições, ele poderia ser usado novamente para futuras alterações de quebra de compatibilidade. Isso tornaria as coisas mais fáceis no futuro com as alterações listadas em # 16863.

TLDR: Eu sou totalmente a favor das mudanças, eu acho que deveria apenas esperar até Godot 4.1 ou um sistema / período de transição deveria ser feito para dar a todos tempo para se ajustar às mudanças.

Independentemente de como essa proposta acabe: Eu acho que Godot 4.0 será ótimo e estou ansioso por isso 🙂

@reduz eu digo vá em frente. E eu segundo @ jahd2602

Não sou um grande fã de fazer todos os nós 3D terminarem em "3D", mas claro, se todos quiserem. Eu acho que é bom manter nomes diferentes em vez de sempre ter um sufixo (ex: TileMap e GridMap)

Eu preferiria muito "posição" em vez de "tradução". O último pode ser confundido com localização e idiomas, e o primeiro é imediatamente claro e amigável para iniciantes. No entanto, Godot já não usa "origem" na maioria dos lugares para isso?

Também concordo com @neikeq que vale a pena quebrar a compatibilidade se for uma mudança benéfica para novos projetos. Eu pessoalmente adoraria ver a grande maioria das coisas em # 16863 implementadas.

(aliás, por que Sprite3D existe quando poderia ser apenas uma malha quad?)

@TwistedTwigleg Leia meu post, os projetos 3.0 abrirão bem no 4.0 se um sistema de compatibilidade interno for adicionado.

Boa mudança, como programador, fico feliz em ver o nome da contraparte o mais simétrico possível

Você pode explicar o que as texturas de estilo ORM significam com mais detalhes?

@reduz é a única diferença entre o material espacial padrão e o ORM, que você só tem um canal de textura (ao invés de 3 como é atualmente) com o ORM? Você ainda terá acesso aos mesmos parâmetros (em metálico e rugosidade) como especular e os multiplicadores? Não é usado com frequência, mas às vezes é usado para ajustar.

Eu gosto da ideia, mas me perguntando se é um exagero ter 2 tipos de materiais para uma mudança tão pequena. Em vez disso, poderia haver uma alternância para alternar entre 1 canal de textura para o modo ORM ou 3 para o estilo existente, usando um único material?

Recentemente, também coloquei o canal de profundidade (altura) no canal alfa de meus mapas ORM para obter mais quilometragem das texturas. Então você pode fazer a maioria das texturas usando apenas 3 texturas ... albedo / normal / ORM (H). Isso pode valer a pena adicionar por padrão (a menos que tenhamos uma opção de 16 bits para mapas de altura, onde você gostaria de usar um separado). Se 4.0 eventualmente obtiver mosaico / deslocamento, o canal de altura será muito mais importante do que é atualmente.

E por falar nisso, também seria uma boa oportunidade para alterar o nome do canal DEPTH para HEIGHT no 4.0 e fazer com que ele use o inverso do que usa atualmente (ou seja, o branco é uma superfície elevada e o preto é rebaixado). Isso o colocaria em sintonia com outros renderizadores e motores de jogo e, mais importante, com ferramentas como Substance, Quixel e Marmoset.

Eu prefiro sufixos explícitos para nós 2D e 3D, e nenhum sufixo se não for aplicável. Também gostaria que os nós "Control" fossem separados completamente para os nós "Node2D" (ambos atualmente agrupados em "CanvasItem").

Sobre translation versus position , eu escolheria o primeiro em 2D e 3D.

position parece mais amigável, mas deixa de fazer sentido quando um ancestral tem alguma rotação ou escala.

Com relação à compatibilidade, o estágio de transição deve durar para todas as versões 4.x para dar bastante ou tempo aos tutoriais, usuários e projetos. Os novos nomes devem ser os cidadãos de primeira classe e encorajados, mas os antigos devem funcionar, com algum mecanismo no editor para informar as pessoas sobre a mudança.

Sou absolutamente a favor das alterações sugeridas, contanto que sejam feitas de forma que seja fácil para os usuários finais atualizarem o código existente - seja o seu próprio ou o código de tutoriais e documentação existentes - por meio de algum tipo de ferramenta, conforme mencionado. Na falta dessa ferramenta, eu tenderia a concordar que estamos nos acumulando logo após as grandes mudanças da v2 para a v3.

@TwistedTwigleg em relação ao lançamento de jogos 3D, isso porque estamos aguardando 4.0 e Vulcan 😎

Eu também revisaria Control nomes de nós ... e documentação embutida.

Às vezes me pergunto qual é a diferença entre AcceptDialog e ConfirmationDialog , e o mesmo com PopupPanel , PopupDialog , PopupMenu ... espero que isso ajuda!

Como tutor e colaborador de documentos, eu diria que vá em frente! Não me importo em produzir mais conteúdo se as mudanças tornarem mais fácil para todos aprenderem e entenderem o motor no futuro. É melhor fazer esse tipo de mudança o mais rápido possível.

Chegar atrasado para a festa, mas alguns esclarecimentos para manter o controle:

• Comente apenas sobre a proposta de renomeação de nós e suas implicações técnicas sobre como preservar a compatibilidade, o impacto em projetos existentes, tutoriais, criadores de conteúdo, etc.
• Este não é o lugar para discutir pontos específicos na API que devem ser considerados para renomeação. Se decidirmos fazer essa renomeação massiva, revisaremos toda a API em uma planilha para garantir que temos nomes consistentes. Para itens específicos como métodos, propriedades ou classes que devem ser renomeados além do que é discutido aqui, consulte # 16863.
• @RandomShaper @fracteed @fire @reduz Por favor, mova a discussão sobre materiais padrão para uma edição específica.

Olá,
Por que não seguir a prática de outras APIs e criar um decorador Obsoleto / Obsoleto para classes (ou mesmo métodos), ou seja, os nomes antigos são simplesmente apelidos / ponteiros para os novos. Isso interromperia quaisquer alterações significativas e permitiria que os nomes fossem eliminados na versão 5, de forma que menos pessoas fossem afetadas ou mesmo notadas.

Usar um decorador também pode trazer dois outros benefícios:

1. O IDE poderia facilmente pegar essa tag e exibi-la na janela de seleção de nó, por exemplo, em vez de simplesmente dizer 'Espacial', ele poderia ler 'Espacial (uso obsoleto Node3D)'.

2. O decorador pode então se tornar um aviso embutido mostrado no editor de código.

Além disso, não impede ninguém de criar uma ferramenta de renomeação ...

Alguns pensamentos:

Concordo com a renomeação de nós, bem como de alguns métodos e propriedades (consulte a lista atual em # 16863) para melhorar a consistência e tornar a API mais fácil de aprender e usar. Deixar a distinção 2D / 3D clara parece uma boa ideia e, se feito, deve ser feito de forma consistente (por exemplo, também MeshInstance3D como mencionado). Eu sugiro que usemos uma planilha para listar todos os nós atuais e quais devem ser seus novos nomes no 4.0 - e podemos pedalar lá sobre nós específicos como TileMap / GridMap. Criarei essa planilha nos próximos dias se confirmarmos que é assim que queremos.

Ainda assim, devemos nos esforçar para limitar ao máximo a quebra de compatibilidade. Como Juan mencionou, podemos ter renomeações de compatibilidade nas partes internas do motor para que as cenas antigas possam ser carregadas e convertidas, mas isso não é suficiente.

Como @RandomShaper e @chucklepie mencionaram, devemos adicionar aliases obsoletos para todos os nós, métodos, propriedades, constantes, sinais, etc. que renomeamos, com um decorador / metadados de propriedade que os sinalizaria como obsoletos e encorajaria os usuários a mudar seu código. O uso dessas informações no IDE deve possibilitar que os usuários sigam os tutoriais 3.x no 4.0 sem problemas, enquanto aprendem facilmente sobre os novos nomes à medida que avançam.

Para fazer isso, precisamos de métodos auxiliares que nos permitam definir aliases obsoletos ao registrar ligações. # 23023 é a primeira tentativa de adicionar tal interface, mas ela ainda precisa ser revisada, mesclada e talvez expandida se não for suficiente para o que precisaremos na 4.0. Esses aliases obsoletos podem ser mantidos por todo o ciclo de lançamento do 4.x e eliminados no 5.0.
Eu me oporia a qualquer quebra de compatibilidade de renomeação até que tenhamos esta interface bem projetada e mesclada, então qualquer pessoa interessada nisso pode experimentar este PR e sugerir mudanças, se necessário.

Quanto a quando , insisto que, se quisermos quebrar a compatibilidade novamente, é agora. Esperar pelo 5.0 não faz sentido, pois tornaria ainda mais conteúdo obsoleto quando chegarmos ao 5.0 e não ajudaria a retratar Godot como uma ferramenta de desenvolvimento estável se quebrarmos a compatibilidade com (espero) muitos jogos excelentes em desenvolvimento com Godot 4 .x.

A base de usuários de Godot mais ou menos dobra a cada ano, portanto, a cada ano que passa torna uma refatoração menos realista, já que, eventualmente, a inércia de uma grande base de usuários supera os benefícios de quebrar a compatibilidade. Se outros engines como Unity ou Unreal parecem relativamente estáveis ​​em termos de API em comparação com Godot, não é porque eles não têm coisas que gostariam de refatorar ou renomear, mas porque não podem pagar. Ainda podemos, por enquanto, então temos que aproveitar a oportunidade. Foi o mesmo para Godot 3.0 e a comunidade saiu dele relativamente ilesa, embora tenhamos uma pequena proporção de usuários que aderem ao 2.1, pois não podem pagar a portabilidade para o 3.0. Para 4.0, o escopo dessas mudanças deve ser muito menor e qualquer trabalho de portabilidade deve ser simples, mas a comunidade cresceu muito nesse meio tempo, então o impacto de qualquer quebra de compatibilidade será tão grande ou maior do que para 3.0 em termos de imagem / aborrecimento acumulado do usuário :)

Sou um grande defensor da quebra de compatibilidade.
Por que não é um problema: se um desenvolvedor lançar seu jogo em uma versão mais antiga e continuar desenvolvendo na versão mais antiga do motor, ninguém estará forçando o desenvolvedor a migrar para a nova versão. Além disso: continue oferecendo versões mais antigas para download exatamente para esse propósito.
Novos projetos podem ser iniciados na nova versão do mecanismo e, em seguida, depende do desenvolvedor ter paciência para reaprender como o mecanismo funciona.
Quando se trata de melhorar a usabilidade do motor, a paciência para reaprender nunca deve ser um problema, se o objetivo é se tornar o motor mais amigável ou poderoso que existe.

Quanto à renomeação, ajuda a reduzir a curva de aprendizado se houver padrões no material a ser aprendido. Por exemplo, Node2D vs Node3D, etc. para todos os outros nós. Se se parece com um pato, você sabe como funciona, provavelmente é um pato ou um nó neste caso.
O cérebro humano funciona como um computador quântico otimizador, que aprende conectando estados de sistemas de menor energia uns com os outros para criar caminhos lógicos entre as idéias. Se as ideias a serem aprendidas são semelhantes, seus estados de energia mais baixos são mais próximos uns dos outros, o que torna mais fácil conectá-las (e lembrá-las), o que explica por que é mais fácil para um aluno entender 3D se ele tiver aprendido 2D de antemão . Se os nomes dos nós refletirem a semelhança entre eles, também será mais fácil aprender e entender como um novo tipo deve ser usado se houver conhecimento em um tipo semelhante.

Eu digo vá em frente, refatore e quebre a compatibilidade da maneira que desejar. Mesmo se você perder poucos usuários, ganhará muito mais com o aumento da facilidade de uso e a redução da curva de aprendizado.

Em relação a isso, pegue o Blender 2.80 por exemplo. Compare sua aparência e comportamento agora com o que era antes. É uma grande mudança que força muitos desenvolvedores a reaprender como o software funciona. Agora pense em quantos usuários o Blender tem. Comparados a Godot, eles são gigantescos, mas mudaram drasticamente seu software de qualquer maneira. Porque? Porque no longo prazo, é sempre mais lucrativo reduzir a curva de aprendizado e melhorar a facilidade de uso, mesmo que isso signifique perder alguns usuários que não têm paciência para fazer a transição para o novo fluxo de trabalho.

No geral, não sou a favor de uma alteração significativa neste caso.

Posso entender a frustração sentida com as convenções de nomenclatura que cresceram organicamente, mas não vejo nenhuma que justifique uma mudança ampla e significativa.

Eu sou totalmente favorável a descontinuar APIs das quais desejamos deixar de usar (e sinalizá-las no momento da compilação e nos documentos), mas o ideal é que os nomes dos nós antigos continuem a funcionar como antes.

Talvez, em alguns anos, possamos perguntar se é hora de descontinuar os nomes de nós legados, pois isso se tornou totalmente indolor. Até então, minha sugestão seria adicionar novos nomes conforme desejado (não tenho uma opinião forte sobre isso) e evitar quebrar a compatibilidade com versões anteriores.

@fracteed Na verdade, ter profundidade em um canal de outra textura provavelmente não é uma boa ideia, porque o mapeamento de paralaxe faz muitos toques nessa textura, forçando a obter RGB desnecessariamente todas as vezes. Se você usar uma única textura em tons de cinza, Godot a compactará para a metade do tamanho, economizando um pouco de largura de banda.

Ter um modo ORM no material padrão também pode ser uma boa ideia, é preciso verificar isso.

@chucklepie O problema é que nem todos os idiomas suportam apelidos de classe como typedef. C # é um deles.

@reduz ah, não sabia disso, bom saber. A questão mais importante é mudar o canal de profundidade para a altura de 4.0, então, esperançosamente, você considerará mudar isso.

editar. desculpe Akien, acabei de ver seu comentário depois de postar isso ...

@neikeq O problema é que nem todas as linguagens suportam apelidos de classe como typedef. C # é um deles.

Não sei como a biblioteca C ++ nativa é implementada, mas estou me referindo mais a um mecanismo para fazer essa decoração no nível C ++ nativo, de forma que não importa qual seja a ligação de linguagem upstream. Se isso não for possível, as ligações para cada linguagem podem ser facilmente adaptadas ao conjunto (por exemplo, usando atributos em C #, etc).

@ gerald1248 Leia meu post, em nenhum lugar que mencionei que vai quebrar, os projetos criados no 3.x continuarão a funcionar usando aliases no carregamento e nos scripts. Usá-los irá disparar um aviso de suspensão de uso, mas seu projeto continuará funcionando.

Eu sou um grande fã de

Navegação -> Nagivagion3D

renomear. Apoio este pedido!

@reduz disse:
@TwistedTwigleg Leia meu post, os projetos 3.0 abrirão bem no 4.0 se um sistema de compatibilidade interno for adicionado.

Que pena, perdi essa parte do post.

Um sistema de compatibilidade interna ajudaria na migração e definitivamente me colocaria mais no lado "faça a mudança" da cerca, especialmente se combinado com algo como # 23023. Saber que algo está planejado para os projetos antes dessa mudança é bom ouvir e ameniza muitas das preocupações que eu tinha sobre essa proposta.

@Norrox disse:
@TwistedTwigleg em relação ao lançamento de jogos 3D, isso porque estamos aguardando 4.0 e Vulcan 😎

Isso é justo.
Especialmente devido às melhorias no lado 3D de Godot que virão no Godot 4.0, esperar pode não ser uma coisa ruim para projetos pesados ​​em 3D.

a diferenciação 3d e 2d já é consistente . Os nós 3D são vermelho claro, os nós 2d são azuis e os nós da interface do usuário são verdes. sempre haverá usuários com problemas de nomenclatura. é um problema sem fim e é um problema multiplicativo com base no tamanho da comunidade.

em relação às mudanças sugeridas no OP: os nós 2d já têm um sufixo "2D" aplicado, o que _inerentemente significa que suas contrapartes são 3d_.

entretanto, sou a favor de mudanças como Label para TextLabel . ( @MuffinManKen é um ótimo argumento)

Eu apoio totalmente basicamente tudo aqui, mas com relação à questão "Sprite2D / Sprite3D", eu sugeriria deixar Sprite como Sprite, se por nenhuma outra razão que o sufixo 2D adicionar uma quantidade extra de desordem, IMO.

Como @girng diz, a diferenciação 2D / 3D já é bastante clara devido ao código de cores, então não precisamos ir muito longe para evitar confusão. Da perspectiva de um desenvolvedor Godot, eu pessoalmente não gostaria de ter -2D adicionado a todos os nós não renomeados em meu projeto. : D

Esse código de cores é útil para pessoas com várias formas de daltonismo?
Definitivamente, não é útil quando você está digitando código (ao contrário de adicionar nós da caixa de diálogo).

@reduz obrigado pela sua resposta. Eu percebo que é para uma versão principal e, portanto, totalmente bom em um sentido comum. Pessoalmente, evito fazer alterações como essas mesmo para uma versão principal, mas estou ciente de que você tem uma ideia muito melhor se isso seria um problema ou não. Estou apenas olhando para o histórico de grandes mudanças nas versões principais (python2 para python3, por exemplo) e geralmente prefiro viver com inconsistência (ou novos nomes de nó mais nós antigos e obsoletos). De qualquer forma, eu amo Godot e continuarei usando-o, quaisquer que sejam as mudanças significativas.

Mas, novamente, fique à vontade para sugerir se você prefere algo mais explícito e tornar tudo 2D / 3D sempre.

explícito é melhor do que implícito.

@girng @AlexHoratio Nós com uma cor diferente no editor não são úteis quando você está escrevendo código. Acho que é aqui que surge a confusão.

(Eu ainda não vejo porque Sprite3D precisa existir, outros engines apenas usam malhas quádruplas para o mesmo propósito, seria mais fácil se Sprite fosse um termo exclusivamente 2D).

@gimg , @AlexHoratio Não se esqueça que 4,5% da população também é daltônica: hung_out_tongue:

Acho que renomear é uma boa ideia.
A transição de 2D para 3D se tornará muito mais fácil. Pelo menos para pessoas que começam com 2D (e provavelmente o contrário também)

está claro que há um problema e a comunidade acha que é uma boa ideia. sou apenas tendencioso com godot e muito ligado emocionalmente. estar neste estado gera pensamentos que realmente não fazem sentido para os outros, mas fazem sentido perfeito para mim, de uma maneira linda . difícil de explicar. obrigado por me deixar expressar meus pensamentos

Eu concordaria com o consenso geral aqui de que vale a pena renomear para consistência. No momento, pode dar a impressão externa de que um conjunto de nós é de "primeira classe" e o outro é de "segunda classe", ou talvez até mesmo hackeado com base no primeiro.

Pessoalmente, acho que Sprite -> Sprite2D seria uma infeliz casualidade de uma renomeação explícita e totalmente rigorosa, mas acho que sempre posso renomear manualmente para Sprite em cada cena que faço até ficar cansado disso.

Eu acho que é desanimador que CanvasLayer e CanvasItem não estejam agrupados, e que Node2D esteja dentro do CanvasItem com Control, como outros apontaram.

Eu sei que @ akien-mga disse que isso é apenas para renomear os nós, mas acho que pelo menos o debate sobre position vs. translation entra em jogo aqui. Eu acho que o propósito de renomear nós cai um pouco se suas APIs são significativamente diferentes (exceto diferenças entre sistemas de coordenadas e similares), então eles definitivamente devem ser os mesmos, sejam eles quais forem. Eu votaria em "posição" como o caminho a seguir aqui, houve um comentário sobre isso ser enganoso em comparação com "tradução". Eu diria que a "tradução" é enganosa porque implica uma transformação ou movimento em vez de simplesmente ser coordenadas. A posição é intuitivamente relativa, imo (você não endireita suas cadeiras em relação às direções da bússola, você o faz em relação às paredes da sala).

Eu acho que as variáveis ​​devem ser nomeadas posição para ambos, mas as funções translate devem permanecer, mudando as funções move_local em Node2D para translate_local , a documentação até chama isso de tradução. Eu manteria o uso de move para os nós relacionados à física, para distinguir entre o movimento físico e a translação geométrica.

Muito da segunda metade disso é relevante para # 16863 também

Além disso ,

Acabei de pensar em uma ideia, se isso fosse implementado, poderíamos ter uma configuração de editor chamada "Nomes de nó simples", o que significa que os nós recém-criados não têm o sufixo em seus nomes, por exemplo, criar um novo "Whatever2D" definiria seu nome para "Whatever", mas os scripts nesse nó ainda diriam "extends Whatever2D" etc. Seria o mesmo que criar um nó e renomeá-lo manualmente.

Isso evitaria a confusão de ver os nomes padrão "2D" ou "3D" na Hierarquia se o usuário escolhesse ativá-la, mas ainda tornaria o código mais consistente e explícito. Sem os nós 3D contendo "3D", isso seria confuso, mas faria sentido com "3D" no final por padrão.

@aaronfranke Acho que é uma ideia bastante sólida. Parece um compromisso que permite manter a base de código consistente e clara, ao mesmo tempo que permite que os usuários mantenham o excesso de desordem fora de sua hierarquia. Acho que muitas das objeções à ideia de renomear vêm do efeito que isso terá nas hierarquias, ao invés de uma objeção aos próprios nomes.

@aaronfranke Eu odiaria ser aquele que estragaria uma ideia sensata, mas nomes de nós diferentes entre sistemas diferentes tornariam o compartilhamento de arquivos de script gd impossível. Como todos os plug-ins são exportados como cenas e arquivos gscript brutos, eles parariam de funcionar se fossem desenvolvidos em um sistema com diferentes mapeamentos de nós. Para evitar isso, todos os arquivos gdscript e arquivos de cena precisariam incluir mapeamentos de nomes de nós para traduzir o arquivo para o novo sistema. Tenho certeza de que esse tipo de sobrecarga é um grande não para o @reduz.

@aspenforest Eu não acho que adicionar um mapeamento seria uma grande sobrecarga, mas talvez eu esteja sendo ingênuo, pois não conheço a arquitetura do motor

O que poderia ser facilmente feito com a ideia de MeshInstance seria automaticamente nomeado mesh_instance vez de MeshInstance ), outra configuração poderia ser adicionada para sufixos de nó, o que removeria o sufixo "2D" ou "3D" dos nomes dos nós (então um novo nó Sprite2D é nomeado apenas Sprite ).

Ninguém jamais reclamou sobre KinematicBody2D ou Particles2D e coisas semelhantes, tendo um sufixo "2D" desnecessário, então não vejo por que devemos adicionar recursos para contornar a adição de um sufixo "3D" em suas contrapartes ... Se os usuários realmente não querem que esses sufixos estejam lá em primeiro lugar, esta proposta talvez deva ser descartada, e não contornada com uma maneira de renomear nós no IDE por algum motivo cosmético ...

@ akien-mga isso não seria tanto "contornar" os novos nomes dos nós, para mim é mais o molho por cima, algo que é apenas não-hacky com um esquema de nomenclatura consistente. EU QUERO os sufixos lá, para quando estou codificando, adicionando nós ou procurando documentação. Mas uma vez que eles estão em uma cena, eu sei o que são, e muitas coisas terão nomes personalizados de qualquer maneira.

Se fosse necessário escolher entre tornar os nomes consistentes e obter um recurso de editor para simplificar os nomes, eu escolheria a primeira opção, mas acho que @aaronfranke estava chegando ao fato de que quaisquer objeções a esta proposta eram, na verdade, fundamentalmente cosméticas, e sua sugestão aborda que, embora não custe nada da consistência subterrânea dessa ideia, na verdade.

Eu definitivamente acho que adicionar o recurso de editor seria seu próprio problema / pr, não algo necessário para incluí-lo.

Evitei inicialmente SpatialMaterial porque tinha um nome estranho. Mas é uma classe tão poderosa. Em vez disso, eu apenas comecei a aprender como codificar shaders com albedo + ao + normals mapeados triplanar. Então eu descobri que todo o trabalho que eu tinha feito foi em vão, pois eu poderia ter feito tudo isso no SpatialMaterial e então convertido em código e obtido um resultado melhor. Portanto, ele precisa de um nome mais amigável.

+1 para nomes 2D / 3D explícitos.

Tenho dúvidas sobre um nó que suponho que possa ser marcado para depreciação no futuro, e quem é a existência que eu posso imaginar pode ser confusa do ponto de vista de nomenclatura. Desde que o novo sistema de animação caiu, agora temos dois nós, um denominado AnimationTree e AnimationTreePlayer, que basicamente não têm qualquer relação um com o outro. Alguma ideia sobre qual pode ser a melhor maneira de resolver isso?

@SaracenOne Este não é o lugar adequado para fazer perguntas como essa. Desculpa. Este tópico é para discutir apenas o sufixo 2D / 3D.

Há outro problema para discutir mudanças de nome de forma mais geral https://github.com/godotengine/godot/issues/16863

Eu pensei que provavelmente estaria além do escopo da quebra de compatibilidade aceitável para 4.0 e, portanto, provavelmente é simplesmente inviável / inaceitável, mas decidi mencioná-lo para ver se alguém mais experiente do que eu gostaria de comentar.

Imaginei que todos esses nós 2D / 3D poderiam herdar de um único tipo de nó 2D ou 3D. A API para tal nó conteria todas as funções que você esperaria para qualquer versão, e sua implementação dependeria se esta em particular era 2D ou 3D.

Em teoria, tal sistema poderia:

1. Certifique-se de que estamos criando APIs consistentes entre contrapartes 2D / 3D. Isso é tanto uma vantagem quanto uma desvantagem, a meu ver, já que, apesar dessa consistência, pode haver coisas que não são necessárias para incluir em um, mas estão no outro.
2. Facilite a interação dos dois tipos diferentes ou crie scripts personalizados que você deseja anexar às versões 2D e 3D de um nó.

Seria bom para evitar uma situação em que "SomeClass2D tem x, yez implementados, mas não há nada parecido com SomeClass3D" e resolva o problema de nomenclatura de uma maneira diferente. Isso provavelmente é monumentalmente estúpido por alguns motivos que não estou pensando agora, mas pensei em jogá-lo fora.

@vortexofdoom Isso já acontece. Node2D é herdado por todos os nós 2D e Spatial é herdado por todos os nós 3D. A questão é como chamar tudo.

E, mais importante, tanto Spatial quanto Node2D herdam de Node .

Eu diria que ainda há algo na ideia de @vortexofdoom não coberto apenas pela hierarquia de classes, mas não posso determinar exatamente o que é.

Apenas pensando: você acha que seria benéfico adicionar um sufixo - Res a todas as classes derivadas de Resource ?

@aaronfranke Estou me referindo à ideia de ter UM de cada tipo de nó (simplesmente KinematicBody ou Sprite), e o principal sendo algum tipo de Node2D3D que dita seu comportamento. Desculpe se isso não foi bem explicado. Então, em vez de ter uma hierarquia 2D e uma hierarquia 3D, teríamos uma hierarquia 2D / 3D. É por isso que eu disse que seria um refatorador maior do que provavelmente o aceitável.

_Poderia_ funcionar tendo os tipos básicos não utilizáveis ​​por si próprios, mas precisando ser implementados como 2D / 3D para que sejam um nó real, caso em que estamos de volta à estaca zero em nomes de nó, mas a herança é mais automaticamente direto e relacionado entre o 2D e 3D e a interação entre os sistemas ainda seria mais agradável (eu acho).

@vortexofdoom Mas nada é realmente compartilhado entre 2D e 3D. Eles podem ter alguns dos mesmos tipos de nó e ter os mesmos nomes de método, mas quase todas as implementações são completamente diferentes. O máximo de compartilhamento que eu poderia esperar seria uma interface, já que sua ideia envolveria if (is2d) { do 2d stuff } else { do 3d stuff } e tornaria os arquivos de código duas vezes mais longos e muito ilegíveis sem nenhum benefício.

A viabilidade de classes únicas com comportamento variável é definitivamente dependente de quanto do trabalho pesado que o nó 2D / 3D de nível superior poderia fazer, enviando abstrações ainda mais para baixo. Misturar as classes como elas existem agora definitivamente não valeria a pena, tenho certeza. Eu não me importaria com o uso de interfaces para realizar a reorganização, porém, ainda iria impor pelo menos algum nível de padronização para os diferentes tipos.

A ideia foi motivada por um desejo ocioso de que eu pudesse herdar de uma versão geral de um nó, então não tive que implementar tudo duas vezes em um projeto onde eu tinha uma versão 2D e 3D rodando em paralelo. No momento, você teria que herdar de um nó e fazer uma projeção para fazer isso de qualquer forma, já que o nó é o único ancestral comum.

Acho que Node2D3D (estou ciente de como isso soa ridículo) teria algum valor, mesmo que apenas como uma forma de fazer os dois sistemas de coordenadas funcionarem melhor um com o outro, mas isso está se aproximando de uma questão de design completamente diferente. do que este tópico. Desculpe ter desviado.

@RandomShaper Eu definitivamente poderia ver o benefício disso, especialmente se tivermos essa opção de nomes simples.

Deixando meus comentários para a posteridade, mas estou retratando minha sugestão em favor de um esquema de nomenclatura 2D / 3D estrito, enquanto deixo a hierarquia praticamente como está.

A razão é que renomear todos os nós liberaria todos os nomes de classes para uso do usuário, o que significa que eu poderia implementar a funcionalidade que estava procurando criando meu próprio conjunto de classes como KinematicBody ou CollisionObject que poderia puxar uma funcionalidade relevante e passá-la adiante.

Mas mesmo fora desse caso extremo, permitiria a você criar classes como Area vez de inventar algo como RoomGroup como um exemplo rápido.

Estou muito feliz que isso esteja sendo discutido. Estou esperando que seja feito.

Não sei se isso foi dito, mas se as coisas vão ser renomeadas para consistência, pode muito bem ir com consistência total (como humanamente possível) e também renomear certos métodos.

Exemplo:

Geometry.get_closest_point_to_segment()    # <-- this is the 3D version
Geometry.get_closest_point_to_segment_2d()

Além de nós e métodos, e as estruturas de dados? Presumo que Transform será renomeado para Transform3D para alinhar com Transform2D , mas Basis provavelmente não precisa ser Basis3D porque não há Basis2D , pois está tudo incluído em Transform2D .

@RandomShaper

Apenas pensando: você acha que seria benéfico adicionar um sufixo - Res a todas as classes derivadas de Resource ?

Parece pouco para o investimento. Eu prefiro votar para incluir Recursos em minha sugestão (# 31054) para destaque de código, tbh. Tê-los em uma cor diferente refletirá seu tipo de base assim que você terminar de digitar o nome da classe (assim como acontece com tipos integrados como Vetores e AABB).

Que tal projetos separados para 2D e 3D.

(Na imagem, sugestão para substituir 2d por UI e 3d por Scene).

Ao iniciar o projeto, você seleciona em qual irá trabalhar.
Não são necessários mais sufixos (2D, 3D) nos nomes das classes.

Então, dessa forma, está criando um tipo de namespace, e não há mais combinações entre esses tipos:

usando Godot2D;
usando Godot3D;

Quando você está em um projeto 3D ou 2d - clique na IU, você tem uma janela de IU (2D) para editar a GUI, ao clicar em Cena - você está na cena (2d ou 3D depende do tipo de projeto).

Assim, mantemos o modo 2d para a IU em qualquer projeto, mas a cena abre a janela 2d ou 3d

Nesta janela estarão disponíveis apenas entidades relacionadas ao tipo de projeto (2d ou 3d) ou compartilhadas se utilizarem em ambos

Quando você está no modo UI, a adição de um novo nó mostra esta janela apenas com componentes relacionados à UI.
Quando no modo Cena, os controles da IU não são mostrados, apenas coisas que você pode aplicar à cena

@dmitryuck Para a imagem que você postou, o botão 2D é sempre necessário, já que até os jogos 3D precisarão usar o modo 2D de Godot para interfaces de usuário e outras coisas. E é desejável ser capaz de misturar 2D e 3D de qualquer maneira. Tecnicamente, os jogos 2D não precisam usar o botão 3D, mas dificilmente é necessário ocultá-lo.

Sugeri acima que podemos fazer com que os nomes dos nós sejam cosmeticamente alterados na hierarquia para evitar sufixos visualmente desnecessários, mas seria melhor se o código fosse sempre explícito.

@aaronfranke Eu adicionei uma explicação um pouco ampla do que eu quis dizer no meu comentário anterior.

Acho que exibir nomes de nós de maneira diferente dependendo das circunstâncias aumentaria a confusão.

As pessoas devem ser capazes de entender roteiros e árvores de cena à primeira vista. Acho que isso é obrigatório para colaboração, tutoriais claros, etc.

@dmitryuck Alguns projetos podem exigir a mistura de 2D e 3D, e alguns jogos têm interfaces de usuário em 3D.

@Skaruts mudando para vista 2d em cena 3D possível implementando componentes como neste editor

O modo de IU, é claro, deve estar presente em ambos os tipos de projetos, mas pode ser uma janela separada com ferramentas feitas especialmente para IU, como uma grade, encaixe aprimorado, réguas e assim por diante.

@reduz Renomear é bom, mas deve haver um longo período de transição, por exemplo de 4.0 para 5.0, porque isso desatualizou muitos tutoriais e respostas de https://godotengine.org/qa

@xxmatxx Eu preferiria que a renomeação acontecesse com um curto período de transição para parar de arrastar os nomes antigos 'o que seria'.
Além disso, eu certificaria de documentar bem as mudanças e garantir que as pessoas que estão apenas ficando presas em Godot saibam sobre as mudanças. Um aviso no editor informando que você está usando a versão obsoleta dos nomes dos nós também será útil caso alguns se esqueçam disso.

Eu concordo, quanto mais tempo demorar, mais tempo terá a chance de confundir as pessoas. Tutoriais e documentos não ficarão imediatamente desatualizados se, como sugeriu @AtomaFajrovulpo , por um período de tempo o editor ainda permitir o material obsoleto, mas disparar um aviso. Suponho que algo assim:

Node type 'Spatial' is deprecated and replaced by 'Node3D'. 

e

Method 'clip_polygon()' is deprecated and replaced by 'clip_polygon_3d()'. 

Descobri ontem que nem todas as constantes seguem o mesmo caso. Por exemplo, há Color.black e Vector3.UP . Isso não deveria ser consistente para 4.0?

@BenjaminNavarro A alteração das constantes de cores para maiúsculas também foi discutida na parte inferior de https://github.com/godotengine/godot/pull/14704.

Além disso, renomeação de método / sinal / constante deve ser discutido em # 16863, já que esse problema é especificamente sobre nomes de nós.

@Calinou Obrigado, eu tinha certeza que havia outros problemas, mas não consegui encontrá-los.

Eu prefiro renomear no 4.0 e terminar com isso, então sabendo que virá mais tarde, depois que o projeto em que estou trabalhando crescer mais.

se um grande lançamento não é o momento para fazê-lo, qual é.

SemVer: Dado um número de versão MAJOR.MINOR.PATCH, incremente:
Versão PRINCIPAL quando você faz alterações de API incompatíveis,
Versão MINOR quando você adiciona funcionalidade de maneira compatível com versões anteriores, e
Versão PATCH quando você faz correções de bugs compatíveis com versões anteriores.

Até onde você irá com isso?

O GridMap se tornará TileMap3D e o Tilemap Tilemap2D, por exemplo?

Além disso, node2D e node3D parecem um pouco genéricos, por que não ter Spatial2D e Spatial3D então?

Eu acho que uma grande diferença de UX também seria ter controle, node2D e espacial, qualquer que seja o nome, diretamente acessível abaixo do nó na caixa de diálogo do novo nó, embora node2D e controle sejam herdados de CanvasItem. Você não pode adicionar um CanvasItem diretamente a uma árvore de qualquer maneira, então talvez ele não deva estar visível nessa caixa de diálogo.

E no que diz respeito aos métodos, acho que não há necessidade de adicionar um postfix 2D ou 3D neles, já que você sabe como os chama, certo?

Ainda espero fazer algumas atualizações úteis, como abordar a importação lenta de recursos e a otimização de desempenho de scripts GD. Atualmente, leva cerca de uma hora para importar recursos 1G. Se você importar recursos 10G, terá que sentar na frente do computador e dormir por dois dias. No entanto, o navegador do sistema de arquivos do editor de recursos da importação 700M-1G agora está quebrado e nada será exibido. Lista de arquivos, esta pode ser a deficiência do próprio editor, então acho que otimizar e resolver os problemas existentes é o melhor caminho para Godot. Se eu puder importar apenas 100-500 milhões de recursos, então Godot não poderá desenvolver jogos grandes, mas meu caminho agora está bloqueado e não posso seguir em frente. Espero que a próxima versão resolva tais problemas, desejo Godot cada vez melhor!

@ qq715152910 Por favor, não comente tópicos longos com informações completamente não relacionadas. Todos os que comentaram sobre este assunto receberão um ping e seu comentário não tem nada a ver com a proposta de renomeação de nós. Como resultado, ocultarei seu comentário.

Vou dar nossa opinião sobre algumas renomeações que seriam úteis para nós (usamos principalmente C #)

A renomeação que sugerimos fortemente:

1. Transform.origin -> transform.origin

(Fazendo o acesso a uma propriedade de transformação em letras minúsculas)

Porque?
Por exemplo, o espacial tem a Transform que podemos acessar, mas muitas vezes escrevemos "this.Transform.origin" para melhor legibilidade, se mudarmos "Transform" para "transform", não precisaríamos usar "this" all A Hora. Essa é a nossa opinião pessoal.

1. Também oferecemos suporte para alterar "Label" para algo como "TextLabel". Ou pelo menos quando buscamos por "texto" ao adicionar o novo nó, deve aparecer "Rótulo", pois é totalmente relacionado.

2. As constantes para algumas cores predefinidas devem ser acessadas com Color ao contrário de Colors .

Para o resto da proposta de renomeação, esperamos ver o que a comunidade acha que é melhor.

AtlasTexture -> TextureAtlas

É denominado AtlasTexture porque segue a convenção usual de <Type>Texture , em que <Type> pode ser Image , Viewport , Stream ,…

AtlasTexture -> TextureAtlas

É denominado AtlasTexture porque segue a convenção usual de <Type>Texture , em que <Type> pode ser Image , Viewport , Stream ,…

Isso é o que aparece quando eu digito "Atlas".

Isso é o que acontece quando digitamos Texture:

Edit: Entendemos por que essa convenção. Na segunda captura de tela, AtlasTexture está muito abaixo de outras coisas que seguem a convenção <Type>Texture . Em seguida, esse ponto foi removido de nosso post anterior. Para este caso particular, ainda não é muito amigável com o preenchimento automático. Mas nós aceitamos. .

@bigmonte O Transform struct pode ser renomeado para Transform3D no Godot 4.0 como por esta questão, para que você não terá mais necessidade this. deixar claro que é uma propriedade.

EDITAR: https://github.com/godotengine/godot/pull/38430

As constantes para algumas cores predefinidas devem ser acessadas com Color ao contrário de Colors .

Fui eu quem propôs isso em primeiro lugar e discordo veementemente. É melhor mantê-los separados, pois aumenta a descoberta dos membros estáticos de Color (atualmente Color8 , ColorN e FromHsv ) ao usar o preenchimento automático em vários IDEs. Também estou considerando propor uma renomeação de Color.red etc -> Colors.RED em GDScript para consistência.

A propósito, acho que você estava procurando o # 16863.