Messages

Harmony patches itself (using Harmony) to achieve backwards compatibility. There's nothing stopping you from using Harmony to patch the old UniversalFermenter to use your code.

Best practices? Probably not. Likelihood you'll step on someone's toes? Pretty slim.

Of course, you can also just change your namespace. Won't solve the old problem, but does ensure new mods use your new fermenter.

it goes to class incidentWorker_WandererJoined and IlSpy doesn't show where that class is instantiated.

No surprise there; RimWorld almost never directly instantiates classes, certainly not classes referenced in XML. If the XML does contain a class, point your decompiler to that Def's field. For instance, type in def.Worker in your favourite decompiler and see what all pops up. This rather abstract design pattern is repeated for multiple things, in different ways.

As for "the first raid", that's a bit tricky. Cassandra and Phoebe both use "StorytellerCompProperties_ClassicIntro" so they have fixed behaviour for the first few days. Randy however does what he wants. I would suggest you introduce your own "StorytellerComp" into (all) existing storytellers which does what you want.

https://github.com/RimWorld-CCL-Reborn/AlienRaces/wiki

Grab yourself a decompiler and take a look. ILSpy is good. DnSpy also works.

From a glance, it stores em by def.shortHash, does some bitshifting so its a byte array and then stores it as a base64 string.

Been looking forward to this one. Congrats to you and Dubwise on the release.

Code Select Expand


public void GainTrait(Trait trait)
{
if (HasTrait(trait.def))
{
Log.Warning(pawn + " already has trait " + trait.def);
return;
}
allTraits.Add(trait);
//other code of the original method omitted
}
//So if I can get this to something like:
            [HarmonyPatch(typeof(TraitSet), "GainTrait")]
            private static class Patch_GainTrait
            {
                private static bool TraitTech(TraitDef __instance, FactionDef other, ref bool __result)
                {
                    if (__instance is TraitDef_ReligionTrait)
                          {

From there I compare __instance.techLevel and other.techLevel and check for overlap, else return.

Is that essentially the idea?

In the right direction, yeah. The approach/design could work, but the C# you posted won't.

Code Select Expand

private static bool TraitTech(TraitDef __instance, FactionDef other, ref bool __result)
There are four errors in this line:
- Since you're using annotation patching, you need to specify whether or not this is a postfix or a prefix. You can do that with the methodname or with more annotations.
- The __instance will never be of type TraitDef. The instance is TraitSet, as that is the class you are patching.
- Since the original method doesn't receive a FactionDef as argument, neither can your patch.
- The original method returns void. A void returns nothing. That means it does not return a __result. There is no __result to return.

You'll also need a way to get the Pawn from the TraitSet, but that's a protected variable. Harmony 1.2+ offers an easy way of getting non-public variables: prefix the variable name with three underscores and accept them as argument. So

Code Select Expand

ProperlyNamedMethod(TraitSet __instance, Pawn ___pawn, Trait trait) { ... }

Code Select Expand

__instance is TraitDef_ReligionTrait -- are you going to subclass TraitDef just for the sake of adding a techLevel field? In that case, I strongly suggest using a DefModExtension instead. They are a hundred times easier; more compatible, less code, less maintenance.

On a more global level: Is your current intent a destructive prefix (i.e. don't run the original method) if the trait is of a too high tech level? While that certainly works, it has two downsides/side-effects you might not be aware of:
- It prevents other prefixes and the original method from running. This is generally considered a bad thing, for the sake of compatibility. Sometimes that's acceptable, other times not.
- It will sneakily reduce the commonality of your trait. If a tribal gets assigned a high-tech trait and you say "no, don't add this", it's very likely they will end up with a different trait that's not one of yours. That's okay.

You can't add fields or variables to existing classes; C# simply forbids this. Since the backstories aren't exposed to XML either, you can forget about any XML-based approaches too.

That still leaves multiple approaches to your issue. You mention "forcedTraits" and that is certainly possible. Every BackStory in the BackStoryDatabase has a public List<TraitEntry> forcedTraits; entry. You can add yours to that. Do keep in mind those are *forced* entries. The game doesn't have a choice in adding traits from that list; it will add all of them.

Another option is a Harmony Patch on the method(s) that add a trait to the Pawn. There are two or three of those:
- RimWorld.TraitSet.GainTrait
- Verse.PawnGenerator.GenerateTraits
- RimWorld.ScenPart_ForcedTrait.ModifyPawnPostGenerate

at a quick glance, a patch on the first should suffice.

The final option that I see is inspired by the Forced_Trait Scenario Part. Add your own Scenario Part that inherits from RimWorld.ScenPart_PawnModifier.ModifyPawnPostGenerate, and add the appropriate traits there.

Note; while you can't add a list to the TraitDefs, there's nothing stopping you from having your list/dictionary/custom data structure keeping track of what Traits are appropriate and what aren't. If you think a field like that would solve all your problems, I would recommend a design pattern that RimWorld supports very well: Adding a ModExtension to the relevant Defs. See the RimWorld wiki for more info on that.

If you post your XML, we can play "spot the difference" rather than "guess the difference".

I did in my OP as a pastebin link because I wasn't sure if posting it on the forums would work out well:

Code:
https://pastebin.com/hqk6CTb7

I also did a text compare:
https://i.imgur.com/TTRyYVV.png

Apologies, I totally missed that!

Your XML looks correct to me, though I'm obviously not the most observant today.

But all I really did was change the textures and some xml values and somehow I broke it.

If you post your XML, we can play "spot the difference" rather than "guess the difference".

spawnCategories and their associated counterpart backstoryCategories.

Alternatively, faction tech level.

The exception is because you are missing a thingClass entry in your def.

I spent more time fighting the very peculiar environment the cookiecutter sets up than it will ever save me. In the end I found it quicker to set up a solution manually. If you set it up right once, you can even export your project as template and subsequent mods will be ready to go in a few clicks.

The wiki has very detailed instructions on how to set up a solution, and it works well. https://rimworldwiki.com/wiki/Modding_Tutorials/Setting_up_a_solution

There's this mod called Core which has food policies.

It's kinda bloated, some parts are OP, but honestly I can't play RimWorld without it.

Download link here.

They are.

https://steamcommunity.com/profiles/76561198325939800/myworkshopfiles/?appid=294100&numperpage=30

Bodyparts come down to HediffWithComps, and you can do all sorts of things with Comps. The bionic arm adds a new tool to the pawn. From a quick glance at my decompiler, there's support for verbs as well.

Since RimWorld itself doesn't utilise native ranged verbs, you'll likely need some C# of your own to flesh out the rudimentary systems already in place.