Realmente gosto do seu post.

EDITAR:
Porra, ignorou esse parágrafo

Tenha uma maneira de realmente copiar os arquivos para o projeto, caso a modificação no nível da fonte seja desejada. Só então os arquivos devem ser trazidos para a própria pasta do projeto. Os ativos "clonados" podem ficar em uma pasta oculta como .custom.

Então você basicamente cobriu as preocupações que eu tinha. (Desculpe)
Eu apenas aprofundo como imagino o fluxo de trabalho + o comportamento.

PUBLICAR:
Um fluxo de trabalho é negligenciado IMO embora.
Usando ativos como apenas um recurso ou uma primeira pedra de construção.
A abordagem atual realmente transparente e simples também permite que você baixe alguns ativos. excluir alguns arquivos. Então mantenha alguns png's e um script que tenha algumas das funcionalidades que você deseja. Atualmente é possível apenas trabalhar neles e modificá-los.

Se os ativos estivessem ocultos em uma pasta .local/godot/assets essa funcionalidade seria meio perdida.

Proposta

Os ativos ainda devem estar visíveis e listados no navegador de arquivos do editor. Independente se estiverem dentro da pasta .local/godot/assets ou na própria pasta do projeto. Assim você pode navegar pelos arquivos e entender como funciona caso não haja documentação adequada, ou se quiser aprender com ela.
Cada pasta que é 'um ativo' também deve ser marcada como uma com algum tipo de ícone para que você tenha uma visão geral do que é um ativo e onde os arquivos reais estão armazenados.
Deve haver também uma janela do editor que lista todos os ativos. (em uma tabela)

• Baixado lista todos os ativos que foram baixados. Eles podem ser adicionados ao seu projeto com um clique de um botão. Mas fora isso, eles são os mesmos que os ativos na biblioteca de ativos. Esta lista é a mesma em qualquer projeto e não tem efeito no projeto em si. (simplesmente torna mais fácil ter uma visão geral. também é fácil limpar esta lista e baixar novamente todos os ativos ao abrir um projeto.)
• Sempre ativo (basicamente apenas alterna "Usado neste projeto (ativo/inativo)" para cada projeto) Esses ativos são adicionados a CADA PROJETO em sua máquina (mesmo os recém-criados). (Talvez o próprio recurso precise permitir isso.) Esses são realmente orientados ao Editor. Como um relógio no canto, git support, listas de tarefas ou para ter mais alguns recursos padrão: (um ambiente personalizado mais alguns temas e um monte de sprites para trabalhar no início de cada projeto) ...
  Eles podem ser desativados manualmente por projeto.
  Eles ainda estão listados no sistema de arquivos do projeto e se comportam como qualquer outro assed/plugin. para que você possa navegar em seus arquivos e ver como eles funcionam/o que eles fazem.
• Usado neste projeto (ativo/inativo) isso realmente mostra a pasta vinculada no sistema de arquivos do projeto. e "adiciona" (eles ainda estão dentro da pasta .local/godot/assets , mas se comportam como arquivos locais do projeto.) arquivos ao projeto.
  Aqui você também pode escolher qual versão do Ativo você deseja ativar. E mude a versão.

Assim que você deseja editar/salvar/atualizar um arquivo de um ativo, você recebe duas opções

Economize em .local/godot/assets

ou atualize o ativo no .local/godot/assets que o coloca em uma versão de usuário personalizada.
Se o gerenciador de pacotes for baseado em git, a versão personalizada do usuário pode ser um commit adicional. que recebe commit --amend ed sempre que você salva.
( 3.2.5/user por exemplo) e está disponível em todos os seus outros projetos também. (ao atualizar a versão nesses outros projetos para sua versão de usuário)
por que isso é útil?
Um tema da loja de ativos é quase perfeito, mas você odeia o tipo de fonte...
altere o tipo de fonte salve-o como uma nova versão do ativo. Revisite todos os seus outros projetos e altere a versão do ativo para /user . Agora você está feliz.
Talvez também possa haver um botão para publicar a versão do usuário do ativo.
Portanto, na loja de ativos, outras pessoas têm a opção de escolher também uma versão do usuário com pequenos ajustes.
Apenas como um intermediário para fazer um pr para o repositório git de ativos. (ou o autor do ativo decide escolher as mudanças de uma versão /user para uma nova versão no master.)

Faça local para projeto

copia os arquivos da pasta .local/godot/assets para o projeto atual... remove qualquer comportamento de ativo especial (como versão...) e agora você pode mexer nele como quiser. (também a pasta perde sua aparência personalizada como um ativo.)

Isso permite que o repositório de ativos também cubra o caso de uso de modelos. E é uma escolha perfeita para quase qualquer ativo relacionado à arte. Uma vez que você pode trabalhar nos ativos para torná-los como você precisa.
Você sempre pode ativar um monte de ativos já baixados (digamos, alguns sprites protótipos básicos) torná-los locais e importá-los.

pensamento aleatório

Isso pode até ser uma boa solução para sua própria biblioteca/coleção de ativos/recursos locais. Uma pasta em .local/godot/assets permite que você adicione seu conteúdo a qualquer projeto Godot com um bom editor de interface do usuário e sem procurá-lo no gerenciador de arquivos do seu sistema operacional.

Concordo que tanto a AssetLib quanto a integração da biblioteca de ativos (tanto no editor quanto com GDScript) precisam de amor se continuarmos pressionando-a como uma alternativa para incluir coisas no mecanismo principal.

No entanto, eu pessoalmente discordo com o quão forte isso deve ser um plugin é empurrado.

A primeira pergunta que nos fazemos em um novo PR não deveria ser isso poderia ser um plugin? mas isso será usado o suficiente para estar no núcleo? .

Existem problemas em ter coisas em plugins:

• As pessoas precisam saber o que estão procurando em primeiro lugar. Godot é voltado para iniciantes . O software amigável para iniciantes geralmente tenta ter tudo o que alguém vai (razoavelmente) precisar, porque, caso contrário, eles primeiro precisam aprender o que estão perdendo e como conseguirão.
  Há uma razão pela qual os iniciantes usam o Ubuntu, não o Gentoo. Independentemente de quão legal você faça esse sistema de dependência.
• A paralisia de decisão existe. Se houver um recurso no Godot, ótimo, demora um segundo para usá-lo. Se houver 5 plugins para ele, qual vou usar? Por exemplo, existem mais de 5 plugins de console . Qual deles um iniciante deve escolher, e por quê, e quanto tempo eles devem gastar razoavelmente nessa decisão?
• Os plugins são abandonados, têm menos qualidade, ficam para trás ao serem atualizados. Há ainda menos razão para confiar que um plugin aleatório não vai explodir em mim do que confiar em Godot, onde há pessoas suficientes por trás dele.
• Veja Unidade . Seus ativos são principalmente pagos , e ainda é uma droga que, para muitas coisas, você precisa primeiro de plugins que eventualmente são mal integrados ou são quebrados em atualizações - ou descontinuados, mesmo que sejam pagos e geralmente possam pagar pelo menos algum suporte.
• Documentação : Não temos o suficiente disso de qualquer maneira. Todos os recursos que não estão no núcleo, não posso usar em tutoriais/docs oficiais. Pessoas solteiras aleatórias para plugins provavelmente não fornecerão documentos, ou apenas exemplos curtos, nem a parte mais valiosa de fornecer demonstrações ou tutoriais completos sobre como integrar esse recurso com outros perfeitamente em um projeto.

Exemplos:

• Nó de braço de mola. (https://github.com/godotengine/godot/pull/18822) Adição razoavelmente pequena, separada em sua própria classe, então não deve quebrar as coisas, será usada por muitos jogos 3D, se não por todos os jogos em terceira pessoa . Resposta: deve ser um plugin.
• Mesmo para o material RNG, foi discutido tê-lo como um plugin. Como se nem 90% dos jogos precisassem de um RNG em algum lugar.

Edit: Para ser claro, sou a favor de evitar o inchaço. Mas isso é um equilíbrio, e eu quero dar voz ao suporte por não ter tudo em plugins. Coisas muito específicas do jogo ou não amplamente usadas, plugins proprietários, grandes dependências, sim, por favor , coloque-os no Asset Lib!

@karroffel Este é um post excelente e concordo com tudo o que você disse. Gostaria, no entanto, de comentar este ponto:

Os ativos são salvos com a versão associada, todos armazenados em .local/godot/assets ou algo assim. Eles não fazem mais parte do projeto em si, mas estão disponíveis em todo o sistema.

Isso é semelhante a como o sistema pip do Python funciona. As pessoas então perceberam que a versão mais recente de um pacote estragava os outros projetos que você tem em seu sistema. virtualenv resolve esse problema. No ecossistema npm do Javascript, os módulos são instalados localmente em um projeto por padrão e todo o sistema é um recurso opcional ( npm install --global ). Em seguida, você verifica seu package-lock.json no controle de origem para garantir que todos na equipe usem a mesma versão de cada módulo npm e evitem conflitos.

Os pacotes para todo o sistema são bons, pois reduzem o inchaço nos sistemas das pessoas. A fixação de versões é boa porque ajuda a equipe a manter um conjunto consistente de versões e pode ajudá-lo a identificar uma coleção completa de versões que funcionam bem juntas.

Se seguirmos a rota de todo o sistema, sugiro manter a fixação da versão. Por exemplo:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

O Projeto A poderia usar o fsm-1.0 enquanto o Projeto B usa o fsm-1.1. O Projeto C vem e pode ser reutilizado. Os usuários devem ser capazes de especificar versões específicas de plugins em seus arquivos dependencies.json ou patch mínimo, versões secundárias ou principais.

Depois que as dependências são baixadas, um arquivo dependencies-lock.json pode ser gerado e verificado no controle de origem.

@mhilbrunner Eu definitivamente concordo, acho que a mentalidade "este deve ser um plugin" é forçada um pouco demais, exatamente essas situações desencadearam esses pensamentos. Acho que coisas mais comuns como o SpringArm valem a pena estar no motor, assim como o InterpolatedCamera , que Juan quer que seja removido, é insanamente útil e legal! Mesmo que essas coisas sejam apenas algumas linhas de código, elas demoram um pouco para acertar, então "isso é muito pequeno" também é uma justificativa ruim para empurrar para a AssetLibrary.

Meus pensamentos estavam principalmente centrados em "Bem, o líder do projeto disse que é assim, então o que pode ser feito para melhorar a nova situação?"

Eu gostaria que o esforço pesado de recursos como plugins fosse reduzido um pouco, mas de qualquer forma acho que as mudanças apresentadas ajudariam muito!

@saltares Sim, esse foi o meu pensamento. Eu sou um grande fã de carga para Rust. Funciona praticamente da mesma forma. As bibliotecas são instaladas em uma pasta de todo o sistema em todas as versões que já foram necessárias localmente. A descrição está em um arquivo e uma configuração específica está em um arquivo .lock , funciona muito bem!

Fico feliz que isso já tenha despertado algumas discussões :blush:

Segue minha opinião sobre os pontos acima:

Empurrando coisas para fora do motor

Empurrar coisas para fora do motor é o caminho a percorrer. Existem muitas plataformas onde o tamanho do deploy importa (mobile, html5) e o bloat é uma grande preocupação para um projeto do tamanho de Godot, então não podemos simplesmente ficar felizes em incluir tudo.

A filosofia para mim deve ser que algo deve fazer parte do mecanismo somente se TODOS os critérios abaixo forem atendidos:

1. É usado com relativa frequência
2. É difícil fazer você mesmo
3. Existe apenas uma maneira de fazer esse recurso

Isso exclui o braço da mola, o terreno e espero que possa ajudar a, no futuro, remover recursos como InterpolatedCamera, Vehicle, etc. que acredito que deveriam estar fora do motor.

A principal preocupação sobre isso é que, se algo não for oficial, não será mantido. É aqui que vocês estão errados.

Ninguém disse que essas coisas não deveriam ser oficiais, podemos ter um repositório oficial para elas e elas podem ser extensões próprias. As demos são mantidas dessa maneira e estão atualizadas, então não vejo por que não funcionaria para um repositório de extensão oficial.

As extensões devem parecer parte do mecanismo

Sobre esses pontos:

• facilitar a extensão de nós personalizados, permitir herança de script entre idiomas

Eu sou muito contra isso. Não há nenhum benefício prático em fazer isso, e o custo de implementação é muito caro. Desculpe pessoal, eu sei que parece um bom recurso de se ter, mas ponderar custo/benefício/risco é do lado muito negativo.

Também acho positivo que nós ou recursos personalizados devam aparecer como se NÃO fossem essenciais, é uma coisa boa para os usuários finais. Os usuários não são estúpidos e essa informação não deve ser ocultada para eles.

Se um novo nó for adicionado a partir de uma extensão e for feito com um script, isso deve ser mostrado na caixa de diálogo de criação.

• A herança de script não é sugerida ao anexar um script - a substituição é o padrão para esses casos.

Isso precisa definitivamente ser feito e seria uma adição muito bem-vinda.

• adicione o gerenciamento de dependência adequado com instalações de ativos em todo o sistema. Mova addons para fora do próprio projeto com uma maneira de trazê-los de volta para modificação

Meu sentimento sobre isso é que pode funcionar de forma fantástica ou resultar em uma bagunça completa e complementos que quebram sem uma razão óbvia. Observando como outros mecanismos funcionam com isso, não parece que ter gerenciamento de dependências seja tão importante para mim.

• permitir que scripts sejam referenciados por nome de classe e namespace para evitar caminhos super longos no caso de ativos.

Isso é algo que discutimos antes, mas a conclusão que chegamos foi que deve ser principalmente dependente da linguagem do script (e não fornecido pelo próprio mecanismo como um ScriptDB principal), com um pequeno aprimoramento de usabilidade na nova caixa de diálogo do script, caso você queira usar uma classe global.

Meu sentimento sobre isso é que pode funcionar de forma fantástica ou resultar em uma bagunça completa e complementos que quebram sem uma razão óbvia.

Acho que os complementos nunca devem atualizar automaticamente no nosso caso, mas talvez deva haver uma lista de instalados com a versão listada e atualização manual, para que o usuário possa solicitar atualização e verificar imediatamente se algo foi quebrado.

Este comentário é separado em seções recolhidas devido ao seu grande comprimento.

Quer uma câmera? Godot tem uma câmera que pode seguir um jogador, com pouco ou nenhum código seu. Quer fazer uma animação em Godot? Não só você pode fazer animações de personagens, esse mesmo sistema pode (quase) substituir aquele sistema de cut-scenes em que você trabalhou tanto, precisando apenas de cinco ou mais linhas de código de você. O editor foi usado até para fazer outros editores como RPG in a Box. É fantástico o quanto você pode criar em Godot.

Agora, com isso fora do caminho, espero que qualquer um que esteja lendo isso possa entender o que estou pensando enquanto tento responder a alguns dos pontos de redução em relação a empurrar as coisas para fora do mecanismo. (Isso não responderá à seção "As extensões devem parecer parte do mecanismo", pois não tenho pensamentos sobre isso atualmente.)

Empurrar coisas para fora do motor é o caminho a percorrer. Existem muitas plataformas onde o tamanho do deploy importa (mobile, html5) e o bloat é uma grande preocupação para um projeto do tamanho de Godot, então não podemos simplesmente ficar felizes em incluir tudo.

Posso concordar que o inchaço é uma preocupação, mas quando vejo o que você está querendo remover até agora, me pergunto se realmente vale a pena remover esse material. Mesmo se você remover nós como Vehicle, InterpolatedCamera, etc... Quanta diferença no tamanho do arquivo isso realmente fará? Talvez meio megabyte? Talvez alguns megabytes? Mesmo que economize vários megabytes, qual é a diferença entre um download de 35 MB e um download de 45 MB? Os recursos do jogo preencherão rapidamente esse vazio de 10 MB, independentemente! A menos que você planeje remover metade do motor, não vejo o ponto.

Se você realmente está preocupado em economizar o máximo de espaço possível, posso sugerir tornar mais fácil para o usuário final remover os nós que não precisam do mecanismo? Deixe que as pessoas que vão usar o motor decidam se estão bem com o inchaço – não decida por elas.

Agora é claro que não podemos simplesmente incluir todas as sugestões que nos são dadas...

1. É usado com relativa frequência
2. É difícil fazer você mesmo
3. Existe apenas uma maneira de fazer esse recurso

...e essas diretrizes são um ótimo ponto de partida para examinar o que deve ser permitido no motor. Não há dúvida de que todos os três pontos já estão sendo considerados para cada solicitação de recurso que chega pelo rastreador de problemas.

algo deve fazer parte do motor somente se TODOS os critérios abaixo forem atendidos

Mas vamos lá. O destino de um recurso ou nó não deve depender tanto de ser um recurso principal. Suas diretrizes sugeridas são ótimas, não me entenda mal, mas não devemos usá-las como uma lista de verificação. Isso é o que a YoYo Games faz quando você sugere um recurso em seus fóruns, e é outra parte do motivo pelo qual fui afastado do mecanismo deles - pode ser feito usando uma extensão? Sim? Então nossa resposta é fazer uma extensão. Adivinhe quantas solicitações de recursos foram negadas porque poderiam ser transformadas em extensões, independentemente de quão razoável seria estar no mecanismo, de quão fácil seria implementar em comparação ou de como a comunidade se sente sobre esse recurso.

O que estou dizendo é que você pode definitivamente manter essas diretrizes em mente. Você pode considerá-los sempre que um recurso for sugerido. Mas se todas elas se aplicam NÃO deve ser o fator decisivo para a inclusão de um recurso. Pese a ideia em relação a essas diretrizes, considere a importância de cada uma dessas diretrizes e aplique peso a esses fatores... Só porque uma ideia não funciona parece que é usado com muita frequência não torna automaticamente uma má ideia (lembre-se de que você pode não conhecer a verdadeira escala de como é usado, mesmo com vários anos de experiência). Só porque uma ideia é fácil de implementar não significa automaticamente que é uma má ideia. E só porque podemos implementar uma ideia de mais de uma maneira não significa que seja uma má ideia! Sem mencionar que talvez alguém esteja sugerindo a ideia X porque acha que outras pessoas se beneficiariam dela.

Lembre-se de que este é um mecanismo que se apresenta como amigável para iniciantes, e toda vez que um iniciante precisa codificar algo não específico para o jogo que não faz parte do mecanismo, ou procurar em alguma biblioteca de ativos para obter o código de que precisa , ou percorrer um longo caminho para obter o que eles querem da engine, isso pode afastá-los um pouco mais para outra engine, ou às vezes até mesmo para longe do desenvolvimento do jogo como um todo.

tl;dr : As diretrizes são ótimas quando são usadas como diretrizes e não como listas de verificação.

A principal preocupação sobre isso é que, se algo não for oficial, não será mantido. É aqui que vocês estão errados.

Ninguém disse que essas coisas não deveriam ser oficiais, podemos ter um repositório oficial para elas e elas podem ser extensões próprias. As demos são mantidas dessa maneira e estão atualizadas, então não vejo por que não funcionaria para um repositório de extensão oficial.

Eu pessoalmente discordo dessa ideia. Juntamente com o que eu disse acima (que removê-lo do mecanismo vanilla não economizará muito espaço), tenho que perguntar se vamos convertê-los todos para GDscript ou se vamos exigir para recompilar o mecanismo apenas para obter esses nós.

• Se os mantivermos como C++ e exigirmos uma recompilação... por que? Não há nenhuma boa razão para que sejamos obrigados a recompilar o mecanismo, a menos que estejamos alterando uma parte central dele ou adicionando nossa própria funcionalidade. Isso é apenas mais um tempo perdido no desenvolvimento, porque estamos esperando o processo de compilação terminar, além de exigir que o usuário médio instale outras ferramentas que eles podem nem usar novamente apenas para obter alguns nós primários. Agora isso soa como inchaço!

• Se os convertermos para GDscript, isso virá com todas as limitações do GDscript. Limitações como a sobrecarga potencial de nós filhos adicionais (especialmente se você estiver pedindo ao usuário para importar esse nó primário como uma cena), ter que usar caminhos em vez de nomes de classe para se referir a suas classes (embora você tenha abordado isso, é parece, mas sinto que preciso trazê-lo à tona), desempenho inferior (independentemente de quão pequena seja a diferença, ainda é menor), etc. É um pouco mais ideal que C++ porque você passou de recompilar para arrastar e soltar, mas...

Qualquer uma das opções também significa que os arquivos para esses nós terão que ser importados para o mecanismo com cada novo usuário (para C++) ou para a pasta do projeto com cada novo projeto (para GDscript) que deseja usá-los. Eu não sei sobre todos os outros, mas isso soa como um incômodo para mim, e parece que tornaria sua primeira diretriz ("É usado com relativa frequência") muito discutível. Vou tentar explicar porque acho isso.

Ao exigir um esforço adicional para usar esses nós, tenho certeza de que o número de usos dessa solução primária cairá, e essa solução primária realmente não será mais usada "com relativa frequência" onde poderia ter sido antes. Isso, por sua vez, aumentará lentamente o número de alternativas que recriam os mesmos recursos quando as pessoas pararem de aprender que há uma solução primária -- quando tenho certeza de que preferiríamos as versões existentes (neste caso, as nossas) às ser melhorado, em vez de ter um novo criado com o recurso X adicionado, um novo com o recurso Y e um novo com esses dois recursos, mas não tão otimizados, e assim por diante... Está criando esse mercado para alternativas quando as pessoas não sei se existe uma solução de primeira parte. Está criando uma confusão .

Além disso, você diz que eles permanecerão mantidos. Isso é ótimo! Mas quem vai mantê-los? Quais serão nossas diretrizes para adicionar coisas novas a este repositório? E vamos nos esforçar para garantir que esse repositório de extensões first-party sempre funcione, seja com uma versão estável ou com master? Basicamente, vale a pena o esforço do que é efetivamente um projeto separado?

a propósito, eu prefiro implementar vários scripts por suporte de nó
em vez de herança cruzada de idiomas. O primeiro é apenas algumas linhas
de código..

Em Dom, 10 de junho de 2018 às 13:51 PLyczkowski [email protected] escreveu:

Meu sentimento sobre isso é que pode funcionar de forma fantástica, ou resultar em um
bagunça completa e complementos que quebram sem uma razão óbvia.

Acho que os complementos nunca devem ser atualizados automaticamente no nosso caso, mas
em vez disso, talvez haja uma lista de instalados com a versão listada
e atualização manual, para que o usuário possa solicitar a atualização e verificar imediatamente se
qualquer coisa quebrou.

—
Você está recebendo isso porque comentou.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
.

Vários scripts por nó foram tentados algumas vezes e sempre falhando.

o que foi tentado é o nó multiscript, mas foi um aborrecimento

Em Dom, 10 de junho de 2018 às 15:01 Zireael07 [email protected] escreveu:

Vários scripts por nó foram tentados algumas vezes e sempre
falhando.

—
Você está recebendo isso porque comentou.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
.

Eu entendo que os ativos não devem ter a mesma aparência que o material interno. Mas também acho que eles deveriam estar em uma classe mais alta do que os scripts feitos pelo usuário. Eles devem ter uma separação clara para que seja fácil substituir/atualizar ativos sem precisar extraí-los do seu projeto.

Além disso, adicionar uma camada para ativos e permitir que eles se integrem melhor ao mecanismo para estendê-lo é uma ótima maneira de manter o núcleo pequeno e limpo, enquanto fornece facilmente novas funcionalidades por meio da biblioteca de ativos. Se os ativos puderem registrar novos tipos não apenas para nós/recursos, mas também classes a serem estendidas, de uma forma que seja globalmente acessível (ou seja, não dependente do caminho), seria um grande benefício para os frameworks serem construídos em cima do mecanismo.

Frameworks como Escoria poderiam se beneficiar muito com isso, e poderia haver outros frameworks para coisas como RPGs, plataformas, romances visuais, etc.

Tudo o que estou dizendo aqui é bastante abstrato, mas ter uma separação clara do que está embutido, o que é ativo de terceiros e o que é código do usuário (independentemente da forma como essa separação é apresentada) fará com que "mantenha o núcleo pequeno e forneça extensões "avançar com muita facilidade.

A herança entre idiomas parece uma ideia horrível para mim.

No trabalho que tenho feito com o TypeDB no EditorData, tenho mantido um namespaced-typename para o caminho do arquivo HashMap que é convertido em um dicionário no ProjectSettings após a modificação. Na minha ramificação, o analisador e o compilador GDScript estão usando esses dados para criar nomes globais para tipos. Neste momento, tenho scripts de tipo personalizado aparecendo. Os scripts podem acessá-los e herdá-los por nome. Além disso, esses dados são acessíveis a qualquer coisa que possa ver ProjectSettings. Assim, um CSharpScript visto pelo Editor pode gerar um mapeamento que é inserido no Dicionário ProjectSettings, permitindo que os tipos declarados em C# sejam acessíveis ao GDScript. Provavelmente também há uma maneira de envolver os dados do Dicionário ProjectSettings em um objeto C# que retorna objetos Script quando acessados, dessa forma o C# também poderia acessar tipos GDScript por nome.

Essa técnica mantém os namespaces compartilhados fora do núcleo e puramente dentro do contexto do Editor, por meio do qual os idiomas que optam por participar podem preparar seus próprios meios de acesso aos dados.

Eu gosto da sugestão do @karroffel para poder ter herança de script entre idiomas (nem sei se isso seria possível). De alguma forma, duplica automaticamente os métodos que delegam chamadas para o script base e também definem todas as mesmas propriedades/sinais/constantes, etc.

Eu também gostaria de um acesso mais simplificado ao conteúdo no AssetLibrary, com a capacidade de manter alguns plugins para o editor geral e outros plugins para apenas um único projeto.

O sistema TypeDB que estou fazendo também dará suporte ao editor para...

1. Ter todos os scripts personalizados aparecendo no CreateDialog
2. A extensão de um script de tipo personalizado faz com que você estenda automaticamente esse script ao adicionar um script ao nó
3. Remover um script que estende um script de tipo personalizado restabelecer o script de tipo personalizado após a remoção (para que você não possa remover um script personalizado - você deve usar o comando "Alterar tipo" no Editor).

Além disso, todas as alterações de interface que estou fazendo manteriam os scripts de tipo personalizado claramente entendidos como scripts, além de manter o script em questão acessível. Os usuários sempre saberão o que é um script e permitirão que eles acessem o script, mas ainda assim eles se sentirão como objetos in-engine até certo ponto. Mesmo dentro do GDScript, os nomes não são acessados ​​globalmente, como se fossem um tipo de núcleo, mas sim extraídos de um Dicionário global chamado Scripts . Até agora eu o tenho trabalhando com scripts de tipo personalizado, mas gostaria de eventualmente expandir para que o Dicionário registre cenas de tipo personalizado e qualquer script ou cena típico disponível no projeto também, provavelmente através do sistema de importação se a linguagem do script não tem um meio simples de adquirir o nome do tipo com namespace.

Como participei do processo de reflexão desta proposta, gostaria de destacar algumas coisas:

Minha visão de Godot

TLDR: Imagino o Godot como uma ferramenta que pode ser altamente estendida com ativos e plugins de uma maneira muito fácil, modular e amigável para iniciantes.

O motivo por trás da rejeição do meu SpringArm pr é mais do que razoável, e é por isso que @karroffel e eu discutimos sobre a direção que o motor poderia tomar para continuar sendo leve e, ao mesmo tempo, amigável.

O que eu adoraria ver é um mecanismo de núcleo limpo, pequeno e rápido e um ecossistema bem integrado de complementos e plugins.
Como o ArchLinux tem mais de um repositório de pacotes, acho que seria ótimo se Godot tivesse um repositório "oficial" (mantido por Godot) para a funcionalidade principal (e nós que agora são principais) e outro repositório para a comunidade. No "repositório de extensão" do núcleo Godot, eu colocaria todos os nós que são difíceis de codificar, mas não o suficiente costumavam ser enviados com a versão vanilla do Engine.
Nota lateral, o que muitas vezes não é levado em consideração é que alguns recursos podem ser fáceis de codificar, mas também podem exigir muita pesquisa antes de estabelecer essas poucas linhas.

Imagino que os usuários sejam capazes de baixar plugins e ativos que parecem estar "estendendo" o próprio mecanismo: dependendo do que você está baixando, você tem Godot-fps ou Godot-platformer ou Godot-racing.

Godot poderia ser o primeiro motor a se sentir realmente semelhante ao Unix e modular, superando até o Unity com suas extensões de editor. Muitos de vocês sabem como é bom quando seu sistema Linux não é "aquela distro", é o seu próprio sistema personalizado com suas funcionalidades muito pessoais.

Vantagens

TLDR: essa abordagem permitiria que o gerenciamento da Godot gerencie separadamente os principais recursos técnicos hardcore e plug-ins mais fáceis de usar, sem se preocupar muito com o inchaço do mecanismo

O que há de bom nessa proposta também é a separação de preocupação e o manejo do colaborador. Eu sinto que, por enquanto, não está claro o que é bom estar no núcleo e o que não é. Não há uma regra clara nem dados estatísticos sobre os quais falar. Alguns podem dizer que um determinado recurso é amplamente utilizado e outros pensam que não é.

Dividir Godot em diferentes "rings" dá a oportunidade de um gerenciamento mais refinado de PRs e recursos, e pode dar mais tempo para @reduz e outros desenvolvedores muito técnicos se concentrarem em coisas técnicas hardcore , enquanto outra equipe gerenciaria o anel de extensão, levando mais em conta o feedback do usuário e a usabilidade , em vez de ter que enfrentar o inchaço do motor, já que o "anel de extensão" ficaria inchado sob demanda.

Sobre herança multilíngue

À medida que Godot está crescendo, a loja de ativos pode facilmente se tornar uma bagunça em chamas. A estrita divisão entre a linguagem de script pode literalmente destruir qualquer tentativa que as pessoas façam de vender ativos e desenvolver um ecossistema na loja de ativos, matando muitas oportunidades para fabricantes de ferramentas freelancer fabricarem e venderem ferramentas para Godot.
As pontes linguísticas precisam ser mais completas se quisermos que qualquer mudança desenvolva um ecossistema dinâmico.
Por enquanto, herança entre idiomas parece ótimo para mim, mas não sou técnico o suficiente para dizer qualquer coisa sobre esse assunto. Eu só quero apontar um problema que provavelmente se apresentará em breve, especialmente porque há uma comunidade tão grande em torno do C#.

Observação sobre usabilidade

Estou usando Godot há quase um ano, e ultimamente sinto que acontece que as pessoas que decidem sobre recursos não estão usando o mecanismo para nada maior do que pequenas demos. @LikeLakers2 apontou um problema que eu sinto que é compartilhado por alguns dos usuários que não estão profundamente envolvidos na equipe principal de desenvolvimento.

Eu acho que o que é considerado inchaço é um tópico trivial no esquema maior das coisas, não é como se a decisão que tomamos agora seja o que precisaremos respeitar por toda a vida de Godot. Ser open-source nos permite fazer mudanças sempre que quisermos, o único problema é que quanto mais esperarmos, mais pesada será a decisão de mudar.

Agora isso também é uma discussão para outro dia. Agora no presente os fatos são,

1. Godot é um motor de jogo compacto, rápido e portátil. E eu gosto muito, mas, ....
2. O executável do Godot tem cerca de 45-60 MB, dependendo de vários fatores. Mas o modelo de exportação pode ter até 300 MB. Agora isso é um grande golpe para o primeiro ponto.
3. Godot tem muitos recursos incríveis que o tornam um deleite para os iniciantes, como Camera Follow, Parallax BG e Vehicles, isso é uma grande vantagem em relação a outros mecanismos de jogo semelhantes. Como torna a criação de jogos muito mais simples no Godot. E torna Godot um lar para muitos desenvolvedores novatos, que não têm as habilidades para escrever suas próprias implementações para essas ferramentas.

Agora, o que acontecerá se removermos recursos que algumas pessoas consideram inchados. Bem, o motor certamente será mais compacto, mas isso é necessário? Não vejo problema em baixar um Engine de 100 MB se ele atender melhor às minhas necessidades. Mas e a exportação, um motor de 100 MB não exporta jogos maiores?

Provavelmente sim, mas em um mundo onde os desktops não parecem usar nada menos que 256BG SSD + 1TB HDD e até mesmo os telefones têm espaço a partir de um mínimo de 16GB, o que é mais do que provável que aumente , seria isso MAU?
Quero dizer que não precisamos remover nada ainda, só precisamos começar a gerenciar algumas coisas melhor e deve ser isso.
Os recursos devem ter algum tipo de lista de importância a ser decidida se eles devem estar no núcleo ou não, mas isso não significa que se torne uma lei, mas sim uma regra geral.

E para os nit-pickers, poderíamos remover algumas ferramentas extremamente inutilizadas, mas é isso. Os recursos não incham um motor, a menos que sejamos descuidados. E mesmo todo o inchaço no Unity não impediu as pessoas de usá-lo, tem.
E eu absolutamente não quero dizer que não devemos nos preocupar com o inchaço, mas ser cuidadoso e ser paranóico são assuntos diferentes juntos.

Quanto à herança multilíngue, não vejo utilidade para isso aqui. Claro que devemos ser capazes de interagir com scripts de vários idiomas, mas com herança! Isso é provavelmente mais trabalho do que eu poderia imaginar com benefícios que simplesmente não parecem valer a pena.
Considerando que, multi-script pode ser apenas a solução para muitos problemas, desde criação de complementos até melhor modularidade. Embora essa seja a minha perspectiva.

Há algo a ser dito sobre a limitação do número de nós e tipos de recursos que vêm na caixa. Ao transferir quaisquer recursos menos usados ​​para um download externo, você torna 1. muito mais fácil para novas pessoas controlarem o sistema apenas por "brincar" sem serem sobrecarregados pela amplitude de recursos (paralisia de decisão), e 2. não acabe criando tanta bagagem herdada se alguns dos ativos de cenário de caso de uso mais restritos acabarem tendo um fluxo de trabalho que não é tão bom quanto algo que vem depois com uma API diferente.

Quando o último acontece com built-in, você está preso a eles. Quando isso acontece com os ativos para download, os mais populares tendem a se tornar padrão de fato ao longo do tempo, mas não têm seu destino permanentemente entrelaçado com o de Godot. Isso significa que eles podem desaparecer na obscuridade sem ter que se preocupar tanto em quebrar a compatibilidade esperada do núcleo.

O ponto de herança entre idiomas precisa de alguma explicação. Não só considero uma má ideia, como também não vejo como é remotamente possível.

1. O executável do Godot tem cerca de 45-60 MB, dependendo de vários fatores. Mas o modelo de exportação pode ter até 300 MB. Agora isso é um grande golpe para o primeiro ponto.

300 MB os modelos de exportação? Você quer dizer com ativos?

@neikeq o problema é que, se todo o seu projeto estiver em C #, mas você estiver usando um nó personalizado baixado da AssetLibrary, esse nó é apenas um nó regular, provavelmente com apenas um GDScript anexado.

Se você quiser "estender" o nó, não pode! Acho que você pode adicionar um nó filho para adicionar novas funcionalidades, mas dessa forma não é possível substituir as coisas.

Implementação

Atualmente as linguagens de script usam um padrão muito semelhante para chamadas herdadas que podem ser generalizadas.

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

O padrão aqui é

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

Portanto, ele começa na parte inferior da árvore de herança do script e tenta chamar os níveis superiores se não houver tal método encontrado.

Se cada script tivesse um Ref<Script> parent_script em vez da estrutura de herança específica do idioma, isso poderia ser generalizado para

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

Afinal, isso pode não ser uma boa ideia, mas não ter a opção de substituir coisas entre idiomas pode ser um problema ao longo do tempo se empurrarmos mais o AssetLib.

@neikeq Veja isso,

@swarnimarun São modelos de exportação para todas as plataformas, todos os arcos suportados, depuração e lançamento, seu tamanho é completamente irrelevante para o "inchaço" do mecanismo. Podemos decidir suportar apenas a versão Linux X11 de 64 bits e este arquivo terá 20 MB...

@akien-mga Eu não pretendia chamar isso de inchaço.
Mas um novo usuário irá baixá-lo em tamanho real, ele não será experiente o suficiente para saber que pode construir separadamente ou baixar para uma plataforma específica.

Como é irrelevante quando isso é o que fornecemos para usuários iniciantes?

@akien-mga: O tamanho dos modelos de exportação é importante, pois seu argumento para remover nós foi

implantar tamanho importa (móvel, html5)

@swarnimarun @Zireael07 Sim, o tamanho dos modelos de exportação importa individualmente , mas meu ponto é que medir o tamanho de um pacote de modelos não nos dá nenhuma indicação. O tamanho de um modelo (por exemplo, o modelo de lançamento wasm, 3,4 MB compactado ou o APK de versão Android, 23 MB compactado com libs armv7 e x86) é muito mais relevante do que "baixar tudo o que é necessário para desenvolver leva 350 MB" (+ talvez 10 GB para Visual Studio se você precisar construir algo...). O que importa se o tamanho de um jogo mínimo terá em plataformas onde o tamanho importa (web, mobile).

Embora eu ache que o tamanho do deploy seja muito importante, também acho que o que precisa ser levado em conta também é o tempo do desenvolvedor. Por exemplo, o Unreal tem literalmente qualquer recurso que você possa estar procurando, mas o fato de haver tantos torna o processo de desenvolvimento altamente ineficiente, porque toda vez que você precisa fazer algo com ele, primeiro precisa descobrir qual funcionalidade integrada você precisa usar e, em seguida, aprender a usá-lo corretamente.

Isso é algo que eu realmente amo em Godot. Você pode codificar seu recurso imediatamente e, em seguida, alguém virá e lhe dirá "yo, você sabia que tínhamos essa coisa interna que você poderia usar?"

O problema quando um motor tem muitos recursos juntos é que desenvolver com esse motor se torna uma experiência muito cansativa. Sim, é bom ter todos os recursos de que você precisa, mas é uma dor gigantesca passar por todos eles para descobrir o que você realmente precisa. Isso é inchaço. E é por isso que estamos propondo ter recursos bem integrados sob demanda.

adicione o gerenciamento de dependência adequado com instalações de ativos em todo o sistema. Mova os complementos do próprio projeto com uma maneira de trazê-los de volta para modificação.

Isso é o mesmo que perder a portabilidade. Meus plugins fazem parte do meu projeto, eu preciso disso em qualquer computador que eu esteja trabalhando e preciso da modificação concreta de cada plugin para cada projeto... Não vejo nenhum benefício em ter meus plugins armazenados em .local/whatever . Isso é uma espécie de ofuscação meus projetos.

O sistema atual de res://addons é bom... gratuito para o usuário e portátil em torno de computadores. Se não houver reclamações sobre este sistema, é necessário mudar isso? Há muitas outras coisas que os usuários realmente reclamam...

@Ranoller você poderá a qualquer momento copiar o plugin para a pasta do jogo.
De qualquer forma, nesse caso, seu project.godot listaria seu plugin como uma dependência e seria baixado para seu novo computador com a versão correta

Baixado? Meus plugins estão dentro do projeto que está dentro do pendrive, e fazem parte do repositório git... Não entendo proposta... Plugins mudam igual que outro código... Mudo mais código de plugins que gamecode, eu não quero numerar plugins por versão e trabalhar fora do projeto... Cada mudança de código de linha precisará alterar manualmente todos os plugins em cada computador?... Realmente os plugins parecem parte do projeto .. . Dar plugins do repositório git é bobagem para mim, mas eu realmente acho que não entendo algo sobre isso ...

@Ranoller a ideia é mover esses plugins para fora do projeto que você não precisa modificar . Por exemplo, o InterpolatedCamera será apenas um nó que você deseja usar como está, não alterar o código dele.

O mesmo pode ser o caso de plugins somente de editor, como listas TODO ou integração com git, etc. Essas são coisas que você deseja usar, mas não alterar.

Isso é muito parecido com um gerenciador de pacotes e as bibliotecas funcionam em todas as linguagens que não sejam C e C++. Você tem um arquivo que especifica todas as dependências e, em seguida, o gerenciador de pacotes buscará essas dependências. Isso acontece mesmo quando você muda de PC - o gerenciador de pacotes baixará todos os pacotes ainda não existentes.

Quando você deseja modificar algo , você traz o código para o projeto. Então está no seu git e no projeto com todo o seu código fonte etc. Mas nem sempre é esse o caso.

Minha proposta é ter coisas fora do projeto por padrão até que você realmente precise modificar alguma coisa.

Atualmente, muitos ativos são principalmente modelos que você precisa modificar, ter um sistema desse tipo pode mudar isso, então as coisas são de propósito mais geral por meio de APIs, não por meio de modificação de origem.

@karroffel Mas como a herança entre idiomas funcionará em cada idioma? Pode ser fácil para o GDScript, que está fortemente acoplado ao mecanismo, mas é uma história completamente diferente para linguagens de uso geral, como C# ou outras linguagens adicionadas ao GDNative.
Eu realmente não consigo ver como isso poderia ser alcançado, muito menos como não poderia fazer mais mal do que bem.

IMO, não é uma boa ideia modificar o conteúdo de um complemento do qual seu projeto depende. Se alguma modificação for necessária, basta copiar o conteúdo fora da pasta do addon e fazer suas alterações lá.

EDIT: ou "fork" o addon 😜

@neikeq O que você modifica está dentro do seu projeto. Quando você deseja modificar um complemento, ele é copiado dentro do seu projeto e modificado apenas localmente.

@karroffel Uma ideia de plugin de projeto e plugin de editor pode ser necessária para evitar confusão, com separação clara dos dois.

@QbieShay E se houver uma atualização que modifique os arquivos que você modificou?

@neikeq A herança de script não é A SOLUÇÃO para este problema, seria apenas uma. Atualmente, não há uma boa maneira de substituir a funcionalidade de um nó com um script anexado quando você deseja usar uma linguagem de programação diferente.

Se tivéssemos a opção de substituir métodos na API Script , isso também seria bom! (basicamente definindo externamente novos métodos e substituindo métodos existentes).

@PLyczkowski essa é uma sugestão que também seria útil, mas o que proponho não se limita a isso - e por um motivo.

Vamos pegar o exemplo InterpolatedCamera novamente. Eu nunca vou tocar no código-fonte para isso, eu só vou usá-lo. Ter a fonte no meu projeto seria um desperdício. Além disso, a maioria dos projetos que faço são todos 3D, então eu provavelmente teria esse código copiado em todos os meus projetos.

Por outro lado, uma integração git pode ser super útil para adicionar um comportamento personalizado que é difícil de expressar com git hooks, portanto, a personalização é desejada.

Não há linha preta/branca quando algo deveria estar dentro do projeto e quando fora, editor ou não.

@neikeq

E se houver uma atualização que modifique os arquivos que você modificou?

Nesse caso, você perderia as informações de versão, portanto, não poderá mais atualizar facilmente. Você deve usar uma ferramenta como o git para esses casos então.

A ideia é

• fora do projeto: mais fácil de atualizar, mais fácil de ter projetos cruzados
• projeto interno: personalizável, perde status de ativo, sem atualizações automáticas

Basicamente, eles se tornam apenas arquivos normais quando você os copia em seu projeto.

Lendo isso, posso dizer que evitar o inchaço e minimizar o tamanho do arquivo dos jogos é válido. Permitam-me lançar algumas idéias aqui embora.

• Godot poderia usar um sistema que retira o código do jogo usado por nós que ele não usa (ou seja, a maioria dos nós 2D com muitos jogos 3D e a maioria dos nós 3D com muitos jogos 2D). Isso reduzirá a pressão para não aceitar novos tipos de nós para manter o tamanho do arquivo do jogo baixo. Os usuários do Unity, por exemplo, já estão usando algo semelhante para obter ótimos resultados.
• Godot talvez possa ter um navegador de ativos embutido que se conecta a uma página de plug-in no site Godot. Você escolhe quais nós personalizados deseja e ele será instalado automaticamente no local correto. Plugins que não são usados ​​são removidos quando o jogo é empacotado.
• Talvez até, nós personalizados populares possam ser empacotados com compilações Godot (como o Blender faz com complementos). Os nós personalizados também devem ser marcados, pois geralmente podem ser de nível mais alto e podem, até certo ponto, ser mais uma caixa preta do que os nós mais genéricos.

Meus 2 centavos de qualquer maneira.

@Ace-Dragon

1. Eu acho que seu primeiro ponto seria muito legal ter como um recurso de todo o mecanismo. Se seu jogo exportado não usa um Node ou se um Node não é usado por nenhum dos Nodes que você está usando em seu projeto, seria legal se fosse possível excluí-los automaticamente do binário final. Fora isso, atualmente você só precisa confiar em switches e recompilar o mecanismo. :-/

2. Isso é basicamente o que a Biblioteca de Ativos já é. O problema é que ele não tem nenhum conceito de dependências, coloca coisas diretamente no diretório do seu projeto e não tem nenhum meio de manter um determinado conjunto de plugins em todo o sistema para cada projeto que você faz.

3. Os nós personalizados são sempre marcados explicitamente, portanto, não há necessidade de se preocupar com isso (eles têm um ícone de script ao lado deles porque você cria nós personalizados usando um script para estendê-lo). Por serem scripts, eles nunca são enviados com o mecanismo. Eles seriam parte de algum tipo de plug-in, então, se houver, você pode ter algo mais como meu repositório godot-next, que é um repositório de "extensões de nó" para coletar coisas. Seria apenas uma capacidade mais "oficial" do que qualquer coisa (esse repositório também poderia dar muito trabalho, lol).

Ok, devagar mas pego... Se eu mantiver os addons dentro do projeto eu poderia trabalhar no código do plugin como em outros scripts sem perder a integração do git com o projeto atual e sem perder a portabilidade... plugins em uma ferramenta para outros desenvolvedores ou em uma ferramenta geral para todos os meus projetos eu compartilho em uma forma de pacote externo que pode ser atualizado com o repositório git externo da ferramenta e alterado para outras pessoas com a biblioteca de ativos... Se é, para mim está ok... Se outro desenvolvedor usa a ferramenta, e precisa de sua versão pessoal, ele precisa armazenar dentro do projeto e neste caso o plugin não funciona (não perca seu próprio trabalho )... Isto é?

@Ranoller Sim, acho que você entendeu a essência da proposta dele.

Alguns comentários sobre o que vocês estão discutindo

1) Se esse fosse um problema real que precisasse ser resolvido, prefiro suportar vários scripts por nó (que são apenas algumas linhas de código), em vez de herança cruzada de idiomas (o que é uma loucura). Eu ainda não acho que este é um problema que precisa ser resolvido.

