KSP Keostationary Orbits broken

[Starman4308]

Another way to think about what Corona and I have been saying:

Position during iterative physics is a function of where you were before. Keeping things simple and ignoring acceleration:

x(t₀+dT) = x(t₀) + v*dT

Thus, x(t₀+dT) is a function of x(t₀), and the error in x(t₀+dT) is a function of the error in x(t₀).

Given floating-point errors, you have issues because of an imprecise x(t₀), imprecise v, and potentially even imprecise dT if you choose a strange timestep.

What's worse is when you consider future timesteps.

x(t₀+2*dT) = (x(t₀) + v*dT) + v*dT

x(t₀+3*dT) = ((x(t₀) + v*dT) + v*dT) + v*dT

You get compounding sources of error taking your ship farther and farther from where it should truly be. So, the error in x(t+3t) is a function of the error in three prior timesteps.

 

Position during on-rails orbits is not a function of where you were before.

x(t) = f(SMA, eccentricity, inclination, argument of periapsis, longitude of the ascending node, mean anomaly at epoch, t)

You can calculate this for any time t, without ever needing to know x(t₀). While you have seven sources of uncertainty (6 orbital elements and time), six of them are consistent for any given time t. So, if you Hyperedit vessels into a perfect constellation (same plane, same SMA), they will remain in that constellation forever, plus or minus a few meters' wobble around the true position.

Without Hyperedit or similar, you're never going to get quite exactly perfect without extreme luck; even if you're utterly precise with your burns, there is some uncertainty when going from iterative physics to the 6 orbital elements; the game isn't completely precise storing your velocity and position when in iterative physics, so it won't be completely precise converting that to an orbit. Once you're on-rails, though, there are only five things that can possibly change your orbit:

1: Switching back to the vessel, thus switching back to iterative physics.

2: Transitioning to a new sphere of influence.

3: Impact with a planet.

4: Deleting the vessel in the tracking station.

5: Editing the orbit using Hyperedit, save file editing, or similar.

[Starman4308]

24 minutes ago, Geschosskopf said:

I KNOW what you say is SUPPOSED to be true.  But the problem is, it doesn't work out that way in practice.  And AFAIK, there is no cure for this.  Every game that purports to have even semi-realistic orbital mechanics going on has the same problem.  Crank time warp "up to 11" and the universe falls apart sooner rather than later.  That's the inevitable result of trying to replicate what is in reality an n-body "analog"* system with what is, by the nature of the underlying hardware and software, a discrete X-body system.  In stock KSP, X=2.  If you have some mod that does "n-body" (however that math is defined), you still can't escape the bottom limit of the positional coordinate system, which is orders of magnitude greater than the Planck Length.

There's something beautiful about the Keplerian 2-body approximation when you ignore collisions and SOI transitions:

You don't need to calculate forces, velocities, positions, or anything like that timestep after timestep. You don't need to integrate any laws of motion, because there's a closed-form solution to position given time.

You just take your 6 stored orbital elements, the current clock, plug it into an equation, and get out your new position.

That's largely what KSP does: it checks each vessel to see if there's an impact or SOI transition it has to handle, else it simply just updates the clock, and moves the vessel to the new position blissfully ignorant of where it was before.

Again, I tested this. I set up a constellation of satellites using Hyperedit, warped time forwards a few years at max timewarp, and they were still perfectly aligned.

 

If using some sort of iterative physics solver, solar systems will tear themselves apart given time. Even under Keplerian 2-body physics, unless you have an integration scheme that conserves all the relevant quantities, it'll tear itself apart due to these floating-point issues. Under N-body physics, not only is an iterative physics solver necessary*, it's a chaotic system; the solar system will fall apart, with some bodies colliding with the central body, and other bodies ejected off to infinity.

*Technically there's a non-iterative way to do it, but it's an infinite sequence of terms that, even when truncated, is very impractical as more than a demonstration.

While setting a large timestep makes inaccuracies manifest themselves sooner, an N-body system such as the real-world solar system is literally fated to fall apart. Major changes have already happened; it's thought that Uranus and Neptune switched places long ago in the early Solar System, and we quite possibly had another body ejected from the system entirely. Even if you had infinite precision and an infinitely short timestep (no numerical issues at all), N-body physics is inherently chaotic.

Edited November 30, 2017 by Starman4308

[Corona688]

32 minutes ago, Geschosskopf said:

