Thoughts on stock communication system in ksp 1.1

[gogozerg]

And I consider the time frame in which a command is executed from the time a player touches a physical keyboard to the time the in-game ship 'does something' orthagonal to local control. So the design goal is to simulate, in a reasonably believable way, how that probe would behave when occluded. YMMV.

I read 4 times, but still can't get it...

Well, the reasons why we'll end up with unrealistic and unsatisfactory features are rather obvious if control directly depends on occlusion. So i'm just saying "please do nothing". :-)

[RoverDude]

What I am saying is that there are other ways to simulate partial control other than 'signal delay and a flight computer', simple as that.

[FancyMouse]

My 2 cents.

I enjoy RemoteTech and don't expect I would use the upcoming stock comm system given what I've heard. I use stock ISRU and didn't bother Kethane/Karbonite/ScanSAT stuff.

If I don't like how stock works... Guess what? I CAN TURN IT OFF!!!

If I don't like HOW it works, but like the general idea... Guess what? I CAN GET A MOD!!!

I guess if the stock design keeps this argument true if possible, then I'm all happy.

[Tarmenius]

From what I understand based on the article (and someone correct me if I'm wrong here), the Relay Network feature will affect 2 Game Systems: probe control and science transmission.

For probe control, I see only 3 ways to handle occlusion: 1) The player loses all control of the probe; 2) The player retains all control of the probe; 3) The player retains some control of the probe. #1 is unreasonable (and unrealistic), #2 means the feature will only affect 1 Game System, making #3 the likely solution. To implement this they could say attitude control is removed but throttle control remains (or vice versa), but that doesn't make much logical sense. So, the most reasonable solution seems to be some form of "programming" of the probe. Allowing it to execute maneuver nodes is likely the best way as tater most recently mentioned, and for the reasons he gave. But given that the current probe control mechanics limit which can be used for SAS functions, it could end up that only some probes can be "programmed" at all. If that's the case, I hope it's only the very early one or two probe cores which lack that functionality.

For science transmissions, the solution's probably obvious to anyone: No transmissions without line of sight to Kerbin or another probe which itself has line of sight to Kerbin.

What I am saying is that there are other ways to simulate partial control other than 'signal delay and a flight computer', simple as that.

Care to elaborate on those other ways? I'm having a hard time imagining what they are.

[rcp27]

I think the issue of communications in KSP is a difficult one. Consider a few aspects of how real space flight and communications issues are dealt with.

Ground based communications is really very good and very extensive. I can buy a satellite dish that can receive signals from a satellite in geosynchronous orbit for a price that is affordable to your average consumer. The ability to get signals to and from Earth's surface to low orbit satellites is, frankly, trivial.

Ground based communications are also able to get signals to and from probes a very long way away is possible without space-based communications relays. The Voyager probes are both far beyond the height of aphelion of Pluto, and we are able to send commands to them and receive data back from them using ground based communications facilities.

Space probes can be programmed with complex manoeuvres in advance, and execute complex flight profiles autonomously without direct command from mission control. For example the atmospheric entry, parachute descent and sky-crane landing of the Curiosity rover on Mars was all executed based on flight programs uploaded to the craft in advance. The signal delay between Earth and Mars made direct control impossible anyway.

If you want to impose "realistic" constraints on KSP, therefore, if you are going to be able to execute the kinds of missions we see happening in the real solar system, we also need "realistic" tools to overcome those constraints. That means something probably more complex than kOS, and the ability to simulate missions in advance of executing them. While that is definitely realistic, I'm not sure it is fun.

The question, then, is where is the right balance between realism and fun?

[mikegarrison]

The game already has a mechanism for locking you out of using maneuver nodes. Right now you need at least one upgrade in the tracking station and one upgrade in the mission control. So there must be code for this already.

A pseudo-realistic way of dealing with occlusion, signal delay, etc. would simply be that you can't make a maneuver node for a probe unless you A) have a signal path back to mission control, and have enough time to get the message from mission control to the ship before the node. (It's silly to ignore B, but it sounds like Roverdude is going to insist on doing that. But A could still be implemented.)

The other aspect of this could be that you can only control probes with maneuver nodes. Also, you could go a step further and say all hand-flying of probe engines is disallowed. Give all probes the "point to node" SAS mode, give all probes a very simple autopilot that only executes node burns, and require all probe maneuvering to be by use of nodes. That would simulate remote control from the ground pretty well without requiring any special flight computers. You just use the same maneuver node system players already know, but robot probes would fly the nodes robotically. That makes sense to me!

You could still allow probes to be launched by hand if you made a sphere around Kerbin (say 100 km) where probes were allowed to be flown by hand.

This would make soft-landing probes on distant bodies very difficult, however. But there would be mods for that. MechJeb can already soft-land probes very well.

[boosters++]

I think AntennaRange is a good difficulty level for the base game's target realism, and this system sounds basically like AntennaRange, so it strikes me as appropriate.

RemoteTech will be updated, no doubt, to please the realism crowd (of which I am a part).

