类别: 文件格式

让我们来谈谈 OBJ 进口商 (最后一次)

(这篇文章是为了反映本和我的讨论而编辑的)

层流研究公司对 XPlane2Blender 和其他出口商的持续要求是一个重要的目标特征。所以,最后一次,新闻是: 到目前为止,进口商基本上永远不会成为 XPlane2Blender 的一部分,但是这可能是它自己的项目!然而,要使它抛光得非常好,可能需要多年的开发。

T以下是一些在论坛上开始的项目,如果你愿意,你可以结账!

为什么这是一个如此困难的问题?

读取顶点表、属性、动画关键帧表并将其转换为 Blender 数据很简单,事实上,一些项目已经可以这样做了。问题是得到确切或接近确切。混合文件。

作为一名艺术家,不要保存你想要和需要的一切

一些你永远无法从 OBJ 导入的东西

  • 窗口设置
  • 包含脚本、注释或注释的文本块
  • 我们不关心的任何 non-XPlane2Blender 搅拌机设置
  • 对象、层、材质和纹理名称
  • 一堆不容易推断的设置 (稍后会有更多)
  • Blender 的亲子关系

如果生成的 OBJ 带有注释和正确的缩进,则可能能够得到一些这些东西的背面 (可能只是几个名字。)没有这些东西的大型复杂混合文件是无组织混乱的噩梦,将使手动逆向工程过程的其余部分更加困难。

倍数。Blend 文件可以产生相同的 OBJ 内容

如果 A.blend 、 B.blend 和 C.blend 可以产生相同的 OBJ,那么应该将 OBJ 反向设计回哪个 OBJ?XPlane2Blender 设置和 OBJ 中出现的内容之间的关系可能非常深奥,并且并不总是 1:1 关系。某些 ATTR_s 仅在使用某些设置组合时出现。你可能会发现绝对没有好的违约。

一个适度聪明的进口商需要了解所有出口商的大量历史

为了完美地解决这些歧义并产生。混合文件类似于最初导出 OBJ 文件的内容,了解导出有问题的 OBJ 的导出器的行为将非常有用。这意味着进口商需要知道每个出口商的所有错误和特征,我们甚至不知道在开发出口商之后。臭虫正在等待被发现,或者被艺术家使用,直到它们必须变成一个特征。我们的出口商当前努力考虑过去的错误,这就是出口商!

这变成了它自己的歧义来解决: “这个 OBJ 提到的过时的 ATTR_s 是艺术家做出的选择吗?尽管有反对的警告,还是这是一个仍然被写出来的错误,还是这个 OBJ 在被反对之前就写好了?"现在你不仅在摆弄有效与否,而且在摆弄 OBJ 应该是什么样子。

优化带来进一步的挑战

出口商通常采用优化来提高 OBJ 的性能和质量。例如:

  • 删除重复的顶点、关键帧、属性
  • 动态舍入或更改数据
  • 忽略或追加 ATTRs 来处理废弃或过时的 OBJ 特征

现在你将拥有更少的信息,或者,现在,看似不正确的信息!Obj 是针对 X 平面的,不是针对人类的。因为这样的出口商可以对 OBJs 的内容有很多自由,只要他们符合艺术家的意思。这可能导致非常复杂的优化,甚至可能打破我们自己的指导方针,所有这些都是为了向消费者和我们的艺术家提供最好的 (并按时交付)。这使得开发一个能再现 importer OBJ 的 importer 变得更加困难,无论是精确的还是简单的视觉匹配 (更不用说适当的动画或纹理)。

生的。混合文件,物体就像乐高积木,被烤成一个固体块。反过来可能不会得到同样整齐的分离。搅拌机不够聪明,无法分辨什么是机翼形状,什么是车轮形状,什么是油门水平形状。将顶点分离回这些不同的网格可能是不可能的 (尤其是在优化之后)!制造一个 “真正聪明” 的形状感知进口商是一个残酷而艰难的算法,世界上最好的计算机科学家仍在试图解决这个问题。这可能不是你想接受的挑战。

我们也许有一天会建立一个合理的进口商!

