KSP's physics and the laws of physics it defies.

[FirstSecondThird]

You remember the kraken from 0.17 and before, that made KSP unrealistic.

I mean, in real physics, when you move around, you move around spacetime, but in 0.17 and before they made spacetime move around you, causing the kraken when at high speeds and high physwarp.

I know it's just a game but simulation games are designed TO SIMULATE, not do the OPPOSITE.

[Camacha]

So what is your question, argument or whatever exactly?

Edited July 14, 2014 by Camacha

[cpast]

I mean, in real physics, when you move around, you move around spacetime, but in 0.17 and before they made spacetime move around you, causing the kraken when at high speeds and high physwarp.

You have that precisely backwards. The kraken resulted from floating-point issues related to calculating physics on a craft far from the center of a coordinate system. They *reduced* kraken issues by making your craft the center of the coordinate system. Furthermore, "you move around spacetime" is meaningless as a concept -- you don't do anything over time in spacetime, because adding a time dimension already accounts for changes over time. Instead, your entire path - past, present, and future - is a single curve in spacetime that does not change. As far as Newtonian gravity goes, it makes not even a tiny bit of difference whether you're moving or the universe is moving - aside from you moving at high speed causing some sort of floating-point precision issues.

[Kerbart]

There are many responses possible to this post and I'm sure there will be many responses, as the question suggests a complete misunderstanding of many, many, many concepts. But I'll keep it short.

1) Moving space around the ship was introducted to prevent the Kraken from appearing, it wasn't done to introduce it. Why do you think they picked this method in the first place? Just for fun?

2) You're talking about what happens under the hood. Simulations get judges by what happens above the table. Nobody cares if space moves around the ship or the other way around (which is modern physics by the way: google "frame of reference" which you might or might not want to combine with "Einstein" and "relativity") or if the motion is simulated by studying the trajectories of balls on a pool table by a set of hamsters playing eight-ball. It's the result that we judge a simulation on.

[Ralathon]

You remember the kraken from 0.17 and before, that made KSP unrealistic.

I mean, in real physics, when you move around, you move around spacetime, but in 0.17 and before they made spacetime move around you, causing the kraken when at high speeds and high physwarp.

I know it's just a game but simulation games are designed TO SIMULATE, not do the OPPOSITE.

"That is not only not right, it is not even wrong!" - Wolfgang Pauli

You are mistaken on a fundamental level and are working yourself up about nothing. Not much else that can be said here.

[J.Random]

OP, watch this:

PS Actually, not only OP. There are two floating point origins, one was before Krakenbane - for position, another one was Krakenbane - for speed.

Edited July 14, 2014 by J.Random

[SpaceXray]

KSP doesn't support multi-body physics, in other words you cannot be affected by 2 bodies at the same time, thus making things like Lagrange points and artificial tidal locking impossible

[magnemoe]

KSP doesn't support multi-body physics, in other words you cannot be affected by 2 bodies at the same time, thus making things like Lagrange points and artificial tidal locking impossible

This have two other effects in that the Mun don't affect an Minmus mission if you are outside of SOI, with multi body physic you would have two stable orbit around Jool one would be low orbit the other would be far outside Pol, in short the game would be far harder and you would get lots of unexplained bugs as Mun sent you ship in high Minmus orbit into solar orbit.

More importantly the aerodynamic is stupid, drag depend on weight not on cross section on most part. In reality cross section and aerodynamic is the only thing affecting drag,

[KerikBalm]

1) Aerodynamics model: both the mass dependand drag, and that drag scales with the square of velocity, whereas lift is linear

2) ISP: thrust should vary, not fuel consumption. Relatively minor: ISP curves should be adjusted so that ISP drops even further in atmospheres over 1 atm (jool, eve)

3) Gravity/mass effects: Patched conics don't support lagrange points and such, effects of gravity are applied to the whole craft's Cg, rather than at each part, which has some minor effects as far as differential forces on long craft.

(minor enough IMO, given that the simulation has limited resources).

[Camacha]

3) Gravity/mass effects: Patched conics don't support lagrange points and such, effects of gravity are applied to the whole craft's Cg, rather than at each part, which has some minor effects as far as differential forces on long craft.

(minor enough IMO, given that the simulation has limited resources).

That is indeed not an oversight, but a deliberate choice to make the game playable on lighter systems.

[Kryten]

Yes, that abstraction was only added in (IIRC) 0.11; previously, craft actually did demonstrate stuff like gravity-gradient stabilisation.

[SciMan]

That is indeed not an oversight, but a deliberate choice to make the game playable on lighter systems.

You know, as much as it's not much liked on this forum, Orbiter is fully capable of running on lower spec computers, with better precision, and at a better frame rate. And it fully simulates N-body, gravity gradient torque, and even non-spheroidal gravity sources (the equatorial bulge from planetary rotation affects gravity strength)

So that kinda negates the whole "N-body is hard to make run fast on a low spec computer" argument.

