Steam 설치
로그인
|
언어
简体中文(중국어 간체)
繁體中文(중국어 번체)
日本語(일본어)
ไทย(태국어)
Български(불가리아어)
Čeština(체코어)
Dansk(덴마크어)
Deutsch(독일어)
English(영어)
Español - España(스페인어 - 스페인)
Español - Latinoamérica(스페인어 - 중남미)
Ελληνικά(그리스어)
Français(프랑스어)
Italiano(이탈리아어)
Bahasa Indonesia(인도네시아어)
Magyar(헝가리어)
Nederlands(네덜란드어)
Norsk(노르웨이어)
Polski(폴란드어)
Português(포르투갈어 - 포르투갈)
Português - Brasil(포르투갈어 - 브라질)
Română(루마니아어)
Русский(러시아어)
Suomi(핀란드어)
Svenska(스웨덴어)
Türkçe(튀르키예어)
Tiếng Việt(베트남어)
Українська(우크라이나어)
번역 관련 문제 보고









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?