真的很喜欢你的帖子。

编辑：
该死的忽略了这一段

有一种方法可以将文件实际复制到项目中，以防需要在源代码级别进行修改。 只有这样文件才应该被带入项目文件夹本身。 “克隆”资产可以存在于像 .custom 这样的隐藏文件夹中。

所以你基本上已经涵盖了我的担忧。 （对不起）
我只是更深入地了解我如何想象工作流程+行为。

邮政：
不过，IMO 忽略了一个工作流程。
将资产用作资源或第一块基石。
当前真正透明且简单的方法还可以让您只下载几个资产。 删除一些文件。 比保留一些 png 和一个包含你想要的一些功能的脚本。 目前可以对它们进行处理和修改。

如果资产将隐藏在.local/godot/assets文件夹中，则此功能将丢失。

提议

资产应该仍然可见并在编辑器文件浏览器中列出。 如果它们在.local/godot/assets文件夹或项目文件夹本身内，则独立。 因此，您可以浏览文件并了解它是如何工作的，以防没有适当的文档，或者如果您想从中学习。
每个作为“资产”的文件夹也应该用某种图标标记为一个，这样您就可以大致了解什么是资产以及实际文件的存储位置。
还应该有一个列出所有资产的编辑器窗口。 （在表格中）

• 已下载列出了所有已下载的资产。 只需单击一个按钮，即可将它们添加到您的项目中。 但除此之外，它们与资产库中的资产相同。 这个列表在任何项目中都是一样的，对项目本身没有影响。 （只是让概览变得容易。在打开项目时清除此列表并重新下载所有资产也很容易。）
• 始终处于活动状态（基本上只是为每个项目切换“在此项目中使用（活动/非活动）”）这些资产被添加到您机器上的每个项目中（甚至是新创建的项目）。 （也许资产本身需要允许这样做。）这些确实是面向编辑器的。 就像角落里的时钟、git 支持、待办事项列表或拥有更多默认资源：（一个自定义环境，一些更多主题和一堆精灵在每个项目开始时使用）......
  它们可以在每个项目中手动停用。
  它们仍然列在项目文件系统中，并且表现得像任何其他 assed/plugin。 所以你可以浏览他们的文件，看看他们是如何工作的/他们做了什么。
• 在这个项目中使用（活动/非活动）这实际上显示了项目文件系统中的链接文件夹。 和“添加”（它们仍在.local/godot/assets文件夹中，但行为类似于项目本地文件。）将文件添加到项目中。
  您还可以在此处选择要激活的资产版本。 并切换版本。

只要您想从资产编辑/保存/更新文件，就会提示您有两个选项

节省.local/godot/assets

要么更新.local/godot/assets中的资产，将其放入自定义用户版本。
如果包管理器是基于 git 的，自定义用户版本可能是一个额外的提交。 每当您保存时，它都会获得commit --amend ed。
（例如3.2.5/user ）并且在您的所有其他项目中也可用。 （将其他项目中的版本更新为您的用户版本时）
为什么这有用？
资产商店的主题几乎是完美的，但你讨厌字体类型......
更改字体类型将其保存为新的资产版本。 重新访问所有其他项目并将资产版本更改为/user 。 现在你很开心。
也许还可以有一个按钮来发布资产的用户版本。
因此，在资产商店中，其他人也可以选择稍作调整的用户版本。
就像对资产 git repo 进行 pr 的中间体。 （或者资产的作者选择了从/user版本到 master 上的新版本的更改。）

本地化项目

将.local/godot/assets文件夹中的文件复制到当前项目中...删除任何特殊资产行为（例如版本...），现在您可以随意处理它。 （该文件夹也失去了它作为资产的自定义外观。）

这允许资产商店也涵盖模板的用例。 并且是几乎所有艺术相关资产的完美选择。 因为您可以根据需要处理资产来制作它们。
你总是可以激活一堆已经下载的资源（比如说一些基本的原型精灵），让它们成为本地的，然后你将它们导入。

随意的想法

对于您自己的本地资产/资源库/集合，这甚至可能是一个不错的解决方案。 .local/godot/assets中的文件夹可让您将其内容添加到具有漂亮编辑器 ui 的任何 Godot 项目中，而无需在操作系统文件管理器中搜索它。

我同意 AssetLib 和资产库集成（在编辑器和 GDScript 中）都需要爱，如果我们继续推动它作为在核心引擎中包含东西的替代方案。

但是，我个人不同意这应该是一个插件的推送程度。

我们在新 PR 上问自己的第一个问题不应该是这可能是一个插件吗？ 而是这是否足以成为核心？ .

在插件中有东西存在问题：

• 人们首先需要知道他们在寻找什么。 Godot 是针对初学者的。 对初学者友好的软件通常试图拥有某人将（合理地）需要的一切，因为否则他们首先需要了解他们缺少什么以及他们将如何获得它。
  初学者使用 Ubuntu 而不是 Gentoo 是有原因的。 不管你把这个依赖系统做得多么好。
• 存在决策瘫痪。 如果 Godot 中有一个功能，那太好了，需要一秒钟才能使用它。 如果有 5 个插件，我会使用哪个？ 例如，有 5 个以上的控制台插件。 初学者应该选择哪一个，为什么，他们应该在这个决定上合理地花费多少时间？
• 插件被遗弃，质量较差，更新时滞后。 没有理由相信一个随机插件不会对我产生影响，而不是相信 Godot，因为它背后有足够多的人。
• 请参阅统一。 他们的资产大部分都是有偿的，而且对于许多事情，您首先需要插件，这些插件最终集成不良或在更新时被破坏 - 或停产，即使它们是有偿的并且通常至少可以提供一些支持，这仍然很糟糕。
• 文档：无论如何，我们还没有足够的。 不是核心的每个功能，我不能在官方教程/文档中使用。 插件的随机单身人士可能不会提供文档，或者只提供简短的示例，而不是提供演示或关于如何在项目中无缝集成该功能与其他功能的完整教程的更有价值的位。

例子：

