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

[vardicd]

@vardicd: No it's not a big deal.

FltShow (and EditShow) control the visibility of AGX in those scenes. 1 is show and 0 is hide so the last time you left the flight scene you had AGX hidden is all that means.

@Diomedea: Any mods off the top of your head that you would suggest I look at? I think I know what you are getting at, but a picture is worth a thousand words and all that.

D.

okay thanks.

[JeffreyCor]

Odd.

Can you open the logging console (Alt-F2) and tell me if there are any "AGX Fail..." messages please?

D.

edit: I see you have Procedural Fairings in the screenshot, just booted up KSP and tried that mod and it worked as expected. (Although I have a different version with only 2 panels, not 4, per fairing base.)

edit the second: Okay, I'm really puzzled now. Here's a version with some logging enabled. Please go into Flight mode and select multiple parts and try adding an action. This will log a bunch of "AGX..." messages to the log. Please grab the ksp.log and either send me the entire file or copy-paste the last part of the log so I can see what is happening please.

In the debug window when assigning an action I am getting an error "[Exception]: KeyNotFoundException: The given key was not present in the dictionary."

Was writing this as you were editing it seems Will put the debug version in now

Update: I tried it a few times, both with symmetry and manual selection of parts. In all cases only 1 action gets assigned and triggered. I'll give you both a copy of AGX entries and a link to the full log so you can have anything you need. Fingers crossed I got some data that will help.

[LOG 19:20:45.313] AGX A solarPanels4

[LOG 19:20:45.314] AGX B 3||3

[LOG 19:20:45.315] AGX C Toggle Panels||Toggle Panels

[LOG 19:20:45.316] AGX E 1

[EXC 19:20:45.317] KeyNotFoundException: The given key was not present in the dictionary.

KSP.log: https://www.dropbox.com/s/8pg7fz8wbc1ajyq/KSP.log

Edited June 18, 2014 by JeffreyCor

[Diazo]

Wow, talk about your boneheaded errors.

Try this version please (Logging Enabled).

If it works, here is the Version 1.6b release .dll with the logging disabled.

First post download link updated to Version 1.6b to fix this bug.

D.

Edited June 18, 2014 by Diazo

[JeffreyCor]

Good news! It seems to be working perfect now with both symmetry and multiple selection parts assigning as they should now. As suspected this also corrected that weird cargo bay doors issue as well. Whoo hoo!

[Diazo]

Great to hear.

For the record, all it was is that I forgot to not set the default action groups when it is assigned to group 11 or higher.

So when you tried to assign the actions to group 43, the mod tried to set that action assigned to group 43 in the default groups which does not exist and so this happened. The annoying part is I remembered to limit loading the default groups to only groups 1-10, I just forgot to limit the saving of them.

And because the mod defaults to group 1 when it loads, that is what I was using for testing and so I did not see the error as the error did not happen on groups 1 to 10. It was not until you posted the screenshot and I saw you were using group 43 that I started to figure out what was happening.

Anyways, issue resolved, download in first link is updated to latest and we can lay this to rest.

Thanks for all the help and patience with this JeffreyCor.

D.

[JeffreyCor]

You are very welcome! Small errors are always the most annoying. I'm glad to have been of help in fixing the problem! I love this mod

[DMFirmy]

Okay, in 10 minutes of testing I can not replicate your report. Can you please post a more detailed step-by-step on how you are getting this error please?

Sorry for the delay in my reply... I have done a bit more testing myself and I think it may have been a conflict with another mod or something... I am using the mod now in a game with no other mods and I haven't experienced this behavior again. If I figure out the source of the issue, I will respond back here with the cause so that the conflict can be resolved or avoided for the future. Again, great mod.

[Diazo]

Sorry for the delay in my reply... I have done a bit more testing myself and I think it may have been a conflict with another mod or something... I am using the mod now in a game with no other mods and I haven't experienced this behavior again. If I figure out the source of the issue, I will respond back here with the cause so that the conflict can be resolved or avoided for the future. Again, great mod.

Have you updated to 1.6b? If you are using 1.6a or earlier and have actions assigned to an actiongroup with a number of 11 or higher, the save routine was crashing out and not finishing. This might have caused the effect you saw as saving the action assignments would crash and so when it went to save the group names it would see no actions assigned and so save blank.

If you were only using groups 1 through 10, then there is still something else going on as the bug I fixed in 1.16b does not affect the first 10 groups.

