Jump to content

Potential changes to probe cores


Recommended Posts

Here's my idea to make probes more realistic, while adding stock mechjeb in a fair way:

Step 1: add communication delay. The way this would work is pretty simple. A time delay is added between when a command (like pitch up) is given and when it is initiated. The further you are from Kerbin the longer it takes. To compensate this probe cores will be given automation such as being able to execute maneuvers automatically and on higher level cores avoiding danger.

Step 2: add mechjeb like automation to probe cores, the features form a hierarchy like this:

  • Stayputnik: same features as in the stock game, plus communication delay, no SAS.
  • Okto: Same as stayputnik but has SAS, smart A.S.S, and prograde retrograde lock.
  • Hecs: Same as Okto, but can automatically execute maneuver and has maneuver lock.
  • Okto2: Same as hecs but also has normal/antinormal and radial in/out lock.
  • Rovemate: Same as hecs but has a bon voyage like rover autopilot. It is limited to a top speed of 0.05 m/s though.
  • Small remote guidance unit: Same as Okto2, but has target mode and target lock.
  • Large remote guidance unit: Same as the small one, but it has support for auto gravity turn and orbital insertion, as well as the ability to run simple kos like scripts.
  • Hecs2: Same as large remote guidance except it has more advanced kos
  • Hecs3: A new probe core that can be set to stabilize its orbit automatically if is on an impact trajectory. Has also features of hecs2
  • Dodec: A new probe core that can automatically orbit and transfer to any body and has full kos. All features of Hecs3
  • Dodec2: all probe core features and full mechjeb and kos.

Step 3: change what Kerbals can do:

Kerbals can now:

  • Increase the top speed of the rovemate to 15 m/s.
  • Use probe core specific features like smart A.S.S. without time delay.

Kerbals can no longer:

  • Use docking mode.
  • Use target mode on navball.

My ideas aren't perfect, but they get the point across, so what do you guys think of the idea and how it should be implemented?

Edited by catloaf
Link to post
Share on other sites

I like the idea of having a kOS system stock though I hope there would be a VPL that can be over written with text that the written code the VPL is based on (so essentially both a VPL and regular scripted language). Perhaps earlier cores would only allow the VPL and the amount of types of code one can use would be dependent on tech level (earlier probes having very limited features and the library of features grows along with probe tech level).

As for restricting kerbal abilities, I disagree. There are too few reasons to actually use kerbals already and nerfing them more would only make this problem worse.

Link to post
Share on other sites

The limitations of probe cores especially on lower limits is a good idea. I 95% agree with everything. But I feel the later ones are a bit OP, I guess it would be higher tier meaning more advanced though. We are talking about a game with metallic hydrogen and "torch drives" so nothing is out of the ballpark

Link to post
Share on other sites
50 minutes ago, mcwaffles2003 said:

 

As for restricting kerbal abilities, I disagree. There are too few reasons to actually use kerbals already and nerfing them more would only make this problem worse.

Not really, the main benefit of kerbals in this system would be no comm delay and being able to use the probe cores features without delay. This means that that probe core and the Kerbals are useless for docking outside of LKO separately, but provide a ksp1 like experience together. Plus comm delay is such a big rebalance to probe cores that it arguably makes Kerbals more useless not less. This is more realistic too, because astronauts fly with a lot of help from computers. Also making both Kerbals and probes have advantages and disadvantages would be better than the stock system of one making you feel guilty when you kill them and the other needing constant ec.

1 hour ago, The Doodling Astronaut said:

The limitations of probe cores especially on lower limits is a good idea. I 95% agree with everything. But I feel the later ones are a bit OP, I guess it would be higher tier meaning more advanced though. We are talking about a game with metallic hydrogen and "torch drives" so nothing is out of the ballpark

Your correct, everything beyond small remote guidance is future tech, and everything beyond hecs3 is fusion tier tech. Dodec 2 is antimatter level tech. 

Link to post
Share on other sites
2 hours ago, catloaf said:

Step 1: add communication delay.

And here you lost me, 2 reasons:

  1. I like manually flying things, I have nothing against mechjeb-like automation, as long as it doesn't prevent me from manually flying my probes and rockets.
  2. When you're piloting anything you're not interpreting a Kerbal in the KSC directly piloting the craft, you're interpreting the probe onboard systems.

I would love to have a KOS-like system (maybe a VPL with a Python/Lua option), but not forced like this.

Link to post
Share on other sites
2 minutes ago, Master39 said:

And here you lost me, 2 reasons:

  1. I like manually flying things, I have nothing against mechjeb-like automation, as long as it doesn't prevent me from manually flying my probes and rockets.
  2. When you're piloting anything you're not interpreting a Kerbal in the KSC directly piloting the craft, you're interpreting the probe onboard systems.

I would love to have a KOS-like system (maybe a VPL with a Python/Lua option), but not forced like this.

