djungelorm
New Member
- Messages
- 3
- Reaction score
- 8
Hi, I'm the developer of the kRPC mod. It has been around on KSP for years, and I'm now bringing it to KSA. While setting up the build system, I hit a problem that probably affects every code mod, so I wanted to raise it here. There didn't seem to be a subforum for this kind of thing in the modding section, so apologies if this isn't the right place.
The problem
Code mods compile against the game's DLLs. That means a mod can only be built on a machine with the game installed. For automated builds, such as GitHub Actions, there's nothing to compile against. Mod authors either skip automated builds, or have to run the build by hand to check if the mod compiles and to cut a release.
For KSP, my GitHub CI builds against "stub" assemblies. They have the same public types and signatures as the game's DLLs, with every method body replaced by `throw new NotImplementedException()`. They contain no game code and can't run the game - they are just the bare minimum needed for the code mod to compile. This is a useful way to catch some game incompatibility issues quickly, and could be used for automated release builds.
Why this matters for KSA
KSA updates often, which is great, but each update can change APIs that code mods use. With automated builds, a mod author can rebuild against a new version as soon as it ships and see straight away what broke. Mods get fixed faster after updates, and fewer players hit broken mods.
Suggestion
Publish reference assemblies (public API only, no implementation) for each game version, for example as a NuGet package. This is the standard .NET way to ship an API without its implementation, and any code mod could then build anywhere.
Other games mod communities do this with packages: examples include Krafs.Rimworld.Ref and Bannerlord.ReferenceAssemblies on NuGet.
In the meantime
Would it be OK for mod authors to generate stub assemblies themselves from the game's DLLs and publish them, so CI can download them? Or is this a licensing issue?
Thanks!
The problem
Code mods compile against the game's DLLs. That means a mod can only be built on a machine with the game installed. For automated builds, such as GitHub Actions, there's nothing to compile against. Mod authors either skip automated builds, or have to run the build by hand to check if the mod compiles and to cut a release.
For KSP, my GitHub CI builds against "stub" assemblies. They have the same public types and signatures as the game's DLLs, with every method body replaced by `throw new NotImplementedException()`. They contain no game code and can't run the game - they are just the bare minimum needed for the code mod to compile. This is a useful way to catch some game incompatibility issues quickly, and could be used for automated release builds.
Why this matters for KSA
KSA updates often, which is great, but each update can change APIs that code mods use. With automated builds, a mod author can rebuild against a new version as soon as it ships and see straight away what broke. Mods get fixed faster after updates, and fewer players hit broken mods.
Suggestion
Publish reference assemblies (public API only, no implementation) for each game version, for example as a NuGet package. This is the standard .NET way to ship an API without its implementation, and any code mod could then build anywhere.
Other games mod communities do this with packages: examples include Krafs.Rimworld.Ref and Bannerlord.ReferenceAssemblies on NuGet.
In the meantime
Would it be OK for mod authors to generate stub assemblies themselves from the game's DLLs and publish them, so CI can download them? Or is this a licensing issue?
Thanks!
Upvote
1
