Jump to content

more options with action groups (inherit from context menus)


Recommended Posts

The options that some parts have for action groups seems rather limited (or even a bit arbitrary).  For example on an Elevon you can set action groups to toggle, extend and retract.  But on the context menu for the same Elevon there are quite a few more actions available; state toggle (which covers the action group options), deploy toggle (inverted or normal) and a toggle for pitch, roll and yaw.  

The action group options "extend" and "retract" are kind of pointless when you have "toggle" and the really useful one to have as an action group (the deploy toggle) just isn't available as an action group option (the other toggle could be useful too with certain designs). In order to change deploy state in flight you have to use context menus (which while coming into land at speed can be tricky!).
Looking at the small landing gear, while it has almost all context menu actions available as action group actions there is no action group option for toggling the brake (I don't mean applying the brakes, I mean enabling/disabling them on a particular wheel).  

So my main point is;
We need more action group options available, in fact everything that can be done via context menus should be doable via action groups.

 

This leads me to my second point, (programmer hat on) which is about the implementation logic for action groups and context menus;
There is quite a difference on some parts between what's available on context menus and what's available as action group options.  Obviously there is overlap, but there's a lot of difference too.  It seems to me that there must be two separate definitions for what's available in action groups and what's available on context menus.  That's not very DRY (coder term; Don't Repeat Yourself). 

There shouldn't be two definitions, there should just be a definition of what appears in context menus and the options available in action groups should simply inherit that (with the exception of any sliders). Anything that exists as a togglable thing in a context menu should automatically be available as a togglable action group.  (A good, complete design should also have a option to set a flag to exclude a context menu toggle from action groups, but that should be a rare exception rather than the norm.)

The current implementation implies that someone had to think about what's available in context menus vs what's available in action groups, and maybe they did think about all the insane things we may want to do.  By having action groups inheriting their options from the context menu options it means that it doesn't require anyone to think about what's available; the functionality of the part defines what's needed in the context menu and that automatically takes care of the action groups. The result is more functionality available via action groups, it fulfils the expectation that anything you can do via context menu you can do via action groups and the implementation is simpler (should be less code) and less rule bound.


Aside; further enhancements to action groups.

Spoiler

I feel that action groups, while being a very important and useful feature, have been rather poorly implemented.  For one thing they should be a stageable object (object in the OO sense of the word).  By which I mean they should be able to behave like any other stageable part so if you want you could drag an action group into the stage list so it's triggered when a certain stage is fired (but still be able to trigger it again with 0-9).  

There should be an infinite number of action groups (obviously we don't need a infinite number, but the implementation should scale.  Why build in limitations/rules when it's less code to have more functionality).  Yes there are only 0-9 keys available for them.  But + and - are still free (IIRC).  So we could have "pages" of action groups, each page with 10 actions and you switch which page of actions you're on with + and - (with some small indicator to single which page you're on).  You'd have 0-9 on the first page set to the key actions you need, but then by changing page 0-9 now have a different set of actions.  ie: You could have a setup where your first page of action groups deals with in-flight actions, but then when you land (in say your mining rig) you could switch to page 2 and now you have your mining actions, when you want to fly again, switch back to page 1.

I know there is a mod to enhance action groups (actually never tried it out), but I really feel this is an important aspect and the stock game should have a more polished implementation for this.

 

Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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