Comm delay could be a difficulty setting

Link to post
Share on other sites

I think that all the probe cores should be upgradable. The Stayputnik could get increasing levels of SAS as the tech tree advances. If SAS can fit into a tiny Okto 2, the same capabilities should be able to fit into a Stayputnik body. That gives us more flexibility when designing satellites.

One way to do that is to decouple the probe shape from the SAS level. Probe bodies get unlocked on the tech tree but are mostly structural parts with just basic manual controls, and space for 1 SAS control module. The control module gets unlocked later with increasing levels of SAS as you progress up the tech tree.

In KSP 1 I deal with that by starting with the probe body that I want, then clipping in a 2nd small probe like the Okto 2 if I want a higher level of SAS. It's sloppy and can trigger bugs.

Link to post
Share on other sites
22 minutes ago, catloaf said:

Comm delay could be a difficulty setting

Let's assume you'll have both KOS-like and Mechjeb automation, you either are close enough for direct control or you're so far that direct control is nothing but a delay between on the "run" button for the automation you must have prepared, basically just another "On/Off" condition like the presence of signal with Commnet.

You just end up with another, redundant, "no control" condition, just with some minor differences between it and commnet "no signal".

 

Also I don't think signal delay could be a difficulty setting, an option, sure, but based on how you implement automation it can range from "you just have a 'do the piloting stuff' button" all the way up to "you need a full team of programmers, astronomers and mathematicians to write an actual probe OS" and regardless of where you want the game balance to be, you can just replace the whole signal delay thing with a simpler "you can't control probes directly outside Kerbin's SOI" (or, better, outside the SOI of a body with a colony equipped with a Space Center facility, let's remember that the KSC will not be the only KSC in KSP2) and have the same result.

 

Also, you just killed a whole probe category.

Link to post
Share on other sites
2 hours ago, catloaf said:

Not really, the main benefit of kerbals in this system would be no comm delay and being able to use the probe cores features without delay. This means that that probe core and the Kerbals are useless for docking outside of LKO separately, but provide a ksp1 like experience together. Plus comm delay is such a big rebalance to probe cores that it arguably makes Kerbals more useless not less. This is more realistic too, because astronauts fly with a lot of help from computers. Also making both Kerbals and probes have advantages and disadvantages would be better than the stock system of one making you feel guilty when you kill them and the other needing constant ec.

Sorry, I somehow missed you mentioning comm delay.  Also, I think you meant "useful" here, no?

Link to post
Share on other sites

For comms delay to make any sense at all and not just be an easily bypassable artifact it would need to be ever-present. No magic instant hands-on flying at all ever of a probe core craft regardless of its sophistication or the distance. If you want to experience what this is like even right now and see if you enjoy it in a game, load up any craft in KSP1 large enough to push your clock into red and then try to fly it. Fun, isn't it? That's simulating a reaction delay that numbers in the seconds. Now extrapolate this 'fun' into minutes and hours.

So it would at the very least need to be an entirely optional setting - only for when we actively choose to punish ourselves instead of spending some relaxing off-time on a game. Ok, so assuming complete optionality, the only reason to offer this optional functionality would be in the guise of realism. In which case there can really be no half measures. So.

It would only make sense going to the extent of implementing this, at all, if we can only watch the results of our programming. In the earliest cheapest cores, it would be preprogrammed before launch; with later more expensive cores, we could have fully reprogrammable probe cores that can independently perform conditional branching sequences of steps.

If there's gonna be probe cores, any probe cores, that effectively turn craft into quantum-entangled AI avatars with faster-than-light local awareness, reaction time, and free will, comms delay would still just be another artificial nuisance in the guise of 'leveling', that basically relegates Kerbals to entirely optional lab-rats instead of the end-game. So pick one.

I'm not inherently against a native kOS implementation connected to losing the option of 'live' flying a core-controlled craft, which is what this would amount to, but the tiering would need to be inherently different than what you propose. A more realistic form of leveling would be based on limited core memory and sensors. Making working with early cores more about programming efficiency and compromise on what our craft will be able to do. "At this level, we can make it circularize, or we can make it run an experiment... but not both, unless we make two craft that each do one of these tasks" - that sort of thing.

Any form of 'live' or non-programmed control of any craft would then strictly be a kerbal-only feature, penalized by needing the extra weight of life-supporting cabins etc. That doesn't necessarily force probe cores to be used before kerbals... historically we've definitely risked test pilots before we sent automated craft, up to a point, so in a career play I could see that happening too. At the same time, kerbals would have to be amputated of their magic android brains - ie. kerbals don't have advanced chips or gyros implanted in their heads to magically determine when they are pointing prograde/radial/normal, so they'd only ever be able to do those things if there's also a probe core installed with that preprogrammed capability to show it on their dials or consoles.

