Automation integrated systems

[mattinoz]

On 4/3/2022 at 4:28 AM, shdwlrd said:

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. 

Yes every command pod should be fit for a purpose any features for that purpose should be assumed to be installed by the engineer in the design team responsible. 

Sure pods would get better over time have more function to service new purpose but should fit a mission profile the player would currently be targeting. Sure that probably means a bigger range of Pods or support pods. I mean you wouldn't send an Apollo to Mars so you shouldn't expect it to have the function required to get there. 

 

[shdwlrd]

1 hour ago, mattinoz said:

Sure pods would get better over time have more function to service new purpose but should fit a mission profile the player would currently be targeting. Sure that probably means a bigger range of Pods or support pods. I mean you wouldn't send an Apollo to Mars so you shouldn't expect it to have the function required to get there. 

I see your point, but consider this. Do you rip out a cockpit of a plane, frame and all just to update the avionics? No, you just remove the old avionics and replace them with new ones. There are planes out there that were built before glass cockpits were a thing, but have been updated with glass cockpits. You don't have to update the structure of a command pod to update the capabilities. That's the whole point I'm trying to convey. You can use the MK3 pod for a lander, main control point, an escape capsule, a reentry vehicle, separately or together. It does make sense to be able to add or remove functionally as needed. Not to have dozens to pods that looks the same that do slightly different things. That we the whole point of my gripe earlier in the thread, it's stupid to add or repeat parts to add functionality to crafts. Just add the functionally to the one part and be done with it. 

PS, don't know if you're being sarcastic with using the Apollo lander for Mars. We both know that it wouldn't work because the Apollo landers only have enough thrust & DV to land on the moon and return to orbit. But to directly answer your remark, it wouldn't matter. The flight control systems on the Apollo landers relied on different sensors to determine it's position in space. How the craft reacts would depend on the programing, and the programing can be changed. So the Apollo lander could be used to land on Mars, as long as the correct landing profile was programed into the flight control computer.

[mrgreco]

[mrgreco]

thats my problum,  i would love to have a user interface , like a tablet that helps balance ------>  ///system heat ////wasteheat/////coreheat////thermalheat  whatever heat it will help balace and convert or even trancmit but that being said its prim foctions are to manage heat and power , secendery foctions would be like atmo harvisting antimatter harvieting oh and shipbuilding mosly making probe surfce scanersas you genarate scince the systum is generating knowedge for your to function alittle better and better and as it learns this it will inprove in foction power syply and in  in as a joke the system will make mistakes and will have to rebout and in that mistake nothin mayjor might of turn on lights or shut off an isru       this is a 400 plus part /exploration/shipbuilder/harvsiter sciene lab expariments      and it will need a computercorebuildin body of the ship and will need supercoolet fuel new fule modfor only the core   to cool fisrt gen dell cpu's LOL  and as it learnsn it self upgrades to 2 gen and so on and you get pick the cpu's     and mybe for later on ideas cores can talk to eachother in ther own code and learn off each other       so beckle in cuz you and your core are going on a jurney    LOL whatever       oh and if you pull the core out to put it in an other ship it will lose mybe more then what its lernt and degrde a few gens       and as a joke put on the core in big red caps  LAUGHING AT CORE AFTER MAKEING A MISTAKE COULD MAKE YOUR SHIP EXPLODE       just kidding     i  never made a mod, and this will  take me forever to make  sooo if anyones up for the task on making this  leave me message i got 64 mods and i use them all   and after this task is cumplete not only you have a new friend ill even toss a donation for your hardwork  godbless you all  have a great day      i got more testing to so back in the vab

[shdwlrd]

Without directly quoting anyone, my opinion is the possible stock implementation of function control for craft would depend on the primary purpose of the craft.

If the craft is meant as a rover, choosing a ground configuration would change how the SAS works, ignore commands that are used in flight, (Ex. Ignoring pitch and roll inputs.) disable some map/ui functions used for flight while adding functions that are better suited for ground operation.

If a craft is to be used as an atmospheric plane, then choosing plane mode would again change how the SAS functions, change the map/ui functions available, allow for input remapping to better suit atmospheric flight. (Ex. Better access to the control surface trims.)

If the craft would be used as a space craft, the controls and functions would be the same as the currently are in KSP1. This would be the default setting as it could be used in all scenarios.

