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

[Diazo]

It's currently in the queue.

I'm working on the next version which will include the momentary action groups at the moment. I currently have my head buried in some remotetech compatibility stuff, but it is coming.

D.

[somewhatcasual]

I am having an issue where my action groups are replicating at some point, either after saving or launching and reverting to SPH. I am having to re-do my actions quite frequently during build and test phase of my ship design. Is this a know bug or mod conflict? I'm running mostly USI , and KSPI extended for parts, and the vast majority of the other mods are ones that affect gameplay mechanics, such as your mods or tacls as examples. Any help is greatly appreciated. Thanks

[novahike999]

Could you post some screenies? I think you may be getting confused with some of the features like I did. Although it could be a problem similar to a one that I had if you're loading up vehicles that had action groups assigned before you installed the mod.

[somewhatcasual]

Could you post some screenies? I think you may be getting confused with some of the features like I did. Although it could be a problem similar to a one that I had if you're loading up vehicles that had action groups assigned before you installed the mod.

I always clear out the parts when assigning a new action group, so it's not like I'm leaving parachutes in my assignment when working with thrusters. A clearer example would be that I have 8 Attila thrusters from kspi assigned To toggle on/off. I notice after launching that not all of them are toggling. Revert to sph and check the ag and see that instead of 8 toggles there are 29 Attila thrusters( only 8 Attila parts are on the craft) set to toggle, so some are toggling multiple times and as a result, just not working after launch.

I can try for a screen shot later after I get home from work. Given the issue, I am not sure it will be too helpful.

https://www.dropbox.com/s/gzk1xox84hcbzp6/Screenshot%202015-02-23%2020.26.06.png?dl=0

As you can see, from the parts list I selected the ATTILA, which I only have 8 attached to my craft, and yet the actiongroup has populated itself with 30 of the them, and this completely screwed up my flight, hence my finding it. Weird!

Edited February 24, 2015 by somewhatcasual
Link

[Diazo]

That sounds like the action in question is odd in some way and AGX is having problems handling it.

Notably "I notice after launching that not all of them are toggling." is a red flag there is an error somewhere.

Can you replicate and get me a copy of your output_log.txt please? AGX should be logging the errors in there.

D.

[somewhatcasual]

That sounds like the action in question is odd in some way and AGX is having problems handling it.

Notably "I notice after launching that not all of them are toggling." is a red flag there is an error somewhere.

Can you replicate and get me a copy of your output_log.txt please? AGX should be logging the errors in there.

D.

I will post a dropbox link as soon as I reproduce it. I actually re-installed everything fresh after the latest KSPI extended update, so hopefully you don't hear back from me.

[Drew Kerman]

Diazo I noticed a stutter in my framerate every other second or so and opened up the log to find I have a lot of exceptions for you to look at. Log.

Let me know if you need any contextual info.

Latest version installed

[Diazo]

@Gaiiden: I see the error you are talking about and I'm not sure what to make of it.

In the output log you have attached, I see you visited 3 flight scenes. That is you switched from the track station to flight mode (to ComSat Mun II), then to a vessel far enough away it was outside physics range (ComSat Mun III), then to a 3rd vessel again outside physics range (ComSat Mun I). I can't tell if you switched between nearby vessels within the same scene.

Can you remember which of those scenes the stuttering was in? AGX was only throwing errors in the third scene (on ComSat Mun I), if it was during the first scene that was actually VOID throwing the errors (on ComSat Mun II).

If it was in the second scene (ComSat Mun III), I'm not sure what to say as there are only a few errors in the log for that scene as compared to the 1st or 3rd scene where the log is being spammed with errors.

Looking at the error, can I ask you to open your most recent AGExt#####.cfg file and check that all the PART nodes on the ComSat Mun I vessel and make sure the "flightID" field has a number string in it? You can search the file for the name "ComSat Mun I" to easily find the correct vessel.