面对所有这些挑战,进口商必须不愿意处理所有边缘情况,也不试图将 OBJ 逆向工程回原样。成功的混合文件。例如,一个 3 岁的 OBJ 不会被反向设计到。三年前制作的 blend 文件,尤其是因为艺术家想要更新他们的资产!让艺术资产 “被困” 在其他出口商身上或 “死亡” 是相当可怕的时间浪费,可能比用手修理许多小东西更痛苦。正如 Ben 指出的,“如果我们不能直接导入 [。skp->。混合,。Ac->。混合] 路径,OBJ 导入是最不糟糕的选项。

2.49 转 2.7x 转换器

2.49 转换器是一个更易于管理的项目 (远远处于次要地位。)这个工具的复杂性更易于管理,因为 2.49 没有在积极的发展,你正在转换。混合到。混合,不。Obj to。混合。搅拌机对搅拌机是搅拌机已经非常擅长的东西。

张贴在飞机 & 建模,显影,文件格式,风景,工具 | 2 条评论

X 平面 11 最无聊的特征 -- 新 Navdata

当每个人都敬畏地看着新的用户界面时,X-Plane 11 也有一些重要的变化。随着 Aerosoft Navdata Pro 现在也支持 X-Plane 11 beta,让我们来谈谈最钻孔技术的X-Plane 11 的特点: 完全重新设计的导航数据数据库,这使得像 Aerosoft 和 Navigraph 这样的数据提供者更容易为 X-Plane 导航设施提供数据更新, 同时保持风景的兼容性。

设计新数据库时最重要的目标是消除 X-Plane 世界和 X-Plane 导航系统中数据之间的重复,从而为细微的不一致留下更少的空间。我还想解决 navdata 更新和全球风景的兼容性问题 (主要涉及机场的本地化人员)。其他改进是 SBAS 路径点 (LPV 方法所需) 和 RNP 服务量的集成。最后但并非最不重要的是,我希望能够直接使用 ARINC424 数据,并消除大多数微妙的编码差异,这些差异是由不同的提供商产生的文件与略有不同的转换器产生的。

新数据库的工作始于 2016年4月,当时我与联邦航空局的代表取得了联系美国联邦航空局航空安全中心SUN 'n FUN其中外部数据计划 (EDAi)启动了。初步工作于 4月底完成,并在华盛顿 EDAi 利益相关者会议(The整体跳闸相当a难忘经验)。我再怎么强调联邦航空局的开放数据倡议的价值也不为过 -- 这是你纳税人的钱在工作中的一个例子。

数据库的规范于 9月完成,Navigraph 和 Aerosoft 都获得了以新格式为 X-Plane 11 创建 navdata 所需的工具。事实上,我们并不局限于那些 “两大” -- 因为这个工具对每个人都是可用的,开放数据纯粹主义者实际上可以使用联邦航空局的文件

伴随着统一数据库的巨大力量而来的是巨大的责任: 导航数据只能和它所处的世界风景一样好,尤其是机场。X-Plane 在默认场景中的一些机场跟不上现实世界发展的步伐: 跑道被重新命名 (由于磁位移),延伸, 建成或关闭,X-Plane 的机场风景只有关心它的社区才一样好。为了让他们的生活更轻松,我们目前正在服务器端进行一个大型自动场景更新。我们将很快在风景网关上重命名世界各地数千条跑道,这将解决人们目前面临的新数据库的最恼人的问题: 跑道没有被找到,因为它们已经被重新编号。
然而,这种自动风景更新只是解决方案的一部分 -- 因为我们只能重命名我们拥有的跑道!如果一个机场在现实世界中因为建造了新的跑道而被扩建,我们依靠风景网关和它的难以置信社区对于更新的机场。

我花时间写了更多钻孔技术的关于 X 平面中一切如何协同工作的文章 11:X 平面中的 Navdata 11。如果你是最终用户,你不需要麻烦,因为这是 TL; 博士: 太棒了。它为您提供了客机的 RNP 方法和 GA 飞机的 LPV 方法。

写这篇文章,当我把它与新的用户界面进行比较时,我不禁觉得这部网络漫画中的可怜人因为这正是最终用户将如何体验变化: 大多数人甚至不会注意到。

张贴在显影,文件格式 | 34 条评论

什么是条件

一位用户问我,我们是否会有一个 OBJ 格式的条件指令,让作者根据天气改变对象的外观。我的回答:

绝对不是-这绝对是条件句的意图!

条件句的目标是允许作者处理引擎的多种 “渲染模式”,其中:

  • Sim 的外观在渲染模式和
  • 在较低的渲染模式下工作的性能成本很高。