Anything beyond these 3 settings would be a mod. So if you wanted to add automatic functions, autopilots, improved functions beyond stock, those could be modded in using the above examples.

 

[Vl3d]

On 4/1/2022 at 12:23 PM, Vl3d said:

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.

I believe the devs can decide what functions to implement in stock as long as there is a base system which allows more control over rocket software design. But I think the principles stated above are helpful to implement practical automation and not abstract away automation. Having MechJeb functions implemented in stock allows recording or scripting key-actions for craft used on resource runs, for example. They can be late game tech for the player, but they should be there. Seeing automated craft moving around would create an interesting and busy world that feels alive.

[t_v]

1 hour ago, shdwlrd said:

Without directly quoting anyone, my opinion is the possible stock implementation of function control for craft would depend on the primary purpose of the craft.

If the craft is meant as a rover, choosing a ground configuration would change how the SAS works, ignore commands that are used in flight, (Ex. Ignoring pitch and roll inputs.) disable some map/ui functions used for flight while adding functions that are better suited for ground operation.

If a craft is to be used as an atmospheric plane, then choosing plane mode would again change how the SAS functions, change the map/ui functions available, allow for input remapping to better suit atmospheric flight. (Ex. Better access to the control surface trims.)

If the craft would be used as a space craft, the controls and functions would be the same as the currently are in KSP1. This would be the default setting as it could be used in all scenarios.

Anything beyond these 3 settings would be a mod. So if you wanted to add automatic functions, autopilots, improved functions beyond stock, those could be modded in using the above examples.

 

I definitely agree with those settings- but I would like them to be customizable. I think that this thread is actually about two different things, one is the new telemetry and functions on craft and the other is the implementation of an automation system. I think that automation shouldn’t be there by default. I’m not opposed to it, but I think it should not be incentivized to keep the focus on manual flight. But I want a layer of depth to what features you want, so that just like you can’t have a perfect engine, you can’t make a perfect pod. A GPS system to show you what areas are not good for driving (recycling examples) is beneficial for a rover, but what if your rover also has a limited VTOL mode to get up and down cliffs? Instead of only having presets, you can mix and match what you want. And I definitely think that having presets is a good thing so that people can just fly their rocket without needing to fiddle with its capabilities.

Remember, all suggestions from here on out are not for release day but instead for potential future updates, so ambitious suggestions and ones that aren’t really important for the initial release are ok. I think the devs are taking a look every once in a while and adding things to their roadmap. 
 

So, putting aside the topic of automating vehicle movement, what do you think of a modular capabilities system as opposed to a set of capabilities for each pod or a few different presets to choose between?

[shdwlrd]

On 4/1/2022 at 4:23 AM, Vl3d said:

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 personal take on this.

1. No, using rendezvous and docking as an example. I personally will take a hour and a half to two hours to rendezvous and dock. Most of the time spent docking. MJ can do the same in about 15min. Everyone doesn't have the time to spend getting good at a game.

2. Everything in KSP can get repetitive. So everything can get automated?  Seriously, allow the user to choose what they want to automate. If the user wants to directly control their craft, awesome. If the user just wants to plan the route and just ride along, awesome.

3. No extra parts for crafts, part modules are ok. No unsuitable parts for colonies. Costs should be in line with what the item is used for.

4. Colonies only. Colonies can instruct craft. Command pods and probes control the crafts functions.

5. Doesn't make sense. Not everything you want to automate can be recorded. (Launching resupply missions when X resource is below 25%.)

6. I agree with plan everything, but get rid of the recording. See above.

7. Agree with that one.

[shdwlrd]

3 hours ago, t_v said:

-snipped- see below

Remember, all suggestions from here on out are not for release day but instead for potential future updates, so ambitious suggestions and ones that aren’t really important for the initial release are ok. I think the devs are taking a look every once in a while and adding things to their roadmap. 
 

So, putting aside the topic of automating vehicle movement, what do you think of a modular capabilities system as opposed to a set of capabilities for each pod or a few different presets to choose between?

Very true, I've gotten the same sense. But when everyone is so focused on craft automation and ignoring background automation for colonies and logistics, might as well put input for both. I'd rather concentrate on the colony and logistics automation than craft automation. My opinion on autopilots and such is all over other threads. And to this day, there are players that believe KSP should be played manually with no QoL features. Whom every says otherwise is playing the game wrong, yada-yada-yada. Until a moderator shuts down the thread.

