[1.12.x] DefaultActionGroups v1.4: Part actions automatically in the action group of your choice.

[fourfa]

On 5/5/2016 at 9:10 AM, Snark said:

2. Scenario:  Same as above, but ModuleManager happens to read Muddr's config after DefaultActionGroups has already processed, so Muddr's stuff doesn't get picked up.  Action required:  Copy the existing DAG config (which I link to above) to a new file, and on the first line add an "AFTER" clause to force it to process after Muddr's mod.

This.  It's using ModuleAnimateGeneric and ToggleLights across the board, but it doesn't currently work with standard DAG.

Would you mind being a bit more specific about the action required?  Somehow I doubt you meant to literally just throw the word "AFTER" in the first line, but I haven't the foggiest idea what else that might mean.

Sorry, this is literally my first time looking at the syntax of the code in these cfgs.  And kinda funny, googling 'kerbal "after clause"' only returns this exact thread

Edited May 7, 2016 by fourfa

[Snark]

22 hours ago, fourfa said:

Would you mind being a bit more specific about the action required?  Somehow I doubt you meant to literally just throw the word "AFTER" in the first line, but I haven't the foggiest idea what else that might mean.

Sure.  By the way, for your reference, there is some pretty good ModuleManager documentation with lots of examples, located here and here.  You can do some pretty amazing things with it, but the syntax can sometimes be a bit arcane.

The syntax you'd want would start with a line like this:

@PART[somePartName|someOtherPartName|andAnotherPart]:NEEDS[DefaultActionGroups]:FOR[TheNameOfTheModFolder]

...where you just string together all the parts you want to tweak with | characters, and "TheNameOfTheModFolder" is whatever folder under GameData that Muddr's mod gets installed into.

The above syntax assumes that you have a specific list of parts you want to work with.

The other approach is to try to specify the parts "procedurally" using wildcards rather than list them all one by one.  That has the advantage of being more "robust" (will automatically pick up new stuff, if it gets added), but can be tricky sometimes.

For example, if you wanted a procedural filter, you'd need to come up with some expression that would basically be "find every part that has ModuleAnimateGeneric with a 'Toggle Lights' GUI action, but which doesn't already have ModuleDefaultActionGroup added to it (by the DefaultActionGroup mod itself).  It's probably possible to concoct such a filter in MM... but unless you're more of a MM guru than I am, it'll take a lot of trial-and-error, restart-KSP-a-zillion-times debugging to figure out how to make it work, and for your use case I'd say it's probably not worth the bother.  Just collect the names of the parts you want to work with and string 'em together, it's simple and should work.

[fourfa]

The specific list of parts should work, it's only seven.  Where does that patch need to go?  Top level of GameData?  Or inside the MuddrMods folder under GameData?  Or that line inserted into each cfg patch inside the mod subfolders?

I've tried it a few ways so far, and nothing happened.  I also tried an AFTER patch a few ways, and also nothing happened.

Edited May 8, 2016 by fourfa

[Snark]

8 minutes ago, fourfa said:

Where does that patch need to go?  Top level of GameData?  Or inside the MuddrMods folder under GameData?  Or that line inserted into each cfg patch inside the mod subfolders?

I've tried it a few ways so far, and nothing happened.  I also tried an AFTER patch a few ways, and also nothing happened.

It can go anywhere, as long as it's somewhere within GameData.

A suggestion:  Make yourself a folder in GameData named "000_fourfa" and put all your ModuleManager .cfg files in there.  (The "000" is to make it come alphabetically first, for your own convenience in finding things.)

By putting all your configs in one spot like that, you make them easy to find, and also you don't have to worry about them getting munged if you delete some other mod somewhere.

[Cultist_O]

I'm a little late to the call to arms about suggesting optional configs, but hopefully you are still considering?

Antennae and dishes in customX?

It's worth noting that remoteTech uses MM to add stuff to antenna animations as well, so hopefully this can be done without a compatibility issue. (It also adds a static antenna, not sure if that matters)

[Muddr]

I'll look into this more.  I made it as stock as possible, so it copies how porkjet did it, then I have MM replace the stock models with mine..  I'm pretty sure Scenario 2 is what's happening.  I have ModuleManager set to load them last which I probably shouldn't have.  I'll do some testing and see what I come up with.

