I just posted one of my favourite old mods to Steam Workshop:

Aside from the transition from map condition to game condition (which means that it persists across the entire planet) I cleaned up the code and made a minor performance improvement.

Previously, when the Solar Apocalypse condition raised the temperature to 85 degrees, it would slowly kill off all the plants on the map. However, because it was trying to kill all the plants at once there would be quite a bit of a performance hit. I’ve alleviated this by making the plant deterioration random. It’ll take longer for the plants to die, but at least your framerate won’t tank.

I will be uploading the new version of the mod here on the site as well along with a couple of mods that I’ve neglected to add.

In other news, I’m considering setting up a Patreon. As always, I will continue to make mods without putting up any kind of paywall, but I anticipate that I won’t be doing well financially over the next few weeks (possibly months), so if that’s a way that I can earn a few extra pounds to keep the lights on, I’m going to look into it.

Contains scalable vector graphics which can be imported into your painting program and used to tag your uploaded thumbnail for a RimWorld mod. Depending on your setup, they may need to be scaled up or down (I work at 2948×1658).

Credits to Marnador for the RimWorld font.

You can use SteamCMD with a customised VDF file to make the process of updating your thumbnails easier.

I’ve begun the process of porting my mods from RimWorld A16 to A17.

First of all, I’m not completely sure that everything will work as it should. I haven’t run into any problems, but that doesn’t mean they don’t exist.

Secondly, I’m probably going to update as and when needed. In other words, if I run into a problem which requires one of my mods, then I’ll probably work on that.

Lastly, I’m expecting that next month (June) may introduce some time suckage. It might not happen, but then again it might, so at least I’ve forewarned you.

Following a recent request, I’ve released the source for Hunting Restriction (including the code for the Trigger Happy update). The project file isn’t included.

Note that this isn’t all of the mod files. You’ll still need to download Hunting Restriction and pull the XML files if you need those too.

Hi guys,

No doubt you’re aware now that RimWorld Alpha 17 is in the works. This post is not about that, but rather what my plans are for modding once it releases.

I released a lot of mods for RimWorld Alpha 16. Part of the reason for that was an increasing familiarity with libraries like HugsLib and with the game’s decompiled source. Also, I had a lot of free time on my hands.

I’m writing today to let you know that the same may not be true for RimWorld Alpha 17.

Okay, but why?

Lots of reasons.

First of all, especially when mods gain a following on Steam Workshop, there is this expectation that the mod will continue on and on from one alpha to the next. When the next version of the game is released, there is a hell of a lot of ‘please update to new version of the game’ interaction. Hardly ever does anyone actually say thank you when I spend hours updating and re-releasing a mod, and I’m not sure it’s warranted because a lot of the time it’s a straight port to the next version, with no new features.

I don’t get a chance to explore new features because my inbox is full of plz update and I’m like fine, fucking have it, hope you choke on it.

No, that’s not actually a thing that happens with enough regularity to make me drop f-bombs. But the constant trickle of notifications is annoying enough that I have in some cases turned them off entirely.

I’ve gone from annoyance-fixing to annoyance-getting. That’s not good.

I can take a break from modding and because I need one, I will.

When other mod authors read this post or notice that I’m not updating my mods, they’re going to fill the void quite soon after RimWorld Alpha 17 releases.

Secondly, Steam Workshop is saturated with mods. I’m not just talking about the big mods that have been there since Alpha 14, I’m also talking about new mods for all sorts of things. Some mods are basically the same as others but with different approaches.

Increasingly, when I release a mod on Steam Workshop, I have an idea based on my own or someone else’s complaint, and turn it into a working mod before another mod author does it.

It’s becoming a tired formula and a recipe for burnout.

Thirdly, RimWorld isn’t the firm favourite game of mine that it has been in the past. I’ve been avoiding it. Maybe it’s a combination of spending a lot of time modding the game, testing to see that the game works with mods, and consequently finding that I still don’t get the sort of stories that I want.

Finally, like I said, I need a break. I need to do new things. Time loops are not as fun from the inside as they appear on the outside.

Incident Not Initialised. It’s a fairly informative error message. It tells me that I’ve broken one of my mods again.

To explain in more detail, I had a lucky break today when I released a broken update for a mod on Steam and here on the site. I might not have noticed the problem until some irate user complained about getting errors. As it turned out, I had a feeling that I’d done something wrong, so I loaded up RimWorld and did a bit of basic testing, finding an error right away.

This isn’t the first time I’ve managed to break a mod that was working fine by adding a new wrinkle and then not doing all the necessary testing. In future, I’ll have to stop and think about whether I’ve really covered all the possible cases.

Because I didn’t. I loaded up an existing save, didn’t see anything immediately wrong, and then I went ahead and updated the mod on Workshop. What I should have done was start a new game and fired the Solar Flare incident at least once. 😛

However, I did come up with a fairly neat solution to the problem.

Basically, my modded incident worker in the original DLL did not inherit the necessary features to work properly, because I goofed and set it to inherit directly from IncidentWorker, instead of IncidentWorker_MakeMapCondition.

What a dumb mistake that was. Maybe I meant to type that in full or copy and paste, but obviously that didn’t happen and now I’m writing this cautionary tale.

I don’t have a code repository and I wasn’t at home so I had to copy my mod from the Workshop directory, decompile my DLL, and make a new project to patch it. The decompile wasn’t clean because I didn’t think to download Zhentar’s awesome fork of ILSpy from his GitHub. So I had to fix a few little things here and there.

Maybe now I will consider the benefits of using a repository.

Anyway, the neat part is that instead of overwriting the entire DLL, I just needed to add a second one and point to that one instead from the incident XML file. The broken class is still there in the original DLL, but it isn’t referenced.

Good enough for a quick fix.

Obviously, this isn’t an impressive feat in the eyes of a professional coder. But that’s not the audience I’m writing for. There’s plenty of modders out there, experimenting with all sorts of interesting stuff that they might not know the ins and outs of.

If one of them is you, the point I’m trying to make is that your projects don’t need to be single monolithic screeds of code. They can be modular. And it might make it easier to fix things when they go wrong.

Obviously for the purposes of efficiency you might want some things to be bundled up in the same library, but it doesn’t always have to be so.

Thanks for reading. 🙂