Fix ion engines by fixing the Rails system

[StarManta]

(Inspired by a discussion in the 'easy-to-implement' features thread regarding the annoyance of using ion engines.)

Ion engines are unused because KSP requires you to have a craft focused and in only physics time-warp while it's thrusting. In most scenarios, this is sensible, because thrust can destabilize unbalanced ships or tear apart flimsy ones. However, it makes ion thrusters - even the massively-overpowered ones that we have in KSP - so annoying to use that they're crippled. I would propose enhancements to the rails physics system to fix ion thrusters (and then ion thrusters can be nerfed down to more realistic levels). 

Specifically, with this system, thrust can be used while on rails (e.g. in time-warp) as long as....

A. The thrust force is below a certain threshold (which nukes and ion thrusters would be)

B. The thrust vector is stable over X seconds and aligned with the COM within some tiny variation (probably 0.1 degrees or so)

C. No changes in throttle are permitted during timewarp (this way, the player must start the engines and THEN timewarp, so that they may not take advantage of timewarp to thrust super-fragile ships)

D. Power and the relevant fuel tanks are both above, say, 1% of capacity (this way it drops out of timewarp before the engines cut off outside of player control, in compliance with C)

E. SAS + Reaction Wheels are engaged

Thoughts?

Edited December 28, 2015 by StarManta

[nikokespprfan]

13 minutes ago, StarManta said:

A. The thrust force is below a certain threshold (which nukes and ion thrusters would be)

maybe it should be TWR that has to stay withing a certain treshold or the acceleration. If I have a big ION driven ship, with the TWR of an typical small ION craft, just alot heavier and with a ton of ION engines on it, I would not be able to timewarp, although I should be, as its a very small acceleration. 

Apart from that, I feel this is an good addition that will certainly give more attention to the ION drives.

[StarManta]

Thanks, I agree with your alteration. That's basically what I had in mind, but it didn't occur to me that the mass of the ship would have to factor into that.

Edited December 28, 2015 by StarManta

[MKI]

Is this actually feasible? 

I can imagine myself and many other players taking advantage of this and having multiple ships being "active" simultaneously. Would this create a heavy workload in the background calculating multiple ships moving at different rates in different areas?

Now if we cut down on active changes and make things more estimated relative to the time passing would we get any sort of rounding errors or issues that could come with it? I already know maneuver nodes can be off by millions of KM due to rounding. If we were to exacerbate this issue with movement over time would I end up with a ship FLYING at the time of the rounding? I can only see bigger issues coming with this. 

 

I always agreed that the current way ION engines are setup make them very niche low powered engines. But to make them realistic means tackling problems that are not only deeply rooted into the game, but very difficult to solve. Floating point conversions has always been a problem in Computers. 

[Kerbart]

I must be misguided. I thought the whole point of “on rails” is that there are no physics calculations, making position and velocity mathematically pre-determined. The only reason timesteps are needed in “on rails” is to resolve SOI transitions and surface boundary intersections. Not sure if this would fit in with that.

[nikokespprfan]

7 hours ago, MKI said:

Is this actually feasible? 

I can imagine myself and many other players taking advantage of this and having multiple ships being "active" simultaneously. Would this create a heavy workload in the background calculating multiple ships moving at different rates in different areas?

Now if we cut down on active changes and make things more estimated relative to the time passing would we get any sort of rounding errors or issues that could come with it? I already know maneuver nodes can be off by millions of KM due to rounding. If we were to exacerbate this issue with movement over time would I end up with a ship FLYING at the time of the rounding? I can only see bigger issues coming with this. 

 

I always agreed that the current way ION engines are setup make them very niche low powered engines. But to make them realistic means tackling problems that are not only deeply rooted into the game, but very difficult to solve. Floating point conversions has always been a problem in Computers. 

But I do remember a mod that made some kind of thrust during warp possible. I don't remember the name though. IIRC it was a realism overhaul mod.

 

EDIT, I found it, or at least another mod that does it. Its persistent thrust from mrsolarsail: http://forum.kerbalspaceprogram.com/index.php?/topic/120404-wip105-persistentthrust-v104-alpha/

so that means that it is probably feasable.

Edited December 29, 2015 by nikokespprfan

[StarManta]

14 hours ago, MKI said:

I can imagine myself and many other players taking advantage of this and having multiple ships being "active" simultaneously. Would this create a heavy workload in the background calculating multiple ships moving at different rates in different areas?

 