[SteveD80]

A couple of additions that I would like to see and imagine others would:
drills start/stop
science (I believe that one would be a bit more intensive than your examples)
close intakes, possibly added to 10 as I believe that it is desirable to have it fire at the same time, although that may not always be the case.

[Snark]

Hi all,

I'm happy to announce that I have released DefaultActionGroups v1.2, for KSP 1.2 compatibility.  Please see the download link in the OP for this thread.

No new functionality in this release; it's a compatibility update only.  (There's actually a bit "less" functionality:  I've removed the config files for adding cabin lights to the Light action group, which amusingly enough was my original motivation for writing this mod int he first place.  Turns out that the cabin lights thing is now default behavior in stock KSP 1.2, so it doesn't need any help from me.) 

The only other noteworthy change is that the license has changed to CC-BY-NC-ND 4.0 (it was previously MIT).  It's a more restrictive license than MIT, but I don't expect that the change of license will affect users of this mod.  The most noteworthy changes in licensing are:

1. you can't make money off it
2. if you modify it in any way, you can't distribute the modified version

Enjoy!

[sebi.zzr]

Hello dear Sir,i have some old landing legs,which support only "ModuleAnimateGeneric".Is there any way i could add theme to default action group?
thank you

[Jiraiyah]

@Snark did you consider about adding antena and toggling their activation to an action group (say 3) specially with support of remote tech?

[Snark]

7 hours ago, sebi.zzr said:

Hello dear Sir,i have some old landing legs,which support only "ModuleAnimateGeneric".Is there any way i could add theme to default action group?

Actually, it turns out that as of KSP 1.2, you don't actually need DefaultActionGroups anymore for anything based on ModuleAnimateGeneric.    That's because they added support for a "defaultActionGroup" field on that module.  (Yet another case of Squad gradually making my mods obsolete by having the stock game do what I wanted...)

So anyway, if you have someNiftyLandingLeg that happens to be implemented with ModuleAnimateGeneric, you can now (as of KSP 1.2) fix it up like this, assuming that you have ModuleManager installed:

@PART[someNiftyLandingLeg] {
    @MODULE[ModuleAnimateGeneric] {
        %defaultActionGroup = Gear
    }
}

...or something like that.

The march of progress, huh? 

 

2 hours ago, Jiraiyah said:

did you consider about adding antena and toggling their activation to an action group (say 3) specially with support of remote tech?

Not a bad idea.  I wouldn't want to do that by default (not everyone will want it), but it would make a nice addition to the library of sample configs that comes with the mod.  I'll add that with the next iteration of the mod.

[Johnny2000]

This was a handy mod, and I thought I could add Antennas and other stuff myself. I mean, How hard can it be?

I see that you are planning to release a cfg for antennas, but I am an impatient man ;-)

Here's what I got:

// Extend/Retract antennas added to group Custom01.

@PART[*]:HAS[@MODULE[ModuleDeployableAntenna]] {
	@description ^= :(.)$:$0 Antennas toggle via action group Custom01 by default.:
	MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleDeployableAntenna
		actionGuiName = Toggle Antenna
		defaultActionGroup = Custom01
	}
}

// This part is for the antennas in Bluedog's mod (and possibly many other?)
@PART[*]:HAS[@MODULE[ModuleAnimateGeneric]:HAS[#antenna]] {
	@description ^= :(.)$:$0 Antennas toggle via action group Custom01 by default.:
	MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleAnimateGeneric
		actionGuiName = Toggle Antenna
		defaultActionGroup = Custom01
	}
}

I got the second part working if I only used [ModuleAnimateGeneric] but then almost every item in the VAB said: "Antennas toggle via action group Custom01 by default".

What am I doing wrong. Btw. I am completely noob to MM cfg's. However I did manage to make one work for another mod :-)

[Snark]

On 11/24/2016 at 10:57 AM, Johnny2000 said:

I got the second part working if I only used [ModuleAnimateGeneric] but then almost every item in the VAB said: "Antennas toggle via action group Custom01 by default".

What am I doing wrong. Btw. I am completely noob to MM cfg's. However I did manage to make one work for another mod :-)

Yeah, the problem is that practically everything that moves uses ModuleAnimateGeneric.