My first guess is that it looks like that flightID field is invalid somehow, either it has non-numeric characters in it, or it is blank (or missing).

D.

Edited February 24, 2015 by Diazo

[Drew Kerman]

Looking at the error, can I ask you to open your most recent AGExt#####.cfg file and check that all the PART nodes on the ComSat Mun I vessel and make sure the "flightID" field has a number string in it? You can search the file for the name "ComSat Mun I" to easily find the correct vessel.

My first guess is that it looks like that flightID field is invalid somehow, either it has non-numeric characters in it, or it is blank (or missing).

It's missing. Completely. I get no hits when I search for it. I see II and III, but nothing for I

[somewhatcasual]

I will post a dropbox link as soon as I reproduce it. I actually re-installed everything fresh after the latest KSPI extended update, so hopefully you don't hear back from me.

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

ok it happened again. Doubling of AG's and AG's that are getting mix and matched on their own to other assigned AG's. I've been saving and testing and reverting ad nauseum. I hope this is helpful!

Thanks for looking

[Diazo]

@Gaiiden: That is odd. Are you saying that the vessel itself is missing completely, or that the vessel is there, there are just no PART nodes?

@Ssomewhatcasual: That you for that, taking a look now.

D.

[Drew Kerman]

@Gaiiden: That is odd. Are you saying that the vessel itself is missing completely, or that the vessel is there, there are just no PART nodes?

There are no results for "ComSat Mun I" (txt file)

[Diazo]

Version 1.30i test release

1.30i download

Remotetech users:

1) Download RT 1.6.3 from the official thread.

2) Install RT development version 1.7.0 .dll here. I am working with the RT guys and this is the official in-progress version of RT. I have permission to release this so AGX works with RT until the official 1.7.0 release comes in a bit. Note that as this is the in development version please make sure you indicate that if you talk to the RT guys yourself while using this .dll file.

To be clear, AGX 1.30h and earlier work with RT 1.6.3 as downloaded. Only AGX 1.30i and newer required the linked .dll file. With AGX 1.30i and the in development 1.7.0 RemoteTech, you can now queue commands to the flight computer.

-Fix Karbonite/Regolith actions probably not saving correctly for most people

-Flight ID workaround.

@somewhatcasual: I was not able to replicate the Attila engine error, but in your log your Karbonite actions were not saving correctly and this release fixes that. One oddity I noticed was you were hitting the cooldown queue quite often. Can you open your log and confirm that those messages are actually printing when you try and activate the action group please? And are you activating the group with your keyboard or the mouse? "AGX Action not activated, that group still in cooldown" is the exact message that will appear in the log when you hit the cooldown queue.

@Gaiiden: That is odd. My next suspicion is that the "unique" identifier has been re-used so that AGX is trying to load the actions from an old vessel that no longer exists. Version 1.30i has a work around, if it hits that error again rather then crashing out like it has, it will discard that action and move on to the next one. You will still lose that action, but everything else, including other actions in AGX, should work normally. To confirm this, I would need the .sfs file that goes with the AGExt#####.cfg file you linked me above.

D

Edited February 25, 2015 by Diazo

[Drew Kerman]

@Gaiiden: That is odd. My next suspicion is that the "unique" identifier has been re-used so that AGX is trying to load the actions from an old vessel that no longer exists. Version 1.30i has a work around, if it hits that error again rather then crashing out like it has, it will discard that action and move on to the next one. You will still lose that action, but everything else, including other actions in AGX, should work normally. To confirm this, I would need the .sfs file that goes with the AGExt#####.cfg file you linked me above.

I've got enough potential issues with my install (you've seen all the exceptions ) to not want to bother with a dev version of a mod so I'll wait for 7.0 release to try out your workaround but here is the persistence file for you to look at. You may be able to help me with a possibly related issue - I have no idea how the UID for one of my flags got set to all zeroes (AFAIK that was its initial value). The game hasn't seemed to make any big deal about it but that could be something to send things sideways

