Jump to content

Signal delay?


Lo.M

Signal delay?  

43 members have voted

  1. 1. Signal delay?


This poll is closed to new votes

  • Please sign in or register to vote in this poll.
  • Poll closed on 03/24/2021 at 03:00 AM

Recommended Posts

Signal delay in comunications in ksp 2?

Example: The signal that will be transmitted from a spaceship in another star system to Kerbin or a colony

Edited by Lo.M
Link to comment
Share on other sites

14 minutes ago, The Aziz said:

In manually controlled ships? Elaborate. 

Because if  what you mean is a delay between hitting a button and ship reacting to it, it's called input lag and no game should have it, ever. 

Delay between sending a signal from one location to another. Example: The signal that will be transmitted from a spaceship in another star system to Kerbin or a colony.

Link to comment
Share on other sites

It’s a very natural incentive to promote kerballed missions over probes, adding fun challenges for those who like probes. I’d love to see something akin to RT implemented in the game, even if it’s optional in the settings.

Link to comment
Share on other sites

What you’re describing violates the speed of light. Photons have a fixed maximum speed, be it via a laser or a radio signal, and at interstellar distances the distances are measured not in multiples of metres, but by the distance that light travels in a given period of time e.g. light years; light goes at ~300,00km/s so those distances are pretty staggeringly large- a light year is about 9x1015 metres, or 9 million billion metres! Nothing can go faster than that (bar the so far hypothetical FTL tachyon which might not even exist) and pretty much everything else goes slower.

Signal delay is bad enough just communicating to and from the Moon (just over a light second each way) so remotely driving a little rover on the Moon from the Earth would have a noticeable and very distracting input delay; Mars is light minutes away (hence the need to program rovers and probes to do what they’re doing in advance then sit and wait to find out if it worked), Jupiter closer to a light hour and the nearest star over four light years away, so even with the 1/10th scale of the Kerbals’ universe those distances are still too long for direct control even at interplanetary distances.

Edited by jimmymcgoochie
Link to comment
Share on other sites

33 minutes ago, jimmymcgoochie said:

What you’re describing violates the speed of light. Photons have a fixed maximum speed, be it via a laser or a radio signal, and at interstellar distances the distances are measured not in multiples of metres, but by the distance that light travels in a given period of time e.g. light years; light goes at ~300,00km/s so those distances are pretty staggeringly large- a light year is about 9x1015 metres, or 9 million billion metres! Nothing can go faster than that (bar the so far hypothetical FTL tachyon which might not even exist) and pretty much everything else goes slower.

Signal delay is bad enough just communicating to and from the Moon (just over a light second each way) so remotely driving a little rover on the Moon from the Earth would have a noticeable and very distracting input delay; Mars is light minutes away (hence the need to program rovers and probes to do what they’re doing in advance then sit and wait to find out if it worked), Jupiter closer to a light hour and the nearest star over four light years away, so even with the 1/10th scale of the Kerbals’ universe those distances are still too long for direct control even at interplanetary distances.

 

42 minutes ago, MechBFP said:

The speed of light is the speed of light.

Thanks

I expressed myself in the wrong forms.

I was referring to transferring more data in less time.

Edited by Lo.M
Link to comment
Share on other sites

1 hour ago, MechBFP said:

The speed of light is the speed of light.

*Laughs in Kraken attacks*

Okay, so it's more like transmission rate changing depending on distance. And that is something I could get behind (a reason to set up large relay arrays and stuff so data can go in larger packets at once)

But then we know nothing about communication. I assume there will be some kind of commnet, but I also assume that a) extrasolar outposts will be independent of ksc, and/or b) there will be no need to sit and watch the transmission going. I don't think there will be science points either, so if colony on Puf discovers new tech, it will be available everywhere else just like that.

Link to comment
Share on other sites

5 hours ago, Lo.M said:

Signal delay in comunications in ksp 2?

Example: The signal that will be transmitted from a spaceship in another star system to Kerbin or a colony

I think this should be option to toggle in settings of your save. If you want it you can have it on. If you don’t you can turn it off. I it should I think this should be default this off if this is an option in settings.

Link to comment
Share on other sites

The only way that would really work (for probe control) would be a stock KOS-like programmed autopilot.  And not a lot of people want to learn a programing language to play.  KSP1 already has <20% of players making it to a Mun landing or something like that?  How many more would be lost if you had to learn KoS just to launch a probe?

