[0.25] Orbit Manipulator Series (Updated March 12 2014)

[HoneyFox]

I remember the first time I sent an ion-powered probe to Jool - spending over an hour at 4x physics warp... can't wait to try this mod!. Time-warping ion drives should be part of stock, instead of the .23.5 tweak.

I'm also glad to see the orbital decay; I've been manually deleting debris with PE < 60KM for a long time now, and finding it tedious. I understand it would wreak havoc on many player's stations and satellites, but would you consider an option to extend the orbital decay into the exosphere?

Since you're already calculating orbital decays, consider a "station keeping" option which auto-drains RCS to counteract the drag… (and maybe an alarm when RCS is running out; another reason to refuel my stations periodically

On my planning list and that "station keeping" sounds interesting as well, but I might start these features a bit later because i want to enjoy the new ARM as well.

Edited April 4, 2014 by HoneyFox

[NERVAfan]

Speaking of ions, could you add an ion engine with way less thrust so we can use it with x100, x1000 or x10000 time warp and have it actually act like an ion engine? Thrust of .01 or less maybe?

[HoneyFox]

Speaking of ions, could you add an ion engine with way less thrust so we can use it with x100, x1000 or x10000 time warp and have it actually act like an ion engine? Thrust of .01 or less maybe?

should be quite easy by simply copying the stock ion thruster and modify its maxThrust from 2.0(0.23.5) to 0.002(2 Newton force)

[NERVAfan]

should be quite easy by simply copying the stock ion thruster and modify its maxThrust from 2.0(0.23.5) to 0.002(2 Newton force)

Yeah, I just thought it would make sense to have it 'packaged' with the mod as none of the stock engines are really low-thrust/long-burning enough to make full use of thrust-during-timewarp (especially with the 0.23.5 increase in ion engine thrust).

[HoneyFox]

Yeah, I just thought it would make sense to have it 'packaged' with the mod as none of the stock engines are really low-thrust/long-burning enough to make full use of thrust-during-timewarp (especially with the 0.23.5 increase in ion engine thrust).

Perhaps I can make such a package for realistic performance of these thrusters... but well, that will make the game epic hard since in RL an ion thruster might only be able to accelerate a small probe by less than 10m/s of dV per 24 hours, ouch!

[NERVAfan]

Perhaps I can make such a package for realistic performance of these thrusters... but well, that will make the game epic hard since in RL an ion thruster might only be able to accelerate a small probe by less than 10m/s of dV per 24 hours, ouch!

Yeah, but on a mission to Eeloo it may add up...

A good point, though, in that KSP's solar system is scaled down so there will be less time for an ion engine to work on a Kerbin-Jool trip than an Earth-Jupiter one. Still, .01 (10 N) or .002 (2 N) or whatever is way more than the thrust of real-world ion engines (Dawn's are 90 millinewtons http://dawn.jpl.nasa.gov/mission/ion_prop.asp) so that should balance out the shorter mission time.

Something like Dawn, according to my limited understanding, flies a totally different kind of trajectory, thrusting most of the time, than a chemical rocket which makes short burns at the most efficient points and coasts the vast majority of the time.

[HoneyFox]

Yeah, but on a mission to Eeloo it may add up...

A good point, though, in that KSP's solar system is scaled down so there will be less time for an ion engine to work on a Kerbin-Jool trip than an Earth-Jupiter one. Still, .01 (10 N) or .002 (2 N) or whatever is way more than the thrust of real-world ion engines (Dawn's are 90 millinewtons http://dawn.jpl.nasa.gov/mission/ion_prop.asp) so that should balance out the shorter mission time.

Something like Dawn, according to my limited understanding, flies a totally different kind of trajectory, thrusting most of the time, than a chemical rocket which makes short burns at the most efficient points and coasts the vast majority of the time.

Yes, the Dawn burns its ion thruster about 70% of its flight time, it can only provide about 6m/s per day but it's a nearly-one-year journey...

Perhaps I will tune it down to some level that is, still more powerful than in RL but not too OP for high rate time-warp.

[quasarrgames]

this is what ive always dreamed of...

will definately be trying this out!

[NERVAfan]

I tried to install this in 23.5 and it doesn't seem to work... I still get "cannot warp faster than 1x when the ship is throttled up" when I try to use ion engines, and I don't see any other sign the mod is installed. Exactly where in the KSP folder is the "NBody" folder supposed to go to make it work correctly?

