牧游社 牧有漢化翻譯

Stellaris Dev Diary #240 - Scripting Improvements in 3.3

Caligula Caesar, Stellaris Technical Scripter

Hello and welcome to another modding-based dev diary - as has become tradition in the weeks before releases in recent times. I fear that we may soon run out of ways to revolutionise the script system, but for now, there's some pretty cool improvements we have to show off which will be making their debut in 3.3 (you can try them out early in the open beta).

大家吼啊，歡迎閱讀另一篇主要關(guān)注Mod開(kāi)發(fā)的開(kāi)發(fā)日志——在更新發(fā)布前幾周發(fā)布與Mod開(kāi)發(fā)相關(guān)的開(kāi)發(fā)日志，已經(jīng)在最近成為了我們的傳統(tǒng)。我擔(dān)心我們可能很快就會(huì)窮盡改進(jìn)腳本系統(tǒng)的方法，但現(xiàn)在我們還是有一些好康的改進(jìn)能給大家看看的，它們將在3.3版本號(hào)中首次亮相（你也可以在開(kāi)放測(cè)試中試用）。

Script Values

腳本化數(shù)值

This story starts with weight fields. With which I mean something that looks a bit like this:

首先從權(quán)重方面開(kāi)始。這個(gè)系統(tǒng)差不多是下面這個(gè)樣子：

Code:
weight = {
base = 1
modifier = {
factor = 2
some_trigger = yes
}
}

We realised that the code underlying this script structure was not consistent: there were a number of distinct code implementations that varied in ways that were not readily obvious to the end user, the scripter. For instance, in certain ones, you could input "factor" or "add", in others, "factor" or "weight". Then there were the downright problematic cases: sometimes, when you set the base to 0, the game would read 1, and in one case (ai personalities) "factor" would actually count as "add"!

我們發(fā)現(xiàn)這個(gè)腳本結(jié)構(gòu)的底層代碼并不統(tǒng)一：有許多不同的代碼實(shí)現(xiàn)方式，對(duì)終端用戶（腳本編寫者）而言很難發(fā)現(xiàn)問(wèn)題。例如，在某些腳本中你輸入“factor”和“add”，在其它腳本中你則是輸入“factor”和“weight”。然后是出現(xiàn)問(wèn)題的情況：有時(shí)，當(dāng)你將基數(shù)設(shè)為0時(shí)，游戲會(huì)讀為1，在一種情況下（ai人格），“factor”實(shí)際上會(huì)按照“add”處理！

The solution here was to remove all the variations and consolidate them into one code implementation to rule them all. It would have to be made to incorporate the idiosyncrasies (except for the mentioned issues/bugs) of the existing versions (i.e. not break vast swathes of script), but on the other hand, having one system would allow for us to roll out improvements that could be used everywhere in the game.

這里的解決方案是刪除所有的變量，并將它們整合到一個(gè)代碼實(shí)現(xiàn)方式中。它必須結(jié)合現(xiàn)有版本的特性（除了提到的問(wèn)題/錯(cuò)誤）（即不破壞當(dāng)前的大量腳本），但另一方面，這個(gè)系統(tǒng)將允許我們推出可以在游戲中隨處使用的改進(jìn)。

Despite a few hitches at the start (I may or may not have accidentally had every anomaly capable of spawning on every planet, at one point), this proved quite achievable, so now we no longer need to worry about these fields working differently in different places. Basically the only variance left is whether their default value is 1 or 0.

盡管一開(kāi)始出現(xiàn)了一些問(wèn)題（我不能保證每一個(gè)異常現(xiàn)象都能在任何一個(gè)星球上生成），但事實(shí)證明，這是完全可以實(shí)現(xiàn)的，所以現(xiàn)在我們不再需要擔(dān)心這些東西在不同地方的工作方式不同?；旧希ㄒ皇Ｏ碌牟町愂撬鼈兊哪J(rèn)值是1還是0。

This done, a few more things could be added to the system. For instance, why just have "factor", "add" and "weight"? There are a lot of other mathematical operations out there. So we added subtraction, division, modulo, min, max, abs, and rounding (with round, floor, ceiling and round_to). We also made it no longer necessary to enclose these in "modifier = {}", if they were meant to always apply rather than be triggered.