1) The phrase "taking advantage of this" implies that this would be cheating or unfair, but I don't see how. If anything, the fact that we're currently unable to thrust simultaneously with two indepedently-controlled ships is unfair in the other direction - an artificial limit imposed by the game for performance/gameplay simplification reasons.

2) I didn't say that you'd necessarily be able to switch away from a ship while accelerating, only that you could timewarp during it. Given the conditions I proposed under which the ship would revert out of timewarp, it would still be sensible to make the player stay focused on the ship for that time.

14 hours ago, Kerbart said:

I must be misguided. I thought the whole point of “on rails” is that there are no physics calculations, making position and velocity mathematically pre-determined. The only reason timesteps are needed in “on rails” is to resolve SOI transitions and surface boundary intersections. Not sure if this would fit in with that.

I believe that that is not so much the "whole point", more of a logical result of the way it is implemented. However, there are at least two exceptions to its predetermined-ness: SOI transitions as noted, and collisions with terrain. This would simply be another exception.

[Mister Dilsby]

Really interesting idea. Really, all it asks for is to ignore all "off-rails" physics except thrust, when thrust is small enough that the other physics don't matter. The idea of not allowing a change in thrust except at time 1x would ensure that it's OK to ignore. Also the timewarp should end when crossing an SOI boundary or getting into physics range of any other ship. 

Some problems to consider though: the ship will consume fuel and therefore lost mass as it travels--also if the ions rely on solar power then you could be in a situation where the ship loses power mid-flight. So, acceleration would not really be constant, and the game engine might have to check for power (and fuel!) which I'm not sure is in the on-rails list. Still, interesting!

[pandaman]

Interesting idea. From a 'realistic' representation of ion engines point of view I'm in favour.

As much as I liked using an ion powered lander on Minmus, because I could, I know it was only as a by product of ion engines being waaaaaaay more powerful than they should be due to the understandably important gameplay need to offset the fact that they can't apply thrust in time warp.

So, if it's properly doable then it gets my vote.

[MaxL_1023]

There are a couple shortcuts that could be used to make something like this work:

1. Assume sun-tracking panels have a sun exposure of 90% or 100% (or some other number, removes orientation checks in deep space)

2. Assume static panels have a sun exposure of 50% (same as above, removes a wrap exploit).

3. Assume power is routed to the ion drive last, after all other rail-monitored sinks

4. Ion thrust is applied through the CoM regardless of actual engine location (no real exploits, since you can get the same effect by orienting the craft in 1x)

5. Assume the craft velocity vector and orientation is constant within a timestep.

This way, the ion engine will serve to thrust the craft along the instantaneous rail direction. If you split this into timesteps you can get the following operation:

1. Using initial conditions (power generation plus location/velocity) you calculate the instant available power to the ion drive. Throttle it automatically to obtain the thrust vector. Calculate fuel consumption. If the craft has insufficient fuel, throttle down the engine further until consumption = remaining, with the excess charge being discarded.

2. Calculate the ion-resultant displacement change as:  0.5 * (thrust vector)/mass * timestep length ^2. Also calculate the final velocity vector.

3. Superimpose this change on the current rail by moving the point at t + timestep accordingly.

4. Starting from t + timestep, calculate a new rail using the updated position and velocity.

5. Repeat

 

The timesteps could be about 1 second long, with the rails in this mode replaced by small linear segments. A warp of 10x or 100x should be doable using this model. The original rail could be linearized using the trapezoidal rule with the original expected t + timestep location, with the thrust vector used to basically slightly lengthen the segment. The rail calculation update would only require a few timesteps worth of rail (at most) to be calculated, with the normal full rail being reestablished when the mode is exited, or every set number of timesteps.

This should allow a craft to thrust under ion power, with the low thrust/changes relative to the timestep length minimizing linearization errors. If enough computing power is available, a simplified physics model could be used instead (only one force due to the engine and one vector for gravity, all others (intracraft) deleted) to get a more accurate model.

[StarManta]

4 hours ago, Kuzzter said:

Some problems to consider though: the ship will consume fuel and therefore lost mass as it travels--also if the ions rely on solar power then you could be in a situation where the ship loses power mid-flight. So, acceleration would not really be constant, and the game engine might have to check for power (and fuel!) which I'm not sure is in the on-rails list. Still, interesting!

Was addressed by point D in my original post - if either power reserves or fuel reserves drop below 1%, it drops out of timewarp.

[Mister Dilsby]

2 minutes ago, StarManta said:

Was addressed by point D in my original post - if either power reserves or fuel reserves drop below 1%, it drops out of timewarp.

