"Shortcutted" physics mode for items outside of the immediate range.

[Ruedii]

It could save massive amounts of processor time to "shortcut" the physics of far out objects into a single center of gravity.

This would allow the objects to still have simulation of their orbital trajectory and rotation, but reduce processor load enough to be able to simulate them far out without shortcutting precision in a manner that would summon the Space Kracken and other physics bugs.

This same method could also be used in time-warp mode.

[Kermunist]

It already is isn't it?

Objects more than 2.5km (I think) away are treated as a single point mass following an orbit calculated using patched conics. This is colloquially referred to as being "on rails".

In normal timewarp, the same applies to the active craft (and anything else inside the 2.5km limit) - it is put on rails. Physics timewarp keeps doing physics calculations, and is limited to 4x by lag and accuracy issues.

As currently implemented, rotation is lost. It might be better if it was kept, and I think it's on the todo list. It's certainly been suggested a fair few times.

[vexx32]

This is already in the game, and it's basically how it works -- only rotation is not simulated. If it was, the game would be more​ CPU-intensive than it presently is, though probably not by much.

[NERVAfan]

I would like timewarp and outside-range to preserve rotation too... the current version leads to weird conservation-of-angular-momentum violations.

[Red Iron Crown]

I'm imagining the blur a mildly rotating ship would become at high timewarp.

[vexx32]

It would look odd, aye. Even if it just took a moment to calculate where its rotation should leave it as you drop out of warp, that would certainly be acceptable to most people.

[SpaceK531]

I think being able to turn the rails off for craft outside of the 2.5 km range while in timewarp x1 or physwarp would be amazing. It would allow things like kOS-programmable multi-stage lifters like what SpaceX's Falcon 9 system is going to do.

[vexx32]

*shrugs* for now, you can turn to mods. I know the Lazor System has that feature. However, be warned that it takes a lot of CPU power to do it, which increases with both the number of craft that are inside the inflated physics sphere and how far from you they are.

[KASASpace]

Well, maybe only do physics on the largest parts at 2.5 km?

[Dunbaratu]

There's absolutely no reason you can't have rotational inertia when "on rails", and I have no idea why KSP doesn't do it. It's far simpler to calculate math than anything used for the current linear XYZ movement that's tracked by plugging in Time = T into parameterized equations for an ellipse. All it is is a simple line function with a modulo operator thrown on the end of it: Rotational position around axis FOO is equal to:

(IR + RV*t) mod U

Where:

IR = initial rotational position at the moment it first went on rails.

RV = rotational velocity around this axis.

t = time (the only part that changes, that you plug in for the on-rails equation)

U = The size of a single unit circle, in whatever angle measuring system you're using (either 2*pi or 360, depending on if it's radians or degrees).

Do that for each axis of rotation of the craft. There's nothing to even track "live" unless the ship happens to be in view when time-warping. As long as it's not in view, then just don't bother tracking the rotation until the craft gets reloaded, at which point you plug back in the time=t parameter to see where it's gotten rotated to while you weren't looking at it.

[pizzaoverhead]

There's absolutely no reason you can't have rotational inertia when "on rails", and I have no idea why KSP doesn't do it.

KSP might not do it, but a mod does: Timewarp Rotation Fix

[tntristan12]

I had that mod in its last version but I don't think it's been updated since. I'd certainly like to make a mod like that. Might even make rotations a bit more realistic too.

[Eric S]

There's absolutely no reason you can't have rotational inertia when "on rails", and I have no idea why KSP doesn't do it.

Mostly because they haven't gotten around to doing it. The devs have discussed the possibility of doing this.

[coolitic]

They need to either find a fix or a workaround where objects can pass through stuff untouched when not simulated as it is too exploitable.

[Dunbaratu]

Mostly because they haven't gotten around to doing it. The devs have discussed the possibility of doing this.

That's good to hear. I admit I've gotten lazy at times and exploited timewarp to stop a rotating object that I really shouldn't have been able to stop, but that's a hole that really should be plugged.

[Kasuha]

There's absolutely no reason you can't have rotational inertia when "on rails"

I have one reason.

KSP comes with plenty of phantom forces, making your ship rotate in random directions when you need it to stay still. Having at least one tool available to get rid of that is good.

I'm all for having rotational inertia on rails after we get rid of phantom forces.

[Dunbaratu]

I have one reason.

KSP comes with plenty of phantom forces, making your ship rotate in random directions when you need it to stay still. Having at least one tool available to get rid of that is good.

I'm all for having rotational inertia on rails after we get rid of phantom forces.

