How to handle dependency?

[Diazo]

Alright.

I've almost got my Additional Action Groups mod ready to go but there is one last thing I still need to deal with.

How do I expose my plugin to other plugins so they can interface with me?

So far I've come up with 4 methods:

The simplest is to simply expose a method that other mods call. The problem with this is that makes my mod a hard dependency that requires my mod to be installed for the other mod to even run.

I'm going to make this option available anyway by making my internal call I use public, but I don't expect this to be popular due to the hard dependency requirement.

The second is to use the reflection that blizzy's toolbar uses. While this is a better then a hard dependency as it allows the other mod to run if my mod is not present, it does make other mod's include code from me. While not a huge issue, it can be problematic for inexperienced coders to implement. (It took me something like 2 hours to get my Vertical Velocity mod to correctly implement this.)

The third method (which I have not investigated at all yet so I don't know how valid this is) is to look into the SendMessage event. Because of how my mod works, I don't actually need to pass data back and forth, all I need is a trigger to activate an action group. So I'm hoping I can set things up so that other mods do a SendMessage("AGX001") as an "Activate Action Group 1" message and that my mod can then pick up on it. This would not allow another mod to see any of my data, such as which actions are in which action groups, but for something like a SimPit that does not care about that stuff, I'm hopeful this will be an easy way of triggering actions.

The fourth method, and the one I like least, is to use an unused field on either the Vessel or Part class. I've never seen Part.customData (type string) have any data in it so I think it could be used for this. So another mod would append a text string of something like "AGX001" to that field. My mod would then be watching that field and parse that as the trigger to activate group 1.

I don't like this method because it requires that Squad both never use that field and not delete it as unused on a future optimzation pass. It also requires that other mods not use the field either. I could append a special character in front so that any existing data in the field is preserved but that will probably still screw up any other mods using the field for something.

Now, after all that I have two questions:

1) Is there another method that I have not thought of for passing data between two mods? All I'm after here is passing the "Activate Group 1" command. Anything more complex will require a dependency or reflection.

2) If you were writing a mod to use the extended action groups in my mod, what would be your preferred method?

D.

[stupid_chris]

You can call methods with Reflection. You really don't ever need hard dependancy.

[Diazo]

So I could offer code as follows?

pseudo-code

private void AGxActivateActionGroup(int group)
{
if(Check if my mod is installed and running)
{
Call my method ActivateGroup(group) here
}
else
{
Mod maker can stick code in here to run if my mod is not installed.
}

}

(Not on my programming computer to look up the correct code)

And they copy-paste that method into their namespace at the same level as the Update() method and we are good to go?

D.

[Faark]

Reflection is the only reasonable (and by the way highly efficient) way to go, if you can't avoid a dependency altogether and the other mod does not necessarily need your mod. I don't see the any real difficulty here, since you provide a fully functional .cs file that does all the heavy lifting and that they don't have to edit at all. Btw, best thing would be if its behavior doesn't change, regardless whether your mod is present or not. If it is, use your Code... if not, fall back to what the stock version of that method.

[stupid_chris]

So I could offer code as follows?

pseudo-code

private void AGxActivateActionGroup(int group)
{
if(Check if my mod is installed and running)
{
Call my method ActivateGroup(group) here
}
else
{
Mod maker can stick code in here to run if my mod is not installed.
}

}

(Not on my programming computer to look up the correct code)

And they copy-paste that method into their namespace at the same level as the Update() method and we are good to go?

D.

That's not really how I would proceed.

In your place, I would simply require modders to add methods to their code with a prefix. Basically, when a part is selected to add to an action group, you could search through all the part modules and look for methods named something like "AGx_*something*" (so basically Contains("AGx_"), and those would be the action groups. Then you simply need to store the part modules and string names of the methods, and invoke them when that action group is fired. All of this using reflection of course. Using a combination of Linq and Reflection should be pretty effective here.

Then all modders would have to do is add Methods who begin with "AGx_" in their code and that would be the action groups. The only problem I see with that is stock action groups. I /think/ you could search for methods that have a KSPAction attribute. That should work filling that gap I believe.

[Faark]

Afaik isn't he really looking for that kind of dependency. AG methods are defined as usual in KSP and he can use them. But utility features like managing or firing those custom action groups will be a problem. Imo, the best approach would be to offer a .cs file doing exactly that for the users. It doesn't just offer compatibility but also provides a simplified API to do so, that way how ever wants to use it doesn't have to learn the KSP-way to do the same in the first place. Though i'm not really sure what features an action group manager should expose anyway^^

Guess the best solution would be to just release the mod for now and think about such stuff later

Edited March 17, 2014 by Faark

[Diazo]

Okay.

First, this is going to be a full fledged action group manager. My mod takes care of remembering which actions are in which group and triggering the action groups and everything associated with that.

Note that I am building action lists dynamically. As long as an action attached to a part would show in the default ActionGroup manager, it will automatically show in mine with no extra steps required.

So I was thinking of exposing the following methods:

ActivateActionGroup(int group) //Activate action group by number, all most mods will need
ActionGroupStatus() //Return activated action groups, what I expect to be the second most commonly used method
ListActions() //Multiple overloads here to return all actions, actions in a group, actions on a part, etc.
AddAction() //Add an action to an action group
RemoveAction() //Remove an action from an action group

I can't think of anything else a mod would need? I'm trying to cover everything in terms of managing action groups within my mod, it's really the people doing external hardware, such as a simpit, that I expect to have to interface in code to pass actions from the physical buttons and switches.

At this point, I think I have answered my question and I'll see what people think once I can get an actual release into their hands.

D.

[stupid_chris]

Okay.

First, this is going to be a full fledged action group manager. My mod takes care of remembering which actions are in which group and triggering the action groups and everything associated with that.

Note that I am building action lists dynamically. As long as an action attached to a part would show in the default ActionGroup manager, it will automatically show in mine with no extra steps required.

So I was thinking of exposing the following methods:

ActivateActionGroup(int group) //Activate action group by number, all most mods will need
ActionGroupStatus() //Return activated action groups, what I expect to be the second most commonly used method
ListActions() //Multiple overloads here to return all actions, actions in a group, actions on a part, etc.
AddAction() //Add an action to an action group
RemoveAction() //Remove an action from an action group

I can't think of anything else a mod would need? I'm trying to cover everything in terms of managing action groups within my mod, it's really the people doing external hardware, such as a simpit, that I expect to have to interface in code to pass actions from the physical buttons and switches.

At this point, I think I have answered my question and I'll see what people think once I can get an actual release into their hands.

D.

Why would people need to add/remove and activate actions themselves?

[Diazo]

Why would people need to add/remove and activate actions themselves?

I'm not sure, but I have to setup the reflection for the other methods anyway, so it is more a sense that I might as well do it rather then not do it when it will take me something like 30 additional seconds to code.

Maybe there will be a one-shot part of some sort that after activating can not be deactivated and so should not longer be in an action group?

D.

[stupid_chris]

I'm not sure, but I have to setup the reflection for the other methods anyway, so it is more a sense that I might as well do it rather then not do it when it will take me something like 30 additional seconds to code.

Maybe there will be a one-shot part of some sort that after activating can not be deactivated and so should not longer be in an action group?

D.

IMO you should handle everything that relates to managing the action groups. Modders should simply have to add action group methods and the rest should be done by AGx. Action groups are just void methods that are called on key presses. If modders need to start handling how the action groups are managed, it's going to be much harder on the other side of the deal.