Godot: 为 Godot 4.0 重命名节点的建议

创建于 2019-07-21 · 111评论 · 资料来源: godotengine/godot

破坏兼容性

我知道我承诺尽可能降低 Godot 4.0 的兼容性，但我已经考虑了一段时间并基于反馈，我认为这是值得的。它不应该破坏与现有场景的兼容性（我们可以添加内部重命名），但它会与代码......

所以也许我们可以做的是 Godot 4.0 中的一个工具，它基本上将脚本从 3.0 转换为 4.0 进行符号重命名或只是重新标记..这样用户无需手动完成（因此没有大量的痛苦就像我们从 2.0 迁移到 3.0 一样）。

为了重用现有的教程（我认为无论如何都不会受到太大影响），我们可以发表一篇文档文章来展示重命名的内容。

我会改变什么

尽管很多人说 Godot 最初是一个 2D 引擎，但这是错误的。最初，它是一个 3D 引擎，并且唯一支持的东西是画布 (UI) 节点的 2d。 2D 节点后来出现。

因此，这使得对于 3D 节点使用“空间”术语而对于 2D 节点使用“Node2D”这一术语非常令人困惑。

对于开始使用 Godot 的用户（甚至是高级用户），这通常很令人困惑（仅借助节点颜色，但如果您在代码中犯了错误，意识到您使用的是正确的 3D 版本可能会令人困惑）而不是 2D))。

我的建议是简单地明确，如果节点以 2D 和 3D 形式存在，它们应该命名相同，但在最后添加 3D 或 2D（除了一些例外）。

所以，典型的重命名是：

空间 -> Node3D
区域 -> 区域 3D
相机 -> Camera3D
导航 -> Nagivagion3D
RemoteTransform -> RemoteTransform3D
KinematicBody -> KinematicBody3D

等等。

对于某些人，我认为我们可以保持当前的方式，因为用例主要用于 2D 或 3D，以及相反的版本，例如：

Sprite 和 Sprite3D 是有意义的，因为 Sprite 主要是一个 2D 节点
MeshInstance / MeshInstance2D 是有道理的，因为网格主要用于 3D

但话又说回来，如果您更喜欢更明确的东西并始终将所有内容制作为 2D/3D，请随时提出建议。

命名空间

出于几个原因，我不太热衷于 Godot 中的命名空间

Godot 是一个应用程序，而不是一个库
当您查看继承时，一切都有明确的作用。
调试符号随命名空间而显着增加，并且我们的调试版本会更大

但是没有什么可以避免我们使用 ClassDB API 定义它们，因此严重基于命名空间的语言以及用户非常习惯的语言（如 C#）可以使用它们。

举个例子：

在 GDCLASS("Node2D") 定义下面，一个可选的
GDNAMESPACE("Nodes2D")

它也将使浏览帮助和文档变得更容易。

我想改变的其他事情

SpatialMaterial 对新用户（以及现有用户）来说简直令人困惑。我认为我们应该重命名为 StandardMaterial3D。我可能还想制作两个不同的版本，一个与现有版本相似，另一个使用 ORM 样式纹理（现在在 Godot 中设置它们是使用空间材质和手动分配通道的巨大麻烦）。这样我们就可以有类似的东西：

+ Material3D
- + StandardMaterial3D
- + ORMMaterial3D

或类似..

3D 场景导入过程仍然相当麻烦，因为您无法在导入时为单个网格和材料设置选项，因此我想在导入停靠栏中添加一个选项，以便导入带有某些类型资源设置的窗口（在导入场景的这种情况）。

3D 场景导入将向您显示包含所有数据的树，然后您可以为每个节点/材质选择很多不错的东西，例如：

保持材料内置
用这个文件替换这个材料
编辑/创建网格 LOD 以获得适当的细节级别
编辑网格光照贴图选项，包括光照贴图比例，以便您可以在光照贴图中为不同的对象使用不同的比例等
许多其他选择。

欢迎反馈！

breaks compat discussion

资料来源

reduz

👍176 ❤39 🚀18 👀9 🎉3 😕2

最有用的评论

我专业使用 Godot 一年多了。

我同意你说的一切，除了：

对于一些人，我认为我们应该保持现在的方式

如果我们有这个千载难逢的机会，让我们重命名一切。这包括 Sprite2D 和 MeshInstance3D。

完全痛苦的重构总是比许多部分痛苦的重构更好。

jahd2602 于 2019-07-21

👍134

所有111条评论

我专业使用 Godot 一年多了。

我同意你说的一切，除了：

对于一些人，我认为我们应该保持现在的方式

如果我们有这个千载难逢的机会，让我们重命名一切。这包括 Sprite2D 和 MeshInstance3D。

完全痛苦的重构总是比许多部分痛苦的重构更好。

jahd2602 于 2019-07-21

👍134

说到重命名： https :

Zylann 于 2019-07-21

👍8

@jahd2602我个人不介意，我们可以在最坏的情况下进行投票。

我绝对可以看到人们仅仅因为这是不一致的事实而烦恼，但我们至少可以看到他们是多数还是少数。

reduz 于 2019-07-21

👍8

@Zylann我知道，如果我们在这里决定什么，我们会把它移到那里。

reduz 于 2019-07-21

我认为反对命名空间的立场是短视的。从一般的引擎工作流程的角度来看，这是有道理的，但它忽略了工具制造商的角度。例如，bitwes 的 Godot 单元测试 (GUT) 由于其中一个更新中的命名冲突而中断。使用专用的 GUT 命名空间有可能避免这种情况。

我还想要用于等待和测试 (WAT) 的命名空间，这样我就可以使用类名，例如 Test（通过 WAT.Test 访问），而不会在其他框架上运行（例如 GUT，如果要使用 GUT.Test）或只是用户的脚本。我已经多次尝试使用包含所有用作子类的脚本的 WAT 类，但这只是一个循环引用地狱。

如果鼓励我们从引擎内部构建工具，那么我们需要在引擎中创建这些工具的工具，即使它们对于引擎工作流本身并不是绝对必要的。

总而言之，一个专用的命名空间系统既可以从引擎（或者至少是插件脚本）访问也可以定义，因此工具制造商最终不会相互交叉，否则他们的使用将是天赐之物。

CodeDarigan 于 2019-07-21

👍15 👎2 😕1

@CodeDarigan我知道它有好处，我不否认它们，但我真诚地相信成本超过它们。

除此之外，我们几乎没有来自 GDScript 用户的重大抱怨，他们更喜欢当前的方法，因此这将迫使他们进入不需要的工作流程并以一种旨在快速编写快速和肮脏的东西的语言键入更多代码。（不过，C# 用户似乎确实需要它们）。

这就是为什么我的意思是它们可以作为脚本语言绑定的元数据存在，我们甚至可以为 GDNative C++ 添加它们。只是不要为核心 C++ 引擎添加它们。

reduz 于 2019-07-21

👍9 👎5 😕2

导航 -> Nagivagion3D
这是笔误吗？

nitodico 于 2019-07-21

😄9