例如,当阴影关闭时,您必须使用一些 ATTR 状态更改来在对象上放置假阴影。这扼杀了实例,所以当阴影打开时 (sim 需要更多的性能),留下双重阴影不仅丑陋,而且缓慢。

条件的工作原理是完全 “剥离” 对象阴影的命令,然后重新分析它。

所以条件句的胜利是你不为你不使用的东西付费,因为一切都是在负载上完成的 -- 这就像运送两个高度优化的对象。

但不利的一面是: 条件句要求场景重新加载,这是缓慢的、破坏性的和禁止的。这就是为什么我们永远不会将它们用于 sim 中动态变化的东西,比如天气或一天中的时间。

我们想要有天气效果,但是我们的方法将会非常不同: 在物体上有一个 “天气地图” 纹理 (与物体相同的紫外线) 指示由于天气影响,纹理的哪些部分会收到材料的变化。随着时间的推移,这将使物体看起来越来越潮湿,而不会在下雨时重新加载。

张贴在显影,文件格式,风景 | 15 条评论

机场展平

X-Plane 10.45 通过 ICAO 代码排除机场对象,修复了全球机场的一个大 “生态系统” 问题。这使得全球机场不太可能与定制景观发生冲突,即使定制景观没有禁区。

对于 10.50,我正在考虑我们如何管理机场的另一个变化,这将有助于 gateway 作者:每个机场压扁控制。

从 X-Plane 10.45 开始,机场展平是一个用户设置; 用户可以选择让所有机场平坦,或者所有机场遵循地形等高线。

这是一个相当愚蠢的设置。一个尺寸并不适合机场展平,机场的作者比飞往机场的用户更有可能知道机场在展平/不展平的情况下会是什么样子。如果作者不能按照他们想要的方式设置机场,让 X-Plane 社区的每个人单独设置平台当然是无效的。

据我所见,机场平整有两种合法用途。

  1. 为了修复潜在地形中的漏洞,例如,如果 DSF 被搞砸了,那么机场可能需要将其变平以使机场完全可用。我们希望这是例外,而不是规则。(X-Plane 10 比过去的 X-Plane 发布的 WRT 崎岖不平的跑道更有缺陷,所以现在这听起来可能很有趣, 但是总的来说,我们的目标是让用户能够在非平坦的跑道上飞行。)
  2. 为了适应高度定制的机场,三维模型依赖于平面。

在 X-Plane 10.50 中,应该有可能 (使用新版本的 WED) 将机场标记为 “总是变平”。预期的用法是:

  • 用户始终保持 “跑道跟随地形轮廓”。
  • 作者将单个机场标记为需要平整,例如修复错误或适应自定义风景。

有一个用例没有很好地处理: 如果一个机场需要基于不同的基底网格,在机场没有办法标记它。但是我认为这是一个很难用现有技术解决的问题 -- 我们需要一个二维网格来匹配机场的每一个定制版本和曾经存在的每一个版本的网格。

固定网格

请注意,此功能是能够在当地机场从覆盖层定制网格高程的替代品。“网格修补” 是我们长期希望能够做到的,但是对于 X-Plane 的引擎, 这也意味着渲染引擎的工作方式有很多复杂的内部变化; 定制展平是我现在可以在 10.50 中发布的东西,至少有帮助。

展平也不能代替修复基础网格中的错误; 我在 X 平面上观察到的一个趋势 (!)) 源数据的准确性不断提高。十年前,说 “如果每个人都把现实世界的价值观用于他们的风景,它就会起作用” 是愚蠢的。在这一点上,这实际上不是一个白日梦,它通常是完全可以管理的。所以我希望有一天我们能到达一个地形精确的点,每个人都使用它。

到目前为止,我有这个代码在 X 平面上工作,但是我没有一个支持它的 WED 版本。我们仍在研究 10.50 apt.dat 功能,所以我希望能尽快发布一些东西。

张贴在文件格式,风景,工具 | 36 条评论

Blender 2.7 出口商: 新版本

Ondrej 发布了一个关于 Blender 2.7 出口商新版本的公开帖子这里

3.3 版本是我们 (层流研究) 与 Ondrej 密切合作的第一个版本,我们希望它将成为 X 平面建模的未来基石之一。

如果您目前正在使用 Blender 2.49 或 AC3D,我预计 2.73 将为 X 平面建模提供最佳方式。

