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

[Rodger]

Addendum to the above - I'm playing with JNSQ and just saw it disables kopernicus solar panels, so that'll be why it was broken with the normal DAG solar panel patch. The patch probably needs to use the KopernicusSolarPanels module with a NEEDS[Kopernicus, !JNSQ]

[Cruesoe]

On 2/16/2020 at 3:04 AM, Rodger said:

Addendum to the above - I'm playing with JNSQ and just saw it disables kopernicus solar panels, so that'll be why it was broken with the normal DAG solar panel patch. The patch probably needs to use the KopernicusSolarPanels module with a NEEDS[Kopernicus, !JNSQ]

I still can't get this working with the new Kopernicus (bleeding edge) and JSNQ.  It's probably my wonky MM code but I can't get Solar Panels to Action 1 to work.

Has anyone got a correct patch that works?

[dbentbroad]

Any possibility of adding a default action to experiments?

Normally I will put "run experiment" in 1, reset/discard in 2, and collect all in 3. I've reconfigured those already in my install, however I don't know how to create a cfg file to run experiments, or at least to catch most of the experiments like that (I understand some may have unique code that doesn't make it easy or something, idk).

[Snark]

23 hours ago, dbentbroad said:

Any possibility of adding a default action to experiments?

Normally I will put "run experiment" in 1, reset/discard in 2, and collect all in 3. I've reconfigured those already in my install, however I don't know how to create a cfg file to run experiments, or at least to catch most of the experiments like that (I understand some may have unique code that doesn't make it easy or something, idk).

Well, "collect all" is already handled by the optional config file Collect_Science_in_Custom08.cfg, so you can copy that into your install for that-- this works for the science box and the upper-tier probe cores.

As for collecting/discarding... I'm disinclined to add it to the mod, since I myself don't want that on my ships.  (For example, if I did that, then hitting the associated action key would cause every science instrument on the ship to take a reading, even if it doesn't actually have anything to collect.  For me, that would be an incredible hassle and annoyance.)

However, if you want to create your own config file to do that, it shouldn't be hard.

1. Copy the sample config file I linked above
2. Replace "ModuleScienceContainer" with "ModuleScienceExperiment"
3. Update the description appropriately
4. Change moduleSource from ModuleScienceContainer to ModuleScienceExperiment
5. Change actionGuiName to the GUI name of the action you want to be triggered (whatever it is for the experiment)
6. Set defaultActionGroup to whichever one you want

I note that not every science experiment has the same GUI name for its action, though, so you might want to have separate PART declarations for the different experiments, rather than a single wildcard to catch them all.

(Hmmm.  That actually raises an interesting point.  Would be a nice feature addition to the mod to allow specifying the "invariant name" of the action rather than the GUI name.  With such a feature, you could have a wildcard that would match all science experiments... and it would also make the mod more robust at dealing with different localized versions.  The only reason it's not like that already is that this is a mod I wrote quite some time ago, before KSP had localized versions.  I shall have to think on this.)

[fittedorphan68]

On 2/9/2021 at 1:35 PM, Snark said:

Well, "collect all" is already handled by the optional config file Collect_Science_in_Custom08.cfg, so you can copy that into your install for that-- this works for the science box and the upper-tier probe cores.

As for collecting/discarding... I'm disinclined to add it to the mod, since I myself don't want that on my ships.  (For example, if I did that, then hitting the associated action key would cause every science instrument on the ship to take a reading, even if it doesn't actually have anything to collect.  For me, that would be an incredible hassle and annoyance.)

However, if you want to create your own config file to do that, it shouldn't be hard.

1. Copy the sample config file I linked above
2. Replace "ModuleScienceContainer" with "ModuleScienceExperiment"
3. Update the description appropriately
4. Change moduleSource from ModuleScienceContainer to ModuleScienceExperiment
5. Change actionGuiName to the GUI name of the action you want to be triggered (whatever it is for the experiment)
6. Set defaultActionGroup to whichever one you want

I note that not every science experiment has the same GUI name for its action, though, so you might want to have separate PART declarations for the different experiments, rather than a single wildcard to catch them all.

(Hmmm.  That actually raises an interesting point.  Would be a nice feature addition to the mod to allow specifying the "invariant name" of the action rather than the GUI name.  With such a feature, you could have a wildcard that would match all science experiments... and it would also make the mod more robust at dealing with different localized versions.  The only reason it's not like that already is that this is a mod I wrote quite some time ago, before KSP had localized versions.  I shall have to think on this.)

This is kind of the "Brute Force" workaround I came up with. It renames all science experiment actionNames with either "Log Data" or "Delete Data" as appropriate so you can than cast a broad net to run and then delete experiments. Sure it kills immersion as they now all have the same name, but it serves the purpose:

 

@PART[*]:HAS[@MODULE[ModuleScienceExperiment]] 
{
    @MODULE[ModuleScienceExperiment]
    {
        %experimentActionName = Log Data
        %resetActionName = Delete Data
    }
    MODULE 
    {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleScienceExperiment
        actionGuiName = Log Data
        defaultActionGroup = Custom01
    }
    MODULE 
    {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleScienceExperiment
        actionGuiName = Delete Data
        defaultActionGroup = Custom03
    }
}

[Errol]

On 2/14/2020 at 11:44 PM, Rodger said:

Looks like the solar panel patch is broken with the new kopernicus, it doesn't seem to need the kopernicus NEEDS logic anymore. The name of "KopernicusSolarPanel" did change to "KopernicusSolarPanels", but in my testing just changing moduleSource to the regular ksp ModuleDeployableSolarPanel worked.

 

On 10/25/2020 at 11:29 AM, Cruesoe said:

I still can't get this working with the new Kopernicus (bleeding edge) and JSNQ.  It's probably my wonky MM code but I can't get Solar Panels to Action 1 to work.

Has anyone got a correct patch that works?

 

Ran into this problem myself. Tried adding an s to kopernicusSolarPanels, that didn't work. Then I tried removing the NEEDS and the kopernicus line altogether, and that worked:

 

Spoiler

// The retractable panels get "Toggle" added to group Custom01.
@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[~retractable[false]]] {
    @description ^= :(.)$:$0 Panels toggle via action group Custom01 by default.:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleDeployableSolarPanel
        actionGuiName = Toggle Panels
        defaultActionGroup = Custom01
    }
}

// The non-retractable panels get "Extend" added to group Custom01.
@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[#retractable[false]]] {
    @description ^= :(.)$:$0 Panels extend via action group Custom01 by default.:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleDeployableSolarPanel
        actionGuiName = Extend Panel
        defaultActionGroup = Custom01
    }
}

Also, @Snark I have noticed that remote tech 1.9.10 seems to break the antennas cfg. I should also mention that I'm using restock plus, but having that without RT seems fine. @tomek.piotrowski, anyone got ideas on this one? I'm pretty sure these lines from the RemoteTech_Squad_Antennas.cfg are at fault, but I have no idea how to fix it (been out of practice with ksp and mm.cfgs for a few years):

...
	@MODULE[ModuleDeployableAntenna]
	{
		%name=ModuleAnimateGeneric
		...
	{

EDIT: Been messing around with the RT patch today, but nothing I try seems to work;

Spoiler

// Deployable antennas get "Toggle" added to group Custom03.
@PART[*]:HAS[@MODULE[ModuleDeployableAntenna]] {
    @description ^= :(.)$:$0 Antenna toggles via action group Custom03 by default.:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleDeployableAntenna
        actionGuiName = Toggle Antenna
        defaultActionGroup = Custom03
    }
}

// remoteTech antennas get "Toggle" added to group Custom03.
@PART[*]:HAS[@MODULE[ModuleRTAntenna]] {
    @description ^= :(.)$:$0 Antenna toggles via action group Custom03 by default.:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleRTAntenna
        actionGuiName = Toggle Antenna
        defaultActionGroup = Custom03
    }
}

 

Spoiler

// Deployable antennas get "Toggle" added to group Custom03.
@PART[*]:HAS[@MODULE[ModuleDeployableAntenna]]:AFTER[RemoteTech] {
    @description ^= :(.)$:$0 Antenna toggles via action group Custom03 by default.:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource:NEEDS[!RemoteTech] = ModuleDeployableAntenna
        moduleSource:NEEDS[RemoteTech] = ModuleRTAntenna
        actionGuiName = Toggle Antenna
        defaultActionGroup = Custom03
    }
}

 

Edited May 30, 2021 by Errol

[Snark]

Hi all,

I'm pleased to announce the release of DefaultActionGroups 1.4.

What this update adds is a feature that, honestly, should have been there from the beginning.  It's an alternate syntax that lets you use non-localized names of actions in the config, which is considerably more stable and robust (for example, your config won't break if someone is using KSP in a different language).

The way it works is, there's now a field actionName, which you can use instead of actionGuiName.  (The latter still exists, and still works as before-- but if you specify actionName, then it will simply ignore actionGuiName.)

Here's what it looks like in practice:

// Old way
MODULE {
    name = ModuleDefaultActionGroup
    moduleSource = ModuleEnginesFX
    actionGuiName = Activate Engine
}

// New way
MODULE {
    name = ModuleDefaultActionGroup
    moduleSource = ModuleEnginesFX
    actionName = ActivateAction
}

 

In the particular case of ModuleAnimateGeneric, for ActionName you can either specify actionName as  "ToggleAction", or (if you need to specifically identify which ModuleAnimateGeneric you're working with) you can set actionName to the animationName of the ModuleAnimateGeneric.

Caveat:  The special handling of ModuleColorChanger has changed.  If you're using DefaultActionGroups with ModuleColorChanger, you now have to use the new syntax based on actionName.  For everything else, the old, localization-based way still works; it's just deprecated, and I would encourage people to use the new way instead.

I've updated most of the optional configs included with the mod to use the new syntax.

 

@Errol, I don't know that this will solve your RemoteTech woes with DefaultActionGroups, but you might want to try giving this a whirl-- see if you can make things work using something like,

MODULE {
    name = ModuleDefaultActionGroup
    moduleSource = ModuleAnimateGeneric
    actionName = ToggleAction
}

 

[Dominiquini]

This mod is not assign ActionGroup to Solar Panels with Kopernicus installed!

Thanks.

[Sppion1]

Hello @Snark !
Why do I discover this mod only now ? I don't really know....

I'm trying to tweak it a bit to my uses, and so far I did everything I wanted, but one :

cockpit light only on Custom02.

Use case (for me) : I fly planes, and for them I use light for landings legs light (as for landing light). But I keep the cockpit on (or off when lazzy ^^) for all the flight.... For me it make more sense to have landing leg's light on "Light" action group, and cockpit light on Custom02 (for example). Adding it to custom02 is not difficult, it's done. But.... how can I remove the ToggleAction of ModuleColorChanger from Light ?

Thanks for developing this mod for so many years, so I can have it now ! (and for all the overall work ^^)

[Snark]

 Thank you for the kind words, glad you like it! 

 

11 hours ago, Sppion1 said:

But.... how can I remove the ToggleAction of ModuleColorChanger from Light ?

DefaultActionGroups only adds, it never removes.  So it can't do this.

However, fortunately for you, you don't need it for that, since I believe you can do that just with plain-vanilla ModuleManager syntax, with a clause like this:

@MODULE[ModuleColorChanger]
{
    -defaultActionGroup = dummy
}

(see relevant ModuleManager syntax guide)

Does this help?

[Sppion1]

Thanks for the help, that was almost it :

@PART[*]:HAS[@MODULE[ModuleColorChanger]] {
	@MODULE[ModuleColorChanger]
	{
		-defaultActionGroup = dummy
	}
}

I did not thought about vanilla MM syntax, I'm not (yet?) very familiar with it ^^
Thanks for the kink, I'm keeping it !
Have a nice day

[Aotezukay]

@Snark love this mod. Thanks for maintaining it!

On 2/9/2021 at 2:35 PM, Snark said:

As for collecting/discarding... I'm disinclined to add it to the mod, since I myself don't want that on my ships.  (For example, if I did that, then hitting the associated action key would cause every science instrument on the ship to take a reading, even if it doesn't actually have anything to collect.  For me, that would be an incredible hassle and annoyance.)

However, if you want to create your own config file to do that, it shouldn't be hard.

1. Copy the sample config file I linked above
2. Replace "ModuleScienceContainer" with "ModuleScienceExperiment"
3. Update the description appropriately
4. Change moduleSource from ModuleScienceContainer to ModuleScienceExperiment
5. Change actionGuiName to the GUI name of the action you want to be triggered (whatever it is for the experiment)
6. Set defaultActionGroup to whichever one you want

I note that not every science experiment has the same GUI name for its action, though, so you might want to have separate PART declarations for the different experiments, rather than a single wildcard to catch them all.

(Hmmm.  That actually raises an interesting point.  Would be a nice feature addition to the mod to allow specifying the "invariant name" of the action rather than the GUI name.  With such a feature, you could have a wildcard that would match all science experiments... and it would also make the mod more robust at dealing with different localized versions.  The only reason it's not like that already is that this is a mod I wrote quite some time ago, before KSP had localized versions.  I shall have to think on this.)

 

For those interested in running/resetting science experiments using custom action groups:

// Runs experiments
@PART[*]:HAS[@MODULE[ModuleScienceExperiment]] {
    @description ^= :(.)$:$0 Science Experiments run via custom action group 05:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleScienceExperiment
        actionName = DeployAction
        defaultActionGroup = Custom05
    }
}
// Resets experiments
@PART[*]:HAS[@MODULE[ModuleScienceExperiment]] {
    @description ^= :(.)$:$0 Science Experiments reset via custom action group 08:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleScienceExperiment
        actionName = ResetAction
        defaultActionGroup = Custom08
    }
}

NOTE: This also adds 'Crew Report' and 'Discard Crew Report' from all command/passenger modules, which you might not want.

One workaround is to replace this line

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

with

@PART[*]:HAS[@MODULE[ModuleScienceExperiment],!MODULE[ModuleCommand],!MODULE[ModuleInventoryPart]]

Edited February 20, 2022 by Aotezukay

[Errol]

Seems like remote tech and kopernicus have both broken their respective .cfgs for this mod again....not sure what is going on this time, I've been out of it for a while...

[Errol]

For those using this mod:
 

Which is intended to be used with this mod:
 

It is absolutely critical that you properly shutdown your engines, and not just set the throttle to zero, as they would still be running in that case! It is useful to be able to safe all your engines before interacting with autopilots/SAS/RCS etc. In order to facilitate this, I have created this patch to add engine shutdown to custom action group 09 by default. Took the idea to search for engine parts with oxidizer propellant (instead of liquidfuel) so that anything using exotic fuels will still be included from the engine spooling patch in the community module manager patch database.

The reason this is useful is it allows mechjeb's smartRCS to utilize it's "rcs throttle when engines offline" option for ullage (which is more convenient than the "fore by throttle" tweakable because it doesn't waste RCS fuel once the engines are running). Using smart parts timers you can pretty easily set up automatic ullage burns and engine starts instead of trying to rely MJ's autostage while using ascent guidance.

 

// All liquid fuel engines Shutdown via action group 09 by @Errol 

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer]]] {
	@description ^= :(.)$:$0 Liquid engines shutdown via action group Custom09 by default.:
	MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleEngines
		actionName = ShutdownAction
		defaultActionGroup = Custom09
	}
}

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer]]] {
	MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleEnginesFX
		actionName = ShutdownAction
		defaultActionGroup = Custom09
	}
}

 