@nitodico确实

reduz 于 2019-07-21

@reduz我同意 @jahd2602。即使有些事情可能很明显，但为了一致性起见，我们应该使用 2D 或 3D 进行后缀。

Duroxxigar 于 2019-07-21

👍37

我仍在开始使用 Godot 并且提议的更改对我来说听起来很明智——对节点的 2D 或 3D 变体使用略有不同的名称是让我在了解哪一端结束并转向 Thing2D 时有点困惑的事情/Thing3D 或 Thing/Thing3D 感觉像是对清晰度和可理解性的重大改进。

swetland 于 2019-07-21

👍3

请这样做。

ripperdave 于 2019-07-21

无论如何，这种变化会发生，所以最好现在就去做并坚持下去。对于 3d，没有那么多的 tuts，所以现在这种变化造成的损害将比一年后、两年后要少。

StyrmirNathrakh 于 2019-07-21

👍2

关于材质，最好拥有某种仅使用最少资源（如漫反射和镜面反射）的传统材质，这对 3D 手机游戏很有用。

Janders1800 于 2019-07-21

我也赞成将事物重命名为明确的 3D 或 2D。

难道不能让原始名称作为新名称的别名仍然存在吗？它们将对编辑器隐藏，因此旧名称将无法使用（或放置在“已弃用”标题下）。这样旧代码仍然可以工作，无需更改，也不需要额外的逻辑来转换任何内容。

可以使用不推荐使用的节点名称为代码添加警告，然后在 4.1 或 4.2 中可以删除它们。

MuffinManKen 于 2019-07-21

👍14

如果节点有两个版本，我总是会附加 2D/3D 后缀。

pkowal1982 于 2019-07-21

👍1

另外，如果 Label -> TextLabel，我会很高兴。我去添加一个节点，这样我就可以显示一些文本，所以我在搜索栏中输入文本，当然只有 RichTextLabel 出现，这提醒我标准文本节点的名称中实际上没有文本。

MuffinManKen 于 2019-07-21

👍29 👎2

@Janders1800这就是它现在的工作方式，您在 SpatialMaterial 中使用的功能越少，它创建的着色器就越小。

reduz 于 2019-07-21

我是一个 2d 人，所以对于主要有 2d 应用程序的节点，如果节点名称没有后缀，则保持节点名称不带后缀对我来说似乎很好。对于 3D 用户来说，这似乎是一个更痛苦的重构，但在某些节点在大多数情况下只有 2d 或 3D 应用程序的情况下，它们保留其预期域的较短名称并在其他地方有后缀确实很有意义。任何其他可以统一的东西都会很高兴看到统一，特别是Spatial 。

nobuyukinyuu 于 2019-07-21

👍3

我也赞成无条件使用2D / 3D后缀。

虽然确实对于某些节点来说，拥有更多“自然”名称的机会似乎已经失去，但一致性获胜。

我不太喜欢的是StandardMaterial3D是非 ORM 的。我的观点是 ORM 得到了一个标准的更强有力的支持（至少 RM，这是你在 glTF 中所拥有的）。

但我还不能建议一个更好的命名。

或许这也是一个对“画布”做点什么的机会。我发现这个概念有时有点令人困惑。

我知道这很困难，因为它没有 3D 对应物：3D 场景存在于Spatial节点中，但画布可以包含Node2D和Control的混合。

但是，如果我们可以定义一些命名，允许将CanvasItemMaterial重命名Material2D ，同时保持它对“纯”2D 和 GUI 领域有意义，那就太好了。

RandomShaper 于 2019-07-21

👍11

我不一定反对重命名，但原始名称对我来说很有意义，也许是因为我的背景。
物理学或工程学中的默认值是“3D”。除非您在其他空间工作，否则您不会说“3D 运动学身体”，而是说“运动学身体”。
但是，我敢肯定，并非每个人都有相同的背景，甚至对此都没有同意，因为这毕竟是游戏引擎，不必严格遵循物理或工程惯例。

m4nu3lf 于 2019-07-22

👍2

为了将来的兼容性，在 gdscript 中

一个 gdscript 文件...

扩展空间
class_name Node3D

等等。

RKiemGames 于 2019-07-22

👍2

您是否考虑过将空间节点的translation重命名position ？

BeayemX 于 2019-07-22

@BeayemX我认为翻译是 3D 空间的常用术语，而位置对于 2D 开发人员来说是常见的 :thinking:

我不知道 4.0 会不会是最好的节点名称更改，会有很多事情要处理，从 2 到 3 有很多变化，这意味着弃用书籍、视频、课程。
即使文档不完整，随着中期完成的变化，修复也会减慢很多速度......

eon-s 于 2019-07-22

我赞成按照此处的建议重命名 3D 节点。我不知道这对教程制作者来说会有多大的问题。至少，重构现有代码库应该是微不足道的。在 C# 中，我们甚至可以在调试模式下滥用ObsoleteAttribute以使其更容易（但不确定是否是个好主意）：
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

我希望我们添加#18711 中讨论的命名空间/类别。我想将 C# API 分成命名空间和程序集，以便用户可以只选择他们需要的内容。
我对 4.0 的计划是在没有其他选择的情况下自己硬编码一个命名空间表，但我更希望我可以从 ClassDB 获取这些信息。

neikeq 于 2019-07-22

@eon-s 我不认为它是...虽然translation在技术上代表坐标是有效的，但 Godot 是我看到这里使用不同术语的第一个引擎，否则我总是看到position无论是 2D 还是 3D。同样对我来说， translation与运动有关，并与另一个与语言/转换相关的术语相冲突，这让它很奇怪。 https://github.com/godotengine/godot/issues/16863 中也提到了这一点。

Zylann 于 2019-07-22

👍4

顺便说一句，为什么我们计划尽可能少地打破？我理解为什么人们不想要更多的兼容性破坏，特别是那些制作教程的；但如果我们不以 4.0 为契机打破兼容性，那我们什么时候开始呢？ #16863 已经积累了很多建议。

neikeq 于 2019-07-22

👍5

@neikeq等不及 5.0 了吗？由于没有计划新的或大的功能，否则人们将停止为每 1 年或 2 年更换一次重要部件的引擎制作东西和购买课程（对于视频教程制作者来说，这意味着重做他们的所有工作）并且有几个月的警告时间...

eon-s 于 2019-07-22

👍2

我赞成重命名以具有一致的 2D/3D 后缀，并且我同意该线程中的许多人的观点，即应该对所有节点进行重命名以保持一致性。拥有一致的命名约定对于学习引擎的人或从事物的 2D 方面转向 3D 的人非常有帮助，反之亦然。

@eon-s 等到 5.0 肯定意味着会有更多的工作需要更新？

martin-jw 于 2019-07-22

尽管教程很棒，但我会投票支持使引擎更易于理解，而不是为了现有教程而使引擎变得混乱。希望 fixit 脚本或可选别名（如上所述）可以用于平滑升级路径。

swetland 于 2019-07-22

