This project is incredibly hard to build

[abrenneke]

Hi @Mhburg! First off, really great work creating the successor to RPG inventory! It seems like all the performance problems I was having have been resolved, and this mod adds a ton more features than RPG inventory had, which is really awesome!

I ran into a bug with this project and wanted to try to fix it, but I've been having an incredibly difficult time building this project. I appreciate your sense of software craftsmanship here - there's lots of automation, like with the building process, you have things siloed into multiple DLLs, and you even have unit tests! However, it all seems extremely tailored to your specific computer's file system setup. I've had to change a bunch of project files manually, and even now, I can't get the project running in RimWorld myself.

The NotooShabby.RimWorldUtility project seems to have some useful utilities in it, but I cannot find that project anywhere! There is only a single DLL reference in this project, but no source code.

My best suggestion is to really embrace the open-source ecosystem, and let people easily build and run this project without any complications. Ideally, one could download this project, hit Build Solution, and you'd have a working mod directory for the game! It would be great if you also switched to a more permissive license like MIT - LGPL is alright, but it does place annoying restrictions to anyone that wants to fork this code. There have been so many modders who eventually stop modding RimWorld that it's important that anyone else can fork and take over the project in the future, just like you've done here with RPG Inventory! Also, please release the NotooShabby.RimWorldUtility project as well so that others may benefit from it!

Cheers,
Andy

[Mhburg]

Thanks for the appreciation. Awesome Inventory began as a personal project as most mods are and grew from there, so most automation is tied to my system, and it is mainly for the convenience of deploying the project. I hope you are using MSVS to build the project as error messages in the output window should help you troubleshoot most problems in the building process.

I will attach a README on how to build this project in the near future, or I might create a new development branch instead of using master. In the mean time, you can safely remove the Directory.Build.targets file, and remove the call to Deploy.bat. My best guess for your problem is the last two targets, starting from here https://github.com/Mhburg/AwsomeInventory/blob/master/src/Common/AwesomeInventory.Base.csproj#L105
If you still fail to build the project after removing all automation, you might want to check other csproj file, and I would suggest using dnSpy to directly modify the dll if you are so keen to.

RimWorldUtility is a library shared among all my mods, and is not published to Github due to my procrastination, but it should be uploaded shortly.

The reason I use LGPL instead of MIT is I dislike the idea of open source project can be converted into a closed one. LGPL doesn't stop others from taking over the project under the restriction that the project has to stay open-source. With that said, LGPL arguably is a better fit for the principle of open source.

Thanks,
Zizhen

[abrenneke]

Hey thanks for the quick reply!

Thanks for the appreciation. Awesome Inventory began as a personal project as most mods are and grew from there, so most automation is tied to my system, and it is mainly for the convenience of deploying the project. I hope you are using MSVS to build the project as error messages in the output window should help you troubleshoot most problems in the building process.

I totally understand how it goes, no worries. Yeah I'm using VS, but you can't really edit the build scripts within VS, and it's been struggling to tell me where the correct file is. I'm an experienced developer but figuring out every project's quirks can take a lot of time 😅

The reason I use LGPL instead of MIT is I dislike the idea of open source project can be converted into a closed one. LGPL doesn't stop others from taking over the project under the restriction that the project has to stay open-source. With that said, LGPL arguably is a better fit for the principle of open source.

Yeah, I do absolutely agree with the principles of copyleft, and there are certainly worse licenses than LGPL 😄. Some of the requirements such as you must "state significant changes made to the software" are a bit annoying in my opinion, won't argue this though, all subjective. I release all my open source stuff using UNLICENSE, so just different approaches! Maybe it's naive but I just expect that other devs will embrace the openness. It's fascinating how RimWorld development is entirely based around decompiling other people's code and changing it, even Ludeon just giving the thumbs-up.

Oh also, I suggest perhaps not strong-naming your assemblies. I think that might be the problem with RimWorldUtility not loading like #47 also mentions (I ran into the same problem). Had to decompile and recompile RimWorldUtility and I think it's working now.

[Mhburg]

The only reason I use strong name for RimworldUtility is because it is shared among all my mods. For any change in its API, I will have to update all my mods if it is not strong-named, which allows multiple version of it loaded into one AppDomain.

[abrenneke]

Oh I see, that makes sense to ensure that. Otherwise you'd have to have a base mod like HugsLib and Harmony do (which wouldn't be the worst thing imo, though having one base utility that all modders could agree on would be the best 😆). However, if it does indeed not work in non-steam RimWorld for some reason, that's not great either.