2) Não gosto da ideia de um gerenciador de pacotes e instalação de complementos em todo o sistema. Eu acho que é uma ideia terrível e nada significativo é ganho com isso. Eu vi o quão traumático é até mesmo para os desenvolvedores do Unity atualizar uma versão de um ativo em grandes projetos e ver tudo quebrar e passar dias consertando.

3) Não gosto da ideia de gerenciamento de pacotes em si. Já vi usuários do Unity roubando o que obtêm da loja de ativos na maior parte do tempo. Muitas vezes, eles apenas o usam como base, depois trabalham nele e o personalizam para seus próprios usos, porque o ativo que você obtém está apenas 60/70% do caminho que você deseja ... ou eles só queriam ver como é feito e, em seguida, fazer suas próprias coisas mais tarde.

Acho que não se ganha nada na vida real com as propostas que estão sendo discutidas, então não pretendo acrescentar muito a essa discussão.

Quanto tamanho do motor podemos reduzir se permitirmos que as pessoas exportem sem nenhum material 3D de maneira simples? Muitos jogos (metade? mais da metade?) não requerem recursos 3D, mas ainda ficam lá no mesmo binário. Eu sei que teoricamente pode ser recompilado com uma macro em todas as plataformas, com um pouco de investimento ...
Além disso, seguindo essa ideia, se os módulos fossem apenas bibliotecas dinâmicas "internas" que fazem parte das distribuições oficiais do mecanismo, adicionar mais recursos ao mecanismo seria menos problemático no sentido de que eles podem ser excluídos facilmente (apenas isso ), no entanto, usar bibliotecas dinâmicas como essa pode ser um pouco restritivo para algumas plataformas (celulares e HTML5 principalmente). Então, para módulos, eu entenderia que GDNative é o preferido (oh espere... tem os mesmos problemas ^^).

@reduz como vários scripts funcionariam? E como isso contribuiria para a extensão do motor? Você explicou sua ideia em uma edição existente? (perguntando porque provavelmente é demais para explicar neste tópico)

adicione o gerenciamento de dependência adequado com instalações de ativos em todo o sistema. Mova addons para fora do próprio projeto com uma maneira de trazê-los de volta para modificação

Não. Eu gostaria deles no diretório do projeto por questões de robustez. Mas talvez com uma maneira de atualizar os escolhidos manualmente com o gerenciador de pacotes e talvez com o cache de todo o sistema deles.

Quanto às preocupações com o inchaço, gostaria de ter mais controle sobre os _modules_, e isso já foi votado na pesquisa do Patreon de janeiro de 2018:

Prioridade do roteiro: mais opções para desativar a compilação de partes do mecanismo para criar tamanhos binários menores [Esperado para 3.1]

É difícil comentar sobre esta proposta, pois ela toca uma variedade de coisas e as pessoas estão comentando sobre diferentes aspectos e levantando questões diferentes.

No geral, acho que a proposta do "gerenciador de dependências" soa bem no papel, mas acho que a implementação não trará nenhum benefício que a simples venda de complementos na pasta do projeto não trará. Será necessário incorporar um mecanismo complexo de gerenciamento de dependências para resolver 1 caso de "mais fácil de instalar". Este projeto já tem mais de 3.000 questões abertas com uma pequena equipe de colaboradores. Introduzir algo tão complexo quanto o gerenciamento de dependências é uma arma na minha opinião.

Concordo com @reduz que o core deve ser minimalista. Na minha opinião, tudo e qualquer coisa que não possa ser classificada como "núcleo" deve ser incorporada de forma independente. Como usuário espero que Godot seja um jogo multi-plataforma _engine_. Se eu quiser o Godot _game framework_ (veículos, câmeras interpoladas, terreno, controladores de jogadores etc.) ele deve estar disponível como um complemento de primeira classe (ou módulo?) independente do núcleo. Acho que melhorar a história do complemento ajuda com isso, mas um gerenciador de dependências completo e um gerenciador de complementos automatizado parecem estar pressionando-o para um baixo benefício líquido.

Meu comentário final seria ser cauteloso ao atender a "iniciantes" e abandonar usuários "poderosos". Godot vem chamando a atenção de usuários mais avançados devido aos seus poderosos recursos (módulos, gdnative, gdscript, editor, etc.) e flexibilidade. São esses tipos de usuários que testam o godot, ultrapassam seus limites, exploram sua API e muitas vezes contribuem de volta para o projeto. Esses são os mesmos usuários que podem criar links simbólicos para um diretório em seu sistema de arquivos para reutilizar seus complementos em vários projetos.

Se a ideia é remover nós de nível superior do núcleo, esses nós devem estar prontamente disponíveis e fáceis de encontrar para download. Idealmente, poderíamos mantê-los como "oficiais", para que tenham melhor visibilidade (assim como os nós do motor). Então os recursos oficiais podem ser usados ​​em demos e tutoriais sem muito problema.

A vantagem de terceirizar esses é que eles podem ser melhorados e lançados sem ter que esperar por uma nova versão do motor. Portanto, os bugs podem ser corrigidos imediatamente, pois para uma extensão é muito mais simples empacotar uma nova versão.

Acho que no final o gerenciamento de pacotes seria um aborrecimento na maioria das vezes. Mesmo no caso de uma nova versão de um nó personalizado que você adicionou ao seu projeto, atualizá-lo pode causar muitos outros problemas (mesmo com o semver, já que você pode ter contornado um bug que agora foi corrigido).

OTOH para alguns plugins de editor, pode fazer sentido tirá-los do projeto e atualizá-los com frequência. Meu plugin de importação Tiled é um exemplo. Você provavelmente não quer que ele seja enviado com o jogo e quer ter a versão mais recente que suporte mais recursos e tenha correções de bugs.

Isso se aplica ainda mais a outras extensões de editor, como gerenciadores de git e rastreadores de tempo. Você pode nem se importar se seus colegas de equipe têm o plug-in do rastreador de tempo ou não, não está relacionado ao projeto. Ainda assim, você tem que colocar na sua pasta addons e habilitar nas configurações do projeto, então tome cuidado para não fazer commit com o resto do jogo. Esses são provavelmente a minoria dos plugins, mas ainda ter plugins de todo o sistema que não estão vinculados ao projeto tem um caso de uso real.

Acredito que o meio termo seria criar um gerenciador de pacotes como uma ferramenta externa, não tê-lo integrado ao Godot. Nem precisa ser oficial (embora possa ser "endossado"). Se algumas mudanças forem necessárias no mecanismo básico para dar suporte a isso (como ter plugins globais), não seria um grande problema adicionar, especialmente se eles forem somente editor.

Então aqueles que acham que é benéfico podem usá-lo. Se ele se tornar generalizado e todos estiverem usando, teremos as estatísticas de uso e feedback sobre usabilidade para decidir se e como integrá-lo totalmente no mecanismo básico.

Agora, herança de script cruzado para mim é um não-não (se isso for possível). Multiscript é meio estranho, mas substituiria efetivamente a herança de script cruzado de uma maneira mais limpa. Embora levante algumas preocupações, como: como chamar a função de outro script no mesmo objeto? Acho que é outra discussão.

Fazer referência a scripts pelo nome OTOH parece muito bom. Idealmente, todos os recursos podem ser referenciados por nome para que os caminhos não sejam um problema a ser resolvido se você decidir mover as coisas.

@vnen o único problema que ainda vejo é a incompatibilidade entre addons e projetos. Como você resolveria esse problema?
Porque se houver uma lib de extensão oficial mantida pela Godot, ou cada nó é enviado em todos os idiomas possíveis, ou vejo a herança entre idiomas como a única maneira de manter a facilidade de uso.

@vnen se você referenciar todos os ativos pelo nome, será uma bagunça conflitante. Isso é mais adequado para scripts, pois apenas os programadores precisam criar nomes exclusivos para suas classes para digitá-los e usá-los (ou, mais raramente, recursos). Para as outras coisas, se nos livrarmos dos caminhos, precisaríamos disso https://github.com/godotengine/godot/issues/15673 , a menos que você queira que artistas, designers etc tenham que nomear todos os seus ativos exclusivamente (o que ainda vem com a questão da renomeação).

@Zylann @vnen O TypeDB que estou escrevendo deve permitir que as pessoas registrem opcionalmente um nome para qualquer ativo, teoricamente. Atualmente, estou usando apenas para scripts e pretendo fazê-lo também para cenas de tipo personalizado, mas você também pode modificá-lo para trabalhar com recursos. A lógica atualmente tem apenas um HashMap para scripts e cenas, mas talvez eu possa generalizar a lógica para lidar com qualquer tipo de ativo, tudo em HashMaps categorizados.

Eu posso respeitar as preocupações do reduz com o material de todo o sistema, e essas são certamente preocupações com plugins que modificariam as ofertas do mecanismo, mas quando se trata de recursos para o Editor especificamente, como vnen está descrevendo, posso definitivamente ver que é útil em uma forma relativamente segura. Se as pessoas estão adicionando plugins para conceder ao Editor mais recursos, essas não são coisas que elas normalmente abrirão e modificarão. Eles vão apenas usá-lo como está, ou se eles fizerem modificações, provavelmente será para promover essas mudanças para melhorar as ferramentas. Você não está adaptando-os a um jogo, afinal. Como tal, se for para um plugin como este, acho que devemos ter um meio de conceder facilmente esses recursos ao mecanismo quando você inicia um novo projeto (de alguma forma).