D.

[Diazo]

Version 1.7 Release

Flight Window now can anchor at the bottom of the screen: When the bottom of the Flight Window is within 20 pixels of the bottom of your screen, the window will now anchor at the bottom and move the top of the window when a resizing is required.

Monitor Toggle State: You can now monitor a group's activated state. Red=Off, Green=On, Yellow=Mixed, some actions in the group are on, some are off. Note that this defaults to off, please see end of post for reasoning. This is enabled/disabled for a group by pressing the "Show Toggle" button underneath the text box to change a groups description on the main parts selection window.

5 actiongroup views: Show only the actiongroups you wish to, so display all your lifting body actiongroups during ascent, display all your science/orbital actiongroups in orbit and then your landing actiongroups during descent.

Which actiongroups are in a given view is controlled with the "Show 1 2 3 4 5" buttons just above the keybinds button on the main part selection window. When a number is green, that actiongroup shows in that view and when the number is red it does not show.

Which view is current is controlled by the top right button on the Flight Window, it says "Group 1" by default. Click this button and then select the view you wish to use, view 1 is at the top and view 5 is at the bottom of the little pop-out that appears.

The name of each view can be changed in the Keysets window. You can also change the active view in here, or set the default view when you are in the Editor (and so do not have the Flight Window available).

On why monitoring the state of actiongroups defaults to off.

During testing, I stated with having all groups monitor their status by default, but it quickly got very confusing due to how KSP handles actiongroup.

Using a stock solar panel as an example, it comes down to the fact that the "Deploy Panel", "Retract Panel", and "Toggle Panel" are 3 separate actions, not 3 commands tied to the same action.

If you activate the "Deploy Panel" action, that action becomes active as expected. However, the "Toggle Panel" action does not.

Then, if you activate the "Retract Panel" action to stow the panels, the display now shows both the "Deploy Panel" and "Retract Panel" as active, even though the panels are stowed and you would expect them to display inactive.

Having said that, if you only use the "Toggle Panel" action, the actiongroups state does behave as you would expect so it does make sense when used like that so I left the ability in for you to turn it on if you wish.

Remember: The state of an actiongroup reported by the toggle monitoring function only displays as you expect when you only use the toggle action. If you use a deploy or retract action, do not enable the state monitoring as it will report the wrong information.

[Diazo]

Okay, version 1.7 is out with some of the UI changes that have previously been discussed.

Some of the other changes discussed were looked at but discarded.

Change the Skin/Font: A lot of work would be required to do this so it is off the table for now. (A lot of work in this case being having to rewrite about 40-50% of the mod.) Does not mean it will never happen, but very unlikely at this point.

Colors for different actions: I looked at this and it changed during the development. The different colors for different types of actions (engines/science/etc) morphed into the actiongroup views and the different colors for the different actionstates (on/off) became the toggle state monitoring. At this point I think this covers what has been discussed for colors but I am open to other ways of using them if it would help with the mod.

Size of windows: Due to the way I programmed the windows, their size is hardcoded. This is one of the main reasons changing the skin/font would be such an involved process. While it will not be dynamic, I do intended to add a "wide" option so you can use longer text strings on the actiongroup descriptions if you wish. Are their any other windows people particularly want to see a different size on? It's not a huge deal to give a few optional sizes.

Are there any other UI issues people want to raise? Now is the time to do so as I am going to be adding a new window (or two) for the staging function which is up next so I'm in there messing around anyway.

On the topic of planned features, the two biggest things I'm pondering are triggering the actions on a vessel nearby that is not your current vessel and to complement this adding a list of "non-actiongroup" actions that can be added to actiongroups so you can "control" a second vessel this way. I'm not sure it is worth it however, anything simple can be done via a quick switch with [, and if you are after true control of a second vessel, there are mods out there for that.

Anyways, that is where my thoughts currently are with this.

D.

[diomedea]

Flight window. Nice the attach-to-bottom, nice the actionstate color, nice the groups .

A thought: are really two buttons needed for each actiongroup on that window? (One titled with the description assigned, another with the keybinding, but both performing the same).

I would leave one button for actiongroup, default showing description. If ever the keybinding is to be shown, it may appear as a tooltip (after a brief moment of hovering the cursor on that button), or a keypress (e.g. Alt, or Cmd) may be detected while the cursor is within the Flight window, and then the keybindings shown instead of the description.

Having just one button would give more space for the text to be displayed, so the size issue for that window may be solved.

[Diazo]

Back when I started this, I actually made the deliberate choice to put the keybinding on a separate button like that for two reasons:

1) I wanted to be able to see the keybinding at a glance. Having myself become confused on which action I've assigned to what group when I just had the base 10 groups available, I've now gone and made it more difficult to keep things straight by adding both more actiongroups and the ability to change keybindings with keysets. So for me personally, I want to have the keybindings always visible like they are.

