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
5 
Report this post
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.