I KNOW what you say is SUPPOSED to be true.  But the problem is, it doesn't work out that way in practice.

Work out how?  "On rails" does not mean "perfect".  There's no way to get a perfect orbit in the first place without editing.

Squad has done a good job of plumbing the limits possible with 32-bit numbers but these limits still exist.

This is not the same thing as "orbits on rails still get less accurate".  That is simply wrong.  Sources in this very thread contradict you on that.

8 minutes ago, Starman4308 said:

Again, I tested this. I set up a constellation of satellites using Hyperedit, warped time forwards a few years at max timewarp, and they were still perfectly aligned.

Remember - if you fly a craft or even just approach within several km of it, its perfect orbit is ruined when iterative physics kicks in.  Getting and keeping a perfect orbit is tricky.

Edited November 30, 2017 by Corona688

[Geschosskopf]

40 minutes ago, Starman4308 said:

There's something beautiful about the Keplerian 2-body approximation when you ignore collisions and SOI transitions:

Which, unfortunately, KSP does not ignore for on-rails ships at least when high levels of time warp for prolong periods is involved.  This is not about the underlying math being "wrong", it's a computational limit inherent to what the hardware and software are trying, but failing, to do correctly with said math.  Those are entirely different issues.

 

40 minutes ago, Starman4308 said:

You don't need to calculate forces, velocities, positions, or anything like that timestep after timestep. You don't need to integrate any laws of motion, because there's a closed-form solution to position given time.

Yet the game does these things.  Otherwise, the observed results would not be happening.  Ships get torn from their orbits, or at the very least their orbits have substantial drift, precisely because the forces acting on on-rails ships vary over time, and the game takes that into account.  If things were as you say, none of that would happen.

 

33 minutes ago, Corona688 said:

Work out ho  "On rails" does not mean "perfect".  There's no way to get a perfect orbit in the first place without editing.

Squad has done a good job of plumbing the limits possible with 32-bit numbers but these limits still exist.

Squad did do a good job, at least for the original purpose(s) they intended.  Which were A) getting to LKO and (rather later in time) getting to Mun.  For trips beyond those distances, and the time warps they involve, the system has numerous. obvious, inherent flaws.  Just look at the struggle of creating an interplanetary transfer maneuver node.  The system is great within the Kerbin SOI, barely tolerable at Duna, and horrible for anywhere further away.  And that's just the tip of the iceberg.  KSP cannot escape its roots of being optimized for just getting to Mun.  Anything beyond that is gravy and also rather fuzzy.

This is something even old-timers tend to forget because we've had so many other destinations for so long, and because we've long since had our coping mechanisms on autopilot so don't usually give such things a 2nd thought.   And it's something newcomers don't even know about because everything in the current version is spread enticingly before them, without the underlying context.  But it is what it is.  It's not a math issue, it's a computational issue.

 

33 minutes ago, Corona688 said:

This is not the same thing as "orbits on rails still get less accurate".  That is simply wrong.  Sources in this very thread contradict you on that.

And those sources are obviously wrong because they do not match observations.  Neither the OP's nor my own, nor those of countless other players.  For the reasons I have outlined above.

 

33 minutes ago, Corona688 said:

Remember - if you fly a craft or even just approach within several km of it, its perfect orbit is ruined when iterative physics kicks in.  Getting and keeping a perfect orbit is tricky.

And none of that matters because inherent computational limits throw things "off the rails".

[Corona688]

1 minute ago, Geschosskopf said:

Which, unfortunately, KSP does not ignore for on-rails ships at least when high levels of time warp for prolong periods is involved.  This is not about the underlying math being "wrong", it's a computational limit inherent to what the hardware and software are trying, but failing, to do correctly with said math.  Those are entirely different issues.

That's nice, but that's not what you said a page ago.

[Starman4308]

15 minutes ago, Geschosskopf said:

And those sources are obviously wrong because they do not match observations.  Neither the OP's nor my own, nor those of countless other players.  For the reasons I have outlined above.

Could you kindly cite me these observations of orbits changing?

Ensure the following:

The vessels did not change spheres of influence or collide with a body.

At no point did they exit on-rails physics, either by directly switching to that vessel, or moving an off-rails vessel close to them until they entered the iterative physics bubble.

If it refers to an alignment of vessels, such as a keostationary communication network, those vessels were placed by Hyperedit or similar so they had exactly the same semi-major axis, and not just approximately the same semi-major axis.

