Automation integrated systems

[Vl3d]

I know how controversial this subject is, I have read some long threads about it. I think we can have a constructive discussion if we stick to a few principles:

1. Clearly state the specific problem we are trying to solve.

2. Talk about ways (paradigms) to implement the automation solution.

I will make a list of identified problems and ways to solve them through automation in this OP. I will centralize ideas (new and existing) and update regularly.

I am not concerned about the learning process and how the levels of automation are unlocked according to experience, knowledge and skill levels. This is for the devs to decide. I am more concerned about paradigms to implement automation, using:

A. Parts

B. Interface tools

C. Scripting

D. Recording

 

Guiding principles:

1. Do everything manually at least once.

2. If it gets repetitive, automate it.

3. Everything is a part (module) with an associated cost.

4. Centralize command and control.

5. Record only what you can automate.

6. Plan anything you can record.

7. All interfaces have a unified look.

 

My suggestions:

I think that every automation process should have a corresponding part that gets added (or upgraded) on the craft, as it's tradition. So A is closely related to B, C and D.

This is why I think we should have a integrated system, a central Command & Control Core (CCC) part, where we could add automation modules (as parts). So everything related to automation would become a module (like installing software on a PC). And each module would then have it's GUI representation - up to the devs / modders.

- So we know that stock KSP1 already has automation baked in mainly through action groups, SAS, RCS and KAL-1000. I feel like all of these should be modules for the CCC.

- Unfortunately one significant thing that's missing is conditional triggers. This is fixed by the SmartParts mod, which I feel should be stock as modules for the CCC.

- We should have a telemetry module that centralized all information regarding craft sensors and components state.

- We should also have a science module for the CCC, where we can have an overview of all instruments, experiments and sensors.

- All MechJeb features related to automation I think should be stock as CCC modules parts in a simplified, easy to use format (like SAS). You decide what to use if you can afford the parts and if you unlocked them. It should be a construction decision, not an interface decision. If you want to be able to hover, add a hover module. If you want to automate ascent / rendezvous / docking / landing / maneuver nodes execution - add the appropriate modules.

- KOS should also be a module you could add to the Command & Control Core. It would interact with all other modules and with craft state information. This way we could easily create abstraction layers for scripting (interact with MechJeb, SAS, SmartParts, action groups, telemetry etc).