新东西

新版本有几个主要功能,旨在创建一个新的现代工作流程:

  • 所有动画错误都已修复。(至少,我们认为 -- 如果你找到了,请尽快报告!) 这意味着动画是所见即所得的。动画和动画数据块容器支持支架。
  • 出口商了解所有现代 OBJ 特征,包括 X-Plane 10.50 中计划发布的特征。
  • 实例是通过出口商验证的单一选项来处理的,因此您不必知道实例是如何获得实例的。
  • 材料规则经过验证,材料会自动找到; 你可以简单地按照你的意愿建模,如果有问题,Blender 会尽最大努力导出它或者告诉你。
  • 镜面和法线图从两个不同的来源 “合并” 在一起。这允许您在 Blender 中单独的材质通道中设置镜面反射和法线贴图,以获得更 WYSIWYG 的方法。这也意味着不再用 Photoshop 来组合这些层。

其中许多的目标是隐藏 X-Plane 建模格式的特质,并提供更清晰、更适合艺术家的建模视图。

关于实例: 我们采用的模型是我们在 2.49 出口商内部使用的模型: 你 (艺术家) 将一个出口标记为 “实例” 或不是。

  • 如果启用了实例化,导出器仅将数据写入将由 X 平面进行硬件实例化的 OBJ。如果你做了一些不能实例化的事情,比如动画,你会得到一个导出错误,告诉你必须删除什么。
  • 如果实例关闭,导出器将正常写入对象。

这里的胜利是你不必知道 (复杂的) 实例规则; 为你需要快速批量制作的风景物体设置实例 (例如行李车、房子、将在一个小区域使用多次的东西),你会得到最佳的输出。

优化即将到来

3.3 版本的目标是建立一个作者可以使用新工作流程工作的环境。我们还没有完成优化 OBJ 输出。

如果您将现有的 2.7 导出器用于飞机工作,输出应该在性能上相似。如果您使用的是 2.49 导出器,则新输出 (与当前的 2.7 导出器一样) 没有得到很好的优化。

在未来的更新中,我们将收紧生成的 OBJ 代码; 除了产生更好的 OBJ 之外,这不应该影响任何人。

兼容性

新的出口商应该与之前的 Blender 2.7 出口商完全兼容; 如果你发现你现有的项目不起作用,请提交一个错误!

我们的计划是为 Blender 2.49 项目创建一个迁移工具; 这将将注释、操纵器和对象属性上的数据从 2.49 格式正向转换为 2.73 格式。这使得使用 2.49 的作者可以向前移动到 2.73,并拥有现有内容的迁移路径。(这项工作还没有开始,但是已经计划好了 -- 我们有自己的飞机需要继续工作。)

张贴在飞机,飞机 & 建模,显影,文件格式,风景,工具 | 15 条评论

排除的新方法

MH1212,开发者X-Plane 的预制机场,请求这个功能,看起来我们将能够将它偷偷带入 X-Plane 10.45。(如果我们遇到错误,它可能会被推到 10.50,但是到目前为止事情看起来还可以。)功能是: 排除对象的能力按机场 ID不使用禁区。

现在,当一个定制的风景包取代机场 (通过 apt.dat) 时,旧的 apt.dat 被完全忽略。但是包括基于 DSF 的覆盖对象、立面等; 自定义场景包必须使用禁区来消除它们。

通过此扩展,场景包中基于 DSF 的覆盖对象可以执行好像它们在 apt.dat 文件中,当 apt.dat 机场被替换时消失。这意味着当你替换机场时 (通过 apt.dat 文件),不仅跑道会消失,覆盖元素也会消失。

胜利是这样的: 我们可以通过这种方式从 X 平面风景网关导出我们的全球机场,定制风景将通过替换 apt 自动移除覆盖元素。 dat,即使没有禁区。

以下是一些细节:

  1. 该计划是可行的,底层的机场被正确标记为其物体和正面位于机场 “内部”。因此,与禁区不同,如果修改了底层机场,而不是重叠机场,该方案就可以工作。
  2. 这是一个新计划-没有现有的场景已经这样做了; 必须重新导出场景才能访问此功能。
  3. 该功能需要最新版本的 X 平面,但对旧的 X 平面无害 -- DSFs 仍将加载。
  4. 禁区仍然有效并且仍然被推荐; 如果你正在制作定制的风景,并且你在 autogen 或者一个没有使用这个新方案修改的旧风景包的上面,只有一个禁区会拯救你。

