Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
A functional 1.6 build has been made, but I want to migrate to the new TickInterval system introduced in 1.6 before releasing it.
You can download the development branch from GitHub if you want to want to update your own mod before the official release is ready.
Thanks for the great work, my own mod wouldn't be possible without it.
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.