[HoneyFox]

I tried to install this in 23.5 and it doesn't seem to work... I still get "cannot warp faster than 1x when the ship is throttled up" when I try to use ion engines, and I don't see any other sign the mod is installed. Exactly where in the KSP folder is the "NBody" folder supposed to go to make it work correctly?

Huh? You just unzip the package to the GameData folder so that the dll should be in: .../KSP/GameData/NBody/Plugins/NBody.dll

You can check the ion engine's context menu, if there's an additional slider named "Throttle", you're good to go.

To use it, kill the stock throttle by pressing "Ctrl" or "X", then use the "Throttle" slider to control the in-warp thrust.

One thing that I want to remind you is, you'd better install the Toolbar plugin. This plugin will then provide three buttons to the toolbar so that it's more convenient to switch on/off several functions.

[NERVAfan]

Huh? You just unzip the package to the GameData folder so that the dll should be in: .../KSP/GameData/NBody/Plugins/NBody.dll

OK, I did that... it is there...

You can check the ion engine's context menu, if there's an additional slider named "Throttle", you're good to go.

Is that the right click menu when you click on the actual part? If so, no, I don't see it, just

Fuel Flow

Thrust

Specific Impulse

Status: Nominal

Thrust Limiter

Activate Engine

...

One thing that I want to remind you is, you'd better install the Toolbar plugin. This plugin will then provide three buttons to the toolbar so that it's more convenient to switch on/off several functions.

.... but I don't have the toolbar plugin. Where do I find that?

[nothke]

The only thing that I found truly interesting in the OP is orbital decay =) I'd really love to see, as a difficulty option, orbital decay above 70km, so that you need to boost your stations from time to time, and if you neglect them, they should eventually reenter. =)

[HoneyFox]

OK, I did that... it is there...

Is that the right click menu when you click on the actual part? If so, no, I don't see it, just

Fuel Flow

Thrust

Specific Impulse

Status: Nominal

Thrust Limiter

Activate Engine

...

.... but I don't have the toolbar plugin. Where do I find that?

Uh-oh... That means the module is not added onto the ion engine part...

I thought I have implemented that toolbar support as optional, so it should still work even if you don't have toolbar plugin installed.

But anyway, you can find it here.

And one more question, do you have ModuleManager plugin installed? I forgot to mention that this plugin requires ModuleManager in OP.

EDIT: OP edited.

Edited April 25, 2014 by HoneyFox

[HoneyFox]

The only thing that I found truly interesting in the OP is orbital decay =) I'd really love to see, as a difficulty option, orbital decay above 70km, so that you need to boost your stations from time to time, and if you neglect them, they should eventually reenter. =)

I would like to know what kind of model should i use for the exosphere to calculate drag to simulate the orbit decay.

Has KSP provided any kind of function that can work out the air density even if the given altitude is higher than the atmosphere height?

[Streetwind]

If there's one person who knows everything about KSP's atmosphere model, it would be ferram4. Try asking him?

Which opens up a new question: is your atmospheric decay functionality compatible with FAR? I reckon that the exact drag and atmosphere scaling model you use is largely irrelevant in the grand scheme of things as long as slow and gradual decay happens, but it should be tested whether or not FAR changes something your code relies on.

Another question I'd like to ask is in regards to the N-body implementation (I understand it's just a proof-of-concept, no worries). You say that it only affects the active vessel. Does that imply that if I perform a transfer, I actually need to stick with the vessel or risk not getting an encounter at all? Since, if I am elsewhere and the on-rails vessel is using KSP's usual patched conics mechanic, it might get a completely different solution than the N-body solver computed while I was making the burn?

[HoneyFox]

If there's one person who knows everything about KSP's atmosphere model, it would be ferram4. Try asking him?

Which opens up a new question: is your atmospheric decay functionality compatible with FAR? I reckon that the exact drag and atmosphere scaling model you use is largely irrelevant in the grand scheme of things as long as slow and gradual decay happens, but it should be tested whether or not FAR changes something your code relies on.