這樣一來(lái)，系統(tǒng)中還可以添加更多的東西。例如，為什么我們只有“factor”、“add”和“weight”？還有很多其他的數(shù)學(xué)運(yùn)算。所以我們添加了減法、除法、模、最小值、最大值、絕對(duì)值和舍入（包括四舍五入、向下取整、向上取整）。如果它們總是要被使用而不是被觸發(fā)的話，我們也不再需要將它們括在“modifier={}”中。

But that was just the start. Back in 3.1, we added the ability to use "trigger:<trigger>" in lieu of a number in places such as this, to allow some more complicated maths (so it would take the result of the trigger e.g. num_pops could return 32 pops instead of an absolute number). The code behind this wasn't quite ideal, though. Basically, whenever the game wanted to calculate what "trigger:num_pops" meant, it would take the string "trigger:num_pops", see if it started with "trigger:", if yes then shave that off, and then try and make a trigger from the remainder (and log an error if it failed). Unfortunately, this wouldn't happen during startup, but rather whenever the game encountered this in script - for example, if it was needed to calculate a tooltip, it would be doing this every frame. Which made it annoying to debug and more potentially costly performance-wise than it needed to be.

但這只是開(kāi)始?；氐?.1版本號(hào)中，我們添加了使用“trigger:<trigger>”來(lái)代替這種數(shù)字的功能，以允許進(jìn)行一些更復(fù)雜的數(shù)學(xué)運(yùn)算（因此它將使用觸發(fā)器的結(jié)果，例如num_pops可以返回“32 pops”，而不只是32）。不過(guò)，這背后的代碼并不十分理想?；旧希慨?dāng)游戲想要計(jì)算“trigger:num_pops”是什么意思時(shí)，它都會(huì)使用字符串“trigger:num_pops”，查看它是否以“trigger:”開(kāi)頭，如果是，則將其刪除，然后嘗試從剩余部分中創(chuàng)建一個(gè)觸發(fā)器（如果失敗，則記錄錯(cuò)誤）。不幸的是，這不會(huì)發(fā)生在啟動(dòng)期間，而是發(fā)生在當(dāng)游戲在腳本中每次遇到這種情況時(shí)——例如，如果需要計(jì)算提示欄中的數(shù)據(jù)，它會(huì)在每一幀都這樣做。這使得調(diào)試變得很煩人，而且在性能方面的潛在消耗比實(shí)際需要的要高。

This could be done better. So, for 3.3, we made a container called a "CVariableValue", which could contain several objects:

這是可以被改進(jìn)的地方。所以，在3.3版本號(hào)中，我們做了一個(gè)叫“CVariableValue”的容器，它可以容納多個(gè)對(duì)象。

- An integer or fixed point (basically just a normal number)
- 一個(gè)整數(shù)或小數(shù)點(diǎn)位置固定的數(shù)（一個(gè)普通的數(shù)字）

- A scope/event target - so you could refer to "owner.trigger:num_pops"
- 一個(gè)作用域或事件對(duì)象-可以參考“owner.trigger:num_pops”

- A trigger
- 一個(gè)觸發(fā)器

- A modifier definition
- 一個(gè)修正項(xiàng)定義

- A variable string
- 一個(gè)可變的字符串

- A script value*
- 一個(gè)腳本化數(shù)值*

* I'll get back to this later.
* 我之后會(huì)回來(lái)講這個(gè)地方

Basically, whenever the game would read a script value, it'd work out what it is on startup. This means that whenever the actual value is needed, it would not have to chop up the string and work out what is wanted, but it could simply give the value or call the trigger that is specified. Coincidentally, this system also made it vastly easier to roll out the ability to use "trigger:<trigger>" in various places, so if there are more places where they'd be desirable, we really don't have that many excuses not to provide them there (uh oh).

