天一

2024年6月11日更新日志【2024.06版本】

06/11473 浏览日志专区

除部分严重BUG修复会覆盖旧版本，以下新功能均在编辑器版本2024.06中生效

开发者可以在编辑器顶部菜单-编辑器版本中进行版本切换

【必看】触发器中文字符处理优化

在过去，使用字符串处理函数的用户可能注意到当字符串中存在中文时，中文字符可能被截断的问题。

为此我们在2024.06版本中对服务器与客户端触发编辑器中一些字符串处理相关的函数和动作进行了UTF8相关的优化。

受影响的api有：『获取字符串长度』、『截取字符串』、『头部填充字符串』、『尾部填充字符串』。

在过去增加了特殊自定义逻辑（如将汉字视作三个字符串来截取）的用户可能需要在升级到2024.06版本后重新检查一下处理逻辑的正确性。

我们预期这一改动会更符合开发者的使用直觉，能减少后续所有开发者的维护成本。

在新版本中，汉字应当被视作一个字符。例如，字符串『张三李四王五』长度为6，截取第2到第3个字符串结果为『三李』。

血条编辑器自定义血条配置相关优化

我们在之前的更新日志中提及了星火编辑器加入了血条编辑器。但此前，单位数编数据中能够选择的血条配置与血条编辑器中的血条配置并不是一一对应的。

在2024.06版本中，我们修改了单位节点配置血条的方式。从原本的下拉菜单改为了一个复合界面。

单位节点配置血条的方式

在这个复合配置中，用户不单可设置单位的默认血条模板，也可以设置单位在不同视角下显示的血条模板：比如，上图的英雄单位作为主控单位的时候，所属玩家观察它时会显示绿色血条，在友方看来显示蓝色血条，在敌方看来显示红色血条，在中立看来则显示为黄色血条。

新的血条配置界面功能强大，除了可以按照阵营来配置血条外，还可以根据玩家所属的队伍来显示血条。比如用户可以将所有的”天灾“队伍的单位血条设置为显示红色，”近卫“队伍的单位血条显示为蓝色。此外，即使同为所属玩家的单位，当单位身为主控单位和非主控单位的状态下，也可以配置显示不同类型的血条模板。

队伍配置

血条配置复合界面支持多项配置并存，这些配置会按照固定的优先级生效，比如，用户可以将同时配置一个单位的”所属玩家“和队伍配置血条。如下图，这样就能实现除了自己以外的天灾单位血条都显示为红色，近卫单位血条都显示为蓝色，但只有自己的单位不管在哪个阵营都显示为绿色的效果。

队伍配置优先级

配置生效的优先级顺序为主控>所属玩家>队伍>敌我中立关系。（之所以主控和所属玩家分成两个级别，是因为星火编辑允许存在属于玩家自己非主控单位）

我们已经修改了所有星火单位默认模板的血条配置和样例单位的血条配置，升级到2024.06的项目应当绝大部分都会自动会享受到新的血条配置，它们同时也可以作为血条配置样例帮助用户更好地配置单位血条。对于此前选择过自定义血条类型的单位节点，旧有的选择依然会保留且依然会生效。在这些节点上用户依然会看到旧式的血条配置界面，用户可以选择保留原状。但如果想要利用新的血条配置机制，用户选择将旧的血条类型字段值改为『无』，这样就会关闭旧的兼容模式，显示新的血条配置界面。

以前修改过血条类型的单位依然会显示旧的血条配置项

此外，为了方便用户在游戏运行时动态修改单位血条，客户端触发器动作『修改单位血条模版』动作中的血条模板参数现在从需要输入字符串改为了可以直接在所有血条模板中选择。其中，选择『无』等价于动态隐藏单位的血条。

今后我们将进一步提供更多自定义血条相关的支持。

血条与文字标签控件本地化富文本

星火编辑器需要使用『获取本地化文本』函数来获取如单位名、物品名等本地化文本。但本地化文本仅仅保存于客户端。但当服务器想要往客户端传递一个带显示名的拼接字符串时，由于服务器没有获取本地化文本的函数，这样的操作经常令用户感觉到复杂。