• 弹簧臂节点。 (https://github.com/godotengine/godot/pull/18822) 相当小的添加，分离到自己的类中，所以不应该破坏东西，将被许多 3D 游戏使用，即使不是每个第三人称游戏。 回应：应该是一个插件。
• 即使对于 RNG 的东西，也有人讨论过将其作为插件使用。 好像不是 90% 的游戏在某个地方需要 RNG。

编辑：要清楚，我完全是为了避免臃肿。 但这是一种平衡，我想表达对插件中没有所有内容的支持。 非常特定于游戏或未广泛使用的东西、专有插件、大依赖项，是的，请将它们放在 Asset Lib 中！

@karroffel这是一篇很棒的帖子，我基本上同意你所说的一切。 但是，我想对这一点发表评论：

资产与相关的版本一起保存，全部存储在 .local/godot/assets 或类似的东西中。 它们不再是项目本身的一部分，而是在系统范围内可用。

这类似于 Python pip 系统的工作方式。 然后人们意识到最新版本的软件包破坏了您系统中的其他项目。 virtualenv 解决了这个问题。 在 Javascript 的 npm 生态系统中，模块默认安装到项目本地，系统范围是一个可选功能（ npm install --global ）。 然后，您将package-lock.json签入源代码控制，以确保团队中的每个人都使用每个 npm 模块的相同版本并避免冲突。

系统范围的软件包很好，因为它们可以减少人们系统的膨胀。 版本固定很好，因为它可以帮助团队保持一组一致的版本，并可以帮助您确定可以很好地协同工作的完整版本集合。

如果我们走系统范围的路线，我建议保持版本固定。 例如：

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

项目 A 可以使用 fsm-1.0，而项目 B 使用 fsm-1.1。 项目 C 出现并且可以重复使用。 用户应该能够在他们的dependencies.json文件或最小补丁、次要或主要版本中指定插件的特定版本。

下载依赖项后，可以生成dependencies-lock.json文件并将其签入源代码管理。

@mhilbrunner我绝对同意，我认为“这应该是一个插件”的心态有点太用力了，正是这些情况引发了这些想法。 我认为像 SpringArm 这样更常见的东西值得在引擎中使用，以及 Juan 想要删除的InterpolatedCamera非常有用和酷！ 即使认为那些东西只是几行代码，它们也需要一段时间才能正确，所以“这太小了”也是推动 AssetLibrary 的一个不好的理由。

我的想法主要集中在“嗯，项目负责人说是这样的，那么可以做些什么来使新情况变得更好？”

我希望将功能作为插件的大量推动降低一点，但无论哪种方式，我认为所呈现的更改都会有很大帮助！

@saltares是的，那是我的想法。 我是 Rust货物的忠实粉丝。 它的运作方式几乎相同。 库安装在本地需要的所有版本的系统范围文件夹中。 描述在一个文件中，特定配置在.lock文件中，效果非常好！

我很高兴这已经引发了一些讨论 :blush:

以下是我对以上几点的看法：

将东西推出引擎

将东西推到引擎外是IMO的必经之路。 有太多的平台部署大小很重要（移动，html5）和膨胀是一个像 Godot 大小的项目的大问题，所以我们不能高兴地包含所有东西。

对我来说，哲学应该是，只有满足以下所有标准，某些东西才应该成为引擎的一部分：

1. 它使用得比较频繁
2. 做自己很难
3. 只有一种方法可以执行此功能

这排除了弹簧臂、地形，我希望它可以在未来帮助删除我认为应该在引擎之外的功能，例如 InterpolatedCamera、Vehicle 等。

对此的主要担忧是，如果某些东西不是官方的，它将不会被维护。 这就是你们错的地方。

没有人说这些东西不应该是官方的，我们可以为它们建立一个官方存储库，它们可以是第一方扩展。 演示以这种方式维护并且它们是最新的，所以我不明白为什么它不适用于官方扩展回购。

扩展应该感觉像是引擎的一部分

关于这几点：

• 更容易扩展自定义节点，允许跨语言脚本继承

我非常强烈反对这一点。 这样做没有任何实际好处，而且实施成本非常昂贵。 对不起，伙计们，我知道拥有它感觉是一个不错的功能，但权衡成本/收益/风险是非常不利的一面。

我还认为自定义节点或资源应该看起来好像它们不是核心对最终用户来说是一件好事，这是积极的。 用户并不愚蠢，不应该为他们隐藏这些信息。

如果一个新节点是从扩展中添加的，并且是通过脚本完成的，那么这甚至应该显示在创建对话框中。

• 附加脚本时不建议使用脚本继承 - 覆盖是这些情况的默认设置。

这绝对需要完成，这将是一个非常受欢迎的补充。

• 通过系统范围的资产安装添加适当的依赖管理。 将插件移出项目本身，并带回它们进行修改

我对此的感觉是，它要么工作得很好，要么导致完全混乱和附加组件在没有明显原因的情况下崩溃。 看看其他引擎如何使用它，对我来说，依赖管理似乎并不那么重要。

• 允许通过类名和命名空间引用脚本，以避免资产的超长路径。

这是我们之前讨论过的问题，但我们得出的结论是它应该主要依赖于脚本语言（而不是由引擎本身作为核心 ScriptDB 提供），在新脚本对话框中进行小的可用性增强以防万一使用全局类。

我对此的感觉是，它要么工作得很好，要么导致完全混乱和附加组件在没有明显原因的情况下崩溃。

我猜在我们的例子中，插件永远不会自动更新，而是应该有一个已安装的列表，列出版本和手动更新，因此用户可以请求更新并立即检查是否有任何损坏。

由于篇幅过长，此评论被分成折叠的部分。

想要相机？ Godot 有一个可以跟随玩家的相机，几乎没有代码。 想在 Godot 中制作动画？ 您不仅可以制作角色动画，而且同一个系统（几乎）可以取代您辛勤工作的过场动画系统，只需要您编写大约五行代码。 该编辑器甚至被用于制作其他编辑器，例如 RPG in a Box。 您可以在 Godot 中创造多少东西真是太棒了。

现在有了这个问题，希望任何阅读本文的人都能理解我的想法，因为我试图回应reduz关于将事物推出引擎的一些观点。 （这不会回复“扩展应该是引擎的一部分”部分，因为我目前对此没有任何想法。）

将东西推到引擎外是IMO的必经之路。 有太多的平台部署大小很重要（移动，html5）和膨胀是一个像 Godot 大小的项目的大问题，所以我们不能高兴地包含所有东西。

我同意臃肿是一个问题，但是当我看到你到目前为止想要删除的内容时，我问自己是否真的值得删除这些东西。 即使您删除了 Vehicle、InterpolatedCamera 等节点......这真的会产生多大的文件大小差异？ 也许半兆字节？ 也许几兆字节？ 即使它节省了几兆字节，35MB 下载和 45MB 下载有什么区别？ 无论如何，游戏资产将迅速填补这 10MB 的空白！ 除非您打算卸下一半的引擎，否则我看不到重点。

如果您真的关心尽可能多地节省空间，我是否建议让最终用户更容易从引擎中删除他们不需要的节点？ 让那些将要使用引擎的人决定他们是否可以忍受臃肿——不要替他们做决定。

当然，现在我们不能只包括给我们的每一个建议......

1. 它使用得比较频繁
2. 做自己很难
3. 只有一种方法可以执行此功能

...这些指南是审查引擎中应该允许的内容的一个很好的起点。 毫无疑问，对于通过问题跟踪器提出的每个功能请求，都已经考虑了所有三点。

仅当满足以下所有标准时，某些东西才应成为引擎的一部分

但是来吧。 特性或节点的命运不应过于依赖核心特性。 你建议的指导方针很棒，不要误会我的意思，但我们不应该将它们用作清单。 当你在他们的论坛上推荐一个功能时，这就是 YoYo Games 所做的，这也是我被推离他们的引擎的另一个原因——它可以使用扩展来实现吗？ 是的？ 然后我们的回应是进行扩展。 猜猜有多少功能请求被拒绝，因为它们可以改为扩展，无论它在引擎中的合理性如何，相比之下实现起来有多容易，或者社区感觉如何该功能。

我要说的是，您绝对可以牢记这些准则。 每次建议功能时，您都可以考虑它们。 但是，是否所有这些都适用不应成为决定一个功能是否进入的决定因素。根据这些指导方针权衡这个想法，考虑每一个指导方针的重要性，并对这些因素应用权重......仅仅因为一个想法不似乎它使用得太频繁并不会自动使其成为一个坏主意（请记住，即使有几年的经验，您也可能不知道它是如何使用的真实规模）。 仅仅因为一个想法很容易自己实现并不意味着它是一个坏主意。 仅仅因为我们可以通过多种方式实现一个想法并不意味着它是一个坏主意！ 更不用说可能有人提出想法 X，因为他们认为其他人会从中受益。

请记住，这是一个自称对初学者友好的引擎，并且每次初学者都必须编写一些不属于引擎的非特定于他们的游戏的东西，或者去查看一些资产库以获取他们需要的代码，或者走很长的路从引擎中得到他们想要的东西，这可能会将他们推向另一个引擎，或者有时甚至远离整个游戏开发。

tl;dr ：当指南用作指南而不是清单时，指南很棒。

对此的主要担忧是，如果某些东西不是官方的，它将不会被维护。 这就是你们错的地方。

没有人说这些东西不应该是官方的，我们可以为它们建立一个官方存储库，它们可以是第一方扩展。 演示以这种方式维护并且它们是最新的，所以我不明白为什么它不适用于官方扩展回购。

我个人不同意这个想法。 除了我上面所说的（从香草引擎中删除它不会为您节省太多空间），我不得不问我们是否要将它们全部转换为 GDscript，或者我们是否需要他们重新编译引擎只是为了获得那些节点。

• 如果我们将它们保留为 C++ 并需要重新编译......为什么？ 没有充分的理由要求我们重新编译引擎，除非我们改变它的核心部分，或者添加我们自己的功能。 这只是从开发中花费的额外时间，因为我们正在等待编译过程完成，同时要求普通用户安装他们甚至可能不再使用的其他工具，只是为了获得一些第一方节点。 现在这听起来像臃肿！

• 如果我们将它们转换为 GDscript，那么这将带来 GDscript 的所有限制。 诸如附加子节点的潜在开销之类的限制（特别是如果您要求用户将此第一方节点作为场景导入），必须使用路径而不是类名来引用它们的类（尽管您解决了这个问题，但它似乎，但我觉得我需要提出来），较低的性能（无论差异有多大，它仍然较低）等等。它比 C++ 更理想一些，因为你已经从重新编译到拖放，但是...

任一选项还意味着这些节点的文件必须与每个新用户（对于 C++）一起导入到引擎中，或者与每个想要使用它们的新项目（对于 GDscript）一起导入到项目文件夹中。 我不了解其他人，但这对我来说听起来很麻烦，而且听起来它会让你的第一个指南（“它相对经常使用”）非常有争议。 我会试着解释我为什么这么认为。

通过需要额外的努力来使用这些节点，我相当肯定这个第一方解决方案的使用次数将会下降，并且这个第一方解决方案真的不会再像以前那样“相对频繁地”使用。 反过来，当人们停止学习有第一方解决方案时，这将慢慢增加重新创建相同功能的替代方案的数量——当我相当确定我们更喜欢现有版本（在这种情况下，是我们自己的）时进行改进，而不是创建一个添加了功能 X 的新功能，一个添加功能 Y 的新功能，以及一个具有这两个功能但没有优化的新功能，等等……当人们为替代品创建这个市场不知道有第一方解决方案。 它正在制造混乱。

此外，您说它们将保持维护。 那太棒了！ 但是谁来维护它们呢？ 在向这个存储库添加新东西时，我们的指导方针是什么？ 我们是否会努力确保这个第一方扩展存储库始终有效，无论是稳定版本还是主版本？ 基本上，值得为一个有效的单独项目付出努力吗？

顺便说一句，我更喜欢为每个节点实现多个脚本支持
而不是跨语言继承。 前者只是几行
代码..

2018 年 6 月 10 日星期日 13:51 PLyczkowski [email protected]写道：

我对此的感觉是，它要么工作得很好，要么导致
没有明显原因的完全混乱和附加组件。

我猜在我们的案例中，附加组件永远不会自动更新，但是
相反，可能应该有一个列出版本的已安装列表
和手动更新，因此用户可以请求更新并立即检查是否
什么都坏了。

—
您收到此消息是因为您发表了评论。

直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/19486#issuecomment-396063688 ,
或使线程静音
https://github.com/notifications/unsubscribe-auth/AF-Z21jtcnUhRyhdyEEnaM_hfTACsxOiks5t7U6HgaJpZM4UhqDC
.

每个节点的多个脚本已经尝试了几次并且总是失败。

尝试的是多脚本节点，但这很麻烦

在 2018 年 6 月 10 日星期日 15:01 Zireael07 [email protected]写道：

每个节点的多个脚本已经尝试了几次并且总是
失败。

—
您收到此消息是因为您发表了评论。

直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/19486#issuecomment-396068742 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AF-Z26u8Rqc1yL-BGX16CAx_iWsYEo1oks5t7V8CgaJpZM4UhqDC
.

我知道资产不应该与内置的东西看起来一样。 但我也认为它们应该比用户制作的脚本更高级。 它们应该有一个明确的分离，因此很容易替换/升级资产，而不必从你的项目中挖掘它们。

此外，为资产添加一个层并让它们更好地与引擎集成以扩展它是保持核心小而干净的好方法，同时通过资产库轻松提供新功能。 如果资产不仅可以为节点/资源注册新类型，还可以为要扩展的类以全局可访问的方式（即不依赖于路径）注册新类型，那么构建在引擎之上的框架将是一个很大的好处。

像 Escoria 这样的框架可以从中受益匪浅，并且可能还有其他框架用于 RPG、平台游戏、视觉小说等。

我在这里所说的都是非常抽象的，但是明确区分什么是内置的、什么是第三方资产以及什么是用户代码（无论这种分离是如何呈现的）将使“保持核心小并提供扩展” ” 轻松前行。

跨语言继承对我来说听起来是个可怕的想法。

在我一直在使用 EditorData 中的 TypeDB 的工作中，我一直在将命名空间类型名称保存到文件路径 HashMap 中，该文件路径 HashMap 在修改后会转换为 ProjectSettings 中的字典。 在我的分支中，GDScript 解析器和编译器正在使用这些数据为类型创建全局名称。 此时，我已经出现了自定义类型脚本。 脚本可以按名称访问和继承它们。 更重要的是，任何可以看到 ProjectSettings 的人都可以访问这些数据。 因此，编辑器看到的 CSharpScript 可以生成输入到 ProjectSettings 字典中的映射，从而允许 GDScript 访问 C# 中声明的类型。 可能还有一种方法可以将 ProjectSettings 字典数据包装在 C# 对象中，该对象在访问时返回 Script 对象，这样 C# 也可以通过名称访问 GDScript 类型。

这种技术将共享命名空间保持在核心之外，并且完全在编辑器上下文中，因此选择加入的语言可以准备自己的访问数据的方式。

我确实喜欢@karroffel关于能够进行跨语言脚本继承的建议（甚至不知道这是否可能）。 以某种方式自动复制将调用委托给基本脚本的方法，并定义所有相同的属性/信号/常量等。

我也希望更简化地访问 AssetLibrary 中的内容，能够为整个编辑器保留一些插件，而其他插件仅用于单个项目。

我正在制作的 TypeDB 系统还将为...提供编辑器支持

1. 让所有自定义脚本都显示在 CreateDialog 中
2. 自动扩展自定义类型脚本使您在向节点添加脚本时扩展该脚本
3. 删除扩展自定义类型脚本的脚本会在删除后恢复自定义类型脚本（因此您无法删除自定义脚本 - 您必须改用编辑器中的“更改类型”命令）。

此外，我所做的所有界面更改都将使自定义类型脚本清楚地理解为脚本，并保持相关脚本可访问。 用户将始终知道什么是脚本并允许他们访问脚本，但它仍然让他们在一定程度上感觉像是引擎中的对象。 即使在 GDScript 中，名称也不是全局访问的，就好像它们是核心类型一样，而是从名为Scripts的全局字典中提取的。 到目前为止，我已经使用自定义类型脚本，但我希望最终扩展为让 Dictionary 注册自定义类型场景以及项目中可用的任何典型脚本或场景，如果脚本语言没有，可能通过导入系统有一种获取命名空间类型名的简单方法。

由于我参与了该提案的思考过程，因此我想指出几点：

我对戈多的看法

TLDR：我认为 Godot 是一种工具，可以通过资产和插件以非常简单、模块化和初学者友好的方式进行高度扩展。

拒绝我的 SpringArm pr 背后的动机是非常合理的，这就是为什么@karroffel和我讨论了引擎可以采取的方向，以保持轻量级，同时保持用户友好。

我希望看到的是一个干净、小巧、快速的核心引擎，以及一个由插件和插件组成的良好集成生态系统。
由于 ArchLinux 有不止一个包存储库，我认为如果 Godot 有一个用于核心功能（以及现在是核心的节点）的“官方”（由 Godot 管理）存储库和另一个社区存储库，那就太好了。 在 Godot 核心“扩展存储库”中，我会将所有难以编码但不足以与原始版本引擎一起提供的节点放在一起。
旁注，通常没有考虑到的是，某些功能可能很容易编码，但在编写这几行代码之前可能还需要进行大量研究。

我想象用户能够下载感觉像是在“扩展”引擎本身的插件和资产：根据你下载的内容，你有 Godot-fps 或 Godot-platformer 或 Godot-racing。

Godot 可能是第一个真正感觉像 Unix 和模块化的引擎，它的编辑器扩展甚至超过了 Unity。 你们中的许多人都知道当您的 Linux 系统不是“那个发行版”时感觉有多好，它是您自己的定制系统，具有您非常个性化的功能。

优点

TLDR：这种方法将允许 Godot 管理单独管理核心技术核心功能和更用户友好的插件，而不必过多担心引擎臃肿

这个提议的好处还在于关注点分离和贡献者的处理。 我觉得，目前还不清楚什么可以成为核心，什么不是。 没有明确的规则或统计数据可言。 有些人可能会说某个功能被广泛使用，而另一些人则认为不是。

将 Godot 划分在不同的“环”中，可以对 PR 和功能进行更细粒度的管理，并可以让@reduz和其他非常技术性的开发人员有更多时间专注于核心技术内容，而另一个团队将管理扩展环，更多地考虑用户反馈和可用性，而不是不得不面对引擎膨胀，因为“扩展环”会按需膨胀。

关于多语言继承

随着 Godot 的发展，资产商店很容易变得一团糟。 脚本语言之间的严格区分实际上会破坏人们出售资产和在资产商店上发展生态系统的任何尝试，从而扼杀了自由工具制造商为 Godot 制作和销售工具的许多机会。
如果我们希望任何渠道发展一个活跃的生态系统，语言桥梁需要更加完整。
现在跨语言继承对我来说听起来很棒，但我技术不够，无法就此事发表任何意见。 我只想指出一个可能很快就会出现的问题，特别是因为围绕 C# 有如此庞大的社区。

关于可用性的说明

我已经使用 Godot 快一年了，最近我觉得决定功能的人不会将引擎用于比小型演示更大的东西。 @LikeLakers2指出了一个问题，我觉得一些未深入开发核心团队的用户共享一个问题。

我认为所谓的臃肿在更大的计划中是一个微不足道的话题，这不像我们现在做出的决定是我们需要在戈多的整个生命中遵守的。 开源让我们可以随时进行更改，唯一的问题是我们等待的时间越长，更改的决定就越沉重。

现在这也是另一天的讨论。 现在的事实是，

1. Godot 是一款紧凑、快速、便携的游戏引擎。 我非常喜欢它，但是，....
2. Godot 的可执行文件大小约为 45-60MB，具体取决于各种因素。 但导出模板可以大到 300MB。 现在这对第一点来说是一个很大的打击。
3. Godot 具有许多令人惊叹的功能，使其成为相机跟随、视差 BG 和车辆等初学者的享受，这是其他类似游戏引擎的一大优势。 因为它使在 Godot 中创建游戏变得更加简单。 并使 Godot 成为许多新手开发人员的家，他们没有能力为此类工具编写自己的实现。

现在，如果我们删除一些人认为臃肿的功能会发生什么。 那么发动机肯定会更紧凑，但这是必需的吗？ 如果它更好地满足我的需求，我认为自己下载 100MB 引擎没有问题。 但是导出呢，一个100MB的引擎不会导出更大的游戏吗？

可能，是的，但是在台式机似乎不使用低于 256BG SSD + 1TB HDD 的任何东西的世界中，甚至手机的空间都从至少 16GB 开始，所有这些空间很可能会增加，是这样吗？坏的？
我的意思是说我们还不需要删除任何东西，我们只需要开始更好地管理一些东西就可以了。
功能应该有某种重要性列表来决定它们是否应该在核心中，但这并不意味着它成为一条法律，而是一条经验法则。

对于挑剔者，我们可以删除一些非常未使用的工具，仅此而已。 除非我们粗心，否则功能不会使引擎膨胀。 甚至 Unity 中的所有臃肿都没有阻止人们使用它，有它。
我绝对不是说我们不应该关心臃肿，而是小心和偏执是完全不同的事情。

至于多语言继承，我在这里并没有真正看到它的用途。 当然，我们应该能够与多种语言的脚本交互，但继承！ 这可能比我想象的要多，但好处似乎并不值得。
然而，多脚本可能只是解决许多问题的解决方案，从插件创建到更好的模块化。 虽然这是我的观点。

关于限制盒子中节点和资源类型的数量，有一些话要说。 通过将任何较少使用的资产存储到外部下载中，您可以 1. 让新人更容易通过“乱搞”来掌握系统，而不会被功能的广度（决策瘫痪）所淹没，和 2. 如果事实证明一些更狭窄的用例场景资产最终的工作流程不如后来使用不同 API 的工作流程好，那么不要最终创建那么多遗留包袱。

当后者发生在内置的时，你就会被它们困住。 当可下载资产发生这种情况时，随着时间的推移，最受欢迎的资产往往会成为事实上的标准，但它们的命运并不会与 Godot 的命运永久纠缠在一起。 这意味着它们可以逐渐变得默默无闻，而不必担心破坏预期的核心兼容性。

跨语言继承点需要解释一下。 我不仅认为这是一个坏主意，而且我什至不知道它是如何实现的。

1. Godot 的可执行文件大小约为 45-60MB，具体取决于各种因素。 但导出模板可以大到 300MB。 现在这对第一点来说是一个很大的打击。

300MB 的导出模板？ 你是说资产吗？

@neikeq问题是，如果您的整个项目都在 C# 中，但您使用的是从 AssetLibrary 下载的自定义节点，那么该节点只是一个常规节点，很可能只附加了一个 GDScript。

如果你想“扩展”节点，你不能！ 我想您可以添加一个子节点来添加新功能，但这样就不可能覆盖事物。

执行

目前，脚本语言对继承调用使用非常相似的模式，可以推广。

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

这里的模式是

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

所以它从脚本继承树的底部开始，然后在没有找到这样的方法时尝试调用上层。

如果每个脚本都有一个Ref<Script> parent_script而不是特定于语言的继承结构，这可以概括为

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

毕竟这可能不是一个好主意，但如果我们更多地推动 AssetLib，那么随着时间的推移，无法选择覆盖跨语言的东西可能会成为一个问题。

@neikeq看到这个，

@swarnimarun这是所有平台的导出模板，所有支持的拱门，调试和发布，它们的大小与引擎的“膨胀”完全无关。 我们可以决定只支持 Linux X11 64 位版本，这个文件将是 20 MB...

@akien-mga 我不打算叫它，臃肿。
但是新用户将下载它的全尺寸，他们将没有足够的经验知道他们可以单独构建或为特定平台下载。

当这是我们为初学者用户提供的内容时，这有什么不相干的？

@akien-mga：导出模板大小很重要，因为您删除节点的论点是

部署大小很重要（移动，html5）

@swarnimarun @Zireael07是的，导出模板的大小很重要，但我的观点是，测量一组模板的大小并没有给我们任何指示。 一个模板的大小（例如，wasm 发布模板，3.4 MB 压缩，或 Android 发布 APK，23 MB 用 armv7 和 x86 库压缩）比“下载开发所需的所有内容需要 350 MB”（+ 可能 10 GB for Visual Studio，如果你需要构建一些东西......）。 如果一个最小的游戏在大小很重要的平台（网络、移动）上采用什么大小，那有​​什么关系。

虽然我认为部署规模确实很重要，但我也认为需要考虑的还有开发人员时间。 例如，虚幻引擎几乎可以提供任何你想要的功能，但事实上有这么多的功能使得开发过程非常低效，因为每次你需要用它做某事时，你首先需要弄清楚哪些内置功能您需要使用然后学习如何正确使用它。

这是我非常喜欢戈多的一点。 您可以立即对您的功能进行编码，然后有人会过来告诉您“哟，您知道我们有这个您可以使用的内置功能吗？”

当一个引擎的功能太多时，问题是使用该引擎进行开发会变得非常累人。 是的，拥有您需要的所有功能固然很好，但是要通过所有这些功能来找出您真正需要的功能是一件非常痛苦的事情。 那是臃肿。 这就是为什么我们建议按需提供良好集成的功能。

通过系统范围的资产安装添加适当的依赖管理。 将插件移出项目本身，并以一种方式将它们带回来进行修改。

这与失去便携性是一样的。 我的插件是我项目的一部分，我需要在我正在工作的任何计算机上使用它，并且我需要对每个项目的每个插件进行具体修改......我认为将插件存储在 .local/whatever 中没有任何好处. 这是一种混淆我的项目。

res://addons的实际系统很好......对用户免费且可在计算机周围携带。 如果没有对这个系统的抱怨，是否有必要改变它？ 用户真正抱怨的还有很多其他事情......

@Ranoller您可以随时将插件复制到您的游戏文件夹中。
无论如何，在这种情况下，您的 project.godot 会将您的插件列为依赖项，并且它将以正确的版本下载到您的新计算机

下载了吗？ 我的插件位于 pendrive 内的项目中，并且是 git 存储库的一部分...我不明白提案...插件更改与其他代码相同...我从游戏代码的插件更改更多代码，我不想按版本对插件进行编号并在项目之外工作......每一行代码更改都需要手动更改每台计算机中的每个插件？......真的插件感觉像是项目的一部分...... . 从 git 存储库中提供插件对我来说是无稽之谈，但我真的认为我对此一无所知......

@Ranoller的想法是将那些不需要修改的插件移到项目之外。 例如， InterpolatedCamera将只是您要​​按原样使用的节点，而不是更改它的代码。

仅编辑器插件（例如 TODO 列表或 git 集成等）的情况也是如此。这些是您想要使用但不会更改的东西。

这很像包管理器，并且库可以在所有非 C 和 C++ 的语言中工作。 您有一个指定所有依赖项的文件，然后包管理器将获取这些依赖项。 即使您更改 PC，也会发生这种情况 - 包管理器将下载任何尚不存在的包。

当您想修改某些内容时，您可以将代码带入项目中。 然后它在你的 git 和包含所有源代码等的项目中。但情况并非总是如此。

我的建议是默认情况下在项目之外拥有一些东西，直到你真正需要修改一些东西。

目前，许多资产主要是您确实需要修改的模板，拥有这样的系统可能会改变，因此通过 API，而不是通过源修改，事情更通用。

@karroffel但是跨语言继承如何在每种语言中工作？ 这对于与引擎紧密耦合的 GDScript 来说可能很容易，但对于 C# 等通用语言或在 GDNative 之上添加的其他语言来说，情况就完全不同了。
我真的看不出这是如何实现的，更不用说它不能做得比好事更坏。

IMO 修改项目所依赖的插件的内容不是一个好主意。 如果需要任何修改，只需将内容复制到插件文件夹之外并在那里进行更改。

编辑：或“分叉”插件😜

@neikeq您修改的内容在您的项目中。 当你想修改一个插件时，它会被复制到你的项目中并且只在本地修改。

@karroffel可能需要一个项目插件和一个编辑器插件的想法以避免混淆，并将两者明确分开。

@QbieShay如果有更新修改了您修改的文件怎么办？

@neikeq脚本继承不是这个问题的解决方案，它只是一个。 当您想使用不同的编程语言时，目前没有一种很好的方法可以通过附加的脚本覆盖节点的功能。

如果我们可以选择覆盖Script API 中的方法，那也很好！ （基本上是在外部定义新方法并覆盖现有方法）。

@PLyczkowski这也是一个有用的建议，但我的建议不仅限于此——而且是有原因的。

让我们再次以InterpolatedCamera为例。 我永远不会接触它的源代码，我只会使用它。 在我的项目中拥有源代码将被浪费。 此外，我制作的大多数项目都是 3D 的，所以我可能会在我的所有项目中复制该代码。

另一方面，git 集成对于添加难以用 git 钩子表达的自定义行为可能非常有用，因此需要进行自定义。

当某些东西应该在项目内部而在外部时，无论是否是编辑器，都没有黑/白线。

@neikeq

如果有更新修改了您修改的文件怎么办？

在这种情况下，您将丢失版本信息，因此您无法再轻松更新。 那么你应该使用像 git 这样的工具来处理这些情况。

这个想法是

• 项目外：更容易更新，更容易跨项目
• 项目内部：可定制，丢失资产状态，无自动更新

基本上，一旦将它们复制到项目中，它们就会变成普通文件。

读到这里，我可以说避免膨胀和最小化游戏的文件大小是有效的。 不过，请允许我在这里提出一些想法。

• Godot 可以使用一个系统来剥离它不使用的节点使用的代码游戏（即大多数 2D 节点具有许多 3D 游戏，大多数 3D 节点具有许多 2D 游戏）。 这将减少不接受新节点类型以减小游戏文件大小的压力。 例如，Unity 用户已经在使用类似效果很好的东西。
• Godot 可能有一个内置的资产浏览器，可以连接到 Godot 站点上的插件页面。 您选择所需的自定义节点，它将自动安装到正确的位置。 打包游戏时会剥离未使用的插件。
• 甚至，流行的自定义节点可能会与 Godot 构建捆绑在一起（就像 Blender 与插件一样）。 自定义节点也应该被标记，因为它们通常可能更高级别，并且在某种程度上可能比更通用的节点更像是一个黑盒子。

反正我的2美分。

@王牌龙

1. 我认为作为引擎范围的功能，您的第一点会非常酷。 如果您导出的游戏不使用节点，或者如果您在项目中使用的任何节点都没有使用节点，那么如果可以从最终的二进制文件中自动排除它们会很酷。 除此之外，您目前只需要依赖开关并重新编译引擎。 ：-/

2. 这基本上是资产库已经是什么。 问题是它没有任何依赖的概念，直接将东西放到你的项目目录中，并且没有任何方法为你制作的每个项目维护系统范围内的一组给定插件。

3. 自定义节点总是被明确标记，因此无需担心（它们旁边有一个脚本图标，因为您使用脚本创建自定义节点来扩展它）。 因为它们是脚本，所以它们不会随引擎一起提供。 它们将是某种插件的一部分，因此，如果有的话，您可能会拥有更像我的 godot-next 存储库的东西，它是一个用于收集东西的“节点扩展”存储库。 它只是一个比任何东西都更“官方”的容量（那个 repo 也可以使用很多工作，哈哈）。

好的，慢慢地但抓住了......如果我在项目中维护插件，我可以像在另一个脚本中一样在插件代码中工作，而不会失去与当前项目的 git 集成并且不会失去可移植性......但是如果我想转换任何其他开发人员的工具中的插件或我所有项目的通用工具中的插件我以外部包的形式共享它，可以使用该工具的外部 git 存储库实现并使用资产库更改为其他人......如果是的，对我来说没问题...如果其他开发人员使用该工具，并且需要他们的个人版本，他/她需要存储在项目中，在这种情况下插件不实际（不要丢失他们自己的工作）... 它是？

@Ranoller是的，我认为您已经了解了他的提议的要点。

关于你们正在讨论的一些反馈

1）如果这是一个需要解决的实际问题，我更喜欢每个节点支持多个脚本（这只是几行代码），而不是跨语言继承（这很疯狂）。 我仍然不认为这是一个需要解决的问题。

2）我不喜欢包管理器和系统范围安装附加组件的想法。 我认为这是一个糟糕的想法，从中没有任何意义。 我已经看到，即使对于 Unity 开发人员来说，在大型项目中更新资产版本并看到一切都崩溃并花费数天时间修复它是多么痛苦。

3）我不喜欢包管理本身的想法。 我已经看到 Unity 用户在绝大多数情况下都将他们从资产商店中获得的东西无休止地砍掉。 他们经常只是将其用作基础，然后对其进行处理并根据自己的用途对其进行自定义，因为您获得的资产只是您想要的方式的 60/70%.. 或者他们只是想看看是怎么做的，以后再做自己的事。

我认为正在讨论的提案在现实生活中并没有真正获得任何东西，所以我自己不打算在这个讨论中添加太多内容。

如果我们允许人们以简单的方式在没有任何 3D 内容的情况下进行导出，我们可以减少多少引擎尺寸？ 许多游戏（一半？超过一半？）不需要 3D 功能，但它们仍然存在于同一个二进制文件中。 我知道理论上可以在每个平台上使用宏自己重新编译它，但需要一些投资......
此外，按照这个想法，如果模块只是作为官方引擎发行版一部分的“内部”动态库，那么向引擎添加更多功能将不是什么问题，因为它们可以很容易地选择退出（只是)，但是对于某些平台（主要是移动设备和 HTML5），使用这样的动态库可能会有点限制。 所以对于模块，我会理解 GDNative 是首选（哦等等......它有同样的问题^^）。

