1.5 came out literally 15 months ago. That's an absurdly long playthrough, if you're still at it. I think it may be time to just go ahead and upgrade your version, that's a bit silly holding on to an old version that long (especially with mods that are definitely going to update and possibly break for new versions).

Does anyone know where to find the files for 1.4? I'm down to just this being left for me to fix to keep playing my long-running save file and I can't find this file on the usual alternative sites.

I can't live without the High Bandwidth trait anymore, especially when I play solo mech.

got a little error when running this with inspiration tweaks, any chance for a patch?

I mean I'd pick all of them given the option, the Backpacker/caravan trait was a good addition, can't think of anything else that'd be obvious to add, will have to wait and see the entirety of what Odyssey brings to think if anything could make for a good addition to the already excellent list of traits.

@Rekalty any thoughts on balance? any traits you just dont use or use every single time?

@Rekalty yea i just needed to dedicate the time, it should work for 1.6 now i still have to wait for Odyssey to make specific traits.

Mandatory mod for me for years now, doing things differently than most other traits mods, wondering if you're planning on updating it for 1.6.

@GwenBlanketSpecter i seem to have overlooked carrying capacity and i like the caravan perk idea, will be added soon

have you considered doing one for carry CarryingCapacity , ForagedNutritionPerDay ? sort of a traveling trait

Hello, would you be willing to configure the traits for "Trait Value"?

\/ yea the mod still states compatibility with <1.4

if the mod is no longer working for 1.4 and below shouldn't u remove it from the about.xml?

Thank you for this mod, making traits enhance other traits/effects is a great idea.
Just one small inconsistency I noticed though: quite a few of the traits with two words in the name randomly have the second word capitalized (e.g. Psychic Prodigy, High Bandwidth, Prison Guard, etc), while the rest are normal (e.g. Natural genius, Crack shot, Field medic, etc). As none of the traits in the base game have the second word capitalized, I hope you can fix the capitalization so that they're all uniform. Small issue I know, but it's been bugging me lol.

I have one more suggestion I just came up with. As it is right now, the only pawns that don't suffer a mood penalty when equipped with flesh body parts like the flesh whip and tentacle are inhumanized and transhumanist pawns, so adding a trait that gives a mood buff for these parts would be pretty interesting.

Simply put, you have the option to make traits that synergize with Anomaly that push the boundaries of most simple traits, whether or not they are exclusive to anomalous creepy joiners.

The only new stats I can come up with off the top of my head that Anomaly outright adds relate to void and entity study, but the nature of many of the new traits opens up new possibilities besides just stat boosts.

For example, new creep joiners can come with a whole assortment of unique traits, ranging from Body Mastery which removes all food, sleep and comfort needs to Joybringer which acts as a small yet constant psychic sooth for your colony. Expanding on the anomalous traits these joiners can have would add more interesting quirks to consider when recruiting these folks.

To give you some suggestions to start off with if possible, you could add a Psychic Sight or Third Eye trait that forces the pawn to have a minimum of 100% or above sight, even when missing their eyes all together. A Telepath trait would be cool, similar to VFR Fungoid's gene but allowing them to start social interactions with any pawn.

@a quality meme yes, if there are appropriate stats that can be taken advantage of. I havent played rimworld since the DLC so i will get to it when i end up playing

Do you have any plans for anomaly based traits?

I have 2 ideas on how to fix it (for those who continue with 1.4 for a bit)