I will point out that nothing I've said contradicts "it is virtually impossible to set up a perfect keostationary network in KSP without mods or save file editing". There's simply too much imprecision in the off-rails, iterative physics calculations to get exactly the orbit you wanted, no matter how careful of a pilot you are.

Edited November 30, 2017 by Starman4308

[Spricigo]

13 minutes ago, Starman4308 said:

Could you kindly cite me these observations of orbits changing?

My observations, taking the precautions you mentioned, are exactly the same of yours: no orbit change.

 

 

[Geschosskopf]

1 hour ago, Corona688 said:

That's nice, but that's not what you said a page ago.

If there is any confusion on that, it's because we are using different words for the same thing and I've been trying to speak your language and cater to your incorrect assumptions. The undeniable fact is that "on-rails" is not constant, which is the point I've always been trying to convey.  Accept that and move on.

 

54 minutes ago, Starman4308 said:

Could you kindly cite me these observations of orbits changing?

If you haven't experienced this yourself, and doubt the OP having had this happen, then we'll have to agree to disagree.

[Corona688]

Just now, Geschosskopf said:

If there is any confusion on that, it's because we are using different words for the same thing and I've been trying to speak your language and cater to your incorrect assumptions. The undeniable fact is that "on-rails" is not constant, which is the point I've always been trying to convey.  Accept that and move on.

No.

That's all I get from you for a long detailed explanation.  That's all you'll get from me for an unsubstantiated opinion.

[Geschosskopf]

5 minutes ago, Corona688 said:

No.

That's all I get from you for a long detailed explanation.  That's all you'll get from me for an unsubstantiated opinion.

Yes, that's all you get, because your explanation is wrong.  You are confusing math/physics errors with computational limits, which are entirely different things.  It's quite possible, as is the case with KSP, to have solid underlying math but still to have things go haywire when the computational limits are exceeded.

[Corona688]

4 minutes ago, Geschosskopf said:

Yes, that's all you get, because your explanation is wrong.  You are confusing math/physics errors with computational limits, which are entirely different things.

You have drastically misread my post.  It is all about both.  If there's anything wrong with my explanation, either, you haven't bothered to say what.

Reread and respond to it, if you like.  If you still believe I am wrong, explain why you  think so.

Or, you know.  Don't.  Have fun.

Edited November 30, 2017 by Corona688

[Geschosskopf]

45 minutes ago, Corona688 said:

You have drastically misread my post.  It is all about both.

OK, hopefully we can now discuss this seriously.  Let us assume the following:

1. 2-body math works perfectly well for pretty much everything players might want to do in KSP except park something at a Lagrange point.
2. Nothing in the game moves simultaneously.  IOW, planets and the ships orbiting them move at different times because the game code can only more 1 thing at a time.
3. Ships that are "on rails" are still affected by local their local 2-body gravity whenever it's their turn to move.  This is manifestly true because you can send ships to fly-by other planets and never touch them again, but still their trajectories are changed by the encounters.

#3 means that an "on rails" ship orbiting a planet must take that planet's gravity into account every time it's that ship's turn to move.  If neither the ship nor the planet has moved very far since last time, the gravitational difference from where they both are now and where the ship was predicted to be last time is insignificant and the player doesn't notice.  However, #2 means that at high warp settings, especially if prolonged, there can actually be a significant difference between where the ship's previous trajectory would have put it relative to the planet, and where it actually is now because of their sequential movement.  But #3 means this has to be taken into account for the ship's current move, so the ship's orbit changes.

In the context of maintaining a stable kerbostationary orbit, even a slight difference between where the ship's last move predicted it to be relative to the planet, and where it actually is when it's ship's next turn to move, is enough to cause the constellation's spacing to break down in a few years.  But in extreme cases, such as when orbiting the moon of a gas giant, the difference (at least with enough warp for long enough) can cause the moon to move out from under the ship, so that now the ship is in the SOI of the gas giant instead of that of the moon it was originally orbiting.  This results in only 3 possible outcomes, all of which happen while the ship is "on rails":

1. The ship is on a collision course with the gas giant
2. The ship is in a highly elliptical orbit of the gas giant
3. The ship is on an escape trajectory from the gas giant, which might also, depending on luck of the draw, be an escape trajectory for the entire solar system.

But that's the extreme case.

