Additional Action Groups Development Thread (Now with Progress Screenshot)

[Diazo]

Okay.

There have been a lot of talk and request for a mod that adds additional action groups and I'm willing to have a go at this.

However, I'm stuck and need some help to even get started.

Pretty much all my stumbling blocks boil down to saving the action groups. I am aware of the KSPField attribute, but does anyone know if I can access the persistence file directly? I could loop through all the action groups and saving them individually through the KSPField fucntion, but I could see that being a performance issue with a high number of groups.

Or is there another way besides the persistance file to save per ship data like this?

I'm about to go off and look at the big mods that save data (Kethane, etc.) to see if those give me any ideas.

I suppose another way to phrase my question is how do I save per-ship data?

I am aware of KSPFields and I know how to read/write data to a .cfg file but I've never had to save per-ship data and am drawing a blank.

D.

Edited March 15, 2014 by Diazo

[sal_vager]

It has to be possible or "Actions on the fly" wouldn't work, maybe you can drop macbernick a PM and see if he can help you out

[diomedea]

I believe you could also find interesting this post from Action Group Manager author (Sir Julio), explaining why additional action groups would require to rewrite the logic behind them (I made him the question time ago, just about what this thread is about).

[Greys]

Feasibility depends on what you want out of it and what you're willing to sacrifice. ActionGroups are basically in game macros so it would be entirely possible to make a mod that is also in game macros; and the events that actiongroups fire are publically findable. It wouldn't integrate with any other mods unless those mods sought out comparability. Integrating with the KSP UI is possible, but I believe an unnecessary amount of work and it would lead to misunderstandings where people don't realize they're separate.

If you want to have more actiongroups, you would have to change KSP.

[Diazo]

Alright.

I think I have a skeleton of an idea on how to get this working.

However, I am now stuck on the details of how KSPField works.

I need to assign a Double value to each part on a ship and I need to be able to assign it in the VAB and have it carry over to Flight Mode when that vessel is launched.

There is no filtering or criteria on this, I simply need to have a Double Value 'AGXGroup' associated with every part and if a part does not have the AGXGroup variable, create it with a value of zero.

The rest I'm pretty sure I know how to do (testing pending), I'm just at a total loss on saving this double value, it's how action groups assigned in the editor will carry over to flight mode.

(AGXGroup = Action Group eXtention Group)

D.

[Mulbin]

ActionGroups are basically in game macros so it would be entirely possible to make a mod that is also in game macros

Exactly this! Too many people have dismissed the idea because they get hung up on the idea that you need to alter the existing action group coding. You don't. The mod can simply be a completely new code that fires its own macros without touching the core ksp files like any other mod.

I'll be watching this thread closely, my simulator build needs about 50 hotkeys

[Diazo]

Okay.

It looks like I was barking up the wrong tree.

I could not figure out how to add a KSPField field onto the Part class, so I'm going to have to go with adding a PartModule onto each part to handle this.

The next question is how big do I go? It looks like I can expand the number of groups in sizes of 31 (or maybe 32) and I'll be keeping the default 10 groups so the initial build is going to take KSP to supporting 72 action groups (31+31+10). I could go smaller and support 41, but that does not meet the requested 50 groups and it's literally copy-paste to go from 41 to 72 groups.

However, how many actions do I need to support? A stock solar panel would have 3 (deploy, retract, toggle). I'm thinking if I go with 5 that should cover things like VTOL engines. Can someone who's played with the RAPIER engines confirm that 5 is enough please? I've never used them myself but from reading about them on the forums they are the part with the highest number of actions I am aware of. (I'm after however many actions show in the Editor when you go to ActionGroup mode.)

I will dynamically support the actions as they are defined on the part, but I am going to have to hard-code the maximum number of action on a part in the plugin. (Unless someone knows how to dynamically create KSPFields on the fly?)

D.

Edited March 6, 2014 by Diazo

[diomedea]

Diazo, if I get this right (and I may be wrong) there is a limit because of the dependency of KSP to Unity.

I mean, Unity allows at most a number of keys to be recognized, and even if those are not regular keybinds, there has to be some way to invoke any action separately. Let's call them keycodes, just as Unity does here, because I have no knowledge of any other means to pass a code to the Unity Event handler. In case I was right, the list of keycodes above is the maximum amount possible.

[Diazo]

Ummm, I'm not limited by the number of keycodes however.

Yes, you can certainly assign key codes to the groups if you want, but I'm going to be working around a GUI with buttons to mouse click.

Even then, Joystick Buttons are valid "key" codes. For what Mulbin is trying to do, there Joysticks 1 through 4 with twenty buttons each, that's 80 free keycodes he can bind to his flight sim that my mod will recognize. (Joystick0 being the physical controller if a player has a joystick attached to their computer.) Keycodes will be settable in-game for each player and their desired setup.

Note that while I'm letting KSP handle Action Groups 1 to 10 as it does now, the action groups I'm adding will be completely controlled by self-contained code in my plugin and don't need a key assigned to them.

D.

[Talisar]