基本上，每當(dāng)游戲讀取腳本化數(shù)值時(shí)，它都會(huì)在啟動(dòng)時(shí)計(jì)算出腳本化數(shù)值。這意味著，無(wú)論何時(shí)需要實(shí)際值，它都不必切碎字符串并計(jì)算出所需內(nèi)容，而是可以簡(jiǎn)單地給出值或調(diào)用指定的觸發(fā)器。巧合的是，這個(gè)系統(tǒng)也使得在不同的地方推廣使用“trigger：<trigger>”變得非常容易，所以如果有更多的地方需要它們的話，我們真的沒(méi)有那么多借口不提供它們（迫真）。

The modders amongst you will have noticed that there's a few extra things we made possible along the way, there. Firstly, a quick win was to let you call "modifier:<modifier>" in the same way as you'd call "trigger:<trigger>". Basically, if a pop had +20% citizen happiness modifiers applying to it, and you used "modifier: pop_citizen_happiness", you'd get 0.2. The other thing we added was script values.

Mod作者可能注意到了，我們?cè)谶@個(gè)過(guò)程中可能還做了點(diǎn)額外的東西。首先要簡(jiǎn)單說(shuō)的是，現(xiàn)在調(diào)用“modifier:<modifier>”和調(diào)用“trigger:<trigger>”方式相同。大體上，如果要對(duì)一個(gè)人口使用一個(gè)+20%幸福度修正，并且你使用了“modifier: pop_citizen_happiness”，你會(huì)獲得0.2。此外，我們添加進(jìn)去的另一個(gè)內(nèi)容是腳本化數(shù)值。

The idea for these came from newer PDS games, the Content Designers of which would taunt us with their games' superior script maths capabilities. Basically, the gist of what made them powerful was being able to substitute a value for a key which would run a series of calculations on demand. So "my_script_value" could be 57 + ( 24 * num_pops ) / num_colonies, or something like that. With the already-mentioned changes, we were almost there, so we added a new thing (named after script_values and capable of many of the things they are capable of in our newer games, but actually sharing very little code, so the exact workings probably vary a bit).

這些新想法來(lái)自于比Stellaris更晚的PDS游戲，那些游戲的內(nèi)容設(shè)計(jì)師會(huì)用他們游戲中更優(yōu)越的腳本數(shù)學(xué)性能來(lái)嘲諷我們?；旧?，讓它們的游戲性能強(qiáng)大的關(guān)鍵就是“讓數(shù)值代替鍵值”，這樣就能根據(jù)需要進(jìn)行一系列的計(jì)算。所以“my_script_value”可以是57+（24*num_pops）/num_colonies，或者是類似的東西。通過(guò)前面提到的修改，我們幾乎做到了，所以我們添加了一個(gè)新東西（命名為script_value，能夠在我們的新游戲中實(shí)現(xiàn)許多功能，但實(shí)際上相同的代碼很少，因此實(shí)際的工作方式可能會(huì)有一點(diǎn)不同）。

These "script values" would basically be a weight field like that mentioned at the start of this section, which would be defined by key in a script_values directory, e.g.

這些“script values”實(shí)際上是權(quán)重字段，就如本段開(kāi)始所說(shuō)的，由script_values目錄中的鍵值定義的。下面是示例。

Code:
leader_cost = {
base = 2
modifier = {
subtract = 6
num_owned_leaders > 5
}
modifier = {
add = trigger:num_owned_leaders
num_owned_leaders > 5
}
mult = 50
}

Then we could refer to it anywhere in the game via "value:leader_cost", and it would calculate the value on demand. We are already finding this very useful in improving the game's scripts - not only is it easier to get correct values with this, but we can also radically cut down on copy-pasted scripts in weight fields (job weights, I’m coming for you!). Conveniently, since script values are read in a similar way to scripted values and triggers, we can feed in parameters, e.g. value:my_value|PARAMETER|50| would have the game use the script value my_value where any instance of "$PARAMETER$" would be substituted with 50.

