Communication delayed by speed of light limit

[Vl3d]

It's another controversial topic, but I know everyone is open to discussions, ideas and suggestions.
So let's just assume that KSP2 will have a simple visual programming language like Vizzy in SR2 that also plays well with the Journey Planner.

Spoiler

 

I think this would allow adding a feature (stock or as a dificulty setting) that would make the game even more interesting: (manned craft or ground support  = command stations <-> unmanned craft) communication delayed by the light-speed limit of causality.

Let's have an open mind and think about it.

1. Manned craft would be controlled in real-time as usual, but it would take some time for scientific results to be transmitted to the network of colonies. This has a small impact on tech progression if experiments would also take time to run as implemented in Kerbalism. Besides, we can always time warp to get the science points.
2. Manned craft would be even more important because they could allow the control of probes in proximity: this is motivation to create space stations, colonies closer to unmanned mission destinations.
3. Unmanned craft would be pre-programmed, re-programmable and remotely controlled with distance-proportional-delay and using limited information  (using data from hull cameras, telemetry, sensors, science and other instruments). This could also mean implementing a Probe Control Center, like an instruments deck similar to IVA view.
4. Previous point means also that early in the tech tree only manned craft would be able to see a direct close-up real-time interactive detailed view of celestial bodies. So there would be a bigger motivation to send actual exploration crew and would ensure gradual discovery of celestial bodies.
5. Unmanned craft would be useful but limited, dispensable, even launch-and-forget - not as important as manned missions. This means a faster rhythm of craft iteration and discovery.
6. It really ties in nicely with reusable craft, logistics automation, and delivery routes system.

I think the game would have a lot to gain from giving the player learning experiences:

• "I hope I did a good job and everything works, because it's out of my real-time control now - I just get the instruments info and watch the show"
• "I messed up the programming, but I will learn from the mistake and do better next launch" (just read how hard it was to send successful missions to Mars)
• "I learned basic programming"
• "I found a mistake during the mission, I can't control the probe in real-time, but I can update the software"
• "I need to send crew to be able to control in-proximity probes in real-time"
• "99% of the work is in design and testing - after launch we hope for the best"

And I'm sure there would be a lot of interesting variation and emergent gameplay from this.

Long live RemoteTech! Unleash it with visual programming!

Edited June 30, 2022 by Vl3d

[t_v]

Refer to this discussion

Some insights have been shared in there

[Vl3d]

Ok, after reading through the previous discussion I realize there's one thing that I mentioned in the OP that needs more explanation: integration of the visual scripting language with the Journey Planner (maneuver nodes), the onboard equipment, the control deck, the manned command center.

Simple ideas (comms signal needed):

1. You create all the necessary action groups and the KAL recordings for the unnamed craft.

2. You set the destination in the Journey Planner and create all the necessary maneuver nodes BEFORE launching the mission.

3. You export the plan (1) with all the intermediary key-frame maneuvers as a basic script frame for the Kizzy editor. This way it's like you have access to high level MechJeb functionality, but you can work with it in the script.

4. In your script you also have access to all the action groups and KAL recordings and telemetry / sensors / other equipment.

5. You finish the script, upload it to the unmanned craft, send it.

6. If later you find a bug you can reupload the improved program (if signals are good).

7. You interact with the unnamed craft indirectly through a Unmanned Craft Control Deck, with UI elements integrated. You see the onboard cameras and all equipment data.

8. You are able to send direct commands only if you have a command center close enough so the delay is below a certain threshold. In this case you can control the unmanned craft in real-time.

9. You do your best, learn from your mistakes, improve the maneuver nodes and the script, upgrade equipment, send manned missions closer to the destination to have real-time control.

I think this would be fun and it would expand gameplay. If not, it could be a very nice spinoff game or DLC.

PS:

Don't tell me it's too complicated. Have you played Paradox games?

Also don't tell me you don't want to learn visual scripting. Have you played SR2? Programming craft is a great fun functionality even as an optional feature.

Having comms delay is actually an emergent feature, it is a difficulty settings unlocked by what is made possible by an integrated scripting system.

Edited July 1, 2022 by Vl3d

[Guest]

• Programming works the same without light delay.
• Light delay actually reduces gameplay and makes it less realistic.

 

 

This becomes impossible to do in a realistic way if you add light delay. No, having a crew in Duna orbit to drive a technology demonstrator is not realistic at all.

Or this:

 

Or this, tech demonstration mission:

Look at how I had to avoid landing in the sea with the first probe, now, write me a program that does that in automatic. No, magical autopilot calls like "Probe.pleaseDonEndUpInWaterButTryToLandOnLand()" or "autopilot.landAt(x,y,z)" are not allowed, you have to start from mapping data and have access to coordinates only if you have a GPS equivalent orbiting the destination, we are trying to be "realistic" here.