Granted the phantom rotational accelerations are quite annoying, but I doubt they'd be "in play" for an object on rails. Rotation on rails would by its very nature have to contain no rotational acceleration (for the same reason that there's no linear accelerations when going on rails - the math equations are only modeling momentum. That means velocity and position, but not acceleration.) The math wouldn't even be capable of *storing* any changes to the rotational momentum. It's assuming a constant rotational velocity is happening while on rails. So as long as you kill the rotation with SAS prior to going on rails, there won't be any phantom rotations while on rails. The parts of the physics engine that are causing the phantom rotations aren't active and the time warp rotation would only be capable of remembering what the rotational velocity was at the moment you went on rails. It wouldn't be capable of altering it while on rails. (So if you are rotating slowly at 2 RPMS when first going into rails, you'll still be going 2 RPMs when you come out. You won't have accelerated via phantom rotational forces to something like 100 RPM or anything like that because those forces don't exist while on rails.)

Edited April 24, 2014 by Steven Mading

[BudgetHedgehog]

So as long as you kill the rotation with SAS prior to going on rails, there won't be any phantom rotations while on rails.

That's the point - the phantom forces spin the ship when it's not on rails and SAS doesn't help (or is even sometimes the cause). Right now, the only way to make your ship stop spinning is by time-warping. I agree with Kashua - if they get rid of that, they better have something that actually keeps the ship still when not on rails.

[Dunbaratu]

That's the point - the phantom forces spin the ship when it's not on rails and SAS doesn't help (or is even sometimes the cause). Right now, the only way to make your ship stop spinning is by time-warping. I agree with Kashua - if they get rid of that, they better have something that actually keeps the ship still when not on rails.

Or, rather than continuing to support one buggy behavior in order to use its side effect to counter another buggy behavior, why not just have a "kill rotation cheat button" as a separate thing? Using the side effect of time warp that stems from the fact that time warp models rotation incorrectly, as the means of having a kill rotation cheat seems the wrong way to go.

By the way, I've had lots of phantom rotation bugs, but none that were so bad in magnitude that they weren't stoppable by SAS.

Edited April 24, 2014 by Steven Mading

[Kasuha]

Or, rather than continuing to support one buggy behavior in order to use its side effect to counter another buggy behavior, why not just have a "kill rotation cheat button" as a separate thing?

Scenario 1:

- you implement momentum conservation

- you implement rotation cheat

- some players are happy for getting more realistic physics

- once upon the time you fix physics problems

- you remove rotation cheat

- some players are angry for getting their comfortable cheat key stolen

Scenario 2:

- once upon the time you fix physics problems

- you implement momentum conservation

- some players are happy for getting more realistic physics

- some players are angry for getting their cheat stolen

Now guess which of the two is less work and pays off better?

[Dunbaratu]

Scenario 1:

- you implement momentum conservation

- you implement rotation cheat

- some players are happy for getting more realistic physics

- once upon the time you fix physics problems

- you remove rotation cheat

- some players are angry for getting their comfortable cheat key stolen

Scenario 2:

- once upon the time you fix physics problems

- you implement momentum conservation

- some players are happy for getting more realistic physics

- some players are angry for getting their cheat stolen

Now guess which of the two is less work and pays off better?

I never said you remove the rotation cheat afterward. You inserted that and pretended I'd said it in order to make up this strawman of what I suggested.. Argue honestly instead of against a strawman you've invented and your argument goes away, because both the "remove rotation cheat" and the "some players are angry for getting their comfortable cheat key stolen" steps only exist in your strawman of what I proposed. Take them out and Scenario 1 stops looking bad compared to Scenario 2.

There's lots of cheats already that you can use if you don't want to play the game hardcore. Leaving the rotation killer as a cheat makes it clear that it's a cheat. Leaving it as a side effect of an incomplete on-rails system makes it look like it's not a cheat.

[xrayfishx]

Kasuha, fixing bugs does not go like "oh hey SQUAD, there's a bug here" - "oh thanks for noticing" - *bug fixed*. Fixing a bug usually creates 10 new ones that you then also have to fix, as a result it's sometimes better to work on other things and workarounds until you figure out how to fix that original bug. As Steven already said, the cheat doesn't have to be removed and in this case no one really loses according to your scenario (not that it went like that for real, but it's close enough). Either way, the last time I had phantom rotation was back in 0.20 or maybe .21, after that I have occasionally activated physics warp while rotating, therefore pressing alt+*insert rotation key here* at the same time, therefore unintentionally trimming controls. In fact, I'd wager most phantom rotation cases are fixable with alt-x.