为此，星火编辑器推出了一系列旨在简化这些多余的服务器、客户端交互的富文本标记。目前开放的富文本标记有'dn', ‘tip’, ‘locale', 'pn’四种。这四种富文本标记不仅仅可以用在文本类型的UI控件上，甚至可以用在血条文本上，方便用户在血条上显示单位名或玩家名！

dn

作用：显示指定数编Id或者血条所属单位的显示名。

格式：<dn>[任何数编Id或不填]</dn>

例：在UI文本中或血条中输入“显示名:<dn>$$default_units_ts.unit.星火战士.root</dn>”（不带引号，下同），那么这段文字在游戏里会被显示为”显示名:近战英雄样例。”（注：默认情况下，『近战英雄样例』是数编节点$$default_units_ts.unit.星火战士.root的显示名）

例2：在单位血条中输入”<dn></dn>“，会显示当前单位的显示名。

例3：在物品血条中输入”<dn></dn>“，会显示物品名。

tip

作用：显示指定数编Id或者血条所属单位的详细描述。

格式：<tip>[任何数编Id或不填]</tip>

例：”<tip>$$default_units_ts.spell.火球术.root</tip>“会显示为火球术的介绍”发出一个火球，对第一个命中的敌人造成伤害。“

例2：在物品的血条中输入”本物品的描述为：<tip></tip>“会显示为”本物品的描述为“+物品的描述。

locale

作用：直接获取本地化文本。

格式：<locale>[本地化文本的key]</locale>

例：”<locale>[EntryNode][$$default_units_ts.spell.冰霜球.root].Data.Game.Name</locale>“会显示为”冰霜球“。（[EntryNode][$$default_units_ts.spell.冰霜球.root].Data.Game.Name对应的实际本地化文本）

注：通过该富文本标记显示本地化文本和『获取本地化文本』函数在显示结果上不会有区别，区别仅仅是『获取本地化文本』实际会返回本地化文本字符串，而locale富文本标签并不会实际改变原始字符串的值，仅仅是让它们显示为本地化文本而已。

pn

作用：获取指定玩家玩家名。

格式<pn=”[玩家号]”></pn>或<pn></pn>

例：在UI文本中使用”<pn></pn>“会显示为当前客户端玩家的玩家名。

例2：”<pn=”2”></pn>“会显示槽位为2的玩家的玩家名。

例3：在单位血条上使用”<pn></pn>”会显示单位所属玩家的玩家名。

玩家名显示规则：对于已经连入的真人玩家，会显示玩家的Tap昵称。但连入的玩家获取Tap昵称的时间点会有滞后性，因此我们加入了『玩家昵称初始化』事件来帮助用户决定正确的获取昵称时间点。

在玩家昵称初始化完成前显示的UI文本或者血条会显示对应玩家在『玩家与队伍设置』中设置的玩家名。在客户端，用户可以注册『玩家属性变化』事件，判断变化的属性为『玩家昵称』然后重新设置UI文本或血条文本以刷新玩家名称显示。在服务端则可使用对应的『玩家昵称初始化』事件。

此外，对于非真人玩家，会显示对应玩家在『玩家与队伍设置』中设置的玩家名。如果输入的玩家槽位没有在『玩家与队伍设置』中定义，会显示为”玩家 N“。（n为对应的的玩家槽位）

『玩家与队伍设置』中设置的玩家名

我们推荐想要从服务器传递带本地化文本的拼接字符串到客户端以便显示它们的用户直接使用富文本标记来传递这些拼接文本，这样服务器就不需要反过来从客户端获取本地化文本了。例如：

语句示例

此外，我们也修复了此前玩家属性和单位字符串属性无法正常设置同步方式的问题，通过设置属性的同步方式，血条绑定单位字符串属性的功能也可以对敌方单位生效了。

我们还在编辑器中为单位加入了一个名为『昵称』的字符串属性，方便用户使用旧有的单位属性绑定方式来配置血条。

