BudgetHedgehog

Ohhh, so THAT'S what JSI stands for! I've always wondered...

Yeah, the only ones left are deployable ones.

KAX has an electrical propeller, Kethane has that Turbine and there's always rocket engines. They don't need to be high TWR - the plane I was on about earlier was a beauty to fly and stayed a steady 200m/s despite having a TWR of around 0.3. So for rockets, you could easily each them with 1 or 2 x 48-7S's or similar. EDIT Sorry, I meant it as an average. For a min/max, I'd say 15-35 or so. I've never flown in Jools atmosphere before so this is really just an educated guess.

What, the reactors with radiators that break in atmosphere if they're deployed and you look at them hard enough? Things might get hairy if you end up driving around attached to a reactor with no cooling mechanism.

Well, the thing is, jets make it a lot easier - higher fuel efficiency means you can take your time in completing the contract. I think they should be within cruising height of most jets which means, off the top of my head: Kerbin - 7/20km Laythe - 5/17km Duna - 3/15km Eve - 10/25km Also, for shiggles, have one for Jool at 30km They're complete guesses but should be doable with planes.

I'll just chime in here and say that I had a contract to test a part at 24000m between 400 and 600 m/s. Getting that high and staying that slow with a turbojet took about 20 minutes and I didn't even finish it - I could get that high but once I'd slowed down, I dropped too low. So for 35km high, you'd need basically either a spaceplane or an airhog. Reconnaissance planes in real life varied from Spitfires which had a maximum operational altitude of 10km up to SR-71s with a usual height of 24km. What they translate to in scaled down Kerbin, I don't know, but I think a minimum of 7km and a maximum of 20km should be well within reach of most air reconnaissance.

Good stuff. Only trouble is, I'm running KER 1.0.0.1

Limitation of KSP, im afraid. If you make the fuel flolike normal monoprop and are pushing a lander or something that is staged to decouple from the SPS stack, it'll use ythe landers supply before its own. So it was changed to act like normal fuel which means radial tanks need fuel lines connecting them to the stack. A MM config will allow surface attachment for them if they don't currently support it.

Because right-clicking and cutting chute is slower and harder than just hitting Space and decoupling a decoupler

What did I say? You're one skilled code monkey Huge thanks!

"Hey, you didn't specify that it had to have fuel in! I'm just saying - you told us to stage it, and we staged it. Gib funds plz"

Disable/empty the thrust and fuel in BACC and attach it to a plane with high powered engines. Boom, done. I have a pretty decent test rig for 'In Flight Over Kerbin' contracts - with SP+ and FAR, almost anything is possible. Test RAPIER on suborbital flight? Done. Test chute at 10km? Done (and then swiftly decoupled). Smaller surface mounted items go in the cargo bay, everything else can be slapped on the outside. Hella fun, I tells ya.

"You must spread some Reputation around before giving it to Biotronic again." God damn it...

Sweet Jebus, he's alive! Hallelujah!

KSP 0.24.1 changelog: * Added IPartCostModifier interface, to allow part modules to tweak a part's cost. How does TweakScale plan to handle/change/cope with/adapt to/incorporate this?

That's just a problem with B9s attach nodes being in the wrong place and is easily fixed with a MM config.

First off, there's no need to quote the entire OP, or indeed, quote it at all. Second, which buttons do you mean? Mechjeb buttons, or KSP buttons?

From the parts description, emphasis mine:

Do you have the B9 fixes installed? The engines have that NaN bug that spreads throughout the craft and breaks FARs displays.

This is why:

Yeah, it triggers when the staging list in the editor covers the Exit button. You click Exit, KSP gets confused and breaks. It's a known bug with stock. @saegio - do you have Module Manager installed as well? The lack of RPM in IVA indicates that it (ALCOR IVA) is not being applied - either it doesn't exist or MM doesn't exist/is failing to apply the changes.

That was an issue due to things like fuel tanks being the root part of the vessel. The latest version, 2.6c, apparently "altered scaling system to cure scaling issues", so upgrade to that and try again. EDIT: But I have just experienced a scale bug myself. 1.25m decoupler rescaled to slightly bigger upon vessel reload. Wasn't the root part, was fine up until then.

Speaking from experience, that's pretty much all that can be deduced from the video. Yes, one pair of tracks seem to (barely) work ok in one specific situation. What about a different craft? Un/redocking? More than one set of tracks? Maybe the Ackerman steering isn't working/implemented on these tracks? In short, there's a lot that can delay a release and being one of the (almost) full-time testers, I can say that these kind of things are legitimate reasons to delay a release.

Probe dependency on (LoS and transmission): physical timewarp speeds up animation, rails timewarp has no visible effect. FRAPS recorded a steady 35-40 FPS during the entire video. Relevant output log from this - there's a few errors from Engineer so ignore those but otherwise, there's nothing that seems to affect antenna animation.. hmm...

BA5 adds clouds to the Sun which makes it white close up. This is the relevant section of BoulderCo/Clouds/CloudLayers-BetterAtmospheres CLOUD_LAYER { SAVED { body = Sun altitude = 1.2E+07 volume = False color { r = 33 g = 33 b = 33 a = 3 } main_texture { file = BoulderCo/Clouds/Textures/Sun scale = 1 offset { x = 0 y = 0 } speed { x = 0 y = 0 } } scaled_shader_floats { falloffPower = 0 falloffScale = 3.5 detailDistance = 0.00875 minimumLight = 0.5 fadeDistance = 0.4 rimDistance = 1 } shader_floats { falloffPower = 0 falloffScale = 3.5 detailDistance = 2E-06 minimumLight = 0.5 fadeDistance = 1000 rimDistance = 0 } } } As long as that's in whatever cfg is present in BoulderCo/Clouds, the sun will be white.