[0.23.5] Realism Overhaul: ROv5.2 + Modlist for RSS 6/30/14

[eggrobin]

NathanKell: I might as well say it more explicitly: n-body physics (and once that works, I'd like to add other stuff, e.g., orbit decay outside the 'official' atmosphere, conservation of angular momentum through timewarp to allow for spin-stabilisation, etc.). Let me hijack your thread with pictures of trajectories (which don't really show fancy n-body physics, but do show plotting of n-body trajectories which happen to be very close to the 2-body ones in various reference frames). As you can see, the other orbit is ever so slightly broken. Also, this only affects on-rails craft at the moment. There is quite a bit of work ahead.

Javascript is disabled. View full album

Edited January 28, 2014 by eggrobin

[Agathorn]

Wait, I thought it wasn't possible to do n-body calculations in KSP. Are you essentially replacing the entire physics system?

This is awesome btw!

[NathanKell]

Oooh! Please post a thread in dev and let us drool all over it.

asmi's on-rails library should be perfect for what you're doing btw; it was how he and I planned to add stationkeeping.

[eggrobin]

Are you essentially replacing the entire physics system?

I'm making an integrator that computes the positions/velocities of the ships and planets, so it doesn't do collision physics and the like.

Oooh! Please post a thread in dev and let us drool all over it.

I'll do that.

asmi's on-rails library should be perfect for what you're doing btw; it was how he and I planned to add stationkeeping.

What is it and where can I find it?

Edited January 28, 2014 by eggrobin

[NathanKell]

It's in ECLSS, it's a framwork for multithreaded updating of all on-rails vessels per tick. It was designed in part with this application in mind

https://bitbucket.org/asmi/ksp/src/ffd4ba49bab1133ca7229a1864e3d679d5d9fb02/KerbalPlugins/RealTimeModules/?at=default

PM asmi for more details maybe?

EDIT: but if you're doing a full integrator and handling planets' orbits too, maybe you need something different?

[eggrobin]

I already have something that moves the planets around (I just set the orbits of the planets and vessels according to their q and v as predicted by the integrator at every tick, brute-force but it works). Doing the integration in a separate thread is possible, and I intend to do it at high timewarp, but it won't improve performance much (I can very nearly sustain 100_000x timewarp and I've been talking to Scott Manley about making the integrator smarter than 'pick a tiny timestep, integrate slowly at that timestep'. Experiments seem to show that for LKO, my 5th order SPRK is exact to an unit roundoff for timesteps of 5 s though, so I might use that at reasonable timewarps and maybe up to and including 100_000x. I will need Scott's smarter techniques for predictions of vessels under thrust, which have to be done within a tick over at least a year). At some point I'll rewrite the classes that don't interact directly with KSP in unmanaged C++ (compiled for the processor rather than for the CLR) so it's faster (and so I can use long double extended precision 80-bit floating points, whose 64-bit mantissa give me a discretisation of 1 mm at 1 light-year instead of 1.4 mm on Sedna with doubles, at no cost in performance). As I said, lots of work ahead.

EDIT: This isn't the right thread, but while I'm talking about floating-point precision, why don't you use doubles in MFS/RF? That would nearly eliminate the problems from error accumulation during resizing. Just convert to float when you talk to somebody that wants a (single) float and to double when you get a float.

Edited January 28, 2014 by eggrobin

[Guest]

Don't you think that moving planets around is a bit much? You could probably simplify your equations and increase performance by not doing true n-body, but assuming planets move along fixed trajectories. Even if the "fixed trajectory" is rather complex, pre-calculating those would help a lot.

[eggrobin]

Don't you think that moving planets around is a bit much? You could probably simplify your equations and increase performance by not doing true n-body, but assuming planets move along fixed trajectories. Even if the "fixed trajectory" is rather complex, pre-calculating those would help a lot.

