How might the Tracking Center and tracking/comms capabilities work?

[Bej Kerman]

On 1/5/2022 at 8:27 AM, intelliCom said:

TL;DR: Probes that are 'X' light seconds away should take 'X' seconds to control in 'real time'.

Kerbals already have advantages of probes, and signal delay would only be pointless hinderance to gameplay anyway.

[shdwlrd]

1 hour ago, Bej Kerman said:

Pretty sure it's been a stock piece of information since precise maneuver control became stock.

The one thing I never use since I find it quicker and easier to use MJ and type the altitudes I want. Not play around with a velocity adjustments to hopefully get the altitudes I want.

[intelliCom]

5 hours ago, Bej Kerman said:

Kerbals already have advantages of probes, and signal delay would only be pointless hinderance to gameplay anyway.

Not pointless hinderance; if done correctly, it can be an interesting challenge.

Like forcing the player to wait an amount of time until control catches up to it. If you sent a probe from here to 6 light years away, and the arrival time was 50 years, you'd initiate control of the probe 44 years after departure, so it allows real-time control on arrival.

There's also stuff like plasma blackout and g-force damage that already exist as toggleable difficulty options. Signal latency of the above type could easily be another.

[Bej Kerman]

10 hours ago, intelliCom said:

Not pointless hinderance

Yes pointless.

10 hours ago, intelliCom said:

If you sent a probe from here to 6 light years away, and the arrival time was 50 years, you'd initiate control of the probe 44 years after departure, so it allows real-time control on arrival.

But it's 6 light years away, not 44 light years.

10 hours ago, intelliCom said:

There's also stuff like plasma blackout and g-force damage that already exist as toggleable difficulty options.

G-force damage rarely happens and plasma blackout is a temporary inconvenience. Input latency is permanent.

 

Besides, I thought everyone agreed that, in lore, all your inputs are pre-programmed into the probe anyway. Input latency truly isn't needed.

[intelliCom]

2 hours ago, Bej Kerman said:

But it's 6 light years away, not 44 light years.

When I say "initiate control", I mean load the craft in from the tracking station. Since it's almost reached 6 light years away after 44 years, another 6 years would need to go by until the probe arrives at the 6 light year distance.
So, another 6 years passes and real-time control can finally be given to the probe.

Reason input latency wasn't as necessary in KSP1 was out of interplanetary distances. Only a few minutes would pass between Kerbin and Duna, so why have the latency there at all?

Latency would be a definite challenge when dealing with interstellar distances, and as such, it's something that should be incorporated into KSP2. KSP devs have talked about torchship engines pushing spacecraft to relativistic velocities, so just ignoring the speed of light would be cheap. If you don't like latency with your interplanetary probes, send a pilot there to use remote assist on a nearby space station or something.

I'm not even talking about actual input latency, because jesus christ I know how much of a hassle it is to deal with cloud gaming, let alone interplanetary communications.
It's just a cooldown for the amount of time it would take for the inputs to be broadcast from the tracking station. If there's a pilot with remote assist that's already in close enough vicinity, the tracking station's cooldown is overriden, and the pilot's distance is used as a cooldown instead. After the cooldown, it's all real-time for as long as the vessel is loaded in. Encourages the player to think ahead of time.

2 hours ago, Bej Kerman said:

Besides, I thought everyone agreed that, in lore, all your inputs are pre-programmed into the probe anyway. Input latency truly isn't needed.

This would be the case for limited control, which only includes the maneuver nodes available to the probe core. If we're considering that, then there's basically just a latency cooldown for full control via a tracking station or nearby pilot.

Edited April 8, 2022 by intelliCom

[Bej Kerman]

2 minutes ago, intelliCom said:

Latency would be a definite challenge when dealing with interstellar distances, and as such, it's something that should be incorporated into KSP2.

The first probes to go interstellar will be preprogramed. As such only the science should take 6 years, but input should be instant on the basis of it being programmed inside the probe.