To me, KSP can come in different flavors. I'm currently building my first multi-module space station in Realism Overhaul, and I had to build a RemoteTech network to do it easily. Sometimes that's the game I want to play.

Other times I want to play the vanilla game, more or less, for a more casual experience - and AntennaRange is a great fit there.

So, thumbs up. This is one less mod to install for me to get one kind of play I want.

[juanml82]

You don't know what will happen to a probe flying 100,000,000 km away, 5 minutes after you sent a message.

I don't understand what you mean. Yes, a probe might be destroyed hours before ground control realizes it, but ground control issues commands to real life probes to be executed in advance because they have a very reasonable idea of what's going to be happening to those probe by the time they have to execute the command (unless it's hit by dust, the landing sequence is innacurate or any other issue)

[tater]

True; but then what's to stop people using that system everywhere. Bingo, you effectively have full perfect autopilot everywhere, something Squad has been against since forever. I also can't think of any good in-game justification why it would ONLY work while probes are occluded. Furthermore, the maneuver node system as-is is insufficient for landing burns.

Such a system would also prevent things from going hilariously wrong. When the player performs a burn there's always the chance the burn isn't perfect. Hitting the wrong key, drifting off course, getting the timing wrong, etc. And this is, arguably, what a lot of KSP is about. Sure, a lot of people play KSP closer to a Sim, but for those people there's mods.

Add in communications delay. The simplest way is to disallow making a node any closer to the present position of the craft than 2X the time delay (1 delay time interval for the craft to report exact last status, etc, the next for the program to be sent).

The skill in "piloting" in KSP is making the maneuver nodes, not executing them, IMO. I've always found it absurd that you can't order a modern craft to point in direction x, and burn for precisely XX seconds. Note that the engines can have a spool up/down time that would create some gray area around node execution. Assume the auto-execution uses ONLY full throttle, perhaps. It's not an impossible problem.

The point where "stick and rudder" piloting would matter would be landing. Which is fine.

- - - Updated - - -

Contradictory. It would only be good for things that maneuver nodes work well for, other things like ascent, landing, docking, etc would not have "full, effective autopilot".

Yep. I agree.

- - - Updated - - -

What I am saying is that there are other ways to simulate partial control other than 'signal delay and a flight computer', simple as that.

"Partial control?"

You either receive a command, or you don't/can't.

- - - Updated - - -

Actually, in addition to just time delay for light-lag, you could simply have an arbitrary delay. Probes are steered BY COMMITTEE. Data comes in. Probe guys look at it, talk among themselves, decide what to do, then send new commands.

You could simply say for probe cores no node can be set within X hours of the present position plus time lag (useful for scaled up solar systems where the light delay might actually be comparable to the committee time).

[gogozerg]

I don't understand what you mean. Yes, a probe might be destroyed hours before ground control realizes it, but ground control issues commands to real life probes to be executed in advance because they have a very reasonable idea of what's going to be happening to those probe by the time they have to execute the command (unless it's hit by dust, the landing sequence is innacurate or any other issue)

First of all, when ground control issues commands to a ship, it computed the ship will be able to receive it when the signal reaches the area (no nearby moon or asteroid coming in between in the meantime). Obviously you don't have this problem if communications are instantaneous.

But am I the only one afraid of playing a "space program simulation" where the speed of light is infinite?

We/I have fun dealing with somewhat realistic orbits, ISP, TWR, staging, etc., etc. that make the game great. And now, infinite light speed, while such things are so fondamental in space flights?

For now, all controls can be seen as purely local, by astronauts or onboard AI. I agree this is not how unmanned missions work, but this is the way the game is conceived (it's about piloting ships directly - go to tracking station, select your ship, and press "Fly"), and it makes much more sense than many other ideas I heard.

Edited July 29, 2015 by gogozerg

[Superfluous J]

But am I the only one afraid of playing a "space program simulation" where the speed of light is infinite?

Having played RemoteTech with speed of light delay, I can wholeheartedly say I am not only not afraid of that, but I am actually afraid of the reverse. I'm afraid that if lightspeed delay is implemented, I'll lose every bit of desire to play KSP and move on to another game.

[gogozerg]

Having played RemoteTech with speed of light delay, I can wholeheartedly say I am not only not afraid of that, but I am actually afraid of the reverse. I'm afraid that if lightspeed delay is implemented, I'll lose every bit of desire to play KSP and move on to another game.

Same as you.

[regex]

Are you guys for real? Of course they're not going to implement a light-speed delay, that would require a proper flight computer that you could program in some fashion.

Of course, what we could get is random input or short control delays to really hack people off... Then you'll be wishing they had implemented light speed delay with a programmable flight computer.

[TMS]

What I am saying is that there are other ways to simulate partial control other than 'signal delay and a flight computer', simple as that.

Care to elaborate on those other ways? I'm having a hard time imagining what they are.

My take: http://forum.kerbalspaceprogram.com/threads/129662-Thoughts-on-stock-communication-system-in-ksp-1-1?p=2104826&viewfull=1#post2104826

I think I'm on the right lines.

[razark]

I think that programming a probe need not be any more complicated than "make a maneuver node." The probe then executes the node when it gets there.

This is a good idea.

(Of course, I figured that this was what the pilots would be able to do.)

[juanml82]

First of all, when ground control issues commands to a ship, it computed the ship will be able to receive it when the signal reaches the area (no nearby moon or asteroid coming in between in the meantime). Obviously you don't have this problem if communications are instantaneous.

But am I the only one afraid of playing a "space program simulation" where the speed of light is infinite?

We/I have fun dealing with somewhat realistic orbits, ISP, TWR, staging, etc., etc. that make the game great. And now, infinite light speed, while such things are so fondamental in space flights?

For now, all controls can be seen as purely local, by astronauts or onboard AI. I agree this is not how unmanned missions work, but this is the way the game is conceived (it's about piloting ships directly - go to tracking station, select your ship, and press "Fly"), and it makes much more sense than many other ideas I heard.

But... ground control doesn't race against the clock. They've issued commands to New Horizons to take all those pictures of Pluto long before the five hours or so before those pictures had to be taken. Had something been in on the way and the signal gotten blocked, NASA would have known with a lot of advance. As for moons, known (largish) moons and their orbits are well known by now.

Yes, space probes often fail. But not because the people in charge of those missions failed to account for signal delay or occlusion.

[mikegarrison]

But... ground control doesn't race against the clock. They've issued commands to New Horizons to take all those pictures of Pluto long before the five hours or so before those pictures had to be taken. Had something been in on the way and the signal gotten blocked, NASA would have known with a lot of advance. As for moons, known (largish) moons and their orbits are well known by now.

Yes, space probes often fail. But not because the people in charge of those missions failed to account for signal delay or occlusion.

Actually, they did race against the clock. As NH approached Pluto they tried to have the probe simultaneously record data from the sensors and also send data back home, but it ran out of memory and crashed the system. So they urgently wrote up a new set of instructions that had the probe shut down communication while it recorded the data from the sensors during the flyby. That's why they were unable to communicate with the probe while it was actually flying by Pluto.

http://in.reuters.com/article/2015/07/06/space-nasa-pluto-idINKCN0PG24B20150706

[cantab]

For probe control, I see only 3 ways to handle occlusion: 1) The player loses all control of the probe...#1 is unreasonable (and unrealistic)

I've played with exactly that behaviour from Antenna Range and found it good. I had to be mindful of when I did and didn't have connection, for example one mission was limited to operating in the fraction of Minmus's day I had both Kerbin and the Sun in sight, and I made good use of relay orbiters. As for realism, it's no more or less unrealistic than the lack of a speed-of-light delay.

[Thomas988]

Excuse me for asking, but I've been so busy lately I haven't been able to follow recent KSP news. Does this mean we're going to have communication between probes in 1.1, or are we just suggesting ideas here?

[Camaron]

I will pass NO JUDGEMENT on anything Squad does until they actually do it, and until I've actually had a chance to try it.

(And, so should you.)

To clarify after razark's reply, "Judgement" being different from having an opinion.

Opinion - I like this idea of communication probes like the Deep Space Network. I really do. I hope Squad implements it well.

Judgment - I have no idea if I like how Squad has done it, because they haven't yet. A lot of people make the mistake of making final judgements on features before they even really exist, and that's what I was talking about.

Edited July 31, 2015 by Camaron

[razark]

And, so should you.

That's an utterly ridiculous idea.

If Squad says "We want to do X", and people think it's a bad idea, they should be free to speak up about it. If they support it, they should also be free to speak up. If people wait to say anything until afterwards, the chance of them having a meaningful voice is much lessened.

[RoverDude]

Actually, the reason we announced this feature early was to give the community some time to mull it over, and to provide constructive feedback (a great deal of which has already been reincorporated into the design).

[Superfluous J]

Excuse me for asking, but I've been so busy lately I haven't been able to follow recent KSP news. Does this mean we're going to have communication between probes in 1.1, or are we just suggesting ideas here?

Yes, we will have to deal with some form of antenna range and object occlusion in (as yet) unspecified degrees. It was announced last week by Ted.

[Tarmenius]

I've played with exactly that behaviour from Antenna Range and found it good.

Ok, so maybe "unreasonable" was the wrong choice of words Still, I imagine that would frustrate more players than it would please. And while it's no more realistic than instant-light-travel, most people don't think about the speed of light in their daily lives (though many of us here do, I'm sure). So the fact that it's instantaneous likely doesn't even register to most players. That unrealistic "game simplification" is much less likely to be noticed in the first place than the fact that people's probes don't work at all sometimes.

Actually, the reason we announced this feature early was to give the community some time to mull it over, and to provide constructive feedback (a great deal of which has already been reincorporated into the design).

Glad to hear that. I'm looking forward to the feature regardless, and it'll be interesting to see how you implement it.

Edited July 30, 2015 by Tarmenius

[Vasious]

Sounds good.

A nice balance, with the option or relays, but not the need to build an intial netwrok each time