Edited February 3 by Errol
Patch was not affecting all engines; updated to be more inclusive.

[Errol]

Sorry for the double post, but this is a new day, and a new patch. Also, I'd like to ping@Snark about it, if it's inclusion in the dl is warranted.

I fixed remote tech breaking the default action group for antennas.

 

// Deployable antennas get "Toggle" added to group Custom03, RT compatability by @Errol

@PART[*]:HAS[@MODULE[ModuleDeployableAntenna]] {
	@description ^= :(.)$:$0 Antenna toggles via action group Custom03 by default.:
	MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleDeployableAntenna
		actionName = ExtendPanelsAction
		defaultActionGroup = Custom03
	}
}

@PART[*]:HAS[@MODULE[ModuleRTAntenna]]:AFTER[REMOTETECH] {
	MODULE {
		name = ModuleDefaultActionGroup
		moduleSource = ModuleRTAntenna
		actionName = ActionToggle
		defaultActionGroup = Custom03
	}
}

 

[Snark]

5 hours ago, Errol said:

Sorry for the double post, but this is a new day, and a new patch. Also, I'd like to ping@Snark about it, if it's inclusion in the dl is warranted.

Thanks for the heads up, and for digging into this!

I'll have a look when I get a chance.

[Villain Vibe]

Hi there

