With the indefinite suspension of development on the popular mod "Combat Realism" and it's creator bringing up problems regarding Rimworld and mod-support, quote (NoImageAvailable):
Just uploaded the 1.6.5 release. It mainly updates melee weapons to A13 by adding bulk, weight and armor penetration stats to melee weapons. With this the mod is fully updated to A13 and out of pre-release. It is also the last update I will do as I am leaving Rimworld modding permanently.
With the complete lack of not only any real support for modding but even base consideration for it (almost every alpha brings with it new internal changes like making various public variables private, which does not affect the base game in any way but breaks mods and makes modding harder than it needs to be) and a number of smaller annoyances like the out of touch community management (Tynan unstickying genuinely useful threads such as well-maintained mod lists while leaving redundant ones up, complete lack of communication on issues such as the whole private variabls thing, that sort of stuff) modding Rimworld has become more of a hassle than it ought to be. At this point I just no longer have the motivation to deal with it all. The only thing keeping me was the fact I wanted to bring CR into a semi-complete state before I go. I did have plans for a melee combat overhaul before I go but since the loadout system took up more time than originally anticipated I have decided to can those plans.
Since people asked for it in the past I have uploaded the ODS sheets with all the weapon stats I used for balancing to github so anyone interested in making gun mods compatible with this can look up how the stats are calculated (keep in mind though, that while the sheets include data for Project Armory guns that data hasn't been updated since the last PA release and is heavily outdated). The zip file also includes my personal todo list where I still have a number of outstanding issues and plans for the future, in case anyone else decides to pick up this project (although somehow I don't see that happening).
I was wondering how other modders are experiencing modding Rimworld, is it really that bad and is there something Tynan can do about it?
From the very beginning, one of the earliest alpha's, mods have been a cornerstone of Rimworld's succes with countless features and playing hours added on top of the base game and this actually worries me cause without mods Rimworld is quite dull if you played it enough. Think about it, alpha 14 won't support "Combat Realism" and as a result the "Modvariety pack", this may just be the beginning of modders leaving the scene due to frustration and other factors.
So I'd like to start a little discussion and maybe hope modders can address problems for Tynan.
inb4 deleted.
from my experience in trying to update cybernetic storm for my own use...
yah, alot of changes seems.... well busy work (suffice to say I gave up after 2 alphas)
I remember having to go find copy and pasting terms that have no change in the structure of the code but just spelling changes (but imagine doing that several dozen times)
and that is just on the xml level.
I don't understand why they change things that way either.
seems more time efficient to do that when you are at the RC stage.
(the tidying up)
but is how Tynan rolls.
Quote
I don't understand why they change things that way either.
seems more time efficient to do that when you are at the RC stage.
refactoring after release? are you mad bro?
everything should be broken on alpha stage to avoid issues after release.
Just to clarify on this, its not about the code changing (game is in alpha, changes are to be expected) but about stuff like the mod menu bug. When 90% of my troubleshooting time is spent clarifying whether a bug is legit or the result of a vanilla bug that has been common knowledge for what, a year now, and still hasn't been fixed despite it being really easy to do so. Stuff like that just sucks all the fun out of modding for me and I find the fact Tynan won't even take an hour to fix the mod menu telling of the overall state of modding support (or lack thereof) in Rimworld.
The current situation can best be described as Rimworld enables modding, but does not support it. There is a (broken and poorly designed) mod menu and that's it. 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. It also comes with a dev tool and most of the source code, comments and all. Rimworld modding on the other hand is pretty much 100% modders bootstrapping and creating that same functionality through things like CCL.
This isn't anything extraordinary since any game without native modding support requires the community to create base functionality. But then it also doesn't do much to keep people in the community and when you factor in the other hassles associated with modding an alpha game you can probably see why it would drive people to move onto greener pastures.
I've only ever created mods for RimWorld, so I have little reference material.
I can say however, that some of the decisions in access levels seem completely arbitrary. For example, in the new social tab, the functions for getting the relations overview are public, but the functions for getting the 'chat log' are private. With the tools available to us (e.g. reflection, detours), most of this can fairly easily be circumvented - but it is a hassle.
Furthermore, there's just some dubious decisions. The threaded loading phase for example. The main, and _only_ benefit of this is that the screen can show a loading message while it loads the game and mods in the background. But, the underlying engine (Unity4), isn't actually multithreaded. Which means that if a mod interacts with unity or loads any assets (e.g. textures) in the loading phase (and thus from a background thread), it produces unreliable behaviour (or on UNIX systems, just plain out crashes the game).
Part of the problem here is that there's very little emphasis on mods and modding in the tester builds - afaik it's only skullywag that is a private tester, and there's only a handful of public tester modders. Moreover, any modding related issues that are found, are often put on low priority - after all, we're only supposed to report vanilla bugs.
Do you guys think that modding could still be vastly improved by Tynan? Is it something that could wait until main release and then Tynan could put more effort in supporting mods? Basically I'm asking anyone who understands modding and knows the issues. We have seen some examples of the problems. What are the obvious solutions?
Rimworld Vanilla is a great game. But I do hope the modding community is just as strong or even stronger once the game is finally fully released. and like many games I imagine full release does not immediately mean all development is stopped. But I feel sometime after full release there will eventually be less things to resolve and maybe more focus on modding?
@Fluffy (l2032)
protection levels - bah!
We still dont have entry point for mod added dlls, static constructor attribute added in a13 is not entry point due to exceptionaly late invocation.
I agree with the points made about the public/private variables, but would also bring up another issue which still affects me and other modders - the hard-coded need for Beer™. Ever since I started development on my first mod "Can I Brew It?", the mod has been permanently broken because of hard-coded references to the Beer object (meaning that pawns will stroll past rows and piles of vodka, tequila, wine, etc., just to pick up Beer™). I brought this up with Tynan, and he said he was aware of the issue. This was a year ago.
This all falls into a discussion I had in private with Tynan not long after A13s release. I outlined the issue of the modders knowing of a fair few places in the code which could be improved to make modding easier and genuinely more enjoyable experience all round. Id thought long about how best to get this information to Ludeon without it being a burden on them, the best I could come up with was a subforum (maybe locked down to certain users who could moderate it???) where we could collate all these things and allow Ludeon to pick and choose what to fix as they see fit. I was told by Tynan that a subforum seemed overkill for this one thing and that I should combine these into one big digest so he could just look at all of them. I havent gotten around to doing this as its just unfeasible to consolidate all of this by myself. So if anyone has any other ideas on how to achieve this im all ears.
Quote from: skullywag on May 10, 2016, 10:07:59 AM
So if anyone has any other ideas on how to achieve this im all ears.
Create a private subreddit?
Slack maybe? With just tynan and some of the more major modders? That is pf course slack works the way i think it does.
I'm pretty sure slack has an option for private channels with only certain members, but I don't know if it's free, it's likely hidden behind the paywall. Discord is similar to slack, and has that option for free, although the voice chat would likely not be used which is what it focuses on, so not much point using it just for exclusive channel.
as a second PA dev I can attest to NoImageAvailable's distaste with the system. It is an alpha game, and features are released on regular basis without any solid effort to support, or make modding more comfortable at this point. I'm not a proficient enough modder, mainly doing math and artwork for PA(and filling out xmls), but i can say this much: the bigger the mod becomes in Rimworld, the more difficult it is to update with each update of Rimworld, PA got so buggy and out of control, as well as other issues we really needed to improve, that we decided to make a complete re-write of the whole mod. After a year of a break from active development. Yes I did contribute some content last winter and genuinely thought i'd be able to get the mod running for A12, but no luck so I gave up for University was pressing against my neck. Yes, modders will suffer eternity of unnecessary bugs and constant fixing untill game gets into beta stage where main structure won't be affected as strongly as it is now. This is the harsh reality and I really think when you are tired of updating the mod, you have to take a break, be it a year, two, or forever. There's always something to do if you want. Developing new mods for new games, or new games themselves... I can totally relate to NoImageAvailable. You can't do one thing all the time. And, like I said, the bigger the mod, the more effort it takes to keep it up to date.
Sorry for the tautology.
ahh yes, the hardcoded references to beer, doors, nutrient dispensers, and a bunch of other stuff are another major hurdle. CCL fixes many of these by detouring the methods at fault and replacing hardcoded references - but it _shouldn't have to_!
And yeah, 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).
Okay time to put in my two cents. I feel like modding support should be a low priority for Tynan at this point in development because he is busy focusing on adding in new content for the base game. If he had spent the time available to him on adding in more modding support we might not have gotten the huge relationships update. Sure he could probably easily fix the problem with opening the mod screen requiring a full restart of the game, but that would have meant less features in the alpha 13 update. Of course it's frustrating to us modders but this is not a fully fleshed out game yet. Bug smashing is not for the alpha phase unless the bug breaks the game completely. Beta phase is where all of the bug fixes take place in ANY game (including XCOM which someone mentioned earlier in this thread). No game has as much modding support during the alpha phase as Tynan has provided us with. The thing that drew me to this game was how easy it was to mod at such an early point in development. We as modders have to be patient and deal with the issues until Tynan has finished adding in all the cool features he envisioned for the game and all the feature suggestions. Once the game is to the point where Tynan calls it feature complete I trust that he will invest some time into making this game even more mod-friendly than it already is. Quit giving him a hard time about mod support unless it is a huge issue. Let him focus on the important things to make the base game fun to play and replay and replay again. The more people hassle him about modding support the more he is going to get frustrated and he may decide that it's not worth working on more features for the base game and he may end development earlier than he normally would have. And that would be bad for everybody in my opinion. We need to show him support and try to make his job easier so he is more willing to keep doing it. This doesn't mean we should just roll over and pretend nothing is wrong with modding support, but we should be less aggressive about it. Give him reports on issues that come up but if he doesn't get to the issues immediately then just understand that means he is busy making the actual game better. Quit treating him as though this is a full-release game with all these issues. This is ALPHA and we need to keep that in mind.
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 (https://ludeon.com/forums/index.php?topic=7037.0). On his first day, he unstickied it and replaced it with his own similar thread (https://ludeon.com/forums/index.php?topic=18272.0), 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).
QuoteCompare 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.
Quote from: Fluffy (l2032) on May 11, 2016, 05:59:12 AM
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.
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.
Quote from: Tynan on May 11, 2016, 01:48:51 PM
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.
Quote from: Tynan on May 11, 2016, 01:48:51 PM
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.
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.
Quote from: Tynan on May 11, 2016, 03:09:17 PM
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.
I could make stuff on Plant virtual, that wouldn't be a problem, I don't think.
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.
Thanks, I'll have to take a closer look at CCL.
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.