类别: 插件

我们的着色器不喜欢被触摸

X-Plane 总是附带对每个人可见的着色器,在资源/着色器目录。部分原因是为了方便将着色器加载到 OpenGL 本身,但是我们也没有任何东西可以隐藏在那里,所以尝试隐藏它们没有多大意义。非常欢迎您查看并戳戳我们的着色器,如果您在这个过程中了解了一些关于 X 平面的信息,那就太棒了!

然而,有一个很大的警告是,我们从未认为着色器是公共可访问接口的一部分,它们在不同版本中是不稳定的。X-Plane 是一款积极开发的产品,我们正在对代码库进行大量更改,包括着色器,因此您永远不应该分发修改着色器的插件或工具。因为我们不能保证我们的着色器在不同版本中保持稳定,所以你总是担心我们可能会破坏你的附加组件。

此外,11.30 中的着色器系统有一个很大的变化,这肯定会破坏所有正在修改着色器的现有插件。这篇博客文章将涵盖即将到来的变化,并希望让每个人相信着色器系统是不断变化的,而不是作为附加组件的基础。bob电竞官网阅读更多

张贴在显影,插件 | 30 条评论

窗口小部件,你现在喜欢!

我最近收到了一些来自第三方开发人员的电子邮件,询问以下问题:

我有一堆基于 XPWidget 的 windows。我什么时候才能将它们与用户界面扩展、弹出支持、虚拟现实支持等新奇的新功能一起使用。?

令人高兴的是,答案是:现在!

我真的把这个埋葬了,但是回到 X 平面 11.20,作为为 VR windows 添加插件支持的一部分,我们为基于 XPWidget 的插件添加了一个新的 “模式”。这一切都开始于调用选择加入这样的 “现代” 窗口 api:

XPLMEnableFeature(“XPLM_USE_NATIVE_WIDGET_WINDOWS”,1);

从现在开始,您创建的所有小部件窗口都将由现代的XPLM 窗口,因此可以与全部新的XPLMDisplayApi。从那里你所要做的就是打电话XPGetWidgetUnderlyingWindow() 获取XPLMWindowID你的窗口传递给这些 api。

张贴在插件 | 评论关闭在窗口小部件,你现在喜欢!

插件开发人员: 请尝试此修复

X-Plane 11.20r2 只有一个我们试图修复的错误: 插件 SDK 中的一个错误,它会导致一些插件在创建和销毁窗口时崩溃。

泰勒和我深入研究了这个问题,发现修复比我们在 RC 后期想要的更具侵犯性。

所以: 如果你是一个插件开发人员,并且你正在使用新的 SDK,或者为了虚拟现实兼容性,使用新的 3.X api,或者仅仅因为你正在更新插件, 这个周末你有时间,请发邮件给我,我可以给你发送我们新的固定 XPLM DLLs。

我的希望是让六个插件开发人员在周末攻击他们,这样当我们削减 11.20r3 时,它真的会发布。

编辑:RC3 已上线-感谢所有帮助过我的人!

张贴在显影,插件 | 4 条评论

让我们谈谈 CEF (更多)

CEF 柱产生了很多争议,我想我应该在这里收集我对主要反对意见的回应,而不是直接在评论中回复 (并做大量复制和粘贴)。

反对: 没有人想在 X 平面浏览网页!

是和不是。我同意,除非你在虚拟现实中,一个成熟的网络浏览器是完全无用的。没有人想在飞行时浏览猫的照片。但是 CEF 真的旨在为传统网络浏览器提供动力。

考虑一下这一系列的其他没有人想要 web 浏览器的应用程序:

  • Spotify
  • Adobe Acrobat
  • Evernote
  • 蒸汽客户端
  • Atom 文本编辑器
  • GitHub 桌面客户端
  • WhatsApp

所有这些应用程序有什么共同点?他们是内建CEF,或密切相关的电子项目。

我的观点是: CEF 的主要用例是构建一个成熟的浏览器 -- 它支持像 HTML5 用户界面这样的东西,大规模降低创建漂亮、易于使用的插件的门槛。它还可以支持显示 PDF 图表或其他电子飞行包功能 -- 理论上没有网络视图是可能的, 但是这些国家的进入门槛如此之高,以至于没有人想解决它们。

