Rimworld mod-friendly?

[Tynan]

First, I need to add some context that NoImageAvailable left out of his frustrated departure message. There's a backstory here that's relevant and that he left out.

NIA asked to be a moderator, was made a moderator, did some inappropriate things, was unmade a moderator, and had some of the things he did undone. He reason he wrote that the way he did (and, I think, part of why he left at all) is because he's bitter about not being able to control the forum the way he wanted, and about being demodded.

E.g. There's a long-standing general info thread on modding. On his first day, he unstickied it and replaced it with his own similar thread, without asking or consulting anyone, thus throwing away months/years of established discussion. Of course now I started getting private complaints about thi from other people, since he pretty much tossed other peoples' resources to the curb to replace with his own. Pissing off long-standing contributors is not a good start to moderatorship. This, combined with him engaging in somewhat catty (but not rule-breaking) arguments as a mod led to him being demodded.

In the end he seemed pretty bitter about being demodded and having things not running the way he wanted them run. He's angry at me personally and I think he wrote his message and left because wanted to vent or do some damage on his way out.

Anyway, I hope that clarifies some of the context of his message. It's not that everything he says is objectively untrue, but he is emotionally motivated to present it negatively.

In the end I realize I never should have let him be a moderator in the first place, but here we are. I'll be more careful next time.

-----

Regarding bugs causing modding problems. Some context on this. We fix hundreds of bugs per alpha. Currently Mantis counts about 2300 fixed bugs, plus 1000+ more fixed from the forums and elsewhere. so roughly 250 bug fixes per alpha. And there are a lot more bugs to fix, because it's a really, really complex game. We could do nothing but bugfixes for quite a few months, but people want their updates. And the game is in alpha, which means it's going to have bugs, by design. Progress would be glacial if we worked more on bugs that we do. We already spend ~50% of our time every alpha doing nothing but bugfixing. We spent all of April fixing bugs and refining code, and are just this month starting on new features for A14. So expect bugs. There aren't any long-standing easy-to-fix bugs that I know of.

Of course, we could spend even more time fixing bugs and generalizing the code (to solve issues like the Beer def being referenced directly in the code). But that's a tradeoff. When we don't fix something, it's because we're working on something else that seems like it has more value to the game as a whole. Of course I could be misprioritizing things, but I try very hard to prioritize well. You just need to understand that modders' concerns may loom huge in your mind, but they go side by side with a lot of other concerns too. People want new builds and features. I need to release to get up-to-date feedback. I have to manage community and write posts like this, and do business, and make trailers, and do taxes, and so on and so on. It's an endless balancing act.

Also, some issues are also much, much harder to fix properly than you might think. The hardcoded Beer reference, for example. Fixing this properly requires us to implement the whole drug system, with abstracted relationships between Things and drug effects and the AI having knowledge about which Thing gives which drug and how much pleasure that will provide, and with it having the ability to evaluate all these pleasure-giving drugs and choose between them intelligently, and so on and so on. The drug system is a big thing I've got a fleshed-out design for, and I don't want to do it halfway. So it's waiting until it can be done properly, then it'll be done properly. I'm hoping that will be soon-ish (maybe A15).

Compare to games like XCOM 2, where the game has a variety of features specifically to facilitate modding, such as the ability for mods to override game classes.

This has me confused given that the RW modding system allows you to replace any def you want, including its attached classes.

while it's fairly trivial to load .dll's, it requires a little bit of trickery to bootstrap. A (set) of predefined entry points for mods would be a huge boon (e.g. pre-loading, post-loading, pre-game start).

I guess I'm a bit confused here as well. You can just define a subclass of MapComponent in your mod dll, and your MapComponent will have entry points you can use to act on first tick (to modify the map), every tick, on GUI, Update, etc.

Alternatively, if you want to do stuff earlier in loading, you can override the MapGenerator to put code hooks wherever you want.

I haven't heard a specific request for entry points elsewhere though. I added entry points to the ThinkTrees so you can inject code into those; if you want one in the MapGenerator it would be a great thing to suggest!

-----

Regarding private variables, enforcing narrow usage patterns on interfaces is generally considered good coding style. The reason this is good is actually because it makes your lives easier when it's time to update. Internal class workings will change a lot between releases, but if you just use the clean public interface as designed, there should be less to update. It means I can change how the inside of, say, the ReservationManager works and your same old CanReserve, IsReserved etc calls will still function as before.

That said, I definitely could've made something private that should've been left public. I'm totally open to feedback on this. But honestly I've only very rarely (2-3 times) seen a specific request along these lines, and I've always responded to them. So make your requests and I'll be able to consider them!

-----