For transmitting science - however KSP2 ends up doing it - IMO, not crazy about it either:  Do you really want to wait 2 or 3 years game time for that amazing discovery you just made on Rusk to be sent back to KSC at the speed of light?  

Which is not to say I wouldn't consider using signal delay if it was an option, but I'm not sure it would be a good use of dev's resources.

Link to comment
Share on other sites

If someone wants to play with autopilots or by coding their own control systems having signal delay actually being there makes no difference at all, and you make kerbal useful by making them useful not by making probes a pain to use.

 

 

 

Edited by Master39
Link to comment
Share on other sites

Here I am not talking about waiting for the next year to receive the for exemple Ovin signal, but rather short times of difference in transmission and reception of signal, over long distances.

4 hours ago, jimmymcgoochie said:

Signal delay is bad enough just communicating to and from the Moon (just over a light second each way) so remotely driving a little rover on the Moon from the Earth would have a noticeable and very distracting input delay; Mars is light minutes away (hence the need to program rovers and probes to do what they’re doing in advance then sit and wait to find out if it worked), Jupiter closer to a light hour and the nearest star over four light years away, so even with the 1/10th scale of the Kerbals’ universe those distances are still too long for direct control even at interplanetary distances

 

Edited by Lo.M
Link to comment
Share on other sites