我们是一直寻找两者的方法

  • 让更多的人参与创建 X 平面附加组件,以及
  • 给现有的插件开发人员更好的工具,这样他们就可以创建以前没有的东西。

这样做使 X-Plane 社区更加强大,并支持创建原本可能不存在的附加组件。

反对: 这是浪费时间。什么你正在努力的是 [的一些其他特征]。

正如我之前提到的,CEF 现在正在 X-Plane 中使用,以实现应用程序内升级。这显然是最钻孔我们可以运送的非功能,我理解为什么超级用户 (可能在第一天购买 X-Plane 11 的人!) 被激怒了。

事实是: 我们为最终用户提供的一些功能*,还有一些我们发货是为了 “付账单”。 “支付账单很无聊,但很重要: 让 X-Plane 在财务上取得成功可以确保我们能够继续改进 sim (咳咳,以最终用户真正关心的方式!)) 在未来的几十年里。在这种特殊情况下,我们有理由相信当前的采购过程是错综复杂的,它正在失去美国的销售。应用程序内升级将增加一些 (小) 百分比的销售,所以即使它不是一个直接的对现有用户的 sim卡进行改进,为未来的发展提供资金。

还有一件事值得一提,那就是 “我希望你这样做”x相反,“我们现在有少数全职开发人员,他们专门从事非常不同的领域,所以我们倾向于在任何时候都有很多正在开发的功能。当然不是这样的,比如说,西德尼在我停止整合 CEF 的时候停止了提高性能的工作。

反对: 我不想要使用 webviews 的 X 平面插件!

我们进行讨论的原因是插件开发人员已经使用 CEF -- 他们这样做的方式与其他开发人员的实现。

我们当然可以选择把头埋在沙子里,忽略这一点 -- 我们可以强迫用户在两者之间做出选择,比如说, 安装飞行因子飞机和安装一个花哨的新的基于网络的插件 (或使用未来的 X-plane 核心功能)。然而,这最终伤害了原本会选择 “以上所有” 的最终用户,也伤害了因用户强制的选择。

我们不能阻止附加制作者使用 webviews,但是我们确保这样做不会给最终用户带来兼容性噩梦。

反对: CEF 代表一个巨大的安全漏洞!

这绝对是我们关心的问题。X 平面中的 web 视图呈现两个主要的攻击面:

  1. 运行不受信任的代码的可能性 (例如,一个邪恶的网站利用浏览器漏洞在你的机器上执行有害的代码)
  2. 将数据发送到你不想让它去的地方的可能性 (例如,一个邪恶的网站伪装成你银行的网站,并将你的登录信息发送给坏人)

我们仍处于 “探索” 阶段,试图了解插件开发人员的需求,但是我们有很多方法可以减轻这些威胁。几个可能性,从最极端到最少列出:

  1. 根本不允许远程连接; 插件创建的 web 视图只能加载局部的与插件捆绑在一起的资产 (HTML 、 JS 等)
  2. 完全禁用 JavaScript
  3. 需要插件来提供被认为可以安全发送和接收来自
  4. 禁用从外部 (或非白名单) 域加载的 JavaScript
  5. 允许用户首选项控制上述策略 (甚至完全禁用 webviews)

反对: CEF 会减慢 sim卡的速度。这是膨胀软件!

那是由测量来决定的!在我们的测试中,让 CEF 在飞行时显示静态页面并没有降低我们可以测量的 sim 速度。由于 CEF 不在主 X 平面线程上运行,操作系统可以安排 CPU 密集型的事情,比如围绕 X 平面工作的页面加载。肯定有一些内存开销 (几百兆字节),但考虑到 X 平面的现有足迹,这不是一个疯狂的量。

而且,就像 X-Plane 中的所有东西一样,如果你想调整它以获得最后一点性能,你可以自由避免使用依赖于 web view 的功能和附加组件。

反对: 不要使用 CEF -- 你应该使用 WebKit 、壁虎、伺服系统等。

