---
# System prepended metadata

title: KubeJS 6.1 譯文
tags: [Translation, Fabric, Forge, Modded, KubeJS]

---

---
description: KubeJS 6.1 更新譯文
image: https://repository-images.githubusercontent.com/46427577/d2446680-c366-11ea-8e6b-8a4da776b475
---

:::info
Note: Use [DeepL](https://www.deepl.com/translator) to translate to Simplified Chinese and use [zhconvert](https://zhconvert.org/) to convert to `Traditional Chinese`.
Message Links:
- [KubeJS 6.1 - Changes for Script and Pack Developers](https://discord.com/channels/303440391124942858/678385948706209822/1125804062332440736)
- [KubeJS 6.1 - Changes for Addon Developers](https://discord.com/channels/303440391124942858/678385948706209822/1125804134281510983)

---

注：使用[DeepL](https://www.deepl.com/translator)翻译成简体中文与使用[繁化姬](https://zhconvert.org/)转换成`繁体中文`
信息连结：
- [KubeJS 6.1 - Changes for Script and Pack Developers](https://discord.com/channels/303440391124942858/678385948706209822/1125804062332440736)
- [KubeJS 6.1 - Changes for Addon Developers](https://discord.com/channels/303440391124942858/678385948706209822/1125804134281510983)

---

註：使用[DeepL](https://www.deepl.com/translator)翻譯成簡體中文與使用[繁化姬](https://zhconvert.org/)轉換成`繁體中文`
訊息連結：
- [KubeJS 6.1 - Changes for Script and Pack Developers](https://discord.com/channels/303440391124942858/678385948706209822/1125804062332440736)
- [KubeJS 6.1 - Changes for Addon Developers](https://discord.com/channels/303440391124942858/678385948706209822/1125804134281510983)
:::

---

[TOC]

---

# English

## KubeJS 6.1 - Changes for Script and Pack Developers

Hey y'all! As KubeJS 6.1 for 1.19.2 is now shaping up for a full release, I've wanted to summarise the main important changes for both addon and script devs here, in order to let you prepare for this release before it's available for public use. Dev builds are available on <https://kubejs.com/downloads/dev-builds> and the Saps maven as usual, and we've already prepared some stuff for testing with certain pack dev teams, as well!

Because this is mostly a massive under the hood and API cleanup, I'll try to keep this user-facing changelog short and sweet, and focus on the addon relevant changes a little later. The most important changes you as a script developer might notice are as follows:
- New wrapper `FluidAmounts` for... fluid amounts! This allows for better cross-loader script compatibility and provides some nice shortcuts for common fluid values like block, ingot and nugget!
- Scheduled events now take in durations (especially strings such as `200 t` for tick durations as well) for their delays! 
- Both `NetworkEvents` have been merged into a single `NetworkEvents.dataReceived`, which handles incoming data based on the script type.
- Registry: `event.custom(T)` is now `event.createCustom(() => T)` and takes in a *supplier* rather than an object reference
- `event.cancel()` now **immediately** exits from the event, and **custom event results** (`event.cancel()`, `event.exit()`, `event.success()`, as well as variants of those holding result values) have been introduced!
- Say goodbye to tag workarounds! Tags have been fixed on initial world load, so **please** stop using /reload in a script already
- Better recipe event performance! (Some would even hesitate to say "better than Vanilla" *in some select cases*)
- Custom toasts: You can now use `player.notify` and the new `Notification` binding to create custom vanilla-style toast notifications!
- Data and resource pack zips can now be loaded directly from the kubejs/data and kubejs/assets folders; no need to unzip and merge them anymore!
- Also watch out for these two Ingredient changes:
  - `Ingredient.of('2x thing')` is now `InputItem.of('2x thing')`. If you use *anything other than this syntax* for ingredient stacks however, you'll be fine!
  - Ingredient stacks and item outputs are no longer *directly* JSON serialisable, as that logic is specific per recipe type; but you can still serialise their parts and create the JSON yourself

And that's about it for all the user and dev facing changes I could think of! There's some other stuff I haven't listed here, and feel free to also check out our wiki for a more detailed 6.1 changelog at <https://wiki.latvian.dev/books/kubejs/page/kubejs-61-update>, which we will be updating as we go along and add some finishing touches to this release!

Now, onto the changelog for addon devs!

## KubeJS 6.1 - Changes for Addon Developers

### Recipe Changes

#### Recipe Schemas
This is __the big one__. Recipe schemas *completely* change the way custom recipe handlers are registered in KubeJS, and should hopefully also mean a lot less boilerplate code down the line for you. Each recipe is now defined by a *schema* containing a set of *recipe components*, with those components acting as "codecs" for the underlying values. For you, this means the following:
- Instead of primarily using RecipeJS subclasses, you will now have to define a **RecipeSchema**
  - Each schema uses a set of **RecipeKeys**, which are named **RecipeComponents** with some additional properties like optional default values and settings for automatic constructor and method generation
  - A **RecipeComponent** is a reusable definition of a recipe element (such as an in/output item, a fluid, or even just a number value) that has a role (input, output, other), a description (for use in addon mods like ProbeJS) and contains logic for (de)serialisation and bulk recipe operations (i.e. recipe filtering and replacement). There are lots of standard components provided in the `dev.latvian.mods.kubejs.recipe.component` package, including blocks, items and fluids, generic group and logic components (array, map, pair, either, optional), and all kinds of primitives (including specialised ones such as number ranges and characters)
  - While the recipe schema *will* generate constructors by default, you can override this behaviour by defining one yourself using `constructor(factory, keys)`. Note that this will stop the default constructor from being generated, so if you want to keep that, you will have to define it yourself again.
  (A good example of complex custom recipe constructors is `ShapedRecipeSchema`)
- While schemas replace **RecipeJS** on the java side, on the JS side, the user is still passed a **RecipeJS** object after creation, with additional autogenerated "builder" methods for each component to allow for the user to set e.g. optional values after recipe creation  (e.g. `event.smelting(...).xp(20).cookingTime(100)`), and you can add even more properties or do additional after-load validation by overriding the recipe factory entirely!

#### InputItem and OutputItem
Instead of augmenting vanilla classes to add functionality for ingredient stacks and chance items to recipes, we now use two entirely separate classes for this: `InputItem` and `OutputItem`. These classes have completely replaced `Ingredient` and `ItemStack` almost everywhere within recipes, and mostly just serve as simple wrappers for recipe schemas. (There are also recipe-aware methods in the schema which allow you to fine tune how item in-/outputs should be parsed!)

#### Generifying recipe replacement (still WIP, for now all you need to know is InputMatch => ItemMatch)

### Event changes
- As mentioned in the other part of the changelog above, events now return `EventResult`. This is similar to the class of the same name in Architectury, or `InteractionResult(Holder)` in vanilla, and you can use this to give users finer control over event return values.
- Events are now registered using a `ScriptTypePredicate`, meaning you can use a single event handler for events that are fired on both sides (`group.common`)! Events now also *only* fire for their relevant script type (though you can use `ScriptTypePredicate.SERVER.negate()` to have something be fired for startup AND client)

### Misc. Changes
- KubeJS should no langer hang up datagen from finishing on Forge.
- Most event listeners are now only fired if they have listeners. While this is only convention, you should still probably do this in your addons as well to improve performance.
- Bindings can now be added through mod resources, without declaring a KubeJS plugin! (Thanks to LLytho for this change!)

---

# 简体中文

## KubeJS 6.1 - 脚本和包开发者的变化

嗨，大家好! 由于1.19.2版本的KubeJS 6.1正在形成一个完整的版本，我想在这里总结一下插件和脚本开发者的主要重要变化，以便让你在这个版本可以公开使用之前做好准备。开发版本可以在<https://kubejs.com/downloads/dev-builds>和Saps maven上找到，而且我们已经准备了一些东西供某些包的开发团队测试！

因为这主要是一个大规模的后台和API清理，我将尽量使这个面向用户的变化日志简短而温馨，并在稍后关注与附加组件相关的变化。作为一个脚本开发者，你可能会注意到最重要的变化如下：
- 新的包装器`FluidAmounts`用于......液体数量 这允许更好的跨加载器脚本兼容性，并为常见的流体值提供了一些很好的快捷方式，如块状、锭状和金块状!
- 预定的事件现在可以接受其延迟时间（特别是字符串，如`200 t`，也可用于tick持续时间）! 
- 两个 "NetworkEvents "都被合并为一个 "NetworkEvents.dataReceived"，它根据脚本类型处理传入的数据。
- 注册表：`event.custom(T)`现在是`event.createCustom(() => T)`，并且接收一个*供应商*，而不是一个对象引用。
- `event.cancel()`现在**立即从事件中退出，并且引入了**自定义事件结果**（`event.cancel()`、`event.exit()`、`event.success()`，以及那些持有结果值的变体
- 告别标签的变通! 标签在世界初始加载时已被修复，所以请***停止在脚本中使用/reload。
- 更好的配方事件性能! (有些人甚至会犹豫说 "比Vanilla好 "*在一些特定的情况下*)
- 自定义敬酒： 你现在可以使用`player.notify`和新的`Notification`绑定来创建自定义香草风格的敬酒通知!
- 数据和资源包的压缩包现在可以直接从kubejs/data和kubejs/assets文件夹中加载；不再需要解压和合并它们了!
- 还要注意这两个Ingredient的变化：
  - `Ingredient.of('2x thing')`现在是`InputItem.of('2x thing')`。如果你使用除此语法之外的任何其他语法*进行成分堆叠，你会没事的
  - 食材堆和物品输出不再是*直接*的JSON序列化，因为这种逻辑是针对每个配方类型的；但你仍然可以序列化它们的部分并自己创建JSON。

这就是我所能想到的所有用户和开发人员面临的变化! 还有一些其他的东西我没有在这里列出，请随时查看我们的维基，了解更详细的6.1变化日志<https://wiki.latvian.dev/books/kubejs/page/kubejs-61-update>，我们将在继续更新，为这个版本添加一些收尾工作！

现在，让我们来看看附加组件开发者的更新日志吧

## KubeJS 6.1 - Addon Developers的变化

### 配方变化

#### Recipe Schemas
这是个大问题。配方模式*完全*改变了自定义配方处理程序在KubeJS中的注册方式，希望这也意味着你可以减少很多模板代码。现在，每个配方都是由一个*schema*定义的，其中包含一组*配方组件*，这些组件作为基础值的 "编解码器 "发挥作用。对你来说，这意味着以下几点：
- 现在你不再主要使用RecipeJS子类，而是要定义一个**RecipeSchema**。
  - 每个模式都使用一组**RecipeKeys**，它们被命名为**RecipeComponents**，具有一些额外的属性，如可选的默认值和自动构造器和方法生成的设置。
  - 一个**RecipeComponent**是一个可重复使用的配方元素的定义（如一个输入/输出项目，一个流体，甚至只是一个数字值），它有一个角色（输入、输出、其他），一个描述（用于ProbeJS等附加模块），并包含（去）序列化和批量配方操作（即配方过滤和替换）的逻辑。`dev.latvian.mods.kubejs.recipe.component`包中提供了很多标准组件，包括块、项目和流体、通用组和逻辑组件（数组、地图、对、任一、可选），以及各种基元（包括数字范围和字符等专用的基元）。
  - 虽然配方模式*会默认生成构造函数，但你可以通过使用`constructor(factory, keys)`自己定义一个构造函数来覆盖这一行为。请注意，这将阻止默认构造函数的生成，所以如果你想保留它，你必须再次自己定义它。
  ("ShapedRecipeSchema "是复杂的自定义配方构建器的一个好例子)
- 虽然模式在java方面取代了**RecipeJS**，但在JS方面，用户在创建后仍然会被传递一个**RecipeJS**对象，每个组件都有额外的自动生成的 "构建器 "方法，允许用户在创建配方后设置例如可选值（例如`event.smelting(..).xp(20).coatingTime(100)`），而且你可以通过完全覆盖配方工厂添加更多属性或进行额外的加载后验证！

#### InputItem和OutputItem
我们现在使用两个完全独立的类来实现这一功能，而不是通过增强香草类来为配方添加原料堆和机会项目的功能： `InputItem`和`OutputItem`。这些类已经完全取代了食谱中几乎所有的 "成分 "和 "物品堆"，并且大部分只是作为食谱模式的简单包装物。(在模式中也有一些食谱感知方法，允许你微调项目的输入/输出应该如何被解析！)

#### 生成配方替换（仍然是WIP，目前你需要知道的是InputMatch => ItemMatch）。

### 事件变化
- 正如上文变化日志的另一部分所提到的，事件现在返回`EventResult`。这类似于Architectury中的同名类，或者vanilla中的`InteractionResult(Holder)`，你可以用它来给用户提供对事件返回值更精细的控制。
- 事件现在使用 "ScriptTypePredicate "注册，这意味着你可以使用一个单一的事件处理程序来处理两边都触发的事件（`group.common'）! 事件现在也只*为其相关的脚本类型触发（尽管你可以使用`ScriptTypePredicate.SERVER.negate()`来让某些东西为启动和客户端触发）。

### Misc. 变化
- KubeJS不应该再挂断Forge上的datagen完成。
- 大多数事件监听器现在只在它们有监听器的情况下被触发。虽然这只是惯例，但你还是应该在你的附加组件中这样做，以提高性能。
- 绑定现在可以通过MOD资源添加，而不需要声明KubeJS插件 (感谢LLytho的这一改变！)

---

# 繁體中文

## KubeJS 6.1 - 腳本和包開發者的變化

嗨，大家好! 由於1.19.2版本的KubeJS 6.1正在形成一個完整的版本，我想在這裡總結一下插件和腳本開發者的主要重要變化，以便讓你在這個版本可以公開使用之前做好準備。開發版本可以在<https://kubejs.com/downloads/dev-builds>和Saps maven上找到，而且我們已經準備了一些東西供某些包的開發團隊測試！

因為這主要是一個大規模的後台和API清理，我將盡量使這個面向用戶的變化日誌簡短而溫馨，並在稍後關注與附加組件相關的變化。作為一個腳本開發者，你可能會注意到最重要的變化如下：
- 新的包裝器`FluidAmounts`用於......液體數量 這允許更好的跨載入器腳本相容性，並為常見的流體值提供了一些很好的捷徑，如塊狀、錠狀和金塊狀!
- 預定的事件現在可以接受其延遲時間（特別是字串，如`200 t`，也可用於tick持續時間）! 
- 兩個 "NetworkEvents "都被合併為一個 "NetworkEvents.dataReceived"，它根據腳本類型處理傳入的數據。
- 註冊表：`event.custom(T)`現在是`event.createCustom(() => T)`，並且接收一個*供應商*，而不是一個對象引用。
- `event.cancel()`現在**立即從事件中退出，並且引入了**自訂事件結果**（`event.cancel()`、`event.exit()`、`event.success()`，以及那些持有結果值的變體
- 告別標籤的變通! 標籤在世界初始載入時已被修復，所以請***停止在腳本中使用/reload***。
- 更好的配方事件性能! (有些人甚至會猶豫說 "比Vanilla好 "*在一些特定的情況下*)
- 自訂敬酒： 你現在可以使用`player.notify`和新的`Notification`綁定來創建自訂香草風格的敬酒通知!
- 數據和資源包的壓縮包現在可以直接從kubejs/data和kubejs/assets文件夾中載入；不再需要解壓和合併它們了!
- 還要注意這兩個Ingredient的變化：
  - `Ingredient.of('2x thing')`現在是`InputItem.of('2x thing')`。如果你使用除此語法之外的任何其他語法*進行成分堆疊，你會沒事的
  - 食材堆和物品輸出不再是*直接*的JSON序列化，因為這種邏輯是針對每個配方類型的；但你仍然可以序列化它們的部分並自己創建JSON。

這就是我所能想到的所有用戶和開發人員面臨的變化! 還有一些其他的東西我沒有在這裡列出，請隨時查看我們的維基，了解更詳細的6.1變化日誌<https://wiki.latvian.dev/books/kubejs/page/kubejs-61-update>，我們將在繼續更新，為這個版本添加一些收尾工作！

現在，讓我們來看看附加組件開發者的更新日誌吧

## KubeJS 6.1 - Addon Developers的變化

### 配方變化

#### Recipe Schemas
這是個大問題。配方模式*完全*改變了自訂配方處理程序在KubeJS中的註冊方式，希望這也意味著你可以減少很多模板代碼。現在，每個配方都是由一個*schema*定義的，其中包含一組*配方組件*，這些組件作為基礎值的 "編解碼器 "發揮作用。對你來說，這意味著以下幾點：
- 現在你不再主要使用RecipeJS子類，而是要定義一個**RecipeSchema**。
  - 每個模式都使用一組**RecipeKeys**，它們被命名為**RecipeComponents**，具有一些額外的屬性，如可選的預設值和自動構造器和方法生成的設置。
  - 一個**RecipeComponent**是一個可重複使用的配方元素的定義（如一個輸入/輸出項目，一個流體，甚至只是一個數字值），它有一個角色（輸入、輸出、其他），一個描述（用於ProbeJS等附加模組），並包含（去）序列化和批次配方操作（即配方過濾和替換）的邏輯。`dev.latvian.mods.kubejs.recipe.component`包中提供了很多標準組件，包括塊、項目和流體、通用組和邏輯組件（數組、地圖、對、任一、可選），以及各種基元（包括數字範圍和字元等專用的基元）。
  - 雖然配方模式*會默怕生成構造函數，但你可以透過使用`constructor(factory, keys)`自己定義一個構造函數來覆蓋這一行為。請注意，這將阻止默認構造函數的生成，所以如果你想保留它，你必須再次自己定義它。
  ("ShapedRecipeSchema "是複雜的自訂配方構建器的一個好例子)
- 雖然模式在java方面取代了**RecipeJS**，但在JS方面，用戶在創建後仍然會被傳遞一個**RecipeJS**對象，每個組件都有額外的自動生成的 "構建器 "方法，允許用戶在創建配方後設置例如可選值（例如`event.smelting(..).xp(20).coatingTime(100)`），而且你可以通過完全覆蓋配方工廠添加更多屬性或進行額外的載入後驗證！

#### InputItem和OutputItem
我們現在使用兩個完全獨立的類來實現這一功能，而不是透過增強香草類來為配方添加原料堆和機會項目的功能： `InputItem`和`OutputItem`。這些類已經完全取代了食譜中幾乎所有的 "成分 "和 "物品堆"，並且大部分只是作為食譜模式的簡單包裝物。(在模式中也有一些食譜感知方法，允許你微調項目的輸入/輸出應該如何被解析！)

#### 生成配方替換（仍然是WIP，目前你需要知道的是InputMatch => ItemMatch）。

### 事件變化
- 正如上文變化日誌的另一部分所提到的，事件現在返回`EventResult`。這類似於Architectury中的同名類，或者vanilla中的`InteractionResult(Holder)`，你可以用它來給用戶提供對事件返回值更精細的控制。
- 事件現在使用 "ScriptTypePredicate "註冊，這意味著你可以使用一個單一的事件處理程序來處理兩邊都觸發的事件（`group.common'）! 事件現在也只*為其相關的腳本類型觸發（儘管你可以使用`ScriptTypePredicate.SERVER.negate()`來讓某些東西為啟動和用戶端觸發）。

### Misc. 變化
- KubeJS不應該再掛斷Forge上的datagen完成。
- 大多數事件監聽器現在只在它們有監聽器的情況下被觸發。雖然這只是慣例，但你還是應該在你的附加組件中這樣做，以提高性能。
- 綁定現在可以通過MOD資源添加，而不需要聲明KubeJS插件 (感謝LLytho的這一改變！)

---

{%hackmd @lumynou5/dark-theme %}