@reduz多个脚本如何工作？ 它对引擎扩展有何贡献？ 您是否在现有问题中解释了您的想法？ （问，因为在这个线程中解释它可能太多了）

通过系统范围的资产安装添加适当的依赖管理。 将插件移出项目本身，并带回它们进行修改

不。为了健壮性，我希望它们在项目目录中。 但也许有一种方法可以使用包管理器手动更新挑选的那些，也许还有系统范围的缓存。

至于膨胀问题，我希望能对 _modules_ 进行更多控制，这已经在 2018 年 1 月的 Patreon 民意调查中投票：

路线图优先级：选择退出编译引擎部分以创建更小的二进制大小的更多选项 [预期为 3.1]

很难评论这个提案，因为它涉及到各种各样的东西，人们在评论不同的方面并提出不同的问题。

总的来说，我认为“依赖管理器”的提议在纸面上听起来不错，但我认为实施不会带来任何好处，而只是在项目文件夹中出售插件不会带来任何好处。 它将需要结合复杂的依赖管理机制来解决“更易于安装”的情况。 这个项目已经有 3000 多个问题由一小部分贡献者开放。 在我看来，引入像依赖管理这样复杂的东西是一种枪法。

我同意@reduz的观点，即核心应该是极简主义的。 在我看来，任何不能被归类为“核心”的东西都应该独立纳入。 作为一个用户，我希望 Godot 成为一个多平台游戏_engine_。 如果我想要 godot _游戏框架_（车辆、插值相机、地形、玩家控制器等），它应该可以作为独立于核心的一流附加组件（或模块？）。 我认为改进插件故事对此有所帮助，但一个全面的依赖管理器和自动化插件管理器似乎正在推动它以降低净收益。

我最后的评论是要警惕迎合“初学者”和放弃“权力”用户。 Godot 因其强大的功能（模块、gdnative、gdscript、编辑器等）和灵活性而受到更多高级用户的关注。 正是这些用户对 godot 进行了测试，突破了它的界限，探索了它的 api，并经常为项目做出贡献。 这些用户可以在他们的文件系统中创建指向目录的符号链接，以便在多个项目中重复使用他们的插件。

如果这个想法是从核心中删除更高级别的节点，那么这些节点应该随时可用并且易于找到以供下载。 理想情况下，我们可以将它们保持为“官方”，因此它们具有更好的可见性（就像引擎内节点一样）。 然后官方资产可以毫无问题地用于演示和教程。

外包这些的好处是可以改进和发布它们，而不必等待新的引擎版本。 因此可以立即修复错误，因为对于扩展，打包新版本非常简单。

我想最终包管理在大多数情况下都会很麻烦。 即使在您添加到项目中的自定义节点的新版本的情况下，更新它也可能会导致许多其他问题（即使使用 semver，因为您可能已经解决了现在已修复的错误）。

OTOH 对于某些编辑器插件来说，退出项目并经常更新它们可能是有意义的。 我的 Tiled 导入器插件就是一个例子。 您很可能不希望它随游戏一起提供，而是希望拥有支持更多功能并具有错误修复的最新版本。

这更适用于其他编辑器扩展，例如 git 管理器和时间跟踪器。 您甚至可能不在乎您的队友是否有时间跟踪器插件，它与项目无关。 但是，您必须放入addons文件夹并在项目设置中启用，然后小心不要将其与游戏的其余部分一起提交。 这些可能是插件的少数，但仍然有与项目无关的系统范围的插件有一个真实的用例。

我相信中间立场是创建一个包管理器作为外部工具，而不是将它集成到 Godot 中。 它甚至不需要是官方的（尽管它可以被“认可”）。 如果需要在基础引擎中进行一些更改来支持这一点（例如拥有全局插件），那么添加它不会有太大问题，特别是如果它们是仅限编辑器的。

然后那些认为它有益的人可以使用它。 如果它变得普遍并且每个人都在使用它，我们将获得使用统计数据和可用性反馈，以决定是否以及如何将其完全集成到基础引擎中。

现在，对我来说，跨脚本继承是一个禁忌（如果可能的话）。 Multiscript 有点奇怪，但它会以更简洁的方式有效地取代跨脚本继承。 尽管它引发了一些问题，例如：如何在同一个对象中调用另一个脚本的函数？ 我想这是另一个讨论。

按名称 OTOH 引用脚本听起来非常好。 理想情况下，所有资源都可以通过名称引用，因此如果您决定移动内容，则路径不是问题。

@vnen我仍然看到的唯一问题是插件和项目之间的不兼容。 你会如何解决这个问题？
因为如果有一个由 Godot 维护的官方扩展库，那么每个节点都以每种可能的语言发布，或者我认为跨语言继承是我们保持用户友好性的唯一方法。

@vnen如果您按名称引用所有资产，那么这将是一个矛盾的混乱。 这更适合脚本，因为只有程序员必须为他们的类提供唯一的名称才能键入和使用它们（或者更少见的是资源）。 对于其他东西，如果我们摆脱路径，它将需要这个https://github.com/godotengine/godot/issues/15673 ，除非您还希望艺术家、设计师等必须唯一地命名他们的所有资产（仍然带有重命名问题）。

@Zylann @vnen我正在编写的 TypeDB 理论上应该允许人们有选择地为任何资产注册一个名称。 我目前只将它用于脚本，并计划也用于自定义类型的场景，但您也可以修改它以使用资源。 目前的逻辑只有一个用于脚本和场景的 HashMap，但也许我可以概括处理任何类型的资产的逻辑，所有这些都在分类的 HashMap 中。

我可以尊重 reduz 对系统范围的东西的关注，这些肯定是对会修改引擎产品的插件的关注，但是当涉及到编辑器的特性时，就像 vnen 所描述的那样，我绝对可以看到它在比较安全的方式。 如果人们添加插件以授予编辑器更多功能，那么他们通常不会破解并自行修改这些功能。 他们将按原样使用它，或者如果他们确实进行了修改，那么可能是为了 PR 这些更改以改进工具。 毕竟，您并没有使它们适应游戏。 因此，如果是这样的插件，我认为我们应该有一种方法可以在您开始一个新项目时（以某种方式）轻松地将这些功能授予引擎。

