安装 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（越南语）
Українська（乌克兰语）
报告翻译问题
0 
举报此帖
https://chatgpt.com/share/68b4dc2c-51e0-8004-a355-d2b706455e74
what mods conflict
ChatGPT Plus
Pensó durante 5s
Short answer: the mods shown in your stack trace are the ones most likely involved — SmartMedicine, PriorityTreatment (TKS_PriorityTreatment / PriorityTreatmentRessurected), AutoArm (Snues.AutoArm), and Yayo's Combat (Mlie.YayosCombat3). SmartMedicine looks like the immediate offender (it calls TryDrop / SplitOff), and the other three are very likely interacting with job/tick timing in ways that expose the bug.
Evidence from your trace
SmartMedicine.TendPatient_Notify_Starting_Patch.DropIt — immediate caller that ends up invoking SplitOff(0). (Mod id: uuugggg.rimworld.SmartMedicine.main)
TKS_PriorityTreatment.Pawn_Patches.TickRare_Prefix — patches Pawn.Tick and appears earlier in the call chain (PriorityTreatmentRessurected).
AutoArm.Pawn_JobTracker_StartJob_Combined_Patch — patches Pawn_JobTracker.StartJob (prefix and postfix) and can change job/reserve behavior.
yayoCombat.HarmonyPatches.Pawn_Tick:Postfix — Yayo's combat patches Pawn.Tick timing.
Core game methods (Verse / RimWorld) are where the SplitOff exception originates, but they're not the mod conflict source.
Why these likely conflict
SmartMedicine does the actual drop/split of medicine. If it ever computes needCount as 0 and calls TryDrop/SplitOff, you get the exception.
PriorityTreatment modifies how and when pawns get tended / job priorities; it can cause extra/duplicate tend jobs or change the timing of when a medicine is reserved or consumed.
AutoArm patches job-start logic; it can affect job reservations/ordering and thus lead to two pieces of code trying to take the same medicine in close succession.
Yayo’s Combat modifies Pawn.Tick timing which can slightly shift the ordering and expose race conditions between the above patches.
So the typical pattern: SmartMedicine tries to drop X medicine, another mod or previous action already removed the stack (or needCount computed incorrectly), resulting in a count == 0 call.
"Capture all downed enemies"
What’s happening (plain)
RimWorld detects when a pawn starts an excessive number of jobs in a single tick and logs the orange error. It’s a defensive message indicating something is looping or repeatedly forcing job starts.
Your stack shows TKS_PriorityTreatment.Pawn_JobTracker_Patches:TryFindAndStartJob_prefix repeatedly being invoked — so PriorityTreatment is actively participating in the job-finding/starting flow and is the most likely immediate cause (either itself is doing something wrong or exposing another mod’s race condition).
Other mods that showed up in your earlier trace (SmartMedicine, AutoArm, Yayo’s Combat) patch job/tick behavior too. Combined, they can create timing/race conditions where multiple patches trigger job starts or duplicate job attempts for the same pawn in one tick.
Most likely conflicting mods (based on your traces)
PriorityTreatment (TKS_PriorityTreatment / PriorityTreatmentRessurected) — repeatedly in the call stack, so very suspicious.
SmartMedicine — previously caused SplitOff(0) in your trace (interacts with tending/medicine).
AutoArm (Snues.AutoArm) — patches job start logic.
Yayo’s Combat (Mlie.YayosCombat3) — patches Pawn.Tick timing which can change ordering/timing.
Core methods in Verse and RimWorld are where errors surface but they’re not the root cause.