Config Nodes, Serialization, and Reflection

[Teknoman117]

I'm new to writing KSP plugins, and from what I gather, the proper way of providing configuration to your mods is the config node system. I've been looking through some existing mods' usage of config nodes and usually I see a lot of ConfigNode value checking and if(has node) type stuff. I've noticed that the PartModule system makes use of reflection information. You attribute your class members with KSPField and the configurations will be loaded when the game starts and written to automatically.

Is there a way of doing this for generic configuration? I'm working on a mod called Kopernicus, which aims to be a replacement for and improvement upon PlanetFactory. We want to be able to put .cfgs for the new planets in the plugin directory, and are wondering if there is some way built in to KSP for the corresponding classes to be instantiated when the config files are read, versus having a plugin hook the start instantly event and scrape the config directory manually with the large trees of config node reading.

http://forum.kerbalspaceprogram.com/threads/88168-Early-development-0-24-Kopernicus-Planetary-System-Modifier

- Nathaniel R. Lewis

[stupid_chris]

Not really. The best you could do is implement IConfigNode, and use [Persistent] attributes over some fields and then load the object through ConfigNode.LoadObjectFromConfig() (I think I wrote that right), but it's about as good as it gets. Though you can speed up the process By using expansion methods on ConfigNode, as I did for RealChute. I believe I got toadicus to implement them within KSPAPIExpansion.

[NathanKell]

You mean swamp_ig. toadicus does Tweakable Everything

I don't know of a way either to do what you're asking; the best approach here is to (as with so many KSP things) write it yourself. Then no one else has to...

[Teknoman117]

Haha, well I'll check out KSPAPIExpansion, and if it doesn't have the answer, I'll write it myself. Is KSP smart enough to sort out the order that assemblies need to be loaded in?

Edit - Talked with NathanKell, it isn't smart enough to do that. 000_ConfigNodeWrangler here we go! I'm going to be looking into how PartModules work and see if I can come up with something similar, but for generic mods.

- Nathaniel Lewis

Edited July 30, 2014 by Teknoman117

[blizzy78]

000_ConfigNodeWrangler

Please, don't. Use [assembly:KSPAssembly] instead.

[rbray89]

I'm new to writing KSP plugins, and from what I gather, the proper way of providing configuration to your mods is the config node system. I've been looking through some existing mods' usage of config nodes and usually I see a lot of ConfigNode value checking and if(has node) type stuff. I've noticed that the PartModule system makes use of reflection information. You attribute your class members with KSPField and the configurations will be loaded when the game starts and written to automatically.

Is there a way of doing this for generic configuration? I'm working on a mod called Kopernicus, which aims to be a replacement for and improvement upon PlanetFactory. We want to be able to put .cfgs for the new planets in the plugin directory, and are wondering if there is some way built in to KSP for the corresponding classes to be instantiated when the config files are read, versus having a plugin hook the start instantly event and scrape the config directory manually with the large trees of config node reading.

http://forum.kerbalspaceprogram.com/threads/88168-Early-development-0-24-Kopernicus-Planetary-System-Modifier

- Nathaniel R. Lewis

Check out what I'm doing in the overhaul release of EVE. I used the [persistent] tags in objects to be loaded by MonoBehaviours that are loaded up. EVEManager is the project you want to look at.

[Teknoman117]

Please, don't. Use [assembly:KSPAssembly] instead.

C# is not a language I'm extremely familiar with (mostly c, c++, and objective-c), what exactly does that do and where does it go?

[blizzy78]

C# is not a language I'm extremely familiar with (mostly c, c++, and objective-c), what exactly does that do and where does it go?

[assembly: KSPAssembly] and [assembly: KSPAssemblyDependency] are used to declare your assembly as a KSP plugin, or declare a dependency on another KSP plugin, respectively. These go into your AssemblyInfo.cs file.

Examples: https://github.com/blizzy78/ksp_voice_commander/blob/master/VoiceCommander/Properties/AssemblyInfo.cs#L38-L40