我做了一个批次研究和测试实现 (在 Windows 上,我甚至使用了三叉戟,互联网浏览器的底层引擎!),和我发现满足 X-Plane 要求的 webview 框架是 CEF。

* 旁白: 11.20 对最终用户来说包括什么?几个亮点来自发行说明:

  • VR 支持
  • 澳大利亚新悉尼地标
  • 一种新型 Aerolite 103 模型
  • 彻底改革的哥伦比亚 400
  • 1,315 机场新的 3d 风景
张贴在插件 | 23 条评论

让我们谈谈 CEF

在 X-Plane 11.20b1 中,我们首次发布了 web 浏览器。我们正在使用铬嵌入框架 (CEF) -- 本质上与铬一样的内脏,包裹在 X 平面内。

目前,它只在一个地方使用*: 支持应用程序内升级,这样如果您有演示,您就可以购买 X-Plane 的完整版本,而无需访问网站。网络视图是无缝的 -- 你不能通过查看应用程序来判断它不仅仅是本地 X 平面用户界面的一部分。

虽然它目前的使用相当有限,但如果一切顺利,我们愿意在 sim 的其他地方扩大它的使用 -- 在辉煌的未来™,我们可能会用它来加载在线图表等。

但是,有一个问题!

没有一个好方法可以一次加载两个 CEF 副本。并且,因为一些插件 (像在新的A320 终极飞行系数) 取决于由 (全局) 插件提供的 CEF 版本,我们必须在该插件存在的情况下禁用 X-Plane 的 web 浏览器功能。这现在没什么大不了的 -- 毕竟,如果你已经安装了 payware,你可能已经拥有了 sim卡 -- 但是如果在辉煌的未来,这将是一个耻辱™,您必须在您的 payware 和核心 X 平面功能之间进行选择。

这种情况比你想象的还要糟糕: CEF 绝对不支持应用程序生命周期中的多个初始化调用 -- 你不能初始化它,关闭它, 然后重新初始化它。这意味着它甚至可能的为了让插件作者成为好公民并 “放弃” CEF 到 X 平面,这样你至少可以在任何时候使用 X 平面的浏览器使用依赖于它的附加组件。要么全有,要么全无!事实上,你必须卸载X-Plane 之前的 CEF 插件可以使用 web 视图本身。

这里有两个可能的修复:

  1. 在将来的某个时候,我们通过插件 SDK 提供对 CEF 的访问。如果我们做了,那一定是CAPI只有-没有花哨的 C + + 包装你。作为一个人的记忆写的 C API 的新鲜的主意,让我说: 这不是很有趣,而且Rife有可能发生内存泄漏。此外,这将断路任何依赖于 CEF 的现有插件-它们将是强制的迁移到 API 的 SDK 版本。
  2. 我们可以 (理论上) 编译一个特定于 X 平面的 CEF 版本与插件使用的版本冲突。这将需要重命名 Mac 上的所有目标 C 符号,并重命名 Windows 上的动态链接库。我没有调查这个可行性,但它肯定理论上可能。这将允许 X-Plane 版本的 CEF 与 (一个) 插件提供的副本共存,尽管在CPU 和内存成本。

让我们通过 SDK 公开 CEF 并不是一个明确的胜利。CEF 是众所周知的版本之间不兼容-您可以或多或少地保证即使微小的更新也会破坏 API 的兼容性某个地方。这意味着 X-Plane 会被固定版本的 CEF 卡住至少主要版本的生命周期,以防止破坏插件。X-Plane 11.20 使用 CEF release 3202; 这将是至少在我们将 CEF 更新到更新版本之前,下一个主要版本。这有两个主要缺点:

  1. 当 X 平面更新到那个新版本时,它会断路针对依赖 CEF 的旧版本 SDK 编译的插件。这比我们正常的贬低策略更具侵略性,并且它使 CEF 插件成为插件开发人员潜在的维护难题。
  2. 如果你的插件真的,真的需要来自最新和最伟大的 CEF 版本的功能,你就倒霉了 -- 等几年 (!!) 和也许我们会更新的。