我很欣赏 Node 和 Spatial 在命名上的不同，因为 Node 节点不知道空间，使用 Node、Node2D 和 Node3D 会让人感到困惑。除非你打算摆脱 Node，否则它是完全合理的。

我赞成只有一个领域 2D 或 3D 不得不忍受后缀。目前是 2D，2D 和 3D 之间的混淆也就到此为止了。

请不要添加 3D 后缀。它真的值得为它添加的东西而头疼吗？值得付出代价吗？更新一切或有过时的教程？不可修改和过时的 youtube 教程？它会带来更多的混乱。

dpalacio 于 2019-07-22

😕1

@dpalacio我只使用了几个月的 Godot，但我认为使用 Node3D、Node2D 和 Node 更清晰简洁，因为 Spatial 充当 Node3D 并且 Node 没有空间信息。我认为为 3D 添加后缀会更容易理解，因为它将被命名为“相反”。我知道这并不是真正的对立，但我不知道如何更好地表达它，因为英语不是我的母语。将 3d 与 2d 明确地放置在我看来很棒。我认为对于初学者来说会更容易，对于第一次接触游戏引擎的人来说更容易。命名空间也很棒，主要用于大型项目和插件。名称冲突令人头疼。作为初学者，我认为兼容性破坏需要最小化和自动化，因为很难在版本之间不断更改项目。如果我们有很多更改，我们也需要有一个自动转换工具和文档。

chalcosoma 于 2019-07-22

@neikeq是的，类别应该由名称空间替换，我们应该制作适当的名称。

reduz 于 2019-07-22

正是我在尝试 Godot 时的想法。我的强迫症告诉我应该是这样。

您是否考虑过将空间节点的translation重命名position ？

“位置”听起来更像是绝对位置而不是相对位置。
将其称为位置可能会帮助新开发人员，但最终他们会意识到它应该称为翻译。

noobaldrin 于 2019-07-22

👍1

作为编写 Godot 教程并在我自己的全功能项目中使用 Godot 的人，我对这个提议持怀疑态度。

我完全赞成更改节点的名称以保持一致，并且我同意其他人的观点，即一致性很重要，即使它可能会使事情变得更加冗长。如果它使代码库和文档中的内容更加一致，我更愿意将 3D 或 2D 添加到节点的末尾/开头。

以下是我希望看到更改以保持一致的一些节点：

MeshInstance -> MeshInstance3D （与MeshInstance2D保持一致）
GridMap -> TileMap3D或GridMap3D
TileMap -> TileMap2D或GridMap2D
YSort -> YSort2D或2DSort （或显示它是用于 2D 的）
ProximityGroup -> ProximityGroup3D
GIProbe -> GIProbe3D （或显示它是用于 3D 的）
ReflectionProbe -> ReflectionProbe3D （或显示它是用于 3D 的）
SpatialMaterial -> PBRMaterial或Godot3DMaterial或StandardMaterial3D （只是想法）
Label -> TextLabel （我同意@MuffinManKen）

以下是我对这个提议的看法，从积极的方面开始：

我认为这种变化会让那些没有戈多经验的人更容易，但只有在这些变化

很多时候我都在帮助其他人使用 Godot，我发现找到解决方案最可靠的方法之一就是查看文档。但是，由于节点的名称并不总是一致的，除非您已经知道要查找的节点的名称，否则某些节点可能很难找到文档页面。此提案中的更改将使找到正确的节点变得更加容易。

我可以看到此更改的另一个好处是它为节点的命名方式设定了标准，这可能对插件创建者和未来的 Godot Engine 贡献有所帮助。例如，如果我正在制作一个贴花节点（例如），那么通过此更改，我知道我应该将其命名为Decal3D而不仅仅是Decal 。
这也可能有助于命名 GDScript/C# 定义的类。

这也将使以后的教程编写更容易一些，因为您不必再解释Spatial基本上是 3D 中的Node2D 。

现在是负面的：

我对这个提议的最大问题之一是它似乎为时过早，特别是考虑到不久前 Godot 3.0+ 改变了很多东西。我认为只有少数使用 Godot 3.0+ 的游戏出现了，而且很少有 3D Godot 游戏。
Godot 展示中的许多大型、令人印象深刻的 3D 游戏仍未发布，做出这样的重大改变意味着这些项目也需要更新，从而进一步推迟一些真正强大的 3D Godot 游戏。

此外，Godot 3.0+ 教程仍在发布。尤其是在 3D 方面，事情开始有所进展。虽然这部分是由于 Godot 3D 方面在 Godot 3.0+ 中变得更强大，但我担心很多材料教程作者正在制作（或正在制作）将突然需要大量改写以解释名称更改。这将需要时间来制作新教程，因为旧教程将不得不删除、重新制作或重写。

命名更改还会使现有的不是教程的资源，只是为问题找到的简单解决方案，突然过时了。虽然 Godot 的 2D 方面可以说是相当强大并且可能会很快适应，但使用 3D 方面的社区明显较小。通过更改节点的名称，我担心这会阻碍 Godot 的 3D 用户增长以及为 3D 相关问题找到解决方案的能力。

我同意@eon-s：这些变化不能等一下吗？至少在代码库中，Godot 4.0 的情况已经发生了巨大的变化。我认为添加另一个巨大的变化只会使开发变得更加困难，并重置人们在 Godot 3D 方面取得的许多进展。

一旦 Godot 4.0 发布，我认为在 4.1 或 5.0 版中重命名节点会非常好，但在我看来，我认为添加另一个像这样的大变化弊大于利。

可能使这种过渡更好的一件事是有一个别名/过渡期，例如可能从 Godot 4.0 到 Godot 4.1。这不会使教程和资源（尤其是 3D 的）立即过时，并且让每个人都有机会适应即将到来的变化，同时仍然能够从 Godot 4.0 的变化中受益。

使用别名/过渡期将允许进行破坏兼容性的更改，而不会突然强制每个人一次全部更新。这也将允许更频繁地进行兼容性破坏性更改，因为理论上一旦系统准备好进行转换，它就可以再次用于未来的兼容性破坏性更改。通过#16863 中列出的更改，这将使事情更容易进行。

TLDR：我完全赞成这些变化，我认为应该等到 Godot 4.1 或过渡系统/时期应该让每个人都有时间适应变化。

不管这个提议最终如何：我认为 Godot 4.0 会很棒，我很期待它🙂

TwistedTwigleg 于 2019-07-22

👍6

@reduz我说去吧。我第二次@jahd2602

Norrox 于 2019-07-22

我不喜欢让所有 3D 节点都以“3D”结尾，但可以肯定，如果每个人都愿意的话。我确实认为保留不同的名称而不是总是有后缀很好（例如：TileMap 和 GridMap）

我非常喜欢“位置”而不是“翻译”。后者可能与本地化和语言相混淆，而前者清晰易懂且适合初学者。但是，Godot 不是已经在大多数地方为此使用了“起源”吗？

我也同意@neikeq 的观点，如果它是对新项目的有益改变，那么打破兼容性是值得的。我个人很乐意看到#16863 中的绝大多数内容得到实施。