Regarding the variable names changing and code changing, my basic attitude is that it's alpha and the future is bigger and more important that the present. So if I can refactor or rename something to make it better, I do. I'm aware this makes headaches for you guys, but the software just isn't mature enough for me to be locking down names and interfaces and become unable to redesign and rename things. It's alpha software; it's deep in development; I really don't want to begin building up interface cruft and poor names now. Start that, and you're there a year or two later going, "Well, isPsychopathic just means this MentalState is aggressive, it doesn't actually relate to the Psychopath trait or the Psychotic MentalState; the MentalState was the historical only aggressive state before Manhunter was added, and the Psychopath trait was added after isPsychopathic was named...", and so on times a thousand. I've seen it on other projects and it's brutal. In the end everyone pays the price for technical debt, forever. So the current policy is not to accrue technical debt. When the game hits more completed versions it will, of course, be a lot more stable.

-----

Bottom line it: I want RW modding to be as easy as possible, but I also want to maintain a decent release schedule, keep a clean code base with good up-to-date names and interfaces, and have time to add vanilla features in each release. Balancing these concerns requires sacrificing each one to some degree. That, along with the fact that RW is unfinished, is the source of the problems you're having.

RW isn't presented to you as a perfect, finished jewel. So please don't compare RW to perfection; compare it to what you'd expect one man to accomplish in a few years with some part-time help from a second programmer, in a project that's still in alpha.

Bottom bottom line: I'm very open to specific notes on things that'd make your lives easier. For example, as skullywag said, I'd love to get a list of the things you guys agree are most important. I can't promise to change anything in particular, but I can definitely put it in competition with all the other things the game wants done.

[shadwar]

Tynan, at first, I want thanks you for your answer.

For me, it will be enought if mods dlls will be loading before jitting as much original code, as possible.

Right now I'm trying to write mod for year length, and, because of JIT optimizations, I can't override only class getters, but must override all jitted methods, thats use this getters.

Also, it will be good if all consts will be optimized on game startup (or during JIT-compilation, but after mod-dlls loading), not pre-hardcoded on translation to il-bytecode.

[Alistaire]

You can just define a subclass of MapComponent in your mod dll, and your MapComponent will have entry points you can use to act on first tick (to modify the map), every tick, on GUI, Update, etc.

Alternatively, if you want to do stuff earlier in loading, you can override the MapGenerator to put code hooks wherever you want.

I haven't heard a specific request for entry points elsewhere though. I added entry points to the ThinkTrees so you can inject code into those; if you want one in the MapGenerator it would be a great thing to suggest!

Many larger mods have to "resort to" adding their own Unity gameobjects, detouring vanilla classes, using reflection to obtain and change fieldinfo
etcetera due to a class having behaviour defined in an unfortunate way - I for one have attempted to start many mods where I got stuck on either
the pathfinder looking for very specific ThingDefs (Fire) for determining impassable tiles other than those defined in the defs themselves - which is
why CCL is a great resource. Not necessarily because it detours vanilla behaviour (like the entire main menu which allows a ModConfigurationMenu
button to be added) but mainly because it provides some functionality for making it easier to change things about the C# part of the game.
Granted as a developer you can't be expected to provide hooks in every part of the game but the hooks that do exist are quite.. useless.. for larger
mods and hooking into them requires you to understand C# already so it is weird that these C# hooks seem to be implemented for XML modders
to use while such modders can not at all be expected to have a use for them unless they know C# to write the actual code.