I was wondering if you're mod has compatibility with this mod? 
 

I would be nice to set default action groups using the extra action groups this mod provides.

Cheers! 

[Snark]

On 6/18/2024 at 10:20 AM, Villain Vibe said:

I was wondering if you're mod has compatibility with this mod?

Nope.  This mod just looks at action groups that exist in the game.  My understanding of how the other mod works is that it provides the necessary UI and functionality to behave as if there were additional "action groups" in the game... but because of the way the original developers implemented action groups, I believe it's not actually possible to truly add action groups to the game.

Since all my mod "knows about" is what it can see in the available action groups that the game provides, there's no way for it to "see" the extra stuff that any other mod adds that looks-and-feels like an action group but doesn't actually change the base game behavior.  The only way to do that would be if I added a bunch of special-case code into my mod, to try to detect that this one specific other mod is out there and then try to interoperate with it, and that's not something I've done (or am realistically likely to do, at this point).

(Sorry for the delay in replying!)

[Fubarbrickdust]

Really handy mod. Went under the radar for a while...love a good find like this.

Quick open query for all; I had a scan through the thread and also a layman's rummage around a few of my craft files but no joy...

Is there a way to define (and name, as sets can be named in-game) the  associated 'Action Set' with a given default action config?
Also, the custom axes (1-4)...any pointers on how one might define those also?

The ability to define an action set as well would be really powerful if it can be done!...