然后我們可以在游戲的任何地方使用“value:leader_cost”，它將根據(jù)需要計(jì)算數(shù)值。我們已經(jīng)發(fā)現(xiàn)這在改進(jìn)游戲腳本方面非常有效——不僅更容易獲得正確數(shù)值，同時(shí)能從根本上減少權(quán)重字段中復(fù)制粘貼的腳本（崗位權(quán)重，說(shuō)你呢！）。方便的是，因?yàn)槟_本化數(shù)值讀取方式和預(yù)設(shè)數(shù)值及觸發(fā)器的讀取方式類似，我們能直接輸入?yún)?shù)。比如value:my_value|PARAMETER|50|將讓游戲使用腳本值my_value，并將所有的“$PARAMETER$”替換為50。

Even with all these changes, there were still a couple more we could make to the scripting language. The first was adding complex_trigger_modifiers to script_values and weight fields. Basically, these allow you to use the value of triggers too complicated to use with "trigger:<trigger>". An example would be this:

即便已經(jīng)有了這些改動(dòng)，我們還是能對(duì)腳本語(yǔ)言做進(jìn)一步的改進(jìn)。第一個(gè)就是將complex_trigger_modifiers增加到script_values和權(quán)重中。大體上，這會(huì)允許你使用復(fù)雜到用不了“trigger:<trigger>”的觸發(fā)器值。以下是例子：

Code:
complex_trigger_modifier = { #fewer worlds => more menace from destroying one
trigger = check_galaxy_setup_value
parameters = { setting = habitable_worlds_scale }
mode = divide
}

This works with the same triggers that work with export_trigger_value_to_variable. We also added a few triggers to these: notably, all count_x script list triggers (e.g. count_owned_planet), and the "distance" trigger.

這對(duì)于能對(duì)export_trigger_value_to_variable生效的觸發(fā)器都可以生效。我們也在以下方面增加了幾個(gè)觸發(fā)器：特別是所有的count_x腳本菜單觸發(fā)器（例如count_owned_planet），以及“距離”觸發(fā)器。

A comprehensive guide on all you can do with script values is attached to this post (and in common/script_values). To be honest, it's hard to overstate the amount of things this new system system enables us to potentially do. For instance, in the example above, we scaled leader costs based on how many leaders you own. We also scaled Unity boosts with the Autochthon Monument based on how many ascension perks you have unlocked with this method. The list goes on and will continue to grow with each update we release.

如何使用這些腳本化數(shù)值的全面指南在文后的附件（還有common/script_values）中。說(shuō)實(shí)話，這個(gè)新系統(tǒng)能讓我們干的事簡(jiǎn)直說(shuō)不完。比方說(shuō)，在上邊的例子中，我們將領(lǐng)袖花費(fèi)與你有多少領(lǐng)袖掛鉤。我們也可以讓先驅(qū)者紀(jì)念碑提供的凝聚力加成和你解鎖了多少個(gè)飛升天賦相關(guān)。相關(guān)例子還有不少，隨著我們的不斷更新也會(huì)越來(lái)越多。

Mod Overwriting

Mod覆寫

Script values isn't the only thing I can talk about today. Modders have long been a bit bemused by the different ways elements of the game handle overwriting. Specifically, by the way it varies. Unfortunately, they will probably continue doing so for a while yet, but since a bit of progress was made here, I felt it would be interesting to people to know why this sort of issue occurs.

我今天能說(shuō)的可不止是腳本化數(shù)值。Mod制作者們經(jīng)常被這游戲各種各樣處理覆寫的方式搞得有點(diǎn)暈頭轉(zhuǎn)向，而且覆寫方式實(shí)在有點(diǎn)多。不幸的是，這段時(shí)間內(nèi)這一點(diǎn)恐怕沒(méi)法改變了，但是我們既然已經(jīng)做出了一些進(jìn)展，我覺(jué)得和大伙兒說(shuō)說(shuō)為什么會(huì)有這種問(wèn)題還是挺有意思的。

Basically, when modders overwrite the vanilla files, they can either overwrite the entire file (which always works), or they can overwrite individual entries within the file, for example the "miner" job. When the game encounters a second entry that matches the key of an existing one, various things can happen:

大體上，當(dāng)Mod制作者們覆寫原版游戲時(shí)，他們要么覆寫整個(gè)文件（總是能夠生效），要么只覆寫文件中的個(gè)別條目，比方說(shuō)“礦工”崗位。當(dāng)游戲遇到了第二個(gè)符合現(xiàn)有鍵值的條目時(shí)，可能會(huì)發(fā)生許多不同的事情：

- It replaces the existing one perfectly (last read is used)
- 完美取代了原先的條目（只采用最后讀取的那個(gè)）。

- It replaces the existing one, but imperfectly, e.g. if you individually overwrite jobs, you can no longer refer to them in modifiers (not ideal)
- 取代了原先的條目，但是不太完美，比方說(shuō)你重寫了個(gè)別崗位，你就不能在修正項(xiàng)中指向它們了（不太理想）。

- The second entry is ignored (first read is used)
- 第二個(gè)條目被無(wú)視（采用了首次讀取的）

- Both the first and the second entries are kept (duplication - not ideal)
- 第一次讀取和第二次讀取的條目都被保留了（重復(fù)——并不理想）

- It appends the information inside to the existing entry (special case for on_actions)
- 在已有條目后追加了新條目的信息（on_actions的特殊情況）。

So, why are there these various behaviours? Basically, it is largely a matter of how the database is read in the C++ code.

那么，為什么會(huì)有這么多不同的行為呢？主要還是因?yàn)镃++代碼中數(shù)據(jù)庫(kù)的讀取方式。

When the game encounters script files, as a rule, it will read the object (e.g. miner = { }) and store that in a matching database (e.g. the job type database), which the game will use in various ways when it needs to do stuff with that matching object type. In the case of many of the oldest objects in the game (stuff that has existed largely in its current form since before release, e.g. technologies and ethics), they would be coded in as an object in a custom-made database. Since the code for reading this database would be written afresh (or copied) each time a new object was defined, both the order in which it would read files (A to Z or Z to A) and the way it would treat duplicates could vary, which is not ideal. In some cases, this made sense: for example, in on_actions, there is a legitimate cause for special handling - basically, the intention there is that modders can use on_actions without having to worry about Vanilla contents. This is also the case for heavily code-dependent databases, such as diplomatic actions, where one cannot simply add an entry and expect the code to know what to do with it.

當(dāng)游戲遇到腳本文件時(shí)，按照規(guī)則，它會(huì)讀取對(duì)象（比如miner={ }）并將其存儲(chǔ)在對(duì)應(yīng)的數(shù)據(jù)庫(kù)中（比如崗位類型數(shù)據(jù)庫(kù)），而對(duì)于匹配的對(duì)象類型，游戲會(huì)用多種方式使用數(shù)據(jù)庫(kù)。對(duì)于游戲中許多的最老的對(duì)象而言（那些從發(fā)售前到現(xiàn)在基本沒(méi)怎么變的東西，比如科技和思潮），它們是作為特制數(shù)據(jù)庫(kù)中的對(duì)象編碼出來(lái)的。因?yàn)樽x取這個(gè)數(shù)據(jù)庫(kù)的代碼每次定義新對(duì)象的時(shí)候都要重新寫一遍（或者復(fù)制過(guò)去），它讀取文件的順序（A到Z或者Z到A）和它對(duì)待復(fù)制品的方式也會(huì)有所不同，這就不太好了。在某些情況下，這說(shuō)得通：比如在on_actions中，對(duì)于這種特殊處理方式確實(shí)有合適的原因——原因大致是Mod開(kāi)發(fā)者們可以在完全不用擔(dān)心原版內(nèi)容的情況下用on_actions。對(duì)于一樣特別依賴于代碼的數(shù)據(jù)庫(kù)來(lái)說(shuō)也是如此，比如外交行動(dòng)，這時(shí)候就沒(méi)法加一行代碼然后指望它還能知道怎么處理這個(gè)。

But for most cases, this is simply a matter of tech debt: nowadays, we have better ways of coding in databases. When we add a new object, we now (since a couple of years) add it as a TGameDatabaseObject in a TSingleObjectGameDatabase. The standard code for the TSingleObjectGameDatabase handles the reading of objects and need not be copy-pasted, and most importantly for modders, it handles overwriting by deleting the existing object and replacing it with the new one.