Actually, it would tend to make things slower. Computing a force pair is one square root and one division, each on the order of 10 clock cycles (the multiplications and additions are free for all practical purposes) If B is the number of planets, V the number of vessels---considered massless---, that's roughly 20 B(B + V) = 20 B^2 + 20 B V cycles for the step (actually, a single one of the six stages of the integrator). Computing the position of the planet at a given time (which I'd need, as I'm applying the forces from there) requires computing the inverse of Kepler's function K(E, e) = E - e sin E, which, even if you start with a table, has to be refined by a few steps of Newton's method, each step of which will require a division (which might as well be for free) and a trig function, which will be a few hundred cycles. Let's say 200 cycles, three Newton steps, 600 cycles. That's 600 B cycles to compute the positions of all the bodies, 600 B + 20 B V cycles for the stage. In KSP, B=20, so 20 B^2 = 8000 < 12000 = 600 B. (Okay, I was biased in picking the numbers, but that's the same sort of speed).

Things change if you want to pick significantly larger steps, and I'll need to read a few papers Scott mentioned. The general idea seems to be that you move bodies following their orbits around the barycenter, then take care of the influence of other bodies, handle close encounters separately, rinse and repeat. This still is fully N-body though. The concerns of system stability that Scott was raising are irrelevant to RSS (if I can show that Jupiter will lose one of its moons within the next year, I probably screwed something up---or I should be published in Nature), and can probably be handled in stock KSP by moving the planets to a more stable configuration. Anyway, who doesn't like stray planets flying around?

EDIT: Another reason for not keeping the planets on-rails is that you lose symplecticity (the energy, momentum and angular momentum of your system may drift).

Edited January 28, 2014 by eggrobin

[NathanKell]

eggrobin: I *do* use doubles in MFT/RF for all resource amounts. I don't for volume though, that's true. Worth trying.

Also, for real distances we'd need at least 1m warp (31.6s/year)--can it work at that speed?

Unmanaged sounds like a good solution here.

[eggrobin]

Also, for real distances we'd need at least 1m warp (31.6s/year)--can it work at that speed?

Unmanaged sounds like a good solution here.