在不需要依赖管理器的情况下可以使事情变得更容易的一种可能的方法是简单地不在插件之间共享依赖关系，而是在项目中复制它们，这样版本控制就不是问题了。 它可能会使单个项目变得更大，但如果它是用于与游戏相关的内容并且人们无论如何都会修补它，正如reduz所说，那么他们可以移动依赖项。 在这种情况下，我们需要一种方法让插件声明它们拥有的外部插件依赖关系，并让用户可以选择自定义他们在哪里寻找该依赖插件。 这样，如果他们确实选择移动一个插件并让其他插件在同一位置查找它，他们可以自定义它。 但是，默认情况下，一切都可以通过管理自己的依赖项来开箱即用。 使用整个 plugins-as-sub-projects 提案 (#19178) 可能也更容易处理这种情况。

这将阻止我们拥有需要依赖管理器的全局依赖（reduz 的问题编号 3）。 我们可以将它与允许用户从资产库中创建收藏资产列表的功能相结合，他们可以选择在创建新项目时自动安装到他们的项目中（因此所有内容仍存储在本地，但它会自动发生并且他们不必手动出去，找到所有他们喜欢的插件并手动下载并安装它们）。 这将解决@karroffel在创建新项目时使用相同资产轻松扩展引擎时想要处理的可用性问题。

对于不需要复制的更多特定于编辑器的插件，也许人们可以标记那些“最喜欢的”插件，他们会自动为它们制作符号链接，将插件存储在某种用户文件夹中。 因此，可能有“编辑收藏夹”和“项目收藏夹”分别表示“我希望在每个项目中使用它，将其存储在共享位置并制作符号链接”和“我想要在每个项目中使用它，复制它”。

将其与用于命名脚本/自定义自定义类型的 TypeDB 东西结合起来，我相信它会正确解决所有提到的问题，但跨语言脚本继承/多脚本问题完全是另一回事。

因此，可能有“编辑收藏夹”和“项目收藏夹”分别表示“我希望在每个项目中使用它，将其存储在共享位置并制作符号链接”和“我想要在每个项目中使用它，复制它”。

也许那样拥有“捆绑”插件更方便 - 用户创建的官方批准 + 用户创建的本地。 因此，我们有“第一人称射击游戏”、“体素块游戏”或只是“我的东西”，而不是“编辑收藏夹”和“项目收藏夹”。 很像 Unity 初始资产，但不需要用纹理等使它们膨胀，不同类型的 Godot 吉祥物面孔就足够了：D

这也可以用作包管理器，其中包管理器现在是人工管理插件包。

@starry-abyss 人们现在制作的插件已经有潜力成为其他插件的“捆绑包”（用户或插件开发人员可以自己移动它们并将它们合并在一起）。 这里的目标是在编辑器实际代表用户执行可用性改进操作的类别之间存在功能差异，因此用户不必手动执行操作。

在这个程度上，我们已经有了“人工管理插件包”功能。 问题在于自动化繁琐的任务，同时在所有用例中保持可定制的高效生产力。

@Zylann

如果您按名称引用所有资产，那么这将是一个矛盾的混乱。 这更适合脚本，因为只有程序员必须为他们的类提供唯一的名称才能键入和使用它们（或者更少见的是资源）。

正确命名空间有什么大不了的吗？ 但它可能是 UID，只要它不依赖于路径，它对我来说并不重要。 甚至路径就像一个名字，因为资源被重新映射到它们的导入对应物......

@QbieShay

我仍然看到的唯一问题是插件和项目之间的不兼容。 你会如何解决这个问题？

如果这确实是一个问题，那么多脚本可能是最简单的解决方案。 它被删除主要是因为#8546 中的讨论，但我认为这可以毫不费力地解决。

我相信多个插件做同一件事的问题是虚拟的。 我们在assetlib中已经有了一个star系统，这个系统就是这个，一个常用和首选的指标。

它被忽略但在我看来是人们要求在核心引擎中添加的原因之一是：谁将为所有平台编译这个东西？

当然对于 gdscript 插件来说这不是问题，但对于 Cpp 插件来说这是一个大问题。

如果我们不解决这个问题，那么核心引擎内部的讨论就会转变为，哪个插件将被标记为官方，将插件标记为官方会破坏星级系统，因为人们正在只是给一个插件加注星标，因为它只是一个官方插件。

所以在我看来，我们必须先解决这个问题，我不知道如何解决。 例如，是否可以通过 Linux 为所有平台编译？ 如果是这样，那么我们可以使用 Ubuntu Imager 之类的东西： https ://www.maketecheasier.com/create-linux-distro/ 为插件制造商和 GDNative 用户创建一个已经设置好的 linux 环境。

例如，是否可以通过 Linux 为所有平台编译？ 如果是这样，那么我们可以使用 Ubuntu Imager 之类的东西： https ://www.maketecheasier.com/create-linux-distro/ 为插件制造商和 GDNative 用户创建一个已经设置好的 linux 环境。

不（macOS 和 iOS 构建只能真正从 macOS 编译），我不认为强迫人们启动实时 Linux 操作系统以便能够将 GDNative 库上传到资产库是一个好主意。

但是，可以使用 Travis CI 和 AppVeyor 为所有平台编译，您可以在公共 GitHub 存储库上免费设置它们。

如果我们不解决这个问题，那么核心引擎内部的讨论就会转变为，哪个插件将被标记为官方，将插件标记为官方会破坏星级系统，因为人们正在只是给一个插件加注星标，因为它只是一个官方插件。

好吧，星级系统从未实施过，所以你不能评价任何东西。 对于官方插件，并不是我们要选择一个并标记为官方的，我们是创建和维护它们的人。

基本东西的内置节点是编辑器最好的东西之一，如果要删除重要的节点或资源，项目管理器将需要模板来自动下载公共节点。

该提议也有风险将引擎打开另一个“始终在线”和“垃圾商店”引擎，如果这样做，许多其他事情将需要获得官方支持（错误修复）和可用性（版本更新）。

并且商店必须提供官方捆绑包以供离线使用（在编辑器中提供离线商店支持）。

如果完成，许多其他事情将需要获得官方支持（错误修复）和可用性（版本更新）。

TBH，在引擎或商店中维护东西几乎是一样的。 例如，车辆节点几乎没有错误报告，因为几乎没有人使用它们，甚至报告的错误也从未得到修复。 我发现外包这些节点要好得多，因为更容易让人们尝试修复问题而不必弄乱引擎源，因此有更多潜在的贡献者。

如果引擎节点有问题，人们会打开一个错误报告。 但如果它是一个带有 GDScript 代码的插件，那么人们很容易更改代码并对其进行测试，很可能会将修复程序回馈给社区。 我真的认为这是一种收获。 但前提是这些外部节点可以轻松集成，目前情况并非如此。 这包括良好的可见性和集成文档。

并且商店必须提供官方捆绑包以供离线使用（在编辑器中提供离线商店支持）。

是的，安装离线包也应该很容易。

@reduz

我不喜欢包管理器和系统范围安装附加组件的想法。 我认为这是一个糟糕的想法，从中没有任何意义。 我已经看到，即使对于 Unity 开发人员来说，在大型项目中更新资产版本并看到一切都崩溃并花费数天时间修复它是多么痛苦。

好的，但是为什么？ 您从中看到的实际限制和问题是什么？ 说“我不喜欢它”而不说为什么不会让人们相信这不是一个好主意； 除了提到的模糊原因之外，您至少应该给出一些解释。

好吧，但是为什么？ 您从中看到的实际限制和问题是什么？ 说“我不喜欢它”而不说为什么不会让人们相信这不是一个好主意； 除了提到的模糊原因之外，您至少应该给出一些解释。

假设系统上的全局“插件”注册表：

• 从在线插件系统下载插件 v1.3。 插件已安装到~/.godot或其他
• 版本在某种本地商店（文件、sqlite 等）中以~/my-project与我的项目相关联
• 我升级到 v1.4。 现在我的插件经理必须知道 1.3 没有被任何项目使用并清理它。 因此，管理器具有额外的功能来跟踪依赖关系以及哪些项目具有哪些依赖关系。 或者，没有人添加这个功能，所以我的本地机器被多个版本的同一个插件污染了
• 我决定将我的项目移动到~/big-project/game 。 现在我需要一种方法来更新插件注册表中对我的项目的引用。 我怎么做？ 我必须单独运行插件管理器吗？ Manager register new_proj_location ?
• 现在决定以requirements.txt python 样式在本地存储依赖项。 太好了，问题解决了。 除了我回到不知道哪些项目依赖于哪些全局包之外，我必须扫描系统以查找 godot 项目或注册每个项目以避免堆积版本。
• 好吧，我只是解决这个问题。 不时手动清理死包。 所以我正在使用 v1.5 为我的项目开发VehicleBodyAddon 。 呃，它为加速计算做了 F * M，但我想做 F * M * 5。让我快速修改代码......哎呀，我所有的其他项目都在运行该插件。
• 让我创建一个依赖于其他插件的新插件。 嗯，现在我需要注册我的新自定义插件依赖于现有的插件。 现在我需要扩展管理器，不仅可以从远程位置下载插件，还可以使用本地路径或 git 存储库或其他东西。

假设“供应商”插件：

• 下载插件到插件目录
• 更新覆盖目录中的插件

因此，管理器具有额外的功能来跟踪依赖关系以及哪些项目具有哪些依赖关系。 或者，没有人添加这个功能，所以我的本地机器被多个版本的同一个插件污染了

这正是其他 ruby​​ 的gem命令所做的，并且没有人在那里抱怨，因为他们有一个命令来清理旧版本的 gem（ruby 对插件的术语），而没有其他 gem 依赖于它们。 另外，为什么我们需要保留旧版本，如果我们正在更新，新版本可能无论如何都会大部分兼容？ 迫在眉睫，如果他们的程序完全依赖旧版本，用户可以再次获得旧版本，而这很可能不会。

我决定将我的项目移动到~/big-project/game 。 现在我需要一种方法来更新插件注册表中对我的项目的引用。

你没有，真的。 当附加组件经理可以...使用项目经理的项目列表并忽略任何不存在的路径时，您对此思考得太深了。 当然，这只是在它绝对需要跟踪项目及其要求的情况下，我不认为我们需要像几乎所有其他附加组件一样保留我们下载的任何附加组件的最新版本

现在决定以requirements.txt python 样式在本地存储依赖项。 太好了，问题解决了。 除了我回到不知道哪些项目依赖于哪些全局包之外，我必须扫描系统以查找 godot 项目或注册每个项目以避免堆积版本。

对于这种附加系统，Python 风格的 requirements.txt 将是一个很好的选择。 这样，如果项目确实需要一些旧版本（但同样，无论如何，您通常都会想要最新版本），我们可以指定它，如果插件管理器最终删除了那个旧版本，它可以知道稍后重新下载。

所以我正在使用 v1.5 为我的项目开发VehicleBodyAddon 。 呃，它为加速计算做了 F * M，但我想做 F * M * 5。让我快速修改代码......哎呀，我所有的其他项目都在运行该插件。

或者使用该项目本地的附加组件的副本？ 如果它确实需要仅适用于一个项目的更改，并且您真的不想在项目本地制作副本，只需制作一个扩展它并进行更改的 .gd 文件，然后使用那个新的 GD 文件代替了插件中的那个。

让我创建一个依赖于其他插件的新插件。 嗯，现在我需要注册我的新自定义插件依赖于现有的插件。 现在我需要扩展管理器，不仅可以从远程位置下载插件，还可以使用本地路径或 git 存储库或其他东西。

Git 子模块。 另一个 requirements.txt（就像 python 所做的那样）。 或者只是告诉用户它需要附加 X。这并不像你想象的那么难。 大多数 Godot 的用户并不愚蠢。 他们知道“这个附加组件需要：附加组件 X 核心、附加组件 Y、附加组件 Z”是什么意思。

@rminderhoud如果您的建议是根据需要在每个项目中存储项目插件的副本（因此它只有它需要的版本并且可以自由修改它而不会引起问题），那么也许我之前的建议可以处理核心围绕这个问题的问题？ 也就是说，在 EditorSettings 中创建一个实用程序，允许用户指定他们希望在创建新项目时自动安装的插件。

我们甚至可以创建一个类似的实用程序，允许人们形成指向 user:// 位置的硬链接以存储某些内容（特别是对于添加编辑器功能的插件）。 如果用户选择不负责任地这样做并搞砸他们的项目，那将是他们自己的决定。 在项目创建期间仅复制所有资产的默认方法可能非常有用。

添加一个新的插件系统不应该像现在这样与res://addons不兼容......这是因为：

实际系统很棒...

我重复：

实际系统很棒...

以前没有人抱怨过这一点。

我迟到了这个讨论，这里有一些关于提案的想法：

• 我个人还没有使用很多“资产”，并且觉得插件文件夹很容易使用。
• 我了解跨语言脚本继承会做什么以及它将解决什么问题（允许 C# 开发人员从 GDScript 脚本扩展以使用 C# 添加自定义功能）（不是我有任何使用它的愿望）但我不确定每个节点的多个脚本会做什么。 哦，所以不是从 GDScript 脚本扩展的 C# 脚本，而是可以调用它？ 哪个脚本将是主要脚本？ C# 代码将如何改变 GDScript 脚本的功能？
• 允许类名/命名空间 (TypeDB) 引用脚本可能很有用。 我对res://paths很好，但是从插件中的某些东西继承确实会产生很长的路径名。 不是一个主要问题，而是一个不错的问题 - 尽管对于跨语言继承，可能需要（或首选）。

我建议的资产管理更简单的设计是

• 有一个 dependencies.json（或者只是将数据保存到项目设置）很有用，这样我就知道我下载了哪个版本的资产以及是否有更新版本。 我认为这是需要的信息。
• 不，不要让资产能够定义依赖关系。 我不认为 Godot 资产会像 npm 模块那样相互依赖。 让资产开发人员在文档中说明它是否真的依赖于另一个资产并让用户手动安装。 这将简化事情，我们不必创建另一个依赖验证，即代码膨胀/需要维护的更多代码。
• 不，不要将资产保存在“全球”位置。 将它们保存在项目插件文件夹中已经很好了。 它允许他们对项目进行源代码控制并使其易于管理。 甚至 npm node_modules 也将项目的模块保存在项目中。
• 现在，改进资产浏览器，以便它可以列出已更新的已安装资产，并让您根据需要进行更新。
• 现在，能够为那些只是编辑器改进的插件提供“全局”插件确实很有意义。 所以普通插件仍然进入项目插件文件夹，但对于编辑器相关插件，您可以选择全局安装它们。 这也会将该代码移出项目的插件文件夹，因此它不会进入发布包。 （这类似于 npm install -g 用于开发工具）

因此，只需进行一些改进即可帮助跟踪更新的资产并能够在全球范围内安装编辑器插件。

假设我们不处理依赖项，我觉得可能存在用户可发现性/易用性的问题。 假设一个新用户想要尝试一个具有依赖关系的插件或“资产包”。 该包显示在资产库中，下载它，然后它无法工作，可能是一些“内部脚本无法加载”或类似的东西。 这很神秘。

• 每个敢于拥有至少一个依赖项的开发人员都必须设置样板代码以向用户展示它需要安装依赖项（即使该软件包只是该插件的演示！）
• 或者资产库至少表明了这一点？

还 +1 以轻松更新资产，无需在库中再次浏览它们。

确实如此，但是一旦用户看到它不起作用，他们将立即查找文档并查看他们需要安装其他资产。

在这一点上，这只是一个想象的问题。 在我看到的项目维护者的心态中，在我们发现它确实是一个问题之前不实施它是有意义的。 IE。 有许多资产依赖于其他资产，用户在使用它时遇到了很多麻烦。

不过，作为一个精心设计的解决方案，我同意拥有并可能鼓励开发基于/依赖于其他资产的资产生态系统是一件好事。

添加由于更新导致的资产之间的中断依赖关系（这在 3rd 方资产依赖引擎中很常见），同一个插件的许多版本应该保留在库中。

@eon-s 那么，类似于@bojidar-bg 的建议？

我认为这里讨论的更重要的问题是关于将事物包含在核心引擎中与将它们作为扩展或官方扩展的主题。

我个人非常喜欢能够自定义引擎并删除我实际未使用的所有内容的想法。 [例如，有人可以指出我将如何删除所有 3D 内容吗？ 我可以禁用我不使用的模块的编译吗？ 如何？]

问题是，当有人提出新的节点类型时，例如。 提到的弹簧臂或新课程，例如。 更好的 RNG 类，或者如果要删除一些现有的核心节点，例如。 车辆控制器……这些是 C++ 代码。 如果它们不包含在核心中，那么它们将如何作为扩展添加？ GDN 原生资产？ 那将是很多 dll 和共享库来管理/构建。

作为构建我自己的 godot 构建的人，我实际上更希望有一种方法将它们安装到我的 godot 构建文件夹中。 例如，如果它们是模块，我会将它们 git clone 到我的模块文件夹中，或者可能会有一个工具以某种方式自动化。 您可以从官方模块列表、官方扩展模块列表以及用户提交的模块列表中选择您希望使用的所有模块。 然后下载（git clone）它们，然后您可以继续构建您的自定义 Godot。 还可以查看哪些已更新并更新它们并稍后安装新的。 （这是指 C++ 代码。）

所以，我想在尝试从引擎中删除功能之前，我们首先需要一个更好、更灵活的资产库（资产安装、依赖项、版本控制等）和更简单的插件集成/扩展（编辑器工具、可编写脚本的自定义节点等） .

在这里回复@chanon 。

不，不要让资产能够定义依赖关系。 我不认为 Godot 资产会像 npm 模块那样相互依赖。

但为什么呢？ 到那时，为什么不让资产拥有这个依赖文件，因为它不会伤害任何东西？ 许多 npm 模块具有依赖关系的原因是因为它为每个人省去了麻烦，并重用了用户甚至可能已经安装的其他模块的代码。 Ruby gems、Python via pip也是如此，甚至 Linux 发行版上的包管理器也允许这样做。 我不明白为什么我们不应该仅仅因为它们可能不经常使用而允许对资产的依赖。

确实如此，但是一旦用户看到它不起作用，他们将立即查找文档并查看他们需要安装其他资产。

我不同意这种观点。 肯定会有很多人会首先查看文档，但我相当肯定，即使他们每次都必须在资产库中搜索每一个需要的资产，也会感到恼火。 但我认为还值得一提的是，总有一大群人似乎从来没有事先用谷歌搜索过问题，只会向资产作者抱怨他们的资产不工作。

我什至不同意删除功能的想法，因为它们可以在 GDScript 中完成。 简而言之，如果您要强迫大量用户下载或实施他们需要的工具/功能/等，这与 Godot 的“满足您所有需求的节点”的目标是背道而驰的。

事实上，大量节点属于@reduz包含在引擎中的第二个要求，仅仅是因为“自己很难做”是完全任意的。 对一些人来说可能很简单的事情对另一些人来说很难。

我认为拥有扩展的官方存储库并不违背“满足您所有需求的节点”。 仅仅因为它们没有集成在可执行下载中，并不意味着它们没有被提供。 此外，这个想法是涵盖了基本需求，并且扩展它们的能力可用于满足特定于游戏的需求。

开箱即用的 FPS 角色控制器固然不错，但对于不玩 FPS 游戏的每个人来说，它都毫无用处。 通过添加类似的东西，你基本上可以让每款游戏都包含许多他们不需要的功能，从而增加最终的二进制文件（这对移动和网络目标很重要）。 应该有一种方法可以从最终导出中删除未使用的东西，并且根据需要在外部提供它们是一种方法（至少部分）。

我同意难度是主观的。 仅当您已经了解实现它的基础知识时，才能轻松制作弹簧臂节点。 否则，您将花费相当长的时间进行研究，这违背了使用全功能引擎的目的。 更好的指标（尽管仍然有些主观）是“有多少低级”是该功能。 如果它需要向物理或视觉服务器添加功能，它可能应该在引擎中提供。 如果只是现有节点的扩展，或许可以外包。

我仍然认为提供官方节点下载和修整内核更有利。 有了这个，我们可以：

• 有一个用于编辑器和导出的小型可执行文件。
• 正式提供更多功能，以及更多特定于游戏的助手。
• 在不发布新引擎版本的情况下更新和修复扩展中的错误。 这意味着外包节点可以有更快的发布周期，并在修复错误后立即发布补丁。

但为此，我们仍然需要使插件成为比用户土地脚本更高级的公民。 使用扩展节点应该感觉像使用核心节点，同时仍然清楚它们不是。

有趣的讨论。 也有很多好的建议。

我必须首先说，我很欣赏最终二进制文件的紧凑性，并且很感激有一个考虑到这个目标的引擎。 我很高兴这里的中心愿景是积极对抗臃肿。 至少对我来说，我更喜欢只拥有手头工作所需的工具。

只是想对其中一些有趣的想法表示赞同。

尤其是关于越来越多的功能被导出到采用官方模块或插件等形式的东西中。

从那我想这就像一个核心，然后是一个模块库，默认情况下只安装了基本的模块。 也许许多人可以通过编辑器设置选择退出。 （我相信 Zylann 提到 2D 游戏不包括 3D。）除了默认设置之外，其他模块可以很容易地定位和包含。

尽管我想知道实施的困难，因为您必须考虑当人们可能想要删除项目中活跃的模块时会发生什么。 它可能必须警告用户在将其停用之前将其从这些场景/脚本中删除......或者它们是否会保留为项目中的墓碑项目，当模块重新添加时可以恢复？

实现它可能不是一件小事，但我喜欢能够尽可能选择所提供的功能，从而允许游戏导出只包含所需的内容。 对我来说，更多的控制听起来很有价值。

Vnen 关于在内置和脚本之间有一些特殊分类的模块的其他想法也是一个不错的想法。 它将允许一些其他类型的分区和编辑器行为和选项，而不会干扰现有设计的优点。

有人说是的，也有人反对让插件看起来更像 Godot 本身的想法，但它可以想象它可能是情境性的。 我也可以想象它是通过稍微拆分概念来完成的。 提供两者。

我也有兴趣了解如何将编辑器工具排除在最终版本之外。 我一直在努力尝试将这些东西分开，因为针对工具的错误和行为可能会潜入游戏本身。 如果您正在修改将要保存的数据，有时会产生破坏性。

同时，我发现使用工具脚本轻松修改编辑器内部的功能非常棒，所以更多的关注也会很棒。

不管怎样，大家继续努力吧。

只是另一个疯狂的想法：

也许有可能以某种方式将 GDNative C++ 自动转换为模块（理想情况下删除由 GDNative 创建的间接层）？ 那么它可能会让“一个静态可执行文件中的所有内容”方法的倡导者和“在不安装编译器的情况下剥离功能”方法的倡导者都满意

对于那些反对移除节点的人来说，如果被移除的节点是在GDScript中作为官方插件实现的，那不是比我们现在的更好吗？ 因为那时初学者实际上可以在脚本中达到顶峰，看看它是如何工作的。

我担心这会损害性能，因为 GDScript 不是很快。

2018 年 6 月 22 日星期五晚上 11:10，Alan North [email protected]
写道：

对于那些反对删除节点的人，如果删除的节点是
在 GDScript 中作为官方插件实现，岂不是更好
我们目前拥有什么？ 因为那时初学者实际上可以在里面达到顶峰
脚本看看它是如何工作的。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/19486#issuecomment-399628884 ,
或使线程静音
https://github.com/notifications/unsubscribe-auth/AEJES-DWkzuyItQDPbOZgsuN_lA345z7ks5t_b_NgaJpZM4UhqDC
.

@AlansCodeLog如果绝对必须将它们删除并制作成外部扩展，那么至少有一个 GDScript 版本会很好，这样用户就不需要重新编译引擎（如果是原始 C++ 文件）或安装 Mono（如果它被转换为 GDNative)。 但是，我最初的部分回复（参见官方扩展存储库的部分）涉及我的担忧，即如果用户不再记得有扩展回购，将它们带入扩展只会创造这种奇怪的市场（因为没有更好的词）包含他们需要的东西，无论官方版本有多正式或最新。 新的插件将进入资产库，其中包含“带有功能 X 的节点 X”、“带有功能 Y 的节点 X”等等（“节点 X”代表被制成扩展的节点）——造成混乱的插件都声称可以帮助车辆，但没有更多官方节点可能获得的级别或审查。