Now tell me if programming a whole ocean avoidance system is fun gameplay to you, or you would just avoid flying probes altogether.

Improved design:

Bigger tech demonstrator for sample return to orbit:

First time a Kerbal even comes within the same SOI of the whole thing:

 

I'd love programming to improve a lot of aspects of that program, having to lock things manually is a pain and it's why I removed the foldable wings in later designs.

Light delay would simply kill anything flying that's not manned or just flying where you already have Kerbals.
Now you could argue that It doesn't take much to have a Duna or Eve babysitting space station to fly things there, but what about Laythe? One thing is to have a crew on a 2-3 years mission to Duna, another one completely is a decades long Jool mission to babysit a flying thermometer.

 

What if I said that to improve realism and add a gameplay loop around cameras we should also remove third person view? You no longer have access to the third person camera, you only see what a Kerbal sees, for the VAB it means view on the ground looking up, for rockets and planes IVA only, for probes it means camera view if you have cameras or sensor data on a graph or as text otherwise. Wouldn't that be realistic? What? Is too restrictive to gameplay? Well, the same goes for lightspeed delay, it's not a realism feature, it's a change in the POV of the game.
In KSP you are the craft, not a Kerbal, not a guy in mission control, but the craft you're flying, whether it is a plane, a probe, a satellite or a Kerbal on EVA.

 

On 7/1/2022 at 10:12 AM, Vl3d said:

Having comms delay is actually an emergent feature, it is a difficulty settings unlocked by what is made possible by an integrated scripting system.

Nope, comms delay is just useless, you can have a hardcore option "only programmed input to probes" and it would be exactly the same.

All the challenge and gameplay is provided by programming, the delay is only a roundabout way to say to pleople that love flying things manually "you're playing the game the wrong way!". There's nothing that delay adds that's not already added by programming.

Doing a "solid only" Mun mission is a funny challenge that creates some interesting gameplay, removing all non-solid engines from the game it's just forcing that challenge on others.

[jimmymcgoochie]

Bad idea at interplanetary distances, truly awful idea at interstellar distances. I've said it before and I'll say it again: having a huge, expensive, took-years-to-build-the-thing interstellar spaceship go ploughing into a planet or hurtling off into deep space rather than parking in orbit due to a tiny mistake in timing or trajectory drift, when all you can do is watch it crash because "light speed delay" means you can't make the tiny and eminently sensible course correction, isn't my idea of fun.

[Vl3d]

Ok, I agree with some of your comments. My basic idea was to move unmanned craft towards pre-programmed control and leave manned craft in the area of real-time control. This is because I believe probes are OP, you can play all of KSP 1 without the need to launch a single Kerbal in space. I believe we need more incentives to use manned craft.

11 hours ago, Master39 said:

There's nothing that delay adds that's not already added by programming.

Adding visual scripting is the most important point.  Indeed KSP1 and CommNet abstracts signal delay away because it's not fun gameplay, but also because there is no tool to pre-program unmanned craft.

So let's think about what incentives there could / will be in KSP2 to use manned craft with real-time control:

• planting flags
• piloting craft when there is no communication signal
• craft construction and modification (one or more kerbals)
• craft repairs
• science labs
• special science experiments (like the deployable ones)
• colony construction and expansion (more important in KSP2)
• resource extraction and processing bonus

What incentives we have to use unmanned craft:

• you can control craft in real-time like you can with manned craft
• you don't have to worry about kerbal loss of life, life support or radiation protection
• you can discover any place manned craft can discover (with relays and good comm signal)
• in KSP1 you can do basic orbital / landed construction using robots and dockable sub-assemblies
• you can do most of the useful science experiments

So if we add visual programming you would have all the benefits of KSP1 unmanned craft and also:

• be able to pre-program control of probes with no communication signal

So basically what we're doing is adding programming and by doing this we are making OP unmanned craft even more powerful, without adding incentives for manned missions. This is why it's important to talk about separating unmanned and manned gameplay, adding extra incentives for manned craft and/or taking away some of the advantages of unmanned craft. It's a balance issue, it can be solved in multiple ways. This is the reason integrated visual programming and signal delay is still one of the possible solutions and a good idea - depending on implementation.

[Guest]

10 hours ago, Vl3d said:

This is the reason integrated visual programming and signal delay is still one of the possible solutions and a good idea

You haven't understood me, read this:

23 hours ago, Master39 said:

Look at how I had to avoid landing in the sea with the first probe, now, write me a program that does that in automatic. No, magical autopilot calls like "Probe.pleaseDonEndUpInWaterButTryToLandOnLand()" or "autopilot.landAt(x,y,z)" are not allowed, you have to start from mapping data and have access to coordinates only if you have a GPS equivalent orbiting the destination, we are trying to be "realistic" here.