[intelliCom]

5 minutes ago, Bej Kerman said:

The first probes to go interstellar will be preprogramed. As such only the science should take 6 years, but input should be instant on the basis of it being programmed inside the probe.

Yeah, but with what tracking station to provide full-control inputs? It's literally light years away. 

The "programmed" part is limited control. Clicking on maneuver nodes with SAS.

Edited April 8, 2022 by intelliCom

[Bej Kerman]

4 minutes ago, intelliCom said:

Yeah, but with what tracking station to provide full-control inputs? It's literally light years away. 

Key words: the first probes to go interstellar will be preprogramed.

5 minutes ago, intelliCom said:

The "programmed" part is limited control. Clicking on maneuver nodes with SAS.

Since when were preprogramed probes only able to point at a few specific vectors?

Bottom line: user input is preprogramed. The only thing that needs delay is science transmission.

[intelliCom]

26 minutes ago, Bej Kerman said:

Since when were preprogramed probes only able to point at a few specific vectors?

Explain limited control in KSP 1. Explain how a probe acts autonomously with specific vectors without direct contact with Kerbin or a pilot?

Is that not pre-programming? If not, then what is it?

Edited April 8, 2022 by intelliCom

[Bej Kerman]

1 minute ago, intelliCom said:

Explain how a probe acts autonomously with specific vectors without direct contact with Kerbin or a pilot?

Why should preprogramed maneuvers be limited to a few vectors? It's full control or bust.

[intelliCom]

5 minutes ago, Bej Kerman said:

Why should preprogramed maneuvers be limited to a few vectors? It's full control or bust.

So you propose that probe cores should be reworked? Honestly, I agree with you on that one.

Doesn't make sense that the player should be able to tell the probe core what to do even when no inputs should be available. I just hope they add some sort of really basic Scratch-like programming system for KSP 2's probe cores.

[Bej Kerman]

On 4/8/2022 at 12:24 PM, intelliCom said:

On 4/8/2022 at 12:17 PM, Bej Kerman said:

Why should preprogramed maneuvers be limited to a few vectors? It's full control or bust.

So you propose that probe cores should be reworked? Honestly, I agree with you on that one.

No, I didn't say that. I propose we do away with input latency. Full control, no latency. Pre-programmed inputs in-lore, whatever. There's no reason to hinder gameplay for silly challenge aspects that don't do anything to make the game any more rewarding or fun.

[snip]

Edited April 9, 2022 by Snark
Redacted by moderator

[intelliCom]

[snip]

Space probes have to be able to do this all the time. Cassini and Juno need to do it when they end up behind their respective planets. It's called a communciations blackout.
And, as I said, really basic Scratch-like stuff. Basically telling the probe to immediately aim its heat shield retrograde if it detects atmospheric pressure, or to program a suicide burn like Falcon 9 boosters do.

Basically giving a KSP-ified experience of software engineers preparing their probes for every potential scenario.

Edited April 9, 2022 by Snark
Redacted by moderator

[Bej Kerman]

2 minutes ago, intelliCom said:

And, as I said, really basic Scratch-like stuff. Basically telling the probe to immediately aim its heat shield retrograde if it detects atmospheric pressure, or to program a suicide burn like Falcon 9 boosters do.

Basically giving a KSP-ified experience of software engineers preparing their probes for every potential scenario.

Or just don't do latency at all, that would be preferable.

[intelliCom]

1 minute ago, Bej Kerman said:

Or just don't do latency at all, that would be preferable.

Programming's more fun than you think. Making the experience of controlling probe cores into just "same as a kerbal in a command pod but there's no kerbal" isn't fun.

Besides, programming probes could also allow for proper automated rovers like literally every Mars rover ever without keeping the rover loaded in at all times. Relying on user input to get the rover from A to B is much more annoying than automating that stuff. Even worse when you have to deal with communications blackout, but since you said that should be removed anyway, you're basically saying that the tracking station serves absolutely no use to probes but science transmission.