Anything short of the above would be just as artificial and unrealistic as the current implementation and defeat the whole point of putting this into the game, in which case I will always go for the more enjoyable game-like concept of flying by hand with instant faster-than-light comms.

Link to post
Share on other sites
29 minutes ago, swjr-swis said:

For comms delay to make any sense at all and not just be an easily bypassable artifact it would need to be ever-present. No magic instant hands-on flying at all ever of a probe core craft regardless of its sophistication or the distance. If you want to experience what this is like even right now and see if you enjoy it in a game, load up any craft in KSP1 large enough to push your clock into red and then try to fly it. Fun, isn't it? That's simulating a reaction delay that numbers in the seconds. Now extrapolate this 'fun' into minutes and hours.

So it would at the very least need to be an entirely optional setting - only for when we actively choose to punish ourselves instead of spending some relaxing off-time on a game. Ok, so assuming complete optionality, the only reason to offer this optional functionality would be in the guise of realism. In which case there can really be no half measures. So.

It would only make sense going to the extent of implementing this, at all, if we can only watch the results of our programming. In the earliest cheapest cores, it would be preprogrammed before launch; with later more expensive cores, we could have fully reprogrammable probe cores that can independently perform conditional branching sequences of steps.

If there's gonna be probe cores, any probe cores, that effectively turn craft into quantum-entangled AI avatars with faster-than-light local awareness, reaction time, and free will, comms delay would still just be another artificial nuisance in the guise of 'leveling', that basically relegates Kerbals to entirely optional lab-rats instead of the end-game. So pick one.

I'm not inherently against a native kOS implementation connected to losing the option of 'live' flying a core-controlled craft, which is what this would amount to, but the tiering would need to be inherently different than what you propose. A more realistic form of leveling would be based on limited core memory and sensors. Making working with early cores more about programming efficiency and compromise on what our craft will be able to do. "At this level, we can make it circularize, or we can make it run an experiment... but not both, unless we make two craft that each do one of these tasks" - that sort of thing.

Any form of 'live' or non-programmed control of any craft would then strictly be a kerbal-only feature, penalized by needing the extra weight of life-supporting cabins etc. That doesn't necessarily force probe cores to be used before kerbals... historically we've definitely risked test pilots before we sent automated craft, up to a point, so in a career play I could see that happening too. At the same time, kerbals would have to be amputated of their magic android brains - ie. kerbals don't have advanced chips or gyros implanted in their heads to magically determine when they are pointing prograde/radial/normal, so they'd only ever be able to do those things if there's also a probe core installed with that preprogrammed capability to show it on their dials or consoles.

Anything short of the above would be just as artificial and unrealistic as the current implementation and defeat the whole point of putting this into the game, in which case I will always go for the more enjoyable game-like concept of flying by hand with instant faster-than-light comms.

Isn't this position a bit extreme? With RemoteTech and MechJeb there is probe delay but you need to just program maneuvers ahead of time and writing scripts isn't exactly necessary. So long as the delay is less than the time until the maneuver the probe should function.

Link to post
Share on other sites
36 minutes ago, mcwaffles2003 said:

Isn't this position a bit extreme?

Isn't signal delay a bit extreme to start with? You're basically killing flying any probe manually outside Kerbin's SOI.

If we're going for extreme realism to have extreme difficulty you need kOS, otherwhise it's just "realism for the sake of realism" and it's quite pointless to have such an extreme feature just to have as an outcome to have to be a spectator instead of a player.

 

Link to post
Share on other sites
14 minutes ago, Master39 said:

Isn't signal delay a bit extreme to start with? You're basically killing flying any probe manually outside Kerbin's SOI.

If we're going for extreme realism to have extreme difficulty you need kOS, otherwhise it's just "realism for the sake of realism" and it's quite pointless to have such an extreme feature just to have as an outcome to have to be a spectator instead of a player.

 

I disagree, you shouldn't be forced to learn programming to play a game though it would be awesome if that was available as well. Also, it wouldn't be realism for the sake of realism, it would make using kerbals actually have a real benefit, it would add balance. If you want that kind of real-time control, send a pilot. As of right now, there is not only no reason to send kerbals (besides planting flags, collecting EVAs or surface samples, and LULZ) but it is actively disincentivized since their command pods add more dry mass to a craft, specifically the final stage which is the worst place to add dry mass.

Link to post
Share on other sites
26 minutes ago, mcwaffles2003 said:

Isn't this position a bit extreme? With RemoteTech and MechJeb there is probe delay but you need to just program maneuvers ahead of time and writing scripts isn't exactly necessary.

Hmm.

If the argument for asking such a feature is a genuine wish for enhanced realism, it needs to be consistent over the whole breadth of the simulation. It also needs to offer the same options to deal with it as in real life. Else it's just an arbitrary request to change the rules of the game to whatever our particular flavour of the month is, ie. cherry-picking what aspects of 'real' we want to have, while effectively still being able to circumvent it at will, simultaneously limiting our ways to handle it because RPG. You say 'extreme' - I counter 'whimsical'.

