[1.2.2](Dec10/16) Action Groups Extended: 250 Action Groups, in-flight editing. Now kOS/RemoteTech

[Diazo]

Hmm. I will admit I had not considered RPM support before, mostly because I rarely use IVA myself.

It is one of those things that I should support I think though, I'll add it to the list of desired features.

D.

[Errol]

Even if it were just an adaptation of the screens from your mod that could be loaded into RPM....somehow? With code-magic?

[CCraigen]

Got a few new ones for ya. Firstly, "Return to SPH" doesn't bring the actions with it or load the saved version's actions, although reloading the ship file loads them properly. Haven't checked the VAB yet.

The second bug is more involved.

(1) Large aircraft with belly cranes and extendable stilts

- action groups 1-10 dealing with engine management and cranes

- action groups 20-24 dealing with stilt operation

(2) EVA kerbal from (1)

(3) Small kethane mining rig

All groups labeled, action groups persisted from SPH to runway for (1). EVA'd (2) and moved him out of the way, switch to (3) and drove it underneath (1). Switched back to (1), actions still good. Switched to (2) and grabbed KAS attachment nodes from containers on (1). Began switching between all 3 repeatedly since it was hard to tell which I was in control of. Bug occurred at this point.

At some point during this quick switching, (1)'s actions in group 1-10 had been cleared of names, but all actions were still present. Actions in groups 20-24, however, were cleared completely. No trace of them. Reloading the saved ship in SPH did not restore the original actions, and it appears they are gone permanently. Log file is here. Ship in question is "Packmule".

---

Just did it again, names cleared again. Didn't map the 20-24 groups this time so not sure if that behavior would have been the same. Might have something to do with Kerbal Attachment System changing the part count of vessels on-the-fly.

Edited September 25, 2014 by CCraigen

[Drew Kerman]

Firstly, "Return to SPH" doesn't bring the actions with it or load the saved version's actions, although reloading the ship file loads them properly.

Can confirm having seen this with the latest version, but not consistently. I think it happened when I first assigned the actions and reverted. Regardless the last time I ran the game, loaded the saved craft and reverted to the VAB the actions were still there. So the issue might go away after the craft has been saved and reloaded

[Jacke]