Saying @PART[*]:HAS[@MODULE[ModuleAnimateGeneric]] is basically saying "do this to every part everywhere which uses ModuleAnimateGeneric, including ones that have nothing to do with antennas, including the ones that are already decorated with ModuleDefaultActionGroup by the DefaultActionGroups mod itself."  Probably not what you wanted. 

Adding :HAS[#antenna] like you've done doesn't help, either.  Basically you're saying, "...but only for the ModuleAnimateGeneric modules that have a property called 'antenna'".  Since ModuleAnimateGeneric has no property on it named "antenna", then by adding this clause you're basically saying "do this to no parts at all."

So, basically you have three options for trying to add this for antennas that don't use ModuleDeployableAntenna:

1. Patch them so that they don't use ModuleAnimateGeneric, but use ModuleDeployableAntenna instead.  This is the coolest solution, if you can do it.  The problem is that it can be tricky-- you need to be able to open the model in Blender or some other tool to find the right "pivot" component in the model to use (since pivotName is a required field in ModuleDeployableAntenna), and there might not actually be a good pivot component if the author of the model wasn't planning on using ModuleDeployableAntenna.
2. Explicitly specify the list of antennas you want to affect.  e.g. PART[SomeReallyCoolAntenna|SomeOtherCoolAntenna], etc.  This is simple, easy, and fairly goof-proof.  It has the drawback of not being super maintainable, i.e. if you add all the antennas in Cool Mod X, and then that mod updates to add a new antenna, your patch wouldn't update that new antenna until you update your patch.
3. Come up with a way of "do this to all the antenna" in a way that filters to just the things that you want.  This is a great one-size-fits all solution, and quite maintainable... but it does require some fairly advanced ModuleManager sorcery. 

What you were trying to do above was #3.  Let's see if we can come up with a workable solution for you.  The key here is to figure out a way to be sufficiently inclusive that you cover all the antennas, but sufficiently exclusive that you only include antennas.

So, let's walk through the process.

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric]]

...Not a bad start... except, as you've seen, lots of parts use ModuleAnimateGeneric, not just antennas.  How do you limit this to just antennas?

Well, I think a pretty good definition is: "If it can transmit science data, then it's an antenna.  If it can't, then it's not."  So how about we filter this to just the parts that have ModuleAnimateGeneric, and which also have a ModuleDataTransmitter on them?  Like this:

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric], @MODULE[ModuleDataTransmitter]]

This is starting to look workable.  However, there's still the problem that this is going to try to add its stuff even to parts which are already decorated by other mods.  So, add another filter criterion:  the part shouldn't already have ModuleDefaultActionGroup on it:

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric], @MODULE[ModuleDataTransmitter], !MODULE[ModuleDefaultActionGroup]]

Next:  You want to mark your patch as requiring DefaultActionGroups.  If you don't, then if someone were to install your patch but not DAG, they'd get weird errors at run time.  By marking it as needing DefaultActionGroups, you safeguard it:  if DAG isn't installed, then your patch simply does nothing and causes no errors.  So you can do that like this:

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric], @MODULE[ModuleDataTransmitter], !MODULE[ModuleDefaultActionGroup]]:NEEDS[DefaultActionGroups]

...The last thing you should do is to give ModuleManager a hint about when to apply your patch.  If you don't, then MM will just load all the patches in alphabetical order, which could cause problems.  (Suppose you're using a mod which includes its own DefaultActionGroups patch, but it is alphabetically later than your own; so your patch looks at the part, sees that there's no ModuleDefaultActionGroup (yet), adds it... and then later the other mod comes along and adds it again.  Probably not what you want.

So, a "when" hint is in order.  The simplest thing to do here is probably just to use a "FINAL" directive, like this:

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric], @MODULE[ModuleDataTransmitter], !MODULE[ModuleDefaultActionGroup]]:NEEDS[DefaultActionGroups]:FINAL

