牧游社 牧有漢化翻譯

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”補丁中即將出現(xiàn)的一些變化，該補丁是以科幻作家弗蘭克·赫伯特Frank Herbert（譯注：美國科幻小說家，作家，代表作《沙丘》三部曲）的名字命名的，我們打算將該補丁與水生生物物種包一起發(fā)布。

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

我們?yōu)橹T位準(zhǔn)備了如下的平衡性改動。

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.
田園綻放帝國現(xiàn)在每建造4個農(nóng)業(yè)區(qū)域就能為所在行星獲得1個行星建筑槽位。

Reduced the ship upkeep cost modifier for clone army admirals to 5/10/20% based on their decisions.
根據(jù)克隆海軍上將事件中做出的決策，我們將他們的艦船維護(hù)費修正減少至5/10/20%。

Ruins of Shallash arc site no longer has a chance of giving quite as much unity as defeating an endgame crisis.
“沙拉什遺跡”考古遺跡將不再會提供相當(dāng)于擊敗終局危機所帶來的凝聚力了。

You can no longer use planet killer weapons on primitives inside your borders if you lack the appropriate primitive interference policies.
在你沒有合適的原住民干涉政策之前，你不再能對自己境內(nèi)的原住民星球使用行星殺手武器。

Pops working the Livestock job now have 10% less political power.
在“牲畜”階層工作的人口現(xiàn)在政治權(quán)利-10%。

A lot of anomalies were rewarding 3 Society Research deposits, there is now more variety.
之前很多異?，F(xiàn)象的獎勵都是3社會學(xué)研究的資源點，現(xiàn)在異?，F(xiàn)象的獎勵會更加多樣化。

Made Awakened Fallen Empires use Traditions (but not Ascension Perks).
覺醒的墮落帝國現(xiàn)在可以使用傳統(tǒng)（但不能使用飛升天賦）。

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.
若干提高生產(chǎn)效率的科技現(xiàn)在其增益效果不再那么令人迷惑，它們的維護(hù)（和產(chǎn)出）效果現(xiàn)在直接影響主要產(chǎn)出資源的工作崗位。

Nerve Stapled Hivemind pops can no longer perform complex drone jobs.
蜂巢帝國“精神閹割”的人口現(xiàn)在不再可以在“復(fù)合子個體”崗位上工作。

Reduced the amount of jobs added by Leisure Arcology Districts to bring them into line with other Ecumenopolis districts.
現(xiàn)在“休閑生態(tài)區(qū)”區(qū)劃提供的崗位數(shù)與其他都市行星區(qū)劃提供的崗位數(shù)相同。

Ion cannons are no longer free to maintain, and have an upkeep cost of 8 energy.
恒星基地粒子炮不再免維護(hù)費，現(xiàn)在它們需要8點能量來維護(hù)。

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.
- 人口產(chǎn)出修正（不論正面負(fù)面）都不再適用于蜂巢思維。
- Made the -50% organic upkeep also apply to energy, for photosynthesis.
- 對“光合作用”來說，-50%有機體維護(hù)費的效果也同樣適用于能量。
- Devouring Swarm Necrophages now spawn with extra infrastructure to account for the lack of chambers of elevation.
- 死靈嗜殺蜂群現(xiàn)在在生成時將提供額外的基礎(chǔ)設(shè)施，來平衡彌補擢升之庭的缺失。

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

這里值得一提的是“實用建筑”的改動，我們知道額外的建筑槽位是這個民政的主要吸引力，但是即使在過了最初發(fā)布的炒作之后，這個民政也被這一條效果過度代表了。

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”補丁那樣，是我們提前規(guī)劃好要做的平衡性改動，但我們還是發(fā)現(xiàn)了一些要調(diào)整和平衡的地方，我們在未來的補丁中也會繼續(xù)這樣做。

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

...那么現(xiàn)在，讓我們交給Caligula Caesar，來瞅一瞅這些性能表現(xiàn)提升以及模組能力方面的話題。

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.

嗨！你可能已經(jīng)習(xí)慣了看我寫這些關(guān)于新的模組能力和腳本語言特性的長篇大論了。這一次，我們在這方面只有一點點東西可以炫耀，但還是有一些很酷的、技術(shù)性的東西可以談一下。

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?