The MapGenerator and MapComponent are loaded on colony loading while mods may very well want to hook into the playdataloader (and in fact it
is one of the things CCL adds). I also have commented before that since Plant extends Thing rather than ThingWithComps it is hard to change
anything about them (though it really really really shouldn't be a ThingWithComps since 85% of the savegame consists of plants) which could be
easily fixed by making more parts of the class virtual.

No sweat, just posting a short explanation for some other parts of the "ugh Tynan hates the modding community" stance.

Also multithreading in the A13s Unity version. That broke a bunch of stuff (temporarily).




Aaaaaand since detouring is a great thing for changing methods around that you don't like, some code in the base game assemblies handling exactly that (same idea as the LongEventHandler in terms of accessibility to modders) would be awesome.

[NoImageAvailable]

First, I need to add some context that NoImageAvailable left out of his frustrated departure message. There's a backstory here that's relevant and that he left out.

This never was about the moderator thing, quite the contrary. The reason I wanted to be a moderator at all is because there are many outstanding issues with the mods forum that I wanted to help solve. The info thread was one such example: because many modders were getting sick of constantly having to explain people where to find the output_log.txt I figured I'd make a general thread where all of that info could be collected and then modders could simply link to that instead of explaining the same routine over and over. Stuff like this is something that one would have to actually be a modder or at least to talk to some to even know about. And it is the reason why I said the community management is out of touch.

Before I applied for a moderator position I did this stuff through Ramsis, who was the one who put me up to it in the first place. I never cared about "running the forums my way", I never cared much to moderate the forums at all, all I wanted to do was make some quality of life improvements to the modding forum and fix long-standing issues because nobody else cared enough to bother.

I never attacked you personally in any of my posts. All I did was make two statements, first in the CR thread because I thought people would want an explanation as to why I'm leaving, then I expanded on it in this thread because apparently people wanted to know. Both times I only stated objective facts and legitimate grievances that other modders have echoed in this thread and the CR thread. People are annoyed about certain modding features missing, just as they are annoyed about many of the code changes or how they were annoyed when you unstickied the new mod announcement thread, which quite a few people use. Lashing out at people and trying to discredit their person for speaking out about these things does you no favors, nor does it help improve the community. As such I find your attack on my person absolutely unwarranted and insulting.

[Tynan]

NIA, nobody attacked your person. I just added some context that you left out.

I also never said you attacked me personally; I said I thought you were probably bitter towards me and this likely motivated you posting the way you did. This is essential context info to help third parties interpret what you wrote.

Now you're taking this information as an "attack on your person" and an "insult". I guess I'll just leave it here since there's no further productive discussion to be had.

I'd rather stay on topic (constructive discussions of how to make modding better) from here on if that's okay.

----

There are some mods I'd never recommend trying to do. Like changing the year length. It sounds simple but yeah, the game is not set up for this at all.

But there are so many things that could be added smoothly and easily; I'd really recommend to modders that they try to be flexible and choose projects that will work well in the existing game. Because you're right, it doesn't smoothly support the entire universe of interesting-sounding mods one could make.

Plants couldn't be a ThingWithComps because, as you noted, it'd be way too much bloat. In fact I kind of want to reduce them further until they're not even actual Things, just sort of "dumb cell fillage" like snow. But that's a potential future optimization.

Multithreading during loading was necessary... it's not acceptable in 2016 to have your game lock up (and go gray on Windows) during loading. Sometimes you gotta pull off the band-aid.

[Alistaire]

Plants couldn't be a ThingWithComps because, as you noted, it'd be way too much bloat. In fact I kind of want to reduce them further until they're not even actual Things, just sort of "dumb cell fillage" like snow. But that's a potential future optimization.

Though making their harvesting methods (literally Methods) public virtual will make it possible for a mod to extend Plant to drop additional things
besides their produce, allow for e.g fruit trees which do not reset full plant growth on harvest, change the growth curve of a Plant, add additional
checks to plants under certain circumstances without having to rewrite the JobWorker for harvesting and similar classes which call specifically for
typeof(Plant) of which no child can override that functionality out of the box.

Changes like this would help beginner C# modders a lot since the answer to stuff like that wouldn't be "you could do it with a workaround because
this one method is protected/not virtual/internal". I reported this stuff before in the Cheap suggestions thread however it doesn't seem that thread
is read thoroughly and since these improvements are not strictly bugs I feel hesitant to post them in the Bugs forum too.

[Tynan]

I could make stuff on Plant virtual, that wouldn't be a problem, I don't think.

[1000101]

Regarding some of the "things CCL fixes via detours," especially in relation to things like beer, doors, steam geysers, etc.

Tynan, you are welcome, and always have been, to any and all code in CCLs code base, it's available freely on github and it's mostly the "hot patch" detours which I think you would find useful (although, some of the class extensions you may like too).  If any part of CCL made it's way into the core game, I would be (a) tickled and (b) happy to be able to remove them from CCL.  Obviously some things are beyond the scope of the core game (ie, tying in CCL's Building_AutomatedFactory into the food sub-system), but those that are in the scope I think would be (relatively) minor code ports to the core game (such as the "fixes" for the steam geyser and custom thing classes (doors, etc)).

While most games which support modding have some form of central community resource (Bethesda games have their "script extenders" - SKSE, FO4SE, etc), it would be nice to shrink CCL back into the "extend" and less in the "hot patch" category.  At this point it's about equally both.

Anyway, my two cents about the modding issue.

[Tynan]

Thanks, I'll have to take a closer look at CCL.

[Fluffy (l2032)]

 It's late right now, and I need to get to bed soon, but just wanted to drop my two cents.

First off, Tynan, thanks a bunch for the reply! It's great to know complaints are being heard. There's a weird disconnect between what I think many modders are feeling, and what you're actually saying. I'm now thinking 'we' may have just been lazy and haven't reached out enough. That said, maybe there should be a sub-forum for this kind of thing, moderated by modders, where modding complaints/features/bugs/enhancements can be discussed, since the suggestions forum often gets swamped, and the bug forum is specifically not for modded games.

Second, please do have a look at CCL! There's a couple of things there that should be vanilla if you ask me. The mod configuration menus, reloading after mod changes, some removal of hard-coded references, injection points for code. MapComponents are fine, but they're quite crude. Also, I have never looked into using MapGen as an entry point, I'll certainly give that a look over.