In other words, "same as a kerbal in a command pod but there's no kerbal". The only good use for probe cores at this point is minaturisation. Anything larger than an external command seat is useless, and uninteresting.

[Bej Kerman]

Just now, intelliCom said:

Programming's more fun than you think. Making the experience of controlling probe cores into just "same as a kerbal in a command pod but there's no kerbal" isn't fun.

I'm not you and don't find programming fun. I do, however, find piloting fun. That seems to be the majority of people here, also. Bottom line still being don't do latency at all.

1 minute ago, intelliCom said:

In other words, "same as a kerbal in a command pod but there's no kerbal". The only good use for probe cores at this point is minaturisation. Anything larger than an external command seat is useless, and uninteresting.

It won't be "same as kerbal without kerbal" at all. Kerbals can reproduce, run colonies, etc. Probes can't do that. Bottom line is still, of course, don't do latency at all.

[intelliCom]

3 minutes ago, Bej Kerman said:

I'm not you and don't find programming fun. I do, however, find piloting fun. That seems to be the majority of people here, also.

Why not ask them yourself? Not cherry picking pilot-nuts, but just average KSP fans. Would they like an easy, basic programming system along the lines of the KAL 1000 but with a conditional 'if-else' feature?
Prove that people really want probe cores to be a boring alternative to Kerbals, instead of probe cores being good and fun for some things and kerbals good and fun for others.

Also, I notice you didn't provide a counter-point for rover automation. You also ignored suicide burn automation. Care to explain that, or should we sweep that under the rug?

[Bej Kerman]

On 4/8/2022 at 12:59 PM, intelliCom said:

Prove that people really want probe cores to be a boring alternative to Kerbals

Prove that probes are a safer alternative to Kerbals? Prove that people would like to spend hours programming just to have less control than they would otherwise? Ask them yourself [snip]

Edited April 9, 2022 by Snark
Redacted by moderator

[Vl3d]

@intelliComHave you read this? I think we have some similar ideas:

 

[intelliCom]

21 hours ago, Bej Kerman said:

Ask them yourself

Don't claim that the majority's on your side if they might not be.

Especially if you're going to ignore the good use cases for probe automation that I already mentioned twice now.

20 hours ago, Vl3d said:

@intelliComHave you read this? I think we have some similar ideas:

 

This is going down the right idea, but it's starting to overcomplicate probe automation.

I was more thinking about small things like if you put a barometer onboard, and it read some air pressure, the probe would assume the worst and prepare for an aerobrake.

Perhaps you could put in all the maths for a suicide burn and let the probe core do it? I feel as though a lot of these problems could easily be done by a KAL-1000 that has if-else conditions. And, not making 5 different KAL-1000s that do different things, but just one unified KAL with individual actions by individual conditions being met.

[Vl3d]

I proposed a integrated system with centralized craft command and control (upgradable hardware) in which you can add software modules representing functions (basic autopilot and others) that you can program using a Scratch-like system with sensors and conditionals provided by science parts, smart parts and telemetry.

This way you link gameplay interface with rocket design, you allow optional automation and it gets very interesting and moddable.

It would even allow programmable probe missions with the comms delay enabled. Building manned space stations would be encouraged in order to locally control probes manually.

Edited April 9, 2022 by Vl3d

[Guest]

15 hours ago, intelliCom said:

Programming's more fun than you think. Making the experience of controlling probe cores into just "same as a kerbal in a command pod but there's no kerbal" isn't fun.

Besides, programming probes could also allow for proper automated rovers like literally every Mars rover ever without keeping the rover loaded in at all times. Relying on user input to get the rover from A to B is much more annoying than automating that stuff. Even worse when you have to deal with communications blackout, but since you said that should be removed anyway, you're basically saying that the tracking station serves absolutely no use to probes but science transmission.

In other words, "same as a kerbal in a command pod but there's no kerbal". The only good use for probe cores at this point is minaturisation. Anything larger than an external command seat is useless, and uninteresting.