该方案有两大优势:

  1. 我们 (层流研究) 定期将我们收集的数千个机场再出口, 因此,我们可以使用这种新方案标记整个全球机场,并让它们很快准备好按机场 ID 排除。所以这个方案将立即开始帮助冲突。
  2. 该方案根本不需要修改覆盖的风景。有些免费软件机场实际上是孤立的 -- 找不到作者,许可证也不允许社区修改它们 *。由于这些机场不能合法地重新分配禁区,这项技术将会有所帮助。

一旦 X-Plane 有了这个扩展并且全球机场使用它重新出口,全球机场将消失时任何自定义风景包通过 apt.dat 取代机场,即使自定义风景包没有良好的禁区。

该功能将在周三 1.5 测试版中提供给第三方。在周三 1.5 中,如果覆盖元素在机场的文件夹中,当机场被排除时,它将被排除。如果覆盖元素在外部层次结构中是 “松散的”,它将不会被 airport 排除 (但会受到其他包的排除区域的影响)。

由于 gateway airports 已经在 airport 文件夹中有对象,因此已经编写了这些对象来使该方案工作。

如果您使用 DSF2Text 、 DSFLib 源代码或其他疯狂的东西等低级工具创建自己的 DSFs,我已经发布了建议的模式这里。对于修补 DSF 格式本身的人来说,这是一个技术链接,但是如果你属于这一类,请 ping 我以获得早期测试材料。(新代码也在 GitHub 上。)

对自定义风景作者的两个警告:如果你正在创建一个定制的机场景观包,尤其是支付软件,请仔细阅读这些:

  1. 这是停止使用禁区的邀请。在野外有很多没有被机场标记物品的布景包,还有 autogen 和各种垃圾,它们可以在你的 payware 下面。如果您的机场没有禁区,并且它与另一个包冲突,它是你的错。去添加禁区,就像我告诉你的那样
  2. 如果您的包 (通过机场 ID) 从 X-Plane 机场网关移除了一个风景包,那么我们的禁区也会被移除。这意味着,如果跑道上的树木被 X-Plane 机场门户机场移走,你将不再免费获得这些禁区。你必须排除那些树你自己!(如果你把排除区从点 1 放进去,这不是问题。)在启用和禁用全球机场的情况下测试您的机场,以确保您的包是好的。

* 附带说明一下,我认为机场在不允许维护废弃软件的许可证下上传并与社区共享是一个真正的问题。很明显,作者有权使用您想要的任何许可证,但是作为一个社区,我希望我们可以鼓励免费软件作者使用许可的开放许可证。

张贴在显影,文件格式,新闻,风景,工具 | 15 条评论

定期维护和免费通行证

这可能发生在您身上: 您从 X-Plane 机场网关导入最新批准的机场风景包并对其进行修改。当你将你的改进导出回网关时,WED 说你的工作无效并且有问题 -- 但不是你所做的改变!

嗯?如果这是门户上批准的机场,如何在婚礼上也是无效的吗?那个其他作者之前是怎么上传机场的?

你可以获得免费通行证

如果我们发现风景和机场有不好的数据,我们该怎么办错误?如果我们不能为你修理布景包呢?我们一直在使用的政策是: “在下次预定维护之前,您可以获得免费通行证;然后你必须修复这个错误。"

X 平面风景网关就是一个很好的例子。有时我们会发现新的创作错误类别 -- 我对 WED 的场景验证功能进行了改进,以捕捉这些创作错误。这些错误如下:

  • 滑行道标志上的打字错误 -- 旧语法用不正确的字母做一个标志。
  • 重叠的航空交通管制路线-有了重叠的路线,人工智能飞机不能正确滑行。

换句话说,在这些情况下,如果单独放置,婚礼布景包会导致显然是坏事发生在 X 平面内。这不是一个 “旧风格或新风格” 的例子,而是一个 “破碎或固定” 的例子。

所以我们要做的是,我们开始拒绝这些未来上传的风景包,但是我们不要从 X 平面本身删除机场。换句话说,有严重错误的机场得到一个自由通行直到下一次作者进行定期维护。

然后,当一个作者在 WED 工作,并且无论如何都要更新机场时,作者必须解决我们发现的问题。