...this tells ModuleManager to apply this patch after everything else.  (Well, everything else that isn't also marked FINAL, anyway.)

 

Anyway... I think that ought to do the trick.  Wanna give it a whirl and find out? 

(Incidentally... for documentation on how to do this sort of stuff, check out the ModuleManager Handbook, lotta useful stuff in there.)

[Johnny2000]

You don't happen to be a teacher, do you? Carl Sagan couldn't have given a better reply

 

1 hour ago, Snark said:

Yeah, the problem is that practically everything that moves uses ModuleAnimateGeneric.

Saying @PART[*]:HAS[@MODULE[ModuleAnimateGeneric]] is basically saying "do this to every part everywhere which uses ModuleAnimateGeneric, including ones that have nothing to do with antennas, including the ones that are already decorated with ModuleDefaultActionGroup by the DefaultActionGroups mod itself."  Probably not what you wanted. 

Adding :HAS[#antenna] like you've done doesn't help, either.  Basically you're saying, "...but only for the ModuleAnimateGeneric modules that have a property called 'antenna'".  Since ModuleAnimateGeneric has no property on it named "antenna", then by adding this clause you're basically saying "do this to no parts at all."

So, basically you have three options for trying to add this for antennas that don't use ModuleDeployableAntenna:

1. Come up with a way of "do this to all the antenna" in a way that filters to just the things that you want.  This is a great one-size-fits all solution, and quite maintainable... but it does require some fairly advanced ModuleManager sorcery. 

What you were trying to do above was #3.  Let's see if we can come up with a workable solution for you.  The key here is to figure out a way to be sufficiently inclusive that you cover all the antennas, but sufficiently exclusive that you only include antennas.

Yes, I wanted to cast a wide net, instead of adding unique parts. So if I installed other mods that contained antennas, they wouldn't need a new or edited .cfg -file

 

1 hour ago, Snark said:

So, basically you have three options for trying to add this for antennas that don't use ModuleDeployableAntenna:

1. Patch them so that they don't use ModuleAnimateGeneric, but use ModuleDeployableAntenna instead.  This is the coolest solution, if you can do it.  The problem is that it can be tricky-- you need to be able to open the model in Blender or some other tool to find the right "pivot" component in the model to use (since pivotName is a required field in ModuleDeployableAntenna), and there might not actually be a good pivot component if the author of the model wasn't planning on using ModuleDeployableAntenna.

 

This is a few months in to the future. I have plans for a few mod. To make a long story short. I've been ill for some years now. Starting to recover and are playing KSP for the first time in two years. Anyway, I have been using SketchUp earlier, but I understand that Blender (or Maya if one can afford it) is much better. So I guess I have to start with that yellow submarine tutorial in Blender. I feel that nothing I've learned in SketchUp is applicable to Blender.

1 hour ago, Snark said:

Adding :HAS[#antenna] like you've done doesn't help, either.  Basically you're saying, "...but only for the ModuleAnimateGeneric modules that have a property called 'antenna'".  Since ModuleAnimateGeneric has no property on it named "antenna", then by adding this clause you're basically saying "do this to no parts at all."

I had a vague hope that the part.cfg -file maybe was at play. So I tried to use :HAS[#antenna]

1 hour ago, Snark said:

So, a "when" hint is in order.  The simplest thing to do here is probably just to use a "FINAL" directive, like this:

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric], @MODULE[ModuleDataTransmitter], !MODULE[ModuleDefaultActionGroup]]:NEEDS[DefaultActionGroups]:FINAL

...this tells ModuleManager to apply this patch after everything else.  (Well, everything else that isn't also marked FINAL, anyway.)

 

Anyway... I think that ought to do the trick.  Wanna give it a whirl and find out? 

I haven't tried it yet, because I think I see a flaw in this, and that is using ModuleDataTransmitter . Because pods and science labs also have this, event though they don't have an antenna. But I think I understand better how MM works now, and I'll try to play around untill I get it right.

Edited November 27, 2016 by Johnny2000

[Johnny2000]

Can Module Manager "see" the action commands for a module? Like extend, retract and toggle?

Or can one use the part name like @part[*dish], | @part[*antenna]

[Snark]

1 hour ago, Johnny2000 said:

You don't happen to be a teacher, do you?

Nope, I've been a professional software engineer for the past couple of decades.

But as a matter of fact, I was a schoolteacher for a few years, back in the day.  Hah, busted.    Thanks!

1 hour ago, Johnny2000 said:

To make a long story short. I've been ill for some years now. Starting to recover and are playing KSP for the first time in two years. Anyway, I have been using SketchUp earlier, but I understand that Blender (or Maya if one can afford it) is much better. So I guess I have to start with that yellow submarine tutorial in Blender.

Sorry to hear you haven't been well; glad you're on the mend!

Blender's an amazing program (especially given that it's free)... pity I'm such a hopelessly incompetent fumblethumbs at it, though that's entirely on me, not on Blender.  It's got a steep learning curve if you're going to be actually modeling, so tutorials are definitely a good idea.  NecroBones has an excellent video tutorial linked in his sig-- I strongly recommend it.

But if you're not actually authoring, and all you want to do is to pick apart someone else's model so you can see what the subcomponents are named, then that's a whole lot easier (heck, even I can do that pretty well), and is pretty quick to pick up.

 

1 hour ago, Johnny2000 said:

Because pods and science labs also have this, event though they don't have an antenna.

Actually, that's not the case. See what happens if you build a ship with a command pod, and a science lab, and no antennas, and take a crew report, and then try to transmit it and see what happens. 

Some example part configs:

• science lab
• Mk1 pod

...if you take a look therein, you'll note that these guys do not have ModuleDataTransmitter on them.

That's not to say that someone couldn't write a mod that has a command pod with built-in ModuleDataTransmitter antenna on it, if they wanted to, so it's possible, yes.

You do raise a good point about probe cores, though-- they have ModuleDataTransmitter on them for control purposes.  So you could filter those out by specifying that you want to require not just ModuleDataTransmitter, but specifically a ModuleDataTransmitter whose antennaType is not INTERNAL:

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric], @MODULE[ModuleDataTransmitter:HAS[~antennaType[INTERNAL]]], !MODULE[ModuleDefaultActionGroup]]:NEEDS[DefaultActionGroups]:FINAL

