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

[Diazo]

Erm, with the 1.13 rewrite it should be very tough for this mod to conflict with others as I did my best to isolate everything as much as I could.

It could certainly be happening of course, can you upload a copy of your output_lot.txt so I can see what is happening please?

I run Alarm Clock without issue on my own install, but I have not tried KCT, Time Control or Final Frontier myself but those mods don't interact with action groups as far as I am aware?

Really, the output_lot.txt will tell the story of what is going wrong.

D.

[Jacke]

Version 1.13f

Download link in that post is for v1.13e.

[Diazo]

Thanks for the catch, updated.

D.

[westamastaflash]

Erm, with the 1.13 rewrite it should be very tough for this mod to conflict with others as I did my best to isolate everything as much as I could.

It could certainly be happening of course, can you upload a copy of your output_lot.txt so I can see what is happening please?

Yeah, I wonder if it had something to do with 1.13e vs f, I apparently had E installed instead, but now the error doesn't seem to be happening anymore with F :/. It I see it again and it seems to be AGX, I will let you know.

It seemed to be crashing on the autosave... But I'm not 100% sure.

Thanks!

[Diazo]

If it is AGX it should be apparent in the output_log.

As this is the first release after the rewrite, I've gone somewhat overboard on the logging to make sure any errors were easy to track down.

I should have a chunk of time on the weekend and the adding of the ability to select parts from a list is going smoothly so I'm hopeful I can push 1.14 this weekend.

As always, no promises, adding features is quick, it's the bug hunting that takes time.

D.

[cttw]

Im having trouble with this mod. Most times it doesn't work. I am in the VAB with the actions set in the config, and the actions showing green in the list, but when I go to launch they are gone. No actions are available, but they can be reconfigured after launch, by doing exactly what I did in the VAB, and then they will work.

[Diazo]

That is really odd.

-Are you trying to assign actions to groups 1 through 10 or 11 and higher?

-If after leaving the editor, when you return to it are your actions still there?

-If you open KSP_Install\Saves\your_save, is there an AGExtEditor.cfg next to your persistent.sfs file? If so, can you upload it for me please?

-Can you please find the output_lot.txt in your KSP_Data folder (or KSP_x64_Data if you run 64 bit) and post that please? It will tell me why things are not working for you.

Thanks,

D.

[Diazo]

Version 1.14

Download

-Upgrading from Version 1.12 will lose all data, except for the Action assignments themselves on groups 1-10 (Version 1.13 data is safe.)

-Vessels do not save KeySet or Group visibility or names during dock/undock (see comment below)

-Add ability to select parts from list rather then clicking on the vessel.

-Mod now cleans up after itself and deletes old AGExt00000.cfg files automatically.

Select part from list instructions here.

Group visibility

I'm currently debating how to work this when vessels dock.

Should all actions go visible on dock?

What about when Group 2 is visible on one ship and not on another?

In other words, how to you actually use this feature?

As always, feedback requested. I'm around most of the weekend to make any tweaks required.

D.

Edited September 6, 2014 by Diazo

[cttw]

I see you have updated, I will install it again and report if the error persists.

[Diazo]

Please do.

It is a 50/50 shot if the update does fix it as nothing in the update touched the save/loading of actions but keep your fingers crossed.

If it still fails, the output_log.txt is what I really need to troubleshoot what is going on.

D.

[JeffreyCor]

Odd problem on both 1.13 and 1.14. After unlocking the UI disappears when pressing a mouse button. For example, holding the right mouse button to move the camera angle the UI turns invisible then reappears after release of the button. Quicksave -load (F5-F9) corrects it and it only happens after an undocking since 1.13 (all subversion).

https://www.dropbox.com/s/afrjfgt8f1xr2ix/output_log.txt?dl=0

[Diazo]

@JeffreyCor:

I actually don't think it is an issue with AGX.

From the error log:

ArgumentException: Value does not fall within the expected range.
  at ferram4.FARControlSys.OnDestroy () [0x00000] in <filename unknown>:0 
  at ferram4.FARControlSys.OnGUI () [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

Note the last line 'RenderingManager.OnGUI()', that is KSP's handler for rendering GUI that both AGX and FAR use, but because FAR is before me in the rendering queue, when this error is thrown by FAR it stops the rendering queue for that frame so AGX never gets the call to be drawn.

I don't know what kind of problem FAR is having that holding down a mouse button would cause it to throw a null ref error and abort the rendering manager for that frame, but because this happens before the GUI code in AGX is reached, that is why there is no error logged by AGX.

How do other mod windows behave when this happens? I know you are seeing AGX's windows vanish while this happens, but what about other mods?

Also, are you okay making a report about this in the FAR thread or do you want me to do it? This is something that ferram4 will have to fix, it's not something I have the ability too.

I'll try to recreate the error on my end to get more details.

D.

[Drew Kerman]

Upgraded from 1.11 to 1.14 and just redid assignments on one of my ships and everything seems to be working fine.

The ship in question is my first interplanetary one and I'm using signal delay with Remote Tech 2 - are there any plans to make AGX aware of RT2 signal delay? Now that RT2 development is active again you may want to look into it since Cliph just helped Athlonic get his Chatterer program interfaced with RT2 so comms would honor signal delay and connection status.

At the same time tho AGX is useful for performing actions that shouldn't require signal delay - for instance selecting the view from one of my cameras, or opening my service bay to click on things inside. So it should probably be an option you can select for each action group individually.

[cttw]

I'm currently debating how to work this when vessels dock.

Should all actions go visible on dock?

What about when Group 2 is visible on one ship and not on another?

In other words, how to you actually use this feature?

D.

I don't know if you can do this, but how about you bind it to the command pod that is controlling the ship? Say a lander with a cockpit and a probe controlled docking interplanetary section. Right click the lander cockpit, control from here gives you the lander's actions. Controlling from the probe gives the probe section actions.

[cttw]

Hi, the problem persists and is worse than I first thought. It happens about 50 percent of the time, without changing anything on my pattern. You can lose the settings going from the Hangar to the runway, and also when it does works in the runway you can lose them by reverting to the hangar. It seems to happen more in the hangar than in the VAB.

I created a new sandbox save, made a plane with cockpit, 1 tank and 2 radiators. Then I set the radiators to toggle with a key using your mod. Radiators seemed to be what caused more trouble in my experience. Often the radiators would not be working but the engine action keys did work.

With this setup, about half the times it loses the settings on the radiators when launching, and sometimes they work on launch but you lose them when reverting to hangar. Some rare times they will both work on launch and will still be there when reverting to hangar. Additionally, this mod will prevent me from using the old-style action groups, even when configured, so I need to remove it to play. But I am looking forward to keeping it in.

I play the 64 bit on Linux. I have no other issue with my mod mix, except this action group problem. My game does not produce a file named output_lot.txt that I could find. The radiators/engines are KSPI Lite.

Here is my AGExtEditor.cfg: http://pastebin.com/Cbp7Sv1H

[Diazo]

@Gaiiden: Both RemoteTech and kOS support are planned. However integrating with both of those mods will probably require me to coordinate with their developers and I have my hands full getting AGX up to 100% at the moment.

@cttw: For the Groups visibility thing, that is what my current thinking on how to approach it is.

edit: Removed original problem suggestion and replaced with below.

Looking at the editor file, I see I made an oversight.

When a rocket (VAB) and a spaceplane (SPH) are name the same, AGX will always try loading the rocket (VAB) action groups.

On the planes you are having issues with, can you try renaming them to something else (Change Rocketparts Refill to Rocketparts Refill SPH or similar).

Looking at the AGXEditor file you linked, the 'Rocketparts Refill' and 'Untitled Space Craft' spaceplanes will try to load the actions assigned to the rockets named the same and so mostly fail, except sometimes the part line up close enough for AGX to find them and so you see this where sometimes a few of the actions on the craft load.

I'll add detection for what kind of vessel is launching in the next version, but for now the workaround is to make sure your spaceplanes and rockets have different names.

The catch is that this does not explain the actions being lost upon reverting to editor. When you revert to the editor the above comment about names does not apply, the actions should be the same as when you hit the Launch button to leave the editor. (Note that any changes to actions made on the runway will be lost as AGX is unable to bring changes over that way.)

D.

Edited September 7, 2014 by Diazo

[Nori]

@JeffreyCor:

I actually don't think it is an issue with AGX.

From the error log:

ArgumentException: Value does not fall within the expected range.
  at ferram4.FARControlSys.OnDestroy () [0x00000] in <filename unknown>:0 
  at ferram4.FARControlSys.OnGUI () [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

Note the last line 'RenderingManager.OnGUI()', that is KSP's handler for rendering GUI that both AGX and FAR use, but because FAR is before me in the rendering queue, when this error is thrown by FAR it stops the rendering queue for that frame so AGX never gets the call to be drawn.

I don't know what kind of problem FAR is having that holding down a mouse button would cause it to throw a null ref error and abort the rendering manager for that frame, but because this happens before the GUI code in AGX is reached, that is why there is no error logged by AGX.

How do other mod windows behave when this happens? I know you are seeing AGX's windows vanish while this happens, but what about other mods?

Also, are you okay making a report about this in the FAR thread or do you want me to do it? This is something that ferram4 will have to fix, it's not something I have the ability too.

I'll try to recreate the error on my end to get more details.

D.

I'm actually having the exact same issue. Ran across it just as I was deorbiting into kerbin. I know this doesn't really help you, but this didn't happen with FAR before installing AGX. Of course it could still be a FAR issue and FAR just isn't playing nice with AGX. Can provide logs if it helps.

[Diazo]

Okay, for those who are seeing the AGX windows vanish sometimes on mouse down and then return on mouse up, please try the AGExt.dll file here.

I tweaked the render settings to hopefully work around the issue.

This is the issue as reported by JefferyCor and Nori.

D.

edit: I've posted this over at the FAR thread to get the root cause fixed.

edit2: Looks like it is a previously reported issue and already fixed for the next version of FAR.

Edited September 8, 2014 by Diazo

[Drew Kerman]

hey cool, glad to know it's in the pipeline. Hadn't even thought about kOS support, that would be sweet as well.

[jonrd463]

Hi Diazo. First, let me say that all of your mods are absolutely indespensible. They've helped me in more ways than one, including successfully winch-lowering a rover from a sky crane a la Curiosity.

I seem to be having a problem with the latest version of this one. Whenever I add a description to an action, it goes away when I switch ships. The assignment is still there, only the description disappears. I'm always open to the notion that I'm doing something wrong, but if it helps, here are the steps I take:

For vessels on the launchpad/runway/in flight:

1. Click AGX in the toolbar.

2. Click Edit button in the Actions window.

3. Select a number in the 1-50 list that pops up for Group 1

4. Select part on ship (example: Karbonite drill)

5. Select action(s) in the AGExt Selected Parts window, in this case, Deploy Drill and Begin Extraction.

6. Enter "Deploy & Extract" in description box. It appears in the main action list window of AGX.

7. Click Edit button in the Actions window again to close the editor windows.

At this point, all looks well. Then whenever I switch to another ship or go to the space center, the descriptions are gone when I switch back. Is it possible I'm missing a step?

[Diazo]

@jonrd463: You have covered every step and it should save.

Can you upload your output_log.txt please? That will show me any errors AGX is logging to let me track down what is going on.

From information in your description of the problem, the only guess I can make is the '&' symbol is throwing things off. Have you tried a group name without the & symbol? As AGX saves text strings, a & in there should not be a problem, but it is not something I have actually tested so it is a possible culprit.

Any further troubleshooting will have to wait until you can get me your output_log.txt.

D.

[JeffreyCor]

@JeffreyCor:

I actually don't think it is an issue with AGX.

From the error log:

ArgumentException: Value does not fall within the expected range.
  at ferram4.FARControlSys.OnDestroy () [0x00000] in <filename unknown>:0 
  at ferram4.FARControlSys.OnGUI () [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()
  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

Note the last line 'RenderingManager.OnGUI()', that is KSP's handler for rendering GUI that both AGX and FAR use, but because FAR is before me in the rendering queue, when this error is thrown by FAR it stops the rendering queue for that frame so AGX never gets the call to be drawn.

I don't know what kind of problem FAR is having that holding down a mouse button would cause it to throw a null ref error and abort the rendering manager for that frame, but because this happens before the GUI code in AGX is reached, that is why there is no error logged by AGX.

How do other mod windows behave when this happens? I know you are seeing AGX's windows vanish while this happens, but what about other mods?

Also, are you okay making a report about this in the FAR thread or do you want me to do it? This is something that ferram4 will have to fix, it's not something I have the ability too.

I'll try to recreate the error on my end to get more details.

D.

All mod windows remain viable normally, only the parts that vanish are stock. I have found something interesting in the behavior only seems to occur when one of the ships that dock together had a Station Science part on it. Ships that don't have one from that mod do not exhibit this problem. Maybe some weird freaky interaction, possibly even caused by Station Science that hasn't popped its head up till now.

[Diazo]

@JefferyCor: Is this with the 1.14 version of AGX or with the tweaked .dll file I linked a couple posts back?

Also, to clarify

All mod windows remain viable normally, only the parts that vanish are stock.

means that other mod's GUI Windows remain viable, it is the stock KSP GUI windows that vanish?

If so, that increases the chances that the tweaked .dll will fix this problem.

D.

[Alvin853]

Maybe I'm stupid, but how do I change the preset action groups: gears, brakes, lights, abort etc.?

[Diazo]

In the editor, click the AGX button on the toolbar to show the KSP default action groups editor with those groups.

In flight, there is no way to do so. Is that something you actually want to see? I did not include those because those are things I did not expect people to want to change after leaving the editor.

D.