Modding in General

I think programming skills are not needed in case of CDE. At first when I read about in-engine mod support, I thought about external DLL plugins and an available API for modders to work with. It doesn't seem to be the case; the game is just a single exe and as far as I can tell there is no mechanism to load external DLLs. You can basically mod anything in the Resources folder (except maybe shaders) by placing your own version of the files into the Mods in Application Data.

Therefore you probably can't mod in new homing algorithms. You can add/replace celestial bodies, including adding your own models and textures, but I doubt you can add a new model for a black box module. It seems even models for existing modules are procedurally generated.

I need to take a closer look at this, myself. From what I can tell in the stacktraces, I'm 95% confident that the game is written in Visual C++. Most of the modding community around similar games is in C#, which has more similarities to Java than C++ in my experience. For example, garbage collection is sort of an add-on in Visual C++, not a core part of the language, so I'll warn everyone right now that "weird edge-case memory leaks" is probably going to cause people blood pressure problems. :3

That said, KSP originally didn't allow external DLL loading: modding support was originally created by a player, who essentially compromised the game code to allow them to inject DLLs. They hired him and made it an official feature. IIRC.

I haven't unlocked black box modules yet (not sure what unlocks the ability to create them), so do you just select a model in the game or do you reference it somehow in the designs file? I got the impression that celestial body model is selected based on their names, i.e. you have to have models with the same name as your celestial body.



You don't need stack traces. It says so right at the beginning of the CDE.pdb file: Microsoft C/C++ MSF 7.00

I don't think that the language is relevant, or at least it's much less of a barrier than having to hack your way into the game. C# is certainly easier to pick up for those who only start learning programming, but if you have to write in C++ to create a mod, there will be people doing it. I think CDE has enough of a community already for that. However creating a good infrastructure for writing and using mods is in turn able to prompt people to make them.

For me the golden standard of mods (and steam workshop) integration is Space Engineers. Making and sharing content, as well as turning mods on and off is extremely easy in that game, and look at the bustling modding community around it. And it's much less of a game after all the years in early access than CDE is right now.

The mod you have linked, as all other modern KSP mods, use the extensive API (over 2000 classes) that KSP provides. I've not seen that original mod for loading external code nivik mentioned, but if I have to guess it must have used something like DLL injection. I'm in no way an expert on DLL injection, but from my limited understanding it consists of loading a DLL into the memory space of the target process and then making that process run some code from it. That's what I meant by hacking into the game.

It's not necessary in KSP today. KSP loads all DLLs in the GameData folder at runtime without any of the above techniques, then it uses class attributes (a feature of C#) to know what components the classes in those DLLs are supposed to replace and it provides a wealth of interfaces to supply data to the mods via the DLLs that modders can include into their projects. This is what I mean by modding infrastructure.

Of course, CDE doesn't have any of that. Your RPC idea should work, but you will still need to inject that DLL that will listen to those calls and execute them for you. The next logical step would be to inject a DLL that would just load other DLLs and run some code from them. That way you won't need another process to make those calls. In fact, that is probably how that original mod for KSP worked. Modders will also have to use a PDB reader to navigate through the PDB file to find what procedures they can call.

That could work, but you still run into the issue of not knowing anything about the game code's structure: what the classes are, what their member functions are, what you can access publicly versus what's private...not to mention more esoteric questions: What happens if I change a nozzle deflection before or after physics was calculated this game tick? What happens if I instruct the nozzle to deflect more than its gimbal angle allows? What happens if I try to deflect a non-gimballing engine? What happens if my AI script isn't terminated after the remote control is destroyed, and I keep telling a nuclear warhead to detonate after it doesn't exist in-game anymore?

If the code is written in a way where it's assumed the person writing control code knows what the limits are, there may not be anything which keeps you from doing things which shouldn't be possible. You might wind up with rocket engines pivoting 120 degrees and poking out the side of the armor or clipping through fuel tanks. You might wind up with a nuclear bomb that goes off once per physics tick, forever, until the game crashes. You might be able to re-class the sun as a 10^18 gigaton nuclear bomb (though it's unlikely you'd do that accidentally).

Here there be dragons.

Hey foof, how did you manage to do that? I'm pretty decent with Blender and would love to use it for modding, but don't know how to get models into the game.