Another question I'd like to ask is in regards to the N-body implementation (I understand it's just a proof-of-concept, no worries). You say that it only affects the active vessel. Does that imply that if I perform a transfer, I actually need to stick with the vessel or risk not getting an encounter at all? Since, if I am elsewhere and the on-rails vessel is using KSP's usual patched conics mechanic, it might get a completely different solution than the N-body solver computed while I was making the burn?

Unfortunately I cannot easily get the FAR's drag calculation result for an on-rail and not-loaded vessel. So currently the drag force is using same way the stock KSP uses: it depends on the mass of the vessel so the acceleration given by the drag force is not related to the vessel's mass (acceleration = force / mass).

After you performed a transfer and can get an encounter to a distant planet, if you stick with this vessel, the encounter might disappear after a period of time (depending on how close your vessel is to any celestial body). If you go elsewhere and leave it on-rail, the orbit won't change and it will encounter with the planet eventually.

[Superfluous J]

Just stumbled on this now, very interesting! Like so many, I've no real interest in the n-body stuff but orbital decay is something I feel should be stock, and ion-in-warp too.

Installed, and looking forward to trying it out!

[Streetwind]

Unfortunately I cannot easily get the FAR's drag calculation result for an on-rail and not-loaded vessel. So currently the drag force is using same way the stock KSP uses: it depends on the mass of the vessel so the acceleration given by the drag force is not related to the vessel's mass (acceleration = force / mass).

After you performed a transfer and can get an encounter to a distant planet, if you stick with this vessel, the encounter might disappear after a period of time (depending on how close your vessel is to any celestial body). If you go elsewhere and leave it on-rail, the orbit won't change and it will encounter with the planet eventually.

Ah, I see. So the N-body thing simulates the physics but the orbit paths drawn still follow the patched conics model. Thanks for clearing that up! (I want to at least try out how it feels once )

[HoneyFox]

Ah, I see. So the N-body thing simulates the physics but the orbit paths drawn still follow the patched conics model. Thanks for clearing that up! (I want to at least try out how it feels once )

TBH the N-body is very inaccurate especially when in higher time-warp, you might look forward to this being released in the future.

[Streetwind]

Yeah, I've seen it, but tbh I would be a fan of a simpler implementation. Last I checked, Principia attempts to simulate the entire star system; all I can think of when I see that is "Jool and its moons are so going to fall apart in short order". And the performance considerations for that many objects all influencing one another... yeah. Better to keep all the celestials fully on rails, tbh. You could then still apply N-body physics to the player spacecraft (and thus also asteroids) themselves - and quite possibly with higher precision, because you save so much performance by not calculating the celestials. It wouldn't be fully realistic, but it would be for most intents and purposes indistinguishable from it. Realism for its own sake is never a good game design paradigm, but believability can be.

Of course, I am also an absolute amateur who doesn't even begin to understand how N-body physics are implemented, so my opinion is probably not all that relevant

[8749236]

Is this still work in progress or is it halted already?

[Endersmens]

Hmm. I might install this for one reason: The first asteroid i tracked in ARM, somehow was orbiting Kerbin, with a periapsis of 31km, and an apoapsis somewhere near the edge. I watched the asteroid fly through the atmosphere and back out into space (from my station) and wished it had been captured (since it would've nearly completely captured the asteroid, saving me a whole lotta work)

[HoneyFox]

Is this still work in progress or is it halted already?

Well it might be actually in Done state. I will change the title of the OP.

[HoneyFox]

Hmm. I might install this for one reason: The first asteroid i tracked in ARM, somehow was orbiting Kerbin, with a periapsis of 31km, and an apoapsis somewhere near the edge. I watched the asteroid fly through the atmosphere and back out into space (from my station) and wished it had been captured (since it would've nearly completely captured the asteroid, saving me a whole lotta work)

That would happen if you had installed this plugin, but for 31km Pe, I wonder if it would be de-orbited directly instead.

[8749236]

Well it might be actually in Done state. I will change the title of the OP.

What about the Ion Engine message spam bug?

I havent seen you mention that you fixed that..

That cause at least 50% drop of frame rate.. for me.. (with only 2 parts, a command module, an ion engine)

That would happen if you had installed this plugin, but for 31km Pe, I wonder if it would be de-orbited directly instead.

Well, wifh FAR, lower than 30 means your gonna deorbit..

Higher than 30 means your gonna surf into space...

if Stock.. since drag is related to mass.. GG..