However, how many actions do I need to support? A stock solar panel would have 3 (deploy, retract, toggle). I'm thinking if I go with 5 that should cover things like VTOL engines. Can someone who's played with the RAPIER engines confirm that 5 is enough please? I've never used them myself but from reading about them on the forums they are the part with the highest number of actions I am aware of. (I'm after however many actions show in the Editor when you go to ActionGroup mode.)

I will dynamically support the actions as they are defined on the part, but I am going to have to hard-code the maximum number of action on a part in the plugin. (Unless someone knows how to dynamically create KSPFields on the fly?)

D.

iirc, 5 is the correct number for the RAPIER, but I seem to recall one of the mods that adds resource gathering used more than that. I could be wrong, and I'm not at my gaming computer, so I can't check to be sure. KSP Interstellar maybe?

In any case, if it wouldn't cause a performance issue or too much more work, I'd suggest going one more than you think is necessary to give you some padding. I guarantee the day after you release one of the first posts will be from someone who wants one more

[diomedea]

Ummm, I'm not limited by the number of keycodes however.

Yes, you can certainly assign key codes to the groups if you want, but I'm going to be working around a GUI with buttons to mouse click.

Even then, Joystick Buttons are valid "key" codes. For what Mulbin is trying to do, there Joysticks 1 through 4 with twenty buttons each, that's 80 free keycodes he can bind to his flight sim that my mod will recognize. (Joystick0 being the physical controller if a player has a joystick attached to their computer.) Keycodes will be settable in-game for each player and their desired setup.

Note that while I'm letting KSP handle Action Groups 1 to 10 as it does now, the action groups I'm adding will be completely controlled by self-contained code in my plugin and don't need a key assigned to them.

D.

Totally agree about the joystick buttons. Indeed there is exactly where I was thinking to put my bindings, after a mod like yours is done.

The issue I was seeing is about the maximum number, even if you make a GUI, each button still will have to match one and one only of the possible keycodes, so that activating it will call the appropriate event. And, clearly, the keys binded to stock KSP actions (as Space, AWSD, IJKLHN and so on) can't be reused. But, you may have some better ideas that I could not see.

[Diazo]

The issue I was seeing is about the maximum number, even if you make a GUI, each button still will have to match one and one only of the possible keycodes, so that activating it will call the appropriate event.

To clarify my last post, because I will have a GUI with buttons to mouse click to activate an Action Group, binding a keycode to my extended Action Groups is optional, not required.

This is because my mod is going to individually sent the part.Activate, part.Deactivate to the individual parts as required, I'm not using KSP's built in Action Group manager in any way.

I'll check out KSP Interstellar to see what actions it uses, but if the RAPIER engine actually has 5 actions, I'll look at coding in a max of 6.

D.

[diomedea]

Thanks for clarifying (I am getting you actually not going to depend on Unity events 'cause you're doing your own manager, and that gives plenty of freedom).

So, if the issue is about max number of actions with a part, I should let you know about HullcamVDS cameras, those have 11 actions coded.

[Diazo]

Erk.

Ummm.

Okay.

I'll have to change a few things up, but I can handle that.

However, performance question for people. If there are 11 actions possible, each part on a vessel will have an associated 62 column boolean array.

So, on a 200 part vessel and the 200 62x11 arrays (of booleans) that brings, do people thing I'll be running into performance issues?

Or do I need to rethink my approach?

D.

edit: Wait, never mind. Just thought of a better approach anyway.

Initial release will support 15 actions on a part.

Edited March 6, 2014 by Diazo

[diomedea]

If your mod requires to poke each cycle all of those bools, it will certainly incur in some performance issue (I can't follow your math, but that's another story).

Same, if those bools are to be stored, those make for a significant chunk of memory. Getting worried about my 900+ parts ships.

Being those cameras rather the exception then the rule, could such parts be associated to a dedicated array, leaving them apart from general parts? (of course, that may require to have a double cycle to check both the general and the dedicated array).

[Diazo]

Actually, the better method I came up with gets rid of the arrays.

Rather, each time a extended action group key is pressed, it will perform a single AND bitwise operation per part per max action group in the vessel.

So for the 15 action groups limit, on a 900 part vessel that will be 13500 AND operations per keypress.

That sounds like a lot, but bitwise operations are just about the least demanding in terms of performance and as they only happen once per action group keypress I expect that even the 900 part vessel will not have problems, well no additional problems beyond what that many parts do to your computer already. (Testing pending of course.)

D.

[Mulbin]

Very excited to see things like "72 action groups" being mentioned Really opens things up for my simpit build... especially as I'll need two groups for some operation (for example a solar panel I would use an "Extend" group on one hotkey and a "retract" group on another to allow me to ensure my microcontrollers are matching the switch positions correctly to the game at all times - a single toggle action group goes out of sync very easily!

But these numbers are very promising and will mean and entire Arduino mega just dedicated to control inputs... individual engine selection switches, gimbal locks, fuel feed switches.... I need to start sketching some more control panels!

[Diazo]

Okay, tonight was promising.

I have made the following work:

-Add the persistant KSPFields onto a PartModule and add them to each part.

-Change the value of said KSPFields in the VAB and have them carry over to Flight Mode. This will allow action groups to be set in the editor