firstly, if you use github, you could grab the files from it before you broke them! (and if you don't, you really should use it)

or, if you are willing to deal with steam shennanigins, you can use steams "revert version" to revert this mod to a state before you broke it. You then subscribe to the mod, meaning you have 2 copies of your mod:

1 mod is the local copy (what your making), with the broken 1.4
1 mod is the steam one, without 1.5 (since you reverted it).

Then, just copy the steam mods 1.4 into your mod, and upload this new one! (Not sure if steam stores versions far enbough back to


just some thoughts on if you want to fix it!

i broke the mod for 1.4 and below when updating to 1.5 and i dont have the original files, 1.5 is out tomorrow so it doesnt really matter

Posted log in discussions for red errors when loading. No issues with mod uninstalled, but issues return with mod installed. I am not using "Inspiration Tweaks" like someone else reported earlier.

I know mods are getting updated all over the place, and I don't know enough to figure out what might be causing the issue. Any advice is greatly appreciated. The super soldier program must continue.

Thanks for the prompt update to 1.5.

Here's an idea, what about genes that allow you to geneticly grant these traits?

Just a thought!

Game on. Thanks for the info, bro/bra.

@TheBardOfHearts that's an issue with Inspiration Tweaks' patch for integrating with this mod, not with this mod itself. The author of this mod renamed their trait defs to include an "SN_" prefix, to avoid collisions with other trait mods I presume. The author of Inspiration Tweaks has not adjusted their patch to suit, so their patch is still trying to look for the prior trait IDs. Reporting as an issue on that mod.

It shows this error for each trait in the mod.

(continued)...

Verse.GenThreading/<>c__DisplayClass7_1`1<Verse.DirectXmlCrossRefLoader/WantedRef>:<ParallelForEach>b__0 (object)
System.Threading.QueueUserWorkItemCallback:WaitCallback_Context (object)
System.Threading.ExecutionContext:RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
System.Threading.QueueUserWorkItemCallback:System.Threading.IThreadPoolWorkItem.ExecuteWorkItem ()
System.Threading.ThreadPoolWorkQueue:Dispatch ()
System.Threading._ThreadPoolWaitCallback:PerformWaitCallback ()

Seems that this mod throws alot of red errors on start up.

Could not resolve cross-reference to RimWorld.TraitDef named peasant (wanter=positiveTraitDefs)
UnityEngine.StackTraceUtility:ExtractStackTrace ()
(wrapper dynamic-method) Verse.Log:Verse.Log.Error_Patch3 (string)
Verse.DirectXmlCrossRefLoader:TryResolveDef<RimWorld.TraitDef> (string,Verse.FailMode,object)
Verse.DirectXmlCrossRefLoader/WantedRefForList`1<RimWorld.TraitDef>:TryResolve (Verse.FailMode)
Verse.DirectXmlCrossRefLoader/<>c__DisplayClass16_1:<ResolveAllWantedCrossReferences>b__0 (Verse.DirectXmlCrossRefLoader/WantedRef)

These are some pretty rad looking traits! Glad I stumbled upon this mod.

Is there any chance to see a trait that would allow Non-Tribals to link with Anima Trees, if its even possible? And/or giving a bonus for treating Guaranlen trees, like some kinda Royalty/Ideology crossover 'Dendrophile' trait?

@RealLifeHobgoblin what? why

Are you on discord?

tks :3

@Umbra ok it seems it was changed since it was first release. changed from .65 to 1.50 multiplier

the text below is a entire one, i needed to cut it on half, just read it from up to bottom as a complete text

so, the base supression is 100%, what the game does, is multiply this value for the result.
on social lvl 0 the pawn have a multiplier of x5%, and on lvl 20 a multiplier of x50%

it is on purpose that on lvl 20 the maximun supression is only 50%
i don't know what is the math that the game does for the calculation but i think it will follow the basic math rules, that is: allways multiplication and division before addition and subtraction

so if you want to add 65% to the social max level (50%) you need to change it from a multiplier (x65%) to a addition (+65%)
if your intend is to increase as a multiplier, the you need the number to be x165%

when you are multipling %, to simplify the calculation what you can do is, remove the % and down 2 houses on the number
so 100% = 1,00, 5% = 0,05, 50% = 0,50, 65% = 0,65, 165% = 1,65

continue below \/

the current full calculation is something like: 1,00 x 0,50 = 0,50

with your mod it becomes: 1,00 x 0,65 x 0,50 = 0,325

if you change to +65% the result will depend of how the game do the math it can become either: 1,00 x 0,50 + 0,65 = 1,15 or (1,00 + 0,65) x 0,50 = 0,825 or even 1,00 + 0,65 * 0,50 = 1,325 <-- this last one is a cientifc methode math so probably it is not how the game will do the calculation

and lastly, if you use x165% then the math goes: 1,00 x 1,65 x 0,50 = 0,825

when multipling by 0,65 the calculation always will end on a broken number such 0,825 or 0,325, the game don't round up them and will only show (and i think also only use) the 2 decimals below zero, so 0,825 = 0,82 and 0,325 = 0,32

i expect that this have explained better the problem on your mod :3

@Umbra

I meant to multiply the suppression stat so it is more effective.

I haven't played much since ideology release. However when i was making that trait i looked at a level 20 social pawn. The level 20 had a multiplier that went down as the social skill went up. It was not intuitive and did not follow logic but i followed it anyway. Again, this was at ideology release and may have been bugged in one way or another and may be fixed now.

im not quite sure what you mean with your explanation on the second half of your message. Are you saying a better social skill (now) multiplies 'Suppression Power' by a factor of greater than 1?

What is the suppression power multiplier for a level 1 social pawn vs a level 20 social pawn? does it follow the same pattern as i mentioned, an inverse relation?

the Supression Power of Prison guard trait is a debuff? because, i don't understand your idea, if the idea was buff the stat, then you should use '+' instead of 'x', what your trait is actually doing now is multipling everything by 0.65, not adding 65% for the stat. the base game use a multiplier because the base stat is 100, examples: a social skill lvl 0 is 5% so 0.05 x 100 = 5, a social skill level of 8 is 23% so 0.23 x 100 = 23, my best social pawn have the guard stat and a social skill of 11 that is 30%, but because of the x65% the math goes: 0.65 x 0.30 x 100 = 19.5, if this isn't on purpose, pls fix :3

That are Traits i want to see man! Please more from these!

Tested with savegame and new game.
Both work like a charm.
Thank you.

Like Kaedys mentioned, you might want to add a prefix to all new traits and at some point to the old ones to avoid this from the get go.

@Caladur ok i did what you did, can you confirm your local file is the same as the version i just uploaded

I seem to have fixed it? Not sure which of the following did the trick.
1. Renamed the RoM folder and the file in it both to Patches
2. Put Patches folder into the Ideology folder
3. Changed the patch operation to the one below (lifted from another mod)

Tested with a savegame that had the Priest magic class but your stats (so, RoM loads before SYN).
Now the pawn has still the magic class but the correct stats with it and a seperate Priest trait appears in trait list. Both traits can be used simultaneously without conflict. Horray for Priest Priest or Double Priest! (coming to a theater near you)

<?xml version="1.0" encoding="utf-8" ?>
<Patch>
<Operation Class="PatchOperationSequence">
<operations>
<li Class="PatchOperationReplace">
<xpath>/Defs/TraitDef[@Name="SN_Priest"]/defName</xpath>
<value><defName>SN_Priest</defName></value>
</li>
</operations>
</Operation>
</Patch>

@ewan
Unfortunately it does not. Same behaviour as before, lower load order mod overrides the stats of the trait, while always giving the magic class. And only one instance of the Priest trait exists.

Just played around with the def file and changed defName from Priest to SN_Priest too (like the TraitDef Name) and it woked, now I got seperate Priest traits that only give the boni they are supposed too.

I therefor assume that the patch operation doesn't do what it should.

@Caladur it should be fixed now. Can you confirm? i do not use RoM so i'm not completely sure. My trait now shows up and it didnt before i tried to patch it.

@ewan a big thank you from me in advance

@Kaedys thanks for your input, i will try to get this done probably on monday maybe tomorrow based on your most recent comment.

Thought up another alternative that's way cleaner. So, first off, you can put a `Name="SN_Priest"` attribute in the opening tag (the <TraitDef> tag) for your def, just like you could a ParentName attribute, and you can do that even if the def isn't Abstract="True". I'm about 95% sure that attribute is only used if other defs want to inherit from your def.

So what you could do is add the above attribute, using the "SN_" prefix in it, to your def, and then use that to positively identify only your trait for the patch without trampling RoM's def as well. Essentially:

(In your main def file)
<TraitDef Name="SN_Priest">

(In your patch file)
[FindMod RoM]
<match Class="PatchOperationReplace">
<xpath>/Defs/TraitDef[@Name="SN_Priest"]/defName</xpath>
<value><defName>SN_Priest</defName></value>

Thanks for the info, figured it was because the internal name being the same as i noticed some had the TM_ prefix but this trait didn't. No idea how to make patches at all.
Funnily enough, deactivating the class via the mod menu still gives the magic tab but clicking it breaks the ui. ... am i glad not to be a programmer, bug fixing would drive me crazy.

I posted the problem on AROM too, so I'll wait and see if it gets fixed there.
Not tthat I really mind, It is just strange that my Commisar moral guide is an actual healing priest, but i guess he heals those he tries to break, to try another day. :3

Other alternative is to remove the Priest def entirely from the base code, and then have a find-mod on RoM, and add this mod's Priest def using new name if RoM is loaded, else add it with the old name. It definitely avoids having to fiddle with differentiating the two, and thus is the most guaranteed to work without collateral damage, but it means that def forevermore lives in the patch files (or at least, does until Rimworld 1.4, when you can reliably make backwards-incompatible changes).