I think it was done to keep the gameplay easy for the player to understand. There are lots of things about n-body, gravity gradient torque, and non spheroidal gravity that make plotting a long-term safe orbit or a good transfer trajectory anything but simple.

As a matter of fact, you pretty much can't "eyeball it" in Orbiter, even if it's just a trip out to the moon. It's very much hard-core compared to KSP, but that's because it optimizes for realism while KSP optimizes for fun. I'm fine with that, and I enjoyed playing KSP at least as much as I used to enjoy playing Orbiter.

[SargeRho]

Orbiter also doesn't run on Unity.

[Guest]

You can make N-body physics in Unity. With a plugin! Principia is how the mod is called, it's currently in slow development, and it already demonstrated the ability to create realistic trajectories for all bodies at high warp. Nonspherical gravity sources are planned, and the way it's done, tidal effects will probably appear, too. The only reason for this "N-body is hard!" BS is Squad sucking at advanced mathematics and physics, symplectic integration in particular. The problem of simulating N-body systems was solved long ago in a great number of ways. That's why I keep saying that Squad should hire someone with a PhD in astrophysics. Physicists are huge nerds (I should know, I'm studying this myself ), I'm sure they'd quickly find someone. Heck, I know a few guys in my institute who would at least consider such job.

Planning is just a matter of tools available. Orbiter doesn't have the maneuver node system, which is simple enough to make planning easy even in an N-body system. It just needs to be a bit more flexible.

[cpast]

N-body is hard. It is not analytically solvable (it relies on step-by-step numerical simulation), and doesn't have stable orbits (as a rule). In contrast, patched-conics has almost all orbits stable, is fairly intuitive, is not nearly as subject to things like floating-point errors (because it's analytically solvable, so errors don't cascade down), and in general has a lot of advantages for a game. And it has nothing to do with advanced math or physics; what you need for N-body is someone who's skilled in applied math, because the main challenge is optimizing lots and lots of numerical calculation.

[rkman]

The only reason for this "N-body is hard!" BS is Squad sucking at advanced mathematics and physics, symplectic integration in particular.

You're not saying advanced mathematics is not hard, are you? It takes a lot of time and effort to learn, pretty much the definition of "hard".

I'd bet that the dev of Principia would find patched-conics orbital mechanics a lot easier to do than n-body.

[Red Iron Crown]

Conservation of angular momentum is violated in KSP, both in on rails timewarp stopping rotation in a reactionless fashion and in reaction wheels that have no saturation point.

There's some biological principles violated by Kerbals themselves, they consume nothing and are energetic over long periods of time.

EVA fuel is both infinite and massless, obviously impossible.

Solar panel output doesn't drop off with distance from the sun in a realistic manner; it drops off far more slowly.

RTG output doesn't degrade over time, even decades.

Infiniglide and ladder force are obviously not physically possible as they are in KSP.

Densities of the celestial bodies defy our real life understanding of matter and planet formation. Yet almost everything floats.

There is no weather anywhere, ever.

The celestial bodies do not cast shadows.

Aerodynamics. Enough said.

Patched conics are an approximation less accurate than the n-body model (though it makes for better gameplay, IMO).

Parts of ships cannot collide with the ship itself.

[Ralathon]

You can make N-body physics in Unity. With a plugin! Principia is how the mod is called, it's currently in slow development, and it already demonstrated the ability to create realistic trajectories for all bodies at high warp. Nonspherical gravity sources are planned, and the way it's done, tidal effects will probably appear, too. The only reason for this "N-body is hard!" BS is Squad sucking at advanced mathematics and physics, symplectic integration in particular. The problem of simulating N-body systems was solved long ago in a great number of ways. That's why I keep saying that Squad should hire someone with a PhD in astrophysics. Physicists are huge nerds (I should know, I'm studying this myself ), I'm sure they'd quickly find someone. Heck, I know a few guys in my institute who would at least consider such job.

Planning is just a matter of tools available. Orbiter doesn't have the maneuver node system, which is simple enough to make planning easy even in an N-body system. It just needs to be a bit more flexible.

That's not why squad isn't doing N body. Squad is perfectly aware and capable of implementing it (at the very least for the active craft). The reason it ain't happening is because it adds very little for players and messes up all your orbits after every trip to Duna.

Station keeping is not a fun gameplay and lagrange points don't make up for that.

[pxi]

In the few forays I've made into programming, I've noticed a recurring pattern: You want to solve a simple issue, so you break it down into steps - now you have ($n + 1) problems.

It's rarely as simple as it seems. There's often a good reason why people didn't do the obviously correct thing.

[Roastduck]

Squad also has said before that they don't want KSP to be a full-on, hardcore simulation game, hence why the Kerbol system is so small, life support isn't necessary (yet), why KSC is exactly on the equator, making it easier to get into certain orbits. They want it to be a game, and they want it to be fun and appeal to the greatest common denominator. If you want a hardcore sim, add mods until it's real enough for you, or try a different game.