（顺便说一句，当 Sprite3D 可能只是一个四边形网格时，它为什么存在？）

aaronfranke 于 2019-07-22

@TwistedTwigleg阅读我的帖子，如果添加了内部兼容性系统，3.0 项目将在 4.0 中正常打开。

reduz 于 2019-07-22

👍2

不错的变化，作为程序员，我很高兴看到对应的名称尽可能对称

kruglinski 于 2019-07-22

你能更详细地解释一下 ORM 风格的纹理是什么意思吗？

fire 于 2019-07-22

👍1

@reduz是标准空间材质和 ORM 之间的唯一区别，即您只有一个纹理通道（而不是目前的 3 个）与 ORM？您是否仍然可以访问相同的参数（金属和粗糙度），例如镜面反射和乘数？不经常使用，但有时用于调整。

我确实喜欢这个想法，但想知道对于这么小的变化来说有 2 种材料类型是否太过分了。是否可以使用单一材质在 ORM 模式的 1 个纹理通道或现有样式的 3 个纹理通道之间切换？

我最近也将深度（高度）通道放入我的 ORM 贴图的 alpha 通道中，以获取更多纹理。然后你可以只使用 3 个纹理来制作大多数纹理......反照率/法线/ORM(H)。默认情况下，这可能值得添加（除非我们为高度图提供 16 位选项，您希望在其中使用单独的选项）。如果 4.0 最终获得曲面细分/位移，高度通道将比当前重要得多。

说到这里，这也是一个很好的机会，在 4.0 中将 DEPTH 通道的命名更改为 HEIGHT，并使其使用与当前使用的相反的名称（即白色是凸起的表面，黑色是凹陷的）。这将使其与其他渲染器和游戏引擎同步，更重要的是与 Substance、Quixel 和 Marmoset 等工具同步。

$fracteed picture$ fracteed 于 2019-07-22

👍2

我更喜欢 2D 和 3D 节点的显式后缀，如果不适用，则没有后缀。我还希望为“Node2D”节点完全分离“控制”节点（它们目前都在“CanvasItem”下分组）。

PaulHMason 于 2019-07-22

关于translation与position ，我会在 2D 和 3D 中选择前者。

position看起来更友好，但是一旦祖先有一些旋转或缩放，它就没有意义了。

关于兼容性，过渡阶段应该持续所有 4.x 版本，以便为教程、用户和项目提供充足的时间。新名字应该是一等公民并受到鼓励，但旧名字应该起作用，通过一些编辑器内的机制来告诉人们这个变化。

RandomShaper 于 2019-07-22

👍1

我绝对赞成建议的更改，只要它的完成方式使最终用户可以通过上述某种工具轻松更新现有代码（他们自己的代码或现有教程和文档中的代码）。缺乏这样的工具，我倾向于同意我们在 v2 到 v3 的大转变之后很快就会堆积起来。

aerger 于 2019-07-22

@TwistedTwigleg关于 3d 游戏的发布，那是因为我们在等待 4.0 和 Vulcan 😎

Norrox 于 2019-07-22

我还会查看Control节点名称...和内联文档。

有时我想知道AcceptDialog和ConfirmationDialog之间有什么区别，与PopupPanel 、 PopupDialog 、 PopupMenu ...希望如此有帮助！

Beelzenef 于 2019-07-22

作为导师和文档贡献者，我会说继续！如果更改使每个人在未来更容易学习和理解引擎，我不介意制作更多内容。最好也尽快进行这种更改。

NathanLovato 于 2019-07-22

❤9 🎉2

参加聚会迟到了，但要进行一些澄清以使事情易于管理：

请仅评论重命名节点的提议，及其对如何保持兼容性的技术影响，对现有项目、教程、内容制作者等的影响。
这不是讨论 API 中应该考虑重命名的特定点的地方。如果我们决定进行这种大规模的重命名，我们将在电子表格中审查整个 API，以确保我们具有一致的名称。对于应重命名超出此处讨论内容的方法、属性或类等特定内容，请参阅 #16863。
@RandomShaper @fracteed @fire @reduz请将有关标准材料的讨论移至专门问题。

akien-mga 于 2019-07-22

你好，
为什么不遵循其他 API 的做法并为类（甚至方法）创建一个过时/弃用的装饰器，即旧名称只是别名/指向新名称的指针。这将停止任何重大更改，并允许在第 5 版中删除名称，从而减少受到影响甚至注意到的人。

使用装饰器还可以带来另外两个好处：

IDE 可以轻松地选取此标记并将其显示在节点选择窗口中，例如，它可以读取“空间（已过时使用 Node3D）”而不是简单地说“空间”。
然后装饰器可以成为代码编辑器中显示的内置警告。

此外，它不会阻止任何人创建重命名工具......

chucklepie 于 2019-07-22

👍4

一些想法：

我同意重命名节点以及一些方法和属性（请参阅 #16863 中的当前列表）以提高一致性并使 API 更易于学习和使用。使 2D / 3D 区别清晰似乎是一个好主意，如果这样做了，则应始终如一地进行（例如，也提到了 MeshInstance3D）。我建议我们使用电子表格来列出所有当前节点以及它们在 4.0 中的新名称应该是什么 - 我们可以在那里找到有关 TileMap/GridMap 等特定节点的自行车。如果我们确认这是我们想要的方式，我将在未来几天创建此电子表格。

然而，我们应该尽可能地限制兼容性破坏。正如 Juan 提到的，我们可以在引擎内部进行兼容性重命名，以便可以加载和转换旧场景，但这还不够。

正如@RandomShaper和@chucklepie 所提到的，我们应该为我们重命名的所有节点、方法、属性、常量、信号等添加不推荐使用的别名，并使用属性装饰器/元数据来表明它们已过时并鼓励用户进行更改他们的代码。在 IDE 中使用此信息应该可以让用户在 4.0 中毫无问题地遵循 3.x 教程，同时轻松了解新名称。

为此，我们需要帮助器方法来让我们在注册绑定时定义已弃用的别名。 #23023 是第一次尝试添加这样的接口，但如果它不足以满足我们在 4.0 中的需求，它仍然需要进行审查、合并和扩展。那些已弃用的别名可以在整个 4.x 发布周期中保留，并在 5.0 中删除。
在我们精心设计和合并此界面

至于何时，我坚持认为，如果我们想再次破坏兼容性，那就是现在。等待 5.0 是没有意义的，因为一旦我们到达 5.0，它会使更多内容过时，并且如果我们破坏与（希望）许多使用 Godot 4 开发的优秀游戏的兼容性，也无助于将 Godot 描述为稳定的开发工具。X。