盡管我對腳本語言非常了解，我總還是發(fā)現(xiàn)我拿捏不好腳本會對性能有多大影響。我所添加的這些東西是否會影響性能？好吧，我可以多多猜測怎樣有效編寫腳本，而且編程的一般概念（如應(yīng)用提前輸出）也是適用的。但差別有多大呢？通過識別低效的腳本并加以改進(jìn)，我們可以節(jié)省多少性能？

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在前一段時間的一個引以為豪的項目中取得了一些進(jìn)展，他將EU4的腳本分析器移植到了Stellaris上。唯一的問題是，它提供的信息相當(dāng)不完整（因為它需要在代碼的許多地方添加許多標(biāo)簽，基本上是在任何調(diào)用效果或觸發(fā)器的地方）。它也很難讀懂所提供的信息。但是現(xiàn)在，隨著守護(hù)者團隊的組建，是時候看看我們能對它做點什么了。

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)

在做了一些（非常冗長的）工作以使信息全面化、系統(tǒng)化和可讀化之后，我讓游戲在一個巨大的星系地圖上運行，對AI進(jìn)行了一些額外的提升——設(shè)定AI為0.75倍的研究成本、1.25倍的可居住行星，并在啟用腳本分析器的情況下運行了一年。然后，就可以發(fā)現(xiàn)問題了。我在附件中附上了這次輸出的兩個版本：一個是早期運行的版本，在全面收集到信息之前（值得注意的是，觸發(fā)器修正項和經(jīng)濟表都沒有），也是在采取任何優(yōu)化工作之前；另一個是現(xiàn)在的版本，在3.2版本號測試版中。(請注意，由于我在未優(yōu)化的調(diào)試模式下打開腳本分析器運行游戲，所以它在每個對象上花費的時間數(shù)字被大大地夸大了。）

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.

現(xiàn)在，我必須事先聲明，由于技術(shù)原因，我們無法在3.2版本號的更新中向公眾發(fā)布腳本分析器（目前，它被隱藏在編譯器旗標(biāo)后面，不對公眾開放）——使用它運行游戲會使游戲慢50%左右，所以我們得想出一個辦法，能夠隨意打開或關(guān)閉它以及它帶來的全部性能影響。但我們肯定希望我們能夠在未來將其發(fā)布給模組作者們。

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.

第一個重大發(fā)現(xiàn)是，游戲每天都在重復(fù)地為每個Pop重新計算某些游戲規(guī)則，這對性能產(chǎn)生了相當(dāng)不好的影響。最大的罪魁禍?zhǔn)资恰癱an_vote_in_democratic_election”這一條，事實證明，當(dāng)每個派系在計算其支持率時，每天都會對該國的每個Pop進(jìn)行檢查。是的，你沒有看錯：威權(quán)派系會檢查整個國家的每個Pop是否被允許投票，然后繁榮派系也會這樣做，然后威權(quán)派系，以此類推……這些情況通過利用每日緩存得到了解決：Pop現(xiàn)在會每天計算一次結(jié)果（或者，在計算species_has_happiness時，每天為一個國家的每個物種計算一次），代碼中的其他地方可以簡單地調(diào)用這個結(jié)果。此外，派系的支持率計算被優(yōu)化了，這樣他們除以支持率的總數(shù)就可以在每個國家計算一次，而不是每個派系計算一次。

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.

從腳本層面來說，通過追蹤各種被高頻使用的腳本，我們注意到一些易于優(yōu)化的代碼。 首先，graygoo.555事件會把一個事件觸發(fā)超級多次，但這個事件理應(yīng)只在灰蠱被激活的情況下（但并沒有）被觸發(fā)。原來這是因為它缺少了“is_triggered_only”參數(shù)，所以它每天都會在所有行星上被觸發(fā)！相似地，一些別的事件也使用了相似的腳本，但因為錯誤地把“always = no”作為觸發(fā)器，它們永遠(yuǎn)都不會被觸發(fā)。它們對性能造成了很小但仍然很明顯的影響，因此它們必須被移除。

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”這一好感度修正，相比起其他好感度修正占用了更多的性能，從大的層面來看這是十分奇怪的。事實證明這可以通過稍微更改一下觸發(fā)器的順序來解決：以往它會在驗證星海共同體成員資格之前檢查“is_in_breach_of_any”，這聽起來不是個大問題，但“is_in_breach_of_any”這個觸發(fā)器會隨即調(diào)用檢查所有已通過議案是否被違反的觸發(fā)器，因此實際上它對性能的影響是許多觸發(fā)器所造成的。簡單地交換順序在這里產(chǎn)生了很好的效果。

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 （不知為何是早期版本中性能消耗第二高的事件）是一個類似的情況，但復(fù)雜得多。主要問題是以下的腳本：

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:

這是非常低效的，而在應(yīng)用提前輸出原則后會有很大的提升。相對來說，使用“Count_owned_pop”作為計算方式的時候的成本是十分昂貴的，因為把腳本轉(zhuǎn)化為代碼并運算出結(jié)果會損失許多效率，當(dāng)一個星球有80人口的時候，腳本會遍歷每個人口并檢查與之相關(guān)的一系列觸發(fā)器。不幸的事，因為順序的原因，它會在每個沒有3個失業(yè)人口的星球上每天遍歷兩次。

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.

該事件每天，或至少經(jīng)常地，在每個已殖民星球上檢查這些觸發(fā)器。準(zhǔn)確來說，一年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

在確定有哪些類型的失業(yè)人口之前，它不會檢查星球上是否存在失業(yè)人口。這意味著OR會在兩個count_owned_pop部分都返回false，從而導(dǎo)致它兩者都會檢查。在開始附近添加“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.

它會檢查與非格式塔相關(guān)的失業(yè)人口的數(shù)量，且只有檢查完之后才會檢查這個國家是否是格式塔。把檢查是否是格式塔放到腳本一開始會使它只嘗試進(jìn)行其中一個“count_owned_pop”循環(huán)。

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

因而一個新的，更有效的觸發(fā)器版本如下：

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

進(jìn)一步分析帶來的收獲

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"

有一些很有趣的東西需要去解決，但除此之外，僅僅查看列表很難做出重大的性能優(yōu)化節(jié)省。使用電子表格！我們把結(jié)果粘貼到電子表格中，套用了幾個公式之后，一個不錯的透視表可以讓我們從可以細(xì)分看到“所有工作的總體影響是什么”，或者“潛在的人口派系的觸發(fā)器有什么影響”。

Picture shows values after performance improvements
圖片展示了性能優(yōu)化之后的數(shù)據(jù)

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 用相對來說較小的觸發(fā)次數(shù)造成了高的離譜的性能消耗。而罪魁禍?zhǔn)讋t是因為“planet_resource_compare”這一觸發(fā)器（主要在這里使用）消耗非常大。問題在于基本上它會重新計算星球上的所有資源輸出（包括檢查每個人口在制造什么?。?。事實證明可以通過有選擇地重新計算相關(guān)資源產(chǎn)出來減輕這一負(fù)擔(dān)（大致75%），但這樣的消耗對于一個觸發(fā)器來說仍然過高，所以我們減少了它的使用。我建議模組的開發(fā)者也不要過度使用它。

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.

還有一個意料之中的事實，崗位的計算耗時耗力，特別是對崗位權(quán)重和“可能”的檢查。我們已經(jīng)有一些在權(quán)重上節(jié)省時間的想法，但是還沒有準(zhǔn)備好討論這個（它們在3.2版本號的開發(fā)中發(fā)現(xiàn)得太晚了，沒法在補丁中顧及到，因為它們可能需要一些迭代），但是我們找到了一種使“可能”觸發(fā)器更容易使用的方法。原則上來講，每七天，人口都會重新計算它的工作崗位緩存，在這個時候它會檢查它是否能去做每一個崗位，如果結(jié)果為是，就計算權(quán)重。但是大多數(shù)崗位都有非常標(biāo)準(zhǔn)的“可能”觸發(fā)器來檢查這個過程中第一個部分。具體來說，工人、專家、統(tǒng)治者和無人機崗位有一組共用的觸發(fā)器。看上去，通過讓人口先計算這四個觸發(fā)器，就能很容易的匹配到正確的崗位，這會有非常顯著的改進(jìn)（幾乎提升了三分之二）。