Yes, we want comms delay, but no, we don't want to deal with all the very real inconveniences that come with acknowledging and dealing with the limitations of lightspeed propagation at astronomic distances in spacetime, and we don't want to allow the flexibility of the solutions we have used in reality so let's simplify that. So just these and these please, but not those, thank you. Can I have it in a paper bag please?

Eg. we entirely disregard that we can still effectively control and affect SPACETIME ITSELF in various ways and once we send a control message we can and very likely will FAST FORWARD TIME to make the reality of time delay immediately irrelevant (because who has time to wait for the actual travel time of a signal, we want to see our craft enter orbit now, not in three years), but let's pretend on just this particular detail that we don't have those powers even if we're totally using them anyway. On that same note, we don't need no stinkin' ((p)re)programmable cores because it's 'real enough' (oh the irony) to pretend a limited predecided set of actions is enough to cover all possible use cases of sending a spacecraft into the unknown perils of space.

Realism. Yeet.

Note that I didn't say I don't want it in the game. But if it is, as an option, it should implement the actual inconveniences of the concept, as well as the options we have found to deal with it. Anything less is really just a request for change of game rules to a different set of rules. We already have plenty of half-implemented realism options in KSP1 without the equivalent realistic tools to deal with them (G-forces effects, part-depth limits, buoyancy, even aerodynamics/drag).

Link to post
Share on other sites
16 minutes ago, mcwaffles2003 said:

I disagree, you shouldn't be forced to learn programming to play a game though it would be awesome if that was available as well.

And that's my position too on scripting in KSP, I would want it but not as a mandatory feature.

 

17 minutes ago, mcwaffles2003 said:

Also, it wouldn't be realism for the sake of realism, it would make using kerbals actually have a real benefit, it would add balance. If you want that kind of real-time control, send a pilot. As of right now, there is not only no reason to send kerbals (besides planting flags, collecting EVAs or surface samples, and LULZ) but it is actively disincentivized since their command pods add more dry mass to a craft, specifically the final stage which is the worst place to add dry mass.

You do that by adding things to do to Kerbals, not by removing possibilities from probes, I don't want to have to hire a team of engineers just to do this, and that's absolutely relevant since we have countless realistic actually proposed designs of flying probes, an already confirmed one (the Dragonfly mission to Titan) and even one on its way to Mars right now.

In the list of reason of why we want to send humans instead of robots to other planets the delay of comunications isn't even there, just make Kerbal useful on their own instead of deleting 80% of the viable probe designs.

Link to post
Share on other sites
11 hours ago, swjr-swis said:

Yes, we want comms delay, but no, we don't want to deal with all the very real inconveniences that come with acknowledging and dealing with the limitations of lightspeed propagation at astronomic distances in spacetime, and we don't want to allow the flexibility of the solutions we have used in reality so let's simplify that. So just these and these please, but not those, thank you. Can I have it in a paper bag please?

I don't see how not forcing players to learn programming circumvents this... the core reason you brought this up still is now an issue:

13 hours ago, swjr-swis said:

For comms delay to make any sense at all and not just be an easily bypassable artifact it would need to be ever-present. No magic instant hands-on flying at all ever of a probe core craft regardless of its sophistication or the distance. If you want to experience what this is like even right now and see if you enjoy it in a game, load up any craft in KSP1 large enough to push your clock into red and then try to fly it. Fun, isn't it? That's simulating a reaction delay that numbers in the seconds. Now extrapolate this 'fun' into minutes and hours.

So there would be reaction delay. You can't just fly a probe with split second manual timing anymore and every maneuver has to be planned ahead.

11 hours ago, swjr-swis said:

Eg. we entirely disregard that we can still effectively control and affect SPACETIME ITSELF in various ways and once we send a control message we can and very likely will FAST FORWARD TIME to make the reality of time delay immediately irrelevant (because who has time to wait for the actual travel time of a signal, we want to see our craft enter orbit now, not in three years), but let's pretend on just this particular detail that we don't have those powers even if we're totally using them anyway.

The fact that we can timewarp doesn't alleviate this, it just means we don't have to sit there for months waiting to play a game.

11 hours ago, swjr-swis said:

On that same note, we don't need no stinkin' ((p)re)programmable cores because it's 'real enough' (oh the irony) to pretend a limited predecided set of actions is enough to cover all possible use cases of sending a spacecraft into the unknown perils of space.

I never suggested not having programming be available, I do hope programmable core makes it into the game but a base requirement for the game shouldn't be knowledge of how to program.

11 hours ago, swjr-swis said:

Realism. Yeet.