@LikeLakers2

但为什么呢？ 到那时，为什么不让资产拥有这个依赖文件，因为它不会伤害任何东西？

我不反对。 但是由于reduz似乎不喜欢它，我建议像我首先建议的那样做一个简单的改进。 看看它是如何进行的，然后可以在以后添加具有依赖关系的资产的能力。 只是一步一步的建议。

但是，我反对在项目文件夹之外的位置安装项目插件的想法，因为这会使事情变得更难管理。 只有“全局”编辑器插件应该在项目文件夹之外。

经过一番思考，实际上，如果要删除核心功能，并且人们希望在他们的所有项目中都可以访问这些核心功能 [这将是扩展]，那么能够将这些扩展安装在为他们提供版本管理的全球位置。 但是在这种情况下，也应该保留将扩展直接下载并安装到项目文件夹中的选项。 （同样，使用 -g 在本地或全局安装类似于 npm 选项）

就像上面说的 eon-s 一样，如果要将事物从核心引擎中移除并转化为资产，那么拥有更好的资产管理系统是有意义的。 否则，这将相当于引擎丢失了功能，因为用户将无法轻松发现已删除的功能。

我在想那个理想的场景

• 新用户和不编译引擎的人：在引擎下载页面上，他们可以选择下载核心引擎，还可以选择他们希望在引擎下载中包含哪些官方或推荐的扩展。 （请注意，如果无法将扩展名保存到全局文件夹，这将是不可能的。用户必须在创建项目后找到扩展名，这会损害可发现性。......但是，在理想的 [不可能] 世界中，网站会从现场选定的扩展/组件构建自定义 C++ 版本。）
• 编译引擎的人：管理扩展 C++ 代码下载和版本并将它们放在构建文件夹中的正确位置以便它们包含在引擎构建中的工具。

作为编译引擎的人，我希望我的扩展作为模块而不是 GDNative（或较慢的 GDScript）。 我正在想象我可以选择特定节点类型以包含或不包含在我的构建中的模块化级别，甚至删除所有 3D 内容。

如果 C++ 扩展都将是 GDNative，那么这会给扩展创建者带来必须为所有平台构建的负担——我认为这可能会阻止人们将其设置为可能有用的简单小扩展，因为这样做会让人觉得有点矫枉过正。做所有需要的发布它 - 并且不鼓励将功能分成许多小模块。 我也不喜欢将这么多 dll/共享库文件添加到输出项目中的事实。

另一方面，对于不编译引擎的人来说，GDNative 是添加 C++ 扩展的唯一解决方案。

所以就像 starry-abyss 建议的那样，如果 GDNative 可以自动适应一个普通的模块，那就太好了。

好的，所以我改变了我的立场，我喜欢一个无膨胀引擎的想法，它的功能与行业的强者处于同一联盟。

将所有额外的节点分开将带来很多优势，尤其是能够选择你想要什么和不想要什么。

以下是我对如何处理它的一些建议，

1. 首先，我们可以向资产库添加可以部分安装的资产的能力，在 git 中，它们可以通过标签或分支分隔。
   所以现在如果我只想要 2D 特征节点，我可以只下载它，但仍然只有一个地方可以查看更新。
2. 其次，我们可以添加为资产更新添加标签的功能，例如一些可以是核心更新某些功能和一些向后兼容性破坏。
   然后，资产管理器可以自动使用它来更新插件并询问您有关此事的最新信息。 就像它会告诉您，您已经等待核心更新，或者您的下一个更新将破坏向后兼容性。 你要不要更新。
3. 第三，允许拥有多个版本的资产，然后当版本太旧时，插件/资产的开发人员可以将其标记为过时，这将在您打开 Godot 时反映出来，它会询问您是否删除旧版本.
4. 最后一个插件请求其他插件的能力就像依赖一样，但它只会告诉你你需要这个插件来运行这个插件，如果你没有安装它。
   如果插件本身注意到插件无法再找到，请要求重新添加它或只显示错误消息。

使用这种方法，我们将不需要依赖管理器，但开发人员将负责这项工作。 如果插件过时并且正在使用过时的资产/插件，那么开发人员可以进行交谈，并且开发人员可以决定做什么。
他可能只是快速移植他的插件。 如果需要，或者在某些情况下，其他插件甚至可以删除过时的标签。

正如@chanon所说，我们需要将资产作为全局下载，然后可以像 Unity 那样导入到项目中。
并且应该允许比我们当前的实现更好的资产管理器，在安装插件过程中具有很大的灵活性。
我建议能够将插件添加为 GDNative 和模块，这会给插件开发者带来一些负担，但我认为这是唯一可以接受的解决方案，除非这里发生了根本性的变化。
但是我们仍然可以向 GDNative 添加一些功能来简化插件的创建。 就像能够同时为所有平台构建会更好。

关于因插件更新而导致依赖和资产中断的问题，
为什么不（如果我错过了已经提出这个建议的人，我深表歉意）

1. 让服务器保持上传的每个版本

2. 允许插件指定特定插件的特定版本

3. 尝试对插件使用健全的版本控制系统（Godot 似乎使用
   Major.Feature.BugFix 版本编号，我喜欢）

4. 最重要的是，不要自动更新插件吗？ （或者至少允许
   用户选择他们可以接受的更新类型，例如错误修复和
   功能更新，但没有重大更新）。

@Two-Tone 那为什么还要让整个事情变得臃肿。？？

我们进行了这个讨论，以使引擎和整个系统尽可能地膨胀，而不会有不必要的版本飞来飞去。

您允许用户决定更新是正确的，但默认情况下错误修复应该是自动的。 因为如果我有一百个插件，我不会一一检查它们是否有错误修复更新。
休息可以由用户决定，如果需要，我们可以设置禁用。

并且商店必须提供官方捆绑包以供离线使用（在编辑器中提供离线商店支持）。