However, the same processes that make the above happen also happen to satellites in kerbostationary orbits.  It's just that the ship is unlikely to change SOIs as a result unless you use VERY high warp for a LONG time.  But even without that, those processes are quite enough to screw up constellation spacing.  I call this "floating point error".  If you want to be pedantic and call it something else, that's fine.  But the process is still there regardless.

Edited November 30, 2017 by Geschosskopf

[Superfluous J]

@Geschosskopf while I understand the idea and the concept, I have never, ever had this happen to me in the game. I frequently use a time warp mod that I wrote that gives me 100x more warp than the stock maximum and haven't seen it with that, either.

As a test, I started a new sandbox save, put a little ship (capsule, T100 fuel tank, terrier) on the launch pad, and then used the stock orbit tool to put it into orbit of Vall (no real reason, I just wanted a moon of Jool) at the default orbit. I then thrust a bit so it wasn't on some weird "cheat-set" orbit. The orbit it ended on was 386750 Pe x 1755456 Ap.

I then went back to the space center and cranked time warp up to max. 100,000x. I alt-tabbed away and let the game run for a bit. When I came back, the ship had been out in space for 1 year and 342 days (Kerbal time). The orbit was 386750 Pe x 1755456 Ap. It had not changed by a single meter on either side.

It would likely help your argument if you provided recreation steps for a way to - while wholly on rails and not intersecting an SOI changes - have a ship's orbit change like you say happens.

[Starman4308]

43 minutes ago, Geschosskopf said:

#3 means that an "on rails" ship orbiting a planet must take that planet's gravity into account every time it's that ship's turn to move.  If neither the ship nor the planet has moved very far since last time, the gravitational difference from where they both are now and where the ship was predicted to be last time is insignificant and the player doesn't notice.  However, #2 means that at high warp settings, especially if prolonged, there can actually be a significant difference between where the ship's previous trajectory would have put it relative to the planet, and where it actually is now because of their sequential movement.  But #3 means this has to be taken into account for the ship's current move, so the ship's orbit changes.

There's a key flaw in your logic here.

A vessel in orbit around, say, Tylo, does not move with respect to a global coordinate frame. It moves with respect to Tylo. In that reference frame, there is an easy mathematical expression to say exactly where the vessel should be at any given time relative to Tylo.

The game first updates the clock.

The game then updates Jool's position relative to the Sun. This calculation is independent of where Jool was the tick before, it only depends on Jool's orbital parameters and the game clock.

The game updates Tylo's position relative to Jool. You can then calculate where Tylo is with respect to the Sun by adding Tylo's Jool-relative position to Jool's Sun-relative position.

The game updates your satellite's position relative to Tylo. If the game notices that your vessel's path crossed through Tylo, it explodes; if the game notices your vessel's path takes it out of Tylo's sphere of influence, it moves your vessel into Jool's sphere of influence and calculates a new orbit. If neither of these occurred, however, your Tylo-relative orbital parameters do not change.

Again, the game is not calculating the force of gravity for on-rails vessels. It is using nice, simple formulas to calculate where the ship should be given the parameters of its orbit and the game clock, and adjusting those orbital parameters only if you have an SOI transition or surface impact.

Under the Keplerian 2-body approximation, these nice easy formulas mean you never have to calculate the force of gravity, and the only sources of error are:

1: When going from off-rails to on-rails, there is some imprecision in converting your current position and velocity to orbital parameters.

2: There may be some minor issues when passing between spheres of influence, and I'm not 100% sure what the math is for that transition.

3: A very, very minute amount of positional error based on the fact that you still get your output coordinates as floating-point numbers; this error is effectively random and has no impact on future timesteps.

 

EDIT: The issues you are describing would be true for an iterative orbital-mechanics integration scheme, such as would be used for N-body gravitation. Key to KSP, however, is that Keplerian orbital mechanics are very simple and provide easy analytical formulas for position with respect to the parent body over time, and that by defining clear spheres of influence, you can say exactly when a ship crosses over between spheres of influence and the orbit has to be recalculated with respect to the new parent body.

Edited November 30, 2017 by Starman4308

[Spricigo]

1 hour ago, Geschosskopf said:

If you haven't experienced this yourself, and doubt the OP having had this happen, then we'll have to agree to disagree.

No one is doubting the OP. What is being questioned is your claim that it's happening during on-rails warp. 

38 minutes ago, Geschosskopf said:

Ships that are "on rails" are still affected by local their local 2-body gravity whenever it's their turn to move.  This is manifestly true because you can send ships to fly-by other planets and never touch them again, but still their trajectories are changed by the encounters.

Two problems:

1.everyone buy you is telling vessel position is not calculatrd that way.

2.everyone agree that a SoI change(aka encounter) will require new orbital parameters.

So no, that assumption cannot be made. You basically asked to start the discussion disregarding the arguments of everyone else.

 

[Corona688]

1 hour ago, Geschosskopf said:

OK, hopefully we can now discuss this seriously.  Let us assume the following:

1. 2-body math works perfectly well for pretty much everything players might want to do in KSP except park something at a Lagrange point.
2. Nothing in the game moves simultaneously.  IOW, planets and the ships orbiting them move at different times because the game code can only more 1 thing at a time.
3. Ships that are "on rails" are still affected by local their local 2-body gravity whenever it's their turn to move.  This is manifestly true because you can send ships to fly-by other planets and never touch them again, but still their trajectories are changed by the encounters.

1. Huh?
2. I already refuted that!  That's not even close to how it works.
3. This, I  think, is the point of contention.  Your next sentence tells me why you believe this.

"You can send ships to fly-by other planets and never touch them again, but still their trajectories are changed by the encounters."

Timewarp used to work that way, but was wildly inaccurate, computationally wasteful, and blew ships apart.  The game still has it, but calls it "physwarp" and limits you to 4x max for obvious reasons.

Parts "on rails" don't do that.  They jump from T+0 to T+900,000,000 in one calculation, with fantastic accuracy. They're represented as hyperbolas, parabolas, and ellipses -- that is, conic sections.

 

Classical orbital mechanics.  An orbit calculated this way won't go sloppy for a very, very long time.  There's just two catches.

1. How good is the data that was fed into it?  Garbage in, garbage out.  If your orbit was .00001% off, as it inevitably was, the conic section will be at least as wrong.
2. What happens if a moon gets in your way sometime through the third millennium?

...which is why timewarp still does some iterating, just to check if you hit anything.  And if something does get in your way, it either has to drop into physics mode - causing a translation from conics back into positions and velocities - or switch to a different SOI, causing two transitions, from and then back to conic sections, with a rescaling inbetween.

Barring that, when you drop out of timewarp, it's just one calculation away from the numbers you started with.

Edited November 30, 2017 by Corona688

[Geschosskopf]

22 hours ago, 5thHorseman said:

It would likely help your argument if you provided recreation steps for a way to - while wholly on rails and not intersecting an SOI changes - have a ship's orbit change like you say happens.

Geez, read my mission reports going back 4 years or so  

Granted, all those games had mods, lots of mods.  But hey, many people's real games, as opposed to bare bones stock test scenarios, also use lots of mods.  So IMHO warning about this problem is quite relevant, even if it is caused, at least indirectly, by mods.  OTOH, though, it could be a fault of the game once you get enough ships in flight.

Warping is, by definition, skipping steps.  Thus, there are opportunities for things to fall through the cracks.  The faster you warp, and the longer you do it, and the more stuff you have in flight, and the more memory is already taxed by just having mods loaded, the more opportunities there are for cracks to open, and the more stuff there is to fall through them.

So, I am not arguing about how things are SUPPOSED to work.  The game is, by definition, designed so this sort of thing doesn't happen.  No question about that.  But it DOES happen from time to time.

[Spricigo]

1 hour ago, Geschosskopf said:

Geez, read my mission reports going back 4 years or so  

 Your mission report is irrelevant for the discussion. 

 

Either provide a test anyone can do and observe on-rails orbital deviation or accept that you have no evidence to backup your claim.

1 hour ago, Geschosskopf said:

But it DOES happen from time to time.

And you said that you know why it happen. Thus you should be capable ot telling us how to make it happen.

You actually said that warping for a few months at max warp speed is "asking for trouble". However we warped for years and nothing happened. 

I had 20 satellites, in a heavily modded install. I warped for 17years. Results: nothing! Not even a single meter of deviation.

 

So what is wrong with my test? Is there a specific mod I need to add to my game? Is there some celestial body where the issue happens more often? Should I have a tea or eat a snack during the test?  (Notice those are rhetorical question, I already know your answers: "I don't know. I don't want to test my claim.")

[OHara]

