Not a Devlog【我也不知道什么意思】

向18前进的道路上的小状态更新

直接翻译的，凑合着看吧

对不起，我一直低着头！伟大的阅读，通过所有的车辆演示反馈，我想集中精力使每个人尽快测试-我很抱歉，我不能给更多的玩家钥匙。最有可能的演示将更新一旦这些任务完成(战斗演示？)，然后通过测试地图，以转换所有资产到我的新玛雅管道。

项目结构

该项目的返工进展顺利，是我的思维方式的一个有趣的转变。多年(可追溯到3.0前？)我一直围绕“资产”(如EagleFire资产或境外资产)设计这些系统，这些资产保存了所有数据、模型、声音等，然后游戏代码从数据构建运行时对象。更不真实的方法是创建特定于每个项目、车辆等的蓝图子类，并将数据设置在相同的位置。

现在，作为这个结构在4中改变的一个例子，以前有些类是这样设置的：

‘BallaticWeaponInstance是UbayleItemInstance，ItemInstance是ItemInstance，ItemDefinition表示的ItemDefinition跟踪ItemDefinition。ItemObserverComponent负责组成ItemInstance的网格、效果等，它知道要从ItemDefinition中的数据创建哪些网格、效果等，后者可以指定要使用的ItemObserverComponent子类。

新的设置基本上必须重新编写，因为体系结构是如此不同，但相对较快，因为从特性上讲，我已经做过一次了：

项参与者组合了定义和实例，并可以对每个特定项进行子类化。可以添加ItemBehaviorComponent，这些组件引入了不同的功能，例如WearableItemComponent和EquipableItemComponent(模拟可使用/武器)。你可以拿把枪当衬衫穿吗？武器参与者是UbayleComponents的新模拟，同样，ItemObserverComponents现在是Item观察者参与者。这将所有观察者数据从定义中移除，并使其更易于自定义-减少了一次性效果所需的共享代码更改，比如微型枪上的旋转桶，这就摆脱了僵化的继承树。首先，这一变化将真正有益于调制器。

武器和可穿戴设备大多是过渡的，所以库存还不够。库存在“虚幻”中提出了一些棘手的挑战，因为你必须拥有一个演员才能调用RPC，但是新设计的另一个好处是，对于MODS来说，在它们的项目上调用RPC要容易得多，因为它们现在是玩家拥有的休眠行为者，而不是简单的UObjects。我还重新研究了如何发现从模块注册表到实现IU4_InteractableInterface的角色/组件之间的交互，该接口被转发到聚焦项实例，因此您的自定义项行为可以很容易地定义新的操作，比如按F键将夜视附加到头盔或其他东西。

不管怎么说，这件事很容易被胡说八道。此外，更多的小效果，如猎枪炮弹，使一个不同的声音降落在草地上，而不是弹壳！

防未来3

在过去的几天里，我一直在忙着做一些更新。我必须在2019年1月底之前更新3到Unity2017.4 LTS，但是我想给车间创建者足够的时间来更新他们的内容，因为资产包是不兼容的。除其他更改外，我还添加了一些(相当明显的)特性，允许每个资产包含多个项/对象/etc，以便更容易地批量更新所有资产，并将夏威夷和希腊转换到此系统。最有可能的是夏威夷、希腊、塞浦路斯和德国将被转移到该讲习班，以增加未来规划地图的空间。

运行时着色排列

现在4是GPU瓶颈，至少在一定程度上是因为FX如草位移，积雪堆积等总是活跃在GPU上。(CPU端已启用/禁用)。统一对全局着色器排列有一个很好的特性，可以根据需要启用/禁用那些着色器变体，但最接近的虚幻属性是材料特性，而且切换速度很慢。我一直致力于重新设计材料质量系统，使材料能够指定他们如何使用运行时排列(香草的虚幻，天气或树叶)，然后迅速地将它们换掉。在编辑器中，我对这一概念的证明是可行的，但也有一些崩溃和烹饪问题需要解决。但现在我知道了，这是绝对有可能的，这将消除一些性能方面的担忧。