但是在大多數(shù)情況下，這就是一個(gè)簡(jiǎn)單的“技術(shù)債”問(wèn)題（譯注：指開(kāi)發(fā)團(tuán)隊(duì)早期選擇了一個(gè)短期內(nèi)易于實(shí)現(xiàn)的方案，但從長(zhǎng)遠(yuǎn)來(lái)看，這種方案會(huì)帶來(lái)消極的影響）。當(dāng)下我們有了更好的數(shù)據(jù)庫(kù)中的編程方法。當(dāng)我們?cè)黾右粋€(gè)新的對(duì)象時(shí)，我們（從幾年前開(kāi)始）會(huì)把它作為TSingleObjectGameDatabase中的TGameDatabaseObject添加進(jìn)去。TSingleObjectGameDatabase中的標(biāo)準(zhǔn)代碼可以處理對(duì)象的讀取，也不需要復(fù)制粘貼了，而且對(duì)于Mod制作者來(lái)說(shuō)十分重要的是，它可以通過(guò)刪除原有對(duì)象再用新增對(duì)象代替的方式處理覆寫問(wèn)題。

This usually works well for modders, but there were some high-profile cases where it didn't: in the cases of jobs, districts, planet classes and a few others, modifiers would be broken, i.e. a modifier adding miner jobs to a planet would end up doing nothing. Basically, what would happen is, the job would create modifiers, which would be a) added to the modifier database and b) stored in the game's job definition (not the script file, but rather what the program gets from reading the script file) - which allows the game to attach an effect to that modifier (i.e. grant x number of this job). Then the job would be deleted and a new one would be made. It too would create modifiers in the same way. But now the modifier list would have two entries with the same key. Then, when the game encounters such a modifier when it is used in a script file, it will look through the list, find the first one which matches, and assume that was the one intended. Unfortunately, the job itself thinks that the second modifier applies to it. As a result, the modifier - for the intents and purposes of a modder - becomes unusable.

通常來(lái)說(shuō)，這對(duì)于Mod制作者能正常生效，但無(wú)法應(yīng)對(duì)一些經(jīng)常出現(xiàn)的情況：對(duì)于崗位、區(qū)劃、行星類型以及其他一些情況來(lái)說(shuō)，修正項(xiàng)會(huì)損壞，也就是說(shuō)，一個(gè)給行星增加礦工崗位的修正向最后什么也不會(huì)增加。大致上發(fā)生的情況就是，這個(gè)崗位會(huì)創(chuàng)造修正項(xiàng)，這會(huì)是：a）增加到修正項(xiàng)的數(shù)據(jù)庫(kù)中，以及b）儲(chǔ)存在游戲的崗位定義當(dāng)中（不是腳本文件，而是程序從腳本文件中得到的東西）——這會(huì)允許游戲?yàn)檫@個(gè)修正項(xiàng)增加效果（比方說(shuō)加X(jué)個(gè)這個(gè)崗位）。然后崗位就會(huì)被刪除，新的崗位就會(huì)創(chuàng)造出來(lái)。它也會(huì)以同樣方式創(chuàng)造出修正項(xiàng)。但是現(xiàn)在，修正列表中會(huì)有兩個(gè)有著相同鍵值的條目。之后，游戲遇到一個(gè)在腳本文件中這么用的修正項(xiàng)時(shí)，就會(huì)過(guò)一遍列表，找到第一個(gè)匹配的，并且認(rèn)為這就是需要的那個(gè)。不幸的是，崗位本身覺(jué)得是用的是第二個(gè)修正項(xiàng)。最后的結(jié)果就是，對(duì)于Mod制作者的目的而言，這個(gè)修正項(xiàng)就發(fā)揮不了作用。

I can report good news on this front, though - we fixed that issue. These objects can now be overwritten safely, or at least, this particular cause is not a reason for their overwriting to break - the modifiers will now function properly. (Why the caution? Well, basically, if adding an entry to one database alters another database, then overwriting it can cause issues unless carefully handled; luckily, this is fairly rare aside from the example of modifiers). This will hopefully be quite useful to modders, since jobs and districts are some of the objects that the are probably most likely to want to alter.