Godot 的用户群每年都或多或少地增加一倍，因此每年过去都会使重构变得不那么现实，因为最终庞大的用户群的惯性会超过破坏兼容性带来的好处。如果说 Unity 或 Unreal 等其他引擎在 API 方面与 Godot 相比似乎相对稳定，不是因为他们没有想要重构或重命名的东西，而是因为他们负担不起。就目前而言，我们仍然可以，所以我们必须利用这个机会。 Godot 3.0 也是如此，社区从中相对安然无恙，尽管我们确实有一小部分用户坚持使用 2.1，因为他们负担不起移植到 3.0 的费用。对于 4.0，这些更改的范围有望小得多，任何移植工作都应该很简单，但与此同时，社区已经发展了很多，因此任何兼容损坏的影响都将与 3.0 中的一样大或更大。图像条款/累积的用户烦恼:)

akien-mga 于 2019-07-22

👍13

我是破坏兼容性的大力支持者。
为什么这不是问题：如果开发人员在旧版本上推出他们的游戏，然后继续在旧版本引擎上开发，没有人会强迫开发人员迁移到新版本。另外：正是为此目的，继续提供旧版本供下载。
新的项目可以在新版本的引擎中启动，然后就看开发者是否有耐心重新学习引擎的工作原理。
当谈到提高引擎的可用性时，如果目标是成为最用户友好或最强大的引擎，重新学习的耐心永远不会成为问题。

至于重命名，如果要学习的材料中有模式，则有助于减少学习曲线。例如，所有其他节点的 Node2D 与 Node3D 等。如果它看起来像一只鸭子，你知道它是怎么回事，它很可能是一只鸭子，或者在这个例子中是一个节点。
人脑就像一台优化的量子计算机，它通过将系统的最低能量状态相互连接以在想法之间创建逻辑路径来学习。如果要学习的想法相似，则它们的最低能量状态彼此更接近，这使得连接（和记住）它们更容易，这解释了为什么如果学生事先学过 2D 则更容易理解 3D . 如果节点的名称反映了它们之间的相似性，那么在相似类型上存在知识的情况下，也更容易学习和理解如何使用新类型。

我说继续重构并以任何您希望的方式破坏兼容性。即使您失去了很少的用户，通过增加用户友好性和减少学习曲线，您也会获得更多。

aspenforest 于 2019-07-22

👍2

与此相关，以 Blender 2.80 为例。将它现在的外观和行为与以前的情况进行比较。这是一个重大变化，迫使许多开发人员重新学习软件的工作原理。现在想想 Blender 有多少用户。与 Godot 相比，他们是巨大的，但无论如何他们都彻底改变了他们的软件。为什么？因为从长远来看，减少学习曲线和提高用户友好性总是更有利可图，即使这意味着失去一些没有耐心过渡到新工作流程的用户。

aspenforest 于 2019-07-22

👍1

总的来说，我不赞成在这种情况下进行重大更改。

我可以理解对有机发展的命名约定感到的挫败感，但我认为没有任何理由可以证明进行范围广泛的重大更改是合理的。

我完全赞成弃用我们希望摆脱的 API（并在编译时和文档中标记这些 API），但理想情况下，旧节点名称将继续像以前一样发挥作用。

或许，几年后，我们可以问是否是时候停止使用遗留节点名称了，因为它已经变得完全无痛了。在那之前，我的建议是根据需要添加新名称（我对此没有强烈意见）并避免破坏向后兼容性。

gerald1248 于 2019-07-22

@fracteed实际上，在另一个纹理的通道中具有深度可能不是一个好主意，因为视差映射对该纹理进行了大量点击，每次都不必要地强制获得 RGB。如果您使用单个灰度纹理，Godot 会将其压缩到一半大小，从而为您节省一些带宽。

在标准材料中使用 ORM 模式也可能是个好主意，需要检查一下。

reduz 于 2019-07-22

@chucklepie问题是并非所有语言都支持 typedef 之类的类别名。 C# 就是其中之一。

neikeq 于 2019-07-22

@reduz啊，我没有意识到这一点，很高兴知道。更重要的问题是将深度通道切换到 4.0 的高度，所以希望你会考虑改变它。

编辑。抱歉 Akien，在发布此内容后才看到您的评论...

$fracteed picture$ fracteed 于 2019-07-22

@neikeq问题是并非所有语言都支持 typedef 之类的类别名。 C# 就是其中之一。

我不知道本机 C++ 库是如何实现的，但我更多地指的是在本机 C++ 级别进行这种装饰的机制，以便上游语言绑定是什么并不重要。如果这是不可能的，那么每种语言的绑定都可以很容易地适应套件（例如，在 C# 中使用属性等）。

chucklepie 于 2019-07-22

@gerald1248阅读我的帖子，我没有提到它会中断，在 3.x 中创建的项目将通过在加载和脚本上使用别名继续工作。使用它们会触发弃用警告，但您的项目将继续工作。

reduz 于 2019-07-22

👍1

我是这个的忠实粉丝

导航 -> Nagivagion3D

改名。我支持这个要求！

NickvdMeij 于 2019-07-22

😄3 👍1

@reduz说：
@TwistedTwigleg阅读我的帖子，如果添加了内部兼容性系统，3.0 项目将在 4.0 中正常打开。

糟糕，我错过了帖子的那部分。

内部兼容性系统将有助于迁移，并且肯定会让我更多地站在围栏的“进行更改”方面，尤其是与 #23023 之类的内容结合使用时。在此更改之前了解项目的某些计划很高兴听到并减轻了我对此提案的许多担忧。

@Norrox说：
@TwistedTwigleg关于 3d 游戏的发布，那是因为我们在等待 4.0 和 Vulcan 😎

那是公平的。
特别是考虑到 Godot 4.0 中 Godot 3D 方面的改进，等待对于 3D 重型项目来说可能不是一件坏事。

TwistedTwigleg 于 2019-07-22

3d 和 2d 的区别已经很明确了。 3d 节点为浅红色，2d 节点为蓝色，ui 节点为绿色。总会有用户对命名有疑问。这是一个永无止境的问题，是一个基于社区规模的乘法问题。

关于 OP 中的建议更改：2d 节点已经应用了“2D”后缀，这 _inherently 意味着它们的对应节点是 3d_。

但是，我赞成将Label更改TextLabel类的更改。（ @MuffinManKen提出了一个很好的观点）

girng 于 2019-07-22

👍1

我基本上完全支持这里的所有内容，但是关于“Sprite2D/Sprite3D”问题，我建议将 Sprite 保留为 Sprite，如果除了 2D 后缀之外没有其他原因会增加额外的混乱，IMO。

作为@girng说，在2D / 3D的分化已经到彩色编码很清楚到期，所以我们并不需要去竭尽全力避免混乱。从 Godot 开发人员的角度来看，我个人不喜欢将 -2D 添加到我项目中的每个未重命名节点上。 :D

AlexHoratio 于 2019-07-22

👍1

这种颜色编码对各种形式的色盲患者有帮助吗？
当您输入代码（而不是从对话框中添加节点）时，这绝对没有帮助。

MuffinManKen 于 2019-07-22

👍3

@reduz感谢您的回复。我意识到这是一个主要版本，因此从某种意义上说完全没问题。就我个人而言，即使对于主要版本，我也会避免进行此类更改，但我知道您对这是否会成为问题有更好的了解。我只是在查看主要版本（例如 python2 到 python3）的重大变化的历史，通常我宁愿忍受不一致（或新节点名称加上旧的、已弃用的节点）。无论哪种方式，我都喜欢 Godot 并将继续使用它，无论可能有什么重大变化。