(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，現(xiàn)在要定義possible_precalc = can_fill_ruler_job。如果你的mod動了這些內(nèi)容，你需要給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.

最后，盡管游戲規(guī)則的優(yōu)化已經(jīng)解決了一些關(guān)于人口派系的性能問題，但是仍然有很多可以改進(jìn)的地方，首先是這派系該不該存在：事實證明腳本和代碼都在檢查是否有5個人口會加入這個派系，當(dāng)派系成立的時候，就不會再檢查了。顯然這不夠理想，所以腳本檢查被我們砍了，代碼檢查也被修改了，對正在減少人口的派系不再生效。

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.

第二點是一個人口該不該加入這個派系：盡管所有的派系僅允許人口加入意識形態(tài)匹配的派系，但是根據(jù)這個進(jìn)行匹配的過濾太遲了。通過把它挪到代碼靠前點的位置，甚至是在腳本檢查之前（如果不希望這么做就加一個覆寫，比如在機器人的科技派系情況下），能大大降低了計算的消耗。

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.

最后，派系的要求檢查著實很有點離譜——它們每天都進(jìn)行檢查。通過改變順序以及使用等價但是更簡單的檢查方式（比如any_owned_species而不是any_owned_pop）。這也能有很顯著的作用，因此人口派系（不包括使用的游戲規(guī)則）的腳本使用量減少了三分之二。

Further Performance Topics

更進(jìn)一步的性能話題

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.

我希望這個工作能夠在游戲后期讓游戲卡頓好一點，我的測試證明這很成功，盡管很難量化。然而這個改進(jìn)只關(guān)注了腳本的性能，所以我們還有很多東西要關(guān)注！不要讓性能改進(jìn)停下來，希望我們有時間在3.3版本號中做進(jìn)一步的改進(jìn)。

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滯后，因為性能改進(jìn)，這可能會有稍微好一點，但是性能改進(jìn)工作并不關(guān)注UI。顯然UI當(dāng)中的部分沒有我們想的那么快，尤其是行星視圖、物種視圖和殖民地選擇菜單，我們正在想辦法給它們加速。（如果有人能想到別的，最好提出來，這將很有幫助?。?/p>

Moddability Improvements

模組能力改進(jìn)

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:

我寫一篇開發(fā)日志真的不能不談?wù)勀＝M能力的改進(jìn)，所以它們就在這里說。正如我所說，這次我們沒有那么多新玩意兒，但有一些大家可能想試試的新東西：

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.
現(xiàn)在出現(xiàn)了“create_nebula”（創(chuàng)建星云）效果。雖然它最好在銀河系生成期間使用，因為銀河系地圖上的視覺效果在游戲期間不會刷新。

Decisions can now have on_queued and on_unqueued effects.
決議現(xiàn)在可以使用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.
地貌改造現(xiàn)在使用Megacorp的經(jīng)濟系統(tǒng)。也就是說，成本是可設(shè)定的資源表，你可以用economic_unit來對成本進(jìn)行控制。

There's a species_gender trigger that checks what gender the species’ leaders can be
新增了一個species_gender的觸發(fā)器，用于檢查物種的領(lǐng)導(dǎo)者是什么性別。

You can now define custom tooltips for systems that you see when you mouse over them on the galactic map
你現(xiàn)在可以為銀河地圖的對象自定義鼠標(biāo)懸停的提示框。

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.
對于傳統(tǒng)，采用某個特定傳統(tǒng)的“可能”觸發(fā)器現(xiàn)在將顯示在提示欄中，如果沒能采納這個傳統(tǒng)的話。我也被告知，現(xiàn)在大家也可以在新增gridbox的時候?qū)鹘y(tǒng)類別填進(jìn)去。

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

還有一些東西需要模組作者進(jìn)行修改更新的（除了提過的地貌改造）：

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現(xiàn)在指的是行星上的所有軍隊，而不僅僅是行星所有者所有的軍隊

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和移除設(shè)計變種現(xiàn)在從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現(xiàn)在是一個觸發(fā)器，而不是權(quán)重作用域。

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.

作為模組能力的最后說明，對于那些錯過了關(guān)于更有干貨和深度的模組能力改動開發(fā)日志的人，不要擔(dān)心！任何使用過我們游戲新腳本的人都會知道，我們的腳本語言有著更大的潛力。還有很棒的東西在開發(fā)中，雖然在這個階段說我不能說它到底是什么或者在哪個補丁中。

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

最后，我也把腳本本文作為本篇開發(fā)日志的附件附上，這樣你就可以看到任何我忘記提及的改動了。而且，任何希望能提早獲得3.2版本號更新的modder（出于更新模組的目的），可以在此處報名登記：https://pdxint.at/3bZbVJN。

翻譯：Frost qqqqyyy 枸杞泡闊落

校對：一水戰(zhàn)阿部熊 三等文官猹中堂

歡迎關(guān)注UP主和主播小牧Phenix！

歡迎關(guān)注牧游社微信公眾號和知乎專欄！微信公眾號改版為信息流，歡迎【置頂訂閱】不迷路，即時獲得推送消息！

B站在關(guān)注分組中設(shè)置為【特別關(guān)注】，將會在私信內(nèi)及時收到視頻和專欄投稿的推送！

歡迎加入牧有漢化，致力于為玩家社群提供優(yōu)質(zhì)內(nèi)容！組員急切募集中！測試群組822400145!? ?