不過(guò)，這方面我可以說(shuō)一些好消息——我們已經(jīng)修復(fù)了這個(gè)問(wèn)題。這些對(duì)象現(xiàn)在可以安全地覆寫了，或者說(shuō)至少這個(gè)特定的原因不再會(huì)導(dǎo)致覆寫不管用了——這些修正項(xiàng)現(xiàn)在可以正常工作。（為什么這么小心呢？好吧，因?yàn)槿绻粋€(gè)數(shù)據(jù)庫(kù)中增加條目會(huì)改變另一個(gè)數(shù)據(jù)庫(kù)，覆寫還是會(huì)導(dǎo)致問(wèn)題，除非處理得非常謹(jǐn)慎；幸好，除了這個(gè)修正項(xiàng)的例子之外，這樣的情況非常少見(jiàn)）。希望這個(gè)改動(dòng)對(duì)于Mod制作者來(lái)說(shuō)會(huì)很有用，因?yàn)閸徫缓蛥^(qū)劃大概是他們最想改動(dòng)的東西吧。

As a final note on TGameDatabaseObjects, since the way they are all read uses the same lines of code, we added a small gift for modders: the error log message warning about overwrites will now specify exactly which one is used, removing some of the ambiguity in overwriting. So if you see this error message, you can be fairly confident of how the game is behaving:

最后還要說(shuō)一下TGameDatabaseObjects，因?yàn)樗鼈冏x取的方式使用了同樣的幾行代碼，我們?yōu)镸od制作者們?cè)黾恿艘粋€(gè)小禮物：覆寫的錯(cuò)誤記錄警報(bào)信息會(huì)特別指出實(shí)際上用了哪一個(gè)條目，這樣就能去掉一些覆寫時(shí)的不確定性了。如果你看到了這條錯(cuò)誤信息，你就能比較確定游戲的運(yùn)行方式了。

[14:03:02][game_singleobjectdatabase.h:147]: Object with key: miner already exists, using the one at file: common/pop_jobs/03_worker_jobs.txt line: 319

As a side note, we've extended the 3.3 Unity Open beta feedback period until Monday, February 7th. We will be leaving the Open beta branch available until 3.3 releases so those of you who are currently playing on the open beta can continue your games until 3.3 releases. And if you haven't yet, please leave your feedback on the 3.3 Unity Open beta here!

還有件事，我們把3.3版本號(hào)凝聚力改動(dòng)的開(kāi)放測(cè)試反饋環(huán)節(jié)延長(zhǎng)到了2月7日星期一。我們也會(huì)把開(kāi)放測(cè)試一直開(kāi)到3.3版本號(hào)發(fā)布為止，這樣你們還沒(méi)玩完的話就可以繼續(xù)玩到3.3版本號(hào)發(fā)布了。如果你還沒(méi)留下反饋的話，請(qǐng)務(wù)必到這里提供你對(duì)于3.3版本號(hào)凝聚力改動(dòng)的開(kāi)放測(cè)試的反饋！

Don't miss the next episode of Dev clash 2022 on Monday, February 7th, starting at 1500 CET.

別錯(cuò)過(guò)了星期一，2月7號(hào)的2022年的開(kāi)發(fā)者大戰(zhàn)，歐洲中部時(shí)間15:00開(kāi)始！

http://twitch.tv/paradoxinteractive

That's all for this week! Eladrin will be back next week to share his thoughts on the open beta and, of course, the dev clash!

這周就到這里了！Eladrin下周會(huì)回來(lái)說(shuō)說(shuō)他對(duì)于開(kāi)放測(cè)試當(dāng)然還有開(kāi)發(fā)者大戰(zhàn)的感想！

翻譯：枸杞泡闊落 AntiAccess

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

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

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

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

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

本作品英文原文著作權(quán)屬Paradox interactive AB所有，中文譯文著作權(quán)屬牧有漢化所有。