Programming has already been discussed multiple time in this thread, bottom line is, I love programming, I want programming, both a visual interface to replace action groups and whatever the KAL system is supposed to be and, if possile, a text option in one well documented real world language, an easy one like Python or LUA. BUT, theres a but:

Programming works just fine as an option, it doen't need dealy to work, and if you decide that beyond a certain range you don't want to do manual piloting you can use programming anyway, regardless of delay.

Programming can be fun, and it's even more approachable and fun if it's not shoved down your throat replacing a 5 minute action like separating a 2 probes and sening them to different orbits with hours of coding and testing.

Immagine this: Action groups are now part of the graphical programming interface, on default you just have the "Press button" block connected to the "do action" one, easy, as easy as current action groups, but, without getting too deep into programming and just as easy players can realize that they could add a conditional block to do things at certain altitudes instead of at a button press, then they find out about logic, and, block by block, craft by craft, they slowly slide into programming without even realising.

Opposed to what you're proposing: If you don't know how to program you can't do a Perseverance replica, and even if you can good luck with doing the sample return collaboration mission with it that requires 3 or 4 rendezvous maneuvers between ground and orbital crafts, good luck programming that.

 

And yes, I know that you could download and use other people's code, but, frankly, it just sounds like trying to sneak a "autopilot mandatory for everyone" into the game from the window. If you just want mandatory autopilots let's discuss that in the appropriate thread.

[intelliCom]

39 minutes ago, Master39 said:

Programming has already been discussed multiple time in this thread, bottom line is, I love programming, I want programming, both a visual interface to replace action groups and whatever the KAL system is supposed to be and, if possile, a text option in one well documented real world language, an easy one like Python or LUA.

I'm not trying to say that use of an actual fully-fledged programming language is what's best. I genuinely just mean absolutely basic programming like Scratch does. Clicking and dragging blocks. Absolutely basic kiddy stuff that could still allow for accessible automated probes.

42 minutes ago, Master39 said:

Programming works just fine as an option, it doen't need dealy to work, and if you decide that beyond a certain range you don't want to do manual piloting you can use programming anyway, regardless of delay

Unless you're looking to feed new programming into the probe core, but speed-of-light delay for real-time inputs would be a good incentive to 'program' probe cores to do things on the player's behalf when the inputs won't get there in time.

45 minutes ago, Master39 said:

Immagine this: Action groups are now part of the graphical programming interface, on default you just have the "Press button" block connected to the "do action" one, easy, as easy as current action groups, but, without getting too deep into programming and just as easy players can realize that they could add a conditional block to do things at certain altitudes instead of at a button press, then they find out about logic, and, block by block, craft by craft, they slowly slide into programming without even realising.

Which is what I was trying to say. It's like Scratch. Not actual typing of code, but pre-made blocks to tack onto each other. Before I got into learning javascript and php, I used Scratch to learn how coding works. Considering how KSP is all about giving players complex concepts in a simpler form, Scratch-like programming would be perfect.
Scratch - Imagine, Program, Share (mit.edu)

47 minutes ago, Master39 said:

Opposed to what you're proposing: If you don't know how to program you can't do a Perseverance replica, and even if you can good luck with doing the sample return collaboration mission with it that requires 3 or 4 rendezvous maneuvers between ground and orbital crafts, good luck programming that.

Scratch. For the third time in this reply, Scratch. Anyone can write functioning code in Scratch. The learning curve is literally a plateau that's about 10% the height of the entire graph.

I'm not literally saying that Scratch itself should be used for probe cores, but definitely something similar.

For players who already have a moderate to advanced knowledge of programming, the blocks could be converted to a text format like conventional programming languages are.

48 minutes ago, Master39 said:

And yes, I know that you could download and use other people's code, but, frankly, it just sounds like trying to sneak a "autopilot mandatory for everyone" into the game from the window. If you just want mandatory autopilots let's discuss that in the appropriate thread.