[Diazo]

@Gaiiden: Thank you for the persistence file. I can confirm it is in fact an issue where the "unique id" is not unique. I use the "flightID" value of the root part of a ship to identify it, looking at your persistent.sfs file, both Comsat Mun I and Comsat Mun II have the same FlightID on their root part so AGX thinks they are the same vessel.

As they are not the same vessel, this causes problems.

The best workaround I can offer if you want to stay on AGX ver. 1.30h is to go into the latest AGExt#####.cfg file and delete the "2827088109" node. That means all actions on both ComSat Mun I and ComSat Mun II will be lost, but at least the vessels will load okay. Then use action groups 1 to 10 only for those two vessels, those groups will still work as AGX will use the base 10 groups in KSP itself for them.

D.

[Drew Kerman]

yea that's a fine fix. I generally don't even need action groups for these two vessels anyhow. Thanks

[novahike999]

Is there any point in downloading this new version if I don't use remote tech?

[somewhatcasual]

Version 1.30i test release

@somewhatcasual: I was not able to replicate the Attila engine error, but in your log your Karbonite actions were not saving correctly and this release fixes that. One oddity I noticed was you were hitting the cooldown queue quite often. Can you open your log and confirm that those messages are actually printing when you try and activate the action group please? And are you activating the group with your keyboard or the mouse? "AGX Action not activated, that group still in cooldown" is the exact message that will appear in the log when you hit the cooldown queue.

D

I don't receive messages on the screen in game, aside from no target on occasion. I had no idea things were going into cooldown. I use my keyboard the majority of the time. I'll try the updated .dll, and see what shakes loose.

[Diazo]

@novahike999: If you do not use remotetech and you are not experiencing any issues, you don't need to worry about updating. I increment the number (and update other hosts such as CKAN) when I add new features. Version with the letters on the end are bug-fix releases where I'm fixing problems. Normally the Remotetech change in version 1.30i would have been enough for its own version number, but I technically released Remotetech functionality with version 1.30 so it does not in this case.