所以,以下是我想从插件开发人员那里听到的:

  1. 你现在是,还是打算将来使用 CEF?
  2. 你愿意只使用 CEF API 的 C 版本吗?
  3. 你能接受 X 平面决定的 CEF 版本和兼容性的限制和潜在的头痛 (上面概述) 吗?

如果你不介意告诉我一些你想要的用例,那也很有帮助!

编辑添加: 这里有第三个选项我没有考虑: X-Plane 可以在 CEF 周围提供一个 “包装”,它 “只是” 一个浏览器表面, 和简单的接口,如以编程方式更改 URL 的能力。这有一个优点,那就是我们可以在不破坏 API 的情况下定期更新 CEF (尽管新版本的铬总是有改变它处理 HTML + CSS + JS 的方式的风险)。缺点有两个:

A) 如果一个插件开发者真的,真的需要 CEF API 的全部功能, 他们运气不好 (或者我们又回到了必须禁用核心 X 平面功能以支持插件的问题上)。

b) New XPLM APIs are a massive tax on our development time. Every time we need to make a change, we have to go test a dozen plugins… then go through an extensive beta… then inevitably hear about a show-stopping bug we introduced three hours after a release goes final. In contrast, providing a (major-version-stable), transparent copy of CEF costs us very little dev time; time that would otherwise be spent maintaining the XPLM API can be spent on, like, major features.

* 旁白: 这实际上是我们测试一个批次X 平面上的新技术: 我们找到一个相对偏僻的地方来利用它,在一个主要的版本更新中发布它, 等着看它是否爆炸了。Betas 发现了很多错误,但不是全部,所以这是一种对冲我们赌注的方法,当涉及到尚未经久不衰的代码时。这就是我们如何从用户界面框架 (飞机制造商的面板编辑器是试验台) 、 X-Plane 11 粒子系统 (幕后, 它被用于 X-Plane 10.51 中的一些非常小的效果),以及更多。

张贴在显影,插件 | 48 条评论

插件: 不注册不绘制的绘图回调

插件开发人员: 标题说明了一切 -- 不要注册一个实际上没有绘制任何东西的绘图回调。

当我这样写的时候,听起来有点傻,但是一些插件在启动时注册了一个绘图回调,因为他们可能画一些东西 -- 但是只有当某些事情发生时才画。我自己也有罪-Libxplanemp寄存器在初始时间绘制回调即使没有多人飞机可以画。

大多数插件这样做是为了简单,为了避免任何关于何时可以注册的奇怪规则 -- 最初的 1.0 SDK 比我们现在拥有的要挑剔得多。回到 1537 法国人入侵佛兰德的时候, 一个 no-op 一个 draw 回调的成本是相当便宜的-只是函数调用的成本和一些书籍保存的说明。

随着时间的推移,随着 X-Plane 的渲染器变得越来越复杂,情况并非如此。当我们点击绘图回调时,X-Plane 现在做了一些重要的工作来保存和恢复 GL 状态,并且开销将会变成显著地当我们搬到 Vulkan/Metal 时会更贵。

为了优化这一点,Tyler 修改了 11.10 中的绘图回调代码-如果我们发现,从 11.10 开始没有插件注册了一个给定的绘图回调,我们跳过了整个过程,包括 OpenGL 图书保存。

因此,如果您的插件进入并注册回调每个绘图回调类型然后我们必须回到慢速路径,小心地隐藏我们的 GL 状态,并为您在每个绘图回调点的运行做准备。

这是我的指导:

  1. 永远不要注册你不会使用的绘图回调。
  2. 请延迟注册绘图回调,直到它是可能的需要它。
  3. 不要试图通过注册和取消注册每帧来优化您的绘图回调。

因此,作为一个例子,当第一架飞机进入系统时,多人游戏 API 注册一个绘图回调是合理的,然后保持它直到最后一架飞机离开, 即使那架飞机不在屏幕上。

(最后一条规则的原因是: 如果我们必须在发现绘图回调后进行昂贵的图形转换需要的是,我们不想让回调消失,然后一遍又一遍地出现。)

张贴在显影,插件 | 13 条评论

