Jump to content

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


Snark

Recommended Posts

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]

Link to comment
Share on other sites

  • 8 months later...
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?

Link to comment
Share on other sites

  • 3 months later...

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).

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

  • 1 month later...
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
    }
}

Link to comment
Share on other sites

  • 2 months later...
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 by Errol
Link to comment
Share on other sites

  • 4 weeks later...

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
}

 

Link to comment
Share on other sites

  • 2 weeks later...
  • 6 months later...

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 ^^)

Link to comment
Share on other sites

 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?

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

  • 3 weeks later...

@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 by Aotezukay
Link to comment
Share on other sites

  • 11 months later...
  • 11 months later...

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 by Errol
Patch was not affecting all engines; updated to be more inclusive.
Link to comment
Share on other sites

  • 2 weeks later...

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
	}
}

 

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...