@somewhatcasual: The message about the queue would not be on-screen, but in the output log that can be enabled via Alt-F2. It has the same contents of the output_log.txt file, just it shows it in-game in real time. The fact that you use the keyboard means that the cooldown queue being hit is probably working as intended. KSP has an annoying bug where for a single press of a keyboard key in real life, it will pass that key press multiple times to AGX, so I have to have a cooldown that an action group can not activate more then once in a given time period. (It's about 1/10th of a second by default.)

Notably, the queue is per action group, not per action, so only some actions in an action group activating would not be explained by hitting this queue at the wrong time. This means I'll have to run some more tests tonight to see if I can figure out why the Attila engines are not behaving for you.

I ran out of time last night to do any extensive testing as I was fixing the errors with Karbonite that were also in your output_log, but I'll look at the Attila's first thing tonight.

D.

[somewhatcasual]

@novahike999: If you do not use remotetech and you are not experiencing any issues, you don't need to worry about updating. I increment the number (and update other hosts such as CKAN) when I add new features. Version with the letters on the end are bug-fix releases where I'm fixing problems. Normally the Remotetech change in version 1.30i would have been enough for its own version number, but I technically released Remotetech functionality with version 1.30 so it does not in this case.

@somewhatcasual: The message about the queue would not be on-screen, but in the output log that can be enabled via Alt-F2. It has the same contents of the output_log.txt file, just it shows it in-game in real time. The fact that you use the keyboard means that the cooldown queue being hit is probably working as intended. KSP has an annoying bug where for a single press of a keyboard key in real life, it will pass that key press multiple times to AGX, so I have to have a cooldown that an action group can not activate more then once in a given time period. (It's about 1/10th of a second by default.)

Notably, the queue is per action group, not per action, so only some actions in an action group activating would not be explained by hitting this queue at the wrong time. This means I'll have to run some more tests tonight to see if I can figure out why the Attila engines are not behaving for you.

I ran out of time last night to do any extensive testing as I was fixing the errors with Karbonite that were also in your output_log, but I'll look at the Attila's first thing tonight.

D.

Oh. yea I really have to try to spam it for the message to appear in the log. I have the part.sethighlight exception message spamming on repeat otherwise

[Diazo]

@somewhatcasual: Okay, I just tried to replicate the error with the attila engines and was unable to. If the issue happens again on version 1.30i, can you post your output_log.txt as well as your persistent.sfs, AGExtEditor.cfg and AGExt######.cfg files please? (Those last 3 files will be in KSP_Install\saves\GameName\persistent.sfs directory.) I only need the AGExt#####.cfg file with the highest number.

Hopefully that will give me enough to go on to figure out what is happening.

Note that there is a chance that fixing the Karbonite errors I did in 1.30i may also fix the errors with the attila's. It's only a 50/50 chance it did, but if you can't replicate the error that would be the reason.

D.

[Yemo]

That is a really great mod!

One small request: Could you put your settings in the AGExt.cfg within a top node?

AGExtSettings
{
name = AGExtSettings

[...]

OverrideCareer = 0
}

It would allow the easy creation of a modulemanger config to change them.

That way, players could keep their private settings without file handling/resetting in case of an update.

It would also allow other mods (like my SETI-BalanceMod, link in signature), to set OverrideCareer = 1 per MM statement.

Thank you very much!

Edited February 26, 2015 by Yemo

[Diazo]

That is an interesting thought, but I don't think it would work.

The AGExt.cfg file is loaded directly by AGX when AGX loads, so at the start of the flight and editor scenes.

ModuleManager runs while KSP is loading and then terminates when KSP reachs the main menu.

As AGX does not use KSP's built in loader, I don't think MM can affect the config file this way.

I'd be up for doing this if it does work, but at the moment I don't see how it can.

D.

[Yemo]

That is an interesting thought, but I don't think it would work.

The AGExt.cfg file is loaded directly by AGX when AGX loads, so at the start of the flight and editor scenes.

ModuleManager runs while KSP is loading and then terminates when KSP reachs the main menu.

As AGX does not use KSP's built in loader, I don't think MM can affect the config file this way.

I'd be up for doing this if it does work, but at the moment I don't see how it can.

D.

Thank you for the consideration, then it is the same problem as with KerbalMass.

Can you somehow delay the AGX loading until after the mm patches?

As far as I can see, time of loading should not affect AGX functionality, as long as it is before loading a savegame/starting a game.

There are quite some configs accumulating,

from AGX to KerbalMass, RemoteTech, TAC life support, and so on.

It would be great if those could be controlled by MM, making the update process much easier and allowing the distribution of micro mm patches.

Eg an mm file that sets AGX to non-career, RemoteTech to no-time-delay, KerbalMass to something that floats with Better Buoyancy and so on.

[Crzyrndm]

The AGExt.cfg file is loaded directly by AGX when AGX loads, so at the start of the flight and editor scenes.

Can you somehow delay the AGX loading until after the mm patches?

The problem is not when he loads it, but how he loads it. Module Manager applies patches to ConfigNodes in GameDatabase. Anything that loads through GameDatabase is almost guaranteed to be ModuleManager compatible. Diazo is not using GameDatabase to load his settings, he's reading the file from the hard drive when he needs it. This is why MM can have no effect on his settings file.

@Diazo

The best way I found to do this is to load the settings file into an object the first time you enter the main menu that persists while the game is running. Thus it is affected by MM and persistent between flights and saves. Any changes made you write to that object and to hard drive (or rather, update the object and then save it).

You can see this approach here where I have a class handling all my presets for Pilot Assistant.

GameDatabase.Instance.GetConfigNode(string url) would be the load function needed for AGX I believe

Edited February 27, 2015 by Crzyrndm