-Find the list of actions that I will have to show in the action group editor, mostly.

-Trigger an action directly through code. (EXTEND that solar panel!)

The only hurdle I really have left is that I can only find Extend and Retract options for the solar panel. I have not yet figured out how the Toggle action works.

I can see the Toggle() method in the Object Browser in Visual Studio, but I don't know how to list in dynamically in game so I can have this mod support it.

After that, I have proofed everything individually, I will just have to put it all together. The GUI for this is going to be the toughest part.....

D.

Edited March 7, 2014 by Diazo

[MrHappyFace]

For the toggle action, couldn't you just have it check if the part is extended or not, and do actions accordingly?

[Diazo]

Actually not quite how the toggle works in the code. I've figured it out but I will have to track if the part is engaged or not.

Having said that, I have got everything working in principle at this point so I'm now getting into the details of presenting the GUI.

The big question I have at the moment is how to handle docked vessels? The straightforward way is simply assign actions to an action group and ignore if ships are docked or not. However, that means that the player has to keep things straight so that the same functions are in the same groups when designing their vessels.

Now, I have heard complaints about groups getting confused when vessels dock because different functions are assigned to the same group number but I'm not sure if I need to worry about it as this mod will have so many action groups you can assign groups 1-15 for vessel 1 and groups 16-30 for vessel 2 so that when they dock they stay separate.

But if I do it that way, the keybinds are different for vessel 1 and 2 as for vessel 2, group 16 is group '1'.

Unless I make it so a key can be bound to multiple action groups, that way the same key activates both group 1 and group 16 so it performs the same function on both vessels.

Thoughts?

D.

[Faark]

I wouldn't think about action groups in numbers, from a users perspective. An action group "Lights" or "Solar panels" or how ever i named them do make a lot more sense. Merging them by name should be pretty safe, while some advanced UI might allow the user to call it for a specific docket part only or sth like that...

[Diazo]

Okay. Progress is being made but Real Lift is intruding and my time is limited at the moment. :/

However, I have prototyped all back end code and can manually make all functions work.

I'm now into the grind of trying to hash a UI together that can actually handle this and almost have something I'm willing to make a screenshot to show off. (If things go smooth I'll be ready to show a picture tonight.)

@Faark: In the back end I'm sticking with action group numbers, things get messy otherwise. I will be offering the option to rename groups though so they have user-friendly names. I have no plans for merging groups by name or anything like that for the initial release.

On the topic of the initial release, here's a relatively firm list of features. No guarantees but I'm now making the UI so any changes are more likely to be there.

Integration with KSP's default action groups. Action Groups 1 - 10 will stay managed by default KSP. Any changes made through this mod will be saved back so that if the mod is uninstalled, those actions will still be in the correct groups.

Increase the available Action Groups up to 260, to be displayed in groups of 20 in the UI. In the code only groups that have actions assigned will be loaded into memory so there should be no performance hit for supporting that many groups. This will be a hard limit however, my comments from earlier in the thread about increasing the number of groups being easy is no longer valid as increasing past 260 will required re-writing most of the mod. Having said that, if you need more then 260 action groups, just what ARE you doing?

Name actiongroups. Can't remember what an actiongroup does? Now you can name them with a (short) text description to be visible in flight. These descriptions will be saved on a per vessel basis so different vessel's groups can be named different things.

Assign ActionGroups in flight mode. All Action Groups (so including KSP's default 10 groups) can be edited in flight mode.

One Key, Multiple Groups. A single hotkey activating multiple groups will be supported. How this used will come down to player preference, but it increases the mod's flexibility.

Multiple Saved Keybindings. Also under the flexibility heading, you can easily swap between different keybindings setups for different ships. Have an interplanetary mothership and a separate lander? Assign groups 1 - 10 to actions on the lander and groups 11-20 to the mothership. Then while launching the lander to dock have physical keys 1-10 on the keyboard control groups 1-10, then once docked and controlling the mothership, have physical keys 1-10 control groups 11-20 instead. Note that this swap will be automatic as each vessel will save which keybinding setup to use. (Optional of course, you can manually control which keybinding setup is in use at any time.)

So, I just now need the time to hack the GUI out. I know the layout I want to use, I just have to convince my code to do it for me.

D.

Edited March 11, 2014 by Diazo

[Mulbin]

Absolutely fantastic work! Can't wait to get my hands on it and really go to town on my simpit build

[Diazo]

Actually, how are you looking to interface to press the "keys" in your simpit?

I am going to expose a method that if you are writing a module you can call action groups directly, or you can use the keybindings that Unity supports as listed here.

Is there a third method to interface you were looking at using?

D.

edit: Just saw your simpitZitronen's thread. Looks like calling the method might be the best way?

Edited March 11, 2014 by Diazo

[Mulbin]

Currently I'm using Zitronen's KSP serial to Arduino plugin... I don't really know any C so at present I'm limited to command he includes in the plugin. For additional commands I planned to simply use more Arduinos generating keystrokes... by having one action group to turn a function on, and a second to turn the function off I can ensure the switches don't go out of sync when loading or docking as the Arduino will be constantly checking the switch state and sending the appropriate signal.