Diazo, thanks for all your attention. I agree with Pecan that you may want to rest up prior to KSP v0.25 becoming live. (I've already backed up KSP v0.24.2.559 from Steam to a separate directory and am running on it so I don't get hit with an unwelcome change before major mods are migrated. It's wonderful you can do that with KSP. )

However, I though I should let you know I've found that the method you suggested for transferring AGExt info for copied .craft files between savegames doesn't quite work, at least for moving between a sandbox game and a full-career game. I don't know if this is related to the Action ambiguous report I PM'ed to you earlier.

@Jacke: To transfer a craft file, you do need to move the ConfigNode relating to that ship as-well. In the AGExtEditor.cfg in the save game you are moving a craft from, find the correct node and then copy that node to the AGExtEdtior.cfg file in your new game.

If you are starting a new game, you can just copy the AGExtEditor.cfg file over in its entirety.

When you open the AGExtEditor file, the node for a craft is as follows:

VAB123456789123456798465 //first line to copy
{
name={ship name}
//node data here
}//last line to copy, the close bracket
VAB222222222222//first line of the next vessel, do not copy

The amount of lines between the two brackets will vary depending on how many actions you have assigned, the easiest way is to find the next vessel identifier line and the close bracket just above it will be the last line you need to copy.

I am planning to merge this data into the .craft file itself at a future date, I will need to do so to support sub-assemblies. (At the moment, AGX can not save actions to sub-assemblies.)

D.

From monitoring the AGExtEditor.cfg file, after copying the stanza for a rocket from the sandbox game to the full-career game while neither are loaded, going back into the full-career game and loading the copied rocket leads to the AGExt stanza being deleted for it, leaving the action names being blanked but the actions being present (at least the 2 I'd set in the first 2 slots). Fairly easy to fix this manually with just a few actions for now.

As far as I can tell, for the same design with the same AGExt settings, the only difference in the AGExtEditor.cfg file stanza is the VAB# and the value groupVisibility, which differs between the sandbox game and the full-career game.

VAB494565458749327510111498105110326587
{
name = 1-A-W1 Kerbin W
currentKeyset = 1
groupNames = ‣001Temperature‣002Pressure
groupVisibility = 1011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111
groupVisibilityNames = Group1‣Group2‣Group3‣Group4‣Group5
PART
{
name = sensorThermometer
vesselID = 0
relLocX = -1.889666E-08
relLocY = 0.5908403
relLocZ = -0.2161526
ACTION
{
group = 1
activated = 0
partModule = BTSMModuleScienceExperiment
actionGuiName = Log Temperature
actionName = BTSMDeployExperimentAction
custom1 = Log Temperature
}
}
PART
{
name = sensorBarometer
vesselID = 0
relLocX = -0.4441701
relLocY = 0
relLocZ = 2.64746E-08
ACTION
{
group = 2
activated = 0
partModule = BTSMModuleScienceExperiment
actionGuiName = Log Pressure Data
actionName = BTSMDeployExperimentAction
custom1 = Log Pressure Data
}
}
}

VAB4945654587493275101114981051103287
{
name = 1-A-W1 Kerbin W
currentKeyset = 1
groupNames = ‣001Temperature‣002Pressure
groupVisibility = 1011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111011111
groupVisibilityNames = Group1‣Group2‣Group3‣Group4‣Group5
PART
{
name = sensorThermometer
vesselID = 0
relLocX = -1.889666E-08
relLocY = 0.5908403
relLocZ = -0.2161526
ACTION
{
group = 1
activated = 0
partModule = BTSMModuleScienceExperiment
actionGuiName = Log Temperature
actionName = BTSMDeployExperimentAction
custom1 = Log Temperature
}
}
PART
{
name = sensorBarometer
vesselID = 0
relLocX = -0.4441701
relLocY = 0
relLocZ = 2.64746E-08
ACTION
{
group = 2
activated = 0
partModule = BTSMModuleScienceExperiment
actionGuiName = Log Pressure Data
actionName = BTSMDeployExperimentAction
custom1 = Log Pressure Data
}
}
}

[Diazo]

Okay, it looks like the auto-save on leaving editor is botched so I'm pulling version 1.17.

Please use my latest 1.16 dev version for now. I should have the next version out tonight.

@CCraigen: I'll parse the log file you provided tonight when I'm working on this, but from your post it sounds like AGX could not keep up with the fast vessel switching. Every time you switch a vessel it has to save the current vessel and the load the new one. I guess if you go fast enough it could be trying to save at the same time it was loading?

The actions being lost would be the editor saving problem I pulled 1.17 because of I expect.

@Jacke: Looking at your post, your actions sound correct. The issue is that the VAB# is different. The VAB# is a hash of the ship name so the longer VAB# with the additional '65' number near the end is a ship named: "1-A-W1 Kerbin AW" (Character code 65 being the letter A).

So the clean up code deletes the stanza because you have a craft file named "1-A-W1 Kerbin W" but the AGX Stanza is named "1-A-W1 Kerbin AW"

I'll double check that there is nothing in the code that change this, it is supposed to generate the VAB# number fresh each time it saves so it is always using the most recent name.

Lots of things to look into now, I'll see what I can get to you guys tonight.

D.

[Jacke]

@Jacke: Looking at your post, your actions sound correct. The issue is that the VAB# is different. The VAB# is a hash of the ship name so the longer VAB# with the additional '65' number near the end is a ship named: "1-A-W1 Kerbin AW" (Character code 65 being the letter A).

D'oh!

I'd changed the name of a .craft outside of KSP, to the filename and the internal 'ship' parameter, from "1-A-W1 Kerbin AW" to "1-A-W1 Kerbin W". I will have to do that inside the game to get it right.

[Diazo]

Dev Version Release: Version 1.17a

Version 1.17 full .zip download (Install first.)

Version 1.17a .dll file only, fix for Editor often not saving actions when you leave it. (Install second.)

Version 1.17a Changelog:

-Rework auto-save on leaving editor so it is no longer as aggressive.

Should still save when mods allow leaving via a non-standard method (although a really strange method may now circumvent AGX's auto-save).

However, as is it now less aggressive it will no longer try to save when the data is in an invalid state and there should no longer be any loss of actions when returning to the editor after leaving it.

-Add ability to disable cleanup of old saves. (All the AGExt00000.cfg files in the save game directory.)

Apparently due to how KSP processes .sfs files (game saves), it can take up to a second per file to process. For people with many quicksaves this can lead to a delay reaching in to the minutes range when trying to load into the space center.

To enable, find the KSP_Install\GameData\Diazo\AGExt\AGExt.cfg file and add the following line:

DeleteOldSaves = 0

(Set to 0 to not run the clean up routine, set to 1 (or leave line out) to run the clean up routine.)

If you do not wish to enable this, do nothing. AGX will run fine with that line missing from the AGExt.cfg file. This option does not disable the clean up of old .craft files in the editor, only the AGExt00000.cfg files.

To help you decide if you should run the clean up routine or not, a start and end time is now printed to the Alt-F2 log when the clean up routine runs so you can tell how much of the delay you are seeing upon loading the Space Center is from this and how much is from other sources.

Work continues.

D.

Edited September 26, 2014 by Diazo

[Jacke]

Appreciate your quick patch releases, Diazo.

[cttw]

Can you remember which part it was?

D.

Firespitter's Parts' Folding Propeller.

[SaintWacko]

Is the only file I need the dll? The installation instructions mention a zip file, but the only downloads I'm finding are dll-only.

[Diazo]

Is the only file I need the dll? The installation instructions mention a zip file, but the only downloads I'm finding are dll-only.

The full download available is Version 1.17 which is a .zip file as there is a .cfg and some.png files that are required.

However, 1.17a fixes a rather nasty bug that would lose actions when you left the editor and it is only a .dll that gets put in the folder created when you extract the .zip file.

I meant to do a full .zip release last night but was not able to as I got side-tracked after supper, I'll go tweak my links to clarify this.

D.

[SaintWacko]

The full download available is Version 1.17 which is a .zip file as there is a .cfg and some.png files that are required.

However, 1.17a fixes a rather nasty bug that would lose actions when you left the editor and it is only a .dll that gets put in the folder created when you extract the .zip file.

I meant to do a full .zip release last night but was not able to as I got side-tracked after supper, I'll go tweak my links to clarify this.

D.

I found my way to your git releases page and found the 1.17 full download. Great mod, very useful! It's so nice to not have to revert to VAB when I realize I've forgotten to set an action group. Is there any way to make it so action groups set mid-flight persist back in the VAB, and in future launches of the same craft?

[Diazo]

I found my way to your git releases page and found the 1.17 full download. Great mod, very useful! It's so nice to not have to revert to VAB when I realize I've forgotten to set an action group. Is there any way to make it so action groups set mid-flight persist back in the VAB, and in future launches of the same craft?

Unfortunately there is not. Due to how the Editor and Flight modes are separated the actions only go from the editor to flight.

There is actually noticeable differences in how the data is stored and that is before we get into issues with staging. (How would actions on parts that have separated be handled?)

I did consider adding that functionality but it would turn into a huge hassle that isn't worth the effort. One of the biggest hassles would be that if rename you ship you can't import back to the Editor anyway as AGX uses ship names to identify vessels. I can't exactly ask people to not rename their ships, that would be unpopular to say the least.

D.

[Jacke]

I discovered another bug (couldn't find it in a search of the thread). The VAB editor Undo function (Ctrl-Z on PC) wipes all AGExt actions. Also, more BTSM "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction" and inability to save BTSM Goo experiment actions to slots 11 and higher (some of these may be duplicates you already know about, Diazo).

Output_log.txt is here. Steps I did during this log:

1. Starte KSP, load BTSM sandbox game, enter VAB.

2. Load small .craft with AGExt actions. Got "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction"

3. Note that AGExt slots 12, 13, and 14 have labels but no actions. Correct each of them to Expose 1 of the 3 Goo experiments. Save the file.

4. Reload same small .craft file. Again got "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction"

5. Note that AGExt slots 12, 13, and 14 still have labels but no actions.

6. Note that AGExt slots 1, 2, 3, 10, and 11 have labels and actions.

7. Make a "mistake" and accidentally pick off a landing leg. "Realise my mistake", discard the landing leg I'm holding, and type Ctrl-Z for Undo. Landing leg is back.

8. Note that all previously assigned AGExt slots, 1, 2, 3, 10, and 11, now only have labels, no actions.

9. Typing Ctrl-Y Redo removes the landing leg but those AGExt slots still only have labels, no actions.

10. Reload same small .craft file. Was distracted and didn't note if there was an "AGX Load Action ambiguous" message.

11. Reload same small .craft file. Again got "AGX Load Action ambiguous. Count: 0 Module: BTSMModuleScienceExperiment BTSMDeployExperimentAction"

12. Changed mode to Action Group. Type Ctrl-Y and then Ctrl-Z. No apparent change.

13. Changed mode to Parts. Type Ctrl-Y and then Ctrl-Z. No apparent change in AGExt information.

14. Removed bottom LV-420 engine and then replaced it. Type Ctrl-Y. No apparent change in AGExt information.

15. Type Ctrl-Z. AGExt information all blanked except labels.

16. Exit VAB, game, and KSP.

Edited September 28, 2014 by Jacke

[Diazo]

Version 1.17b

-Add BTSM actions support.

Version 1.17 full .zip download (Install first.)

Version 1.17bb .dll file only, fix for Editor often not saving actions when you leave it. (Install second.)

@Jacke: This version will make it so the BTSM stuff works.

The undo stuff is new however, I can confirm that it is not working correctly and will look into it.

D.

[Wercho]

Great mod.

I ran into a problem when I switched to 1.17. kOS no longer recognizes action group activation. I uninstalled this mod and kOS started recognizing them again, and I didn't have this problem before 1.17. Do you know why this might have happened with the latest update?

Better description: In kOS, I have a program with responses set up to activate on action group toggles using groups 1-10. When AGX 1.17 is installed, kOS never triggers any of those responses. When AGX 1.17 is uninstalled, kOS triggers them all just fine.

BTW, I'm using kOS 13.1 since 14 has problems with deleting half of my ships sometimes.

[Diazo]

@Wercho: AGX is an action group manager and so replaces the default KSP action groups and manages the actions directly. At the moment that means the KSP default groups never change state as AGX is taking care of it. Do you know which variable kOS is looking at? I can probably go ahead and set that for compatibility.

Note that a major update to support kOS is coming in the next version or two. At the moment any kOS support is more due to luck then anything.

Also, I can't parse what this means:

BTW, I'm using kOS 13.1 since 14 has problems with deleting half of my ships sometimes. 

You mean half your assigned actions are lost?

D.

Edited September 28, 2014 by Diazo

[Wercho]

No, I don't know what variable kOS looks at, and I don't know C# so I don't know if I can be much help finding it myself.

It sounds like the fact that AGX is preventing the default KSP groups from toggling is the issue. I don't know if this is an easy fix or if it makes sense to just wait for the big compatibility update. You've been doing a lot of work getting the save and load functionality of this working, so I don't want to put pressure on you. I'll ask over in the kOS thread and see if I can get some info about the variables it uses.

You mean half your assigned actions are lost?

No, I mean half the ship disappears. It a kOS / KSP load/save system issue, not a AGX issue. They're aware of it over on the kOS side.

[erendrake]

@Diazo the code we have for binding to action groups in kOS is here

https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/Binding/ActionGroups.cs

    Vessel.ActionGroups.SetGroup(KSPActionGroup.Abort, true)
    Vessel.ActionGroups.SetGroup(KSPActionGroup.Custom01, true)

The code for this hasnt changed in quite some time so i cannot see it being a problem on our end.

[Diazo]

@Diazo the code we have for binding to action groups in kOS is here

https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/Binding/ActionGroups.cs

    Vessel.ActionGroups.SetGroup(KSPActionGroup.Abort, true)
    Vessel.ActionGroups.SetGroup(KSPActionGroup.Custom01, true)

The code for this hasnt changed in quite some time so i cannot see it being a problem on our end.

I was afraid of that. That is the code to activate groups via KSP's group manager and so KSP toggles the group state when that command is used. If I add that to AGX, actions will activate twice, once through KSP, once through AGX.

I'm pretty sure I need to set the Vessel.ActionsGroups enum directly, just have to remember the bit-wise logic to do that.

D.

Edited September 28, 2014 by Diazo

[Jacke]

Version 1.17b

-Add BTSM actions support.

@Jacke: This version will make it so the BTSM stuff works.

The undo stuff is new however, I can confirm that it is not working correctly and will look into it.

D.

Tested it out and indeed BTSM actions now saved. Thanks, Diazo.

At least with the Undo bug, if people are aware of it they may not suffer a gotcha from it.

[Diazo]

Version 1.17c

Version 1.17 full .zip download (Install first.)

Version 1.17c .dll file only, kOS will now show state of groups 1-10 correctly. (Install second.)

Add Toggling of default KSP actions groups for compatability.

This is for the request from kOS as seen.

@Jacke: Good to hear it. I know what is going on with the Undo, I just have to figure out a solution.

D.

[Wercho]

Wow, quick work.

This got me one step closer, but it is still missing something. If the action group isn't set to do anything (AGX has no actions tied to it), then the keypress still doesn't pass to kOS. If I set the action group to toggle something, then the keypress will pass to kOS. I'm trying to use the action groups to pass info to kOS, because it doesn't have another form of active input currently, but I don't actually want to activate anything.

Example:

Action group 1 - no actions set:

1. Print ag1 in koS -> true

2. Press '1'

3. Print ag1 in kOS -> true

But, action group 1 set to toggle a solar panel:

1. print ag1 in kOS -> true

2. press '1'

3. print ag1 in kOS -> false

It toggles correctly.

It works oddly if the action group is set to a non-toggle action, such as 'extend panel'. Also you need to wait for the panel to fully extend or retract for the state change to go through correctly. For now, I can get around this by setting action groups 1-10 to an action that executes very quickly and isn't meaningful to the program I'm running (like toggling temperature display).

[Diazo]

Hmm, that's a bigger deal. You are correct that if the group has no actions in AGX, AGX does not trigger that group state.

If there are no actions assigned to a group, I can't set that group state in KSP as that group does not exist in AGX. (In the code I work with actions as my basic unit of data, so a group does not exist until an action is assigned to it.)

At this point I'll have to ask you to wait until I do the kOS rewrite. I was able to get the previous tweak out so quickly because it was a single line of code I had to add, this is more complicated.

D.

Editor UNDO Status Update:

Default behavior on the editor undo is that when a part is recreated via undo it is a fresh part with assigned actions lost (actions in the default 10 KSP groups). AGX currently mimics this behavior and any AGX actions on a part deleted and reset with undo has its actions lost. I will investigate this but will not promise anything.

Edited September 28, 2014 by Diazo