New to making plugins; looking for advice

[The Great Potato]

Hi all!

I'm starting up on my first plugin and I'm trying to get a feel for the API and its documentation. My goal for this plugin is to create a set of part modules that support unguided rockets, i.e. rockets that have no pods or probe cores.

Specifically, I'm looking to make:

- A module (or perhaps an overall game condition) that always allows vessel control during prelaunch, even when there is no active command module.

- A Flight Recorder part that stores flight data. Kind of like an experiment, except recording is automatic and the science is returned at the end of the flight, even after crashes. On Kerbin, at least.

- A Gyroscope part that provides a weak reaction wheel and automatically provides ASAS in a preset vector.

Started working on the first one for now, because it looks like it has the least moving parts to figure out. Looking through the API documentation, I saw the CommandPod class and thought that might be a good way to implement the launch pad controller. Override onCtrlUpd to pass the event to the parent only if the vessel is in the prelaunch state, right? I dug around the docs and the stock cfg's to see if it would work that way, and I ended up getting really, really, confused. The cfg's contain no mention of a CommandPod part, only the ModuleCommand part module.

And so, my first question(s):

Messing around with the cfg's before, I always assumed that the PartModules are primarily what differentiated parts from each other; I didn't expect to see separate Part classes. It looks like these Parts are what do most of the heavy lifting for specialized pieces, but how does the game know from the cfg's which parts are CommandPods -- is it set in the ModuleCommand class? Is it possible/safe to create a new Part subclass?

[sarbian]

CommandPod is the old (pre 18 or 19 ?) class. At that time part where not using module but each had a specific class. Ant class that inherits from Part should be considered as deprecated.

For your need you should do either :

- a class that inherits ModuleCommand and do the control update / lock as you wanted with CommandPod

- a dedicated PartModules that would disable a part ModuleCommand when some condition are met. This one is less likely to generate problem with other mods. You could look into Remotech2 code for some hints on how to do it.

[MrHappyFace]

The Part classes are deprecated, and haven't been used since 0.15. Now, all parts use PartModules, and the solution for making a command module us quite simple:

have a module, that sets vessel.isControllable to true as long as vessel.state == State.PreLaunch, or something like that.

You shouldn't be making any Part subclasses, as almost everything they can do, can be done with modules much more cleanly.

As for the gyro, try messing with the vessel.vesselSAS and vessel.Autopilot members.