我建议一个包含几十个 MB 的离线包，其中包含最重要的演示和应该很容易发现的最重要的附加组件。 官方下载页面上的一个较小的字体链接，比如旧 godot 版本的链接，会很棒。

可能，是的，但是在台式机似乎不使用任何低于 256BG SSD + 1TB HDD 的世界中，甚至手机的空间都从至少 16GB 开始，所有这些空间很可能会增加，是这样吗？坏的？

在便携式和负担得起的笔记本电脑领域，eMMC 活得很好，32GB 大小（不到 10GB 的可用空间）并不少见。

顺便说一句，在该类笔记本电脑上，我认为当前的 android 导出系统可以使用，而计划中的（https://github.com/godotengine/godot/issues/18865）则不行。 我确实理解新系统的优点，总的来说，我自己可能会投票支持它（当我看到这个问题时，已经没有竞争了），但我们应该意识到，我们正在因改变而失去一个重要的用例。

@swarnimarun可能存在误解。 当我在那条评论中说“系统”时，我指的是为插件提供服务的服务器，而不是引擎。 对不起，如果那是你绊倒的原因。

如果不是，那么我看不出尝试使用插件的依赖系统解决人们的问题与试图保持引擎膨胀是对立的。 保存在服务器上的插件以防万一有人需要它不会导致膨胀或维护开销，而且大多数插件都很小，以至于存储它们的成本不应该那么高。

@Two-Tone 是的，我以为你的意思是在电脑上。 但是在服务器上这很好，并且已经可以完成，因为 Github 允许即使在进行更改后也可以保存哈希，因此在当前系统中，即使您更新了 repo，您​​也必须更新资产页面中的哈希。

不仅github甚至gitlab等也允许。 如果还有其他人。 Git 支持将哈希值保存为提交 ID，因此事情按照它们完成的方式完成。

只是我的几分钱，很确定大部分内容之前已经说过，所以我怀疑我是否带来了任何新东西。

我不相信为了做插件而做插件。 我理解规模问题，但我们不再生活在 80 年代。 我们谈论的是 50Mb 或 55Mb 的引擎，而不是介于 50Mb 或 500Mb 之间的引擎，与任何严肃游戏的资产大小相比，要移动到插件中的功能的额外大小增加可以忽略不计。 如果我们付出的代价是更麻烦的集成，那是不值得的。

有很多地方插件更有意义，并且随着 GDNative 等架构的成熟，我们绝对应该问“作为插件是否更好”这个问题，在许多情况下，我认为答案是肯定的。 我喜欢插件的一件事是，它让作为开发人员的您在许多方面有更多的自由。 但也有限制。

我的 VR 体验避开了其中一些。 有一个原因需要更长的时间，然后我想在移动设备上启动并运行它。 由于需要以各种方式设置显示，尤其是在移动设备上，您必须更改核心的工作方式，并且证明很难在插件中捕获它。
到目前为止，OpenVR 和 OpenHMD 都是最简单的。 Oculus 我经历了一个被忽视的解决方法，但我对此很满意。
ARKit 必须是核心，它不能作为一个模块来解决，至少在我们当前的结构中不能解决（Apple 甚至不允许在 iOS 上使用动态库，所以也有）。
GearVR 和 Daydream 确实需要成为核心，对于 GearVR 来说这是不可能的，因为它使用专有库。
Hololens/Microsoft MR 我正在考虑是否可以将其作为平台选择，Microsoft 是这样看待它们的，因为应用程序应该在两者之间运行，并且作为全息应用程序安装在 Hololens 上。

现在 AR 和 VR 是很少有人会使用的小众功能，所以如果可能的话，它们是应该远离核心的类型，我非常同意这一观点。 但我不能对其他事情说同样的话。

我在某处看到了车身，是认真的吗？ 您将其保存到插件中的千字节代码？ 物理是我认为核心恕我直言应该完全支持的东西类型。 我宁愿在核心内部看到一整套完全集成的物理对象，然后必须在插件中寻找那些。 虽然类似于我们在 GDNative 中编写的 ARVRInterface 的接口方法可能会创建一个可靠的集成，但我仍然觉得我们只是让生活变得不必要的困难。

与地形编辑器组件相比，现在我认为有些东西非常适合基于插件。 根据您希望制作的游戏类型，有多种不同的方式来处理地形，因此在不同的插件之间进行选择是有意义的，并且能够独立于核心开发而在这些插件上进行开发，更是一个原因。

长话短说，在插件有意义的地方，支持插件，但不要过火。

可能值得变成插件的节点是由控制节点（复合节点）制作的控制节点，只留下简单的节点来构建其他节点。

像 Vehicle 这样具有复杂逻辑的节点，甚至像 Position 那样简单但有用的节点，在核心上都很好。

IMO，这些都不应该从引擎中移除。 控制节点、物理节点（如车辆），甚至当前不存在的地形支持：

我使用 Godot 是因为它是一个相当独立的集成应用程序。
如果将来我需要下载 Godot，然后寻找车辆、控制节点、地形支持、着色器编辑器、体面的 Navmesh 插件等等 -使用当前插件和 AssetLib 系统- 不，谢谢。

如果我们这样做，插件基础设施和 AssetLib 都需要进行可用性检查。

顺便说一句，我对 UE4 的大安装量的困扰要小于它没有内置对车辆、地形或 UI 的支持——它拥有所有这些。

我不确定已经说明了多少，像这样的大线程很难理解，但无论如何：

我认为我们应该专注于开箱即用的最佳体验。 必须进入资产库，即使是“官方认可”的插件也是相当笨拙的。

IMO，出口规模不应使引擎的可用性变差。 如果我们需要减少导出大小，则制作一些功能来禁用引擎的某些部分，例如导出时的 3D。 尤其是因为我个人不重视移动平台，尤其是网络平台，看到他们在这样的讨论中阻碍引擎让我很痛苦。 （我可以看到他们的需求，不要误会我的意思，虽然螺旋网）

地狱，如果我们担心编辑器的下载大小，那么应该有单独的“包含电池”和“最小”编辑器下载。 如何实现分离还有待商榷，但无论如何都应该很好地整合。

我还没有彻底阅读整个讨论，但我想稍微重新调整一下：我们不关心大小。 当然，在某些平台上保持较小的导出大小很重要，但这并不是在引擎中实现功能时的决定因素。 如前所述，如果需要使某些功能有条件以允许较小的导出大小，那是微不足道的。 引擎本身的下载大小无关紧要。

现在已经解决了，鼓励我们考虑将一些东西（“一些”待确定）排除在引擎之外的主要因素是：

• 技术债。 所有代码都需要维护。 像我们自 2014 年以来使用的损坏的 VehicleBody 并不是特别有用，因为它对于真正的游戏来说还不够好。 最近使用 Bullet 对其进行了改进，因此它变得越来越好，但在过去的 4 年里，它实际上是死代码和不必要的维护负担。
• 通用性：Godot 是一个引擎，可以让你做任何类型的游戏，它提供的功能应该能让你做任何类型的游戏。 这并不意味着它应该是独占的（在大多数游戏中您不需要同时使用 2D 和 3D），但功能应该满足大多数用户的共同需求。 这意味着我们提供的功能应该是低级的，而游戏特定的高级功能大多数时候最好由外部提供。
• 灵活性：在核心之外维护高级特性可以更快地迭代过程来改进它们，如果需要的话，分叉它们等。

如果我们这样做，插件基础设施和 AssetLib 都需要进行可用性检查。

嗯，这就是这个问题存在的理由，不是吗？ :) 重点是我们需要进行可用性大修，以实现更好的工作流程，而不是将所有极端情况捆绑在核心引擎中。

嗯......如果有人需要想法来启动除了所谓的 VehicleBody 之外的外部功能，我想记住从 godot 2 到 3 丢失的一些节点和类：ParticlesAttractor2D（节点）和 EventStreamChibi（这个类非常适合外部资产），我知道particleattractor与实际的粒子系统不兼容，但是......以外部资产的形式恢复godot丢失的功能怎么样（Ej，旧粒子系统与新粒子系统共存......）。 也许有人想在单独的存储库中维护该代码......

@Ranoller新系统总是删除旧东西，这是不可避免的。
CPU 粒子应该与 GLES2 一起返回（因为不支持 CPU 粒子），但是在 CPU 上而不在 GPU 上具有吸引子并不好。
EventStreamChibi 是一个模块，我猜新的音频系统如果变得更灵活，可以更好地支持跟踪文件。

我不认为即使我们关心可维护性，我们也应该把东西分开。
我们可以要求人们通过在一个特殊线程上发布关于它的内容来帮助解决变老的问题，然后人们可以更新功能。
随着 Godot 用户群的巨大增长，我敢肯定，我们会发现很多人愿意更新事物并致力于处理引擎部分缺少的旧功能或基本功能，例如更多关节。

如果您认为让人们处理单独的代码文件更容易，那么大多数人只是不知道这些文件是错误的，因为它永远不会获得相同的曝光，资产管理器需要工作是的，但是将功能作为插件并不能很好地工作.
我见过一些人从 Unity 切换到 Godot，因为它集成得非常好，并且不提供作为插件的基本功能。
Unity 意识到开始致力于让事情更加集成，并将插件开发人员添加到 Unity 开发团队中。

如果我们需要下载一个 30MB 的引擎，然后浪费时间下载单独的功能作为插件，我可能会忘记添加到我的项目中，那么我可能一开始就不会使用它们。 这对初学者来说是个问题。

关于技术债务，这是每个项目（FOSS 或商业项目）最终都必须处理的问题。 事实是，一些开发人员最终会离开，并且某个区域不再受到太多关注（因此必须将其置于“维护”模式，直到有人感兴趣为止）。 正如我所提到的，这甚至发生在大型商​​业应用程序中。 所以它不可避免地会发生在 Godot 身上，无论引擎得到多少微调。

该领域的最佳解决方案是建立一个鼓励人们开始为源代码做出贡献的开发场景（从所有志愿者开发来看，Godot 场景一直做得很好，但必须通过诸如确保补丁贡献者不会等待很长时间才能看到评论）。 但是，如果可能的话，应该避免因为开发人员离开而删除功能（因为不断波动的功能列表将是说服人们_不使用_Godot 的好方法）。 相反，特征删除应该主要发生，因为它正在被更好的东西所取代。

但是，如果可能的话，应该避免因为开发人员离开而删除功能（因为不断波动的功能列表将是说服人们根本不使用 Godot 的好方法）。 相反，特征删除应该主要发生，因为它正在被更好的东西所取代。

再一次，讨论的方向是错误的，所以我会试着把它带回到正确的轨道上。 这个主题不是关于删除东西，而是关于防止添加我们最终可能想要删除的新东西。 因为添加东西很容易，但是我们不能在不破坏兼容性的情况下删除它。

随着 Godot 的发展，越来越多的新贡献者带来了可能不符合我们希望引擎遵循的架构或设计的附加功能。 审查所有这些更改需要花费大量时间，更何况要确定它们是否符合我们的要求。 由新贡献者合并这些新功能将导致引擎维护者不太了解或最终可能不会完全认可的代码，并且原始贡献者通常可能不会坚持重构它并确保它符合我们想要的（参见例如 Tween 节点，这是一个很棒的功能，但设计低于标准，并且原作者不再存在，所以我们需要重新考虑和重写它，在途中破坏兼容性）。

因此， @reduz提案的全部要点是，新贡献者希望将不断增加的功能放入核心引擎中，大多数情况下，它们更适合作为资产库中的资产。 这个问题的重点是如何确保这个工作流程尽可能顺利。

我们不是在尝试缩小 Godot 的代码库，而是在考虑如何保护我们不让它爆炸和失控。 （因为具有大 PR 的一次性贡献者比对完整代码库和我们对引擎未来的愿景有透彻了解的引擎维护者要频繁得多）。

因此， @reduz提案的全部要点是，新贡献者希望将不断增加的功能放入核心引擎中，大多数情况下，它们更适合作为资产库中的资产。 这个问题的重点是如何确保这个工作流程尽可能顺利。

我不得不问，除了将问题向后退一步之外，将这些变成资产库中的资产还能做什么？ 您将从与不再维护的 Godot 捆绑的代码转换为不再维护的 Godot 资产中的代码。 无论哪种方式，最初的贡献者可能会在某个时候停止维护它，并且最终会再次被破坏。

@LikeLakers2好吧，它的目的是为引擎添加新贡献创造一个顺畅的途径（因为现在大多数与资产相关的内容都被拒绝了）。 如果引擎的某些方面没有得到维护，那么它不应该首先与引擎捆绑在一起，因为此时它的纯粹膨胀。 这种性质的东西特别适合作为外部包含/更新的插件。

如果将来我需要下载 Godot，然后寻找车辆、控制节点、地形支持、着色器编辑器、体面的 Navmesh 插件等等 - 使用当前插件和 AssetLib 系统 - 不，谢谢。

确切地。 AssetLib/附加组件现在通常不能很好地解决这个问题，因此为什么谈话往往会偏离这些。 我认为现在没有人想把东西拿出来，但正如已经提到的那样，重点是不要添加太多新东西。

我不得不问，除了将问题向后退一步之外，将这些变成资产库中的资产还能做什么？ 您将从与不再维护的 Godot 捆绑的代码转换为不再维护的 Godot 资产中的代码。 无论哪种方式，最初的贡献者可能会在某个时候停止维护它，并且最终会再次被破坏。

好吧，我假设如果可以将它们与引擎分开管理会更容易。 Blender 会做这样的事情。 他们有“官方”（不是真正官方的，只是预先包含的）附加组件，但是他们的代码保存在一个单独的 git 子模块中，并且当提交它们的人不再维护它们时（我认为你必须重新提交随着每个大版本），它们被丢弃。 虽然老实说我不太喜欢这种方法，但我希望他们只有一个内置的资产浏览器来处理 90% 的东西，然后直接集成其余的东西（比如出口商）。

我认为这个想法是引擎只包含基本的构建块，然后像车辆节点这样的东西可以是官方的附加组件，然后所有其他的大并且可以以不同的方式实现的东西应该只是常规的附加组件， 正确的？

我不明白官方附加组件将如何实施。 我认为目前我们无法编写看起来像是内置的自定义节点，对，他们必须有一个脚本？ 或者是否可以使用 c++ 模块或其他东西（这里是 c++ noob）。

最终我们也会遇到如何拥有依赖于分离的官方节点的附加组件的问题。 如果没有某种依赖系统，这听起来就像地狱。

派对迟到了，但考虑到我当前项目的规模，我发现自己为 Godot 3 开发了很多插件，并且在项目完成之前看到自己开发了更多。 对于每个插件，我尝试以与游戏无关的方式开发尽可能多的插件，并在 MIT 许可下开源它们供其他人使用。 我不会撒谎。 当前的插件系统在宏伟的计划中确实并没有那么糟糕......但是，有一些缺失的部分使其在许多情况下几乎无用。 然而，在我开始讨论这些之前，我想对@karroffel的想法说几句话。

首先，感谢您将这个问题放在一起。 我认为进行这次讨论很重要——尤其是在短期内。 也就是说，我确实认为您在 OP 中提出的每个讨论点大多是正交的，只有切向重叠。 我认为我们可以在这里迭代解决方案，而不必一次性解决所有问题。

