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

[Cochise]

1 minute ago, Snark said:

ModuleEngines.  (Here's the Poodle config, for reference.)

dumb question I know, so thanks 

[Snark]

1 minute ago, Cochise said:

dumb question I know, so thanks 

Well, if I'd made things sufficiently obvious that you could see what the answer was, you wouldn't have had to ask the question, now would you?

So, not a dumb question at all.  And by asking it here (and giving me a chance to answer), you've made things that much easier for whomever comes along later.

See?  Everybody wins. 

[Tyko]

I'm trying to add Service Bays to Custom02, same as Radiators. I thought I'd copied the syntax correctly from the Radiator config, but it's not working. Any advice on what I'm doing wrong? Thanks!

EDIT: Figured it out. I was referencing the wrong module from the part config.

 

// Service Bays

@PART[ServiceBay_125|ServiceBay_250|setiMiniServiceBay]
{
    @description ^= :(.)$:$0 Toggles via action group Custom02 by default.:
    MODULE {
        name = ModuleDefaultActionGroup
        moduleSource = ModuleCargoBay ModuleAnimateGeneric
        actionGuiName = Toggle
        defaultActionGroup = Custom02
    }
}

 

Edited May 3, 2018 by Tyko

[Speadge]

ok - i checked the whole thread - couldnt find an answer:
is there a way to remap an AG to a letter like "T".

i mean "custom01" is typical the number 1 - but can u remap it?
i  saw the statement, that i cant use AGX groups as default - but that doesnt mean i cant reconfig "custom00" to "T" - can i?

 

Nevermind - found in GameSetting

Edited May 13, 2018 by Speadge

[Tyko]

@Snark  Just had an epiphany   (yes, lightning struck my brain)

It may be out of scope for this mod, but I thought how cool it would be to be able to add delays to actions in an action group so you could set a sequence that various actions fire within one group

• maybe the cargo bay doors open 2/10 of a second before stored antennas extend, for example.
• Or on the Abort action set the shroud around the capsule to blow off a split second before the LES fires.

Anyway, I realize this is more work, but you crank out some great quality of life apps and I thought this might catch your interest.

Edited November 26, 2018 by Tyko

[linuxgurugamer]

12 minutes ago, Tyko said:

@Snark  Just had an epiphany   (yes, lightning struck my brain)

It may be out of scope for this mod, but I thought how cool it would be to be able to add delays to actions in an action group so you could set a sequence that various actions fire within one group

• maybe the cargo bay doors open 2/10 of a second before stored antennas extend, for example.
• Or on the Abort action set the shroud around the capsule to blow off a split second before the LES fires.

Anyway, I realize this is more work, but you crank out some great quality of life apps and I thought this might catch your interest.

Maybe look at Smart Parts?

[Tyko]

Just now, linuxgurugamer said:

Maybe look at Smart Parts?

Thank..I'd considered it, but I really didn't want to stack on a bunch of additional parts and another interface for just this one simple (from the users' PoV) task.

Thought it would make more sense for it to be built into the Action Group interface. You'd just need a drop down where you could select...say .2, .5, 1 and 2 second delays. Anything longer than that would be out of scope for a single action.

[Snark]

On 11/26/2018 at 10:17 AM, Tyko said:

It may be out of scope for this mod, but I thought how cool it would be to be able to add delays to actions in an action group so you could set a sequence that various actions fire within one group

• maybe the cargo bay doors open 2/10 of a second before stored antennas extend, for example.
• Or on the Abort action set the shroud around the capsule to blow off a split second before the LES fires.

Anyway, I realize this is more work, but you crank out some great quality of life apps and I thought this might catch your interest.

It's a neat idea, but not really in scope for this mod.  What you're describing is an "automation" feature, and while there's absolutely nothing wrong with that in general, it's not what I myself am into-- I don't want to automate KSP for myself, it's not a feature that I myself would ever use.  Plus, in my own gameplay, there's never any situation where I need two things to happen in rapid succession.  Either I want them to happen simultaneously (in which case I just put them in the same stage or action group), or else they're far enough apart that I can just press two buttons one after the other.

I primarily mod for myself-- i.e. when there's something about the stock game that bugs me, that I wish worked differently.  So I write the mod to make the game work the way I, personally, want it to... and then I share the mod on the off chance that there are other people who might have a similar preference.    In general it's worked out pretty well, I think... but it does mean that I have practically zero motivation to spend any time on a feature that I myself don't want for my gameplay.

On 11/26/2018 at 10:29 AM, linuxgurugamer said:

Maybe look at Smart Parts?

^ Exactly this, is what I was going to suggest.  Great little mod.  I don't usually run with it in my own games, but I've tried it on occasion and it's very good at what it does.

On 11/26/2018 at 10:33 AM, Tyko said:

Thank..I'd considered it, but I really didn't want to stack on a bunch of additional parts and another interface for just this one simple (from the users' PoV) task.

Except that you don't need lots of parts-- if all you want is the "timer" one, you can just install the mod and delete all the parts except that one.

And it really is a breeze to use, very simple and intuitive.  Speaking as a player, I'd rather go the Smart Parts way than to have additional UI clutter in the action-groups window.  It's a natural, flexible, elegant design, very easy to understand and learn, and also easy and intuitive when building ships in the VAB.

It's the correct answer to this particular problem, IMO.  In other words:  even if I did want to solve the "timed sequence of events" problem, I'd be more likely to implement a design like Smart Parts than to try to shoehorn it into DefaultActionGroups.  So... since SmartParts already exists, I see no reason to reinvent this particular wheel.

[Tyko]

6 minutes ago, Snark said:

It's a neat idea, but not really in scope for this mod.  What you're describing is an "automation" feature, and while there's absolutely nothing wrong with that in general, it's not what I myself am into-- I don't want to automate KSP for myself, it's not a feature that I myself would ever use.  (Plus, in my own gameplay, there's never any situation where I need two things to happen in rapid succession.  Either I want them to happen simultaneously (in which case I just put them in the same stage or action group), or else they're far enough apart that I can just press two buttons one after the other.

I primarily mod for myself-- i.e. when there's something about the stock game that bugs me, that I wish worked differently.  So I write the mod to make the game work the way I, personally, want it to... and then I share the mod on the off chance that there are other people who might have a similar preference.    In general it's worked out pretty well, I think... but it does mean that I have practically zero motivation to spend any time on a feature that I myself don't want for my gameplay.

Thanks for replying.  

[Snark]

48 minutes ago, Tyko said:

Thanks for replying.  

No problem. 

Incidentally, if you'd like to see some examples of the relevant "Smart Parts" parts in action, take a look at this challenge thread I posted a couple of years ago:

 

 

[FlyAlpha]

Very helpful thanks ! May I suggest adding toggling service bays and cargo bays to some action group, as well as one to run all experiments on the vessel (crew report, temperature, goo etc...) ?

[PunningLinguist]

Your solar panel config is matching the stock flat panels (the OX-STAT and OX-STAT-XL), as they also use ModuleDeployableSolarPanel. This doesn't affect anything on a functional level (since there's no action to add to the action group) but it does modify their description.

One possible fix (and what I've personally done) is to change the config for the retractable panels to the following:

@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[~retractable[false],~isTracking[false]]] {

 

[Snark]

13 hours ago, PunningLinguist said:

Your solar panel config is matching the stock flat panels (the OX-STAT and OX-STAT-XL), as they also use ModuleDeployableSolarPanel. This doesn't affect anything on a functional level (since there's no action to add to the action group) but it does modify their description.

One possible fix (and what I've personally done) is to change the config for the retractable panels to the following:

@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[~retractable[false],~isTracking[false]]] {

 

Hmm, interesting!  Thanks for catching.

Would it not be a better match, though, to go for the animationName property, instead of relying on retractable and isTracking?  After all, a solar panel that's actually deployable is going to have to specify an animation name-- whereas I could imagine an actually deployable solar panel that isn't retractable or tracking.

[PunningLinguist]

2 hours ago, Snark said:

Would it not be a better match, though, to go for the animationName property, instead of relying on retractable and isTracking?

Using animationName instead of isTracking to filter out the flat panels makes sense, but shouldn't it still avoid matching the retractable panels since they're handled in the other half of the config?

[Snark]

55 minutes ago, PunningLinguist said:

Using animationName instead of isTracking to filter out the flat panels makes sense, but shouldn't it still avoid matching the retractable panels since they're handled in the other half of the config?

Yes, there are undoubtedly certain complexities involved.    I haven't gone through it in detail yet-- main thing is just to be aware of the issue, which I now am, thanks to you!

So thank you for that, and a detailed solution will involve further head-scratching. 

[Tonka Crash]

@Snark I've run into an issue with Nertea's Heat Control Mod that I just started using. It has some non-retractable radiators that weren't deploying with my other radiators. Since stock doesn't have radiators like this, the configs included with DefaultActionGroups don't cover this case.

Locally I've updated my Radiators_in_Custom02.cfg to mimic the solar panel configs for both retractable and non-retractable radiators. This fixes the issue.

Another change I do locally is change the color of the added text to orange so it stands out a in the description.

Spoiler

// Active radiators are toggled via Custom02.
// Thanks to JackDraak in the KSP forums for suggesting the idea!

// Static radiators
@PART[*]:HAS[@MODULE[ModuleActiveRadiator],!MODULE[ModuleDeployableRadiator]] {
        @description ^= :(.)$:$0 \n<color=orange>Radiator toggles via Custom02</color>:
        MODULE {
                name = ModuleDefaultActionGroup
                moduleSource = ModuleActiveRadiator
                actionGuiName = Toggle Radiator
                defaultActionGroup = Custom02
        }
}

// The retractable panels get "Toggle" added to group Custom02.
@PART[*]:HAS[@MODULE[ModuleDeployableRadiator]:HAS[~retractable[false]]] {
        @description ^= :(.)$:$0 \n<color=orange>Radiator toggles via Custom02</color>:
        MODULE {
                name = ModuleDefaultActionGroup
                moduleSource = ModuleDeployableRadiator
                actionGuiName = Toggle Radiator
                defaultActionGroup = Custom02
        }
}

// The non-retractable panels get "Extend" added to group Custom02.
@PART[*]:HAS[@MODULE[ModuleDeployableRadiator]:HAS[#retractable[false]]] {
        @description ^= :(.)$:$0 \n<color=orange>Radiator extends via Custom02</color>:
        MODULE {
                name = ModuleDefaultActionGroup
                moduleSource = ModuleDeployableRadiator
                actionGuiName = Extend Radiator
                defaultActionGroup = Custom02
        }
}

 

 

[Snark]

Hi gang,

Just a note that I've released DefaultActionGroups v1.3.  No new features, just a compatibility update for KSP 1.8.

[Atlas Gaming]

Hey so I like the idea of this, but after installing and looking at the .cfg files I'm wondering why I need the defaultactiongroups.dll? I already use .cfg files with some custom patches in modulemanager. So what does the dll do that the .cfg files alone do not?

[Snark]

On 12/8/2019 at 3:52 PM, Atlas Gaming said:

looking at the .cfg files I'm wondering why I need the defaultactiongroups.dll?

Because if you look at those .cfg files that come with the mod, you'll notice that they all use a PartModule called ModuleDefaultActionGroup, whose implementation lives in DefaultActionGroups.dll.

In other words, the .cfg files won't work without the DLL.  The DLL is where the mod's custom functionality is implemented. The .cfg files then connect that functionality to the specific parts involved.  It's how part-affecting mods work, generally.

[Atlas Gaming]

Got it.. so module manager alone won't add that functionality. 

[Snark]

6 hours ago, Atlas Gaming said:

Got it.. so module manager alone won't add that functionality. 

Correct. ModuleManager doesn't actually add any functionality to the game.  It's not what it's for.  All it does is provide a way to do "patches" to config files-- it doesn't have the power to make those config files cause special effects in the game.

Code is what provides functionality-- whether it's stock code that comes from Squad with the game, or mod code that adds new functionality.  Config just tells the code where and how to apply that functionality.  (You can think of the code as being a car, and the config as being the driver of the car.  Driver doesn't go anywhere without a car.) 

[Atlas Gaming]

I have used Module manager alone to tweak some aspects of the game so it can be used alone. I appreciate the simplified explanation, but I've written mods in unreal engine... just not in Unity.

And a big thanks to you for all the mods for Kerbin - makes the game so much better!

Edited December 11, 2019 by Atlas Gaming

[Snark]

2 hours ago, Atlas Gaming said:

I have used Module manager alone to tweak some aspects of the game so it can be used alone.

Oh sure, absolutely.  It's just that if you use it alone, the only stuff you can put in the .cfg files is stock stuff.  If the config refers to custom code, then the code has to be there for it to work.

[XLjedi]

4 hours ago, Snark said:

Oh sure, absolutely.  It's just that if you use it alone, the only stuff you can put in the .cfg files is stock stuff.  If the config refers to custom code, then the code has to be there for it to work.

True…  I have used Mod Manager to add new code/script segments to stock parts for instance.  Which added a function to a part that it didn't have in stock (multiple skin variant options).  But yeah, the underlying code is what allows parts to have variants.  I can't script in something like "Shoot cool laser beams!"  LOL

I was however, pleasantly surprised with what I could do with Mod Mgr scripts.  It let me do more than I expected.

Edited December 12, 2019 by XLjedi

[Rodger]

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.