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
I wasn't sure if I should post the error or not since you're already working on an update, but figured I'd point it out anyway since it wasn't mentioned yet.
Error while instantiating a mod of type CF.CFMod: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: The type initializer for 'CF.HarmonyLoader' threw an exception. ---> HarmonyLib.HarmonyException: Patching exception in method null ---> System.ArgumentException: Undefined target method for patch method static System.Void CF.GenerateQualityCreatedByPawn::Postfix(RimWorld.QualityCategory& __result, Verse.Pawn pawn)
[Ref 9F468612]
at HarmonyLib.PatchClassProcessor.PatchWithAttributes (System.Reflection.MethodBase& lastOriginal, System.Boolean unpatch) [0x00047] in <8124cc12bdf242eab0a5f7e7edecf387>:0
at HarmonyLib.PatchClassProcessor.Patch () [0x0006e] in <8124cc12bdf242eab0a5f7e7edecf387>:0
--- End of inner exception stack trace ---
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?