机械手和 VR 第一部分: 从鼠标到机构

对于飞机作者来说,虚拟现实带来的最大问题是: 我必须对我的飞机做什么才能让它工作?这是三篇文章中的第一篇,不仅解释了操作如何与虚拟现实一起工作,还解释了我们为什么做出决定以及我们是如何来到这里的。请耐心等待 -- 这将以关于如何处理您的飞机的具体建议结束。

很久以前…

像我这样的老前辈会记得,当 3d 驾驶舱首次问世时,几乎所有的 “大脑” 都是通过点击 2d 面板来驱动的, 它被 “映射” 到三维驾驶舱。X-Plane 会找出你的鼠标点击与三维驾驶舱相交的位置,找到三角形上的纹理位置,并将其映射回二维面板。

这在 15 年前问世时看起来很酷,但是随着作者开始制作更复杂的三维驾驶舱,很明显我们需要一种方法来说明鼠标是如何工作的直接使用三维驾驶舱形状,因为映射回二维不允许用户做一些基本的事情,比如拖动油门。

因此,在 X-Plane 9 中,我们在驾驶舱的三维网格上添加了第一组操纵器标签,指定当用户点击它时会发生什么。操纵器可以指定要修改的数据范围、要启动的命令以及一些关于正在发生的鼠标点击操作的数据。

这里的关键词是鼠标点击。最初的操纵器完全是根据二维屏幕上的鼠标设计的; 它们被设计成与二维面板系统完全一样强大,二维面板系统粗糙也完全以鼠标为中心。通用仪器和原始操纵器之间的关系相当紧密。

转向机制

原始操纵器系统的优点在于它非常灵活 -- 以鼠标为中心的处理程序是一种低级工具,作者可以在它周围做任何他们想做的事情。

这种设计的缺点是,以鼠标为中心的处理程序是一种低级工具,作者可以围绕它做任何我们想做的事情。我们检查了我们自己的十几架飞机的默认机队,发现没有两架飞机的驾驶舱以同样的方式运行, 几乎所有人都至少有一些难以使用的方面 -- 这是一个糟糕的工作操纵者选择。

旋钮尤其困难 -- 最初的二维面板系统使用旋钮上的点击和保持来驱动它, 但是从事 3d 工作的作者经常使用拖动动作来做旋钮,并且拖动动作会根据相机角度做出不同的反应。我们收到了大约 8,452,124 份错误报告,报告称 747 的旋钮很难使用,特别是因为这个。

所以在 X-Plane 10 中,我们在 X-Plane 中添加了一些新的操纵器,他们有一个非常不同的哲学: 操纵器描述了模拟飞机中发生的事情, X 平面选择了一个鼠标行为来使其工作。新的操纵器描述了转动的旋钮和左右或上下翻转的开关。这些操纵器自动对滚轮做出反应,因为 X-Plane 知道旋钮是什么因此,合理的滚轮互动应该是什么。(通过比较,与旧式操纵器,作者必须指定什么是合理的滚轮动作。)

真正的互动之前的事情很酷

事实证明,以机构为中心的机械手是批次虚拟现实比以鼠标为中心的虚拟现实更好。考虑两种情况:

  • 二维轴操纵器 (ATTR_manip_drag_xy) 指定当鼠标相对于屏幕上下和左右移动时会发生什么。开什么接地这是否意味着在虚拟现实中?即使我们做了一些相对于 HMD 屏幕上下和左右跟踪的东西, 结果会非常奇怪,因为驾驶舱里的 “东西” 不会像你的手那样移动。有了鼠标,鼠标和飞机之间的错误匹配并不奇怪,但是在虚拟现实中,伸出手触摸东西,让它表现错误是很奇怪的。
  • 旋钮操纵器。它描述了当顺时针或逆时针转动时做事情的旋钮。这很容易处理 -- 你用你的控制器点击它,然后按时钟或逆时针转动你的手腕,它就会转动。因为我们知道机制是什么 (不仅仅是鼠标应该做什么),所以我们可以在虚拟现实中做出如何处理这个操纵器的好决定。