With the current (C#) integrator, a 10 s timestep won't let you above 120_000x (and with 80 vessels, that would go down to ~24_000x). I'm not sure how much unmanaged code will improve things and while I might end up doing it, I don't want to think about doing computations on the GPU right now.

However, once I implement the Chambers-Saha-Tremaine integrator (Saha & Tremaine 1994), with modifications by (Chambers 1998), who apparently worked with the one and only Manley, I should be able to do most of the integration with timesteps of a few weeks, thereby making thing way faster (hopefully fast enough for a few years of prediction---with reduced tolerances---in a FixedUpdate or two for vessels under thrust). I might still use the 5 s timestep stuff, which seems to be as good as exact, for low timewarp, and maybe tweak the Chambers-Holman-Saha-Tremaine-Wisdom (yes, there's also Holman & Wisdom 1991) integrator to a higher order than 2.

EDIT: Regarding floats, it's a bad idea to ever manipulate anything with lower precision than doubles. Depending on how it's compiled and what it's compiled on/for, computations with floats can also be slower

Edited January 29, 2014 by eggrobin

[Guest]

Hmm, that sounds interesting. I'm really looking forward to seeing this. Also, I wonder what Squad "n-body is impossible!" will say when they see this.

[eggrobin]

Next up: "general relativistic effects, such as frame-dragging and the precession of the perikerbolion of Moho, are impossible!" (and I'm not doing that in the foreseeable future).

EDIT: unrelated to GR, but not treating the planets as point masses, but as quadrupoles, might allow for Sun-synchronous orbits, which would be a nice thing. Let's get this point-mass thing working first.

Edited January 29, 2014 by eggrobin

[Agathorn]

I'll just say you are way smarter than me and i'm looking forward to what you do. Please let us know when you make your dev thread so I can bring a drool bucket.

[Guest]

I suppose I could live without GR effects such as those. Though certainly a factor when planning space missions, they're mostly important when talking mechanics of the system itself. Sun-synchronous orbits would be nice, though.

Also, will this allow for solar sails, torchships and realistic ion engines? Right now, all those things are hindered by inability to apply thrust under high warp.

[eggrobin]

Also, will this allow for solar sails, torchships and realistic ion engines? Right now, all those things are hindered by inability to apply thrust under high warp.

This would be easy* to put in the integrator I think, as would orbit decay due to atmospheric drag at higher altitudes (provided I can get assistance from Ferram in computing drag).

I need some sleep right now.

* Rien n'est simple, Tout se complique (two books by Sempé). EN: Nothing is simple, Everything gets more complicated. This applies surprisingly well to anything software-related.

[ferram4]

I'll be happy to help you out with the orbital decay drag, which shouldn't be too difficult, since free-molecular flow works out to be pretty simple to solve. I'll probably also pick your brain on compiling some stuff in C++, since I've never managed a project that involves two different languages at the same time and I'd like to optimize some more things in FAR.

[HoneyFox]

NathanKell: I might as well say it more explicitly: n-body physics (and once that works, I'd like to add other stuff, e.g., orbit decay outside the 'official' atmosphere, conservation of angular momentum through timewarp to allow for spin-stabilisation, etc.). Let me hijack your thread with pictures of trajectories (which don't really show fancy n-body physics, but do show plotting of n-body trajectories which happen to be very close to the 2-body ones in various reference frames). As you can see, the other orbit is ever so slightly broken. Also, this only affects on-rails craft at the moment. There is quite a bit of work ahead.

http://imgur.com/a/ZGlqp

NBody? I made a similar plugin before too... it emulates all gravity by other bodies and since i implemented that on a per-part basis, the tidal lock effect also occurred.

but it slows down the FPS quite a lot when the game was using LineRenderer to render lots of line segments...

And I also did tests in stock KSP's Jool system, the predicted trajectory is very ... very interesting.

[Agathorn]

Sun Sync orbits would rock. Very much so. I've wanted to do that for so long That and of lagrange points, which we should get if you are expanding things to be n-body.

[HoneyFox]

I stand corrected on pressurized tanks; didn't realize just how small they had to be to use the bladders. HoneyFox, my apologies for leading you astray!

Then the entire pressurized fuel tank logic goes wrong...

Something I'm wondering is: if a bladder tank can only hold a volume of nearly 100L, we can still install multiple of them right, eggrobin?

So perhaps, we can just consider the "(pressurized)" as "(bladders)". I mean we have multiple bladder tanks inside a casing, so there's no limit on the total volume but the dry mass penalty might increase quite a bit.

Something I'm thinking:

1. Adjust the ServiceModule's dry mass calculation if needed. Change the note "(pressurized)" to "(bladders)" so that these tanks are now considered to be using bladders to eliminate the ullage need. For the old "(pressurized)" note, I wonder it's now only for XenonGas & ArgonGas again.

2. I need to remove the logic of "Pressure-fed engines need pressurized fuel tank" because now we don't have that kind of feature anymore. (or do we still want that?)

3. What is a Surface Tension Tank, i need some more information about it, better with some images of its structure so I can understand that better. And perhaps i have to write another function for judging fuel stability for this type of fuel tank.

And from the reference material eggrobin gave to us, there's a type of "Rolling diaphragm" which interests me, is it something like a blender which centrifuges the fuel to the tank wall and the fuel inlets are installed on the wall? Does that mean we can implement a FuelBlender PartModule for fuel tanks that has a note "(centrifuge)" or something like, and once this part module is activated, it consumes plenty of "ElectricCharge" to drive the blender in the tank for a while before the ignition can be commited? This should be an interesting idea and it sounds reasonable IMO.

4. Finally the cryogenic fuel's boil-off micro-acceleration feature has more importance now if the ullage need is not resolved by using a pressurized fuel tank. and... uh... NK you haven't provided me the dictionary yet, so I replicated your logic and acquired all these data by using lots of .NET reflection.

[HoneyFox]

It seems you got it right originally: you *need* ullage thrust for anything other than small-capacity tanks (the propellant is in a bladder by the way, not the other way around). It's a good thing you don't need ullage thrust for RCS, otherwise you'd need to light an SRB in order to to enable fine attitude control...

I rethink about the bladder tank, and still i don't see any reason why gas pocket will not float to the propellant inlet even if there's bladder. Perhaps the propellant must not boil-off, otherwise there will still be gas inside the bladder and you still have no way to keep it away from the inlet, right? Thus any kinds of cryogenic fuel is not allowed. (Ok, i forgot that the bladder itself might not even be able to endure such cold temperature...)

The exception is low-thrust stuff, where you can use surface tension tanks. You'd have to tweak the ullage simulation for those though, as they settle in zero g but are messed up by any acceleration.

Where are the propellant inlets located on this type of fuel tanks? on the side wall I guess?

This sounds quite impractical if the acceleration has to be very small, how much acceleration can it usually endure?

- bladder (no ullage constraints to feed from it, max. volume a few 100 L)

- surface tension (can only feed from it at very low accelerations)

- normal (can feed from it under the current ullage conditions)

Where only pressure-fed engines can feed from bladder and surface tension tanks.

One thing i wondered before: can't a pressurized tank bladder tank serve a normal engine as a starter? It can be used by the engine to generate small thrust (which ullages the main propellant fuel tank) as well as being able to initiate the turbo pumps later when the ullage process is done, right?

Edited January 29, 2014 by HoneyFox

[eggrobin]

Something I'm wondering is: if a bladder tank can only hold a volume of nearly 100L, we can still install multiple of them right, eggrobin?

Yes, and they did that on the LM (they used two tanks for each ergol, cleverly called 'Oxidizer/Fuel A and B'; see schematics APOLLO EXPERIENCE REPORT - LUNAR MODULE REACTION CONTROL SYSTEM, page 4). That's quite a bit of piping though.

So perhaps, we can just consider the "(pressurized)" as "(bladders)". I mean we have multiple bladder tanks inside a casing, so there's no limit on the total volume but the dry mass penalty might increase quite a bit.

On the one hand, that makes sense. On the other hand, I've not heard of something other that RCS/tiny satellite engines being fed from bladders. Even the larger RCS tanks seem to be surface tension.

2. I need to remove the logic of "Pressure-fed engines need pressurized fuel tank" because now we don't have that kind of feature anymore. (or do we still want that?)

It depends whether you still have the old-style pressurised fuel tanks. If we want to fully model the mass overhead from He blowdown (and thus He tank, piping &c.), we will probably need to have them, thus pressure-fed engines can only feed from pressurized tank (as in real life), but they still need fuel stability.

If we want to ignore this (it doesn't change much gameplay-wise now), pressure-fed engines are just like any other engine.

3. What is a Surface Tension Tank, i need some more information about it, better with some images of its structure so I can understand that better. And perhaps i have to write another function for judging fuel stability for this type of fuel tank.

Where are the propellant inlets located on this type of fuel tanks? on the side wall I guess?

This sounds quite impractical if the acceleration has to be very small, how much acceleration can it usually endure?

http://cs.astrium.eads.net/sp/spacecraft-propulsion/propellant-tanks/surface-tension-tanks.html

On modern tanks, the acquisition vanes are all around the walls, yes.

It seems to only be used on RCS.

And from the reference material eggrobin gave to us, there's a type of "Rolling diaphragm" which interests me, is it something like a blender which centrifuges the fuel to the tank wall and the fuel inlets are installed on the wall? Does that mean we can implement a FuelBlender PartModule for fuel tanks that has a note "(centrifuge)" or something like, and once this part module is activated, it consumes plenty of "ElectricCharge" to drive the blender in the tank for a while before the ignition can be commited? This should be an interesting idea and it sounds reasonable IMO.

Nope, it's just another kind of positive-expulsion (bladder-like) tank. It would only matter if we considered shifts to the part CG due to fuel mass distribution, and I don't quite think we're ready for a realistic plumbing mod where you have to make sure your propellants won't eat through your tanks, route the pipes, place the tanks inside the stage, chose their shape, place He tanks, route the helium to the preheaters and then to the tanks...

4. Finally the cryogenic fuel's boil-off micro-acceleration feature has more importance now if the ullage need is not resolved by using a pressurized fuel tank. and... uh... NK you haven't provided me the dictionary yet, so I replicated your logic and acquired all these data by using lots of .NET reflection.

Perhaps, I haven't looked at that in detail.

I rethink about the bladder tank, and still i don't see any reason why gas pocket will not float to the propellant inlet even if there's bladder. Perhaps the propellant must not boil-off, otherwise there will still be gas inside the bladder and you still have no way to keep it away from the inlet, right? Thus any kinds of cryogenic fuel is not allowed. (Ok, i forgot that the bladder itself might not even be able to endure such cold temperature...)

They're only used for storable propellants, from what I can see, so there's no bubble (the gas is outside the bladder).

One thing i wondered before: can't a pressurized tank bladder tank serve a normal engine as a starter? It can be used by the engine to generate small thrust (which ullages the main propellant fuel tank) as well as being able to initiate the turbo pumps later when the ullage process is done, right?

Maybe, but the plumbing would probably be insane. I've not seen any evidence of that.

As a conclusion,

Non-RCS/ACS/whatever it's called engines don't seem to use bladders.

However,

The acquisition assembly consists of four stub galleries and a collector manifold. The stub galleries acquire wall-bound propellant at OMS start and during RCS velocity maneuvers to prevent gas ingestion. The stub galleries have screens that allow propellant flow and prevent gas ingestion. The collector manifold is connected to the stub galleries and also contains a gas arrestor screen to further prevent gas ingestion, which permits OMS engine ignition without the need of a propellant-settling maneuver employing RCS thrusters. The propellant tank's nominal operating pressure is 250 psi, with a maximum operating pressure limit of 313 psia.

[...]

If the amount of OMS propellant used before MECO leaves less than 28 percent of OMS propellants, a 15-second aft RCS ullage thrust is performed after MECO to provide a positive OMS propellant feed to start the OMS-1 thrusting period.

So the OMS was fed in a surface-tension way (but not quite, since they still work under their own thrust), unless the fuel level is below 28%, in which case you need ullage thrust for long burns (this is getting complicated).

Moreover,

The left and right OMS crossfeed A, B switches also provide the capability to supply OMS propellants to the left and right aft RCS engines. The left and right aft RCS will not be used to supply propellants to the OMS due to differences in pressures between the OMS and RCS.

Ok, let's not go down the rabbit hole of the plumbing weirdness of the STS.

How about this: engines need ullage acceleration no matter what (and if we want do model thicker pressurised tanks as well as the overhead from He storage and piping, pressure-fed engines can only feed from pressurised tanks). They can't feed from bladder and surface tension tanks.

RCS can feed from either bladder or surface tension tanks (if you really want to allow for crazy stuff, let's say they can also feed from normal pressurised tanks, though as this might accidentally drain your main engine fuel, it needs to be toggleable in flight), with no ullage requirements for bladder, low acceleration for surface tension (basically, any acceleration that makes the water clinging to your ceiling fall down is bad), and if you want to go that way, standard ullage requirements for standard pressurised tanks.

This is simple enough to be understandable, models most of the existing interesting complexity, and doesn't force us to draw plumbing schematics and do advanced fluid mechanics in order to be sure that the OMS *will* fire when we need it.

EDIT: Apparently, NathanKell was right about the gas being inside the bladder and the propellant outside.

Edited January 29, 2014 by eggrobin

[HoneyFox]

Yes, and they did that on the LM (they used two tanks for each ergol, cleverly called 'Oxidizer/Fuel A and B'; see schematics APOLLO EXPERIENCE REPORT - LUNAR MODULE REACTION CONTROL SYSTEM, page 4). That's quite a bit of piping though.

On the one hand, that makes sense. On the other hand, I've not heard of something other that RCS/tiny satellite engines being fed from bladders. Even the larger RCS tanks seem to be surface tension.

It depends whether you still have the old-style pressurised fuel tanks. If we want to fully model the mass overhead from He blowdown (and thus He tank, piping &c.), we will probably need to have them, thus pressure-fed engines can only feed from pressurized tank (as in real life), but they still need fuel stability.

If we want to ignore this (it doesn't change much gameplay-wise now), pressure-fed engines are just like any other engine.

http://cs.astrium.eads.net/sp/spacecraft-propulsion/propellant-tanks/surface-tension-tanks.html

On modern tanks, the acquisition vanes are all around the walls, yes.

It seems to only be used on RCS.

Nope, it's just another kind of positive-expulsion (bladder-like) tank. It would only matter if we considered shifts to the part CG due to fuel mass distribution, and I don't quite think we're ready for a realistic plumbing mod where you have to make sure your propellants won't eat through your tanks, route the pipes, place the tanks inside the stage, chose their shape, place He tanks, route the helium to the preheaters and then to the tanks...

Perhaps, I haven't looked at that in detail.

They're only used for storable propellants, from what I can see, so there's no bubble (the gas is outside the bladder).

Maybe, but the plumbing would probably be insane. I've not seen any evidence of that.

As a conclusion,

Non-RCS/ACS/whatever it's called engines don't seem to use bladders.

However,

So the OMS was fed in a surface-tension way (but not quite, since they still work under their own thrust), unless the fuel level is below 28%, in which case you need ullage thrust for long burns (this is getting complicated).

Moreover,

Ok, let's not go down the rabbit hole of the plumbing weirdness of the STS.

How about this: engines need ullage acceleration no matter what (and if we want do model thicker pressurised tanks as well as the overhead from He storage and piping, pressure-fed engines can only feed from pressurised tanks). They can't feed from bladder and surface tension tanks.

RCS can feed from either bladder or surface tension tanks (if you really want to allow for crazy stuff, let's say they can also feed from normal pressurised tanks, though as this might accidentally drain your main engine fuel, it needs to be toggleable in flight), with no ullage requirements for bladder, low acceleration for surface tension (basically, any acceleration that makes the water clinging to your ceiling fall down is bad), and if you want to go that way, standard ullage requirements for standard pressurised tanks.

This is simple enough to be understandable, models most of the existing interesting complexity, and doesn't force us to draw plumbing schematics and do advanced fluid mechanics in order to be sure that the OMS *will* fire when we need it.

EDIT: Apparently, NathanKell was right about the gas being inside the bladder and the propellant outside.

Ok I'm lost...

I need to work out a solution ...

And since the gas is in the bladder, can we have multiple bladders in a bigger tank so that each of them can occupy some ullage space?

[Spanier]

Question, will you add a rescale of the stock engines/tanks to match the new metric system, or shall I do it myself?

And are those many additional parts essential?

Edit:

How can I turn of this:

Edited January 29, 2014 by Spanier

[eggrobin]

And since the gas is in the bladder, can we have multiple bladders in a bigger tank so that each of them can occupy some ullage space?

You need the bladder to fill the tank completely when inflated, so I'm afraid this would be next to impossible. Piston or rolling diaphragm designs might work.

As for a solution, I think we should ignore the really fiddly details of the STS OMS and go with the following for engines non-RCS:

- All non-RCS engines need stable fuel to start (the fuel should be at the bottom, current ullage simulation).

- Pressure-fed non-RCS engines can only feed from pressurised tanks, which are heavier (thicker tank wall, helium piping and tanks).

The fancy tank types are only used for RCS engines, with the following characteristics.

- RCS can only feed from bladder (representing bladder, piston and rolling diaphragm) and surface tension tanks. Bladder tanks are heavier for the same fuel quantity, as they represent clusters of small tanks (the mass should increase linearly with the volume for volumes above 50 L, representing clusters of tanks rather than one tank getting larger).

- If the ullage simulation says the bubble's not in the middle, RCS can only feed from bladders. RCS can always feed from bladders.

This way RCS doesn't accidentally feed from main propellant tanks, and if you want to do that (which should be a backup plan), you can use the game's fuel transfer.

EDIT: for the proportionality constant for bladder tank mass, I would suggest using the Astrium site as a reference: 8.5 kg of tank mass for 39 L of propellant. Add to that about 100 g of He (for a starting pressure of 26 bar, which is the upper range of inlet pressures specified by the Ariane 5 ACS thrusters), handwave in another 400 g for a few valves and piping, and call that 230 g/L (litres of fuel). As far as density goes, the volume of the sphere seems to be 58 L, so if we pack the spheres closely, that's 1 l of fuel for 2 l of tank space. This should be enough to make filling the stage with bladder tanks prohibitive.

EDIT2: If we want to add an interesting detail, both types of RCS tank have two possible configurations: blow down, where the tank contains some set amount of pressurant gas and pressure (thus thrust) decreases as fuel gets used up (many examples Ariane 5 is one), and pressure regulated as in the LM bladders or most large surface tension tanks. Pressure regulated means constant thrust, but more mass (more pressurant gas, need an He or N tank).

So that would make our lineup:

- For non-RCS engines:

-- Unpressurised for turbopumps

-- Pressurised for pressure fed

- for RCS:

-- Bladder blow down, heavy but always works, decaying thrust.

-- Bladder regulated, heavier still but constant thrust.

-- Surface tension blow down, works in zero g, don't shake, decaying thrust.

-- Surface tension regulated, a bit heavier, constant thrust.

If we only want two types of RCS tanks, I'd recommend bladder blow down and surface tension regulated: the point of bladders is to be simple. If we can allow three, I'd say both bladders (but if we can do three we can do four).

With that we should be set as far as tank types go. (There's the spin stabilized ones, but we'll worry about those when we can keep things spinning through timewarp).

I'll be happy to help you out with the orbital decay drag, which shouldn't be too difficult, since free-molecular flow works out to be pretty simple to solve. I'll probably also pick your brain on compiling some stuff in C++, since I've never managed a project that involves two different languages at the same time and I'd like to optimize some more things in FAR.

Caveat: I haven't tested this yet.

The thing you really want is *unmanaged* C++, compiled with clang or something like that, which you call from *managed* (CLR) code in your plugin (managed C++ won't be much faster, and using the Visual Studio compiler, double is the same as long double, so you can't make use of 80-bit extended precision either).

The most straightforward way to do this is to just import an unmanaged dll, but you have to be very careful with marshalling and keeping your interfaces compatible and declaring your members in the right order... O, that way madness lies. Let me shun that; No more of that.

A better solution is to have your C# code call some C++/CLI code, also managed, so it's like calling C# code, and have the C++/CLI code reference unmanaged C++ (as you have a header file, you don't have to do the interfacing brute-force).

Edited January 30, 2014 by eggrobin

[Zyglrox]

I have a small bugreport/suggestion regarding SFJackBauer's engine config.

On a clean installation of KSP, with only FAR, RF, RO, RSS, SSRB and Soviet Engines pack (all default configs), the RD-0124 engine always gets a lot of heat very fast and explodes, and it can't be throttled down. I don't know about other engines, only tested this. After removing "%heatProduction = 400" from config (default=150), it doesn't explode anymore.

Suggestion: since Soviet Engines are already designed with realistic size system and realistic stats, maybe heat production should be left alone too? Or, if 400 is some magic number and is required for something else, they should at least be made throttle-able to some extent to prevent overheating. I used only KW engines before and never had this problem.