Orbits are a fundamental tool on which KSP depends, and which most players have been using without trouble.  Therefore I was unlikely to believe you or want to help you, when you called them "broken" on your very first post to the forums.  That being said, welcome to the forums.

On 11/26/2017 at 7:33 AM, PrimoDev said:

1st sat :

Apo = 2863.345

[...]

3rd sat :

Apo = 2863.344

The precision made me think you set the orbits with the cheat menu or using a mod, so I tried to reproduce the problem using Alt-F12 "set-orbit" and to my surprise I also see the problem.  Trying to 'set-orbit' two satellites each to the same orbit :
 Semi-Major Axis = 3222111
 Eccentricity = 0.5
 Inclination = 0°
 Mean Anomaly = 0 radians
 Longitude of Ascending Node = 0°
 Longitude of Periapsis  = 20°
I found that as soon as I switch away from one satellite, and observe it in map view, its orbit has moved.  The values in 'quicksave.sfs' do not match my set-orbit' entries, and make no sense to me. 

It looks like KSP measures orbital angles from the ascending node, which is not well defined if the inclination is 0°. I wonder if KSP has trouble with that case ? 

If I do the same experiment with inclination = 0.5°, I have no problems putting the satellites the requested orbits the values in 'quicksave.sfs' match my entries, and the satellites stay in place through Save/Load and timewarp.

Edited December 2, 2017 by OHara
Happens in a fresh install, but only single-part craft put exactly 0° inclination

[Starman4308]

6 hours ago, Geschosskopf said:

Geez, read my mission reports going back 4 years or so  

No, I don't think I will trawl through years worth of mission reports when, if your conjecture is true, you should be able to just point us at a case of this occurring.

If your evidence is that your network fell out of alignment? If you placed them there in normal gameplay, of course it'll fall out of alignment, because there's no way to, short of editing, ensure your satellites all have exactly the same semi-major axis, and thus exactly the same orbital period.

Show us a case of a satellite, that stayed on-rails throughout, that was not subject to any sort of orbital decay or persistent thrust mod, that did not cross any spheres of influence, that changed its orbit.

2 hours ago, OHara said:

I found that as soon as I switch away from one satellite, and observe it in map view, its orbit has moved.  The values in 'quicksave.sfs' do not match my set-orbit' entries, and make no sense to me. 

Two possibilities:

First, a lot of these values do become poorly defined or degenerate when inclination is exactly zero. Second, when you switched away from the vessel: were you in on-rails warp, or in normal physics flight? Regular, non-timewarp physics does exhibit orbital perturbations thanks to the limits of numerical precision.

[Spricigo]

3 hours ago, OHara said:

The precision made me think you set the orbits with the cheat menu or using a mod,

The kind of precision is not impossible with just small engines, thrust limiting and very carefully applied low throttle. Granted it requires quite a bit of knowledge and patience, but not that uncommon among KSP players (or even newish KSP players). 

 

[OHara]

I see only one a corner case that KSP gets wrong:
 Very simple craft like a single probe-core (with optional antennae and solar panels)
 Use Set-Orbit to put it in orbit with precisely 0° inclination
 Load/Save and the orbit has rotated some random amount between 0 and 360°

This is unfortunately something a new player might do, but rest assured any realistic orbit is perfectly stable in KSP.

The simplest example craft (like the Ion Probe) avoid this problem.  Even 0.000000001° inclination avoids the problem.

[Pand5461]

@OHara this probably happens when game tries to convert position + velocity back to orbital elements for save file. With 0° inclination, this causes large errors in determining LAN and AoP.

AFAIK, longitude of periapsis is used instead in such cases in proper astronomical calculations. Chances are, KSP code does not use this workaround, hence the potentially increased loss of accuracy on near-equatorial orbits.

[Mayer]

What if you did geostationary orbit with 4 satellites(added redundancy)? That way the network should work even when spacing is broken.

I find the extra groundstation option/cheat quite lame because it destroys the incentive to have a satellite network or any satellite around kerbin. Also they display as anomalies on KerbNet..

[Spricigo]

23 minutes ago, Mayer said:

I find the extra groundstation option/cheat quite lame because it destroys the incentive to have a satellite network or any satellite around kerbin. Also they display as anomalies on KerbNet..

Your preferences is your to pick. But is still only a game option, not "/cheat" in any sense.

And no, it's not the ground station that remove the  incentive to have a network around Kerbin. The option to turn off commnet enterily already took care of that.