Stellaris开发日志#232 | 11/11 平衡性改动和性能改进

牧游社 牧有汉化翻译

Stellaris Dev Diary #232 - 3.2 Balance Changes and Performance Improvements

Gruntsatwork, Stellaris Custodian (Game Designer)

Hello everyone, today we would like to tease you with some of the upcoming changes coming with the 3.2 "Herbert" patch, named after Sci-Fi author Frank Herbert, which we will release along with the Aquatic Species Pack.

大家好，今天我们想向大家介绍一下3.2版本号“赫伯特Herbert”补丁中即将出现的一些变化，该补丁是以科幻作家弗兰克·赫伯特Frank Herbert（译注：美国科幻小说家，作家，代表作《沙丘》三部曲）的名字命名的，我们打算将该补丁与水生生物物种包一起发布。

For Balance Changes, we have the following changes in store for you.

我们为诸位准备了如下的平衡性改动。

Functional Architecture and Constructobot: Reduced the free building slots granted from 2 to 1.
实用建筑和施工机器人：提供的免费建筑槽位从2减少到1。

Agrarian Idyll empires now get one planet building slot per four Agricultural districts built.
田园绽放帝国现在每建造4个农业区域就能为所在行星获得1个行星建筑槽位。

Reduced the ship upkeep cost modifier for clone army admirals to 5/10/20% based on their decisions.
根据克隆海军上将事件中做出的决策，我们将他们的舰船维护费修正减少至5/10/20%。

Ruins of Shallash arc site no longer has a chance of giving quite as much unity as defeating an endgame crisis.
“沙拉什遗迹”考古遗迹将不再会提供相当于击败终局危机所带来的凝聚力了。

You can no longer use planet killer weapons on primitives inside your borders if you lack the appropriate primitive interference policies.
在你没有合适的原住民干涉政策之前，你不再能对自己境内的原住民星球使用行星杀手武器。

Pops working the Livestock job now have 10% less political power.
在“牲畜”阶层工作的人口现在政治权利-10%。

A lot of anomalies were rewarding 3 Society Research deposits, there is now more variety.
之前很多异常现象的奖励都是3社会学研究的资源点，现在异常现象的奖励会更加多样化。

Made Awakened Fallen Empires use Traditions (but not Ascension Perks).
觉醒的堕落帝国现在可以使用传统（但不能使用飞升天赋）。

Several productivity-improving technologies are now no longer of dubious benefit, as their upkeep (and production) effects now only apply to jobs actually primarily producing resources.
若干提高生产效率的科技现在其增益效果不再那么令人迷惑，它们的维护（和产出）效果现在直接影响主要产出资源的工作岗位。

Nerve Stapled Hivemind pops can no longer perform complex drone jobs.
蜂巢帝国“精神阉割”的人口现在不再可以在“复合子个体”岗位上工作。

Reduced the amount of jobs added by Leisure Arcology Districts to bring them into line with other Ecumenopolis districts.
现在“休闲生态区”区划提供的岗位数与其他都市行星区划提供的岗位数相同。

Ion cannons are no longer free to maintain, and have an upkeep cost of 8 energy.
恒星基地粒子炮不再免维护费，现在它们需要8点能量来维护。

Necro-Hives:
死灵族蜂巢：
- Cut Necrophage pop assembly penalty to 50% from 75%
- 死灵族人口的组装速度惩罚从75%改为50%。
- Made pop output modifiers (positive and negative) no longer apply to hive minds.
- 人口产出修正（不论正面负面）都不再适用于蜂巢思维。
- Made the -50% organic upkeep also apply to energy, for photosynthesis.
- 对“光合作用”来说，-50%有机体维护费的效果也同样适用于能量。
- Devouring Swarm Necrophages now spawn with extra infrastructure to account for the lack of chambers of elevation.
- 死灵嗜杀蜂群现在在生成时将提供额外的基础设施，来平衡弥补擢升之庭的缺失。