Now tell me if programming a whole ocean avoidance system is fun gameplay to you, or you would just avoid flying probes altogether.

Now, reply with working code, in a language of your choice or I'll automatically assume you just want to remove the ability to fly my probes.

 

 

10 hours ago, Vl3d said:

we are making OP unmanned craft even more powerful

KSP2 is a game about colonizing new worlds. Probes can't colonize. Probes aren't OP, they can't replace Kerbals.

[Vl3d]

50 minutes ago, Master39 said:

Now, reply with working code, in a language of your choice or I'll automatically assume you just want to remove the ability to fly my probes.

while (!landed) {

while (ASL < AGL) keep flying;

if (ASL > AGL) land; }

The rest are details that can be implemented in the script.

But it would be even easier if the scripting language was integrated with journey planner, maneuver nodes and a landing trajectories calculator.

You keep using one of the most complicated example you can come up with (transforming propeller plane drone) without understanding that the control code would also have to be relatively complicated and it would need integration with the other systems in the game.

Let me make it more clear: I want a difficulty option that creates incentives to program probes. Call it signal delay or "program input only". If you don't like it, play without it.

.. also, unmanned craft are supposed to be expendable and experimental with a fast iteration loop. If you fail you improve your designs and test more - it's what Kerbal's all about.

[Vl3d]

Found another thread on the subject:

 

[Guest]

Let's skip the code part, I'll just give you the merit for having tried, even if you completely missed the kind of complexity of the whole thing.

2 hours ago, Vl3d said:

But it would be even easier if the scripting language was integrated with journey planner, maneuver nodes and a landing trajectories calculator.

Yep, the Magic.autopilot.removePilotingFromTheGame API surely would make everything easier, wouldn't it?

 

2 hours ago, Vl3d said:

You keep using one of the most complicated example you can come up with (transforming propeller plane drone)

No I keep using the example that breaks the whole system.

The thing I spend the most time on when I'm building probes.

Flying probes are a thing, right now, not in the near or far future.

Less than a month ago a real flying probe, Ingenuity, completed its 29th flight on Mars, and you're are proposing to change the gameplay in a way that would kill that entire kind of probes.

Your idea kills an entire way of playing the game, for marginal benefits (I would argue no benefits at all).

 

2 hours ago, Vl3d said:

Let me make it more clear: I want a difficulty option that creates incentives to program probes. Call it signal delay or "program input only". If you don't like it, play without it.

Changing a whole game POV is not a difficulty option, it's like picking up a book written in third person omniscient and asking the author "can you do a first person limited for me? It's just a small change".

In KSP you are whatever you are flying or building, that's the POV, inserting control delay changes that, changes the focus of the game, the focus of the gameplay, brings KSP into a different genre and screams "YOU ARE PLAYING IT WRONG" to people who enjoy flying.

Also, a difficulty option should be about changing the difficulty of the game, and signal delay doesn't. It changes the way you play, the difficulty is entirely correlated to how powerful the autopilot features and the programming language are.

In your idea of having the journey planner directly feed the programming automatically would kill all and any residual difficulty in the programming itself, all the difficult decisions, all the algorithms, all the pro and cons of writing a generic system that is aware of its position vs a dumb automated macro that simply knows when to push the stage button or raise the throttle based on some simple condition.

 

You're basically using signal delay to make programming mandatory and then dumbing down programming to make it accessible to everyone.

Why? Let's just skip on the signal delay, don't make autopilot features available with programming, people that don't want to program an entire autopilot system can get their feet wet with programming anyway by using the VPL instead of KAL or action groups to do things like opening solar panel, parachutes or automating and executing simple deploy/landing sequences.  More advanced users will enjoy being able to program their own complex systems, without having the low skill ceiling that the dumbed down mandatory programming would provide.

For even more hardcore users you just put a "No manual control unmanned crafts" button that it's for all purposes equivalent to the signal delay bur easier to implement.

Edited July 4, 2022 by Master39

[t_v]

2 hours ago, Master39 said:

For even more hardcore users you just put a "No manual control unmanned crafts" button that it's for all purposes equivalent to the signal delay bur easier to implement.

Okay, this sounds exactly like a difficulty setting. “Allow reverting to editor” “CommSat always connected in sandbox” “Probe manual control always enabled”

[RKunze]

8 hours ago, Vl3d said:

while (!landed) {

while (ASL < AGL) keep flying;

if (ASL > AGL) land; }

 

That will happily fly your probe right along a straight coast line until it runs out of fuel and crashes not 10 meteres away from shore 

