Enable other mods to push custom commands

[JDPKSP]

In order for other mods to more closely interface with RT, it should be possible for them to push custom commands in the flight computer, to then later have an event fired within the mod when the command is popped.

In pseudocode such a Command, inheriting from AbstractCommand, could include the following fields:

string guiName; //What to display in the visual queue
bool guiActive; //Whether to display the command in the visual queue at all
Object (or possibly ConfgNode) data; //the input data whith wich to call the event native to the mod

[SirDiazo]

I'd just like to bump this to second it.

I'm looking to integrate Action Groups Extended and with the existing API in 1.6 I can do the delay on directly controlled actions easy enough, but I have no way of adding to the flight computer.

Now, I am stumbling on how exactly to make this general to all mods. Is there some way to hook in a callback? I'm not sure how else to link the commands back.

I'm installing RemoteTech now to test, depending on how things go I'll update this post.

Okay, after 10 minutes of experimenting, I think if RT adds two things, that will allow any mod to become compatible.

Doing things this way, all RemoteTech has to remember is a string that it spits back out when it is time to execute.

1. Open an API call that adds a custom command to the flight computer. SOmething like:

RemoteTechAPI.AddToFlightComptuer(Vessel, GUIString, CommandString)

This would be triggered from the other mod's side. Vessel is the vessel identifier, GUIString is what will appear on the flight computers GUI, CommandString is simply a string that remote tech will spit back out when it is time to execute.

2. Callback that other mods can subscribe to.

This is where a mod listens for it's command string to come back to it. On remote tech's side it is simply a callback that every time Remotetech hits a custom command, it spits the CommandString back out this callback. That means all subscribed mods see all CommandString, but it is the mods job to make sure it processes only the commands directed at it.

I'll see if I can produce some actual code, but before I spend too much time on it, does this approach work for you all?

[JDPKSP]

I would recommend to use Guid and Confignodes in stead:
RemoteTechAPI.AddFlightComputerCommand(Guid vesselID, ConfigNode command)
Where the flight computer tries to look for GUIdescription field to provide the GUI description.
Using a confignode, it would be much easier to send more complex commands without having to do your own custom serialization of a string.

[JDPKSP]

And to add. The absence of a GUIdescription field within the confignode would mean that the command is simply not shown within the flight computer. If your mod is adding a lot of commands continuously, you wouldn't want to spam the command queue with them.

[SirDiazo]

That is actually a good point, there are really 3 types of commands I can think of that this would need to support.

1. The other Mod does everything, RemoteTech just tells it when to activate. This is the example my previous post had. The external mod would add a command to the flight computer that when it was up, RemoteTech would tell the mod "Activate now" and the other mod does everything. This type of command would show on the Flight Computer GUI.

2. The other Mod does everything, but does not show on the Flight Computer. Pretty much the same, but this would be used for things that should not show on the Flight Computer, but should still be subject to signal delay. This would require adding a "remove command from Flight Comptuer" method to the API as well.

3. Mod enters the command, but RemoteTech executes. For stuff like "face prograde", or "set throttle", this would essentially mimic entering the same command via the flight computer's GUI, just done by a mod through code.

For that, a confignode makes much more sense. If RemoteTech is just bouncing the command back, it does not matter what is in the config node so it is much easier for the other mod to work with, and if it is a command RemoteTech will execute, as long as the confignode is in a format remotetech recognises, that works too.

As for Guid, that works too, any unique identifier for the vessel works and I think I've seen Guid used elsewhere in Remotetech's code.

[SirDiazo]

Okay, i'm writing code for this and I think I have a working setup.

However, if a vessel has multiple potential flight computers, what would be the best way to get a reference to the correct computer so I can add the command? As the command is coming from outside, I don't have the internal reference commands currently use when assigned via the on-screen GUI.

(Also, is there a dev thread on the forums for this mod where I could put questions like this?)

[Peppie84]

Hi diazo,

I think it is not possible to have more than one flight computer on a
vessel, because the flight computer is bound to the vessels guid.

We've no dev-thread :/ Should we create one?
Am 20.01.2015 06:37 schrieb "SirDiazo" notifications@github.com:

Okay, i'm writing code for this and I think I have a working setup.

However, if a vessel has multiple potential flight computers, what would
be the best way to get a reference to the correct computer so I can add the
command? As the command is coming from outside, I don't have the internal
reference commands currently use when assigned via the on-screen GUI.

(Also, is there a dev thread on the forums for this mod where I could put
questions like this?)

—
Reply to this email directly or view it on GitHub
#233 (comment)
.

[SirDiazo]

Okay, I need to dig into the code some more then, I found the partModule references to the flight comptuer but not where it limits it to one per vessel Guid.

As for a dev thread, don't create one just for me. I just figured if there was an existing one it was an easier place to have this conversation.

[Peppie84]

Hi, i thought it was the guid. 😊 With this code you can get the current flight computer: https://github.com/Peppie23/RemoteTech/blob/master/src/RemoteTech/UI/TimeWarpDecorator.cs#L163

[SirDiazo]

Ohh, thank you for that, saves me hunting that down.

Now, just to make sure I'm not short-circuiting something, it looks like this here is how I would add a command to the flight computer by passing it a new ICommand class I'm making for this:

https://github.com/RemoteTechnologiesGroup/RemoteTech/blob/master/src/RemoteTech/FlightComputer/FlightComputer.cs#L143

However, when I look at the GUI buttons, they are using this () => RTCore... thing that goes straight over my head. (Modding KSP is a hobby and the sum total of my programming experience so I don't know a lot of stuff still.)

https://github.com/RemoteTechnologiesGroup/RemoteTech/blob/master/src/RemoteTech/UI/AttitudeFragment.cs#L132

Is it okay if I find the correct flight computer and then use that Enqueue method I linked, or is there other stuff on that code behind the GUI button I need to hook into?

[Peppie84]

Yes the Enqueue is the method you need.
Here is a more clear example:
https://github.com/RemoteTechnologiesGroup/RemoteTech/blob/master/src/RemoteTech/UI/AttitudeFragment.cs#L296

And yes, you should create a new ICommand-Class. Maybe ApiCommand but this is up to you ;)

[SirDiazo]

That is pretty much everything I need I think.

I wrote my first try at the new ICommand class (I called it ExternalModCommand, you want me to put API in the name somehwere?) and got stuck on how to correctly add it to the flight computer to test it out.

Those two links you gave me look like exactly what I need so I'll see what progress I can make tonight.

[Peppie84]

no its ok with the name of the command.

[JDPKSP]

When popping custom commands I'd recommend using a static callback<Guid,ConfigNode>, since custom commands would still be handled persistently and serializing callbacks would become very messy. This does require other mods to have a fair bit of persistence themselves, so it might be prudent to add a PersistenceLoaded flag to the configNode when it is saved to persistence. Just so other mods have the opportunity to ignore commands that have passed through persistence.
I would also like callbacks in the API for events such as OnDisconnected, OnConnected, OnUnpowered, OnPowered. Just so that other mods don't have to constantly check connectivity.