没有人喜欢消防演习

这个策略是两个极端之间的妥协:

  • 如果我们现在强迫你修理你的机场 (例如 “修理机场或者我们把它从 X-Plane 上移走”),那就不好玩了,那是一次消防演习。在处理新的 OS X 10.11 和 Windows 10 版本时,我已经经历了大量的消防演习, 我同情那些不想停止一切来尽快处理问题的作者。
  • 如果我们从不要求这些问题得到解决,它们就不会得到解决。十多年来,我从 X-Plane 的创作工具中看到的压倒性证据是一些作者不会解决问题,除非工具强迫他们去做。* *

因此,当作者进行维护但不要求修改现有运输的布景包时,我认为这是最好的妥协: 我们仍然可以对严重的错误做出快速反应, 但是我们不会强迫任何人放弃一切。

* 我确实意识到一些作者非常努力地让他们的风景变得正确,即使工具并没有强迫他们这样做!但是这里的目标是全部风景是正确的; 用户安装的数百个场景包中只需要一个坏掉的场景包就能坠毁。

张贴在文件格式,风景,工具 | 3 评论

X-Plane 10.40: 新的 DSF 加载程序

几个星期以来,我一直想写一些关于 10.40 的笔记。我也一直在尝试将引擎盖放回 10.40,这样我们就可以将它公测; 相反,过去几周是一场关于司机漏洞、过期证书等的飞行马戏团。

但是我们正在取得进展,所以我将在这篇文章中首先描述 DSF 加载方式的变化和宽 DSF 盒。

切线: 口吃和停顿

一篇关于 X-Plane 在飞行过程中暂停的帖子总是会引起一堆博客评论: “当我乘坐我真正昂贵的机器飞行时,X-Plane 口吃了! “这不好,从我听到的情况来看,最近情况似乎变得更糟了;bob电竞官网 这是我们现在正在调查的事情。

但我也想提一下,从历史上看,X 平面从不一直 “不停顿”。我们所做的是周期性地缩短停顿时间; 我们的目标是永远降到零停顿, 但这将通过找到每个暂停来源并一次修复一个来实现。换句话说,我们正处于提高平滑度的过程中,但是即使暂停的一个来源是固定的,另一个来源可能仍然会引起问题。

DSF 加载: 旧方法

从 X 平面 9 开始,当你飞行时,X 平面已经将 DSFs 加载到第二个核心的背景中。这减少了改变风景所需的时间。(X-Plane 的旧版本会在风景被加载和移动时暂停。)

旧的 DSF 加载器确实有一些弱点:

  • 删除 DSFs 时,sim 暂停。随着 DSFs 变得越来越大,这种暂停变得越来越明显。
  • 如果装载机有两次换班,它就会一直等到赶上。这就是可怕的 “30 秒后异步加载超时” 出现的地方 -- 这表明 DSF 加载器远远落后,它锁定了半分钟,没有赶上。
  • 旧的 DSF 加载程序每次加载一个 DSF,最多。

DSF 加载新方式

X-Plane 10.40 具有新的 DSF 加载器,它在工作线程上加载和卸载 DSF,以保持飞行平稳。它还将一次加载多个 DSF,仅受不同时加载相邻 DSF 的要求的限制。

X-Plane 10.40 也可以选择扩展的 DSF 风景区域以获得更清晰的地形; 关闭此选项后, 在 sim 启动期间,一次加载两个 dsf,飞行期间一次加载一个或两个 dsf。打开扩展 DSF 区域后,在 sim 引导期间会同时加载多达四个 DSF,并且在您飞行时会加载一个或两个 DSF。

扩展的 DSF 风景区域是可选的; 如果你使用的是高清网格或者你缺少内存,不要使用这个。新的 DSF 加载程序始终处于打开状态。

张贴在文件格式,新闻,风景 | 60 条评论

RFC: 库依赖项

这是另一篇 “征求意见” 的帖子 -- 请在评论中讨论建议; 如果你评论询问你的评论将会Piped to/dev/null

图书馆系统有一个方面充当了一个没有保护的角落,定期戳用户: 一些风景包需要其他风景包发挥作用。例如,许多免费的机场景观包需要OpenSceneryX。当库包不可用时,X-Plane 将不会加载自定义包,因为它缺少艺术资产。* 用户经常向我们报告这是一个错误。