Note that I didn't say I don't want it in the game. But if it is, as an option, it should implement the actual inconveniences of the concept, as well as the options we have found to deal with it. Anything less is really just a request for change of game rules to a different set of rules. We already have plenty of half-implemented realism options in KSP1 without the equivalent realistic tools to deal with them (G-forces effects, part-depth limits, buoyancy, even aerodynamics/drag).

The inconvenience of not being able to react in real time with the probe is still there... This hasn't circumvented that issue at all and I believe it should be front and center for probes. 

12 hours ago, Master39 said:

You do that by adding things to do to Kerbals, not by removing possibilities from probes, I don't want to have to hire a team of engineers just to do this, and that's absolutely relevant since we have countless realistic actually proposed designs of flying probes, an already confirmed one (the Dragonfly mission to Titan) and even one on its way to Mars right now.

In the list of reason of why we want to send humans instead of robots to other planets the delay of comunications isn't even there, just make Kerbal useful on their own instead of deleting 80% of the viable probe designs.

How would you feel about having the delay being tied to the nearest kerbal with comms? Then if a kerbal is at the planet with the probe and they have a way to link to the probe then the delay would only be on a millisecond level.

 

Link to post
Share on other sites
29 minutes ago, mcwaffles2003 said:

I don't see how not forcing players to learn programming circumvents this... the core reason you brought this up still is now an issue

You highlight and connect the wrong parts, hence the rest doesn't make sense. Ok.

Being able to pre-program control is "the flexibility of the solutions we have used in reality", which you then say (paraphrased)

"nah that's not necessary or not required". So in your implementation of this, we get all the inconveniences of real life, but not the main tool by which we deal with them. What I'm saying is: if we get one, I want the other too. Else we're just asking for another arbitrary inconvenience in the game based on someone's particular preference.

 

47 minutes ago, mcwaffles2003 said:

but a base requirement for the game shouldn't be knowledge of how to program.

When presented with a universe where all the direct control actions you would normally employ to adapt trajectories, react to deviations, and make your craft perform all the things it is meant to do... yes, you will absolutely need to know how to program. That can be a literal programming or scripting language, or it can be more graphical in nature like how they implemented the mission system. But crippling my ways of controlling the craft to just a very limited set of basic actions like 'at such time perform maneuver X' will NOT be even close to enough. Just think a moment how many distinct manual control actions you take while flying a mission yourself, even the simplest ones.

Trigger action groups. Perform experiments, collect data, reset experiments, rinse and repeat at next biome. Deploy control surfaces/chutes. Inflate shields. Open cargo bays. Activate brakes. Adjust deployment sliders. Execute corrections to pre-conceived maneuvers because of how the tiniest initial deviation/error will multiply when dealing with such enormous distances, and you won't know until you're there. Adjust attitude while aerobraking. Time the firing and cutting off of a suicide burn to the exact trajectory taken through the atmosphere. Etc etc etc.

NONE of these things can be done LIVE in a consistent and honest implementation of comms delay. Many of them would be TIME CRITICAL and impossible to perform with a time delay of more than a few seconds, let alone minutes or hours. Yes, I absolutely HAVE to be able to program steps for each and every one of those situations I can reasonably expect to happen in my mission, or the whole mission is dead in the water before we even launch.

So. I have no objection to getting comms delay as an extra difficulty option to the game. But don't then make my life/game harder by throwing in 'realism' and at the same time denying me the very real and required tools to deal with that. Either both of those things, or I'm not interested. KSP1 is full enough of that kind of half-done 'features', and we end up dealing with them by either gaming/working around/magic-washing the system in stock, or by installing mods. Let's please not do that with KSP2 from the onset already.

 

Link to post
Share on other sites

First of all, I don't want comm delay if there is no scripting. You can't add a real problem without the real solution.

I also don't want scripting if it isn't accessible. That's not to say I want everyone to be forced to use a graphical language, I also want the option of text scripting for those who want it (including me.)

Third, I've come up with a solution to the potential annoyingness of comm delay, which is to allow you to control the probe real time in a "simulation". The simulations quality can be upgraded with funds and science. The science is stuff like scansat and telescopes to make the simulation close to reality, allowing you to do things like picking a flat spot to land in (because inaccuracies and limitations of the simulation mean that you can't safely land on slopes, without risking the probe tipping over.) The better the simulation, the closer to reality, and the less likely your probe will smash into the ground when it thinks is 100 meters above it. This creates natural progression from orbiters to landers.

And finally, it has to be a setting or else I don't want it. I understand that s one may prefer the old behavior and that's fine and I respect it. I don't want a feature that a large portion of people will really dislike to be shoved down everyone's throat. 

Edit: to make scripting better, perhaps the script could actually create keyboard inputs.

Link to post
Share on other sites
5 hours ago, swjr-swis said:

You highlight and connect the wrong parts, hence the rest doesn't make sense. Ok.

Being able to pre-program control is "the flexibility of the solutions we have used in reality", which you then say (paraphrased)