我们也在默认样例中增加了一个『在地上时显示物品名称』的物品样例。该样例使用血条富文本机制来显示物品名称。血条的资源消耗通常远远低于可附着面板，我们推荐今后想要显示地上的物品名称的用户尽量使用血条版本。

物品自动拾取逻辑优化

星火编辑器为用户提供了许许多多的通用化功能，通常在数据编辑器中勾选一两个选项就能打开或者关闭一些通用功能的配置。许多通用功能之间还存在组合。方便实现用户的各种特殊需求。但另一方面，这也使得星火编辑器在一些方面会需要针对执行效率和通用性方面进行取舍。

毕竟星火编辑器是这样的，用户只需要使用编辑器功能就可以了，可是在后方的开发团队要考虑的事情就很多了。

以物品的自动拾取功能为例。在通常场合下，能够拾取物品的单位总是会远远少于能够被拾取的物品的。因此若追求执行效率，应当以少数的拾取者去搜索被拾取者。

但星火编辑器为了考虑自动拾取功能的通用性，无法事先指定哪些单位可以拾取物品，毕竟任何单位逻辑上都可以动态拥有物品栏，甚至逻辑上物品自己也都可以拥有物品栏去拾取别的物品。由于其不确定性，自动判定具体由哪些少数单位去搜索多数的物品是无法达成的，我们无法自作主张地为用户来实施这项优化。

因此在默认情况下，星火编辑器采用的是由可被自动拾取的物品反向搜索附近自动拾取范围内可拾取物品的单位的模式——因为可被自动拾取的物品是所有物品的一个子集，而所有物品则又是所有单位的一个子集。在可拾取物品的单位不可限定的条件下，这才符合由少搜多的原则。

但另一方面，我们注意到不少用户有在开发所有物品都能被自动拾取的项目，而有些项目中自动拾取的物品数量非常庞大，吸血鬼幸存者类游戏就是一个例子。

在这些项目中，由成百上前的物品来每帧搜索全游戏中都仅有一两个的拾取者，是十分浪费的。这也是一个事实，毕竟用户自己是知道自己项目里究竟哪些单位可能会自动拾取物品的，若因为机制的通用性，而使得这部分用户失去了优化自己项目的能力，也不是一种理想的结果。

因此，为了能兼顾自动拾取物品系统的通用性，又希望用户能够主动地享受到动自动拾取系统的『由少搜多』优化，在2024.06版本中，我们增加了『设置物品特殊自动拾取模式』和『关闭物品特殊自动拾取模式』的触发器动作，将选择权交到用户手上，允许用户主动地切换为拾取者主动搜索的特殊拾取模式。

设置物品特殊自动拾取模式动作需要传入两个参数，一个传入一个单位组，代表只有这个单位组内的单位会主动搜索附近的自动拾取物品。一个传入一个间隔，默认值为0.33秒，指这些单位的搜索间隔。

一旦『设置物品特殊自动拾取模式』被执行，项目内的可自动拾取物品将不会再自动搜索附近可拾取它们的单位，仅有用户所指定的单位组内的单位会自动拾取自身附近的可被自动拾取物品，这样的操作可以极大地减少相关消耗。而『关闭物品特殊自动拾取模式』则会退出由单位主动拾取物品的模式，回到物品主动搜索单位的模式。

需要注意的是，『设置物品特殊自动拾取模式』再每次执行时，其传入的单位组为覆盖关系。连续执行两次，传入不同单位不会使得两批单位都可实施自动拾取，只有最后一次传入的单位组可以进行自动拾取。

此外还需要注意的时，在关闭物品自动拾取模式时，已经创建在地上的自动拾取物品不会自动恢复自行搜索附近单位的特性，用户可能需要将它们拾取并重新丢弃以刷新它们的自动拾取模式。但我们在一般游戏开发流程中，应当不会出现会想要频繁地在两种模式切换的情况。

为了作为样例展示这两个触发器动作的用法，以及展示该优化所能节省的性能，我们修改了官方的吸血鬼幸存者游戏模板，将这一优化应用到了该模板的触发器中。今后在2024.06版本中新建的吸血鬼幸存者模板项目都会自动获得这一优化。初步的数据显示，经过这一优化的幸存者模板，执行效率比以往增加了25%以上。