在我看来,这里最大的问题是用户无法从 X-Plane 的诊断信息中知道他们应该安装什么库。诊断消息没有用,因为X 平面也不知道。所有的 X-Plane 都知道有一个图书馆之路,没有人为它提供艺术,因此生活不值得活下去。

建议: 库包依赖项

我的提议是这样的:

  • 图书馆风景包可以声明它的 “官方名称”,例如 “opensceneryx” 或 “proaddons/trees” 或其他什么。像插件名称一样,目标是选择一个与您的身份相关联的相当详细的名称,以避免冲突。此指令将进入您的 library.txt 文件。
  • 一个风景包需要该库声明需要同名的库。
  • 当 X-Plane 试图从风景包中加载艺术资产时,如果系统中没有至少一个相关库,则错误消息会更改为类似

无法加载风景包 “KLAS Las Vegas”,因为未安装库 “OpenSceneryX”。

Log.txt 文件将包含完整的细节,但希望最终用户清楚 (er) 出了什么问题: OpenSceneryX 是错误的,因此不能使用 KLAS Vegas。

链接是如何制作的

为了使这个建议有效,需要 X 库的风景包必须包含一个这样说明的指令。因此,这个提议不是万灵药现存的负载问题。从长远来看,这将会有所帮助,因为用这些指令创建了新的风景包和图书馆。

如何建立链接?世界编辑工具 (或其他风景编辑工具) 通过查看作者机器上的依赖项,并在用户选择 “构建” 时将它们复制到风景包中,自动将依赖项写入风景包中。因此,只要库有正确的 “命名” 注释 (这确实需要库作者更新),那么用 WED 制作的新包将自动包含正确的依赖项。

讨厌的细节

一些令人讨厌的细节:

  • 库包需要包含它们的 “永久” 名称和某种 “人类可读的名称” 来进行错误报告。
  • 自定义场景包中的依赖语句将列出所需库的永久名称和人类可读名称的副本; 如果我们需要 “librutures” 并且它丢失, 我们不知道它的真名是 “俄罗斯树 2.0”,除非它在构建时被复制了。
  • 依赖关系也需要一个整数版本号。这允许我们声明安装库的情况,但它太旧了。

X-Plane 的内置库不会包含依赖项名称,因为它们总是可用的。

场景包的依赖项名称将写入 DSF 属性; 不保证或不需要非库场景包具有 library.txt 文件。

未结问题:如果一个场景包声明了一个依赖项,并且它丢失了,如果所有的艺术资产都存在,它应该被允许加载吗?这是更宽松的用例,但它意味着一些相当奇怪的事情正在最终用户的机器上发生。在过渡到使用依赖项名称期间,允许可能是可取的。

它会起作用吗

图书馆系统 (已经有好几年了) 允许 “占位符” 物品被声明在一个布景包中,作为丢失物品的后备。用例是这样的:

  • OpenSceneryX 提供了一个 “回退” 包,该包直接转储到风景包中,每个库路径都有空白对象。
  • 如果最终用户安装了 OpenSceneryX,他们会看到真正的艺术。
  • 否则他们什么也看不到-回退是空白的,并且不会产生错误。

从报告缺少 OpenSceneryX 对象为 “bug” 的用户数量来看,这似乎很清楚工作。使用 OpenSceneryX 的作者并不费心复制 “回退” 包。这甚至可能不是一个错误 -- 也许作者不希望在没有安装 OpenSceneryX 的情况下查看他们的作品。然而,我的猜测是,作者只是不知道回退包的存在。由于作者安装了 OpenSceneryX,他们不需要后退,甚至不知道它是否正常工作。

我希望从长远来看,库依赖方案可以更成功,因为它不需要单个风景作者采取任何行动,只要少数库维护人员更新他们的库。注释风景包的工作是自动的。

* 请不要试图说服我 X 平面应该做的是忽略这个问题并继续。有了上面提出的 RFC,我们可以做一些不那么激烈的事情,比如如果图书馆不存在,就不要加载风景包。但是我强烈反对 “尽我们所能并继续前进”。

如果 X-Plane 将作者身份中的错误视为可接受的结果,那么试图完成实际工作的作者将不得不做更多的工作来检测他们自己的作者身份中的人为错误。我们需要一只虫子成为一只虫子。

张贴在文件格式,风景,工具 | 18 条评论