gerald1248 于 2019-07-22

但话又说回来，如果您更喜欢更明确的东西并始终将所有内容制作为 2D/3D，请随时提出建议。

显式优于隐式。

shackra 于 2019-07-22

👍2

但是， @ girng @AlexHoratio在编辑器中具有不同颜色的节点在您编写代码时没有帮助。我认为这就是混淆的地方。

（我仍然不明白为什么 Sprite3D 需要存在，其他引擎只是出于相同目的使用四边形网格，如果 Sprite 只是一个 2D 术语会更容易）。

aaronfranke 于 2019-07-22

@gimg , @AlexHoratio不要忘记 4.5% 的人口也是色盲 :stuck_out_tongue:

reduz 于 2019-07-22

👍1

我认为重命名是个好主意。
从 2D 到 3D 的过渡将变得更加容易。至少对于那些从 2D 开始的人（也可能反过来）

cupiniki 于 2019-07-22

很明显存在问题，社区认为这是个好主意。我只是对戈多有偏见，而且感情上太依恋了。在这种状态下产生的想法对其他人来说并不真正有意义，但对我来说却很有意义，以一种美妙的方式。很难解释。谢谢你让我说出我的想法

girng 于 2019-07-22

我同意这里的普遍共识，即为了一致性而重命名它们是值得的。现在它可以给人一种外部印象，即一组节点是“一流的”，而另一组节点是“二等的”，或者甚至可能是基于第一个节点而被黑进存在的。

我个人认为Sprite -> Sprite2D将是完全严格的显式重命名的不幸牺牲品，但我想我总是可以在我制作的每个场景中手动将其重命名为 Sprite，直到我累了其中。

我确实认为CanvasLayer和CanvasItem没有分组是令人反感的，而且Node2D位于带有 Control 的 CanvasItem 内部，就像其他人指出的那样。

我知道@akien-mga 说这只是为了重命名节点，但我认为至少关于position与translation的争论在这里起作用。我认为，如果节点的 API 显着不同（除非坐标系统之间存在差异等），那么重命名节点的目的就显得有些单调了，所以无论它们是什么，它们绝对应该是相同的。我会投票支持“位置”作为到达这里的方式，有人评论说它与“翻译”相比具有误导性。我会说“平移”具有误导性，因为它意味着一种变换或运动，而不仅仅是坐标。位置在直觉上是相对的，imo（您不会根据指南针方向拉直椅子，而是根据房间的墙壁来拉直椅子。）

我认为这两个变量应该被命名为两个位置，但translate功能应该留下来，改变move_local函数Node2D至translate_local甚至，文档称之为翻译。我会继续使用move作为物理相关节点，以区分物理运动和几何平移。

后半部分的很多内容也与#16863 相关

还有@reduz ，我认为随着 C# 在引擎中获得功能，越来越多的人会想要 C# 的命名空间，一旦他们使用 C#，我可以想象很多 gdscript 用户想要使用它们而不必切换语言对于功能。我认为命名空间对于最终的 C# 支持是完全必要的，对于 gdscript 的好处要少得多，但它会使即插即用的包成为可能，而无需用户担心。

vortexofdoom 于 2019-07-23

👍2

我只是想到一个想法，如果实现了，我们可以有一个名为“Simple node names”的编辑器设置，这意味着新创建的节点在其名称中缺少后缀，例如，创建一个新的“Whatever2D”将设置其名称为“Whatever”，但该节点上的脚本仍然会说“extendsWhatever2D”等。这与创建一个节点然后手动重命名它是一样的。

如果用户选择启用它，这将避免在层次结构中看到“2D”或“3D”默认名称的混乱，但仍会使代码更加一致和明确。如果没有包含“3D”的 3D 节点，这会令人困惑，但默认情况下以“3D”结尾是有意义的。

aaronfranke 于 2019-07-23

👍4

@aaronfranke我认为这是一个非常可靠的想法。这似乎是一种妥协，允许保持代码库一致和清晰，同时允许用户将过多的混乱排除在他们的层次结构之外。我认为很多反对重命名的想法来自它对层次结构的影响，而不是对名称本身的反对。

vortexofdoom 于 2019-07-23

@aaronfranke我不想成为破坏其他明智想法的人，但是不同系统之间的不同节点名称会使共享 gd 脚本文件变得不可能。由于所有插件都导出为原始 gscript 文件和场景，如果它们是在具有不同节点映射的系统上开发的，它们将停止工作。为避免这种情况，所有 gdscript 文件和场景文件都需要包含节点名称映射，以便为新系统翻译文件。我很确定这种开销对于@reduz 来说是一个很大的问题。

aspenforest 于 2019-07-23

@aspenforest我不认为添加映射会是一个很大的开销，但也许我很天真，因为我不知道引擎的架构

georgikoemdzhiev 于 2019-07-23

@aaronfranke的想法可以很容易地MeshInstance节点将自动命名为mesh_instance而不是MeshInstance ），可以为节点后缀添加另一个设置，这将从节点名称中删除“2D”或“3D”后缀（因此新的Sprite2D节点仅命名为Sprite ）。

bojidar-bg 于 2019-07-23

没有人抱怨KinematicBody2D或Particles2D之类的不必要的“2D”后缀，所以我不明白为什么我们应该添加功能来解决添加“3D”后缀的问题在他们的同行身上......如果用户真的不希望这些后缀首先存在，那么这个提议可能应该被丢弃，而不是出于某种外观原因在IDE中重命名节点的方法......

akien-mga 于 2019-07-23

👍2

@akien-mga 这不会是“解决”新节点名称，对我来说它更像是顶部的肉汁，它只是具有一致命名方案的非hacky。我确实想要那里的后缀，因为当我编码、添加节点或查找文档时。但是一旦它们出现在场景中，我就知道它们是什么，而且很多东西无论如何都会得到自定义名称。

如果归结为在使名称一致和使用编辑器功能使名称简单之间做出选择，我会选择前者，但我认为@aaronfranke正在接受这样一个事实，即对该提案的任何反对从根本上说都是表面上的，他的建议解决了这个问题，虽然不损失任何地下一致性，但这个想法实际上是关于。

我绝对认为添加编辑器功能将是它自己的问题/公关，而不是包含此功能所必需的。

vortexofdoom 于 2019-07-23

👍3

我最初避免使用 SpatialMaterial，因为它有一个奇怪的名字。但它是一个如此强大的类。相反，我刚刚开始学习如何使用三平面映射的反照率+ao+法线编写着色器。然后我发现我所做的所有工作都是徒劳的，因为我可以在 SpatialMaterial 中完成所有工作，然后将其转换为代码并获得更好的结果。所以它需要一个更友好的名字。

+1 表示明确的 2D/3D 名称。

tinmanjuggernaut 于 2019-07-24

👍1

