Dr. Jet

Next release at last! Nice! So... does it have HoneyFox's patch for partial FAR support? And what about MJ compatibility with time delay feature?

Maybe it will be better to have 3 big monitors on the wall than 1 big and 4 small? Big ones can serve as panoramic view for 3 frontal cameras, while 4 smaller monitors on the desk are enough for every other need.

So, it wont work... And to make it work I need either to write my own plugin (considering I'm NOT a programmer), or remaking a part with inbuilt panels and deploying animation (which cannot be imported from existing parts) and second SP module... Complete sadness... Any way to do sun tracking with IR parts ? I doubt that. However, the idea itself is pretty... Not only suntracking, but tracking ANY targettable object with IR-driven manipulators... Very useful for KSPI microwave transmitting... and possibly further versions of RT... But who will write such a code?

I've made a small part, functionally resembling Balka Solar Wings central block. http://www./download/ocpmo2vurvpedtf/SolarBase.zip The moving part was following the sun correctly. Then I wanted to put some solar panels on that in VAB (that was the main reason for making such a part ). Panels attached, as the collider was in place, but after launch, when central part actually started to move, solar panels didn't want to follow and just sat there. What can be the problem and how to fix it?

They do. Especially when chute-landing something HEAVY on Eve's surface. It looks like removing suspension limits, so that piston falls all the way in. So, it may probably work with current config, as it does have a suspension.

You had to rework the .mu files for legs, right? I haven't seen "WheelCollider" colliders in them before. Anyway, great job! My tiny little cute lander probes are very happy to have both compact and WORKING legs again!

Always wondered why RT2 active antennas break at ascent while fully shielded by cargo bay or fairing, making such neat thing as "satellite-controlled jet drones" nearly impossible. So... the actual code in question is: if (MaxQ > 0 && animState == 1 && (vessel.srf_velocity.magnitude * vessel.srf_velocity.magnitude * vessel.atmDensity * 0.5) > MaxQ) { part.decouple(0f); explodeMe = 10; } You see? Not a single sign of checking for "is_shielded" parameter or FAR current drag value (which is realistically position dependent). Thus Q is counted independently of actual environmental exposure and shielded antennas break when they shouldn't. That's not good. We obviously must have a bit of FAR integration here.

They actually do work... partly... When using ModuleLandingLeg like in AIES (without adding suspension) deployment animation plays as intended, but retraction just triggers the legs position instantly. Same problem was discussed on forum - it was something about missing colliders.

Version 3.0.3 looks like having a bug... No matter how many nodes I set, there are only 2 nodes visible and game engine believes those two have 8x symmetry. Update: The problem was with the old version of EditorExtensions.dll. With version 1.1 fairings work smoothly.

Working ModuleLandingLeg configs for Thor landing struts, anyone? Those are completely defunct for now - not a single animation module in .cgf. I believe it should be "Foot" for wheelColliderName, but what about suspension?

Excellent job, man! I'm happy like a child! Can't wait for more MechJeb commands! Self explaining examples: next vessel press "]" prevoius vessel press "[" show ascent guidance (opens MJ window) set ascent altitude to <number> kilometers set ascent inclination to <degrees> degrees ascent autostage <onOFF> limit autostage <number> show ascent path (opens MJ window) set ascent path start to <number> kilometers set ascent path end to <number> kilometers set final angle to <90degrees> degrees set ascent path shape to <90degrees> degrees start ascent circularize now circularize in <number> seconds circularize at <number> kilometers change periapsis to <number> kilometers at <apPe> change periapsis to <number> kilometers in <number> seconds change periapsis to <number> kilometers now change apoapsis to <number> kilometers at <apPe> change apoapsis to <number> kilometers in <number> seconds change apoapsis to <number> kilometers now change iclination to <degrees> degrees at <anDN> change iclination to <degrees> degrees in <number> seconds change iclination to <degrees> degrees now set target body <CelestialBody> match planes at <anDN> hoffman transfer fine tune approach at <number> kilometers resonant orbit <number> slash <number> rendezvous autopilot Can't figure out how to select appropriate docking ports at target vessel, so Docking autopilot if out of commands... yet.

Hmmm... Did you noticed that some parts you deleted are NOT duplicates of the B9 counterparts? Especially the cargo bays. Those are spacier then B9 ones, also they're stackable and have actually CENTERED cargo nodes which is priceless. I'll better delete B9 MK2 and stay with those. BTW, spaceplanes are all about balancing things right. No RCS? Bad fuel balance? Modular Fuel Tanks will fix that. Here's the config for MFT: -PART[mk2Fuselage_L]{} -PART[mk2Fuselage_Short_L]{} @PART[mk2_1m_Adapter] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} MODULE { name = ModuleFuelTanks volume = 300 type = Structural } } @PART[mk2_1m_AdapterLong] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} MODULE { name = ModuleFuelTanks volume = 500 type = Structural } } @PART[mk2_1m_Bicoupler] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} MODULE { name = ModuleFuelTanks volume = 300 type = Structural } } @PART[mk2Fuselage_LFO] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} MODULE { name = ModuleFuelTanks volume = 600 type = Default } } @PART[mk2Fuselage_Short_LFO] { //!RESOURCE[LiquidFuel] {} //!RESOURCE[Oxidizer] {} MODULE { name = ModuleFuelTanks volume = 300 type = Default } } You don't need separate LF tanks with MFT, so those two are removed. Adapters are EMPTY by default, as they are structural parts, but they still have the proper capacity which you can fill. RCS and Xenon can be added to any part in MFT config window, but if you want to have an inbuilt battery somewhere - change the part type to "ServiceModule".

Is it possible to add several "JSIExternalCameraSelector"s to one part? Especially, make 4 inbuilt cameras (3 frontal and 1 backward) of SpaceTech "Eva" (nice probe core body) to actually work? --- Update - 23.04.2014 Possible. Just got it to work. Frontal (90,0,0) and backward (270,0,180) cameras work perfectly. But I was unable to chose the right angle for frontal side cameras. It seems that "rotateCamera = 90,0,45" and "rotateCamera = 90,45,0" rotate the camera AROUND THE SAME AXIS (and that's not the axis needed). How can that be? P.S. RPM Version 0.15 as I still play with KSP 0.23. Using Model{} tag in part config for model rotation, if that matters.

BTW, are those fairings and cover FAR-compatible? I mean the "is shielded" feature.

FAR-shielding compatible?

Works WONDERFUL at Kerbin now. But Eve... too low boundaries problem again... deployment altitude. At Eve system can't predeploy and deploy drogues HIGHER then they actually start to burn. Current ceilings for predeployment and deployment are 50 km and 45 km. It's maybe even too high for Kerbin (40-35 proved to be enough), but it's still too low for Eve. Eve magical descent need drogue deployment ceiling to be 75-70km.

Thanks, man! Tremble, Eve, here comes the BI-I-I-I-IG lander! Bwahahaha!!!

Tried to test it with extra-safe 1500 m/s. No red color anymore, but still "ERROR: Invalid parameters: Main Chute: Landing speed"

Well... OK. Though I was using a drogue-only chute - not coupled. But what values should I type in to achieve the abovementioned? A very-high drogue deployment and aerobraking to about 2 km/s before dangerous altitude?

It seems that option window doesn't accept the "wanted speed at full deployment" parameter for the drogue chute above 300 m/s. But WHY? Achieving 2 km/s is quite enough for safe reentry. We don't need to decelerate to 0.3 km/s. What is wanted ingame: full deployment of drag chutes at 40-45 km altitude (yeah, pressure there is neglible, but on the other hand - the speed is HIGH so chute must deploy correctly), deceleration to about 2 km/s before entering denser layers of atmosphere, cut off drogue chute (to prevent it's burning), predeploy main at 1 km, deploy main at 300m, landing. Yes, I know that actual drogue chutes deploy at 8 km. But the link in upper post is about a high-altitude/high-speed drogues, intended to lower the reentry speed and thus get rid of need for ablative shielding.

May I ask something about drogue chutes? Why their resulting velocity boundaries are set so low? What is wanted from a small and light drogue chute is to deploy as high as possible, then orient the landing craft at right vector and lower it's velocity... a bit... just to avoid the excessive reentry overheating. Gamewise it will be about 2000-1800 m/s speed. http://arxiv.org/pdf/physics/0701094.pdf - I'm talking about reentry scheme like this. Have not heard about it's implementation in IRL crafts, but the scheme is plausible at least. And yes - it will be REALLY NICE to see it working in KSP+FAR+DE with RealChutes.

Win 3.11 was nice Win 95 was crap Win 98 was nice Win Me was crap Win XP was (and is) nice Win Vista was (and is) crap Win 7 is nice Win 8... did you catch on the pattern? Morale: Wait for Win 9 if you don't like Win7x64

IIRC, you don't need it to actually FIT... At least to fit the VAB height. Your lower stage width is a thing you should worry about when building a several kilotons monster. Launchpad is not that big, you know.

BTW, Chris, have you seen an old Spacetech chute from Escape Pod modpack? A bit similar to your double chutes, but it uses foldable airbrakes as a first stage instead of a drogue chute (however it doesn't deploy them at as high altitude as expected). The idea seems to be cool... using airbrakes for orienting pod and slowing it down at speeds where any chute will burn or tear off... How do you think, is it possible IRL?

My Best advice is to install CustomBiomes mod. You'll get a lot more fun fully exploring a same stellar body... and recover a lot more science too... even without returning probes.