事实证明,我们遇到了这样一个问题,即不用鼠标做什么,在我们开始研究虚拟现实之前,我们需要知道机制是什么。同样的问题 (“我想触摸 3d 驾驶舱,就像它是一个东西一样,并让它以预期的方式做出反应”) 存在于虚拟现实和 X-Plane Mobile 上!

因为 X-Plane mobile 在触摸屏上运行,并且你的物理手指在开关上,所以在很多情况下,开关必须非常好地跟踪并以正确的方式工作。如果开关上升和下降,你想抬起手指来打开开关; 如果它向左-向右移动,你想向左和向右移动, 其他任何事情都是惊人的。

所以 X-Plane mobile 让我们走上了基于机械的机器人的道路,而虚拟现实进一步将我们推向了那个方向,因为两者都有相同的物理特性, 用户直接与三维驾驶舱交互的非鼠标环境。

作者指南

所以作为一个作家,你应该做什么在三维驾驶舱工作时?我的答案是: 使用一些操纵器,而不是其他的,来模拟三维的工作方式。

始终使用这些操纵器

这些操纵器是创建某些物理机制的最佳方式 -- 每次这种情况适用于您的飞机时使用它们。

ATTR_manip_drag_axis。将此用于沿线性路径滑动的物理机制,如塞斯纳的油门手柄。

ATTR_manip_drag_rotate。将此用于围绕固定点旋转的物理机制,如 737 的节气门手柄或修整轮。(比起沿着油门手柄的边缘放置拖动轴的旧技术,我更喜欢这样。)

ATTR_manip_noop。用这个来制作一个机械手,它阻止它后面的机构被触摸,例如开关上的安全护板。

ATTR_manip_command。使用此按钮可以在按下按钮时瞬间启动,就像按下和按住按钮驱动启动器一样。

Attr_manip_command_旋钮,attr_manip_command_switch_up _ down,attr_manip_command_switch_left _ right。使用这些旋钮和开关 3 个或更多的位置旋转或移动。为机构选择正确的机械手!

ATTR_manip_axis_knob,ATTR_manip_axis_switch_up_down,ATTR_manip_axis_switch_left_right。这些提供了一个替代上述操纵器,当你必须使用 dataref。我们建议您在任何时候选择 datarefs 上的命令; 命令系统在自定义插件、自定义飞机和自定义硬件之间提供更好的互操作性。

ATTR_manip_command_switch_left_right2,ATTR_manip_command_switch_up_down2,ATTR_manip_command_knob2。使用这些正好两个位置的旋钮和开关。你可以使用这些来获得一个简单的鼠标点击切换 (对鼠标用户来说更快更容易),同时在虚拟现实中获得真正的三维移动。

有时使用这些操纵器

这些操纵器并不完全适合物理运动,可能需要对虚拟现实进行调整,但它们是我们现在针对某些问题的最佳选择。如果可以的话,试着使用 “总是” 列表中的内容。如果您模拟的机构与上面列表中的内容相匹配,请不要使用这些操纵器。

ATTR_manip_drag_xy。这是我们唯一的两轴阻力,也是眼球通风口和轭的最佳选择。轭在虚拟现实中是特殊的,应该基于二维 xy 机械手。我们正在研究虚拟现实中更强大的多维操作,但是这项工作不会在 10.20 完成。

ATTR_manip_command_axis。该操纵器基于向下或向上移动杠杆运行一次命令。你可能应该使用拖动轴或命令上下开关,但是在飞机上可能有一些奇怪的机制,这个操纵器非常合适。它不应该是你的首选操纵器。

Attr_操纵推,attr_操纵无线电,attr_操纵切换。当您绝对必须写入 dataref 而不使用命令时,这些操纵器可以作为按钮样式控件的替代。警告: 永远不要将这些操纵器用于移动,例如,不要将这些用于香蕉开关、旋转旋钮或类似的东西。

不要使用这些操纵器

这些操纵器用于以鼠标为中心的运动,应替换为旋钮或开关操纵器。

ATTR_manip_delta,ATTR_manip_wrap。这些被设计用来通过点击并按住来模拟旋钮,而是使用旋钮操纵器。