这让我对当前的插件系统产生了我的_personal_疑虑，我认为这将是从一个真正定期开发插件的人那里获得一个更美好世界的两个非常好的起点：

当前插件系统的最大问题是缺乏依赖管理。

这已经被大量讨论过，但是大多数建议都相当笨拙，并且与当前系统不太兼容。 现在，我还没有熟悉assetlib 模块的代码库，但我认为这个部门_应该_很容易取胜。 目前，Github 上的第 3 部分插件存储库遵循以下文件夹结构：

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

我的建议是扩展 plugin.cfg 模式并添加简单的依赖版本列表以及选项提交哈希（或分支/标签名称）来使用的能力。 像下面这样的东西会起作用：

[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"

然后，当资产库开始安装资产时，它首先像当前一样将项目下载到 addons 目录，然后下载每个依赖项（使用定义的正确哈希或分支）并将其也放入 addons 目录. 作为第一步，依赖冲突可以被忽略或让用户选择使用哪个。 这不是一个理想的解决方案，但我认为它在大多数情况下都可以工作，并且至少可以让我们坚持下去，直到对资产库进行更多涉及的大修。 （除非有人能想出一个简单的方法来处理他们头脑中的依赖冲突）。

作为一个真实世界的例子，
我有一个 godot 行为树的资产。 该系统的一部分是一个类似 UE4 的 Blackboard 节点，用于存储要跨节点共享的任意全局或节点本地数据。 这在 BT 系统中用于在行为节点之间共享状态。 这一切都很好而且很花哨，但是我目前正在开发一个对话系统和随附的工具，并且该系统的一部分需要某种变量数据库来用于条件。 我也很想将 BT 系统中的黑板组件重用于对话系统。 事实上，Blackboard 组件几乎是通用的，并且全局数据在 gamedev 中是一个相当常见的习惯用法，所以即使它本身也可能是一个相当有用的插件，因为它基本上在每个项目中都会重新实现.

通过适当的依赖系统，我可以将 Blackboard 组件分解为它自己的插件，然后在所有 BT 插件、对话系统插件以及我对它的任何其他游戏特定用途中重用这个组件。 看我的意思？

对多脚本节点的需求

这已经是本期的另一个热门话题，老实说，在不改变 Godot 使用方式的基本意识形态的情况下，我没有一个很好的方法来解决这个问题。 这可能会也可能不会，但是是的……无论如何，这对于插件_authors_来说并不是一个问题，对于插件_users_（通常是同一个人）来说，这并不是什么大问题。

最后，如果我们能解决这两个问题，我认为我们将达到 90%。 在我看来，另外 10% 并不是什么大不了的事，可能应该从彻底改革资产的基本架构的角度来处理，在我看来，这可以在煎完更大的鱼后等待。

如果没有异议，我可能会在未来几天尝试在assetlib代码中实现我关于依赖管理的建议

依赖管理对我来说听起来很酷。 :笑脸:

我唯一不同意的是拥有依赖的版本
是可选列表。 这将导致reduz提到的问题
发生在其他引擎的插件系统中。

除非有人能想出一个简单的方法来处理他们头脑中的依赖冲突

我认为解决方案将取决于插件如何调用代码
一个不同的插件。 如果我们设置它以便插件的脚本执行
extends "dep2/folder/script.gd" ，在安装时我们可以改变dep2
到dep2-v3.1.2 。 对于哈希，我们可以只使用前 5 位数字（除非
我们想要名称至少为 42 个字符长的文件夹）。 在5
数字碰撞的机会非常小。

我现在有点累，所以我可能会错过一些东西，但我没有看到
任何问题。

@jonbonazza如果你这样做，请尽量不要在其中硬编码 Git 的使用。 虽然这听起来似乎是理所当然的，但有些人可能更喜欢其他 VCS 系统（或根本不使用 VCS），所以也许这应该是在资产库方面处理的一个细节。
另外，我想知道我们是否考虑做一些事情来让插件更容易成为项目中的 VCS 子存储库？ 在某个时候提到过，但我不记得是否有协议。

是的，我认为只有资产的 id 和版本就足够了。

指定 Git repository/branch/tag/hash 可能是指定依赖项的一种可选方式，但主要方式应该是通过资产 id。

我不确定资产库是否具有唯一的人类可读 id（slug）。 如果不是，它应该。 例如，npm 模块有一个文本模块名称/ID，您在安装它们时会使用它。

依赖规范可能看起来像

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

@Two-Tone 我尽量不要对此感到太疯狂。 只是想要一些简单的东西来阻止我们，直到决定更好的方法。

@Zylann我可能会使用当前在资产库中使用的相同方法——从 github 下载和提取 zip 文件。

@chanon资产库直接与 github 连接，因此我们对版本的唯一标识是提交哈希、分支和标记。

哪个部分太疯狂了？ 强制依赖版本或我的解决方案
依赖冲突？ 一个在大多数有的地方都是标准的
依赖管理，另一个是对文本和文件夹的简单编辑
命名。 我不认为这两件事都是疯狂的。

2018 年 7 月 3 日，星期二，上午 11:23 Jon Bonazza [email protected]写道：

@Two-Tone https://github.com/Two-Tone我尽量不要太疯狂
有了这个。 只是想要一些简单的东西来支撑我们直到更好
方法决定了。

@Zylann https://github.com/Zylann我可能会使用相同的方法
当前在资产库中使用的 - 下载和解压缩 zip
来自 github 的文件。

@chanon https://github.com/chanon资产库与 github 一起使用
直接所以我们对版本的唯一标识是提交哈希，
分支和标签。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/19486#issuecomment-402214905 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AEJES-_IJBjvj3ImvZnqdu-cIAunCp2gks5uC5qIgaJpZM4UhqDC
.

@Two-Tone 抱歉，但“太疯狂”我的意思是“太复杂”，因为这应该是快速解决问题的方法。 我同意，从长远来看，适当的冲突解决是必要的，但我希望我们可以在没有它的情况下侥幸逃脱。

另一种选择是一起放弃assetlib，直接将deps克隆到项目中，尽管由于当前事实上的插件项目结构植根于addons目录，这不会真正起作用。 我们需要项目根目录更深一层（即不包括插件目录并以插件名称为根）。 老实说，无论如何，我认为这将是一个可喜的变化，因为那时您可以使用 git 子模块进行依赖。

@jonbonazza我明白了。 您的解决方案无需修改资源库即可立即实施和工作。 然后我同意这是一个很好的第一步。 （并不是说我是一个有任何权威的核心维护者......只是我认为这是一个很好的第一步。）

我认为如果资产库数据库添加了文本标识符（slug）和版本信息，那么可以像我上面的示例一样添加。

您可以将 git 子模块用于依赖项。

@jonbonazza这就是我的后一个问题再次出现的地方，因为似乎无法将子模块与插件 repro 一起使用，因为该 repo 需要包含完整的文件层次结构才能适合下载，从而强制.git文件夹位于同一位置......但即使这是一件事，请记住它会迫使人们通过 Git 提供他们所有的东西。

确切地说是@chanon 。 它只需要在几个文件中添加少量附加代码。 老实说，可能会开发一个插件来为您执行此操作，而不是将其构建到资产库中

@Zylann是的，这就是我在关于子模块的评论中得到的。 由于当前对项目结构的限制，目前不可能，但在这方面更改资产库 tob 更加灵活将是微不足道的。

编辑：它也可以以向后兼容的方式完成。

实际上，我不久前就项目结构提出了一个建议。 这实际上是我对插件现在如何工作的主要抱怨。 没有很好的方法来打包它们。 参见#18131。 这真的应该首先改变，imo，在任何事情之前，越早越好，所以我们有更少的人不得不转换他们的插件。

它有什么复杂的？ 一个是可以强制执行的要求
一个简单的检查，另一个是简单的匹配和替换或
附加/前置。 这比实际添加依赖项支持要简单。

2018 年 7 月 3 日，星期二，下午 12:11 Jon Bonazza [email protected]写道：

@Two-Tone https://github.com/Two-Tone抱歉，我的意思是“太疯狂了”
“太复杂”，因为这应该是快速解决问题的方法。
我同意从长远来看，适当的冲突解决是必要的，但是
我希望我们可以在没有它的情况下暂时离开。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/19486#issuecomment-402229111 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AEJES7c8ziwhXZirsTsLY0zWfI-jrBzmks5uC6XUgaJpZM4UhqDC
.

@Two-Tone 您不能只重命名文件夹，因为插件代码中的脚本通常直接使用插件的路径。 例如

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

@jonbonazza我要补充一点，不仅仅是脚本可以做到这一点，任何资源都引用了另一个资源。

然后让附加文件夹结构像我说的但强制性的，然后在
安装时只需使用 String 类的查找和替换功能
每个脚本都有要查找的

'扩展“ res://addonname/ '

并将其替换为

'扩展 " res://addonname-versionnumber/ '

这些不是代码中的难题。 多亏了 c++，它们真的很简单。
这些大多只是用户问题，以确保这些问题得到解决
我们必须授权一些东西。 如果他们上传插件并且用户发现
它完全崩溃了，因为开发人员并没有难以置信地遵循这些
简单的规则，那就是插件开发者。

我们必须从一开始就制定规则，所以我们也不妨
包括这些或其中的某种形式，以确保我们做对了
从一开始就。

2018 年 7 月 4 日，星期三，下午 12:48，Marc [email protected]写道：

@jonbonazza https://github.com/jonbonazza我要补充，不仅仅是
执行此操作的脚本，但任何引用另一个资产的资产。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/19486#issuecomment-402533781 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AEJESwoMKvVVXcllrQ4YQQO852oZ1v7rks5uDP_SgaJpZM4UhqDC
.

我猜如果插件在更新后破坏了兼容性，他们应该提供弃用回退，或者按照@Two-Tone 所说的那样，通过重命名插件或其子文件夹故意破坏路径（尽管这是最坏的情况，因为这不是一个好的情况）。 引擎本身就是这样，其他人也是如此。 编写插件带有完全不同的思维方式，您不认识的其他人/插件将依赖它。

这解决的不是依赖问题，而是依赖冲突的解决方案。 一个插件可能依赖于不同插件的版本 1，而另一个插件可能依赖于版本 2，如果没有这个或类似的东西，我们要么会发生冲突，要么必须限制用户使用插件有冲突的依赖关系。

防止更新破坏兼容性的解决方案是强制每个更新必须具有唯一的版本号。 但是，这可能会开始落入“过于复杂”的类别，因为您必须解析plugin.cfg然后询问资产服务器是否已经存在具有该名称和版本号的插件。 如果有，抛出一个错误。 如果没有，一切都应该没问题。

而且我不确定您是在谈论插件中的脚本还是用户编写的脚本，但无论哪种方式，我都同意这有点笨拙，但应该不是那么困难的问题。

我能想到的唯一解决方案是扩展 gdscript 以便用户可以在脚本中指定他们正在使用的插件的版本，然后从那时起他们只需执行extends "res://addonname/etc并让引擎本身处理使用正确的路径。 但是，这肯定属于@jonbonazza提到的“过于复杂”的问题。 但短期内可以跳过。

还有其他问题需要最终解决。 例如，用户应该知道正在安装哪些依赖项，如何处理内部文件系统浏览器中因解决依赖项冲突问题而产生的多个文件夹，我们如何处理作为依赖项但有更新的插件（我们是否应用与手动安装插件相同的设置？例如，自动安装错误修复或仅在主插件更新其依赖项列表时安装更新），还有更多我确定。

我完全可以理解为什么@reduz觉得依赖管理并不重要。 有太多变量需要考虑和解决，以便值得将其包含在 Godot 中，否则我们最终会得到一个不比其他引擎使用的系统更好的系统。

老实说，我认为短期解决方案的最佳行动方案是更改资产库以支持（尽管不是_require_，因为向后兼容）为addons目录下一层的项目提供服务的能力。 例如

godot-tools.level-streamer/
    project.cfg

代替

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

这样，我们可以在插件的描述中指定它需要其他插件。

如果我们愿意，它还允许我们在项目中轻松使用 gitsubmodules 来代替插件。

为 deps 做这些（例如dep/ ）然后在根目录或用户定义的文件夹中手动安装插件怎么样？ 这样依赖关系就不会弄乱根目录，插件可以在其中一个或？

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

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

@Two-Tone 但是，如果您的依赖项有依赖项怎么办？ deps 文件夹不应该是插件本身的子文件夹，这样您就可以根据需要任意深入吗？

我觉得整个依赖问题都被过度考虑了。 也许我们应该想出一些简单的系统，并就每个系统进行讨论或投票？ 我不认为这次谈话会以目前的方式结束。

话虽如此...

@willnationsdev这可以工作，但如果许多插件依赖于相同的依赖项，那么你有多个该依赖项的副本，可能只需要像......两个。

是的，依赖管理不是一件简单的事情。 否则npm不需要像现在这样复杂，也不需要创建yarn 。

我不认为将依赖项作为资产的子文件夹是一个好主意，因为它会导致一条非常复杂的路径。 当两个或更多资产具有相同的依赖关系并且需要某种重复数据删除时，将会出现这种情况。 此外，我认为游戏开发人员最好确切地查看项目具有哪些依赖项，而不是必须通过子文件夹的子文件夹来找出正在使用和/或复制 n 次的依赖项，因为它是一个常见的依赖项。

例如，在 node.js web dev 中，忽略 node_modules 中的内容是可以的，只要它可以工作，因为它只会部署在服务器上。 对于一个游戏，你会将所有代码/资产打包到一个最终的应用程序包中，并且重复 n 次相同的依赖项是非常糟糕的。

这些问题是为什么我最初的建议说不要让资产定义依赖项，而只是有一种方法可以列出项目的依赖项，并让用户手动安装资产的任何依赖项：
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

如果我们有资产定义依赖项，那么我认为它们都应该安装在同一级别（在res://addons文件夹中）。 对于依赖版本冲突（两个资产依赖于同一个资产但它的不同版本），我认为一个简单的解决方案是最好的，比如总是使用较新的版本。

另一方面，如果我们真的想通过允许安装同一资产的多个版本来实现具有重复数据删除和版本冲突解决的依赖管理，那也可以！ 如果它真的很健壮，那么它将能够长期支持资产生态系统的扩展。 不知何故，我不喜欢在我的游戏项目中拥有同一资产的多个版本的想法。 并且花了npm这么多版本，直到他们做对了（尽管我仍然更喜欢yarn ）所以我认为这个任务不应该被低估。

我不认为将依赖项作为资产的子文件夹是一个好主意，因为它会导致一条非常复杂的路径。
如果我们有资产定义依赖项，那么我认为它们应该都安装在同一级别（在res://addons文件夹中

我同意这一点。 我还希望插件在标准位置的项目中存在一次，而不是与其他各种来源和各种文件夹中所需的版本一样多。 依赖是一回事，但我们也可以找到一个中间立场，而不是最大限度地细化，以保持事情相对简单。

这些问题是为什么我最初的建议是不要让资产定义依赖项，而只是有一种方法可以列出项目的依赖项，并让用户手动安装资产的任何依赖项。

对我来说，如果资产定义了依赖项，那么主要是为了让用户比在安装之前查看文档或查看所有插件更快地获得信息。 最终，可以选择同时下载依赖项，但只是为了方便（尤其是从头开始安装时，无论如何都需要安装这些依赖项）。 我们可能也不需要解决依赖冲突，至少安装工具可以通知用户它是否可以检测到一个。

我觉得整个依赖问题都被过度考虑了

@LikeLakers2正确的依赖管理和避免冲突是一个重要而困难的问题。 正因为如此，它被讨论了这么多

我不认为这次谈话会以目前的方式结束。

试图在不弄清楚依赖关系带来的所有问题的情况下推动这一点将是一个非常糟糕的主意，只会导致更多问题。 这是一个难题，需要时间。

对于依赖版本冲突（两个资产依赖于同一个资产但不同版本）我认为一个简单的解决方案是最好的

@chanon我的想法很简单。 命名文件夹和更改文本文档中的相关文件路径有什么复杂之处？ 这对用户来说是一次性成本，让您清楚地知道您安装了什么版本，并且相当容易编写。

比如总是选择较新的版本

这将导致插件在没有警告的情况下中断，因为它们的依赖项更新并改变了它们的工作方式。 EG Plugin 1 和 2 都依赖于 Dep 1，但版本不同。 插件 2 依赖于当前的最新版本，但插件 1 依赖于行为与最新版本不同的旧版本。 插件 1 不再按预期工作或存在未附带的错误。

我们可能也不需要解决依赖冲突，至少安装工具可以通知用户它是否可以检测到一个。

@Zylann然后我们遇到用户无法安装 x 插件的问题，因为 y 使用相同依赖项的不同版本。 这不会被用户视为一件好事

我同意@willnationsdev和@LikeLakers2

我觉得整个依赖问题都被过度考虑了。 也许我们应该想出一些简单的系统，并就每个系统进行讨论或投票？ 我不认为这次谈话会以目前的方式结束。

自行车脱落太多。 这是一个游戏引擎，而不是一个游戏引擎插件交付平台。 只是每个插件目录中的供应商依赖关系，就这样结束了。 没有关于版本冲突或管理的压力，也没有以效率低下为代价的 w/e。 如果插件的用户关心性能，那么他们应该考虑真正的性能优化，如 GDNative 或模块。 我也无法想象为什么任何插件都会有一个深度依赖图。 我可以看到一个插件依赖于另一个插件的唯一原因是它是否以某种方式扩展了它： SweetFpsController -> SweetFpsController w/ flying 。 在这种情况下，我会说这取决于两个项目或其用户来协调他们的耦合，而不是把责任交给引擎。

@Two-Tone 如果插件 A 需要 X 的版本 1 而插件 B 需要 X 的版本 2，我会说 Godot 不应该尝试神奇地修复它。 以下是对此的简单解决方案：

• 通常，X 的第 2 版应该与第 1 版向后兼容，这就是保持简单的方式（记得我在开发插件时提到的心态）。
• 如果您不能使用最新版本的 X，请等待插件 A 支持它并下载以前的版本（我们需要资产库 API 来处理获取不同版本，而不仅仅是最新版本，这应该不难）。 就像模组一样，它不一定是完美的。
• X 的插件制造商将其作为不同的插件上传（因为 API 破坏了兼容性），就像我们在 Godot 3 发布时必须这样做一样。 因此，您将拥有两次相同的插件，但这很好，因为它们差异太大而不能真正成为相同的插件，并且依赖于它的东西也可以工作。 它甚至可以只是插件开发人员重命名的文件夹，甚至不需要有两个资产库条目。

在最坏的情况下，您将不得不手动完成这项工作（最终与插件制造商的 PR 兼容性）。

如果不是这些，那将涉及每次安装具有不同路径的两个版本（在每次更新时拧紧所有引用），或者将核心更改添加到引擎以改变路径的工作方式（复杂）。
我认为，如果我们能够获得简单的依赖管理，那已经很不错了，因为它基本上会使用 Godot 已经拥有的功能和结构（因此实现起来也很简单），并自动执行用户当前拥有的事情无论如何都要手动做。

我不认为依赖管理应该始终有效并且是引擎的全部责任（如 npm），因为那将是很多工作。 我认为这主要是为了方便您目前必须使用现有功能手动完成的事情，并且插件制造商可以基于这个简单的系统发布他们的工作。
如果有人设法很好地实现了一个比这更进一步的系统，那么它可以在以后完成，因为我上面描述的之前是可行的，而且主要是对资产库和编辑器的简单改进。

@Zylann这些选项中的任何一个比我建议的更好吗？ 搜索文本并将其附加到特定字符串并没有什么神奇之处。

选项 1 迫使开发人员尝试确保他们的版本更新不会破坏任何其他依赖它的插件，这给他们增加了很多额外的工作。 谁想为这样的东西开发插件？

选项 2 强制用户不要使用他们想要的插件，因为他们必须等待插件更新，如果它仍在积极开发中，或者根本不使用它。

选项 3 再次使插件开发人员变得更加困难。

具有不同路径的两个版本不是一个难题。 如果它们更新，请检查哪些安装包将它们作为依赖项，在这些包的所有脚本上重新运行搜索和替换（考虑旧版本号），然后最后解压缩新版本。

我觉得人们正试图让它变得比它需要的更复杂。

适当的依赖管理和避免冲突是一个重要而困难的问题。 正因为如此，它被讨论了这么多

@Two-Tone 我的意思是你在这个问题上想得太难了，即使它是一个难题。 很多对话（包括我的回复，诚然，所以请原谅我，因为这听起来很虚伪）都是关于所提出的想法有什么问题，而不是关于可以做些什么来改变它并使它变得更好计划。 所提出的想法不仅有缺点，对吗？ 似乎每个人都想要他们的方式，也只想要他们的方式，这无济于事。

试图在不弄清楚依赖关系带来的所有问题的情况下推动这一点将是一个非常糟糕的主意，只会导致更多问题。 这是一个难题，需要时间。

我建议提出一些简单的想法，暗示我们会解决它们，然后在我们觉得我们有一个好的系统时再决定。 我不认为我必须明确指出这一点，但你去了。

我对这次谈话持续了多久没有任何进展感到有点恼火。 严重地。

不同路径的两个版本不是难题

可能仅此而已。 但是在 Godot 中同时拥有同一个插件的两个版本意味着其他一些难以解决的问题。

• 您的路径不再是您认为的那样/需要对核心进行更改，这主要是核心开发人员关心的问题
• 如果插件公开了一个自定义类型，编辑器会显示哪一个？
• 如果插件是C#，怎么编译不和别人的副本冲突？
• 如果插件注册了自动加载，你如何区分它们？
• 如果用户创建使用插件的数据，它将使用哪一个？
• 哪一个会在编辑器中显示 UI？

我认为在我们甚至可以找到适合引擎的简单解决方案之前（可能还有更多我没有想到的），我们已经可以在不破坏兼容性或引入核心更改的情况下改进编辑器和资产库中的现有内容。

在此线程中的所有内容上 +1 - 扩展插件模块并增加资产库的使用是要走的路

在尝试和学习 Unity 之后，我现在对它应该是什么样子有了更清晰的想法。

首先是 Unity 现在有一个“包管理器”，他们可以使用它让用户选择他们想要安装/卸载的引擎组件。 看起来他们将来也可能将其用于 Asset Store。

像这样的东西真的会帮助 Godot 在拥有“官方插件”的同时能够“减少臃肿”。 即使使用了他们的包管理器，Unity 仍然非常臃肿，而如果 Godot 有一个，它可能会变得更小。 不过，可能不得不放弃“一个 exe”的分发方法。

此外，正常的“模块”可能应该构建为共享库（dll/.so 文件），以便可以在包管理器中选择它们进行安装/卸载。

项目和包应该有清单文件列出它所依赖的包，Godot / 包管理器将确保安装所需的包。

需要一个公共的软件包注册表。

这将使社区能够轻松地扩展 Godot 的能力并轻松地建立在彼此的作品之上。 我认为这将极大地促进社区发展。

不同意转向包管理器方法的整体优点，我还没有下定决心，但我想指出它也有它的弱点 - 一个单一的可执行文件可以更加集成和良好 -测试，至少更容易。

使用包管理器，每个插件和版本的测试表面呈指数增长。 如果插件大多是小添加（如当前在 AssetLib 上），并没有深入到引擎核心中，这并不是那么糟糕，但如果你拆分引擎的核心部分，它很快就会变得如此。

Unity 已经遇到了不同版本的包、编辑器或安装（或未安装）某些特定包组合，甚至安装顺序的问题、崩溃和兼容性问题。

这是很多额外的复杂性，需要妥善管理，以免我们最终陷入依赖地狱:)