Which means the engine has to account for current solar loading, fuel usage, and fuel/energy consumption rate continually while thrusting on rails to see if it does drop below 1%.  

For example--while timewarping 'on rails', your ship passes into the Mun's shadow.  I'm not sure it takes that loss of solar load into account for a ship on rails in the present game, but it'd have to in your system. I know for sure it doesn't take into account the rate of depleting fuel during time warp (or the change in acceleration due to lower mass and constant thrust) because right now you can't deplete fuel during timewarp at all  These are not insurmountable problems, but need to be considered.

[StarManta]

11 minutes ago, Kuzzter said:

I'm not sure it takes that loss of solar load into account for a ship on rails in the present game,

It sure does, I've lost several probe craft because of it

[Boris-Barboris]

5 hours ago, StarManta said:

I believe that that is not so much the "whole point", more of a logical result of the way it is implemented. However, there are at least two exceptions to its predetermined-ness: SOI transitions as noted, and collisions with terrain. This would simply be another exception.

Yet it is the whole point. SOI transitions are also predetermined, collisions with terrain are mathematically very cheap, but not predetermined (you can warp through planet on high enough speed).
While your dream is clearly implementable (with some obvious constraints, for example new upper bound on timewarp multiplier), it will put additional strain on KSP, wich is already struggling on performance front: just skim through complaint topics. It would also require SQUAD to rework patched conics framework to allow non-conic patches between conic ones, and nobody likes to touch legacy stuff, that is working. Adding another CPU-eating script will not really help imho, but reviewing the core concept of introducing mechanics, that encourage hour-long burns would. While ion low-thrust idea is realistic, the only thing blind realism adds to games is suffering. I would prefer ion engines being balanced by some other means (EC consumption for example), rather than a thrust profile the game lacks instruments to realisticly play around with.

My point is, player should not be penaltized by time in the first place, it's bad design.

Edited December 29, 2015 by Boris-Barboris

[KerikBalm]

I've suggested things like this before.

Basically a "physics-lite" timewarp that does not calculate most of the physics on the craft (torque, all the various part connections, part heat, etc). Treat the craft as a point mass, sum the thrust, F=MA, recalculate mass and velocity every 10 seconds or so... a realistic ion engine TWR is so low that this should be accurate enough for the game purposes.

We would need a special maneuver tool for a very very long very very low TWR maneuver, which would be harder to implement I suspect

[StarManta]

19 minutes ago, Boris-Barboris said:

It would also require SQUAD to rework patched conics framework to allow non-conic patches between conic ones, and nobody likes to touch legacy stuff, that is working.

Of these, this is the only valid point - patched conics works now, and changes might break it. That's fair.

You keep harping on additional CPU strain, but if you think about it that clearly won't be an issue - in fact, performance would be better. We're only talking about the one active ship being handled this way (the conditions suggested in the thread all prevent switching away from the craft during thrusting for a number of reasons). Thrusting while in this pseudo-rails mode would clearly be lower in CPU than thrusting with all the craft's physics turned on, which is currently our only option. This improves performance during certain situations, and has zero impact on the rest of situations.

[Eric S]

6 hours ago, StarManta said:

I believe that that is not so much the "whole point", more of a logical result of the way it is implemented. However, there are at least two exceptions to its predetermined-ness: SOI transitions as noted, and collisions with terrain. This would simply be another exception.

 

While I agree with most of what you're saying including thinking that this would be nice to have, the point of on-rails physics is to have mathematically derived orbits so that we can throw the current time into an equation that spits out the craft's position at that time, barring SoI transitions and lithobraking.  Unpowered trajectories fit into this quite nicely.  Powered trajectories would complicate this.  Feel free to derive the required equations and donate them to Squad.

That's for the general on-rails usage.  We could get around this by making active-craft on-rails handled differently than inactive-craft on-rails, though at that point, it might be better to alter physics-warp to allow for higher levels of physics-warp under specific circumstances (low thrust for one), though that would have its own set of issues.

 

[Boris-Barboris]

I was comparing on-rails performace with your suggestion, not loaded one, you're right on that. I was confused by your desire to "and then ion thrusters can be nerfed down to more realistic levels", because that would make a typical burn to span over weeks. Then you would ask for non-instant maneuver planner, etc...

Well, one can only hope that SQUAD will give it a look, but that won't happen anytime soon, i'm afraid. Maybe frustrated modder will come and cleverly poke around vessel orbit, because basic functionality of "point and burn" is not very hard to implement.

Edited December 29, 2015 by Boris-Barboris