Hierarchic order of command modules

[NWM]

Let see a common situation:

There is interplanetary ship docked to a space station. Something like this:

Space station - Interplanetary tug - Command Module (a smaller ship) - Lander - Rover

Let start our space travel:

- Each time when two module got separated one of the module get a stupid name, renaming, but after a docking one of them lost its name.

- Each time using an action group activated, the "dormant" modules also get it - I mean: pushing a button for turn off one of the engine of the Tug and the Lander opens its solar panels. Solution: share the action groups among the modules - yes, we can use 2 a.g./module.

What is "Hierarchic order of command pods" would do:

Each "module" has a command pod of its own. In the VAB I give an hierarchic number to each command pod (0-9), name, type, and separated set of action groups.

If there is more command pod in a module, for example a capsule and a remote guidance unit - they can be equals it means they work as one and same unit, or in hierarchy: master-slave, or alternative (can change the master slave relation): for example an orbital builder has two modules. one of them has the actions of the normal ship, another controls the robotic arm. Changing the status of the command pods also possible with action groups.

The hierarchic order of the previous station-ship looks like this:

(0) A - "Station" - Space Station: PPD-12 Cupola Module = RC-L01

(1) D - "Interplanetary Tug" - Ship: RC L01

(3) D - "Command Module" - Ship: Mk1-2 Command pod = RC-001S

(6) D - "Lander" - Lander: Mk2 Lander Can

(9) D - "Rover" - Rover: EAS-1 External Command Seat

At the beginning of our travel I retract the solar panel of the station - I can use 0-9 to command my active station, because the docked ship is dormant.

Activating the interplanetary tug, and docking off the station - Now my remaining ship's name and type has the highest command module's data in the hierarchy: "Interplanetary Tug" - Ship ! (and not Space Station Probe - Probe!)

And now I can use the full range of the action groups, because the CM, Lander and the Rover is dormant till their tasks...

So the benefits:

- No more renaming after each separation.

- More efficient use of action groups.

And now, let see your opinions and ideas...

Edited August 18, 2014 by NWM

[thereaverofdarkness]

one of those little things that will only be well-received. I support.

[Stratoroc]

yes please

[Haifi]

That sir would be a very good thing to have, but i fear the behaviour we all know and dislike could be one of the limitations of KSP / Unity. Due to the tree structure the craft files use it could be impossible to circumvent this behaviour.

I hope you find a solution!

Best regards

[Sasuga]

That sir would be a very good thing to have, but i fear the behaviour we all know and dislike could be one of the limitations of KSP / Unity. Due to the tree structure the craft files use it could be impossible to circumvent this behaviour.

I hope you find a solution!

Best regards

Not necessarily. What would need to happen is that each piece would have to know which module owned it. When setting up the commands, the player would have to select the piece (as they do now) and the command module, and then set up t

I think the easiest way to do this would be to have a list of available command modules in the Action Groups Menu. If there's only one command module, the list of command modules could be hidden, the Action Groups Menu looks the way it does now to reduce clutter and confusion for new players who are just figuring out the action group menu.

If there's more then one command module, a 4th column could appear to the left of the Action Groups column with a list of the available command modules, listed in the order they were added to the vehicle, and then the player can select which command module they want, then the action group they want, then the piece they want, and then the commands they want.

To make the list easier to understand, and to deal with the naming issues, the player could name each command module and the list could display the names in the list. Also, the vehicle could be named whichever name the command module in charge has.

=-=-=-=

As far as how hard it is to program, well I don't know anything about Squad's code at all. So, I CAN'T REALLY speak to its difficulty or anything... but, as I've used Unity on a daily basis I know I could program it in a game similar to Kerbal Space Program. - I know the engine can handle it.

- But knowing the engine can handle it doesn't mean that it wouldn't require a lot of rewriting or something on Squad's part.

- So, in other words, it could be a feature they could add with some solid planning and a day of programming, or a feature that would require a complete rewriting and add a year or more to the project. ... My experience in game programming makes the think its somewhere in the middle, but hey, again; I haven't seen their code.

=-=-=-=-=

I haven't personally experienced the issues that the original poster has expressed, but I can see how they're a hassle. I totally support this feature request/idea. I think it belongs in this game, and I hope it gets put in.

Edited August 20, 2014 by Sasuga

[NWM]

I'm glad to see your answers and tips! I hope this topic won't sink without effect like my previous suggestions (Variant of parts, etc...).

This idea needs some refinement, thats is the right way of using the forums. Choosing the actual command module in Action Groups menu is a good example of constructive and cooperative replying. I've also some more idea, like the command pods can have a description text too over the name, type and set of action groups, and those could be read and edited by a LMC on the command pod. As the topic became more mature, I'll extend the opening post. (GUI plan, block diagrams, etc...)