...the "INTERNAL" type is the one where data can't be transmitted, it's for control purposes only.

"Add a ModuleDefaultActionGroup to every part that has ModuleAnimateGeneric, and has a ModuleDataTransmitter that isn't internal-only, but which doesn't already have a ModuleDefaultActionGroup on it.  Only do this if the DefaultActionGroups mod is installed.  Do it after all the other ModuleManager patches have been applied."

I think that oughta do it.

[Johnny2000]

22 minutes ago, Snark said:

Actually, that's not the case.  ModuleDataTransmitter is the thing that lets a part transmit science results, which means AFAIK nothing has this on it except antennas.  See what happens if you build a ship with a command pod, and a science lab, and no antennas, and take a crew report, and then try to transmit it and see what happens. 

Some example part configs:

• science lab
• Mk1 pod

...if you take a look therein, you'll note that these guys do not have ModuleDataTransmitter on them.

That's not to say that someone couldn't write a mod that has a command pod with built-in ModuleDataTransmitter antenna on it, if they wanted to, so it's possible, yes.  And it's also possible that someone could mod an antenna part that allows vessel control, but which doesn't allow transmitting science (i.e. doesn't have ModuleDataTransmitter on it).

But in practice, I've only ever seen this module on antennas, and all the antennas I've seen have it.  It's what antennas are for.  If you want to try to write a "do this to all antennas" ModuleManager patch, "does it have ModuleDataTransmitter" is probably the best you'll be able to do, I'd guess.

That page is before 1.2 update. I guess all pods, probes and stuff now has an internal antenna for use on the Comm-net. You know, for vessel control. However, they need a Kerb-net antenna to transmit science.

Now this wasn't easy. Waiting for the game to load now. Fixed some typos. Maybe it will work this time...

How do I know what actionGuiName to use?? Google has not been my friend

[Snark]

14 minutes ago, Johnny2000 said:

That page is before 1.2 update. I guess all pods, probes and stuff now has an internal antenna for use on the Comm-net. You know, for vessel control. However, they need a Kerb-net antenna to transmit science.

You're partially correct-- probe cores have an internal antenna.  Command pods don't, nor does the science lab.  The pages I linked are, AFAIK, correct and up to date.  (If you go look at the config for the science lab and the Mk1 pod, you'll see that they do not, in fact, have ModuleDataTransmitter.  That was actually the first thing I checked before I linked you to the online copies of the config, since naturally I wouldn't trust that the wiki is necessarily up to date.)