ATTR_manip_drag_axis_pix。这是为了通过点击和拖动来模拟旋钮,而是使用旋钮操纵器。

我们喜欢命令

正如你可能已经从这个列表和不断增长的 X-Plane 内置命令列表中注意到的,我们喜欢命令 -- 它们已经成为我们飞机的首选机制。命令比数据参考有一些优势:

  1. 插件系统中有一个清晰的设计来改变命令的行为。因此,第三方飞机可以很容易地 “接管” 现有的发动机启动命令。这是非常非常难以通过 datarefs 来完成的。
  2. 命令可以直接映射到操纵杆和键盘硬件。没有办法将操纵杆绑定到数据区域。*
  3. 命令可以被映射到声音来捕捉用户 “做” 事情的行为,不管它是否有效。例如,如果你想点击起动机开关,不管起动机是否接合 (也许电池没电了),命令可以让这变得容易。通常没有 “用户正在尝试但它不起作用” 的数据。

在 X-Plane 11 中,我们一直在向命令移动,让我们的飞机同时为虚拟现实、新操纵器和 FMOD 声音做好准备。

在下一篇文章中,我将介绍一些虚拟现实和三维驾驶舱特有的问题。

* 编写为 X-Plane 提供外部接口的插件的开发人员: 确保您有办法提供对命令的访问,而不仅仅是数据空间!有些事情你只能用命令而不是 datarefs。

张贴在座舱,显影,插件,虚拟现实 | 12 条评论

针对 SDK 3.0 的新插件包装

这是一个小特性,但是对于插件开发人员来说,它可能会在工作流程上产生巨大的差异。

在插件系统中,直到版本 2.1 (我们通过 X-Plane 11.05 运送的所有东西) 插件都是这样包装的:

My_plugin/64/mac.xpl my_plugin/64/win.xp

这有一个问题:您安装的插件要么命名为 mac.xpl 、 win.xpl,要么命名为 lin.xpl。

事实证明,几乎每个调试工具都假设每个 DLL 都有自己唯一的名称,因为否则会很疯狂。我决定在 fat 插件结构中命名操作系统,这是一个非常愚蠢的决定。

使用 SDK 的 3.0 版本,您现在可以这样打包:

My_plugin/mac_x64/my_plugin.xpl

有了这种格式,每个插件的名称都使其 DLL 独一无二。

这应该解决一堆事情:

  • 你将能够通过 X 代码启动 X-Plane 来调试你的插件,而不会失去一切。
  • Windows 调试工具上的回溯应该使插件执行清晰,即使没有符号。
  • 任何类型的内存映射转储 (包括苹果崩溃报告中的那些) 都将明确显示加载到哪个内存地址的插件代码。

现有的 2.0 格式 (上面显示的 fat 插件) 和 1.0 格式 (瘦插件,仅在全局插件文件夹中支持) 将继续无限期地工作 -- 它们仍然存在。

但是如果你打算瞄准 X-Plane 11.10 并使用新的插件系统功能,你可能想使用新的包装并避免一些调试混乱。

张贴在显影,插件 | 10 条评论

XPlane2Blender v3.4.0-beta.5 到货

在此下载:

https://github.com/der-On/XPlane2Blender/releases/tag/v3.4.0-beta.5

变更日志

新功能

生成版本号

Xplane2blender 的新版本号系统将允许我们调试。混合和。Obj 文件更快。它还应该使数据模型的更新更容易实现。

  • 每一个出口。Obj 文件的页脚包含关于插件版本、编译时间以及原因的信息。例如:3.4.0-beta.5 + 1.20170922151901

组件的分解

  • 3.4.0: 传统的混合插件数
  • 测试: 我们所处的构建周期类型。你可能看到的其他选择是开发(开发人员构建),阿尔法,阻容(用于完全释放)
  • 5: 我们正在使用的构建类型版本。因为这是 beta 5,所以构建类型版本是 5。