我对一个我认为将来可能会被标记为弃用的节点有疑问，我可以想象谁的存在从命名的角度来看可能会令人困惑。由于新的动画系统下降，我们现在有两个节点，一个名为 AnimationTree 和 AnimationTreePlayer，它们彼此之间基本上没有任何关系。关于什么可能是解决这个问题的最佳方法的任何想法？

SaracenOne 于 2019-07-24

@SaracenOne这不是

还有另一个更广泛地讨论名称更改的问题https://github.com/godotengine/godot/issues/16863

clayjohn 于 2019-07-24

我有一个想法，这可能超出了 4.0 可接受的兼容损坏范围，因此可能根本不可行/不可接受，但我想我会提到它，看看是否有人比我更愿意发表评论。

我想象所有这些 2D/3D 节点都可以从 2D 或 3D 的单个节点类型继承。此类节点的 API 将包含您对任一版本所期望的所有功能，它们的实现将取决于此特定功能是 2D 还是 3D。

理论上，这样的系统可以：

确保我们在 2D/3D 对应物之间创建一致的 API。在我看来，这既是一个优点也是一个缺点，因为尽管有这种一致性，但可能有一些东西没有必要包含在一个中，但在另一个中。
使两种不同类型的交互更容易，或者创建要附加到节点的 2D 和 3D 版本的自定义脚本。

最好避免出现“SomeClass2D 实现了 x、y 和 z，但 SomeClass3D 没有类似的情况”的情况，它以不同的方式解决了命名问题。由于某些我现在没有想到的原因，这可能是非常愚蠢的，但我想我会把它扔在那里。

vortexofdoom 于 2019-07-24

@vortexofdoom这已经发生了。 Node2D由所有2D节点继承，Spatial由所有3D节点继承。问题是如何称呼一切。

aaronfranke 于 2019-07-24

👍1

而且，更重要的是， Spatial和Node2D都继承自Node 。

RandomShaper 于 2019-07-25

我想说@vortexofdoom的想法中还有一些东西不仅仅包含在类层次结构中，但我无法确定它到底是什么。

RandomShaper 于 2019-07-25

只是想知道：您认为为所有Resource派生类添加 - Res后缀是否有益？

RandomShaper 于 2019-07-25

👍1

@aaronfranke我指的是让每种类型的节点（只是 KinematicBody 或 Sprite）中的一个，而最上面的一个是某种Node2D3D ，它决定了它们的行为。对不起，如果没有很好地解释。因此，我们没有 2D 层次结构和 3D 层次结构，而是具有 2D/3D 层次结构。这就是为什么我说这将是一个比可能可接受的更大的重构。

它_可以_通过让基本类型不能单独使用来工作，但需要将它们实现为 2D/3D 才能成为真正的节点，在这种情况下，我们将在节点名称上回到正方形，但继承更多2D 和 3D 之间的自动直接和关联以及系统之间的相互作用仍然会更好（我认为）。

vortexofdoom 于 2019-07-25

@vortexofdoom但实际上 2D 和 3D 之间没有共享任何内容。它们可能有一些相同的节点类型和相同的方法名称，但几乎所有的实现都完全不同。我可以期待的最多共享是一个界面，因为您的想法将涉及if (is2d) { do 2d stuff } else { do 3d stuff }并且会使代码文件的长度增加两倍并且非常不可读，没有任何好处。

aaronfranke 于 2019-07-25

具有可变行为的单个类的可行性绝对取决于顶级 2D/3D 节点可以做多少繁重的工作，进一步向下发送抽象。我敢肯定，将现在存在的类混合在一起绝对不值得麻烦。我不介意使用接口来完成重组，但它仍然会至少对不同类型强制执行一定程度的标准化。

这个想法是由一个空闲的愿望激发的，我可以从一个节点的通用版本继承，这样我就不必在并行运行 2D 和 3D 版本的项目中实现所有东西。现在，您必须从 node 继承并以任何方式进行一些转换才能做到这一点，因为 node 是唯一的共同祖先。

我认为Node2D3D （我知道这听起来多么荒谬）会有一些价值，即使只是作为一种使两个坐标系彼此更好地发挥作用的方式，但这完全是一个不同的设计问题比这个线程的。抱歉跑偏了。

@RandomShaper我绝对可以看到这样做的好处，特别是如果我们有那个简单的名称选项。

vortexofdoom 于 2019-07-25

将我的评论留给后人，但我撤回了我的建议，支持严格的 2D/3D 命名方案，同时在很大程度上保持层次结构不变。

原因是重命名所有节点将释放所有这些类名供用户使用，这意味着我可以通过创建自己的一组类（如KinematicBody或CollisionObject来实现我正在寻找的功能

但即使在这种边缘情况之外，它也允许您创建像Area这样的类，而不是设计像RoomGroup这样的东西作为一个简单的例子。

vortexofdoom 于 2019-07-25

👍2

我很高兴正在讨论这个问题。我希望它完成。

不知道是否有人说过，但如果为了一致性要重命名，最好保持完全一致性（尽可能地）并重命名某些方法。

例子：

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

Skaruts 于 2019-08-06

👍2

除了节点和方法，数据结构呢？我假设Transform将重命名为Transform3D以与Transform2D ，但Basis可能不需要是Basis3D因为没有Basis2D因为它都包含在Transform2D 。

aaronfranke 于 2019-08-11

👍2

@RandomShaper

只是想知道：您认为为所有Resource派生类添加 - Res后缀是否有益？