8 hours ago, Vl3d said:

Let me make it more clear: I want a difficulty option that creates incentives to program probes. Call it signal delay or "program input only". If you don't like it, play without it.

 

"Program input only" actually makes sense. My current career is something like that - probes are either kOs controlled and autonomous, or the use the automation features of Kerbalism (mainly for running experiments), and all that's allowed from the ground is the same stuff that a real-world control center can do: Send signals to the in-flight software (I mostly use action groups for that), or update the in-flight software (and if that update breaks the probe past anything that can be repaired with an action group, too bad - we just transformed a million funds deep space probe into just another heap of deep space junk, with the click of a button).

"Signal delay" doesn't add anything to gameplay. All it does is force you to timewarp another four years until the signal of your first interstellar probe finally gets back from Alpha Kentauri....

If you want to get somewhat realistic with signals and actually get some interesting gameplay out of it, go for a bandwidth limit, and make experiments take time both to gather and transmit data (and if you want to see how that feels in KSP1, install Kerbalism).

[Pthigrivi]

The real flaw here is that even if you spent the time to create a thorough and robust programming language for vessels in KSP the ideal outcome would be that players would  focus on each probe and then spend 15 minutes watching and not touching the keyboard and hoping helplessly that it didn’t crash for predictable or unpredictable reasons. That doesn’t sound fun to me.

Edited July 5, 2022 by Pthigrivi

[Guest]

7 hours ago, Pthigrivi said:

The real flaw here is that even if you spent the time to create a thorough and robust programming language for vessels in KSP the ideal outcome would be that players would  focus on each probe and then spend 15 minutes watching and not touching the keyboard and hoping helplessly that it didn’t crash for predictable or unpredictable reasons. That doesn’t sound fun to me.

I think that programming could play a huge role in situations like plasma blackout during reentry or when aero forces would break the antennas away.

Even people with no experience in programming at all will enjoy conditional action groups, "altitude < 5000m = deploy parachute", "touchdown = deploy antenna and solar panels", "tank empty = stage". From there some curious users will start trying something more complex, and then some of them  will notice the "convert script to text" option and discover that it's not that different writing instead of using the blocks of a VPL.

But it works best if it is a gradual path, there are plenty of uses for programming that have nothing to do with control and navigation.

[Vl3d]

After doing some more comparisons between RemoteTech and CommNet and also some play testing I tend to agree with @Master39 and other similar opinions and I forfeit the idea in the OP, but keep the idea of scripting:

1. Signals delay can be abstracted away because of the concept of time zoom (warp), so real-time probe control is acceptable for a better gameplay experience.
   • It slows down gameplay too much. It's hard enough to build and test a probe, it would be even more work to also have to program it. It would generate a lot of "I give up" moments.
   • Also controlling more than one craft (for docking for example) would be impossible without very high level MechJeb functions (which kind of defeats the purpose of scripting).
2. Players should not be forced to exclusively use a IVA / Probe Control Room point of view.
   • Maybe a black and white / fuzzy / sepia overlay in 3rd person craft view is better.
   • But PCR / probe IVA would still be a nice alternative.
3. Having a visual programming / scripting language / editor I think is a must for a modern KSP.
   • This VPL should be optional in stock and normal dificulty, but there should be some harder difficulty settings that could limit manual control to incentivize scripting or there could be more situations where manual control of probes is not possible so the craft goes into an automatic scripted state.
   • The VPL should be closely integrated with the other planning / logistics / navigation / smart-parts / telemetry / science systems to allow template generation and also fine adjustments.
   • VPL would be great to use in situations where we have to control more than one craft simultaneously (booster return-to-base and reuse, small craft swarms / movement mirroring, floating / flying carriers, mining / resource transport / other repetitive operations etc.)
   • Useful in cases where manual control is not possible (lack of signal) so a short automated script can be run (like holding SAS during reentry or queuing a burn during occlusion)
4. There should be a better balance and greater distinction between using:
   • unmanned craft (exploration, safety, simplicity etc.)
   • manned craft (dealing with life support but necessary for colonization, building .. and other uses are needed!)
5. Some better alternatives to signal delay (merging these features):
   • CommNet idea of signal strength and relays;
   • The Kerbalism system of file storage and data transfer speed (which slows as signal is weaker because of redundancy and error correction);
   • The RemoteTech idea of more control over the comm network (being able to point directional antennas and manually change the signal links graph). Omnidirectional antennas would still be in the game, but would be weaker than the directional ones.
   • The RemoteTech idea of queuing scripts / commands in case of loss of manual control.
   • Having a CPU / KAL portrait image instead of a Kerbal when controlling unmanned craft.

Edited July 5, 2022 by Vl3d