Cài đặt Steam
Đăng nhập
|
Ngôn ngữ
简体中文 (Hán giản thể)
繁體中文 (Hán phồn thể)
日本語 (Nhật)
한국어 (Hàn Quốc)
ไทย (Thái)
Български (Bungari)
Čeština (CH Séc)
Dansk (Đan Mạch)
Deutsch (Đức)
English (Anh)
Español - España (Tây Ban Nha - TBN)
Español - Latinoamérica (Tây Ban Nha cho Mỹ Latin)
Ελληνικά (Hy Lạp)
Français (Pháp)
Italiano (Ý)
Bahasa Indonesia (tiếng Indonesia)
Magyar (Hungary)
Nederlands (Hà Lan)
Norsk (Na Uy)
Polski (Ba Lan)
Português (Tiếng Bồ Đào Nha - BĐN)
Português - Brasil (Bồ Đào Nha - Brazil)
Română (Rumani)
Русский (Nga)
Suomi (Phần Lan)
Svenska (Thụy Điển)
Türkçe (Thổ Nhĩ Kỳ)
Українська (Ukraine)
Báo cáo lỗi dịch thuật
The CF's sole goal is to provide broad functionality for modders, and does not claim to improve performance or stability.
With that said, invoking any Harmony patch does come with a marginal overhead. Reducing the number of individual Harmony patches on high-volume methods could lead to a minute increase in performance, though I'd expect the effects to be negligible at best.
Reducing the number of Harmony patches can also provide better stability, as there are fewer third-party methods fighting each other over how the program should behave.
Like Output or Recipe Worker that randomizes output so spending consistent resources crafting you randomly get one of multiple defined objects instead of one specific?
Or what about randomization to glower class so object starts off with one of random glow colours instead of predefined?
I was worried that this might be the case, I will start working on a fix for it.