But the fact that probe cores have an internal antenna is straightforward to deal with, as you'll see in my post above.  The problem is that you just now quoted an old copy of my response from an hour ago (I edited it right after posting).  Try going back and reading what I wrote, again. 

15 minutes ago, Johnny2000 said:

How do I know what actionGuiName to use?? Google has not been my friend

This is how ModuleDefaultActionGroup knows how to activate the thing it's activating.  It's literally exactly what it says:  it's the name of the action, as displayed in the "actions" GUI in the vehicle editor.  Fire up KSP, go into the VAB, add the part to a ship, go to the "action groups" UI, select the part, see what string is displayed there (it'll probably be "Toggle Antenna" or something similar), use that.

Actually, that could be a bit of an Achilles heel for trying to use a one-size-fits-all solution like you're doing.  In an ideal world, every mod author everywhere who creates an antenna would be completely and perfectly consistent with what the stock antennas do, and religiously use the exact string "Toggle Antenna" for this.  So you could just put "Toggle Antenna" there and it would work for everything.

I have no idea how consistent authors actually are about this, though.  If you did that, and somebody came along and had an antenna that used some other string there, then not only would your patch not work, but it would probably log error messages as well.

Though actually, that could give you a convenient "back door" for filtering:  how about picking only the antennas whose ModuleAnimateGeneric happens to have an actionGUIName (careful, note the different capitalization) of "Toggle Antenna"?  i.e.

@PART[*]:HAS[@MODULE[ModuleAnimateGeneric:HAS[#actionGUIName[Toggle Antenna]]], @MODULE[ModuleDataTransmitter:HAS[~antennaType[INTERNAL]]], !MODULE[ModuleDefaultActionGroup]]:NEEDS[DefaultActionGroups]:FINAL

...this will still miss any antennas that happen to use some other string, but at least it'll leave them unaffected and won't cause any error messages.

[Johnny2000]

Yey, finally got it working. Please don't shoot me, but I figured out that your mod isn't compatible with ActionGroupExtended. So it wasn't just me doing everything wrong

You are partially correct as well. The pod you linked to is old. I've checked several pods, and they've got a ModuleDataTransmitter. But it doesn't matter.

Now this may not be pretty, but at least it works

// Extend/Retract stock antennas added to group Custom01.

@PART[*]:HAS[@MODULE[ModuleDeployableAntenna]]:NEEDS[DefaultActionGroups]:FINAL {
		@description ^= :(.)$:$0 Antennas toggle via action group Custom01 by default.:
MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleDeployableAntenna
		actionGuiName = Toggle Antenna
		defaultActionGroup = Custom01
		}
}

// This part is for the antennas in Bluedog's mod (and possibly many other?)

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]:HAS[~antennaType[INTERNAL]]], [!MODULE[ModuleDefaultActionGroup]]:NEEDS[DefaultActionGroups]:FINAL {
	@description ^= :(.)$:$0 Antennas toggle via action group Custom01 by default.:
	MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleAnimateGeneric
		actionGuiName = Toggle Antenna
		defaultActionGroup = Custom01
	}
}

Sorry about not reading your post, but I started to type, and then the game finished loading and I forgot about it, meanwhile you edited it.

Well, now I have to figure out why this does not work with ActionGroupExtended, but I'll save that for another day.

[Johnny2000]

1 hour ago, Snark said:

This is how ModuleDefaultActionGroup knows how to activate the thing it's activating.  It's literally exactly what it says:  it's the name of the action, as displayed in the "actions" GUI in the vehicle editor.  Fire up KSP, go into the VAB, add the part to a ship, go to the "action groups" UI, select the part, see what string is displayed there (it'll probably be "Toggle Antenna" or something similar), use that.

That's what I thought, but the culprit was ActionGroupExtended, and that's why I thought I got it wrong.

 

Sorry if everything is a mess here, but doesn't seem like my browser auto update the thread, so now I see that you have written tons of stuff I haven't read.

Maybe it has something to do with me having set my connection to metered in windows.

[Snark]

21 minutes ago, Johnny2000 said:

Well, now I have to figure out why this does not work with ActionGroupExtended

Because Action Groups Extended doesn't actually use action groups.   (Possible oversimplification and/or may not quite be strictly technically accurate, but I believe that's the gist.)