It provides an obvious and (sort of) realistic incentive to take on crewed missions, which have higher dry masses (especially if there's life support involved) and are generally harder.

It encourages an entirely different gameplay loop and incentivizes players to learn about how to design and deploy constellations, how resonant orbits work, power management and orbit darkness time (if there's background simulation of EC usage, which there isn't in stock currently) and, depending on implementation, even a bit of coding with something like KOS. It can help you understand real-world situations- you don't want to be driving your rover with 500ms delay because you put your CommNet constellation in a surface-synchronous orbit, so instead maybe you make something more like Starlink. Now you need to either launch tons of satellites (launch automation should really be something included in KSP2) or plan ahead and restrict your surface activities to times when you have connectivity. Maybe you set it up so that you only have a connection in the day time, for example. You'd have "working hours" and actual schedules to keep.

It also encourages you to build and fly in a very different way. Landing with direct control and signal delay requires you to either have an inefficient landing profile (cancelling all your horizontal velocity first and then descending straight down) so you can reliably stay in the attitude you want, OR you can send a crew along to stay in orbit and pilot the probe down  in more or less real time. If you're landing with a lot of delay you probably want a lander that's much more passively stable than a manned one, which can just brute-force a landing with reaction wheels. Of course, later on in the tree you can unlock probes that have pilot capabilities which wouldn't be subject to signal delay since they're onboard, so that's a nice career mode incentive. Data transmission simulation in general could provide extra incentive to upgrade your tracking station in a career game.

In the context of interstellar colonization signal delay would have huge significance. The distances involved make signal delay even more important to consider. It should definitely be in stock. KSP2 shouldn't be as reliant on mod authors to keep important gameplay mechanics up to date.

Of course, just like all the other difficulty settings in KSP1, it should be an option. So you can choose if you want to play with it or not.

Link to comment
Share on other sites

42 minutes ago, Jodo42 said:

It provides an obvious and (sort of) realistic incentive to take on crewed missions, which have higher dry masses (especially if there's life support involved) and are generally harder.

Turning probes into a chore is not an incentive to play crewed missions, it's an incentive to not use probes.

And we don't plan to send humans because of the signal delay, that's a utterly ridiculous reason to send a crew instead of a probe.

You don't incentivize a gameplay loop by lowering the rest of the game to the same level of uselessness.

 

48 minutes ago, Jodo42 said:

an entirely different gameplay loop and incentivizes players to learn about how to design and deploy constellations, how resonant orbits work

You can do that by delaying the data sent back or the amount of science points recovered, not by introducing control lag.

 

50 minutes ago, Jodo42 said:

power management and orbit darkness time (if there's background simulation of EC usage, which there isn't in stock currently) 

That doesn't require signal delay and wouldn't be affected by it.

 

52 minutes ago, Jodo42 said:

depending on implementation, even a bit of coding with something like KOS

Something like KOS would be useful and a reasonable addition even without signal delay, and I assure you that not forcing programming onto players but just having it as an useful option works best for everyone.

 

57 minutes ago, Jodo42 said:

It also encourages you to build and fly in a very different way.

By removing the "flying" part of the game for everything that's not manned.

Link to comment
Share on other sites

27 minutes ago, Starhelperdude said:

as a mod or a thing that is in the settings? yeah

but I'm against it as a stock standart feature

Me too

It could be something not mandatory in the settings. 

Link to comment
Share on other sites

16 minutes ago, Master39 said:

Turning probes into a chore is not an incentive to play crewed missions, it's an incentive to not use probes.

And we don't plan to send humans because of the signal delay, that's a utterly ridiculous reason to send a crew instead of a probe.

You don't incentivize a gameplay loop by lowering the rest of the game to the same level of uselessness.

 

You can do that by delaying the data sent back or the amount of science points recovered, not by introducing control lag.

 

That doesn't require signal delay and wouldn't be affected by it.

 

Something like KOS would be useful and a reasonable addition even without signal delay, and I assure you that not forcing programming onto players but just having it as an useful option works best for everyone.

 

By removing the "flying" part of the game for everything that's not manned.

Massive, game-altering mechanics should be in stock, whether people feel like playing with them or not. It shouldn't need to be maintained by unpaid modders. If you don't like constraints that make you change the way you play then don't use them. That's why pretty much all difficulty options are just that, options. Not including it in stock (eventually) is an omission without a point.

Quote

Turning probes into a chore is not an incentive to play crewed missions, it's an incentive to not use probes.

Good thing there's a progression system that forces you to use lightweight probes if you don't have the lift capability or in-space infrastructure necessary for crewed missions yet.

Quote

And we don't plan to send humans because of the signal delay, that's a utterly ridiculous reason to send a crew instead of a probe.

You clearly read my piece about crewed telerobotic missions since you excluded it from the rest of your post. Nowhere do I say "instead." Good luck putting boots on Venus. Send a rover and control from Earth like with Mars? Sure, but it's incredibly slow. It's so slow that we decided to send a helicopter with the recent rover to help speed navigation up. That's directly because of two things: signal delay and bandwidth. A remote-controlled rover on Eve would be far easier to get surface samples and biome science from if it could be driven in real-time like it currently is ingame. So now a one-way mission becomes two-way and there's extra gameplay in the "flying" which you seem to love so dearly. 

Quote

You can do that by delaying the data sent back or the amount of science points recovered, not by introducing control lag.

Suggesting that the devs should implement signal delay that only goes one way instead of signal delay is just creating an unnecessarily contrived solution. If the code's there for the first part then it's there for the option of the second part.

Quote

That doesn't require signal delay and wouldn't be affected by it.

It's not affected by signal delay, but signal delay would be affected by it. If you build your CommNet probes so that they only have power on the day side then they won't relay your signal when they're on the night side. If you've set up some high-eccentricity orbits for your relays (like Molniya and orbits in real life) then they're going be spending a lot of time in darkness for part of the year. Your signal delay could be significantly increased if you haven't planned your constellations properly and the signal needs to reroute to avoid hibernating satellites.

Quote

Something like KOS would be useful and a reasonable addition even without signal delay, and I assure you that not forcing programming onto players but just having it as an useful option works best for everyone.

Glad we can agree that big gameplay enhancing mechanics should be an option. Not including them in stock makes it not an option until the mod gets made- and we can only speculate on how moddable KSP2 will be. And of course, there's console players to think about who just can't get mods period. 

Quote

By removing the "flying" part of the game for everything that's not manned.

I don't think being forced to plan your maneuvers in advance, and in a way that's simple enough to be done with signal delay, is removing flying. It's addition through subtraction- it's a completely different way of flying and a new set of challenges for players to figure out. In the example with early interplanetary probes without onboard pilot functions, you might fly an entire extra mission to test passive reentry around Kerbin.  Even if it is "removing flying"- signal delay adds more than enough gameplay in the planning stage to compensate. I don't know about you, but a big chunk of my enjoyment of this game- perhaps even the majority- is in the mission planning and building phase. As I explained, signal delay adds a lot to this phase that gets little attention without its presence. 

It should be an option, in stock. It doesn't need to release with the game. It could be a later patch or DLC. It doesn't need to be super high priority. But it should absolutely make its way into the dev-updated versions of the game at some point.

Link to comment
Share on other sites

×
×
  • Create New...