Of note here is the Functional Architecture change, we are aware that the extra building slot was the main draw of the civic but it was also way over-represented even after the initial release-hype

这里值得一提的是“实用建筑”的改动，我们知道额外的建筑槽位是这个民政的主要吸引力，但是即使在过了最初发布的炒作之后，这个民政也被这一条效果过度代表了。

While not a pre-planned balance pass like we did for the Lem patch, we still found a few places to tweak and adjust and we will continue to do that in future patches.

尽管这个补丁并不像“莱姆Lem”补丁那样，是我们提前规划好要做的平衡性改动，但我们还是发现了一些要调整和平衡的地方，我们在未来的补丁中也会继续这样做。

...and now, handing over to Caligula Caesar for a look at some performance improvements and moddability topic.

...那么现在，让我们交给Caligula Caesar，来瞅一瞅这些性能表现提升以及模组能力方面的话题。

A Look at Script Performance

脚本性能概览

Hi! You are probably used to me writing lengthy prose about new moddability and scripting language features. This time, we only have a few things to show off in that regard, but there are nevertheless some cool, technical things I can speak about.

嗨！你可能已经习惯了看我写这些关于新的模组能力和脚本语言特性的长篇大论了。这一次，我们在这方面只有一点点东西可以炫耀，但还是有一些很酷的、技术性的东西可以谈一下。

Knowing the script language pretty well, I always found the performance impacts of our scripts to be a big unknown to me. Was what I was adding going to mess with performance? Well, I could do plenty of guessing as to how to script most efficiently, and general concepts of programming such as early outs do apply. But how big was the difference? And how much can we save by identifying inefficient scripts and improving them?

尽管我对脚本语言非常了解，我总还是发现我拿捏不好脚本会对性能有多大影响。我所添加的这些东西是否会影响性能？好吧，我可以多多猜测怎样有效编写脚本，而且编程的一般概念（如应用提前输出）也是适用的。但差别有多大呢？通过识别低效的脚本并加以改进，我们可以节省多少性能？

Moah had made some progress on porting the EU4 script profiler over to Stellaris as a pet project some time ago. The only problem was, its information was quite incomplete (since it needs a lot of tags added in many places of the code, basically everywhere where an effect or trigger is called). It was also pretty hard to read the information presented. But now, with the Custodians initiative, the time had come to see what we could do with this.

Moah在前一段时间的一个引以为豪的项目中取得了一些进展，他将EU4的脚本分析器移植到了Stellaris上。唯一的问题是，它提供的信息相当不完整（因为它需要在代码的许多地方添加许多标签，基本上是在任何调用效果或触发器的地方）。它也很难读懂所提供的信息。但是现在，随着守护者团队的组建，是时候看看我们能对它做点什么了。

After a bit of (very tedious) work to make the information all-encompassing, systematic and readable, I let the game run on a Huge galaxy with a few extra boosts to the AI - 0.75 research costs, 1.25 habitable planets - and ran it a year with the script profiler enabled. Then, issues could be found. I've attached two versions of this output: one as it was in one of the early runs - so before coverage was comprehensive (notably, triggered modifiers and economic tables are missing), but also before any optimisation work was done - and one as it is now, in the 3.2 beta. (Note that the figures for how long it spent on each object is massively inflated by my having run the game in unoptimised debug mode with the profiler turned on)

