[Technically RESOLVED] Which class to inherit from? - New plugin for very basic ship control

[wossname]

Howdy,

I have just started to create my first KSP plugin. I'm up to the point where my IDE is set up correctly according to the tutorial here: http://wiki.kerbalspaceprogram.com/wiki/Plugins.

My goal for now is to make a very simplistic proof-of-concept plugin that simply lets me activate the first stage of a rocket, say 10 seconds or so after spawning on the launchpad.

I do not need any kind of graphical interface whatsoever (writing text to the log file will be sufficient), and the plugin only needs to be enabled when the vessel is actively engaged in a flight (from the launchpad and up until the end of the flight, but not in the VAB).

I want to be able to switch between vehicles (when the user hits the [ and ] keys) and have my plugin affect the next vessel selected, so it "follows" the focus of the main GUI controls such as mouse and keyboard.

I don't want to have a "physical" rocket part that I have to attach to the vessel in order to make my plugin available.

The tutorials I have seen generally assume that we are trying to make a physical part for a ship, but I just want something more to do with non-graphical flight interface augmentation.

The tutorials use "PartModule" as the parent class (which seems to have some baggage with it involving config files). Given that I don't want to make a part as such, is there a more suitable class to inherit from? There's a lot of classes to choose from by the looks of it, could use some guidance.

Cheers.

w.

[NathanKell]

Moved to Plugin Development.

You're going to want to make a KSPAddon. Example:

[KSPAddon(KSPAddon.Startup.Flight, false)]
class ControlLocker : MonoBehaviour

KSPAddons take a startup scene (one of the scenes, or all) and a bool that says whether to start up every time the scene loads or to run only once (you presumably want runonce=true if you're doing some changes on KSP start, like at the main menu, and don't want to doubly change things when someone goes back to main menu).

You can then write various MonoBehaviour methods, like Start(), FixedUpdate(), Update, etc. Presumably you would want to have a double counter = 0, run on FixedUpdate and once FlightGlobals.ready increment the counter by TimeWarp.fixedDeltaTime, and when counter > 10 do FlightGlobals.activevessel.stage or whatever.

[FreeThinker]

I suggest you look at the source code of any mod which does anything at startup.

Edited March 18, 2015 by FreeThinker

[wossname]

Thank you NathanKell and FreeThinker for replying.

I've been looking at the "KSPSerialIO" plugin to try to understand how this all hangs together but I'm struggling to see where the entry point is for it. Where are things like "Start()" and "FixedUpdate()" actually defined? They don't seem to be defined inside the MonoBehaviour class as far as I can see from looking at the VisualStudio object browser ("show definition" when highlighting the MonoBehaviour class name).

If I'm going to override those then don't I need to be able to see the base class's definition of it in the IDE? Sorry, my C# is pretty rusty, it's been a few years.

[Crzyrndm]

Awake, Start, Update, FixedUpdate, LateUpdate, OnGUI, OnDestroy, etc. are inherited from Unity's Monobehaviour (see the flowchart here for details on when each one executes). PartModule also inherits from Monobehaviour, but also has it's own extra versions of those (eg. OnFixedUpdate) which only run when the part is active

Edited March 18, 2015 by Crzyrndm

[wossname]

OK so this class library I'm writing needs to conform to the Unity "interface" (to use a C++ term) but that interface isn't visible from within the C# IDE?

At least I can't see these definitions in my current setup. I'll double check my library references in case I missed something.

Edit: Well I can see my code being called in KSP but I don't understand how.

It's very weird but it is working... where is the "contract" between my library and the Unity Engine? Confused - but happy it works.

I'd be grateful for a description of how Unity knows that my library is the right shape or not. Will it all explode in a heap if I get the slightest thing wrong?

Edited March 18, 2015 by wossname

[Crzyrndm]

Nada, they aren't there (I just checked)

PS

It's not overriding per se. Functions with those names are added to the list to be called at certain events (frame, physics update, etc.), they don't replace anything

Edited March 18, 2015 by Crzyrndm

[stupid_chris]

Unity calls all those functions through Reflection by looking into all the objects loaded in the game that inherit MonoBehaviour. It's a really bad way to do it, but Unity will be Unity. Just take it as it is. The functions will be called at the right moments. If you want the complete list of functions that Ynity can call, you can find them here (under "Messages").

[wossname]

Yeah, I think I should have used the wording "implementing those functions" rather than overriding.

My original question is answered, thank you. I now know that I can inherit from the MonoBehaviour class for my purposes.

But I'd like to understand the reason why the IDE doesn't show at least some kind of placeholder for these functions. The "...\KSP_Data\Managed\UnityEngine.dll" is recognised by the VS IDE since I can see at least some of the class definition for the MonoBehaviour class, just not the bits that are vital for the code to work.

Anyway, I'll continue to ponder this conundrum.

Many thanks.

w.

- - - Updated - - -

Unity calls all those functions through Reflection by looking into all the objects loaded in the game that inherit MonoBehaviour. It's a really bad way to do it, but Unity will be Unity. Just take it as it is. The functions will be called at the right moments. If you want the complete list of functions that Ynity can call, you can find them here (under "Messages").

I did wonder if some sort of duck-typing was going on somehow. Reflection makes sense.

I have been in the wrong frame of mind while trying to write this first plugin. The right frame of mind is something like "O, great Unity, please accept this puny DLL offering and this dead chicken and grant me a few hours of prosperous rocketry!"

[stupid_chris]

I did wonder if some sort of duck-typing was going on somehow. Reflection makes sense.

I have been in the wrong frame of mind while trying to write this first plugin. The right frame of mind is something like "O, great Unity, please accept this puny DLL offering and this dead chicken and grant me a few hours of prosperous rocketry!"

Don't wory about it. It's a really terrible way to do it. By all means, if you were to do a system like that, invoking functions through Reflection this way is NOT the way to do it.

[wossname]

At least I know the trick to this now, so I can get on with it knowing that it really is just a weird interface.

I'm hoping that my final plugin can be simple enough that it uses as few of these "invisible" functions as possible but still accomplish quite a lot.

The main reason I'm trying to get this working is to make some electronic hardware I'm building talk with KSP to control the rocket.

If I can get as much of the complexity abstracted out and away from KSP as possible then the plugin itself should be easily maintainable.

Oh boy, hardware design is so much easier than software. I don't know how you pro's do it!

[stupid_chris]

Oh boy, hardware design is so much easier than software. I don't know how you pro's do it!

I can't tell exactly cause I don't really know either, but I can tell you ridiculous amounts of coffee are involved.

[Crzyrndm]

For a control plugin, you probably only need Start and OnDestroy.

In start you can register a function to enact all your control like this (3 versions. onpre-, on-, onpost-), which does away with the need for FixedUpdate, and you don't need the rest if it's being handled by hardware

Edited March 18, 2015 by Crzyrndm

[sarbian]

Hum, for a control you would need to use the vessel OnFlyByWire callback to input controls (yaw, pitch, roll, RCS, throttle, ...) . You can have a look at Mechjeb MechJebCore to see how we do it.