The thing that Action Groups Extended does is to give lots and lots of action groups, which is great, right?

Well, yes.  Except that you can't have custom action groups in KSP, at all.

"Wait, what?", I hear you cry.

Here's the thing:  In KSP, action groups are implemented as a C# enum.  That's just technobabble if you're not a programmer, but the important thing is:  for an enum, the list of values is hard-coded and can't be modified.  That is, KSP has a specific set of 17 action groups (stage, gear, lights, RCS, SAS, brakes, abort, and Custom01 through Custom10), and it is impossible for any mod to change that list in any way.  The only way to get a new action group is for Squad to make a change to the game and add it.  (Which hasn't happened in a long, long time.  Certainly there hasn't been a new action group added since I started playing KSP 0.23.5 over two years ago.)

"Well, okay," I hear you cry, "then how did @Diazo manage to create Action Groups Extended?"

The short answer is, "because he's awesome."    (And he probably knows more about action groups than just about any other modder out there.  In fact, when I was trying to write DefaultActionGroups and was scratching my head trying to figure out how to make things work, he was the one who answered most of my questions.  Heckuva guy.)

The slightly longer answer is, he went and built this entire new set of functionality-- new "action groups", and UI for working with them-- but they're not actually "action groups" in the strict sense of KSP action groups.  He's built a parallel structure.  It looks and acts like an action group to the player, but as far as the computer is concerned, it's a completely different beast.

That it works is great... but it also means that other mods that do stuff with action groups won't interoperate with Action Groups Extended unless they've specifically been instrumented to do so, because they're not speaking the same language.  That's no fault of Diazo's, it's just a baked-in limitation of the game.

(Mandatory caveat:  I haven't actually looked at the Action Groups Extended code, and it's been a while since I was coding all the stuff around action groups, so I might have gotten some of the details wrong, above-- but I believe that the gist is basically accurate.  Hopefully, Diazo will correct me if I've gotten it wrong.)

[Johnny2000]

He he you won't hear me cry. I don't need 255 shortcuts, I only used it to add something I had forgotten if I discovered it after I had reached orbit.

I rather prefer to just press 1 and 2 (for me; deploy antennas and solar panels) before I send my probe to Venus or somewhere.

 

Edit: I guess your answer explains why the things that went in to  Abort, Gear etc. worked, but not Custom01, Custom02 and so on.

Edited November 28, 2016 by Johnny2000

[Diazo]

@Johnny2000 Until this mod came along, there was no ability for an action group to be assigned to the Custom groups except by player interaction though the Action Groups GUI in the editor so AGX doesn't even look for those actions at the moment like it does for the named groups. (Abort/Lights/Gear/etc.)

As there is now a point for it to do so, the next AGX update will have that ability. No promises on release date though, real life is killing me right now.

D.

[Johnny2000]

@Diazo Aha Nice to know. I guess I can have my cake and eat it too - or however that saying goes

@Snark Thank you for teaching me about how to use MM syntax's (is that the right word?). Now I have been able to move KSC to a more Cape Kerberal-ish latitude. It's fun to do changes that you make yourself and not just download what other people makes. Albeit my little "mod" is completely dependent on other peoples mods.

[Snark]

20 minutes ago, Johnny2000 said:

@Snark Thank you for teaching me about how to use MM syntax's (is that the right word?). Now I have been able to move KSC to a more Cape Kerberal-ish latitude. It's fun to do changes that you make yourself and not just download what other people makes. Albeit my little "mod" is completely dependent on other peoples mods.

Heh, quite welcome.  ModuleManager is so cool... really glad that something like that not only exists, but is ubiquitous enough that it's become a standard.  It's amazing what you can do with just ModuleManager config without having to write a single line of code.

If you're enjoying tinkering with stuff via ModuleManager, another fun mod to add to the pile is Kopernicus.  It's the gateway to being able to mod the solar system.  If you have Kopernicus installed, then that enables you to write simple ModuleManager config that tinkers with the solar system.  "Okay, I want to put Moho here, and resize Eve to this diameter, and make Duna's atmosphere have oxygen, and change the density profile of the atmosphere, and adjust the min-altitude-for-warp-factor-X levels for Gilly like this..."