"nah that's not necessary or not required". So in your implementation of this, we get all the inconveniences of real life, but not the main tool by which we deal with them. What I'm saying is: if we get one, I want the other too. Else we're just asking for another arbitrary inconvenience in the game based on someone's particular preference.

I never said I didn't want programming available, I do, just I dont want that to be the only available solution. I don't think it would be asking much to have mechjeb put in as stock, but I would also hope that we could see a VPL, like simple rockets 2 has, where you can also program with text in the same language the VPL is written in.

Effectively I think this could offer a new, optional, and separate difficulty ladder players could climb, and maybe accidentally learn to program, when it comes to probes where the greater the difficulty you pursue the greater the nuance of control you have. 

  1. No difficulty - fly probes only in near vicinity of kerbal presence and only pilot manned craft far from other kerbals
  2. Low difficulty - Use a system like mechjeb, it has limited and very basic features but offers the base necessities to function a probe through a landing mission
  3. Medium difficulty - Learn to use the VPL including an array of classes and the ability to create your own functions and conditional statements similar to the video mentioned earlier
  4. High difficulty - Effectively kOS
Link to post
Share on other sites
8 hours ago, mcwaffles2003 said:

How would you feel about having the delay being tied to the nearest kerbal with comms? Then if a kerbal is at the planet with the probe and they have a way to link to the probe then the delay would only be on a millisecond level.

The Martian, that mission plan would be impossible without a real team of NASA engineers.

My last 3 or 5 planetary mission had always the ascent veichles landing on the target body with the rover and the base a whole launch window before the Kerbals even leave Kerbin.

Something as common and simple as that becomes impossible unless you put a magical "just land everything at the same place" in the mechjeb analogue, but at that point all this feature is doing is removing difficulty instead of adding it.

 

2 hours ago, catloaf said:

Third, I've come up with a solution to the potential annoyingness of comm delay, which is to allow you to control the probe real time in a "simulation". The simulations quality can be upgraded with funds and science. The science is stuff like scansat and telescopes to make the simulation close to reality, allowing you to do things like picking a flat spot to land in (because inaccuracies and limitations of the simulation mean that you can't safely land on slopes, without risking the probe tipping over.) The better the simulation, the closer to reality, and the less likely your probe will smash into the ground when it thinks is 100 meters above it. This creates natural progression from orbiters to landers.

I'm ok with the simulator idea, it would be useful, but without the "no useful direct control outside Kerbin's SOI" part.

 

41 minutes ago, mcwaffles2003 said:

Effectively I think this could offer a new, optional, and separate difficulty ladder players could climb, and maybe accidentally learn to program, when it comes to probes where the greater the difficulty you pursue the greater the nuance of control you have. 

  1. No difficulty - fly probes only in near vicinity of kerbal presence and only pilot manned craft far from other kerbals
  2. Low difficulty - Use a system like mechjeb, it has limited and very basic features but offers the base necessities to function a probe through a landing mission
  3. Medium difficulty - Learn to use the VPL including an array of classes and the ability to create your own functions and conditional statements similar to the video mentioned earlier
  4. High difficulty - Effectively kOS

1. Organize a whole Kerballed mission to Titan to have the privilege of seeing your Dragonfly replica to actually fly. This can't be the lowest difficulty.

2. Have an op mechjeb playing in your place. This is the lowest difficulty.

3/4. Learn programming or you're forced not to use probes or replicating IRL missions.

 

I want scripting in KSP, but I don't think I'll ever be able to write anything capable of controlling powered flight or precision landings with signal delay, it's absurd even to think it as a viable gameplay option. 

 

Link to post
Share on other sites
1 hour ago, Master39 said:

I want scripting in KSP, but I don't think I'll ever be able to write anything capable of controlling powered flight or precision landings with signal delay, it's absurd even to think it as a viable gameplay option. 

What if you were able to reference Long./Lat./Alt. for waypoints? It would just be a more sophisticated version of maneuver nodes.

Edited by mcwaffles2003
Link to post
Share on other sites
25 minutes ago, mcwaffles2003 said:

I don't think it would be asking much to have mechjeb put in as stock

I think you simultaneously (1) overestimate what MJ can do, and (2) oversimplify how sophisticated the MJ code is.

 

(1) Last time I looked, and with all due respect to what it actually does do, MJ cannot be pre-programmed to perform, start-to-finish, the entire sequence of actions necessary to perform even a simple landing. Is MJ currently capable of ALL actions required? Eg. deploy landing legs just before touchdown, to name just one thing that comes to mind? If the answer is no to even one and you are going to have to press any key or click any button between activating the sequence and coming to a complete stable stop on the surface, you are effectively still controlling the craft LIVE, without signal delay.