+ 之后的元素对普通用户来说通常意义不大

  • 1: 数据模型的版本 (XPlane2Blender 的属性和设置,用于比较更改
  • 20170922151901: “内部编号” 日期此源代码以 UTC 中的 YYYYMMDDHHMMSS 形式打包并发布。
通信

在 “场景设置” 下的 “构建版本号” 部分显示 (隐藏 + 之后的元素)复合法线纹理,可能伴随着关于您正在使用的构建的稳定性的警告。

例子

当启动此版本的测试版时,您将看到以下内容:
Scene_version_comminucation

面向公众的 3.4.0 的未来稳定版本将显示以下内容:
Scene_version_communication_rc_ex
请注意绿色复选标记和缺少任何警告。

在未来 3.4.1 的前阿尔法周期中,两种类型的人将会看到以下内容:
Scene_version_communication_dev_ex

  1. 编写和测试未发布代码的开发人员
  2. 没有领导警告不要使用这样的代码的人,或者被核符号和关于缺少构建号的额外警告吓跑的人

这是稳定性和可追溯性的最坏情况,因此是核符号。

为什么关于缺少内部版本号的额外警告?

缺少内部版本号表明您没有与知识渊博、细心的开发人员进行良好的对话 (电子邮件、聊天、此发布页面或其他渠道)。这意味着你的工作更有可能通过坏版本的代码并被损坏,否则你的错误将更难诊断和修复。
Scene_version_comminucation_rc_no_build_nmbr
在这种情况下,尽管代码似乎来自代码发布附近的稳定时代, 有可能是错误的,并且有非常糟糕的方法来追踪它可能是什么 -- 因此没有绿色复选标记和大红色警告符号。

如果你看到一些你想尝试的新的 pre-alpha 功能,就先问问我们。展望未来,我们想从一个关于潜在危险、测试和不完整特征意图的对话开始,而不是稍后的尸检。不要害怕,我们总是喜欢在有问题之前收到用户的来信,而不是之后!

构建版本历史记录

还有,所有人。Blend 文件将记录他们打开和保存的 XPlane2Blender 的每个不同版本。这是自动的,不需要用户的参与。那些好奇的人可以在场景设置底部的插件开发工具部分查看他们的文件历史。

注意: 这不会记录关于 Blender 版本、使用的其他插件版本、打开或保存的时间戳或对其所做更改 (包括 XPlane2Blender 设置更改) 的任何历史数据。它作为一个调试工具是非常有用的,并且不是傻瓜证明。
Build_history

这个。Blend 文件以遗留文件开始3.4.0 pre-beta.5文件,然后是 3.4.0-beta.5 的副本,没有构建号。然后,它是用来与 3.3.12,最后,用于建立 3.4.0-beta.5 09/18/2017 上创建的 01:27:30 am。

人们可以利用这些信息来猜测数据在其旅程的每一步中可能经历了哪些转变。

张贴在显影,插件 | 1 评论

插件兼容性和新 XPLM 3.0 功能

泰勒发布了一些新功能来到 X-Plane SDK 3.0 版 API (一旦我们找到最后一个 bug 并将其移动到其他地方,11.10 版就可以使用)。以下是窗口系统的兼容性工作原理。

首先,自从 2.0 SDK 以来,XPLMCreateWindowEx它的所有参数都在一个结构中,一个XPLMCreateWindow_t。该结构,又有一个 structSize 变量,它是这样初始化的:

XPLMCreateWindow_tMy_win = {0}; my_win.structSize = sizeof (my_win); my_win.froblinator = xplmfull _ of _ eels;//等等。XPLMCreateWindowEx(& My_win);

现在当我们修改 SDK 的时候,XPLMCreateWindow_t当您 # 定义 xplm300 时,结构会增长。这导致新的插件编译新的 SDK 发送一个大的结构 (有更多的回调) 和旧的插件编译旧的 SDK 发送一个小的结构。

这就是 SDK 如何 “知道” 你正在使用什么 SDK,并为新插件提供新的行为,但提供兼容的行为,现有的插件,编译年前。

(这种技术对 X-Plane SDK 来说并不是新的或独特的 -- 你可以从编码惯例中看出它是从 Win32 SDK 中借来的咳嗽、咳嗽。)

张贴在显影,插件 | 8 条评论