似乎有点太划算了。我宁愿投票将资源包含在我的建议 (#31054) 中以突出代码，tbh。一旦您完成键入类名（就像使用 Vectors 和 AABB 等内置类型一样），让它们具有不同的颜色将反映它们的基本类型。

Skaruts 于 2019-08-11

👍4

Screenshot_6
将项目分为 2D 和 3D 怎么样？

（关于用 UI 替换 2d 和用场景替换 3d 的图像建议）。

当您开始项目时，您可以选择要处理的项目。
类名中不再需要后缀（2D、3D）。

因此，以这种方式创建了命名空间，并且这些类型之间不再混合：

使用 Godot2D；
使用 Godot3D；

当您在 3d 或 2d 项目中时 - 单击 UI，您将获得用于编辑 GUI 的 UI (2D) 窗口，当单击场景时 - 您在场景中（2d 或 3d 取决于项目类型）。

所以这样我们在任何项目中都保持 UI 的 2d 模式，但 Scene 会打开 2d 或 3d 窗口

Screenshot_1

在此窗口中将仅显示与项目类型（2d 或 3d）相关的可用实体，或者如果它们在两者中都使用则共享

当您处于 UI 模式时，添加新节点仅显示与 UI 相关的组件的此窗口。
在场景模式下不显示 UI 控件时，只有可以应用于场景的东西

dmitryuck 于 2019-08-13

👎5 😕1

@dmitryuck对于您发布的图像，始终需要 2D 按钮，因为即使是 3D 游戏也需要使用 Godot 的 2D 模式来处理 UI 和其他内容。无论如何都希望能够混合 2D 和 3D。技术上 2D 游戏不需要使用 3D 按钮，但几乎没有必要隐藏它。

我在上面建议我们可以在层次结构中对节点名称进行装饰性更改以避免视觉上不必要的后缀，但如果代码总是明确的会更好。

aaronfranke 于 2019-08-13

👍3

@aaronfranke我在之前的评论中对我的意思添加了一些广泛的解释。

dmitryuck 于 2019-08-13

我认为根据情况不同地显示节点名称会增加混乱。

人们应该能够第一眼就理解脚本和场景树。我认为这是协作、清晰教程等的必要条件。

RandomShaper 于 2019-08-13

👍1

@dmitryuck 不过，有些项目可能需要混合 2D 和 3D，有些游戏的 UI 为 3D。

Skaruts 于 2019-08-15

👍2

@Skaruts通过在此编辑器中实现组件，可以在 3d 场景中切换到 2d 视图
Screenshot_1

当然，UI 模式必须存在于两种类型的项目中，但它可能是一个单独的窗口，其中包含专为 UI 设计的工具，如网格、增强的捕捉、标尺等。

dmitryuck 于 2019-08-16

👎5

@reduz重命名是件好事，但应该有很长的过渡期，例如从 4.0 到 5.0，因为这已经过时了https://godotengine.org/qa 的大量教程和答案

xxmatxx 于 2019-10-08

👎2 👍1

@xxmatxx我更希望重命名发生在很短的过渡期内，以停止拖动“会是什么”的旧名称。
此外，我会确保对更改进行详细记录，并确保刚陷入 Godot 的人了解更改。一个编辑器内警告通知您您正在使用节点名称的弃用版本也将很有用，以防有些人忘记了这一点。

AtomaFajrovulpo 于 2019-11-11

👍3

我同意，花费的时间越长，混淆人们的机会就越长。如果像@AtomaFajrovulpo建议的那样，在一段时间内，编辑器仍然允许使用已弃用的内容但发出警告，则教程和文档不会立即过时。我想是这样的：

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

和

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

Skaruts 于 2019-11-11

👍4

我昨天发现常量并不都遵循相同的情况。例如有Color.black和Vector3.UP 。这不应该与 4.0 保持一致吗？

BenjaminNavarro 于 2020-01-29

👍2

@BenjaminNavarro将颜色常量更改为大写也在https://github.com/godotengine/godot/pull/14704的底部进行了讨论

此外，方法/信号/常量重命名应该在#16863 中讨论，因为这个问题专门与节点名称有关。

Calinou 于 2020-01-29

👍1

@Calinou谢谢，我很确定还有其他问题，但找不到。

BenjaminNavarro 于 2020-01-30

我宁愿在 4.0 中重命名并结束它，然后知道它会在我正在从事的项目增长更多之后稍后出现。

如果一个主要版本不是这样做的时候，什么是。

SemVer：给定版本号 MAJOR.MINOR.PATCH，增加：
进行不兼容的 API 更改时的主要版本，
以向后兼容的方式添加功能时的 MINOR 版本，以及
PATCH 版本，当您进行向后兼容的错误修复时。

FrederickDesimpel 于 2020-02-07

你会走多远？

GridMap 会变成 TileMap3D，例如 Tilemap Tilemap2D 吗？

另外，node2D 和 node3D 似乎有点通用，那么为什么没有 Spatial2D 和 Spatial3D 呢？

我认为一个很大的 UX 差异也是控制、node2D 和空间，无论它们将被命名为什么，都可以在新节点对话框中的节点下直接访问，尽管 node2D 和控件继承自 CanvasItem。无论如何，您不能将 CanvasItem 直接添加到树中，因此它可能不应该在该对话框中可见。

就方法而言，我想没有必要在这些方法上添加 2D 或 3D 后缀，因为您知道对它们的称呼吗？

FrederickDesimpel 于 2020-02-22

👎1

还是希望做一些有用的更新，比如解决资源导入慢的问题，以及GD脚本的性能优化。目前导入1G资源大约需要一个小时。如果导入10G资源，就得坐在电脑前睡两天。不过现在700M-1G导入的资源编辑器文件系统浏览器坏了，什么都不会显示。文件列表，这可能是编辑器本身的不足，所以我认为优化和解决现有问题是Godot更好的方法。如果我只能导入100-500M的资源，那注定了Godot不能开发大型游戏，但我的路现在被堵住了，无法前进。希望下个版本能解决此类问题，祝Godot越来越好！

qq715152910 于 2020-03-05

@qq715152910请不要对信息完全不相关的长线程发表评论。对此问题发表评论的每个人都会收到一个ping，您的评论与重命名节点的建议无关。因此，我将隐藏您的评论。

clayjohn 于 2020-03-05

我将就一些对我们有用的重命名发表我们的意见（我们主要使用 C#）

我们强烈建议的重命名：

Transform.origin -> transform.origin

（使对转换属性的访问小写）

为什么？
例如空间有我们可以访问的Transform，但是很多时候我们写“this.Transform.origin”是为了更好的可读性，如果我们将“Transform”改为“transform”，我们就不需要全部使用“this”时间。这是我们个人的看法。

我们还支持将“标签”更改为“TextLabel”之类的内容。或者至少当我们在添加新节点时按“文本”搜索时，应该出现“标签”，因为它是完全相关的。
某些预定义颜色的常量应该使用Color访问，而不是Colors 。

对于提议重命名的其余部分，我们期待社区认为更好的内容。

rsousacode 于 2020-03-18

AtlasTexture -> TextureAtlas

它被命名为 AtlasTexture 因为它遵循通常的<Type>Texture约定，其中<Type>可以是Image ， Viewport ， Stream ，...

Calinou 于 2020-03-18

AtlasTexture -> TextureAtlas
它被命名为 AtlasTexture 因为它遵循通常的<Type>Texture约定，其中<Type>可以是Image ， Viewport ， Stream ，...

这是我输入“Atlas”时显示的内容。

capture212

这是当我们输入 Texture 时发生的事情：

asdasd

编辑：我们理解为什么会出现这种约定。在第二个屏幕截图中， AtlasTexture与遵循<Type>Texture约定的其他内容非常相似。之后，这一点从我们之前的帖子中删除。对于这种特殊情况，自动完成仍然不是很友好。但我们接受。 .

rsousacode 于 2020-03-18

@bigmonte的Transform结构将可能被重新命名为Transform3D在陀4.0按这个问题，所以您将不再需要this.要清楚它的属性。

编辑： https :

某些预定义颜色的常量应该使用Color访问，而不是Colors 。

我是首先提出这个建议的人，我强烈反对。最好将它们分开，因为它增加了Color的静态成员（目前Color8 、 ColorN和FromHsv ）的可发现性各种IDE。我也在考虑在 GDScript 中提议重命名Color.red等 -> Colors.RED以保持一致性。

顺便说一句，我认为您正在寻找#16863。

aaronfranke 于 2020-03-18

此页面是否有帮助？

0 / 5 - 0 等级