To fit a true comms delay scenario, after you send the initial command to activate the landing sequence (with enough time in advance so it can traverse space, get to the ship, be parsed, and still start the sequence at the required time) you can only WAIT AND WATCH AND TOUCH NOTHING ELSE until you get response back saying the entire sequence has been successfully executed.

(In fact, to be an honest implementation you'd not even be able to watch it happen in real time! Literally just wait to get a signal back that says 'THE EAGLE HAS LANDED. START PROPOSED OPERATION FIRST FOOTPRINT? (Y/N)', which would come in minutes after the fact. With direct line-of-sight and an unrealistically powerful telescope you might claim to see the craft - as it was minutes ago. But let's not nitpick and continue to suspend reality on that particular (yet rather crucial) side effect of 'comms delay' and at least keep the omni-present and instant-sending magic camera. :D)

 

(2) You're also side-stepping that MJ is a highly sophisticated end-game level pre-programmed computer. That is not 'limited and very basic' in any kind of interpretation - I'd invite you to take a peek at MJs source code repository to get a feel for how much code it takes to make it look simple. Even the code for the stock SAS can hardly be called limited/basic functionality, but I guess all is relative.

 

Anyway, I feel that with OP having been updated much of what I said now falls out of place. Just consider that even a signal delay in the order of fractions of a second is highly disconcerting and very annoying while controlling a craft - just ask any gamer playing a frantic action game over networks or on a subpar computer. This would already play within Kerbin SoI, and would make safe flying beyond that an almost guarantee of disaster.

So I still think we would require a form of scripting to pre-program sequences of actions we would otherwise perform manually, like such a simple thing as deploying landing legs at the right time. At the very least, we'd need to be able to script action group activation and some PAW interfaces with predetermined time delays, even in the lowest tech level.

You would also have to consider carefully where an MJ-level AI is conceptually acting from. If it's meant to replace ground control, which is how I see MJ, it would have to simulate and suffer the full signal delay between every iteration of SEND COMMANDS -(signal delay)-> AWAIT FEEDBACK -(signal delay)-> PROCESS DATA INTO NEW SET OF COMMANDS -> repeat. COMMANDS being literally anything it would tell the craft to do (increase pitch up, increase roll left, increase deploy airbrake, lower throttle, etc), and FEEDBACK being literally anything that changes in the craft state (velocity, attitude, temperature, part deployment, etc). Beyond Kerbin SoI... this would be desastrous.

If however you conceptually place it at the craft as a part of it, then MJ is basically replacing or augmenting your probe core.... effectively a highly sophisticated pre-programmed end-game level probe core. In which case it would need to be subjected to the same stripped down basic start and gradual progression as suggested for the regular probe cores, or only be available at the very last level of the tech tree in its entirety. Anything else would circumvent the progression tied to the concept.

With that I think my contribution to this thread is done.

Link to post
Share on other sites
20 minutes ago, swjr-swis said:

I think you simultaneously (1) overestimate what MJ can do, and (2) oversimplify how sophisticated the MJ code is.

 

(1) Last time I looked, and with all due respect to what it actually does do, MJ cannot be pre-programmed to perform, start-to-finish, the entire sequence of actions necessary to perform even a simple landing. Is MJ currently capable of ALL actions required? Eg. deploy landing legs just before touchdown, to name just one thing that comes to mind? If the answer is no to even one and you are going to have to press any key or click any button between activating the sequence and coming to a complete stable stop on the surface, you are effectively still controlling the craft LIVE, without signal delay.

Pretty much, here's an example from 2013. As for landing legs, I don't see why adding action groups at maneuver nodes is out of the question, though you could just make sure they're deployed manually before the landing sequence starts.

Spoiler

 

 

23 minutes ago, swjr-swis said:

To fit a true comms delay scenario, after you send the initial command to activate the landing sequence (with enough time in advance so it can traverse space, get to the ship, be parsed, and still start the sequence at the required time) you can only WAIT AND WATCH AND TOUCH NOTHING ELSE until you get response back saying the entire sequence has been successfully executed.

Isn't that how probes work?

24 minutes ago, swjr-swis said:

(In fact, to be an honest implementation you'd not even be able to watch it happen in real time! Literally just wait to get a signal back that says 'THE EAGLE HAS LANDED. START PROPOSED OPERATION FIRST FOOTPRINT? (Y/N)', which would come in minutes after the fact. With direct line-of-sight and an unrealistically powerful telescope you might claim to see the craft - as it was minutes ago. But let's not nitpick and continue to suspend reality on that particular (yet rather crucial) side effect of 'comms delay' and at least keep the omni-present and instant-sending magic camera. :D)

I feel like you're going beyond the pale just to argue now :/

25 minutes ago, swjr-swis said:

(2) You're also side-stepping that MJ is a highly sophisticated end-game level pre-programmed computer. That is not 'limited and very basic' in any kind of interpretation - I'd invite you to take a peek at MJs source code repository to get a feel for how much code it takes to make it look simple. Even the code for the stock SAS can hardly be called limited/basic functionality, but I guess all is relative.