I don't want autopilots everywhere because that defeats part of the fun of KSP. However, it should be mandatory in cases where a Kerbal isn't operating anything directly, and where inputs would be delayed due to the speed of light.

Perhaps to combat the problem of probe cores replacing everything, each probe core should have a limit for how much code they can store. Really simple ones like the Stay-putnik could only manage 3 blocks. Potentially just the following:

• "If" condition  block (e.g., vertical speed < 0)
• execute block (e.g., SAS = retrograde) 
• "else" execute block (e.g., return)

This alone would introduce the player to a very basic situation to use programming in; a probe automatically aiming its heatshield retrograde, even during plasma blackout without user input.

[Guest]

1 hour ago, intelliCom said:

delay for real-time inputs would be a good incentive

Not an "incentive", it's a complete change of face for the game from a piloting game to a programming one like Zachtronics ones.

1 hour ago, intelliCom said:

Scratch. For the third time in this reply, Scratch. Anyone can write functioning code in Scratch.

Scratch-like things have a name, it's a graphical programming interface as I said here:

2 hours ago, Master39 said:

both a visual interface to replace action groups and whatever the KAL system is supposed to be and, if possile, a text option

That means a scratch-like interface with a side window with text in it.

 

1 hour ago, intelliCom said:

I don't want autopilots everywhere because that defeats part of the fun of KSP.

Yes you do, that is literally what you're asking for, maybe you're not realizing it yet.

 

1 hour ago, intelliCom said:

it should be mandatory in cases where a Kerbal isn't operating anything directly, and where inputs would be delayed due to the speed of light.

No it shouldn't, the player acts as either a pilot or in place of the probe programming, changing that is just as arbitrary as removing third-person view and forcing eveything to a first person view from a Kerbal or a camera if you remembered to bring one. Would you like that? Not as an option, as the main game mode, with an option to disable it in the cheat menu.

[Snark]

A substantial amount of content has been removed, due to unsubstantive and inappropriate content such as:

• personal remarks
• arguing about arguing

Folks, I assume we're all familiar with the difference with objective fact versus opinion, yes?

If someone is making claims of objective fact, and you believe those claims to be wrong, then you can argue with it, sure.  You can cite your evidence.

On the other hand, opinions?  You cannot argue with someone's opinion.  It's not physically possible.  "Your opinion is wrong" is a meaningless statement.  Why?  Because a person's opinion is simply a statement of what they like, and there's only one authority on that, and that's the person themselves.  Trying to argue with someone about their opinion would be as silly as arguing about which ice cream flavor is better, vanilla or chocolate.  (Chocolate.)

This thread is purely about opinions.  There is no "objective fact" here, because everything in this thread is about what people would (or wouldn't) like.  Anything you read in this thread, you need to mentally prepend whatever the person said with "I, personally, would enjoy it more if <whatever is written>."  Accordingly, please don't try to argue about it.  It's pointless.  If someone says "I would like X, because <reasons>", you are in no position to tell them they're wrong.  You can certainly respond with an opinion of your own, if you like.  For example, "I, on the other hand, would hate X, because <reasons>.  I would much prefer Y instead, because <reasons>."

It's also hopelessly silly to get angry at someone else's opinion, just because it's different from your own.  Different people like different things. ¯\_(ツ)_/¯

So, to summarize:

• This is a thread about opinions, not facts.  You can't argue with opinions, so please don't try.
• It's fine to state your opinion.  It's fine for other people to state their opinions, too, even if those are different from yours.
• Your opinion is no more (or less) valid than anyone else's, so please don't act as though it is.
• Your opinion is yours.  Please don't presume to speak for anyone else, including what "everyone wants".  You don't know what everyone wants; you only know what you want.  If someone wants to say what they want, they are welcome to do so for themselves.

Above all, please do not descend to personal remarks, or get into off-topic areas such as arguing-about-arguing.

Thank you for your understanding.