Messages

[SomeType ___fieldname]

You could try the latest master from GitHub as it contains a preview version 1.1.1 that contains a feature called private field injection. With SomeType ___fieldname or ref SomeType ___fieldname you can access them directly.

If you rather want to stay on your current version, your best bet is to use Traverse.Create(__instance).Field("foo").GetValue<SomeType>() (your example has only one underscore, hope this isn't a typo).

While testing all my mod updates for rw1.0, I tried this to speed up test-launching. It doesn't work. RimWorld stays at Initializing forever when it gets combined with any of my new versions. :-/

Can we try to get Harmony 1.1.1 into HugsLib when I release it on Monday next week?

Harmony 1.0 and 1.1 can coexist. Tested with Achtung and Zombieland which are used with many other mods that of course use Harmony 1.0

Harmony 1.1 does upgrade any older version internally by patching the essential internal core methods.

[New Version!]

New Version!

Now that Rimworld 1.0 is announced and most of you are going to update you mods, it is time to move on to the next version of Harmony.

Harmony v1.1 has many improvements that you are going to love and use. It can inject private fields. It can patch methods with try/catch logic. It has less bugs.

When it comes to compatibility, there is a slight catch. Transpilers have a slightly different api (CodeInstruction now has a new field "blocks" to hold try/catch logic) so Harmony contains some self-patching logic to make it coexist with older versions. This can lead to minor incompatibility issues if other mods use the old version and transpile methods that contain try/catch logic and do it by duplicating or removing code instructions. Harmony will try to fix those transpilers automatically but may fail so. It's an edge case and one that I only saw twice (one auto fixed) in my test period with two of my more popular mods. The solution is always to ask the other author to upgrade to Harmony 1.1 or to fix their transpiler logic.

Now is the time to upgrade. HugsLib and other mods do it too and it requires only trivial changes in some of the renamed api.

Grab the latest release from GitHub:
https://github.com/pardeike/Harmony/releases

Aside for zombie lovers. I had the hair glitch before. Now i use alien framework pregnancy (cause i have aliens too) and the glitch is gone i think

The glitch is gone because I added a fix for a bug in Zombieland that triggered the glitch. Zombies will now never be teens or younger but there is one finally bug that I have not addressed: if a human turns into a zombie and that human is not an adult, the glitch will be there for this particular zombie.

I get the following error when I try to sync my github repo from the modsync homepage:



Also: the overall flow on the site is a bit "weird"...
/Andreas

Hi again,
check out the code of one of my mods as an example. It's not exactly what you need but if you explore the classes and utility functions used you will find a solution:

https://github.com/pardeike/SameSpot/blob/ca294dbe78b6959f730661e451e36b7e48e7af3d/Source/Main.cs#L65

I'm busy right now and on mobile. Pretty sure he thinks about getting the MethodInfo of that somehow hidden and private method. Can someone explain how to use Harmony's AccessTools to get what he needs?

You need to extend the official "Mod" class. It is the preferred way to start a mod and runs much earlier.

Thank you for your feedback. Very kind. It is my pleasure to contribute to a otherwise hard to solve problem.

ENJOY

In my tests, as long as both dlls have different versions, they are loaded separately you rimworld (or any other host assembly)

Sorry, I thought you were talking about the Harmony dll. Btw, dlls are not loaded again only if the dll version is the same. This is because of the system dll cache and is hard to work around - even from RimWorld.

Overall, that would not solve the problem completely. In order to allow multiple patches to coexist on a method, Harmony has to maintain global state. I currently do it with a singleton in-memory assembly that has a static field. Works great until you have to introduce breaking changes.

While the global state is carefully designed to not contain domain specific objects (only things like String, MethodInfo and a few simple wrapper objects) the overall patch process requires that every time someone patches a method, any existing patches have to be replayed to generate the final (and new) replacement method. Like this:

Mod 1:
Original -> patch1 -> Replacement

Mod 2:
Original -> patch1 -> patch2 -> New replacement

Here, patch1 is just a method call inside the dynamically build replacement method.

This works just fine with prefixes and postfixes but transpilers are a problem. They are also chained so if two mods use transpilers, you get this:

Original -> List of CodeInstructions -> Transpiler1 -> Transpiler2 -> Replacement

Here, CodeInstruction can actually come from two different versions of Harmony and thus cannot be assigned:

// Mod1:
CodeInstruction ci1;
// Mod2:
CodeInstruction ci2 = ci1; <-- will throw a cast exception

The current solution to this is to serialize/deserialize the instructions and that just works fine too.

Now, in order to support try-catch blocks, I have to modify the Harmony type CodeInstruction so it carries, preserves and supports the information that is required. This will break the serialization or it will remove the unserializable information effectively erasing it.

One possible solution would be to patch existing Harmony methods to use the new type everywhere. That should work in theory since the extra fields do not need to be understood by the old library to successfully carry over the information during the piping. Old user code adding instructions could instantiate the new class and defaults would prevent errors. No idea if this is doable and maybe someone else could help me discuss this idea.

There is no easy way to solve this. I am working on an update to Harmony and so far, don't have any solution to the problem you describe.