Very little discussion on the background automation has been meaningful. Just abstract ideas, no real meat to the idea. Nothing to really discuss. I have a better picture of what I like to see now compared to when the game was announced. But any discussion goes to autopilots and craft. (Well how else are background resource transfers supposed to happen. Shesh.) See what I mean, you can't have one without the other. Sadly they are interconnected and the argument about autopilots will win. 

Edited April 5, 2022 by shdwlrd

[Vl3d]

Because designing a good craft is just the first step to mass production. Remember what Elon always says: designing a prototype is 100 times easier than designing the factory to build it en-masse.

We can do everything manually at the beginning - colonies included. But instead of piloting the same mission or doing the same tasks we should focus on building better craft versions and a better logistics network. Let the kerbals do their thing - but give them the best tools!

[Vl3d]

1 hour ago, t_v said:

what do you think of a modular capabilities system as opposed to a set of capabilities for each pod or a few different presets to choose between

I think we can have both if we separate command & control (software) from pods.

Have a place on the pod/probe to add some hardware part (my idea was the computing core) which has an inventory where you can add a selection of modules as a kind of operating system.

Physically upgrade the hardware capabilities (mechanical, electric or electronic, computational power). From a key tech onwards, you can wirelessly update the software and mechjeb automation is at the end of the tech tree as AI.

Add whichever modules you prefer and use what you want. Pilot manually if you prefer. But enpower the player to choose.

Separately from craft design have overview management systems (as building or apps), like the tracking station, journey planner, logistics network etc.

[shdwlrd]

1 hour ago, Vl3d said:

Because designing a good craft is just the first step to mass production. Remember what Elon always says: designing a prototype is 100 times easier than designing the factory to build it en-masse.

We can do everything manually at the beginning - colonies included. But instead of piloting the same mission or doing the same tasks we should focus on building better craft versions and a better logistics network. Let the kerbals do their thing - but give them the best tools!

Very true with both statements. The Kerbals don't have to be puppets where you have to control everything they do. Let them do their thing.

1 hour ago, Vl3d said:

Separately from craft design have overview management systems (as building or apps), like the tracking station, journey planner, logistics network etc.

