NathanKell

Hmm, neat! Um, might want to have it moved to Tools and Apps subforum though?

...why not just replace the file? The point of TR is to replace files that aren't user-accessible (locked up in KSP assets)

Ah, I was so hoping you'd post this on the forums so I could thank you--awesome job!

If you can do it all shader-side, then yes. The shader is very under-utilized in KSP. If you have to use CPU time to do it, not so much; it's already CPU-bottlenecked.

The advanced tab offers you various vectors to align to, and the six cardinal orientations. So Surface_Forward is your surface velocity vector (and choosing Surface_Forward and forward will align you with surface prograde); Surface_North is towards the north pole, etc.

Life support oxygen is usually stored as GOX to avoid headaches dealing with cryogenics. But I know Apollo did store it as LOx, due to using LOx/LH2 for its fuel cell (some LOX was heated for breathing; the resultant water (from combination) was used for drinking.

Most welcome! The tanks for breathing aren't LOX, they're gaseous oxygen. What you might make is a small "converter" part that converts LOX to GOX, if you want to carry around your breathing oxygen as LOX (and accept the boiloff).

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.

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?

Scientific notation. 6.67 * 10 ^ -11

As the RF OP/readme/etc say, the engine ignitor configs that come with engine ignitor do not work with RF. That's why the RF engine config needs to have its own engine ignitor configs. At the moment only RftsEngines has Engine Ignitor support; if you're using Stockalike engines or the default SFJackBauer RealEngines, those folks involved haven't had time yet to add Engine Ignitor configs.

That's because the radius and orbits are in km in that equation. If you use meters all round, you can use that big G. http://en.wikipedia.org/wiki/Gravitational_parameter

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.

Ratzap: WAC Corporal was an early sounding rocket designed by Frank Malina at JPL. Used with a Tiny Time booster, and atop ex-V-2s in Project Bumper. Later turned into the Aerobee line. Maybe it doesn't have a custom experiment yet? Rjhere: actually, the thing that changes dry mass etc is Real Fuels. Also engine TWR, and many other things. There is not a pack link yet (making one as soon as latest FAR and KJR come out), although even then it will only includes mods that can be re-distributed; some mods' licenses don't allow it.

They do sound interesting, yes. I really do need to make that replacement ModuleRCS I guess. Also, "I'm slowly working on that" (!) Sounds intriguing!

It depends on which set of engine configs you're using for RF. SFJackBauer hasn't had a chance to add Engine Ignitor settings to the RealEngines pack, and the Stockalike configs don't (they also don't limit throttle), as designed. RftSEngines *do* have EngineIgnitor configs.

sidfu: yup, as Chimer4 found out that's a classic sign of "has more than one engine config installed." Make sure you only have one. If you have StockEngines, delete (from anywhere! in GameData): RftSEngines.cfg MFSEngines.cfg real_engines*.cfg If you have RftSEngines, delete the other files; if you have SFJackBauer's RealEngines, delete the other files. Etc.

They generally don't, actually: that's why I mention it. Hence the upper stage being underpowered. (Not that Centaur, e.g., is *ever* overpowered, but it's even more underpowered if it's lifting a satellite and apogee kick motor into GTO). Heh. Good show.

dlrk: ah, sorry, didn't realize you weren't using regular RSS. Units are meters, kgs, and m/s^2. KSP uses a big G of 6.67E-11. g0 (for use with specific impulse) is 9.82 in the engines (right now) but in the next release of (some mod of mine) I'll fix it.

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! Agathorn: Given that the most efficient path to GEO is usually "launch to LEO but keep burning that upper stage past circularization" the trajectory won't be *much* different. It depends on your upper stage(s)'s TWR. If you're putting a GEO payload on a LEO launcher, and getting it off the ground with thrust augmentation, odds are your upper stage will be underpowered and you'll have to fly it up much higher to have time to get to orbital velocity before hitting the atmosphere again. If it's not underpowered, you can fly a normal LEO ascent; you will have time to hit orbital velocity before reentry. It is always most efficient (AFAIK) to (on ascent) never lift your apogee above where you want your perigee to be. So if doing a 35,786km x 185km GTO, you want your initial apogee no higher than 185km. But given the above, you may need a higher initial apogee with a low-thrust upper stage (though you will doubtless still be burning while falling after apogee, as long as your perigee eventually rises above the atmosphere you're ok).

There's your problem right there. With FAR you need to start your turn when your vessel reaches ~100m/s (less if it's high TWR off the pad). For your average 1.5 sea level TWR rocket, that's about 1km. (If you're launching at 1.2g, which is safer, it's ~1.5km). You set end and shape based on TWR throughout the flight, aiming to never be outside the little prograde marker. If you have a reasonable two-stage rocket (1.2->7, .9->6, say, for the TWRs of the two stages, noting the 1.2 is sea level and the rest vacuum) then maybe something like end at 150 and shape 60? Or even 100/45 if the upper stage has more punch. Anyway, tweak. EDIT: From Ferram:

Wikipedia? They're all changed into actual planets/moons, so the parameters are all the real ones. EDIT: ninja'd. :]

Cool. Looking *very* nice btw. And it's so nice to have a detailed *non* glass cockpit IVA.

You want only one ModuleManager, in the root of the GameData folder; let it be the latest version.

The latest-latest version of DRE has some speedup work by a.g. and should lag less. Also if it's lagging your laptop to death, it's possible that was due to disk writes from errors; post your output_log.txt Regarding joint strength: actually, node size has nothing to do with that; AFAIK the *only* two things node size affects are: (1) the size of the node, visually, in the VAB/SPH, and the snap distance; (2) the "open node" drag in FAR. The only way I know to make the joint wobble less is tweak the collision meshes of the two parts involved so they sit together better/more evenly/tighter.