关于依赖地狱，为什么不从 AppImage 之类的页面中获取一个页面，并尝试通过让插件分发者负责管理资产/文件依赖关系来避免依赖问题？ 这就是我如何看待这个问题......

插件应该（理想情况下）是逻辑（自定义编辑器、自定义节点、动态链接库）或资产（模型、材料、字体、纹理等）的自包含元素，它们应该有自己的依赖集。 试图找出共享依赖是一个难题，虽然人们可能会喜欢它，但这意味着为了维护它需要付出更多的努力。 如果您实际上允许共享依赖项，您将不得不像 steam 运行时那样处理这个问题，并维护一堆不同的库、插件和资产作为它们自己独特的包。 您还需要在服务器上为多个版本存储多个相同的包——这将是一场维护噩梦，现代 linux 发行版或多或少地远离包管理器也就不足为奇了。

插件本质上可以是单个 tar 存档，其中包含该插件独立运行所需的所有元素。 他们应该自己在本地工作，所有依赖项也存档在里​​面。 当 godot 看到这个文件时，它会检查存档文件夹根目录中的清单文件。 此清单可以包含基本信息（名称、描述、godot 版本、图标、作者），但还应包含以下内容：更新信息（下载最新版本的链接，由插件开发人员维护），godot 可以使用这些信息自动更新plugin（有用户许可）、project_website（链接到存储库或网站，让用户快速找到包的来源）和 class_names（此插件中可扩展的类列表，用于编写脚本。）它还可以指向它使用内部插件文件的相对路径作为依赖项的插件。

如果我们在插件中允许插件，那么依赖问题将（或多或少）得到解决。 同一库的不同版本将位于不同的目录路径中，并且可以被视为给定 fork 上的不同“路径”。 当然，这个系统的问题在于您最终会在给定磁盘上拥有大量重复信息。 但是，在打包游戏时，godot 可以理想地遍历所有插件目录并合并通过校验和匹配的文件引用（这可以包括 tar 表示的文件结构？）。 这样，如果两个文件相同，godot 将通过合并对单个文件的引用来优化最终输出的二进制文件。

我敢肯定，对于这么复杂的问题，这太天真了，但由于我的自定义字体补丁，我最近在考虑插件系统。 我认为最好的用户体验是他们不必担心依赖关系，而开发人员应该关心管理自己的依赖关系。 这使用户更容易管理：项目可以将其插件表示为文件系统扩展坞中的单个文件，您可以右键单击并获取其他选项（ extract files （用于开发）， update plugin （为了方便更新），访问网站（ for easy community organization ）并在给定的“容器”中引用类（ extends "[path-to-addon-tar]://ClassName" ）

只是我的 2 美分，我敢肯定我的想法也存在一些缺陷，但这可能是一个有趣的解决方案，也是减少维护需求的好方法戈多团队。

仅基于之前的 2 美分的 2 美分（这是 4 美分吗？）：
我猜.tar档案对大多数用户（咳咳，Windows 用户）来说有点陌生，所以最好使用.zip档案，因为它们有更广泛的支持。

话虽如此，以 Godot 自己的.pck格式分发插件怎么样？ 我确实有一些缺点（例如大多数应用程序无法识别），但这可能是一个使其更加标准和使用的机会。

我猜 .tar 档案对大多数用户（咳咳，Windows 用户）来说有点陌生，所以使用 .zip 档案可能会更好，因为它们有更广泛的支持。

话虽如此，以 Godot 自己的 .pck 格式分发插件怎么样？ 我确实有一些缺点（例如大多数应用程序无法识别），但这可能是一个使其更加标准和使用的机会。

当然，我主要指的是.tar作为通用打包归档类型的示例。 它可以并且可能应该使用 godot 的 .pck 格式。

为什么不使用 ZIP，因为它提供压缩并且是标准格式？

@Calinou我同意。 如果我们要求必须使用 .pck 文件，那么人们将不得不使用 Godot Engine 来打包东西，而不是仅仅使用他们喜欢的打包工具来捆绑他们的插件以供使用。 GitHub 还将存储库下载为 .zip 文件，并且它包含迄今为止最大的 Godot 插件集合。

我同意这里。 我认为不需要创建另一种文件类型。 Zip 文件似乎工作得很好，人们可以选择通过资产库使用 Godot 界面进行安装，或者他们可以自己手动下载。 .pck 文件不允许该选择。

在我的理想世界中，我想在https://godotengine.org/download有两个下载按钮：

• 满足 reduz 三个要求的流畅的最低限度下载，以及
• 一个臃肿的下载包含所有已批准和定期维护的插件，这些插件已经超过了一些质量控制，所以我知道他们的 API 至少与最低版本的 API 一样适用于核心。

更理想的是：
选择并混合。 下载最低限度后，我可以选择最低版本+插件“主题”。 哪些是常见用例所需的常用插件的集合。 （例如：2DPixelart、3D FirstPersonShooter、3D ThirdPerson、RTS、RPG、2.5D 游戏、2DCutout、Rougelike、ManagementSim、Sidescroller、Eventpackage、Shaderpackage、Scriptpackage、Assetpackace 等）。 因此，当我启动引擎时，基本插件已经安装并准备就绪，我知道它们可以工作，因为它们已获得批准。
如果更高级的用户知道他们不需要这些主题集合中的单个插件，或者组合两个或多个插件主题，或者从已批准的插件池中添加其他单个插件到主题以制作自定义包，他们可以取消勾选这些主题集合中的单个插件。

理想情况下，结果将是https://godotengine.org/download从这些选择中创建_一个动态下载链接_。

为什么？ 因为这对于在团队或小组中工作的人、对于必须在多台计算机上部署的学校的教育工作者和教师、对于遵循教程并希望与导师具有相同配置的人、对于个人来说，这将是一个巨大的时间节省和质量保证谁很高兴开发团队有一个官方批准的插件，用于常用但不是每个人都使用的东西，因此不必在 Github 和 Reddit 上挖掘几天来找到他们需要的东西，不知道哪个是最受支持的他们找到的 6 个选项中的一个。

对于那些需要小尺寸的人来说，一键最小下载应该仍然存在，以及不关心尺寸但想要最大功能的最大功能下载，看看引擎可以做什么。

一个更简单的解决方案是在第一次运行编辑器时要求安装额外的 [official only?] 插件。 目前，如果项目列表为空，我们可以选择打开 AssetLib； 如果第一次运行 Godot，为什么不弹出对话框来安装官方插件？

支持https://github.com/godotengine/godot-proposals/issues/142 、 https://github.com/godotengine/godot-proposals/issues/577和https://github.com/godotengine/ godot-proposals/issues/607 ，因为现在在 Godot 提案库上跟踪功能提案。

从 aaronfranke 编辑：另见https://github.com/godotengine/godot-proposals/issues/554