One central source for information will be necessary. Also, one central source for planning. The need to manipulate your background logistics easily and efficiently will grow as your colonies do. The more bases/colonies/shipments/Kerbals you have, the greater the need not to waste time manually doing stuff. The buildings can be present at the KSC or built on the colonies themselves. (I like the idea of having them both at the KSC and colonies. That way you don't have to leave a colony to update your logistics network or transfer some Kerbals from another colony or put a new freighter into production.) They will have to be visually distinctive compared to the other hab structures so you can easily find them. Or they can be accessed by can PAW in the colony. 

[shdwlrd]

3 hours ago, t_v said:

I definitely agree with those settings- but I would like them to be customizable. I think that this thread is actually about two different things, one is the new telemetry and functions on craft and the other is the implementation of an automation system. I think that automation shouldn’t be there by default. I’m not opposed to it, but I think it should not be incentivized to keep the focus on manual flight. But I want a layer of depth to what features you want, so that just like you can’t have a perfect engine, you can’t make a perfect pod. A GPS system to show you what areas are not good for driving (recycling examples) is beneficial for a rover, but what if your rover also has a limited VTOL mode to get up and down cliffs? Instead of only having presets, you can mix and match what you want. And I definitely think that having presets is a good thing so that people can just fly their rocket without needing to fiddle with its capabilities.

Everything I suggested would be the stock defaults. There is no reason not to have the different sub functions being modular. What I suggested would add different QoL features without having to rely on a mod to do something, nor bringing a true autopilot into the game. Image how much easier rovers would be to control is the SAS actually behaved like a car SAS? How much easier would it be if the roll controls didn't get passed to the vehicle unless you needed them. How much easier would you be able to fly planes if you could actually set the trim? How much did you want to remap your controls depending on the use case for the craft? No hidden or impossible to use commands because you can't release a key or didn't know the key bind existed. (Like the trim keys.) 

The example of the VTOL rover, there would be nothing stopping you to add enough flight specific settings for make it functional VTOL. But you would have to select the mode you want, flight mode or driving mode. (That doesn't mean you can't do either or in the wrong mode, just having it in the correct mode would make life easier.) But at some point, you can make it too complicated, so finding the right balance is key.

[Vl3d]

5 hours ago, shdwlrd said:

you would have to select the mode you want, flight mode or driving mode

Yes, yes! +1 to transforming craft QoL improvements

First add transforming craft / mode switch module. Change physical configuration, set correct orientation when switching modes.

Define (and add appropriate modules):

Thruster flight mode using:

- advanced SAS module

- VTOL module (variable engine thrust for horizontal stability)

- RCS module

- autopilot module (hover assist, take-off to orbit, landing etc.)

- specialized action groups

Rover mode using:

- traction control module (electronic suspension, brake balance)

- autopilot module (GPS pathing, hazard avoidance, cruise control etc.)

- specialized action groups

You decide what else. And then you can also record a trip by adding an extra automation / AI module. Or you can add a scripting module and write procedures using all available functions.

It can get as complicated as you prefer or it can be very simple. The main take is having the software modules system as a separate entity.

Edited April 5, 2022 by Vl3d

[Vl3d]

It just dawned on me. I'm not saying it should be in stock, but think about it.

If you have scriptable autopilot functions added as modules and a journey / science planner you can actually make accurate science missions with pre-programmed probes and rovers, while also having comms delay (send and forget / you can watch it but not control it real time).

And it would be a lot easier to use than kOS because you would just chain together MechJeb (autopilot) actions triggered conditionally by sensors and smart parts using an interface similar to Scratch (puzzle-type programming language for kids). You could later change the s/w modules and "script" by remote upload (if you didn't crash), while being limited by hardware.

Think about how fun it would be to send the missions and see them fail or success based on your design and programming. It would capture the essence of unmanned space exploration.

This way you can really make comms delay a stock toggle (based on difficulty). Depending on distance from kerbal pilot there would be control thresholds - if kerbal is in the same SOI as the probe and you have signal you can manually control it. The system would actually encourage manned missions and space stations!

PS:

Simple key autopilot actions chains (basic autopilot scripting) solves a big problem that exists in the record-previously-manually-controlled-journey automation approach. It would solve the wait-for-transfer-window problem because it could dynamically adapt to celestial body positions and configuration.

Edited April 5, 2022 by Vl3d
focus

[shdwlrd]

@Vl3d Since you added your idea on different flight control schemes. I figured I would add my ideas. 

Spoiler

Rules for SAS. The SAS will be used in a manner that does change the base programming. Any actions will be considered a secondary function.

Space mode: This is the default control profile. Everything behaves as you would expect from stock KSP.

Drive mode: 
    1) Changes the control orientation to match gravity. (You still must orient the command pod or probe core properly. Small details.)
    2) Changes the key binding. The WASD along with Z & X key bindings change. No flight inputs will be passed to the craft. (Ex, pitch up or down)
        W: Forward, increase speed
        S: Reverse, decrease speed, cancel cruise
        A: turn left
        D: turn right
        Z: Cruise control, holds set speed until canceled, wheels only
        X: cancel cruise
    3) Changes the behavior of the SAS. 
    The SAS will try to cancel the roll of the craft during a turn by actively rolling to the opposite direction. This could be tunable for different craft type using the     stock torque slider. It will ignore automatic pitch or yaw inputs. 
        Options: 
        Bearing hold: It will try to keep your craft going straight. Doesn’t actively steer.
        Override: Allows the full function of the SAS and temporarily allows pitch, roll, and yaw commands to affect the craft. Useful for flipping you craft back to         the correct orientation. Stunts if you like.
    4) UI changes: Changes the velocity gauge to something easily understandable. Switchable.
    5) Map changes: Shows your direction of travel. No AP/PE info shown when airborne.
Flight Mode:
    1) Changes the control orientation to match gravity. (You still must orient the command pod or probe core properly. Small details.)
    2) Changes the key binding. IJKL would be switched to trim controls. (Optional for VTOLs to allow for sideslip maneuvers.)
    3) No changes to the basic operation of the SAS. Only new selectable options. All options can be overridden by user inputs.
        Options:
        Pitch control: Will try to hold your crafts orientation for level flight. Useful for bank turns. You don’t have to add any inputs to hold your altitude.
        Roll control: Will try to level the craft along the roll axis.
        Prograde hold: Holds prograde, what else would it do.
    4) UI changes: none as of right now.
    5) Map changes: 
        Removes AP/PE markers.
        Shows direction of travel according to prograde.
        Shows impact point for maximum unpowered glide distance.