Um método possível que poderia facilitar as coisas sem precisar de um gerenciador de dependências seria simplesmente não compartilhar dependências entre plugins e, em vez disso, duplicá-las dentro do projeto, dessa forma, o controle de versão não é um problema. Isso tornaria um projeto individual maior potencialmente, mas se for para conteúdo relevante para o jogo e as pessoas estiverem mexendo com tudo de qualquer maneira, como reduz diz, eles podem simplesmente mover as dependências. O que precisaríamos nesse caso é uma maneira de os plugins declararem QUAIS dependências externas de plug-in eles têm e dar aos usuários a opção de personalizar onde eles procuram esse plug-in dependente. Dessa forma, se eles optarem por mover um plug-in e fizerem com que outros plug-ins o procurem no mesmo local, eles poderão personalizar isso. Mas então, por padrão, tudo funcionaria imediatamente, gerenciando suas próprias dependências. Este caso provavelmente também seria mais fácil de lidar com toda a proposta de plugins como subprojetos (#19178).

Isso nos impediria de ter dependências globais que requerem um gerenciador de dependências (questão número 3 do reduz). E poderíamos acoplá-lo a um recurso que permite aos usuários criar uma lista de ativos favoritos da Biblioteca de Ativos que eles podem optar por instalar automaticamente em seus projetos quando um novo projeto é criado (para que tudo ainda seja armazenado localmente, mas acontece automaticamente e eles não precisam sair manualmente, encontrar todos os seus plugins preferidos e baixá-los e instalá-los manualmente). Isso resolveria o problema de usabilidade com o qual @karroffel quer lidar com relação a estender facilmente o mecanismo com ativos idênticos ao criar um novo projeto.

Para plugins mais específicos do editor que não precisariam ser duplicados, talvez as pessoas pudessem sinalizar esses plugins "favoritos" e teriam links simbólicos feitos para eles automaticamente, armazenando os plugins em uma pasta de usuário de algum tipo. Então, talvez tenha "Favoritos do editor" e "Favoritos do projeto" para "Eu quero isso em todos os projetos, armazene-os em um local compartilhado e faça um link simbólico" e "Eu quero isso em todos os projetos, duplique-os", respectivamente.

Combine isso com o material do TypeDB para nomear scripts / personalizar tipos personalizados, e acredito que resolveria adequadamente todos os problemas mencionados, exceto o problema de herança de script / multiscript entre idiomas, que é algo completamente diferente.

Então, talvez tenha "Favoritos do editor" e "Favoritos do projeto" para "Eu quero isso em todos os projetos, armazene-os em um local compartilhado e faça um link simbólico" e "Eu quero isso em todos os projetos, duplique-os", respectivamente.

Talvez então seja mais conveniente ter "pacotes" de plugins - criados pelo usuário oficialmente aprovados + locais criados pelo usuário. Então, em vez de "Favoritos do Editor" e "Favoritos do Projeto", temos "Tiro em Primeira Pessoa", "Jogo de Blocos Voxel" ou apenas "Minhas coisas". Muito parecido com, por exemplo, os ativos iniciais do Unity, mas não há necessidade de enchê-los com texturas etc., diferentes tipos de rostos de mascote Godot devem ser suficientes :D

Isso também funciona como um gerenciador de pacotes, onde o gerenciador de pacotes agora são os pacotes de plugins de curadoria humana.

@starry-abyss Os plugins que as pessoas fazem agora já têm o potencial de serem "pacotes" de outros plugins (o usuário ou desenvolvedor de plugins pode apenas movê-los e mesclá-los). O objetivo aqui é ter uma diferença funcional entre as categorias em que o editor realmente executa operações de melhoria de usabilidade em nome do usuário para que o usuário não precise fazer as coisas manualmente.

Nessa medida, já temos o recurso "humans curating plugin bundles". O problema é automatizar tarefas tediosas, mantendo-o personalizável com produtividade eficiente em todos os casos de uso.

@Zylann

se você referenciar todos os ativos pelo nome, será uma bagunça conflitante. Isso é mais adequado para scripts, pois apenas os programadores precisam criar nomes exclusivos para suas classes para digitá-los e usá-los (ou, mais raramente, recursos).

É muito importante fazer coisas de namespace apropriadamente? Mas pode ser UIDs, não importa muito para mim, desde que não seja dependente do caminho. Até mesmo o caminho é como um nome, já que os recursos são remapeados para sua contraparte importada...

@QbieShay

o único problema que ainda vejo é a incompatibilidade entre addons e projetos. Como você resolveria esse problema?

Se isso for realmente um problema, o multiscript é provavelmente a solução mais simples. Foi removido principalmente por causa da discussão em #8546, mas acho que isso pode ser resolvido sem muito esforço.

Acredito que o problema de vários plugins fazendo a mesma coisa seja virtual. Já temos um star system no assetlib, esse sistema é apenas isso, um indicador do que é comumente usado e preferido.

A única coisa que é esquecido, mas na minha opinião é uma das razões pelas quais as pessoas estão pedindo adições no mecanismo principal é esta: Quem vai compilar essa coisa para todas as plataformas?

Claro que para um plugin gdscript isso não é um problema, mas para um plugin Cpp isso é um grande problema.

Se não resolvermos esse problema, a discussão sobre o que estará dentro do mecanismo principal se transformará em qual plug-in será marcado como oficial e, marcando os plug-ins como oficiais, arruinará o sistema estelar, porque as pessoas estão indo para apenas estrelar um plugin porque é apenas um oficial.

Então, na minha opinião, temos que resolver esse problema primeiro, e não tenho ideia de como. É possível, por exemplo, compilar para todas as plataformas através do Linux? Nesse caso, podemos usar algo como o Ubuntu Imager : https://www.maketecheasier.com/create-linux-distro/ para criar um ambiente linux já configurado para os fabricantes de plugins e usuários GDNative.

É possível, por exemplo, compilar para todas as plataformas através do Linux? Nesse caso, podemos usar algo como o Ubuntu Imager : https://www.maketecheasier.com/create-linux-distro/ para criar um ambiente linux já configurado para os fabricantes de plugins e usuários GDNative.

Não (as compilações do macOS e iOS só podem realmente ser compiladas a partir do macOS), e não acho que forçar as pessoas a inicializar um sistema operacional Linux ao vivo para poder fazer upload de bibliotecas GDNative para a biblioteca de ativos seja uma boa ideia.

No entanto, é possível compilar para todas as plataformas usando Travis CI e AppVeyor, que você pode configurar gratuitamente em repositórios públicos do GitHub.

Se não resolvermos esse problema, a discussão sobre o que estará dentro do mecanismo principal se transformará em qual plug-in será marcado como oficial e, marcando os plug-ins como oficiais, arruinará o sistema estelar, porque as pessoas estão indo para apenas estrelar um plugin porque é apenas um oficial.

Bem, o sistema estelar nunca foi implementado, então você não pode avaliar nada. Para os plugins oficiais, não é que vamos escolher um e marcar como oficial, somos nós que os criamos e mantemos.

Nós integrados para coisas básicas são uma das melhores coisas do editor, se nós ou recursos importantes forem removidos, o Gerente de Projeto precisará de modelos para baixar automaticamente os nós comuns.

Esta proposta também tem o risco de ativar o mecanismo em outro mecanismo "sempre online" e "lixo eletrônico", se feito, muitas outras coisas precisarão obter suporte oficial (correção de bugs) e disponibilidade (atualização de versão).

E a loja deve oferecer pacotes oficiais para uso offline (com suporte de loja offline no editor).

se feito, muitas outras coisas precisarão de suporte oficial (correção de bugs) e disponibilidade (atualização de versão).

TBH, manter as coisas no motor ou na loja é praticamente o mesmo. Os nós de veículos, por exemplo, têm poucos relatórios de bugs porque quase ninguém os usa, e mesmo os bugs que foram relatados nunca foram corrigidos. Acho a terceirização desses nós de tipo muito melhor porque é mais fácil fazer com que as pessoas tentem consertar as coisas sem ter que mexer com a fonte do mecanismo, então há mais contribuidores em potencial.

Se um nó de mecanismo tiver um problema, as pessoas abrirão um relatório de bug. Mas se for um plugin com código GDScript, é muito fácil para a pessoa alterar o código e testá-lo, provavelmente contribuindo com a correção de volta para a comunidade. Eu realmente vejo isso como um ganho. Mas somente se esses nós externos puderem ter uma integração fácil, o que não é o caso atualmente. Isso inclui boa visibilidade e documentação integrada.

E a loja deve oferecer pacotes oficiais para uso offline (com suporte de loja offline no editor).

Sim, e também deve ser fácil instalar pacotes offline.

@reduz

Não gosto da ideia de um gerenciador de pacotes e instalação de complementos em todo o sistema. Eu acho que é uma ideia terrível e nada significativo é ganho com isso. Eu vi o quão traumático é até mesmo para os desenvolvedores do Unity atualizar uma versão de um ativo em grandes projetos e ver tudo quebrar e passar dias consertando.

Tudo bem, mas por quê ? Quais são as limitações e problemas reais que você vê a partir dele? Dizer "não gosto" sem dizer por que não vai convencer as pessoas de que não é uma boa ideia; você deve dar pelo menos alguma explicação além das razões vagas mencionadas.

Ok, mas por quê? Quais são as limitações e problemas reais que você vê a partir dele? Dizer "não gosto" sem dizer por que não vai convencer as pessoas de que não é uma boa ideia; você deve dar pelo menos alguma explicação além das razões vagas mencionadas.

Assumindo o registro global "addon" no sistema:

• Baixe o addon v1.3 do sistema add-on online. Addon está instalado em ~/.godot ou o que não
• A versão é associada ao meu projeto em ~/my-project em algum tipo de armazenamento local (arquivo, sqlite, etc.)
• Eu atualizo para v1.4. Agora meu gerenciador de complementos precisa saber que o 1.3 não é usado por nenhum projeto e limpá-lo. Assim, o gerente tem uma funcionalidade extra para rastrear dependências e quais projetos têm quais dependências. Como alternativa, ninguém adiciona essa funcionalidade para que minha máquina local fique poluída com várias versões do mesmo complemento
• Decido que quero mover meu projeto para ~/big-project/game . Agora preciso de uma maneira de atualizar a referência ao meu projeto no registro do complemento. Como faço isso? Eu tenho que executar o gerenciador de complementos separadamente? Manager register new_proj_location ?
• A decisão agora é feita para armazenar dependências localmente no estilo requirements.txt python. Ótimo, problema resolvido. Exceto que eu voltei a não saber quais projetos dependem de quais pacotes globais, eu tenho que escanear o sistema para projetos godot ou registrar cada projeto ainda para evitar empilhar versões.
• Tudo bem, eu apenas contornei o problema. Limpe manualmente os pacotes mortos de tempos em tempos. Então, estou trabalhando em VehicleBodyAddon para meu projeto usando v1.5. Ugh, ele faz F * M para cálculo de aceleração, mas eu quero fazer F * M * 5. Deixe-me modificar rapidamente o código... Opa, lá se vão todos os meus outros projetos executando esse complemento.
• Deixe-me criar um novo addon que depende do outro addon. Hmmm agora preciso registrar que meu novo addon personalizado depende do existente. Agora preciso estender o gerenciador não apenas para baixar addons de local remoto, mas também para trabalhar com caminhos locais ou repositórios git ou algo assim.

Assumindo addons "fornecidos":

• Baixe o complemento para o diretório de complementos
• Atualizando o complemento de substituições no diretório

Assim, o gerente tem uma funcionalidade extra para rastrear dependências e quais projetos têm quais dependências. Como alternativa, ninguém adiciona essa funcionalidade para que minha máquina local fique poluída com várias versões do mesmo complemento

Isso é exatamente o que o comando gem de outro ruby ​​faz, e ninguém está reclamando lá, já que eles têm um comando para limpar versões antigas de gems (termo de ruby ​​para addons) que não têm outras gems dependendo delas. Além disso, por que precisamos manter a versão antiga quando, se estamos atualizando, a nova versão provavelmente será compatível de qualquer maneira? Empurre para empurrar, o usuário pode obter a versão antiga novamente se o programa depender absolutamente da versão antiga, o que provavelmente não será.

Decido que quero mover meu projeto para ~/big-project/game . Agora preciso de uma maneira de atualizar a referência ao meu projeto no registro do complemento.

Você não, realmente. Você está pensando muito profundamente nisso quando o gerente de complementos poderia simplesmente... usar a lista de projetos do gerente de projeto e ignorar quaisquer caminhos que não existam. Claro, isso é apenas se for absolutamente necessário acompanhar os projetos e seus requisitos, o que não vejo necessidade quando poderíamos apenas manter as versões mais recentes de quaisquer complementos que baixamos, como literalmente todos os outros complementos gerente lá fora.

A decisão agora é feita para armazenar dependências localmente no estilo requirements.txt python. Ótimo, problema resolvido. Exceto que eu voltei a não saber quais projetos dependem de quais pacotes globais, eu tenho que escanear o sistema para projetos godot ou registrar cada projeto ainda para evitar empilhar versões.

Um arquivo requirements.txt no estilo Python seria uma ótima opção para esse tipo de sistema complementar. Dessa forma, se o projeto realmente precisar de alguma versão antiga (mas, novamente, você geralmente desejará a versão mais recente de qualquer maneira), podemos especificar isso e, se o gerenciador de complementos acabar excluindo essa versão antiga, ele pode saber para baixá-lo novamente mais tarde.

Então, estou trabalhando em VehicleBodyAddon para meu projeto usando v1.5. Ugh, ele faz F * M para cálculo de aceleração, mas eu quero fazer F * M * 5. Deixe-me modificar rapidamente o código... Opa, lá se vão todos os meus outros projetos executando esse complemento.

Ou usar uma cópia do complemento local para esse projeto? Se realmente requer uma mudança que se aplica apenas a um projeto, e você realmente não quer fazer uma cópia local para o projeto, apenas faça um arquivo .gd que o estenda e faça a(s) mudança(s), e então use esse novo arquivo GD no lugar do do addon.

Deixe-me criar um novo addon que depende do outro addon. Hmmm agora preciso registrar que meu novo addon personalizado depende do existente. Agora preciso estender o gerenciador não apenas para baixar addons de local remoto, mas também para trabalhar com caminhos locais ou repositórios git ou algo assim.

Submódulos Git. Outro requirements.txt (como o que o python faz). Ou apenas diga ao usuário que ele requer o Add-on X. Não é tão difícil quanto você está fazendo parecer. A maioria dos usuários do Godot não são burros. Eles sabem o que significa "Este complemento requer: Complemento X Core, Complemento Y, Complemento Z".

@rminderhoud Se sua recomendação é armazenar uma cópia dos complementos de um projeto em cada projeto conforme necessário (para que tenha apenas a versão necessária e seja livre para modificá-la sem causar problemas), talvez minha sugestão anterior possa lidar com o núcleo problema em torno desta questão? Ou seja, crie um utilitário no EditorSettings que permita ao usuário especificar quais complementos ele deseja instalar automaticamente ao criar um novo projeto.

Poderíamos até criar um utilitário semelhante que permita que as pessoas formem links físicos para um local user:// para armazenar determinados (especialmente para complementos que adicionam recursos de editor). Se o usuário optar por fazer isso de forma irresponsável e estragar seu projeto, será sua própria decisão. O método padrão de apenas copiar todos os ativos durante a criação do projeto pode ser muito útil.

Adicionar um novo sistema de plugins não deve ser incompatível com o respeito res://addons como está agora... E isso porque:

O sistema atual é ótimo...

Eu repito:

O sistema atual é ótimo...

Nenhuma reclamação anterior sobre esse ponto.

Estou atrasado para esta discussão, aqui estão alguns pensamentos sobre a proposta:

• Eu pessoalmente não uso muitos 'ativos' ainda e sinto que a pasta addon como está é fácil de trabalhar.
• Eu entendo o que a herança de script de linguagem cruzada faria e qual problema ela resolveria (permitir que um desenvolvedor C# se estenda de um script GDScript para adicionar funcionalidade personalizada usando C#) (não que eu tenha qualquer desejo de usá-lo), mas não tenho certeza o que vários scripts por nó fariam. Ah, então, em vez do script C# se estender do script GDScript, ele seria capaz de chamá-lo? Qual roteiro seria o principal? Como o código C# mudaria o que o script GDScript faz?
• Permitir que scripts sejam referenciados por nome de classe/espaço de nomes (TypeDB) pode ser útil. Estou bem com res://paths , mas é verdade que herdar de algo em complementos cria nomes de caminho muito longos. Não é um problema importante, mas um bom de se ter - provavelmente seria necessário (ou preferido) para herança entre idiomas.

Um design mais simples para o gerenciamento de ativos que eu sugiro é

• Ter um dependencies.json (ou apenas salvar os dados nas configurações do projeto) é útil, só para saber qual versão do ativo baixei e se existe uma versão atualizada. Acho que é uma informação necessária.
• Não, não permita que os ativos possam definir dependências. Eu não acho que os ativos Godot terão uma quantidade tão alta de dependência um do outro como os módulos npm. Deixe o desenvolvedor do ativo declarar na documentação se ele realmente depende de outro ativo e deixe o usuário instalar manualmente. Isso simplificará as coisas e não teremos que criar outra coisa de validação de dependência que é o código bloat / mais código para manter.
• Não, não salve ativos em um local 'global'. Mantê-los na pasta de complementos do projeto já é bom. Isso permite que eles se comprometam com o controle do código-fonte com o projeto e os torna fáceis de gerenciar. Mesmo npm node_modules salva os módulos de um projeto dentro do projeto.
• Agora, melhore o navegador de ativos para que ele possa listar quais dos ativos instalados foram atualizados e permitir que você os atualize, se desejar.
• Agora, faz sentido poder ter complementos 'globais' para aqueles complementos que são apenas melhorias do editor. Portanto, os complementos normais ainda vão para a pasta de complementos do projeto, mas para complementos relacionados ao editor, você tem a opção de instalá-los globalmente. Isso também move esse código para fora da pasta de complementos do projeto para que ele não entre no pacote de lançamento. (Isso é semelhante ao npm install -g para ferramentas de desenvolvimento)

Então, apenas algumas melhorias para ajudar a rastrear ativos atualizados e poder ter addons de editor instalados globalmente.

Supondo que não lidamos com dependências, sinto que pode haver um problema de descoberta / facilidade de uso para os usuários. Digamos que um novo usuário queira experimentar um plugin ou "pacote de ativos" que tenha uma dependência. O pacote é mostrado na biblioteca de ativos, baixando-o, depois não funciona, provavelmente com algum "script interno falhou ao carregar" ou algo parecido. Isso é enigmático.

• Ou cada desenvolvedor que se atreve a ter pelo menos uma dependência terá que configurar o código clichê para mostrar ao usuário que ele precisa instalar uma dependência (mesmo que o pacote seja apenas uma demonstração para esse plugin!)
• Ou o assetlib pelo menos indica isso?

Também +1 para fácil atualização de ativos, sem necessidade de pesquisá-los novamente na biblioteca.

É verdade, no entanto, uma vez que o usuário veja que não funciona, ele imediatamente procurará a documentação e verá que precisa instalar o(s) outro(s) ativo(s).

Neste ponto, é apenas um problema imaginado. E na mentalidade dos mantenedores do projeto que tenho visto, faz sentido não implementá-lo até descobrirmos que é realmente um problema. Ou seja. existem muitos ativos que dependem de outros ativos e os usuários estão tendo muitos problemas com isso.

No entanto, como uma solução bem projetada, concordo que seria bom ter e pode incentivar o desenvolvimento de um ecossistema de ativos construído sobre/dependendo de outros ativos.

Adicione as principais dependências entre ativos devido a atualizações (o que é comum em mecanismos dependentes de ativos de terceiros), muitas versões do mesmo plug-in devem ser mantidas na biblioteca.

@eon-s Então, algo como a sugestão de @bojidar-bg?

Acho que a questão mais importante discutida aqui é sobre o tópico de incluir coisas no mecanismo principal versus tê-las como extensões ou extensões oficiais.

Pessoalmente, gosto muito da ideia de poder personalizar o motor e remover tudo o que não estou a usar. [Alguém pode me indicar como eu removeria todas as coisas 3D, por exemplo? E posso simplesmente desabilitar a compilação de módulos que não uso? Quão?]

A coisa é, quando alguém propõe um novo tipo de nó, por exemplo. o Spring Arm mencionado ou nova classe, por exemplo. uma classe RNG melhor, ou se alguns nós centrais existentes devem ser removidos, por exemplo. o controlador Vehicle ... esses são códigos C++. Se eles não estiverem incluídos no núcleo, como eles serão adicionados como extensões? Recursos GDNativos? Isso seria um monte de dlls e bibliotecas compartilhadas para gerenciar/construir.

Como alguém que constrói minha própria compilação godot, eu preferiria ter uma maneira de instalá-los na minha pasta de compilação godot. Por exemplo, se eles fossem módulos, eu apenas os clonaria na minha pasta de módulos, ou talvez houvesse uma ferramenta que automatize isso de alguma forma. Você seria capaz de selecionar todos os módulos que deseja usar da lista de módulos oficiais, módulos de extensão oficiais e também dos enviados pelo usuário. Em seguida, baixe-os (git clone) e, em seguida, você pode seguir em frente e criar seu Godot personalizado. Também seria capaz de ver quais foram atualizados e atualizá-los e instalar novos posteriormente. (Isso está se referindo ao código C++.)

Então, acho que primeiro precisamos de uma biblioteca de ativos melhor e flexível (instalação de ativos, dependências, versionamento, etc.) .

Respondendo a @chanon aqui.

Não, não permita que os ativos possam definir dependências. Eu não acho que os ativos Godot terão uma quantidade tão alta de dependência um do outro como os módulos npm.

Mas por que embora? Nesse ponto, por que não deixar que os ativos tenham esse arquivo de dependências de qualquer maneira, já que não prejudicará nada? A razão pela qual muitos módulos npm têm dependências é porque isso poupa a todos os problemas e reutiliza o código de outros módulos que o usuário pode até já ter instalado. O mesmo vale para gems Ruby, Python via pip , até mesmo gerenciadores de pacotes em distribuições Linux permitem. Não vejo por que não devemos permitir dependências de ativos apenas porque eles podem não ser usados ​​com tanta frequência.

É verdade, no entanto, uma vez que o usuário veja que não funciona, ele imediatamente procurará a documentação e verá que precisa instalar o(s) outro(s) ativo(s).

Não concordo com o sentimento disso. Haverá muitas pessoas que procurarão a documentação primeiro, com certeza, mas tenho certeza que até eles ficarão irritados por ter que pesquisar cada recurso necessário todas as vezes na biblioteca de recursos. Mas acho que também vale a pena mencionar que sempre há aquele pedaço de pessoas que nunca parecem pesquisar problemas no Google de antemão e apenas reclamam com o(s) autor(es) do recurso que seu recurso não está funcionando.

Eu nem concordo com a ideia de remover recursos simplesmente porque eles podem ser feitos em GDScript. Simplificando, é antitético ao objetivo de Godot de " nós para todas as suas necessidades " se você for forçar uma grande quantidade de usuários a baixar ou implementar uma ferramenta/recurso/etc que eles precisam.

Na verdade, uma enorme faixa de nós se enquadra no segundo requisito do @reduz para ser incluído no mecanismo, simplesmente porque "é difícil fazer você mesmo" é completamente arbitrário. O que pode ser simples para alguns é difícil para outros.

Não acho que ter um repositório oficial para extensões vá contra os "nós para todas as suas necessidades". Só porque eles não estão integrados no download executável, isso não significa que eles não estão sendo fornecidos. Além disso, a ideia é que as necessidades básicas sejam cobertas e o poder de estendê-las esteja disponível para as necessidades específicas do jogo.

É bom ter um controlador de personagem FPS pronto para uso, mas é inútil para todos que não estão fazendo um jogo FPS. E adicionando coisas assim, você faz essencialmente todos os jogos contendo muitos recursos que eles não precisam, aumentando o binário final (o que importa muito em alvos móveis e da web). Deve haver uma maneira de remover coisas não utilizadas da exportação final, e fornecê-las externamente conforme a necessidade é uma maneira (pelo menos parcialmente).

Concordo que a dificuldade é subjetiva. Fazer um nó de braço de mola é fácil apenas se você já conhece os fundamentos para implementá-lo. Caso contrário, você gastará bastante tempo pesquisando, o que anula o propósito de usar um mecanismo completo. A melhor métrica (embora ainda um pouco subjetiva) é "quanto de baixo nível" é o recurso. Se precisar adicionar funções aos servidores físicos ou visuais, provavelmente deve ser fornecido no mecanismo. Se for apenas uma extensão de um nó existente, talvez possa ser terceirizado.

Ainda acredito que é mais benéfico fornecer nós oficiais para download e aparar o núcleo. Com isso, podemos:

• Tenha um pequeno executável para editor e exportações.
• Forneça mais funcionalidades oficialmente, com mais ajudantes específicos do jogo.
• Atualize e corrija bugs nas extensões sem liberar uma nova versão do mecanismo. Isso significa que os nós terceirizados podem ter um ciclo de lançamento muito mais rápido e lançar um patch assim que um bug for corrigido.

Mas para isso ainda precisamos tornar os addons cidadãos de classe mais alta do que os scripts user-land. O uso de nós de extensão deve ser parecido com o uso dos nós principais, embora ainda esteja claro que eles não são.

Discussão interessante. Muitas boas propostas também.

Devo dizer primeiro que aprecio a compacidade do binário final e sou grato por haver um mecanismo feito com esse objetivo em mente. Fico feliz que a visão central aqui seja combater ativamente o inchaço. Pelo menos para mim, prefiro ter apenas as ferramentas de que preciso para o trabalho à mão.

Só queria passar um aceno para algumas dessas ideias interessantes.

Especialmente aquele relacionado a que mais e mais funcionalidades são exportadas para algo que assume a forma de algo como módulos ou plugins oficiais.

A partir disso, imagino que seja como um núcleo e depois uma biblioteca de módulos, com os essenciais instalados por padrão. Talvez muitos possam ser excluídos através das configurações do editor. (Acredito que Zylann mencionou a exclusão de 3D para um jogo 2D.) Além dos padrões, os outros módulos podem ser facilmente localizados e incluídos.

Embora eu me pergunte sobre as dificuldades de implementação, porque você teria que considerar o que acontece quando alguém pode querer remover um módulo que está ativamente no projeto. Pode ser necessário avisar o usuário para removê-lo dessas cenas / scripts antes que ele possa ser desativado ... ou eles permaneceriam como itens marcados para exclusão no projeto, que podem reviver quando o módulo for adicionado novamente?

Provavelmente não é pouca coisa para implementar, mas gosto de poder escolher a funcionalidade fornecida, sempre que possível, permitindo a exportação do jogo tendo apenas o necessário. Mais controle sobre isso parece valioso para mim.

Os outros pensamentos de Vnen sobre ter módulos com alguma classificação especial entre built-in e os scripts também foram bons. Isso permitiria alguns outros tipos de particionamento e comportamentos e opções do editor sem interferir nas coisas boas do design existente.

Alguns disseram sim e outros não nessa ideia de fazer os addons parecerem mais com o próprio Godot, mas pode imaginar que talvez seja situacional. Eu também poderia imaginar isso sendo feito dividindo um pouco o conceito. Fornecendo ambos.

Eu também estaria interessado em ver o que poderia ser feito em relação a manter as ferramentas do editor fora da compilação final. Eu trabalhei muito tentando manter essas coisas separadas, porque bugs e comportamentos destinados a ferramentas podem se infiltrar no próprio jogo. Às vezes de forma destrutiva se você estiver fazendo algo com a modificação de dados que serão salvos.

Ao mesmo tempo, acho fantástico modificar facilmente a funcionalidade dentro do editor usando o script da ferramenta, portanto, mais atenção também seria fantástico.

De qualquer forma, continuem o bom trabalho a todos.

Só mais uma ideia maluca:

Talvez seja possível de alguma forma converter automaticamente o GDNative C++ em um módulo (de preferência removendo as camadas de indireção criadas pelo GDNative)? Então pode agradar tanto os defensores da abordagem "tudo em um executável estático" quanto os da abordagem "retirar recursos sem instalar o compilador"

Para aqueles contra a remoção dos nós, se os nós removidos forem implementados no GDScript como plugins oficiais, não seria melhor do que o que temos atualmente? Porque então os iniciantes podem realmente entrar no script para ver como ele funciona.

Temo que isso prejudique o desempenho, pois o GDScript não é muito rápido.

Em sex, 22 de junho de 2018 às 23h10, Alan North [email protected]
escrevi:

Para aqueles contra a remoção dos nós, se os nós removidos forem
implementado em GDScript como plugins oficiais, não seria melhor do que
o que temos atualmente? Porque então os iniciantes podem realmente atingir o pico dentro
o script para ver como funciona.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-399628884 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AEJES-DWkzuyItQDPbOZgsuN_lA345z7ks5t_b_NgaJpZM4UhqDC
.

@AlansCodeLog Se eles absolutamente devem ser removidos e transformados em extensões externas, seria bom ter pelo menos uma versão GDScript, para que os usuários não precisem recompilar o mecanismo (se forem os arquivos C++ originais) ou instalar o Mono ( se for convertido para GDNative). No entanto, parte da minha resposta original (veja a seção em um repositório oficial de extensões) envolveu minha preocupação de que trazê-los para extensões apenas criaria esse tipo estranho de mercado (por falta de uma palavra melhor) se os usuários parassem de lembrar que há um repositório de extensões que contém o que eles precisam, independentemente de quão oficial ou quão atualizada seja a versão oficial. Novos complementos entrariam na biblioteca de ativos que teriam "Nó X com Recurso X", "Nó X com Recurso Y" e assim por diante ("Nó X" representando o nó que foi transformado em uma extensão) - criando uma bagunça de addons que afirmam ajudar com veículos, mas não têm esse nível ou escrutínio que mais nós oficiais podem obter.

@LikeLakers2

Mas por que embora? Nesse ponto, por que não deixar que os ativos tenham esse arquivo de dependências de qualquer maneira, já que não prejudicará nada?

Eu não sou contra. Mas como reduzir parece não gostar, sugiro fazer uma melhoria simples como sugeri primeiro. Veja como vai, então pode adicionar capacidade para ativos com dependências mais tarde. Apenas uma sugestão de um passo de cada vez.

No entanto, sou contra a ideia de instalar complementos do projeto em um local fora da pasta do projeto, pois dificulta o gerenciamento. Apenas os complementos do editor 'global' devem estar fora da pasta do projeto.

Depois de pensar um pouco mais, na verdade, se os recursos principais forem removidos e as pessoas quiserem ter acesso a esses recursos principais [que seriam extensões] em todos os seus projetos, faz sentido poder ter essas extensões instaladas em um local global com gerenciamento de versão para eles. Mas a opção de baixar e instalar a extensão diretamente na pasta do projeto também deve permanecer nesse caso. (Novamente, é como a opção npm instalar localmente ou globalmente com -g)

Como os eons disseram acima, faz sentido ter um sistema de gerenciamento de ativos melhor se as coisas forem removidas do mecanismo principal e transformadas em ativos. Caso contrário, isso resultaria na perda de funcionalidade do mecanismo, pois os usuários não seriam capazes de descobrir a funcionalidade removida facilmente.

Eu estava pensando naquele cenário ideal para

• Novos usuários e pessoas que não compilam o mecanismo: na página de download do mecanismo, eles têm a opção de baixar o mecanismo principal e também selecionar quais extensões oficiais ou recomendadas desejam incluir no download do mecanismo. ( Observe que isso não seria possível se as extensões não pudessem ser salvas em uma pasta global. Os usuários teriam que encontrar extensões depois de criarem um projeto, o que prejudica a descoberta. ... Em um mundo [impossível] ideal, porém, o site seria construa uma compilação C++ personalizada a partir de extensões/componentes selecionados no local.)
• Pessoas que compilam o mecanismo: uma ferramenta que gerencia downloads e versões de código C++ de extensão e os coloca no local correto na pasta de compilação para que sejam incluídos nas compilações do mecanismo.

Como alguém que compila o mecanismo, gostaria de minhas extensões como módulos em vez de GDNative (ou GDScript mais lento). Estou imaginando o nível de modularidade que posso escolher tipos de Node específicos para incluir ou não na minha compilação, ou até mesmo descartar todas as coisas 3D.

Se todas as extensões C++ forem GDNative, isso sobrecarrega o criador da extensão de ter que criar para todas as plataformas - o que acho que pode desencorajar as pessoas de configurá-lo para pequenas extensões simples que podem ser úteis, pois seria um exagero faça tudo o que for necessário para publicá-lo - e também desencoraja a separação da funcionalidade em muitos módulos pequenos. Eu também não gosto do fato de que serão tantos arquivos de biblioteca dll/compartilhada adicionados ao projeto de saída.

Por outro lado, para pessoas que não compilam o mecanismo, GDNative é a única solução para adicionar extensões C++.

Então, como o starry-abyss sugeriu, se o GDNative pudesse ser adaptado automaticamente em um módulo normal, isso seria ótimo.

Ok, então mudei minha posição. Gosto da ideia de um mecanismo sem inchaço com recursos na mesma liga que as potências da indústria.

Ter todos os nós extras separados permitirá muitas vantagens, especialmente a capacidade de escolher o que você deseja e o que não deseja.

Aqui estão algumas das minhas sugestões de como abordá-lo,

1. Primeiro, podemos adicionar a capacidade da biblioteca de ativos de ter ativos que podem ser instalados em partes, no git eles podem ser separados por tags ou ramificações.
   Então, agora, se eu quisesse apenas os nós de recursos 2D, eu poderia baixar apenas isso, mas ainda teria apenas um lugar para verificar se há atualizações.
2. Em segundo lugar, podemos adicionar a capacidade de adicionar rótulos a atualizações de ativos, como alguns podem ser atualizações principais de alguns recursos e algumas quebras de compatibilidade com versões anteriores.
   Isso pode ser usado pelo Asset Manager automaticamente para atualizar os complementos e pedir para atualizá-lo sobre o assunto. Como se ele dissesse que você chegou às atualizações principais esperando, ou sua próxima atualização vai quebrar a compatibilidade com versões anteriores. Você quer atualizar ou não.
3. Terceiro, para permitir várias versões de um ativo e, quando uma versão fica muito antiga, o desenvolvedor do complemento / ativo pode marcá-lo como desatualizado, o que será refletido quando você abrir o Godot e solicitará que você remova a versão mais antiga ou não .
4. E por último, uma capacidade para os complementos solicitarem outros complementos, será como dependência, mas apenas informará que você precisa desse complemento para executar este complemento e, se não o tiver, instale-o.
   E se alguma vez o próprio addon perceber que o addon não pode mais ser encontrado, peça para adicioná-lo novamente ou apenas mostre uma mensagem de erro.

Usando este método não precisaremos de gerenciador de dependências, mas os devs seriam responsáveis ​​pelo trabalho. Se um addon ficar velho e estiver usando um ativo/addon desatualizado, ambos os desenvolvedores podem conversar e o desenvolvedor pode decidir o que fazer.
Ele pode simplesmente portar seu addon rapidamente. Se necessário ou em alguns casos o outro addon pode ter a tag desatualizada removida mesmo.

E como @chanon disse, precisaremos fazer com que os ativos sejam baixados como globais, que podem ser importados para o projeto como o Unity fez.
E um gerenciador de ativos melhor do que nossa implementação atual com muita flexibilidade na instalação do processo de complemento deve ser permitido.
Eu recomendo ter a capacidade de adicionar um complemento como GDNative e Módulo, o que colocará alguma carga nos desenvolvedores de complementos, mas acho que essa é a única solução aceitável, a menos que algo mude radicalmente aqui.
Mas ainda podemos adicionar alguns recursos ao GDNative para facilitar a criação do complemento. Como ser capaz de construir para todas as plataformas de uma só vez seria muito melhor.

Sobre a questão de dependências e quebra de ativos devido à atualização de plugins,
por que não (e desculpas se eu perdi alguém já sugerindo isso)

1. faça com que o servidor mantenha todas as versões carregadas

2. permitir que plugins especifiquem uma versão específica de um plugin específico

3. tente usar um sistema de versionamento sensato para plugins (Godot parece usar o
   Numeração de versão Major.Feature.BugFix, que eu gosto)

4. E o mais importante, não atualiza automaticamente os plugins? (Ou pelo menos permitir que o
   usuário para selecionar com que tipo de atualizações eles concordam, por exemplo, correções de bugs e
   atualizações de recursos, mas sem atualizações importantes).

@Two-Tone Então, por que fazer a coisa toda ficar livre?

Temos essa discussão para tornar o mecanismo e todo o sistema o mais livre possível de inchaços e não ter versões desnecessárias voando por aí.

Você está certo sobre permitir que os usuários decidam atualizar, mas as correções de bugs devem ser automáticas por padrão. Porque se eu tiver centenas de addons, não vou verificá-los um por um para atualizações de correção de bugs.
Resto pode ser até o usuário podemos ter uma configuração para desabilitar se for necessário.

E a loja deve oferecer pacotes oficiais para uso offline (com suporte de loja offline no editor).

Eu sugeriria um pacote offline de alguns 10s de MBs contendo as demos mais importantes e os complementos mais importantes que devem ser facilmente descobertos. Um link de fonte menor na página oficial de download, como o das versões antigas do godot, seria ótimo.

Provavelmente sim, mas em um mundo onde os desktops não parecem usar nada menos que 256BG SSD + 1TB HDD e até mesmo os telefones têm espaço a partir de um mínimo de 16GB, o que é mais do que provável que aumente, seria isso MAU?

No segmento de laptops portáteis e acessíveis, o eMMC está vivo e bem e o tamanho de 32 GB (com menos de 10 GB livres) não é tão incomum.

A propósito, nessa classe de laptops, acho que o atual sistema de exportação do Android é utilizável, enquanto o planejado (https://github.com/godotengine/godot/issues/18865) não é. Eu entendo os méritos do novo sistema e, no final das contas, eu provavelmente teria votado nele (quando vi o problema, já não havia contestação), mas devemos estar cientes de que estamos perdendo um caso de uso importante com a mudança.

@swarnimarun Pode haver um mal-entendido. Quando digo "sistema" nesse comentário, quero dizer o servidor que serve os plugins, não o mecanismo. Desculpe se foi isso que te fez tropeçar.

Se não, então não vejo como tentar resolver os problemas das pessoas com um sistema de dependência para plugins é antitético para tentar manter o motor inchado. Um plugin mantido em um servidor apenas no caso de alguém precisar dele não contribui para o inchaço ou a sobrecarga de manutenção e a maioria é tão pequena que o custo para armazená-los não deve ser tão alto.

@Two-Tone Sim, pensei que você queria dizer no computador. Mas no servidor está tudo bem e já pode ser feito, pois o Github permite hashs que podem ser salvos mesmo após as alterações serem feitas, portanto, no sistema atual, mesmo após atualizar o repositório, você deve atualizar o hash na página de ativos.

Não apenas o github até o gitlab e outros também permitem. Se houver outros. O Git suporta que hashes sejam salvos como ID de confirmação e, portanto, as coisas são feitas do jeito que são feitas.

Apenas meus poucos centavos, tenho certeza que a maior parte disso já foi dito antes, então duvido que esteja trazendo algo novo.

Eu não acredito em fazer coisas como plugins por fazer coisas como plugins. Eu entendo a questão do tamanho, mas não estamos mais nos anos 80. Estamos falando sobre a engine ser 50Mb ou 55Mb, não entre a engine sendo 50Mb ou 500Mb, o aumento extra de tamanho do recurso a ser movido para um plugin é insignificante comparado ao tamanho dos ativos de qualquer jogo sério. Se o preço que pagamos é uma integração mais problemática, não vale a pena.

Há muitos lugares onde os plugins fazem mais sentido e com a arquitetura como GDNative amadurecendo, definitivamente devemos fazer a pergunta "é melhor ser um plugin" e em muitos casos eu diria que a resposta é sim. Uma coisa que eu gosto nos plugins é que eles permitem que você, como desenvolvedor, tenha mais liberdade em muitos aspectos. Mas também há limites.

Minha experiência em RV escapa a alguns deles. Há uma razão pela qual está demorando mais do que eu gostaria de colocar isso em funcionamento no celular. Por causa das demandas, especialmente em dispositivos móveis, de configurar os monitores de várias maneiras, você precisa alterar a maneira como o núcleo funciona e é difícil capturá-lo em um plug-in.
OpenVR e OpenHMD até agora têm sido os mais fáceis. Oculus Eu passei por uma solução que é desprezada, mas estou feliz com isso.
O ARKit tem que estar no núcleo, não pode ser resolvido como um módulo, pelo menos não em nossa estrutura atual (a Apple nem permite bibliotecas dinâmicas no iOS, então também existe).
GearVR e Daydream realmente precisam estar no núcleo, uma impossibilidade para GearVR devido ao uso de bibliotecas proprietárias.
Hololens/Microsoft MR Estou seguindo o caminho de ver se posso fazer disso uma escolha de plataforma, a Microsoft os vê dessa maneira porque os aplicativos devem ser executados entre os dois e são instalados no Hololens como um aplicativo apenas holográfico.

Agora AR e VR são funcionalidades de nicho que poucas pessoas usarão, então são o tipo de coisas que devem ficar fora do núcleo, se possível, e estou de acordo com esse ponto de vista. Mas não posso dizer o mesmo para outras coisas.

Eu vi o corpo do veículo mencionado em algum lugar, sério? O kilobyte de código que você salva colocando isso em um plugin? Física são os tipos de coisas que eu acho que devem ser totalmente suportadas no núcleo IMHO. Prefiro ver um conjunto completo de objetos físicos totalmente integrados dentro do núcleo do que ter que caçar aqueles em plugins. Embora uma abordagem de interface semelhante à ARVRInterface que escrevemos no GDNative provavelmente criaria uma integração sólida, ainda sinto que estamos apenas dificultando a vida desnecessariamente.

Compare isso com os componentes do editor de terreno, agora há algo que eu vejo como ideal para ser baseado em plugins. Existem várias maneiras diferentes de abordar os terrenos, dependendo do tipo de jogo que você deseja fazer, portanto, ter uma escolha entre diferentes complementos faz sentido, e ser capaz de desenvolver neles independentemente do desenvolvimento no núcleo é ainda mais uma razão.

Para encurtar a história, onde os plugins fazem sentido, suporte plugins, mas não exagere.

Os nós que podem valer a pena transformar em plugins são os nós de controle que são feitos por nós de controle (os compostos), deixando apenas nós simples para construir outros.

Nós com lógica complexa como Veículo ou mesmo simples, mas úteis como os de Posição, são bons no núcleo.

IMO, nenhum deles deve ser removido do motor. Nós de controle, nós de física (como Veículo) e até mesmo suporte a Terreno atualmente não existente:

Eu uso Godot porque é um aplicativo integrado bastante independente.
Se no futuro eu precisar baixar o Godot e procurar por Veículo, nós de controle, suporte ao terreno, um editor Shader, um plugin Navmesh decente e assim por diante - usando o plug-in atual e o sistema AssetLib - não, obrigado.

Se seguirmos esse caminho, tanto a infraestrutura do plugin quanto a AssetLib precisam de uma revisão de usabilidade.

E, a propósito, estou muito menos incomodado com o grande tamanho de instalação do UE4 do que ficaria por não vir com suporte embutido para Veículos, Terreno ou UI - o que ele tem, tudo isso.

Não tenho certeza de quanto disso já foi declarado, grandes tópicos como este podem ser difíceis de seguir, mas de qualquer maneira:

Acho que devemos nos concentrar na melhor experiência fora da caixa . Ter que entrar na biblioteca de ativos, mesmo para plugins "oficialmente endossados", é bastante complicado.

O tamanho da exportação não deve piorar a usabilidade do mecanismo, IMO. Se precisarmos reduzir o tamanho da exportação, crie algum recurso para desativar seções do mecanismo, como 3D na exportação. Especialmente porque eu pessoalmente não valorizo ​​plataformas como mobile e principalmente web, e me dói ver o motor retido por eles em discussões como essa. (Eu posso ver a demanda por eles, não me interpretem mal, embora foda-se a web)

Inferno, se estamos preocupados com o tamanho do download do editor , deve haver "baterias incluídas" separadas e downloads "mínimo" do editor. Como a separação é implementada está em debate, mas deve ser bem integrada, não importa o quê.

Não li toda a discussão completamente, mas gostaria de reajustá-la um pouco: não estamos preocupados com o tamanho. Claro, manter o tamanho da exportação pequeno em algumas plataformas é importante, mas não é um fator decisivo ao implementar recursos no mecanismo. Como mencionado, se alguns recursos precisam ser condicionais para permitir pequenos tamanhos de exportação, é trivial. O tamanho do download para o mecanismo em si não importa.

Agora que está resolvido, os principais fatores que nos incentivam a considerar manter algumas coisas ("algumas" a serem determinadas) fora do mecanismo são:

• Dívida técnica. Todo o código precisa ser mantido. Um VehicleBody quebrado como o que temos desde 2014 não é particularmente útil, pois não é bom o suficiente para jogos reais. Recentemente, ele foi aprimorado usando o Bullet, então está melhorando, mas nos últimos 4 anos era efetivamente código morto e carga de manutenção desnecessária.
• Universalidade: Godot é uma engine que permite que você faça qualquer tipo de jogo, e os recursos que ele oferece devem permitir que você faça qualquer tipo de jogo. Isso não significa que deva ser exclusivo (você não precisa de 2D e 3D ao mesmo tempo na maioria dos jogos), mas os recursos devem atender às necessidades comuns da maioria dos usuários. O que significa que os recursos que fornecemos devem ser de baixo nível e que os recursos de alto nível específicos do jogo são na maioria das vezes melhor fornecidos externamente.
• Flexibilidade: Ter recursos de alto nível mantidos fora do núcleo permite um processo de iteração muito mais rápido para melhorá-los, bifurcá-los, se necessário, etc.

Se seguirmos esse caminho, tanto a infraestrutura do plugin quanto a AssetLib precisam de uma revisão de usabilidade.

Bem, essa é a razão de ser desta questão, não? :) O ponto principal é que precisamos de uma revisão de usabilidade para permitir um fluxo de trabalho melhor em vez de agrupar todos os casos de canto no mecanismo principal.

Bem... se alguém precisar de idéias para iniciar os recursos externos, além do chamado VehicleBody, quero lembrar alguns nós e classes perdidas do godot 2 a 3: ParticlesAttractor2D (node) e EventStreamChibi (esta classe é perfeita para um ativo externo ), sei que o atrator de partículas é incompatível com o sistema de partículas atual, mas... Que tal recuperar a funcionalidade perdida do godot em forma de ativo externo (Ej, sistema de partículas antigo coexistindo com o novo....). Talvez alguém queira manter esse código em repositórios separados...

Os novos sistemas @Ranoller sempre removem coisas antigas, é inevitável.
As partículas da CPU devem voltar com o GLES2 (porque não suporta as da CPU), mas ter atrativos na CPU, mas não na GPU, não será bom.
EventStreamChibi era um módulo, acho que o novo sistema de áudio pode dar melhor suporte para arquivos rastreadores se ficar mais flexível.

Eu não acho que, mesmo que nos preocupemos com a manutenção, devemos separar as coisas ainda.
Podemos pedir às pessoas que ajudem em coisas que envelhecem postando sobre isso em um tópico especial e, em seguida, as pessoas podem atualizar os recursos.
Com o tremendo crescimento na base de usuários Godot, estou certo de que encontraremos muitos caras dispostos a atualizar as coisas e trabalhar em coisas ficando velhas ou faltando recursos essenciais em partes do mecanismo, por exemplo, mais juntas.

Se você acha que é mais fácil fazer as pessoas trabalharem em arquivos de código separados, então está errado, a maioria simplesmente não saberá sobre esses arquivos, pois nunca terá a mesma exposição, o gerenciador de ativos precisa trabalhar sim, mas ter recursos como plugins não funciona bem .
Eu vi algumas pessoas mudarem do Unity para o Godot porque ele é tão bem integrado e não oferece recursos essenciais como plugins.
E a Unity percebeu que começou a trabalhar para tornar as coisas mais integradas e adicionou os desenvolvedores de complementos à equipe de desenvolvimento da Unity.

Se precisarmos baixar um mecanismo de 30 MB e perder tempo baixando recursos separados como plug-ins que eu possa esquecer de adicionar ao meu projeto, talvez não os use em primeiro lugar. O que é um problema para um iniciante.

Em relação à dívida técnica, esta é uma questão com a qual todo projeto (FOSS ou comercial) eventualmente tem que lidar. A verdade é que alguns desenvolvedores acabam saindo e uma área deixa de receber muita atenção (por isso tem que ser colocada em modo "manutenção" até que alguém se interesse). Como mencionei, isso acontece até com grandes aplicativos comerciais. então inevitavelmente acontecerá com Godot, não importa o quanto o motor seja ajustado.

A melhor solução nessa área é simplesmente promover uma cena de desenvolvimento que encoraje as pessoas a começarem a contribuir para a fonte (e a cena Godot tem feito um bom trabalho ao olhar para todo o desenvolvimento voluntário, mas tem que ser mantido coisas como garantir que um contribuidor de patch não espere muito para ver uma revisão). No entanto, a remoção de recursos porque o desenvolvedor saiu deve ser evitada se possível (porque uma lista de recursos constantemente flutuante seria uma ótima maneira de convencer as pessoas a não usarem Godot). Em vez disso, a remoção de recursos deve ocorrer principalmente porque está sendo substituída por algo melhor.

No entanto, a remoção de recursos porque o desenvolvedor saiu deve ser evitada se possível (porque uma lista de recursos constantemente flutuante seria uma ótima maneira de convencer as pessoas a não usar Godot). Em vez disso, a remoção de recursos deve ocorrer principalmente porque está sendo substituída por algo melhor.

Mais uma vez, a discussão está indo na direção errada, então tentarei conduzi-la de volta ao caminho certo. O tópico não é tanto sobre remover coisas, é sobre prevenir a adição de coisas novas que podemos acabar querendo remover. Porque adicionar coisas é muito fácil, mas não podemos removê-las sem quebrar a compatibilidade.

À medida que Godot cresce, mais e mais novos contribuidores vêm com adições que podem não se encaixar na arquitetura ou design que queremos que o mecanismo siga. Revisar todas essas mudanças leva muito tempo e, mais ainda, decidir se elas se encaixam no que queremos. A fusão desses novos recursos por novos contribuidores resultará em um código que os mantenedores do mecanismo não conhecem bem ou podem não aprovar totalmente, e os contribuidores originais muitas vezes podem não ficar por perto para refatorá-lo e garantir que corresponda ao que queremos (consulte por exemplo, o nó Tween, que é um ótimo recurso, mas com design abaixo da média, e o autor original não está mais por perto, então cabe a nós repensar e reescrevê-lo, quebrando a compatibilidade no caminho).

Portanto, o ponto principal da proposta da @reduz é que o número cada vez maior de recursos que os novos contribuidores desejarão colocar no mecanismo principal seriam, na maioria das vezes, mais adequados como ativos na biblioteca de ativos. O objetivo deste problema aqui é como garantir que esse fluxo de trabalho seja o mais suave possível.

Não estamos tentando encolher a base de código de Godot, estamos pensando em como nos proteger de explodir e ficar fora de controle. (Porque contribuidores ocasionais com um grande PR são muito mais frequentes do que mantenedores de mecanismos com uma compreensão completa da base de código completa e da visão que temos para o futuro do mecanismo).

Portanto, o ponto principal da proposta da @reduz é que o número cada vez maior de recursos que os novos contribuidores desejarão colocar no mecanismo principal seriam, na maioria das vezes, mais adequados como ativos na biblioteca de ativos. O objetivo deste problema aqui é como garantir que esse fluxo de trabalho seja o mais suave possível.

Eu tenho que perguntar, o que fará isso em ativos na biblioteca de ativos, exceto mover o problema para trás um passo? Você está indo de código empacotado com Godot que não está mais sendo mantido, para código em um ativo Godot que não está mais sendo mantido. De qualquer forma, o contribuidor original provavelmente deixará de mantê-lo em algum momento e eventualmente será quebrado novamente.

@LikeLakers2 Bem, o objetivo disso é criar um caminho suave para que novas contribuições sejam adicionadas ao mecanismo (já que a maioria dos mais relacionados a ativos é rejeitada por enquanto). Se algum aspecto do mecanismo não estiver sendo mantido, ele não deve ser empacotado com o mecanismo em primeiro lugar como seu puro inchaço nesse ponto. Coisas dessa natureza são especialmente adequadas como plugins incluídos/atualizados externamente.

Se no futuro eu precisar baixar o Godot e procurar por Veículo, nós de controle, suporte ao terreno, um editor Shader, um plugin Navmesh decente e assim por diante - usando o plug-in atual e o sistema AssetLib - não, obrigado.

Exatamente. O AssetLib/add-ons em geral não funciona bem agora para isso, por isso a conversa tende a se desviar para eles. Eu não acho que ninguém quer tirar coisas agora, mas como foi mencionado o ponto é não adicionar muitas coisas novas.

Eu tenho que perguntar, o que fará isso em ativos na biblioteca de ativos, exceto mover o problema para trás um passo? Você está indo de código empacotado com Godot que não está mais sendo mantido, para código em um ativo Godot que não está mais sendo mantido. De qualquer forma, o contribuidor original provavelmente deixará de mantê-lo em algum momento e eventualmente será quebrado novamente.

Bem, suponho que seria mais fácil se eles pudessem ser gerenciados mais separados do mecanismo. O Blender faz algo assim. Eles têm complementos "oficiais" (não realmente oficiais, apenas pré-incluídos), mas seu código é mantido em um submódulo git separado e quando eles não são mantidos pelas pessoas que os enviaram (acho que você precisa reenviar a cada grande lançamento), eles são descartados. Embora eu honestamente não goste dessa abordagem, eu gostaria que eles tivessem um navegador de ativos embutido para 90% das coisas e apenas integrassem o resto (coisas como exportadores).

Eu acho que a ideia é que o motor teria apenas os blocos básicos de construção incluídos, então coisas como o nó do veículo poderiam ser complementos oficiais, então tudo o que é grande e poderia ser implementado de maneiras diferentes deve ser apenas complementos regulares , certo?

O que eu não entendo é como os complementos oficiais seriam implementados. Eu pensei que atualmente não poderíamos escrever nós personalizados que parecem ter sido construídos, certo, eles tinham que ter um script? Ou isso é possível com um módulo c++ ou algo assim (sou noob c++ aqui).

E também, eventualmente, entramos no problema de como ter um complemento que depende dos nós oficiais separados. Sem algum tipo de sistema de dependência, parece um inferno.

Tarde para a festa, mas dada a escala do meu projeto atual, eu me encontrei desenvolvendo _muitos plugins para Godot 3 e me vejo desenvolvendo muitos mais antes do projeto terminar. Com cada plugin, eu tento desenvolver o máximo que posso de uma maneira agnóstica de jogo e abri-los sob a licença do MIT para que outros possam usar. Eu não vou mentir. O sistema de complementos atual realmente não é tão ruim no grande esquema das coisas... NO ENTANTO , há algumas peças faltando que o tornam quase inútil em muitos casos. Antes de chegar a isso, no entanto, quero dizer algumas coisas sobre as ideias de @karroffel .

Em primeiro lugar, obrigado por colocar este problema juntos. Eu acho que ter essa discussão é importante - especialmente no curto prazo. Dito isso, acho que cada um dos pontos de discussão que você apresentou no OP são principalmente ortogonais, com apenas sobreposição tangencial. Acho que podemos muito iterar em uma solução aqui sem ter que resolver todas as preocupações de uma só vez.

Isso me leva às minhas dúvidas _pessoais_ com o sistema de complementos atual e o que acho que seriam dois pontos de partida muito bons para um mundo melhor de alguém que realmente desenvolve plugins regularmente:

O maior problema com o sistema de complementos atual é a falta de gerenciamento de dependências.

Isso já foi muito discutido, mas a maioria das sugestões são bastante pesadas e não são extremamente compatíveis com o sistema atual. Agora, ainda não me familiarizei com a base de código do módulo assetlib, mas acho que _deveria_ haver uma vitória fácil neste departamento. Atualmente, os repositórios de complementos de 3ª parte no Github seguem a seguinte estrutura de pastas:

addons/
    addon_name/
        plugin.cfg
        ...other files

O que proponho é estender o esquema plugin.cfg e adicionar a capacidade de simplesmente ter uma lista de versões de dependência com um hash de confirmação de opção (ou nome da ramificação/tag) para usar. Algo como o seguinte funcionaria:

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

Então, quando a biblioteca de ativos vai instalar o ativo, ela primeiro baixa o projeto no diretório de complementos como faz atualmente, depois baixa cada dependência (usando o hash ou branch correto definido) e o coloca no diretório de complementos também . Como primeiro passo, os conflitos de dependência podem ser ignorados ou permitir que o usuário escolha qual usar. Esta não é uma solução _ideal_, mas acho que funcionará na maioria dos casos e pelo menos nos manterá até que uma revisão mais complexa do assetlib seja realizada. (a menos que alguém possa criar uma maneira simples de lidar com conflitos de dependência de cabeça).

Como exemplo do mundo real,
Eu tenho um recurso para árvores de comportamento godot. Parte deste sistema é um nó Blackboard do tipo UE4 para armazenar dados arbitrários globais ou de nós locais que devem ser compartilhados entre nós. Isso é usado no sistema BT para compartilhar o estado entre os nós de comportamento. Tudo bem e elegante, mas atualmente estou desenvolvendo um sistema de diálogo e as ferramentas que o acompanham, e parte desse sistema requer algum tipo de banco de dados de varibales para usar para condições. Eu gostaria muito de reutilizar o componente quadro-negro do sistema BT para o sistema de diálogo também. Na verdade, o componente Blackboard é o mais genérico possível, e os dados globais são um idioma bastante comum no gamedev, então, mesmo por si só, isso pode ser um complemento bastante útil, pois é reimplementado basicamente em todos os projetos de qualquer maneira .

Com um sistema de dependência adequado, eu poderia quebrar o componente Blackboard em seu próprio complemento e, em seguida, reutilizar esse componente em todo o complemento BT, o complemento do sistema de diálogo e qualquer outro uso específico do jogo que eu tenha para ele. Parece o que quero dizer?

A necessidade de nós multi-script

Este já é outro tópico quente nesta edição e, honestamente, não tenho uma maneira muito boa de abordar isso sem mudar a ideologia fundamental de como Godot deve ser usado. Isso pode ou não ser bom, mas sim... De qualquer forma, isso não é tanto um problema para os _autores_ do plugin quanto para os _usuários_ do plugin (embora muitas vezes a mesma pessoa;).

No final, se conseguirmos resolver essas duas coisas, acho que estaremos 90% lá. Os outros 10% não são tão grandes na minha opinião e provavelmente devem ser abordados na perspectiva de revisar a arquitetura fundamental de ativos, que na minha opinião pode esperar depois de fritar peixes muito maiores.

Se não houver objeção, provavelmente tentarei implementar minha sugestão sobre gerenciamento de dependências no código assetlib nos próximos dias

o gerenciamento de dependências parece legal para mim. :risonho:

A única coisa que não concordo é ter a versão da dependência
ser uma listagem opcional. Isso fará com que os problemas reduzam mencionados que
acontece com o sistema de plug-in de outro mecanismo.

a menos que alguém possa criar uma maneira simples de lidar com conflitos de dependência de cabeça

Eu acho que a solução para isso dependeria de como um plugin chama o código de
um plug-in diferente. Se configurarmos para que os scripts do plug-in
extends "dep2/folder/script.gd" , na instalação poderíamos apenas alterar dep2
para dep2-v3.1.2 . Para hashes, poderíamos usar apenas os primeiros 5 dígitos (a menos que
queremos pastas com nomes com pelo menos 42 caracteres). Às 5
dígitos a chance de colisão é incrivelmente pequena.

Estou um pouco cansado agora, então posso estar perdendo alguma coisa, mas não vejo
quaisquer problemas.

@jonbonazza , se você fizer isso, tente não codificar o uso do Git nele. Embora pareça garantido por aqui, algumas pessoas podem preferir outros sistemas VCS (ou não usar VCS), então talvez esse deva ser um detalhe a ser tratado no lado da biblioteca de ativos.
Além disso, gostaria de saber se consideramos fazer algo para tornar mais fácil ter plugins como sub-repositórios VCS em um projeto? Foi mencionado em algum momento, mas não me lembro se houve um acordo.

Sim, acho que apenas o id do ativo e a versão devem ser suficientes.

Especificar repositório/ramificação/tag/hash do Git pode ser uma maneira opcional de especificar a dependência, mas a maneira principal deve ser pelo ID do ativo.

Não tenho certeza se a biblioteca de ativos possui IDs legíveis por humanos exclusivos (slugs). Se não deveria. Por exemplo, os módulos npm têm um nome/id de módulo de texto que você usa ao instalá-los.

A especificação de dependência talvez se parecesse com

[dependency]
asset_id="some_asset"
version="1.0.0"

@Two-Tone Eu estava tentando não ficar muito louco com isso. Só queria algo simples para nos segurar até que uma abordagem melhor fosse decidida.

@Zylann Eu provavelmente usaria a mesma abordagem que é usada atualmente na biblioteca de ativos - baixando e extraindo o arquivo zip do github.

@chanon o asset lib funciona diretamente com o github, então a única identificação que temos para as versões é commit hash, branch e tag.

Que parte é muito louca? Ter versões de dependência obrigatórias ou minha solução
para conflitos de dependência? Um é padrão na maioria dos lugares que
gerenciamento de dependências e o outro é uma simples edição de texto e pasta
nomeado. Eu não acho que nenhuma dessas coisas é loucura.

Em terça-feira, 3 de julho de 2018, 11h23, Jon Bonazza [email protected] escreveu:

@Two-Tone https://github.com/Two-Tone Eu estava tentando não ficar muito louco
com isso. Só queria algo simples para nos segurar até um melhor
abordagem é decidida.

@Zylann https://github.com/Zylann Eu provavelmente usaria a mesma abordagem
que é usado atualmente na biblioteca de ativos - baixando e extraindo o zip
arquivo do github.

@chanon https://github.com/chanon o asset lib wirks com o github
diretamente, então a única identificação que temos para as versões é o hash de commit,
ramo e etiqueta.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402214905 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AEJES-_IJBjvj3ImvZnqdu-cIAunCp2gks5uC5qIgaJpZM4UhqDC
.

@Two-Tone desculpe, mas "muito louco" eu quis dizer "muito complicado", pois isso deveria ser uma solução rápida para nos segurar. Concordo que, a longo prazo, é necessária uma resolução adequada de conflitos, mas esperava que pudéssemos fugir sem ela nesse ínterim.

Outra opção é simplesmente renunciar ao assetlib e apenas git clonar os deps diretamente no projeto, embora, como a estrutura atual do projeto de plugin de fato está enraizada no diretório addons , isso realmente não funcionará. Nós precisaríamos que a raiz do projeto fosse um nível mais profundo (ou seja, excluindo o diretório addons e enraizado no nome do plugin). Sinceramente, acho que isso seria uma mudança bem-vinda, pois você poderia usar submódulos git para dependências.

@jonbonazza entendi. Sua solução é algo que pode ser implementado e funcionar imediatamente sem a necessidade de modificar a Biblioteca de Ativos. Então eu concordo que é um bom primeiro passo. (Não que eu seja um mantenedor do núcleo que tenha alguma autoridade .. só que acho que é um bom primeiro passo.)

Eu acho que se o banco de dados da Biblioteca de Ativos tiver um identificador de texto (slug) mais informações de versão adicionadas, isso poderá ser adicionado como meu exemplo acima.

você pode usar submódulos git para dependências.

@jonbonazza e é aí que minha última pergunta surge novamente, pois não parece ser possível usar submódulos com um plugin repro porque esse repo precisaria incluir a hierarquia completa de arquivos para ser adequado para download, forçando .git pastas estejam no mesmo local... mas mesmo que isso aconteça, lembre-se de que forçaria as pessoas a fornecer todas as suas coisas através do Git.

@chanon exatamente. Isso exigiria apenas uma pequena quantidade de código adicional em alguns arquivos. Honestamente, um addon provavelmente poderia ser desenvolvido para fazer isso por você em vez de construí-lo no assetlib

@Zylann sim, era isso que eu queria chegar no meu comentário sobre submódulos. No momento, não é possível devido às restrições atuais na estrutura do projeto, mas alterar o asset lib tob para ser mais flexível nesse sentido seria trivial.

EDIT: Isso também pode ser feito de maneira compatível com versões anteriores.

Na verdade, eu fiz uma proposta sobre a estrutura do projeto um tempo atrás. Essa é, na verdade, minha principal reclamação sobre como os plugins funcionam agora. Não há uma maneira legal de embalá-los. Veja #18131. Isso realmente deveria ser mudado primeiro, imo, antes de qualquer coisa, e quanto mais cedo melhor, então temos menos pessoas tendo que fazer a transição de seus plugins.

O que há de complicado nisso? Um é um requisito que pode ser aplicado com
uma verificação simples e a outra é uma simples correspondência e substituir ou
anexar/prender. Isso é mais simples do que realmente adicionar suporte a dependências.

Em terça-feira, 3 de julho de 2018, 12h11, Jon Bonazza [email protected] escreveu:

@Two-Tone https://github.com/Two-Tone desculpe, mas "muito louco" eu quis dizer
"muito complicado", pois isso deveria ser uma solução rápida para nos segurar.
Concordo que, a longo prazo, é necessária uma resolução adequada dos conflitos, mas
Esperava que pudéssemos fugir sem ele nesse ínterim.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402229111 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AEJES7c8ziwhXZirsTsLY0zWfI-jrBzmks5uC6XUgaJpZM4UhqDC
.

@Two-Tone você não pode simplesmente renomear pastas porque os scripts no código do plug-in geralmente usam o caminho do complemento diretamente. Por exemplo

extends "res://addons/foo/bar.gd"

@jonbonazza , eu acrescentaria, não são apenas scripts que fazem isso, mas qualquer recurso que faça referência a outro.

Em seguida, faça com que a estrutura de pastas do complemento seja como eu disse, mas obrigatória, então em
tempo de instalação basta usar as funções localizar e substituir que a classe String
tem em cada script para procurar

'estende " res://addonname/ '

E substitua-o por

'estende " res://addonname-versionnumber/ '

Estes não são problemas difíceis no código. Eles são realmente simples graças ao c++.
Estes são principalmente apenas problemas do usuário para garantir que esses problemas sejam corrigidos
temos que ordenar algumas coisas. Se eles fizerem upload de um plug-in e os usuários acharem que
está completamente quebrado porque o desenvolvedor não seguiu estes incrivelmente
regras simples, então isso está no desenvolvedor do plug-in.

E vamos ter que impor regras para começar, então podemos
inclua estes ou alguma forma deles para ter certeza de que estamos fazendo isso corretamente
do começo.

Em qua, 4 de julho de 2018, 12:48 Marc [email protected] escreveu:

@jonbonazza https://github.com/jonbonazza eu acrescentaria, não é apenas
scripts que fazem isso, mas qualquer ativo referenciando outro.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/19486#issuecomment-402533781 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AEJESwoMKvVVXcllrQ4YQQO852oZ1v7rks5uDP_SgaJpZM4UhqDC
.

Eu acho que se o plug-in quebrar a compatibilidade após uma atualização, eles devem fornecer fallbacks de descontinuação ou fazer como @Two-Tone diz, quebrando intencionalmente o caminho renomeando o plug-in ou uma subpasta dele (isso seria o pior cenário possível porque não é uma situação legal). É assim que o próprio motor faz, e outros fazem. Escrever um plugin vem com uma mentalidade totalmente diferente de que outras pessoas/plugins que você não conhece dependerão dele.

O que isso resolve não é um problema de dependência, mas uma solução para conflitos de dependência. Um plug-in pode depender da versão 1 de um add-on diferente e outro pode depender da versão 2, sem isso ou algo semelhante teríamos conflitos ou teríamos que restringir o usuário de usar plugins que têm dependências conflitantes.

E a solução para evitar que as atualizações quebrem a compatibilidade é impor que cada atualização tenha um número de versão exclusivo. Isso, no entanto, pode começar a cair na categoria "muito complexo", pois você teria que analisar plugin.cfg e perguntar ao servidor de ativos se já existe um plug-in com esse nome e número de versão. Se houver, lance um erro. Se não, tudo deve ficar bem.

E não tenho certeza se você está falando sobre scripts no plug-in ou scripts que o usuário escreve, mas de qualquer forma eu concordo que é um pouco complicado, mas não deve ser um problema tão difícil.

A única solução que consigo pensar é estender o gdscript para que o usuário possa especificar no script qual é a versão do plugin que está usando, então a partir desse ponto basta fazer extends "res://addonname/etc e fazer com que o próprio mecanismo lide usando o caminho correto. Isso, no entanto, definitivamente cai na questão "muito complexa" que @jonbonazza mencionou. Mas para o curto prazo pode ser ignorado.

Há outras questões que precisarão eventualmente ser resolvidas. Por exemplo, o usuário deve saber quais dependências estão sendo instaladas, como lidar com as várias pastas no navegador do sistema de arquivos interno que vem da solução do problema de conflito de dependências, como lidamos com plug-ins que são uma dependência, mas têm uma atualização (nós aplicar as mesmas configurações que são usadas para plug-ins instalados manualmente? (por exemplo, correções de bugs de instalação automática ou apenas instalar atualizações quando o plug-in principal atualizar sua lista de dependências), e mais, tenho certeza.

Eu posso absolutamente ver porque @reduz sente que o gerenciamento de dependências não é importante. São tantas variáveis ​​que _precisam_ ser consideradas e resolvidas para que valha a pena incluir no Godot ou então acabamos com um sistema que não é melhor do que os outros motores usam.

Honestamente, acho que o melhor curso de ação para uma solução de curto prazo é alterar a biblioteca de ativos para suportar (embora não _require_ por causa da compatibilidade com versões anteriores) a capacidade de servir projetos que são uma camada sob o diretório addons . Por exemplo

godot-tools.level-streamer/
    project.cfg

Ao invés de

addons/
    godot-tools.level-streamer/
        project.cfg

Dessa forma, podemos apenas especificar na descrição do addon que ele requer algum outro addon.

Também nos permitiria usar facilmente gitsubmodules em nosso projeto para complementos, se quisermos.

Que tal fazer isso para os deps (por exemplo dep/ ) e ter os plug-ins instalados manualmente no diretório raiz ou em uma pasta definida pelo usuário? Dessa forma, as dependências não estão sobrecarregando a raiz e os complementos podem estar em ou?

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@Two-Tone Mas e se sua dependência tiver uma dependência? A pasta deps não deveria ser uma subpasta do próprio plugin, dessa forma você pode ir arbitrariamente fundo conforme necessário?

Eu sinto que toda essa questão de dependência está sendo pensada demais. Talvez devêssemos criar alguns sistemas simples e discutir cada um, ou votar? Não prevejo que esta conversa termine do jeito que está indo atualmente.

Dito isso...

@willnationsdev Isso pode funcionar, mas se muitos plugins dependerem da mesma dependência, você terá várias cópias dessa dependência, onde pode ser necessário apenas... dois.

Sim, o gerenciamento de dependências não é uma coisa simples. Caso contrário npm não precisaria ser tão complexo e yarn não precisaria ter sido criado.

Não acho que colocar dependências como subpasta de ativos seja uma boa ideia, pois está levando a um caminho que será muito complexo. Haverá casos em que 2 ou mais ativos têm a mesma dependência e algum tipo de desduplicação seria necessário. Além disso, acho melhor para o desenvolvedor do jogo ver exatamente quais dependências o projeto possui, ao invés de ter que passar por subpastas de subpastas para descobrir quais dependências estão sendo usadas e/ou duplicadas n vezes já que é uma dependência comum.

No node.js web dev, por exemplo, não há problema em ignorar o que está dentro do node_modules, desde que funcione, pois só será implantado no servidor. Para um jogo, você estará empacotando todo esse código/ativos em um pacote de aplicativo final e ter a mesma dependência duplicada n vezes é muito ruim.

Esses problemas são o motivo pelo qual minhas sugestões iniciais diziam para não deixar os ativos definirem dependências ainda, mas apenas ter uma maneira de listar as dependências do projeto e permitir que o usuário instale manualmente quaisquer dependências de ativos:
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

Se temos ativos que definem dependências, então acho que todos devem ser instalados no mesmo nível (na pasta res://addons ). Para conflitos de versão de dependência (dois ativos dependem do mesmo ativo, mas de versões diferentes dele), acho que uma resolução simples seria melhor, como sempre ir para a versão mais recente.

Por outro lado, se realmente queremos implementar o gerenciamento de dependências com desduplicação e resolução de conflitos de versão, permitindo que várias versões do mesmo ativo sejam instaladas, tudo bem também! Como se fosse realmente robusto, será capaz de suportar a expansão do ecossistema de ativos a longo prazo. De alguma forma, eu não gosto da ideia de ter várias versões do mesmo ativo no meu projeto de jogo. E foram necessárias npm tantas versões até acertarem (ainda prefiro yarn ) então não acho que essa tarefa deva ser subestimada.

Não acho que colocar dependências como subpasta de ativos seja uma boa ideia, pois está levando a um caminho que será muito complexo.
Se tivermos ativos que definem dependências, acho que todos devem ser instalados no mesmo nível (na pasta res://addons

Eu concordo com isso. Eu também preferiria que os complementos existissem uma vez no projeto em um local padrão, não tantas vezes quanto as versões exigidas por várias outras fontes e em várias pastas. Dependências são uma coisa, mas também podemos encontrar um meio-termo em vez de ir ao máximo, para manter as coisas relativamente simples.

Esses problemas são o motivo pelo qual minhas sugestões iniciais diziam para não deixar os ativos definir dependências ainda, mas apenas ter uma maneira de listar as dependências do projeto e permitir que o usuário instale manualmente quaisquer dependências dos ativos.

Para mim, se os ativos definem dependências, seria principalmente para o usuário ser informado mais rapidamente do que ter que consultar documentos ou revisar todos os plugins antes de instalar. E, eventualmente, ter a opção de baixar as dependências ao mesmo tempo, mas apenas por conveniência (especialmente quando você instala do zero, você precisaria instalá-las de qualquer maneira). Provavelmente não precisamos resolver conflitos de dependência também, pelo menos a ferramenta de instalação pode informar ao usuário se pode detectar um.

Eu sinto que toda essa questão de dependência está sendo pensada demais

@LikeLakers2 O gerenciamento adequado de dependências e a prevenção de conflitos são questões importantes e difíceis. Está sendo muito discutido por causa disso

Não prevejo que esta conversa termine do jeito que está indo atualmente.

Tentar apenas empurrar isso sem descobrir todos os problemas que a dependência traz seria uma ideia muito ruim e apenas causaria muito mais problemas. Esta é uma questão difícil e vai levar tempo.

Para conflitos de versão de dependência (dois ativos dependem do mesmo ativo, mas diferentes versões dele), acho que uma resolução simples seria melhor

@chanon Minhas ideias são simples. O que há de complexo em nomear uma pasta e alterar os caminhos de arquivo relevantes em documentos de texto? É um custo único para o usuário, torna aparente qual versão do que você instalou e é bastante fácil de escrever.

como sempre ir para a versão mais recente

Isso levará à quebra de plug-ins sem aviso à medida que suas dependências são atualizadas e alteram a forma como funcionam. EG Plugin 1 e 2 dependem do Dep 1, mas de versões diferentes. O plug-in 2 depende da versão atual e mais recente, mas o plug-in 1 depende de uma versão mais antiga que se comporta de maneira diferente da versão mais recente. O plug-in 1 não funciona mais como pretendido ou possui bugs com os quais não foi enviado.

Provavelmente não precisamos resolver conflitos de dependência também, pelo menos a ferramenta de instalação pode informar ao usuário se pode detectar um.

@Zylann Então temos o problema em que o usuário não pode instalar x plugin porque y usa uma versão diferente da mesma dependência. Isso não será visto como uma coisa boa pelos usuários

Eu concordo com @willnationsdev e @LikeLakers2

Eu sinto que toda essa questão de dependência está sendo pensada demais. Talvez devêssemos criar alguns sistemas simples e discutir cada um, ou votar? Não prevejo que esta conversa termine do jeito que está indo atualmente.

Excesso de queda de bicicleta. Este é um mecanismo de jogo, não uma plataforma de entrega de complemento de mecanismo de jogo. Apenas dependências de fornecedores em cada um dos diretórios dos complementos e encerramos o dia. Sem estresse sobre conflito de versão ou gerenciamento ou w/e ao custo de alguma ineficiência. Se o usuário do complemento estiver preocupado com o desempenho, ele deve estar em condições de considerar otimizações de desempenho REAIS, como GDNative ou módulos. Também não consigo imaginar por que qualquer complemento teria um gráfico de dependência profunda. A única razão pela qual posso ver um addon tendo uma dependência de outro é se ele o estende de alguma forma: SweetFpsController -> SweetFpsController w/ flying . Nesse caso eu diria que cabe aos dois projetos ou seus usuários conciliar seu acoplamento ao invés de dar a responsabilidade ao motor.

@Two-Tone se o plugin A precisar da versão 1 do X e o plugin B precisar da versão 2 do X, eu diria que Godot não deveria tentar corrigi-lo magicamente. Aqui estão soluções simples para isso:

• Normalmente, a versão 2 do X deve ser compatível com a versão 1, e é assim que as coisas devem ser para mantê-lo simples (lembre-se quando mencionei a mentalidade ao desenvolver plugins).
• Se você não pode usar a versão mais recente do X, espere o plugin A para suportá-lo e baixe a versão anterior (precisamos da API assetlib para lidar com a obtenção de versões diferentes, não apenas a mais recente, que não deve ser difícil de fazer). É como mods, não precisa ser perfeito.
• O criador do plugin X o carrega como um plugin diferente (porque a API quebra a compatibilidade), assim como tivemos quando Godot 3 foi lançado. Então você terá duas vezes o mesmo plugin, mas tudo bem porque eles são muito diferentes para serem realmente os mesmos de qualquer maneira, e coisas que dependem dele também funcionarão. Pode até ser apenas uma pasta renomeada pelo desenvolvedor do plugin, nem mesmo a necessidade de ter duas entradas de asset lib.

Na pior das hipóteses, você teria que fazer isso funcionar manualmente (e compatibilidade de PR para o fabricante do plug-in eventualmente).

Caso contrário, isso envolveria duas versões com caminhos diferentes sendo instalados toda vez (parafusar todas as referências em cada atualização) ou alterações principais sendo adicionadas ao mecanismo para alterar como os caminhos funcionam (complicado).
Acho que se pudermos obter um gerenciamento de dependência simples , já será muito bom, já que basicamente usaria a funcionalidade e a estrutura que Godot já possui (portanto, seria bastante simples de implementar também) e fazer automaticamente as coisas que o usuário tem atualmente fazer manualmente de qualquer maneira.

Não estou considerando o gerenciamento de dependências como algo que deve sempre funcionar e ser de inteira responsabilidade do mecanismo (como o npm), porque isso daria muito trabalho. Eu considero isso principalmente como uma conveniência para as coisas que você atualmente tem que fazer manualmente com a funcionalidade existente, e os criadores de plugins podem liberar seu trabalho com base nesse sistema simples em mente.
Se alguém conseguir implementar bem um sistema indo muito além disso, isso pode ser feito mais tarde, porque o que descrevi acima é viável antes e é principalmente melhorias simples apenas para o assetlib e o editor.

@Zylann Como alguma dessas opções é melhor do que sugeri? E não há nada de mágico em procurar e anexar texto a uma string específica.

A opção 1 força os desenvolvedores a tentarem garantir que suas atualizações de versão não quebrem nenhum outro plugin que dependa dele, o que adiciona muito trabalho extra neles. Quem quer desenvolver plugins para algo assim?

A opção 2 força os usuários a não usar o plug-in que desejam porque precisam esperar a atualização do plug-in, se ainda estiver sendo desenvolvido ativamente, ou simplesmente não usá-lo.

A opção 3 mais uma vez torna as coisas mais difíceis para os desenvolvedores de plugins.

Duas versões com caminhos diferentes não é um problema difícil. Se eles forem atualizados, verifique quais pacotes de instalação os têm como dependência, execute novamente a pesquisa e substitua (levando em consideração o número da versão antiga) em todos os scripts para esses pacotes e, finalmente, descompacte a nova versão.

Eu sinto que as pessoas estão tentando fazer isso parecer mais complicado do que precisa ser.

O gerenciamento adequado de dependências e a prevenção de conflitos são questões importantes e difíceis. Está sendo muito discutido por causa disso

@Two-Tone O que eu quis dizer é que você está pensando demais no problema, mesmo por ser um problema difícil. Muito da conversa (incluindo minhas respostas, admito, então, por favor, desculpe-me, pois isso vai parecer hipócrita) foi sobre o que há de errado com as ideias apresentadas, não tanto sobre o que pode ser feito para mudá-las e torná-las melhores. plano. As ideias sugeridas não podem ter apenas desvantagens, podem? Parece que todo mundo quer do seu jeito e do seu jeito também, o que não ajuda em nada.

Tentar apenas empurrar isso sem descobrir todos os problemas que a dependência traz seria uma ideia muito ruim e apenas causaria muito mais problemas. Esta é uma questão difícil e vai levar tempo.

Eu sugeri algumas ideias simples com a implicação de que nós as resolveríamos e então decidiríamos assim que sentíssemos que temos um bom sistema. Eu não acho que eu tinha que apontar isso explicitamente, mas lá vai.

Estou meio chateado com o tempo que essa conversa continuou sem nenhum progresso. A sério.

Duas versões com caminhos diferentes não é um problema difícil

Isso por si só não é, provavelmente. Mas ter duas versões do mesmo plugin em um determinado momento no Godot implica em outras coisas que se tornam confusas para resolver.

• Seus caminhos não são mais o que você pensa que são / mudanças precisam ser feitas no núcleo, o que é uma preocupação para os desenvolvedores principais principalmente
• Se o plug-in expõe um tipo personalizado, qual o editor exibe?
• Se o plugin for C#, como você o compila sem entrar em conflito com outras cópias?
• Se o plugin registra carregamentos automáticos, como você os diferencia?
• Se o usuário criar dados que usem o plugin, qual ele usará?
• Qual deles mostrará a interface do usuário no editor?

Acho que antes mesmo de podermos encontrar soluções simples para aquelas que se encaixam no mecanismo (e pode haver mais em que não pensei), já podemos melhorar as coisas existentes no editor e na biblioteca de ativos sem quebrar a compatibilidade ou introduzir alterações no núcleo.

+1 em tudo neste tópico - estender o módulo de plug-in e aumentar o uso da biblioteca de ativos é o caminho a percorrer

Depois de experimentar e aprender Unity, agora tenho uma ideia mais clara de como isso deve ser.

O primeiro é que o Unity agora tem um 'Gerenciador de Pacotes' que eles usam para permitir que os usuários selecionem quais componentes do mecanismo eles gostariam de instalar/desinstalar. Parece que eles também podem usar isso para a Asset Store no futuro.

Algo assim realmente ajudaria Godot a "reduzir o inchaço" enquanto possui "addons oficiais". O Unity ainda está super inchado, mesmo com o Gerenciador de Pacotes, enquanto se Godot tivesse um, poderia ficar ainda menor. O método de distribuição "um exe" pode ter que ir embora.

Além disso, "módulos" normais talvez devam ser construídos como bibliotecas compartilhadas (arquivos dll/.so) para que possam ser selecionados para instalação/desinstalação no gerenciador de pacotes.

Projetos e pacotes devem ter arquivos de manifesto listando os pacotes dos quais depende e Godot / o gerenciador de pacotes garantirá que os pacotes necessários sejam instalados.

Seria necessário um registro público de pacotes.

Isso permitiria que a comunidade estendesse facilmente as capacidades de Godot e construísse facilmente as obras uns dos outros. Acho que promoveria muito o desenvolvimento da comunidade.

Não discordando do mérito geral de migrar para a abordagem do Gerenciador de Pacotes, ainda não me decidi sobre isso, mas quero salientar que também tem seus pontos fracos - um único executável pode ser muito mais integrado e bem- testado, pelo menos mais facilmente.

Com um gerenciador de pacotes, a superfície de teste cresce exponencialmente para cada plugin e versão. Isso não é tão ruim se os plugins são principalmente pequenas adições (como atualmente no AssetLib) que não se conectam muito profundamente ao núcleo do mecanismo, mas rapidamente se torna assim se você dividir as partes principais do mecanismo.

O Unity já se depara com problemas, travamentos e problemas de compatibilidade com diferentes versões de seus pacotes, seus editores, ou por ter algumas combinações específicas de pacotes instaladas (ou não instaladas), ou mesmo com a ordem em que foram instaladas.

Isso é muita complexidade adicional que precisa ser bem gerenciada, para que não acabemos no inferno da dependência :)

Em relação ao inferno das dependências, por que não pegar uma página de algo como AppImage e tentar evitar problemas de dependência, tornando os distribuidores de plugins responsáveis ​​​​pelo gerenciamento de dependências de ativos / arquivos? Veja como eu vejo esse problema...

Os plug-ins devem (idealmente) ser elementos independentes de lógica (editores personalizados, nós personalizados, bibliotecas vinculadas dinamicamente) ou ativos (modelos, materiais, fontes, texturas etc.) que devem ter seus próprios conjuntos de dependências. Tentar descobrir dependências compartilhadas é um enigma que, embora as pessoas possam gostar, significa muito mais esforço para mantê-las. Se você realmente permitisse dependências compartilhadas, teria que abordar esse problema de maneira semelhante ao tempo de execução do steam e manter várias bibliotecas, plugins e ativos diferentes como seus próprios pacotes exclusivos. Você também precisaria armazenar vários dos mesmos pacotes em um servidor para várias versões - seria um pesadelo de manutenção e não é surpresa que as distribuições Linux modernas estejam mais ou menos se afastando dos gerenciadores de pacotes.

Um plug-in pode ser essencialmente um único arquivo tar de todos os elementos necessários para que esse plug-in funcione isoladamente. Eles devem funcionar nativamente por conta própria com todas as dependências arquivadas também. Quando o godot vê esse arquivo, ele verifica se há um arquivo de manifesto dentro da raiz da pasta arquivada. Este manifesto pode conter informações básicas (nome, descrição, versão do godot, ícone, autores), mas também deve conter coisas como: update-info (link para baixar a versão mais recente, mantida pelos desenvolvedores do plugin) que o godot pode usar para atualizar automaticamente o plugin (com permissão de usuários), project_website (link para repositório ou site para permitir que os usuários encontrem rapidamente a fonte de um pacote) e class_names (lista de classes dentro deste complemento que podem ser estendidas, usadas para scripts.) Também pode apontar para os addons que ele usa como dependências usando o caminho relativo para um arquivo de plugin interno.

Se permitirmos plugins dentro de plugins, os problemas de dependência serão (mais ou menos) resolvidos. A versão diferente da mesma biblioteca estará em caminhos de diretório diferentes e poderá ser tratada como 'caminhos' diferentes em uma determinada bifurcação. O problema com este sistema, é claro, é que você acaba tendo muitas informações duplicadas em um determinado disco. No entanto, ao empacotar um jogo, o godot poderia idealmente passar por todos os diretórios de plugins e mesclar referências de arquivos que correspondam via checksum (isso pode incluir estruturas de arquivos representadas por tar?). Dessa forma, se dois arquivos forem idênticos, o godot otimizará o binário de saída eventual mesclando a referência a um único arquivo.

Tenho certeza de que essa é uma solução muito ingênua para um problema tão complicado, mas estava pensando no sistema de plugins mais recentemente devido ao meu patch de fonte personalizado. Acho que a melhor experiência do usuário é aquela em que eles não precisam se preocupar com dependências, e os desenvolvedores são os que devem se preocupar em gerenciar suas próprias dependências. Isso facilita o gerenciamento do usuário: um projeto pode ter seus complementos representados como um único arquivo no dock do sistema de arquivos, você pode clicar com o botão direito e obter opções adicionais ( extract files (para desenvolvimento), update plugin (para atualizações fáceis), acesse o site ( for easy community organization )) e também faça referência a classes dentro de um determinado 'contêiner' ( extends "[path-to-addon-tar]://ClassName" )

Apenas meus 2 centavos sobre o assunto, tenho certeza de que há algumas falhas na maneira como estou pensando nisso também, mas pode ser uma solução interessante e também uma maneira decente de reduzir a necessidade de manutenção para o Equipe Godot.

Apenas 2 centavos com base nos 2 centavos anteriores (isso significa 4 milhas?):
Eu acho que os arquivos .tar seriam um pouco desconhecidos para a maioria dos usuários (ahem, usuários do Windows), então pode ser melhor usar os arquivos .zip , pois eles têm um suporte um pouco mais amplo.

Dito isto, que tal distribuir plugins no próprio formato .pck da Godot? Eu tenho alguns contras (como não ser reconhecido pela maioria dos aplicativos), mas isso pode ser uma chance de torná-lo mais padrão e usado.

Eu acho que os arquivos .tar seriam um pouco desconhecidos para a maioria dos usuários (ahem, usuários do Windows), então pode ser melhor usar arquivos .zip, pois eles têm um suporte um pouco mais amplo.

Dito isso, que tal distribuir plugins no próprio formato .pck da Godot? Eu tenho alguns contras (como não ser reconhecido pela maioria dos aplicativos), mas isso pode ser uma chance de torná-lo mais padrão e usado.

Claro, eu quis dizer principalmente .tar como um exemplo de um tipo de arquivo compactado genérico. Ele poderia e provavelmente deveria usar o formato .pck da Godot.

Por que não usar ZIP, pois oferece compactação e é um formato padrão?

@Calinou eu concordo. Se exigirmos que os arquivos .pck sejam usados, as pessoas terão que usar o Godot Engine para empacotar coisas em vez de apenas usar qualquer ferramenta de empacotamento preferida para agrupar seu plug-in para uso. O GitHub também baixa repositórios como arquivos .zip e abriga de longe a maior coleção de plugins Godot.

Eu concordo aqui. Eu não acho que outro tipo de arquivo precisa ser criado. Arquivos zip parecem funcionar muito bem, e as pessoas têm a opção de instalar usando a interface Godot através da biblioteca de ativos, ou podem baixar manualmente. um arquivo .pck não permite essa escolha.

No meu mundo ideal, gostaria de ter dois botões de download em https://godotengine.org/download :

• Um download mínimo simples e elegante que atende a três requisitos de redução e
• Um download de bloat com todos os plugins aprovados e mantidos regularmente que ultrapassaram algum controle de qualidade, então eu sei que a API deles funciona pelo menos tão bem com o núcleo quanto com a API da versão mínima.

Ainda mais ideais:
Selecione e misture. Ao baixar o mínimo, posso selecionar a versão mínima + Plugin "Temas". Que são coleções de plugins comuns necessários para casos de uso comuns. (por exemplo: 2DPixelart, 3D FirstPersonShooter, 3D ThirdPerson, RTS, RPG, 2.5D game, 2DCutout, Rougelike, ManagementSim, Sidescroller, Eventpackage, Shaderpackage, Scriptpackage, Assetpackace, ect). Então, quando eu começo os plugins essenciais dos motores já estão instalados e prontos para ir e eu sei que eles funcionam porque eles foram aprovados.
Usuários mais avançados podem desmarcar plugins individuais dentro dessas coleções de temas se souberem que não precisam deles, ou combinar dois ou mais temas de plugins, ou adicionar plugins individuais adicionais aos temas do conjunto de plugins aprovados para fazer um pacote personalizado.

Idealmente, o resultado seria que https://godotengine.org/download criasse a partir dessas opções _one link de download na hora_.

Por quê? Porque isso seria uma enorme economia de tempo e garantia de qualidade para pessoas que trabalham em equipes ou grupos, para educadores e professores em escolas que precisam implantar em vários computadores, para pessoas que seguem tutoriais e desejam a mesma configuração do tutor, para indivíduos que estão felizes por haver um plugin oficial aprovado pela equipe de desenvolvimento para algo que é comumente usado, mas não por todos, e assim não precisa vasculhar Github e Reddit por dias para encontrar o que precisa, sem saber qual é o mais suportado opção das 6 que encontraram.

Um download mínimo de um clique ainda deve existir para aqueles que precisam do tamanho pequeno, bem como um download máximo de recursos que não se importam com o tamanho, mas desejam o máximo de recursos para ver o que o mecanismo pode fazer.

Uma solução mais simples seria pedir para instalar plugins adicionais [somente oficiais?] ao executar o editor pela primeira vez. Atualmente temos a opção de abrir o AssetLib se a lista de projetos estiver vazia; por que não ter um pop-up de diálogo para instalar plugins oficiais se estiver executando o Godot pela primeira vez?

Fechando a favor de https://github.com/godotengine/godot-proposals/issues/142 , https://github.com/godotengine/godot-proposals/issues/577 e https://github.com/godotengine/ godot-proposals/issues/607 , pois as propostas de recursos agora são rastreadas no repositório de propostas Godot.

Editar de aaronfranke: veja também https://github.com/godotengine/godot-proposals/issues/554