自定义数编节点任意函数公式

在触发编辑器中配置自定义数编节点时，现在可以设置两种新的数编属性类型：『任意函数（服务器）』与『任意函数（客户端）』。它们的使用方式与效果节点公式类似，但生成的数编公式参数传入一个任意类型值并返回一个任意类型的值。用户可以利用这两个任意函数数编属性类型来为自己的自定义数编节点配置自定义的公式字段，无需再限定于固定的效果节点公式签名。

物品技能被动效果和高级事件效果的改进

现在，物品技能的周期性效果和技能高级事件节点下所的连接的效果树中都可以直接获取效果节点的引发物品了（以前只对非被动效果生效）。

需要注意的是，物品技能高级事件中的“获得时效果”依然无法直接获取效果节点的引发物品，这是因为当技能刚被获得时，技能的一些信息还未初始化完成。用户可以在节能节点的获得时效果出口后面连一个时长为0秒的延迟效果，之后便可以正常获得效果节点的引发物品。

云变量提交回调

星火编辑器已经增加了第三方依赖库相关的支持。考虑到对云变量相关操作的包装可能会在第三方依赖库中有较广的使用场景。但结合星火编辑器开发组在过去提供云变量相关的预制功能库的实际实践，我们发现用户通常会希望在官方包装的云变量操作进行提交后加入一些自定义的额外逻辑。

考虑到未来第三方依赖库的作者可能也会遇到这样的场景，我们在2024.06版本中加入了云变量提交回调功能。我们在触发器中添加了『添加云变量提交请求：添加提交回调函数』动作。该动作可以指定一个云变量提交对象，并在其进行提交时执行自定义的额外逻辑。这样即使提交操作是在另一个依赖库中进行的，该功能也允许用户在提交操作成功或失败时附加额外的处理逻辑。

客户端搜索优化

我们在2024.06版本中对客户端搜索单位的效率进行了一定的优化，现在大部分不会在客户端描绘的单位（如已经被拾取的物品）不会再出现在搜索候选中，这应该能够极大地优化在一些极端条件下的客户端单位搜索代价。

触发编辑器

客户端触发器加入了『获取所有物品的数编Id』、『获取所有技能的数编Id』等列出所有指定分类的公用数编Id的函数。（服务端此前已经加入了相关函数）
『设置带限制的云变量』语句现在更名为『修改带限制的云变量』，以更加契合云变量相关内容的措辞习惯，更好地体现该触发器当作的实际作用，并修改了一些云变量相关的描述文字。我们也随之更新了线上文档中与云变量相关的文档的一些措辞。
客户端触发器『设置允许右键移动』的触发器动作和『是否允许右键移动』的触发器函数。用户可以用这些新的触发器功能来打开/关闭右键移动功能，也能判断当前客户端是否打开了右键移动功能。
服务器触发器的物品面向对象方法中现在增加了『获取云变量物品绑定用户的虚拟Id』方法，允许用户动态判断一个云变量物品所绑定到的玩家账户。该方法对非云变量物品或者未绑定给任何用户的云变量物品使用，可能获取到空值。
触发器编辑器中场景相关的API逻辑变得更为统一，现在大部分会返回场景的函数和事件都使用场景枚举而非场景字符串。
服务端触发器增加了『玩家-回到游戏时』事件。该事件将会在玩家从暂离状态恢复时引发。注意该事件不同于玩家的重连事件。
服务端触发器增加了『玩家-昵称刷新』事件。该事件将会在玩家获得昵称时引发，时间略晚于『玩家-连入』事件，服务端可以监听此事件拿到玩家的对应昵称。
『创建并加载场景副本』语句的动作类型改成了函数，添加该语句会默认添加一个场景对象的返回值。
此外，我们还删除了触发器中一些已被废弃的事件和api。

新增了API支持为玩家创建快捷方式，只在Android系统上可用，并且由于系统限制，目前无法准确的获得是否创建成功，对应的API为：