2) It is on a separate button because if I did a text string combining the group name with the keybinding, the longer group names would push the keybinding off the right side of the button so you could not see it.

Having said that I can see why not everyone would need it showing all the time. Should be straightforward to add a show/hide option.

Also, looking at the keybind button it is a little wider then it needs to be for what it displays. (I'm going to size it so 'Numpad0' just fits, the 'Alpha0' and individual letters are both smaller then that.)

I'm still planning to add the 'wide' option as well so that should take care of the Flight Window from a UI perspective I think.

D.

[kiwiak]

i think i will switch to this from action groups manager

[diomedea]

It may require further testing, but till now it seems the Toggle State is lost across stages and vessels switching. Or, it is not persistent.

Doing some effort to put the State correctly (reflecting the part actual situation), so to show green when active, red otherwise. After a staging command, or a vessel switch, all states with AGX show red (so, have to re-sync them with the relevant parts).

[Diazo]

It may require further testing, but till now it seems the Toggle State is lost across stages and vessels switching. Or, it is not persistent.

Doing some effort to put the State correctly (reflecting the part actual situation), so to show green when active, red otherwise. After a staging command, or a vessel switch, all states with AGX show red (so, have to re-sync them with the relevant parts).

Odd, my first guess would be vessel switching as I don't interact with the staging at all.

That means I never tested the staging stuff so of course that's where the problem is going to be....

Taking a look now.

D.

edit: Wow, it is staging. It looks like all groups reset to deactivated when I stage. Odd.....

edit2: Oh, it's when the part count of the ship changes. That is something I do interact with for other reasons, you have to love code that does extra things don't you?

Edited June 30, 2014 by Diazo

[Diazo]

Version 1.7a release. (Download in first post.)

Fix Toggle state not saving correctly.

This was a bit of a sideways bug. When the part count on a ship changes, the action list gets refreshed so that parts that fell off are removed and parts that are docked to get added to the list.

However, when this happened the Toggle State was loading from when you switched to the vessel. Effectively the state was never updating as it always saved the same state as when you started flying that vessel and any changes made during that flight were lost.

There were a couple other conditions that could cause this as well that are now also fixed.

Let me know of anything else that comes up.

D.

[diomedea]

I continue to have issues when switching vessels, even with the latest version. No error logged.

But perhaps I am beginning to find a pattern about the toggles actionstate.

If I alternate two different vessels, each with similar AGs defined, those AGs that are set as toggles (with parts that allow also set and reset commands beyond the toggle) are scrambled in the switch; also, some AGs that are peculiar of only one vessel, are blanked (lose their action definitions, though keeping the names) when switching over. AGs with parts that only have the toggle command seem to always work fine, however.

So, I kept re-syncing all those toggle AGs with the correct state of the relevant part after switching, only to find - again - the AGs reversed with the other vessel when switching back. In the end, left those toggle AGs as they were appearing with one vessel (reversed from the switch); and when switching back to the first vessel, those AGs were in the correct state!

Hope the above is clear enough and could be of help. Like if the state of the AGs is not aware there are different vessels (each one with a different situation). If that is because AGX gets confused with parts that have multiple commands, the solution may require to read the state from the vessel definition ingame (as the state with all parts is actually persistent, and is restored when switching to the vessel).

Other issue: the Flight window still "flies" (does not stick to the bottom and keeps its position based on the top of the rect) when switching vessels. In case it helps, I use KSP in a borderless window of 1920 x 1080. I move the Flight window as far down as possible while flying a vessel, but there is no sign it gets stickied.

[Diazo]

@diomedea: I'll look into the switching vessels thing some more. Something to do with the values not holding correctly when you switch vessels probably. I have to handle that differently then loading a fresh flight scene because KSP does not save when you switch between two vessels using [ and ], so I have to "semi-save" the state of everything manually.

I assume from your description that when you switch to another vessel outside of physics range via the map, (or space center -> tracking station) everything works as expected?

On the flight window, are you going from a larger to a smaller window when switching? I'm actually cheating on this bit, I don't actually change the anchor position, I just fake it based on the location of the bottom of the window. But when switching it destroys and draws a new window and so bypasses my check. Simple enough fix now that I know about it.

@Alshain: Glad to have you on board. The mod is supposed to load actiongroups assigned to KSP's default groups automatically to make the transition smooth but please let me know of any issues and I'll get them fixed up for you.

D.

[diomedea]

@diomedea: I'll look into the switching vessels thing some more. Something to do with the values not holding correctly when you switch vessels probably. I have to handle that differently then loading a fresh flight scene because KSP does not save when you switch between two vessels using [ and ], so I have to "semi-save" the state of everything manually.

I assume from your description that when you switch to another vessel outside of physics range via the map, (or space center -> tracking station) everything works as expected?

On the flight window, are you going from a larger to a smaller window when switching? I'm actually cheating on this bit, I don't actually change the anchor position, I just fake it based on the location of the bottom of the window. But when switching it destroys and draws a new window and so bypasses my check. Simple enough fix now that I know about it.

My tests till now were done switching two crafts via the map (though, the issue shows also going through the space center); also the issue shows switching by using the targetron mod (but I guess that gives control of crafts just the same way as right-clicking them on the map). So, have to say switching via the map is not working as expected. Never tried yet with two vessels within physics range. In case it may help, please suggest some specific situations to be tested.

Also, have to correct myself about the parts presenting the issue. I had solar panels keeping the state consistent across vessel switching (while other parts had the AGX state reversed), but solar panels also have a similar arrangement of commands (set, reset, toggle) than those other parts. So, it may be the state is kept consistent if - by design or luck - both vessels had the same situation for those parts. Can't say what, if those parts have to be on exactly the same AG with both vessels, have to be in the same state (with both vessels set or both reset), the two conditions together, or else.

Flight window: yes, the issue happens when switching from a vessel with lots of AGs shown (long window) to a vessel with less AGs (smaller window).

[Diazo]

Okay, that gives me some more avenues to explore on the toggle issue. I'll have to look into in and get back to you as your second report means what I thought was happening isn't.

I'll probably throw the flight window in there first, it's a quick fix.

Will see what I can get done after work tomorrow. (Was a long weekend for Canada day up here, don't get this much time in to work on this usually.)

D.

[Diazo]

My tests till now were done switching two crafts via the map (though, the issue shows also going through the space center); also the issue shows switching by using the targetron mod (but I guess that gives control of crafts just the same way as right-clicking them on the map). So, have to say switching via the map is not working as expected. Never tried yet with two vessels within physics range. In case it may help, please suggest some specific situations to be tested.

Also, have to correct myself about the parts presenting the issue. I had solar panels keeping the state consistent across vessel switching (while other parts had the AGX state reversed), but solar panels also have a similar arrangement of commands (set, reset, toggle) than those other parts. So, it may be the state is kept consistent if - by design or luck - both vessels had the same situation for those parts. Can't say what, if those parts have to be on exactly the same AG with both vessels, have to be in the same state (with both vessels set or both reset), the two conditions together, or else.

Flight window: yes, the issue happens when switching from a vessel with lots of AGs shown (long window) to a vessel with less AGs (smaller window).

Okay, I am unable to replicate either the issue with the toggle states not saving correctly and with the action groups going wonky on tests with multiple different stock parts. Are the parts you having issues with from mods? It may be they are treating actiongroups differently then squad does on their stock parts.

Can you check the log (alt-f2) to make sure there are no errors being thrown and can I get a copy of your persistence.sfs file so I can check the data is being saved correctly?

D.

edit: Looks like Targetron is not an issue, it seems okay on my end.

edit2: Before switching, you are waiting for any animations to finish? My mod toggles an actiongroup state from inactive to active (or vice-versa) immediately on keypress, but the actual state does not change until the animation finished playing. On the solar panels I test with, if you switch before they fully deploy, they will be stowed and inactive when you switch back to the vessel, but my mod will think they are active.

Edited July 3, 2014 by Diazo

[diomedea]

Okay, I am unable to replicate either the issue with the toggle states not saving correctly and with the action groups going wonky on tests with multiple different stock parts. Are the parts you having issues with from mods? It may be they are treating actiongroups differently then squad does on their stock parts.

Can you check the log (alt-f2) to make sure there are no errors being thrown and can I get a copy of your persistence.sfs file so I can check the data is being saved correctly?

D.

edit: Looks like Targetron is not an issue, it seems okay on my end.

edit2: Before switching, you are waiting for any animations to finish? My mod toggles an actiongroup state from inactive to active (or vice-versa) immediately on keypress, but the actual state does not change until the animation finished playing. On the solar panels I test with, if you switch before they fully deploy, they will be stowed and inactive when you switch back to the vessel, but my mod will think they are active.

I may have found something. This time I tested AGX on an almost clean KSP 0.23.5 install to start with. Launched two different vessels with as many different toggle commands tied to stock parts as I could. On a clean install the actionstates are preserved. Looking at the log window, noticed warning messages about AGX not saving things at launch (probably a temporary thing). But something in those messages made me have a look at the config you use with parts so to preserve data. Noticed the instruction "@PART

[*]:Final", went looking for other mods that issue similar instructions with my main install. A few do (mainly for their own parts), one struck my attention because more generally applied to any suitable part: FAR. Installed FAR on the same test environment, relaunched the same game, and now actionstates get lost! (FAR seems to apply some parameters to parts by default, though the exact cause may be different. But the effect is, FAR and AGX seem not compatible currently).

Of course the question comes: AGX really needs to place its module as "Final" ? Anyway, here are all files relevant to that test for you to see, I hope you will identify what goes on. The real cause may well be different from what I'm guessing.

If those questions above still are of interest: issue is found with both stock and mod parts; I do wait for animations to finish (actually, most parts with this issue have no animation).

[Diazo]

FAR? Odd. I'll see what FAR is doing in it's code.

That surprises me because while I don't have FAR on my dev install, it is on my for fun install and I've had no issues with it in past versions. I've had no time on my for fun install since releasing 1.7 though as real life kept getting in the way. :/

As for the partModule having to be Final, AGM does not actually care one way or another.

However, if I do not apply it as Final, I break custom animations on RemoteTech as that animation code refers to the partModule by index number, not name, and I have to add mine at the end of the list for compatibility.

Also, your link is broken. The one that is supposed to go to the files you uploaded goes to the forum thread for FAR.

D.

edit: Are you using ModuleManager 2.0 or newer? If so, does changing GameData\AGext\part.cfg as follows do anything:

@PART[*]:Final
{
MODULE
{
      name = ModuleAGExtData
	AGXData = Empty
	AGXNames = Empty 
	AGXKeySet = 0
	AGXActivated = 0
        AGXLoaded = false   <-Add this line
        AGXGroupStates =    <-Add this line
        AGXGroupStateNames =   <-Add this line
}
}

It looks like ModuleManger's invalid module cleanup routing might be wiping that data because I did not have it formatted as ModuleManager expected.

Edited July 3, 2014 by Diazo

[diomedea]

Sorry about that link: here the correct one.

I am indeed using MM 2.1.5, maybe that is part of the issue as well (noticed you keep packing MM 1.5.6 with AGX, but certainly can't use that with other mods). I'll try those instructions soon.

Yes, I had some knowledge RT2 is numbering PartModules. Can't remember now about what other mod it was discussed, but the issue was really similar.

[Diazo]

Okay. On your test adding in FAR which of these things happened?

In both cases:

Base game things work okay -> close game and install FAR -> load game and everything is screwy

Case A:

Still in the game with FAR installed, reset toggles and actiongroups and things work correctly when switching vessels

Case B:

Still in game with FAR installed, reset toggles and actiongroups and things are still forgotten when switching vessels.

If it was Case A, then I would suspect ModuleManager is the culprit and ask that you test the modified part.cfg in my post above.

If it is Case B, then the problem is not ModuleManager and there is still something else going on that I have not figured out yet.

Looking at the data files in your link, the data is saving correctly so something in the loading process is going sideways.

D.

edit: Hmmm.

[WRN 07:33:14.587] PartModule is null.
[WRN 07:33:14.588] Part mumech.MJ2.AR202 cannot load module #6. It only has 5 modules defined

This is on Test Station 1, looking at the craft file, module #6 is my AGXData module so the partModule does not load. Looking more and more like this is something to do with ModuleManager.

Edited July 3, 2014 by Diazo