在做了一些（非常冗长的）工作以使信息全面化、系统化和可读化之后，我让游戏在一个巨大的星系地图上运行，对AI进行了一些额外的提升——设定AI为0.75倍的研究成本、1.25倍的可居住行星，并在启用脚本分析器的情况下运行了一年。然后，就可以发现问题了。我在附件中附上了这次输出的两个版本：一个是早期运行的版本，在全面收集到信息之前（值得注意的是，触发器修正项和经济表都没有），也是在采取任何优化工作之前；另一个是现在的版本，在3.2版本号测试版中。(请注意，由于我在未优化的调试模式下打开脚本分析器运行游戏，所以它在每个对象上花费的时间数字被大大地夸大了。）

Now, I must state in advance that we aren't able to release the script profiler to the public with the 3.2 update for technical reasons: running the game with it makes the game about 50% slower, so we need to work out a way to be able to turn it - and its full performance impact - on and off at will. (At the moment, it is hidden behind compiler flags that are not available to the public). But we definitely hope that we'll be able to release it to modders in the future.

现在，我必须事先声明，由于技术原因，我们无法在3.2版本号的更新中向公众发布脚本分析器（目前，它被隐藏在编译器旗标后面，不对公众开放）——使用它运行游戏会使游戏慢50%左右，所以我们得想出一个办法，能够随意打开或关闭它以及它带来的全部性能影响。但我们肯定希望我们能够在未来将其发布给模组作者们。

Early Gains

前期收获

The first big finding was that the game is repeatedly recalculating certain game rules a large number of times per pop each day, which was having a disproportionate impact on performance. The biggest culprit was "can_vote_in_democratic_election", which it turned out was checked on every pop in the country every day for each pop faction while they were calculating their support value. Yes, you are reading this right: the imperialist faction would check whether each pop in the entire country was allowed to vote, then the prosperity faction would do the same, and the imperialist one, and so on… These cases were fixed by making use of daily caching: the pops will now calculate the result once per day (or, in the case of species_has_happiness, once per species in a country each day), and other places in the code can simply refer back to that result. Furthermore, pop factions’ support calculations were optimised so that the total by which they were dividing their support could be calculated once per country, rather than once per faction.

第一个重大发现是，游戏每天都在重复地为每个Pop重新计算某些游戏规则，这对性能产生了相当不好的影响。最大的罪魁祸首是“can_vote_in_democratic_election”这一条，事实证明，当每个派系在计算其支持率时，每天都会对该国的每个Pop进行检查。是的，你没有看错：威权派系会检查整个国家的每个Pop是否被允许投票，然后繁荣派系也会这样做，然后威权派系，以此类推……这些情况通过利用每日缓存得到了解决：Pop现在会每天计算一次结果（或者，在计算species_has_happiness时，每天为一个国家的每个物种计算一次），代码中的其他地方可以简单地调用这个结果。此外，派系的支持率计算被优化了，这样他们除以支持率的总数就可以在每个国家计算一次，而不是每个派系计算一次。

On the script side, by parsing various of the top hits, we noticed a few easily-optimised bits of script. First off, graygoo.555 was trying to fire a surprising number of times for an event that should come into play only when the Gray Goo are active (which they weren't). It turns out that this was because it was missing "is_triggered_only", so it was trying to fire on all planets every day! Similarly, a number of test events were scripted in a similar way, but with "always = no" as their trigger so they'd never fire. They made a small but nevertheless noticeable impact on performance, so they had to go.

从脚本层面来说，通过追踪各种被高频使用的脚本，我们注意到一些易于优化的代码。 首先，graygoo.555事件会把一个事件触发超级多次，但这个事件理应只在灰蛊被激活的情况下（但并没有）被触发。原来这是因为它缺少了“is_triggered_only”参数，所以它每天都会在所有行星上被触发！相似地，一些别的事件也使用了相似的脚本，但因为错误地把“always = no”作为触发器，它们永远都不会被触发。它们对性能造成了很小但仍然很明显的影响，因此它们必须被移除。

The opinion modifier triggered_opinion_galactic_community_in_breach was taking up more performance than any other opinion modifier, by a distance, which seemed a bit strange. It turned out this could be fixed by a slight change in order in the triggers: it was checking "is_in_breach_of_any" before verifying Galcom membership - which sounds like it wouldn't be a big issue, but that trigger then checks the triggers for the breach conditions of all passed resolutions, so it is in effect a lot of triggers in one. Simply swapping the order had very positive results, here.

“triggered_opinion_galactic_community_in_breach”这一好感度修正，相比起其他好感度修正占用了更多的性能，从大的层面来看这是十分奇怪的。事实证明这可以通过稍微更改一下触发器的顺序来解决：以往它会在验证星海共同体成员资格之前检查“is_in_breach_of_any”，这听起来不是个大问题，但“is_in_breach_of_any”这个触发器会随即调用检查所有已通过议案是否被违反的触发器，因此实际上它对性能的影响是许多触发器所造成的。简单地交换顺序在这里产生了很好的效果。

Finally, the event crime.1 (somehow the second most costly event in the early version) was a similar case, but a lot more complicated. The main problem here was the following piece of script:

最后，事件crime.1 （不知为何是早期版本中性能消耗第二高的事件）是一个类似的情况，但复杂得多。主要问题是以下的脚本：

Code:
OR = {
AND = {
count_owned_pop = {
limit = {
is_shackled_robot = no
is_unemployed = yes
NOR = {
has_living_standard = { type = living_standard_utopian }
has_living_standard = { type = living_standard_good }
has_living_standard = { type = living_standard_shared_burden }
}
}
count > 3
}
owner = { is_gestalt = no }
}
AND = {
count_owned_pop = {
limit = {
is_unemployed = yes
NOT = { has_living_standard = { type = living_standard_organic_trophy } }
}
count > 10
}
owner = { is_gestalt = yes }
}
}

This is quite inefficient, and large benefits could be found in applying the principle of early outs. "Count_owned_pop" is a relatively expensive way of calculating anything, because a lot of efficiency is lost in converting script into code and working out the results of this, so on a planet with 80 pops, it is looping through each of those and checking a set of triggers on each of those. Unfortunately, because of the ordering, it would do this twice per day on each planet which did not have 3 unemployed pops on it:

这是非常低效的，而在应用提前输出原则后会有很大的提升。相对来说，使用“Count_owned_pop”作为计算方式的时候的成本是十分昂贵的，因为把脚本转化为代码并运算出结果会损失许多效率，当一个星球有80人口的时候，脚本会遍历每个人口并检查与之相关的一系列触发器。不幸的事，因为顺序的原因，它会在每个没有3个失业人口的星球上每天遍历两次。

The event is checking the triggers every day on each inhabited planet. Or at least often. 44,000 times in a year, to be exact.

该事件每天，或至少经常地，在每个已殖民星球上检查这些触发器。准确来说，一年44000次。

It does not verify that there are unemployed pops on the planet before working out what kinds of unemployed pops there are. Which means that the OR will return false on both count_owned_pop sections, which consequently means it is checking both. Adding "num_unemployed > 3" near the start had big benefits

在确定有哪些类型的失业人口之前，它不会检查星球上是否存在失业人口。这意味着OR会在两个count_owned_pop部分都返回false，从而导致它两者都会检查。在开始附近添加“num_unemployed > 3”有很大好处

It would check the number of unemployed pops relevant to non-gestalts and only after that check the country was not gestalt. By swapping the gestalt check to the start, it means it will only ever be trying one of the count_owned_pop loops.

它会检查与非格式塔相关的失业人口的数量，且只有检查完之后才会检查这个国家是否是格式塔。把检查是否是格式塔放到脚本一开始会使它只尝试进行其中一个“count_owned_pop”循环。

A new, more efficient version of the trigger was therefore this:

因而一个新的，更有效的触发器版本如下：

Code:
num_unemployed > 3 #early out before the expensive count_owned_pop to come
OR = {
AND = {
owner = { is_gestalt = no }
count_owned_pop = {
limit = {
is_unemployed = yes
is_shackled_robot = no
NOR = {
has_living_standard = { type = living_standard_utopian }
has_living_standard = { type = living_standard_good }
has_living_standard = { type = living_standard_shared_burden }

}
}
count > 3
}
}
AND = {
owner = { is_gestalt = yes }
count_owned_pop = {
limit = {
is_unemployed = yes
NOT = { has_living_standard = { type = living_standard_organic_trophy } }
}
count > 10
}
}
}

Gains from Further Analysis

进一步分析带来的收获

This was some cool stuff to fix, but beyond this, simply looking at the list became a bit harder to yield significant savings. Enter spreadsheeting! We pasted the results into a spreadsheet and, a few formulas later, and a nice pivot table to give us some breakdowns along the lines of "what is the total impact of all jobs", or "what is the impact of the potential trigger of pop factions"

有一些很有趣的东西需要去解决，但除此之外，仅仅查看列表很难做出重大的性能优化节省。使用电子表格！我们把结果粘贴到电子表格中，套用了几个公式之后，一个不错的透视表可以让我们从可以细分看到“所有工作的总体影响是什么”，或者“潜在的人口派系的触发器有什么影响”。

Picture shows values after performance improvements
图片展示了性能优化之后的数据

This allowed us to pinpoint a few more things. Firstly, ai_resource_production was causing an absurdly high performance cost from a rather small number of hits. The culprit, here, turned out to be that the "planet_resource_compare" trigger (used mainly here) was incredibly expensive. The problem was that it was recalculating the resource output of all resources on the planet, basically (including by seeing what each pop was producing!). It turned out to be possible to mitigate this somewhat (to about 75%) by making it selectively recalculate the production of the relevant resource, but this was still quite expensive for a trigger, so we also cut down on its use a bit. I suggest modders not overuse it either.

这允许我们查清更多事情。首先, ai_resource_production 用相对来说较小的触发次数造成了高的离谱的性能消耗。而罪魁祸首则是因为“planet_resource_compare”这一触发器（主要在这里使用）消耗非常大。问题在于基本上它会重新计算星球上的所有资源输出（包括检查每个人口在制造什么！）。事实证明可以通过有选择地重新计算相关资源产出来减轻这一负担（大致75%），但这样的消耗对于一个触发器来说仍然过高，所以我们减少了它的使用。我建议模组的开发者也不要过度使用它。

Another thing we saw was that, not unexpectedly, jobs were quite expensive. Specifically their weights and their "possible" checks. We have some ideas to save time on the weights that we aren't ready to speak about yet (they emerged too late in 3.2 development to be considered for the patch, because they are relatively likely to need some iteration), but we found a way of making the "possible" triggers cheaper. Basically, every seven days, a pop would recalculate its job cache, at which point it will check whether it is allowed to work each job, and if so, calculate its weight. But most jobs have fairly standard "possible" triggers that check the first part - specifically, there is a shared set of triggers between, respectively, worker, specialist, ruler and drone jobs. It turned out that very significant improvements (to the degree of almost two thirds) were possible by having the pop calculate these four triggers first, then loop through the jobs and simply match the result to the right job.

还有一个意料之中的事实，岗位的计算耗时耗力，特别是对岗位权重和“可能”的检查。我们已经有一些在权重上节省时间的想法，但是还没有准备好讨论这个（它们在3.2版本号的开发中发现得太晚了，没法在补丁中顾及到，因为它们可能需要一些迭代），但是我们找到了一种使“可能”触发器更容易使用的方法。原则上来讲，每七天，人口都会重新计算它的工作岗位缓存，在这个时候它会检查它是否能去做每一个岗位，如果结果为是，就计算权重。但是大多数岗位都有非常标准的“可能”触发器来检查这个过程中第一个部分。具体来说，工人、专家、统治者和无人机岗位有一组共用的触发器。看上去，通过让人口先计算这四个触发器，就能很容易的匹配到正确的岗位，这会有非常显著的改进（几乎提升了三分之二）。

(Note to modders: the format looks a bit different now. If you used the scripted triggers worker/specialist/complex_specialist/ruler/drone_job_check_trigger, you will now need to define e.g. "possible_precalc = can_fill_ruler_job". And if you changed them, you will need to change the new versions of them in game_rules)

Mod作者瞟一眼这里：写脚本的格式又变了，如果用了worker/specialist/complex_specialist/ruler/drone_job_check_trigger，现在要定义possible_precalc = can_fill_ruler_job。如果你的mod动了这些内容，你需要给mod更新了。

Finally, although the game rules optimisations had already fixed several performance issues with pop factions, there were a few more spots where they could be improved. The first was whether a faction should exist at all: it turned out that both the script and the code was checking whether there were 5 pops that could join the faction, just that the code wasn’t checking this anymore after the faction was formed. Obviously, this wasn’t ideal, so the script check (being the slower) was removed, and the code check amended to account for shrinking pop factions becoming invalid.

最后，尽管游戏规则的优化已经解决了一些关于人口派系的性能问题，但是仍然有很多可以改进的地方，首先是这派系该不该存在：事实证明脚本和代码都在检查是否有5个人口会加入这个派系，当派系成立的时候，就不会再检查了。显然这不够理想，所以脚本检查被我们砍了，代码检查也被修改了，对正在减少人口的派系不再生效。

The second was deciding whether a pop should belong to a faction: even though almost all factions only allow pops matching their ethos, the filter by ethos is quite late. By putting it much earlier - in code, before the script is even checked at all (with an override in case this isn’t desired, e.g. for technologist robots) - this massively cut down the costs of this particular calculation.

第二点是一个人口该不该加入这个派系：尽管所有的派系仅允许人口加入意识形态匹配的派系，但是根据这个进行匹配的过滤太迟了。通过把它挪到代码靠前点的位置，甚至是在脚本检查之前（如果不希望这么做就加一个覆写，比如在机器人的科技派系情况下），能大大降低了计算的消耗。

Finally, a number of their demands - checked each day per faction - were quite exorbitant. By changing the ordering and using equivalent but cheaper checks (e.g. any_owned_species instead of any_owned_pop). This, too, had a significant impact, so that the script footprint of pop factions (excluding game rules they use) was reduced by about two thirds.

最后，派系的要求检查着实很有点离谱——它们每天都进行检查。通过改变顺序以及使用等价但是更简单的检查方式（比如any_owned_species而不是any_owned_pop）。这也能有很显著的作用，因此人口派系（不包括使用的游戏规则）的脚本使用量减少了三分之二。

Further Performance Topics

更进一步的性能话题

It is my hope that this work will be felt in the form of a bit less late game slowdown. My tests would indicate that this was a success, though it's very hard to quantify by how much. It was however work that was solely focused on the script performance footprint, so there's plenty of other things for us to look at! The job is never over, when it comes to performance, and hopefully we’ll have time to make further improvements for 3.3.

我希望这个工作能够在游戏后期让游戏卡顿好一点，我的测试证明这很成功，尽管很难量化。然而这个改进只关注了脚本的性能，所以我们还有很多东西要关注！不要让性能改进停下来，希望我们有时间在3.3版本号中做进一步的改进。

For example, I have heard a few complaints about UI lag in the late game, which might be improved slightly in a few interfaces as a result of the performance work, but this work didn't focus on UIs. It is certainly true that some of them are not as fast as we would like them to be. Particular ones in this regard are the planet view, the species view and the colonisation selection menu, and we are looking at options to speed them up. (And, indeed, if anyone can think of any others, it would be useful for you to point them out!)

比如，我听说有抱怨说游戏后期UI滞后，因为性能改进，这可能会有稍微好一点，但是性能改进工作并不关注UI。显然UI当中的部分没有我们想的那么快，尤其是行星视图、物种视图和殖民地选择菜单，我们正在想办法给它们加速。（如果有人能想到别的，最好提出来，这将很有帮助！）

Moddability Improvements

模组能力改进

I can't really do a dev diary without talking about a few moddability improvements, so here they are. As I said, we don’t have that much this time, but there's a few things that people might enjoy trying out:

我写一篇开发日志真的不能不谈谈模组能力的改进，所以它们就在这里说。正如我所说，这次我们没有那么多新玩意儿，但有一些大家可能想试试的新东西：

There's now a create_nebula effect. Although it's best used during galaxy generation, since the visual effects on the galaxy map won't refresh during the game.
现在出现了“create_nebula”（创建星云）效果。虽然它最好在银河系生成期间使用，因为银河系地图上的视觉效果在游戏期间不会刷新。

Decisions can now have on_queued and on_unqueued effects.
决议现在可以使用on_queued和on_unqueued效果。

Terraforming now uses the Megacorp economy system. Meaning, the costs are configurable resource tables, and you can make economic_unit modifiers to apply to them.
地貌改造现在使用Megacorp的经济系统。也就是说，成本是可设定的资源表，你可以用economic_unit来对成本进行控制。

There's a species_gender trigger that checks what gender the species’ leaders can be
新增了一个species_gender的触发器，用于检查物种的领导者是什么性别。

You can now define custom tooltips for systems that you see when you mouse over them on the galactic map
你现在可以为银河地图的对象自定义鼠标悬停的提示框。

There’s now on_actions for on_capital_changed and on_planet_class_changed
为on_capital_changed和on_planet_class_changed新增了on_actions

For Traditions, the "possible" trigger of its adopt tradition will now show in the tooltip for adopting it if it fails. I'm told that you can also now make the tradition categories have a container where you add a gridbox.
对于传统，采用某个特定传统的“可能”触发器现在将显示在提示栏中，如果没能采纳这个传统的话。我也被告知，现在大家也可以在新增gridbox的时候将传统类别填进去。

There's also a couple of things that modders will have to update (aside from the terraforming, as mentioned):

还有一些东西需要模组作者进行修改更新的（除了提过的地貌改造）：

any/count/every/random_planet_army now refers to all armies on the planet, not just all owned by the owner of the planet
any/count/every/random_planet_army现在指的是行星上的所有军队，而不仅仅是行星所有者所有的军队

Set_starbase_building/module and the remove variants are now consistent in starting at slot 1, rather than "set" starting at 0 and "remove" at 1.
Set_starbase_ building/modul和移除设计变种现在从slot 1开始，而不是从0开始“Set”和从1开始“remove”。

In component_templates, valid_for_country is now a trigger rather than a weights
field
在component_templates中，valid_for_country现在是一个触发器，而不是权重作用域。

Fire_on_action had some issues where you defined scopes with "prev" and "from", those no longer exist.
Fire_on_action存在一些问题，如果你使用“prev”和“from”定义了范围，这些范围就会不存在。

As a final moddability note, for anyone who misses the meaty dev diaries with far-reaching moddability changes, not to worry! Anyone that has played around with the script of our newer games will know that there's a lot more potential in our scripting language. There's some cool stuff in the works, though I can't at this stage say what exactly or in which patch it'll be.

作为模组能力的最后说明，对于那些错过了关于更有干货和深度的模组能力改动开发日志的人，不要担心！任何使用过我们游戏新脚本的人都会知道，我们的脚本语言有着更大的潜力。还有很棒的东西在开发中，虽然在这个阶段说我不能说它到底是什么或者在哪个补丁中。

I am also, as last time, attaching the script docs to the dev diary, so that you can see any changes I forgot to mention. Also, any modders who are interested in early access to the 3.2 Update, for the purposes of getting your mods updated, you can sign up here: https://pdxint.at/3bZbVJN

最后，我也把脚本本文作为本篇开发日志的附件附上，这样你就可以看到任何我忘记提及的改动了。而且，任何希望能提早获得3.2版本号更新的modder（出于更新模组的目的），可以在此处报名登记：https://pdxint.at/3bZbVJN。

翻译：Frost qqqqyyy 枸杞泡阔落

校对：一水战阿部熊 三等文官猹中堂

欢迎关注UP主和主播小牧Phenix！

欢迎关注牧游社微信公众号和知乎专栏！微信公众号改版为信息流，欢迎【置顶订阅】不迷路，即时获得推送消息！

B站在关注分组中设置为【特别关注】，将会在私信内及时收到视频和专栏投稿的推送！

欢迎加入牧有汉化，致力于为玩家社群提供优质内容！组员急切募集中！测试群组822400145!