- Journey recorder should be a module and it should only be able to record and re-do flying and rover driving if you have all the other necessary modules on-board (you can't record docking / landing / maneuver execution without MechJeb docking / landing / maneuver automation modules etc.). It should be linked to the journey planner for a clear overview of logistics.

- There should also be a colony CCC building and modules for base related automation.

- Future mods regarding automation should be integrated as modules for the CCC, not direct game interface add-ons (they would have module GUIs with a unified look). I don't know how it would work exactly, but it would look more streamlined and everything would be managed by the CCC.

- Fuel distribution automation for center of mass control.

- Thrust / vectoring / RCS control - modules (if engine parts support them). It would allow us to control VTOL and transformer craft.

- Aerodynamic surfaces control - centralized as a module.

- Have a CCC progression (mechanical -> electric -> electronic -> computer -> machine learning / AI). And then you can also upgrade the CCC hardware for any type of pod/probe and also update the software (with modules).

- Initially on primitive craft replace modules like hardware components, but later be able to wirelessly update modules. But CCC hardware upgrades could only be done physically.

Other automation ideas:

- Manufacturing planner: build N craft of type X, economics overview etc.

- Logistics planner: similar to journey planner, related to manufacturing planner. Would manage automated resources transportation routes.

- Science planner: automate experiments, have overview of available science parts per craft, check realtime sensors - R&D extension.

I will add more ideas...

Edited April 3, 2022 by Vl3d

[shdwlrd]

I don't know how to approach this without sounding hyper critical, no offense is intended.

The problem with the overall automation setup is everyone thinks that you need a new part for every function. I've hate having to add warts to my craft to get a specific function. I will just patch the parts out and add the functionality to the appropriate stock parts. Did I mention I hate ship warts? Just make it so when you build the craft you can add the functions you want before launch.

Now if you want to add a control center to the KSC or colony, I'm down for that. It makes sense to have one centralized building for that function. But don't make me build a new building for each function if the buildings are equivalent to 10 story office buildings. You can host several businesses in that type of space. So at that point, it becomes a waste of materials to add functionality in that manner.

Now with that out of the way. I like to have the ability to add one centralized building to control all your logistics, production, gathering, and crew/colonists. Something like that would be very useful once you have several colonies operational and have your transfer routes established. You wouldn't have to play "where is he?" or "who's doing what?" game. It would get very tedious bouncing around to figure out what's going on in the background, and making adjustments to your production and gathering  individually. It would make sense to be able to make global adjustments that effect all your colonies.

This should be available once you establish your first colony, but the true sense of the power of this shouldn't be realized until you have a few colonies operational. The cost shouldn't be more than a standard habitation building to construct. The cost would be with the required manpower to efficiently run the operation. Maybe 5-20 workers per section depending on what function they need to control. (You don't really need many Kerbals for production control, but for HR (Kerbal Resources?) that can vary with the total number of colonists you have.)

[Vl3d]

5 hours ago, shdwlrd said:

hate having to add warts to my craft to get a specific function

I agree with you, this is why I suggested having just a Command & Control Core that can get added to pods or probe cores. It can be something like the inventory system in KSP1, it can have upgradable size. And then you can add modules to the CCC which are special electronic parts (that cannot be added like a regular part on the ship).

Again: Imagine the CCC being like an inventory system where you add special electronic parts called modules corresponding to functions as described in OP. No warts. Modules would be the new thing.

Imagine: Pod / probe core has a place for a Command & Control Core part. CCC is a unique part that has space (like an inventory) for modules. You add the modules according to the functions you want and save the CCC as a kind of subassembly part. You can then place the CCC inside any pod / probe.

Last time: All control and automation functions are modules that get placed inside the CCC part that can be saved as a submodule and then added to Pods or Probe Cores.

Edited April 2, 2022 by Vl3d

[shdwlrd]

11 hours ago, Vl3d said:

I agree with you, this is why I suggested having just a Command & Control Core that can get added to pods or probe cores.

It's still a part. Why just add it to the command pods or probe cores and then you select the functions you want before launch. If you want to update, you will need another VAB, maintenance area, or engineer to update the software list. This way you don't have to recover or tear apart a craft in the field to update it. 

[t_v]

I agree with @shdwlrd that having it as a part creates some limitations but I also really like the idea of being able to use the same pod for more complex tasks as the game goes on. Instead of having a new mk.1 pod for every tech level with set capabilities for each pod, have one or a few different pods which have a different (or upgradable?) amount of “hard drive space/processing power”. I think that difficulty settings could determine what you start with, because I tried removing all telemetry but visual once and it was fun for me but would definitely not be fun for someone else. That way, you can use the larger probe core functionality on a small probe core once you get the tech to pack all that fancy “rotate to target” software. It always bugged me that there weren’t tech options that made the best probes smaller as we see in real life with smaller electronics. 
 

As for the annoyances of it being a part, that doesn’t necessarily have to happen. Yes, there could be a dedicated computer part just like there are dedicated SAS parts, but replacing software could be as easy as having a connection the the KSC. But, a really old pod would not be able to fit all the specialized software that a new pod of the same model could. This could be annoying but it would incentivize not just letting stuff sit around forever, and if course an engineer (or scientist?) could upgrade the tech. 
 

An application of this could be the specialization of different craft. Is your rover going to go flying? If not, it can free up some space to get a GPS navigator to tell you where to avoid all those rock fields while driving  If yes, you might want to install a module that allows you to lock an exact pitch/altitude, heading and speed while in atmospheric flight. Are you using ion engines or a Daedalus? You might need a new maneuver planner where you set your thrust and see your trajectory as that thrust continues being applied until the next maneuver (change in thrust). 
 

The next problem is how to not make the process of selecting your software tedious as you get into the endgame and still keep it customizable. I’ll get to this later, but for now, default settings and bundles of modules would probably help.

 

[Bej Kerman]

Can just be a mod

[t_v]

True, but I feel that this could also fit the stock experience. Maybe not the way that it is currently proposed but in some form. 

[Bej Kerman]

1 minute ago, t_v said:

True, but I feel that this could also fit the stock experience. Maybe not the way that it is currently proposed but in some form. 

KSP at its core is about building and flying, but not waiting.

[Vl3d]

3 hours ago, shdwlrd said:

update the software list. This way you don't have to recover or tear apart a craft in the field to update it. 

I agree, wireless update of software modules is probably a better idea than changing electronic modules. Or maybe it can be realistic and have a progression of some kind (mechanical -> electric -> electronic -> computer -> machine learning / AI). And then you can also upgrade the hardware for more module inventory space or higher level functions. It can be a really interesting and educational mini-game on its own.

1 hour ago, t_v said:

use the larger probe core functionality on a small probe core once you get the tech to pack all that fancy “rotate to target” software

 That's a great idea, I always wanted to have that in KSP1. Then you only need a probe core per size and you can just upgrade it as you progress.

1 hour ago, t_v said:

the specialization of different craft.

I would love to have saved as some kind of subassemblies different module packs depending on craft specialization. It would really make me think about software and function design. Rover vs first stage control and automation - completely different needs.

1 hour ago, Bej Kerman said:

just be a mod

I think having software modules with specialized functions and a centralized command and control (mechanical, electrical, electronic, computer or ML/AI) is actually a structural change to gameplay and would be a big improvement. People would actually start thinking about aeronautics and space software engineering and design. And it would allow practical automation of craft, based on predefined or recorded chains of commands and progressive capabilities. You can actually build mods using this model that expands it.

Craft command & control / software and automation management should be a standalone integrated system with layers of control and abstraction. And I think realism oriented players and modders would love it.

Edited April 2, 2022 by Vl3d
typos

[Bej Kerman]

4 minutes ago, Vl3d said:

I think having software modules with specialized functions and a centralized command and control (mechanical, electrical, electronic, computer or ML/AI) is actually a structural change to gameplay and would be a big improvement.

*Improvement only as seen by people who would believe such a thing to be an improvement

* Improvement in the form of a mod

[Vl3d]

I believe there's a big difference in quality of gameplay between having a solid basis for logistics and automation (which uses real in-game mechanics = parts / modules) and just abstracting everything away by magic. Let me give you two examples:

1. Designing and building a reusable first stage with actual hardware capabilities (CCC + smart parts) and software capabilities (modules). Then "programming" it (journey / action planner + mechjeb style automation). Then seeing it actually return to base and land. Then mass producing that model and launching N such rockets and actually watching them return to base.

VERSUS

Just abstracting everything away and after staging assuming it did some previously "recorded" action and was magically recovered and funds / resources / components returned to us.

2. Designing and building a rover to transport mined resources back to the colony. Mass producing it and managing the logistics. Actually seeing your creation roam around the planet.

VERSUS

Just abstracting everything away and seeing a +100 from time to time in the resources stockpile value.

I sincerely believe automation should not be abstracted away. I think we should be proud seeing our creations roaming and flying around doing stuff.

Edited April 2, 2022 by Vl3d

[t_v]

3 hours ago, Bej Kerman said:

KSP at its core is about building and flying, but not waiting.

3 hours ago, Bej Kerman said:

*Improvement only as seen by people who would believe such a thing to be an improvement

* Improvement in the form of a mod

Alright, I see what you mean, and I am of the strong opinion that KSP should be mostly about building and flying vehicles with a few engaging gameplay systems directly connected to space flight. In this case, this improves on the “building rockets” part but I understand that not everyone will want to engage with this system. For comparison, if you don’t want to engage with other systems such as the electricity system when building, you can simply turn on infinite electricity and not have to deal with that. So, I’ll defend my position that this could make a good addition to the stock game, but with the caveat that it has to be well designed to not be tedious, and needs to have an easy way to circumvent (cheats) or ignore (default software in each pod) the system. 

[t_v]

On the other hand, it is up to the developers which  systems to include. It looks like colonies and space manufacturing will be one, as well as what seems to be an expanded heat system and a more complex selection of resources to manage. I’m happy with all of those, others might not be, and the important part is that auxiliary (not core) systems are not impossible to circumvent if you don’t want to engage with them. 

[Bej Kerman]

12 hours ago, t_v said:

I am of the strong opinion that KSP should be mostly about building and flying vehicles with a few engaging gameplay systems directly connected to space flight.

Yes

12 hours ago, t_v said:

For comparison, if you don’t want to engage with other systems such as the electricity system when building, you can simply turn on infinite electricity and not have to deal with that.

That's cheating and electricity is easy

12 hours ago, t_v said:

So, I’ll defend my position that this could make a good addition to the stock game, but with the caveat that it has to be well designed to not be tedious, and needs to have an easy way to circumvent (cheats) or ignore (default software in each pod) the system. 

Players shouldn't be cheating in the first place. This entire idea only works as a mod.

[t_v]

So really, your issue with this is that it falls above your personal threshold of complexity, because you are fine dealing with electricity but not simplified software. I was mentioning cheating to demonstrate an example of how players who don’t want to deal with systems can circumvent them, like I’m sure you won’t want to deal with software and some people won’t want to deal with balancing supply routes. The important part that I probably didn’t convey properly is that the game is still playable without those systems. Each pod has a limited supply of electricity which should be enough for basic operations, and you can simply set up colonies that produce most of what they need to make supply routes simple, between two colonies at most. Each pod coming with a default configuration works to make the game playable without fiddling with that gameplay. For example, I’m not sure if you ever tried this, but in KSP 1, you can set fuel flow priorities to make fuel flow from certain tanks first. That opens up a new design aspect, but if you never choose to change the priorities, the default fuel flow will be fine in nearly all applications. There’s lots of examples like this, from mono propellant to heat, where you technically don’t need to install mono prop tanks, EVA thrusters or radiators if you don’t want to because pods have those and heat dissipates automatically. 
 

I guess what I’m asking for is an explanation of how this is objectively different from the other complex systems that fit into stock already. Not based on its complexity because that is arbitrary, but rather give me a valid reason why this would narrow the audience too much seeing as you don’t actually have to interact with it. 

[Bej Kerman]

54 minutes ago, t_v said:

So really, your issue with this is that it falls above your personal threshold of complexity, because you are fine dealing with electricity but not simplified software. I was mentioning cheating to demonstrate an example of how players who don’t want to deal with systems can circumvent them, like I’m sure you won’t want to deal with software and some people won’t want to deal with balancing supply routes. The important part that I probably didn’t convey properly is that the game is still playable without those systems. Each pod has a limited supply of electricity which should be enough for basic operations, and you can simply set up colonies that produce most of what they need to make supply routes simple, between two colonies at most. Each pod coming with a default configuration works to make the game playable without fiddling with that gameplay. For example, I’m not sure if you ever tried this, but in KSP 1, you can set fuel flow priorities to make fuel flow from certain tanks first. That opens up a new design aspect, but if you never choose to change the priorities, the default fuel flow will be fine in nearly all applications. There’s lots of examples like this, from mono propellant to heat, where you technically don’t need to install mono prop tanks, EVA thrusters or radiators if you don’t want to because pods have those and heat dissipates automatically. 
 

I guess what I’m asking for is an explanation of how this is objectively different from the other complex systems that fit into stock already. Not based on its complexity because that is arbitrary, but rather give me a valid reason why this would narrow the audience too much seeing as you don’t actually have to interact with it. 

KSP is only about building and flying rockets. Beyond making sure players aren't trapped in pointless, grindy and monotonous milk runs, automation deserves to die.

[Vl3d]

40 minutes ago, Bej Kerman said:

automation deserves to die

That's your opinion, thank you for sharing it! I hope other players also engage in constructive dialogue.

[mrgreco]

im thinking one interface !!!!!!!!! not with every screen its anoolying   2 options automated or manul to ship systum parts in manul you set it , and forget it, in automated you tell it not to go anyhighter then the number you requested or lower try to stay around ,,,whatever     for power ,,,,, exe    keep power at 70% but if falls below its say 49% reactor picks up or automaticly shuts down secendery functions like ISRU and use back up Batteris but you have to tell it to doo these things in advance,,, you just have to make sure it see the part and unstandes it ,,,,, i hope this made sence    and im so sorry about my spelling 

[mrgreco]

21 hours ago, t_v said:

So really, your issue with this is that it falls above your personal threshold of complexity, because you are fine dealing with electricity but not simplified software. I was mentioning cheating to demonstrate an example of how players who don’t want to deal with systems can circumvent them, like I’m sure you won’t want to deal with software and some people won’t want to deal with balancing supply routes. The important part that I probably didn’t convey properly is that the game is still playable without those systems. Each pod has a limited supply of electricity which should be enough for basic operations, and you can simply set up colonies that produce most of what they need to make supply routes simple, between two colonies at most. Each pod coming with a default configuration works to make the game playable without fiddling with that gameplay. For example, I’m not sure if you ever tried this, but in KSP 1, you can set fuel flow priorities to make fuel flow from certain tanks first. That opens up a new design aspect, but if you never choose to change the priorities, the default fuel flow will be fine in nearly all applications. There’s lots of examples like this, from mono propellant to heat, where you technically don’t need to install mono prop tanks, EVA thrusters or radiators if you don’t want to because pods have those and heat dissipates automatically. 
 

I guess what I’m asking for is an explanation of how this is objectively different from the other complex systems that fit into stock already. Not based on its complexity because that is arbitrary, but rather give me a valid reason why this would narrow the audience too much seeing as you don’t actually have to interact with it. 

t-v i understand what your sayin ok now try to look at this in a diffrent view, part count pc performence, and how we all know how this game just loves to eat up all your goddam ram, then craps out memory leak thats my reason and im pretty sure thats his reason so please go a little easy on the cheat thing,,, good day to you

[snip]

21 hours ago, t_v said:

So really, your issue with this is that it falls above your personal threshold of complexity, because you are fine dealing with electricity but not simplified software. I was mentioning cheating to demonstrate an example of how players who don’t want to deal with systems can circumvent them, like I’m sure you won’t want to deal with software and some people won’t want to deal with balancing supply routes. The important part that I probably didn’t convey properly is that the game is still playable without those systems. Each pod has a limited supply of electricity which should be enough for basic operations, and you can simply set up colonies that produce most of what they need to make supply routes simple, between two colonies at most. Each pod coming with a default configuration works to make the game playable without fiddling with that gameplay. For example, I’m not sure if you ever tried this, but in KSP 1, you can set fuel flow priorities to make fuel flow from certain tanks first. That opens up a new design aspect, but if you never choose to change the priorities, the default fuel flow will be fine in nearly all applications. There’s lots of examples like this, from mono propellant to heat, where you technically don’t need to install mono prop tanks, EVA thrusters or radiators if you don’t want to because pods have those and heat dissipates automatically. 
 

I guess what I’m asking for is an explanation of how this is objectively different from the other complex systems that fit into stock already. Not based on its complexity because that is arbitrary, but rather give me a valid reason why this would narrow the audience too much seeing as you don’t actually have to interact with it. 

i thought the topic was automated with ship parts

omg NVM mybad

[Vanamonde]

Some remarks removed. Don't make it personal, please. 

[mrgreco]

oh i dint , i just mixed up the 2 windows

[Bej Kerman]

2 hours ago, mrgreco said:

t-v i understand what your sayin ok now try to look at this in a diffrent view, part count pc performence, and how we all know how this game just loves to eat up all your goddam ram, then craps out memory leak thats my reason and im pretty sure thats his reason so please go a little easy on the cheat thing,,, good day to you

Rephrase please?

Edited April 3, 2022 by Vanamonde

[mrgreco]

i got the coments mixed up sorry

[mrgreco]

i would like to make a all purpose generator that ataches to your ship and pulls in any form of heat then converts it to elelictric and or megajoles and have the option to turn those off and on of your chooin purpos it to lower partcount  thats all

[Bej Kerman]

57 minutes ago, mrgreco said:

i would like to make a all purpose generator that ataches to your ship and pulls in any form of heat then converts it to elelictric and or megajoles and have the option to turn those off and on of your chooin purpos it to lower partcount  thats all

Is it realistic?