So we shouldn't include mechjeb because it's very difficult to make even though it's already made?

26 minutes ago, swjr-swis said:

Anyway, I feel that with OP having been updated much of what I said now falls out of place. Just consider that even a signal delay in the order of fractions of a second is highly disconcerting and very annoying while controlling a craft - just ask any gamer playing a frantic action game over networks or on a subpar computer. This would already play within Kerbin SoI, and would make safe flying beyond that an almost guarantee of disaster.

So I still think we would require a form of scripting to pre-program sequences of actions we would otherwise perform manually, like such a simple thing as deploying landing legs at the right time. At the very least, we'd need to be able to script action group activation and some PAW interfaces with predetermined time delays, even in the lowest tech level.

You would also have to consider carefully where an MJ-level AI is conceptually acting from. If it's meant to replace ground control, which is how I see MJ, it would have to simulate and suffer the full signal delay between every iteration of SEND COMMANDS -(signal delay)-> AWAIT FEEDBACK -(signal delay)-> PROCESS DATA INTO NEW SET OF COMMANDS -> repeat. COMMANDS being literally anything it would tell the craft to do (increase pitch up, increase roll left, increase deploy airbrake, lower throttle, etc), and FEEDBACK being literally anything that changes in the craft state (velocity, attitude, temperature, part deployment, etc). Beyond Kerbin SoI... this would be desastrous.

If however you conceptually place it at the craft as a part of it, then MJ is basically replacing or augmenting your probe core.... effectively a highly sophisticated pre-programmed end-game level probe core. In which case it would need to be subjected to the same stripped down basic start and gradual progression as suggested for the regular probe cores, or only be available at the very last level of the tech tree in its entirety. Anything else would circumvent the progression tied to the concept.

With that I think my contribution to this thread is done.

I feel like you don't believe that I have already played KSP with RemoteTech and mechjeb.... Have you?

 

Link to post
Share on other sites
3 minutes ago, mcwaffles2003 said:

Pretty much, here's an example from 2013.

I've played modded games with MJ well after that. It did not include ways to trigger action groups or PAW functions. If you say it does now, I'll take your word for it.

 

5 minutes ago, mcwaffles2003 said:

Isn't that how probes work?

Uhm, no. Stock probe cores are lore-wise under live instantaneous remote control from either Kerbin or a pilot control point.

 

7 minutes ago, mcwaffles2003 said:

I feel like you're going beyond the pale just to argue now :/

A passing thought that I hadn't considered before, still relevant to the subject, but for the same reason relegated to parenthesis.

 

8 minutes ago, mcwaffles2003 said:

So we shouldn't include mechjeb because it's very difficult to make even though it's already made?

Not the point at all. You mentioned MJ as a basic and limited set of programmed remote control. I wanted to point out MJ is anything but.

 

9 minutes ago, mcwaffles2003 said:

I feel like you don't believe that I have already played KSP with RemoteTech and mechjeb.... Have you?

I have, briefly, it didn't stick very long in my mod list at the time. I remember it offering a better-than-stock simulation of antenna, including breakage at high speeds in atmosphere when the stock antenna were impervious, the need to point them the right direction, and implementing line of sight. I do not recall signal delay being part of it, or if it was, it must've somehow been easily circumventable. Then again, maybe it did and it was the reason it did not last in my mod list and I have been trying to repress that trauma ever since.

I fail to see how my previous playing or not playing with that mod would invalidate anything I've said though, or serve as a oneliner answer/solution to the differnt issues mentioned.

Link to post
Share on other sites
4 minutes ago, swjr-swis said:

I've played modded games with MJ well after that. It did not include ways to trigger action groups or PAW functions. If you say it does now, I'll take your word for it.

No, but I don't see why adding that would be a daunting task

5 minutes ago, swjr-swis said:

Uhm, no. Stock probe cores are lore-wise under live instantaneous remote control from either Kerbin or a pilot control point.

Was referring to real ones

5 minutes ago, swjr-swis said:

Not the point at all. You mentioned MJ as a basic and limited set of programmed remote control. I wanted to point out MJ is anything but.

The programming required to make it work is complex, but from the user end it offers less than a VPL would and is more easy to use

6 minutes ago, swjr-swis said:

I have, briefly, it didn't stick very long in my mod list at the time. I remember it offering a better-than-stock simulation of antenna, including breakage at high speeds in atmosphere when the stock antenna were impervious, the need to point them the right direction, and implementing line of sight. I do not recall signal delay being part of it, or if it was, it must've somehow been easily circumventable. Then again, maybe it did and it was the reason it did not last in my mod list and I have been trying to repress that trauma ever since.

I will simply say that I've established whole relay networks around other planets under signal delay with the two mods and the tools afforded make the task possible and well within anyone's skill set to do

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